Système CRM synchronisable

Question

Je dois développer un système de gestion de la relation client qui permettra aux utilisateurs de disposer d’une copie locale de la base de données, qui pourra ensuite être synchronisée avec le système du serveur principal. L’idée est qu’une équipe de vente puisse se rendre dans des zones non équipées d’Internet et continuer à fonctionner avec des informations relativement à jour, puis se synchroniser à son retour au bureau.

Je n’ai jamais fait quelque chose comme ça auparavant, est-ce que quelqu'un peut recommander une solution de synchronisation?

Answer 1

Ayant moi-même écrit un tel système, je vous recommande de l'éviter si possible. Les moyens par lesquels les utilisateurs peuvent bousiller un tel système sont légion, en particulier lorsque ce sont les utilisateurs qui constituent l'équipe des ventes. Un système CRM nommé Act! (vous êtes probablement familier avec) a déjà proposé une telle option de synchronisation, et peut-être le fait-il encore. Chaque fois que mon entreprise vend à une entreprise qui utilise le système de synchronisation d'Act!, Elle se plaint toujours de bases de données corrompues et mal synchronisées.

Si vous avez vraiment besoin de faire une telle chose, alors je vous recommanderais une réplication au niveau de la base de données (qui n'était pas disponible au moment où nous avons écrit notre application de synchronisation). De nombreuses bases de données offrent une réplication, y compris MS-SQL Server. Vous pouvez éliminer bon nombre des problèmes rencontrés en suivant les modifications au niveau de la base de données et en rendant la base de données responsable du transport de ces modifications vers une base de données distante.

Answer 2

Pourquoi réinventer la roue? Il existe de nombreuses applications CRM offrant cette fonctionnalité. Certains sont même open-source afin que vous puissiez les étendre. Mais si vous avez simplement besoin d'une base de données client avec des fonctionnalités hors connexion et une synchronisation, de nombreuses applications CRM vous l'offrent. Pour la base de données cliente, Highrise serait parfait, mais je pense qu’il n’existe aucune fonctionnalité hors connexion / synchronisation. Vous pouvez peut-être consulter SugarCRM , 24SevenOffice ou Salesforce ?

Et il est difficile de créer une application de synchronisation car il y a beaucoup de problèmes à résoudre lors de la fusion des données. Si vous avez toujours besoin de le faire, consultez SyncML , qui est un standard ouvert pour la synchronisation. . Certains outils prêts à installer sont disponibles à partir de Funambol .

Answer 3

Vous pouvez consulter le Microsoft Synch Framework . Je ne l'ai pas encore utilisé, je ne peux donc pas donner d'opinion personnelle à ce sujet.

Answer 4

MS CRM 4.0 dispose de fonctionnalités hors connexion lorsqu'il est associé à Outlook:

http://www.microsoft.com/dynamics/crm/product /overview.mspx

Se déconnecter a ses propres particularités (assurez-vous de le déconnecter avant de quitter votre connexion réseau efficace), mais dans l’ensemble, cela fonctionne bien ici. Le contenu du client mobile n'est toujours pas sorti, cependant.

Answer 5

Tout d’abord - si le CRM doit être un produit que vous vendez, construisez-le - si c’est pour un usage interne, je dirais qu’une autre supporte la peine de résoudre ces questions et n’achète qu’un CRM.

Hormis la réplication au niveau de la base de données, qui, selon moi, ne suffit pas pour tout résoudre, vous devez vraiment "lancer votre propre".

Je suis arrivé dans une équipe qui planifiait certains composants d’un système ressemblant à un système de gestion de la relation client. Au départ, ils avaient prévu d’utiliser la réplication de base de données car elle paraissait simple - jusqu’à ce que vous résolviez le conflit.

En fin de compte, nous avons décidé d'utiliser les GUID comme identificateurs uniques, car cela simplifiait considérablement la gestion des nouveaux enregistrements créés par les utilisateurs. Sinon, vous obtiendrez ces schémas de partitionnement d'ID numériques peu pratiques pour chaque système client. Road to Hell.

Rien n’aide à la résolution des conflits lorsque des modifications sont apportées entre les synchronisations, c’est un problème au niveau de l’application. La base de données peut obtenir une liste des transactions à relire de Bob, mais s’il édite les mêmes éléments que Alice - quelle version doit-elle utiliser? les horodatages ne suffisent pas, car si Alice remplit les siens au fur et à mesure et qu'elle a un horodatage précoce, mais Bob attend jusqu'à l'heure du déjeuner pour obtenir un horodatage ultérieur.

Je suggérerais vraiment de lire tous les articles / entrées de blog que vous pouvez sur la synchronisation et la résolution des conflits - la synchronisation est simple à une hauteur de 10000 pieds où vous pouvez être tout ondulé, mais c'est une histoire différente quand vous êtes en panne dans la boue.

Answer 6

Voici ma stratégie lorsque j’utilise ma propre solution de synchronisation dans le passé.

1. Limitation du nombre d'opérations de changement pouvant survenir lorsque le système est hors ligne.
2. Évitez d’utiliser le nombre entier à incrémentation automatique comme clé primaire, car cela entraînerait un problème grave. Dans le passé, j'avais attribué à chaque client déconnecté un identifiant unique et l'utilisais conjointement avec un numéro généré automatiquement pour former une clé primaire agréable et lisible (comme XXX-YYYYYYYY). Ceci est facile à faire car la création d’un numéro séquentiel est triviale dans un environnement non concurrent.
3. Conservez un journal des transactions, par exemple, chaque "opération DML effectuée en mode hors connexion peut être rejouée". au serveur. Vous pourrez optimiser ce journal ultérieurement lorsque vos besoins de synchronisation de base seront satisfaits.
4. Vous devez décider de la façon de préparer votre application client avant qu'elle ne soit déconnectée. Une solution typique consiste à obliger votre utilisateur à appuyer sur un bouton pour que l'application passe en "mode hors connexion". J'ai trouvé cette solution assez problématique, en particulier lorsque votre utilisateur est négligent et oublieux. Une simple gifle de la part de leurs gestionnaires suffit généralement au début, mais vous pouvez choisir de mettre en œuvre une solution plus intelligente plus tard.
5. Créez d'abord ma solution à partir de l'opération la plus simple, puis avancez dans un scénario plus complexe. (Opération d'enregistrement unique à table unique, opérations à enregistrements multiples à tables multiples, série d'opérations devant agir en tant que transaction)
6. Créez un scénario de résolution de conflit. Assurez-vous que le scénario est approuvé par vos utilisateurs.

Inutile de dire que c’est un voyage pénible. Si vous pouvez sous-traiter le problème à un tiers (par exemple, en achetant des solutions CRM disponibles), ce sera la meilleure solution.