Estimation de charge et de délai pour un petit projet de migration

[tonyntech]

Je débute sur les migrations de données. J'ai besoin d'une aide.

On me demande une estimation avant même d'avoir tous les éléments. Et pas possible d'attendre. Elle concerne la migration de ventes depuis SAGE vers notre CRM maison.

En gros, il y deux tables à alimenter avec un total de 63 champs.

Est-ce qu'il est possible sur la base de cette information de donner une estimation de la charge de travail et de délai ? Quelle est la méthode ?

[StringBuilder]

Bonjour,

Même si vous n'avez pas beaucoup d'informations sous la main, vous devriez en avoir un peu plus à nous donner :

- Qui va s'occuper de cette migration ?
=> Un DBA ou développeur habitué à ce genre de manipulations ira 1000 fois plus vite qu'un stagiaire en sanitaire et social...

- Quel est le résultat attendu ?
=> Si vous devez simplement créer 2 tables dans la base du CRM et recopier les données d'un serveur à l'autre, ça peut se faire en quelques minutes (peut-être même quelques secondes). Mais si vous devez trouver un paramétrage dans votre CRM pour stocker les ventes dans les tables déjà existantes, ça peut tout de suite prendre... 6 mois comme 2 heures, tout dépend des capacités de votre CRM et du niveau de connaissance de celui qui va faire la manipulation.

- Afin de consulter les données ainsi récupérées, avez-vous besoin de faire des développements complémentaires (interface de saisie, affichage de graphiques, états, etc.)
=> En effet, chaque développement prend du temps, même les plus basiques.

Voici 3 chiffrages "à pifomètre", selon les hypothèses de réponse aux questions :
- Nouvelles tables dans la CRM, pas de développement d'interface : au grand maximum 1 jour (en comptant que Sage et votre CRM utilisent des SGBD différents, non standard, et que vous devez mettre en place une moulinette maison)

- Intégration au modèle des données existant du CRM, paramétrage et pas de développement (en partant du principe que vous connaissez votre affaire) : entre 1 et 5 jours, tests compris (tout dépend des difficultés rencontrées lors de l'intégration des données au modèle existant)

- Bouillie bordelaise dans les tables du CRM, avec nouveaux développements pour rendre le machin paramétrage, et nouveaux écrans de consultation : entre 5 et 20 jours selon le bordel déjà ambiant.


Questions subsidiaires à vous poser pour faire les bons choix :
- Pourquoi intégrer les données de Sage dans le CRM ? Avez-vous pensé aux évolutions des données (et donc leur réplication) Pourquoi ne pas utiliser un état de Sage ?
- Pourquoi ne pas changer tout simplement de solution, et avoir un unique outils unifié (Sage propose notamment un CRM si je ne m'abuse !)
- Pourquoi un tel niveau d'urgence ? (généralement, un choix qu'on ne prend pas la peine de réfléchir et étudier, est un mauvais choix)

[tonyntech]

StringBuilder,

Merci pour ta réponse. Je suis de ton avis sur l'utilité de se précipiter : aucune.

Il est dommage de constater que de nombreuses entreprises (client ou fournisseur) sont atteintes par ce mal. De plus, les charges de ce projet ont étés amplement sous-évaluées : la précipitation a mené à de nombreux oublis (du client et du consultant métier). J'espère que ce cas de figure servira à faire comprendre aux entreprises oncernées, à leurs managers et leur dirigeants la nécessité de prendre le temps d'une bonne réflexion en début de projet.

Plus d'info sur le projet.

La personne qui réalise cette migration a ce profil :
- maîtrise MySQL pour des besoins en développement ;
- Niveau moyen sur SQL Server ;
- Un débutant en migration d'annuaires ;


Pour être plus précis le projet c'est de la "Bouillie bordelaise" :
- Exporter toutes les données DEVIS et VENTE
- Les intégrer dans deux nouvelles tables avec transcodage par-ci par-là ;
- Matcher ces données (date de livraison) avec les date de livraison de l'agenda du CRM afin de regrouper ces livraisons sous une même vente (ou devis), toujours dans le CRM ;
- A l'aide de la précédente opération, récupérer les IDs des sociétés depuis SAGE afin de les matcher avec les IDs société du CRM.

Si j'ai bien compris le délai se situe entre 2 et 4 semaines incluant les simulations de bascule. Avec un risque d'erreur puisque la pré-étude n'a pas encore été faite.

J'aimerais pouvoir répondre quant au choix des applications... Aucune idée... J'étais arrivé sur le projet bien après que ces choix ont été faits. Comme le choix a déjà été fait, je préfère y réfléchir par la suite car ça risque de faire

[StringBuilder]

Si je comprends bien, au final, le besoin est de pouvoir retrouver dans le CRM les informations sur les mouvements commerciaux du client qu'on a au bout du fil, c'est bien ça ?

Donc n'oubliez pas la mise à jour des données (ça peut vite devenir bordelique si on n'écrase pas tout à chaque fois... mais si on écrase tout à chaque fois, ça peut vite devenir très lent !)

Questions subsidiaires :
- Je ne connais pas bien MySQL : Supporte-t-il les "dblink" ?
- En revanche, je connais un peu PHP : pourquoi ne pas greffer dans l'application CRM une lecture directe des tables de Sage qui sont sous SQL Server ?

Ces questions sont motivées par les avantages suivants (mais aussi inconvénients).
Avantage 1 : Vous avez des données à jour en permanence
Avantage 2 : Aucune procédure de nuit qui recopie les données d'une base à l'autre (ça laisse plus de temps pour les sauvegardes, et ça réduit la charge de développement)
Avantage 3 : Les données n'étant pas répliquées, un unique référentiel est utilisé pour chaque donnée. Ça évite les confusions lorsqu'on parle d'une données mais d'un référentiel différent (données à jour, pas d'états contradictoires, etc.)
Inconvénient 1 : La base de Sage est exposé à l'application CRM. Pour des raisons de sécurité, ça peut être gênant, Sage gérant habituellement des données très sensibles, telles que les fiches de paie ou la compta.
Inconvénient 2 : Le fait que le CRM aille directement relire les informations dans la base de Sage va provoquer une surcharge qui peut être importante du serveur Sage : les deux applications risque de se retrouver ralenties, et l'investissement dans un nouveau serveur de base de données peut être à envisager (après surveillance de la charge).
Inconvénient 3 : La matching des données ente Sage et le CRM devra se faire "à la volée". Si les traitements restent simples, ça gêne pas. S'il faut en revanche faire des calculs complexes sur de grands volumes de données, ça peut vite devenir problématique. Ceci dit, pour ça, SQL Server dispose d'outils permettant d'améliorer les choses (vues stockées par exemple).