Migration d'un système ERP à un autre

Très souvent, la transition de l’entreprise vers un nouveau système ERP n’arrête pas les coûts financiers de l’achat et de l’achèvement, mais la nécessité de migrer de l’ancien système. Ils ont des centaines voire des milliers d'utilisateurs qui exécutent leurs processus métier dans un programme, et d'une manière ou d'une autre, ils doivent être transférés tous vers un autre sans aucun arrêt pour l'entreprise.

Ces dernières années, nous avons suivi cette voie plusieurs dizaines de fois et nous avons déjà développé la manière la moins douloureuse de le faire.

Des difficultés

Le jour où Bison a honoré votre village de sa présence, est devenu pour vous la chose la plus importante de la vie. Mais pour moi, c'était mardi.
- Bayson, Street Fighter

Le processus de transition est souvent compliqué par le fait que de nombreux employés particulièrement impressionnables du client sont dans un état de panique pour la première fois, car pour eux, il s'agit très probablement de la première migration de leur carrière. Pour nous, il s'agit d'un événement ordinaire qui, en règle générale, se déroule selon le même scénario.

Lorsqu'une personne échange un produit contre un autre, la première chose qu'il remarque est qu'il lui a été enlevé et ne se rend pas encore compte de ce qu'il a reçu . Par conséquent, souvent la première réaction est: "quelle bêtise tu m'as glissé ici - fais comme ça." Dans la pratique, nous avons eu une situation où un utilisateur s'est plaint qu'il n'était pas à l'aise avec la nouvelle action, qui était effectuée dans l'ancien système en cinq transitions entre les formulaires. Mais il l'avait perfectionné à un tel automatisme que pour une personne, il était vraiment plus rapide de le faire que de faire deux actions nouvelles, mais beaucoup plus simples.

Une autre difficulté est que pendant la transition, les clients aiment changer les processus métier selon leur vision. Cela doit être traité avec beaucoup de soin, car les processus actuels «tels quels» sont garantis pour fonctionner. En règle générale, les processus intégrés au produit fonctionnent également, car ils sont utilisés par d'autres clients. Mais les nouvelles inventions peuvent en théorie être belles, mais dans la pratique, elles se heurteront à une bagatelle, à cause de laquelle tout le processus peut se bloquer.

Scénarios

En pratique, il existe deux scénarios principaux pour passer d'un système à un autre:

Momentané

La date de transition vers le nouveau système est déterminée. Toutes les fonctions sont développées pour décharger les données de l'ancien système et les charger dans un nouveau. Le jour X, la migration commence la nuit et le matin, tous les utilisateurs avec tous les processus métier commencent à travailler dans le nouveau système d'une nouvelle manière.

Tout est beau sur papier. Mais dans la pratique, il existe au moins quatre catégories de problèmes:

1. La formation . Au moment de la transition, en règle générale, de nombreux utilisateurs formés oublient complètement ce qui leur a été enseigné. Ils commencent à tout piquer et, par conséquent, ils arrêtent leur travail avec les mots «rien ne fonctionne». Ce problème peut être résolu avec l'aide du personnel de soutien de première ligne qui peut vous aider en ce moment. Mais il y aura tellement de demandes de ce type le premier jour du transfert qu'il sera impossible de les satisfaire avec le nombre d'employés disponibles. Ou vous devez avoir un moyen d'augmenter rapidement leur nombre pendant le transfert, ce qui est également assez difficile à faire.
2. Améliorations et erreurs . En règle générale, un nouveau système ERP apporte avec lui de nouveaux processus métier (sinon pourquoi le changer). Il est clair que juste avant la mise en œuvre, ils ont été chassés d'une manière ou d'une autre, mais au moment d'un véritable «test de bataille», une quantité énorme de nuances apparaît généralement, à cause de laquelle souvent les processus ne peuvent pas être exécutés. En conséquence, encore une fois, le nombre de ces améliorations avec priorité immédiate augmente comme une boule de neige, et il y a un besoin criant de ressources de programmeur qui physiquement ne pourront pas fermer un tel nombre de demandes.
3. Données . Habituellement, les développeurs de l'ancien système ne sont pas très désireux d'aider à télécharger des données (pour eux, c'est généralement un triste événement de perdre un client), et s'ils aident, la qualité du téléchargement laisse beaucoup à désirer. Et des incohérences, en règle générale, se trouvent dans les premiers jours de fonctionnement d'un nouveau système. En conséquence, il est nécessaire de corriger le déchargement, et en quelque sorte recharger les données, en tenant compte des changements déjà effectués pendant le fonctionnement.
4. Performance . Pendant le processus de test, il n'est pas si facile de reproduire la charge complètement «réelle» sur le système. Si la fonctionnalité de base du produit est généralement déjà testée et affiche des paramètres de performances normaux, des améliorations «personnelles» du client peuvent, dans certaines circonstances, «asseoir» le serveur. Ceci, à son tour, nécessite également des ressources de programmation pour l'optimisation.

Lorsque ces quatre problèmes surviennent le premier jour ou la première semaine de la transition en même temps, les pertes commerciales ne peuvent être évitées. Par conséquent, un tel schéma ne fonctionne efficacement que sur de petits projets. Par exemple, lorsque le nombre d'utilisateurs est inférieur à cent et que les processus ne sont pas critiques.

Il est clair que vous pouvez consacrer plus de ressources à la formation et au test du système immédiatement avant la transition, et il y aura alors moins de problèmes. Mais dans la vie, les employés du client se réfèrent généralement à ces processus «sans manches» et comptent sur «peut-être». Ou ils se trompent tout simplement, s'attendant à ce qu'un certain processus soit en mesure de gagner de l'argent dans un certain cadre, mais en fait, il semblerait que des nuances mineures réduisent tout.

Progressive

Avec cette approche, le système est divisé horizontalement (par processus) ou verticalement (par utilisateurs) en parties, qui sont introduites tour à tour. Cela vous permet de répartir tous les problèmes ci-dessus dans le temps et de les résoudre car ils reçoivent moins d'énergie.

De plus, je décrirai le processus de migration d'un système ERP basé sur la plate-forme lsFusion ouverte et gratuite pour une chaîne de magasins de détail, car nous sommes spécialisés dans cette industrie. Mais nous avons appliqué le même principe aux clients d'autres domaines.

Lecture des données

En règle générale, pour les entreprises qui prennent en charge l'ancien système, la nouvelle du remplacement de leur programme et de la perte d'un client est un coup dur. Certains tombent dans un état inadéquat et commencent à menacer le client d'un arrêt immédiat du soutien. Naturellement, cela ne fonctionne jamais et ne peut jamais renverser la décision. Cependant, il est rarement possible de convenir avec ceux qui prennent en charge l'ancien système qu'ils fournissent des tableaux où toutes les données nécessaires à la transition sont stockées.

Tout d'abord, vous devez déterminer dans quel SGBD les informations nécessaires sont stockées et comment y accéder. Au cours des dernières années, nous avons dû faire face aux SGBD suivants avec lesquels les anciens systèmes fonctionnaient:

• Accès La plateforme étant écrite en Java, il a été possible de creuser une ancienne bibliothèque qui savait se connecter à mdb (mais uniquement pour la lecture). Cela a fonctionné de façon très particulière, car malgré les filtres, il a lu tout le tableau, mais néanmoins c'était suffisant. Nous avons eu la chance que le service informatique du client connaissait très bien la structure de la base de données et nous ait dit quoi et où est stocké.
• MS SQL L'ancien système était l'Axapta 2000. Nous avons été mis en place l'accès au système de test, où nous avons lancé l'interface graphique et SQL Profiler. Ensuite, nous nous sommes relayés dans les répertoires et avons examiné les demandes générées par Axapta. Il était facile de comprendre d'eux où exactement telle ou telle information est stockée.
• Visual Foxpro Tout était simple, car il y avait une transition de nos anciens systèmes et il n'était pas difficile d'obtenir des informations. La seule difficulté a été de trouver une bibliothèque Java pouvant fonctionner non pas avec des tables DBASE, mais avec le format Visual Foxpro.
• Oracle Transition du programme en boîte supermag. Nous avons travaillé selon un schéma similaire au schéma Axapta: GUI et requêtes dans SQL Developer pour les requêtes les plus récentes. La structure de base et les interfaces étaient certainement beaucoup plus simples que dans Axapta, donc il n'y avait pas de gros problèmes.
• Progress / OpenEdge . Transition du programme Gestori en boîte. Étant donné que le SGBD, pour le moins, n'est pas du tout populaire, nous n'avons trouvé aucun profileur. Cependant, il y avait un vidage dans les fichiers texte. Cela a permis d'accéder simplement à l'interface graphique du serveur de test et de rechercher dans les fichiers texte pour rechercher des données visibles à l'écran. Heureusement, sur le site officiel de ce SGBD, il est possible de télécharger le pilote JDBC et d'effectuer des requêtes dans la base de données SQL. C'était alors une question de technologie.

Grâce à de telles approches, je n'ai jamais eu à me tourner vers les développeurs de l'ancien système, ce qui a considérablement réduit les dépenses des clients, car généralement, ils ont simplement déployé d'énormes sommes d'argent pour la coopération.

Données de base

Tout commence par l'importation de données de base. En particulier, pour le commerce de détail, les importations d'annuaires de groupes de marchandises, de marchandises, d'entrepreneurs et de magasins sont les premières à être réalisées. Avec une transition progressive, il existe deux approches pour importer des données de base:

• Importation de données unique, puis double entrée dans l'ancien et le nouveau système.
• Mise à jour incrémentielle continue des données de l'ancien vers le nouveau système.

Il y a des cas où la première approche est utilisée, mais elle prend trop de temps et est très sensible au facteur humain avec la probabilité d'erreurs. Par conséquent, nous n'utilisons toujours que la deuxième option.

Idéalement, l'ancien système pourrait accumuler des changements et communiquer d'une manière ou d'une autre qu'il doit être réimporté. Mais généralement, personne ne changera ou modifiera quoi que ce soit dans l'ancien système. Par conséquent, le seul schéma de travail que nous utilisons est le suivant:

1. Il y a une demande au répertoire de l'ancien système, qui en lit toutes les données.
2. Les données lues sont comparées au courant dans le nouveau système et des changements sont détectés.
3. Les modifications sont écrites en une seule transaction sur le nouveau système.

Le code sur la plate-forme pour importer le répertoire du produit ressemblera à ceci:

Cela fonctionnera comme suit:

• LIRE considère l'ensemble du répertoire avec le code et le nom en mémoire
• IMPORT écrira toutes les données dans les propriétés locales (à savoir, les tables temporaires dans la base de données)
• Le premier cycle créera toutes les marchandises qui ne sont pas encore dans la nouvelle base de données (recherche par code produit). Malgré le fait que FOR y soit écrit, il se compile en une seule requête dans la base de données, qui ne fonctionnera qu'avec des tables temporaires.
• Le deuxième cycle mettra à jour les champs pour tous les produits (y compris ceux nouvellement créés). Dans ce cas, seules les valeurs modifiées seront écrites dans des tables temporaires.
• La troisième action SUPPRIMER détecte toutes les marchandises qui se trouvent dans la nouvelle base de données, mais pas dans les données lues et les supprimera.
• APPLY démarre la transaction et écrit toutes les modifications dans la base de données en fonction des tables temporaires générées par les commandes précédentes.

En fait, cette action au moment du lancement synchronise complètement l'ancien et le nouveau répertoire. Il ne stocke aucune information incrémentielle, il peut donc être redémarré à tout moment, même si l'échange précédent s'est terminé avec des erreurs.

Étant donné que toutes les actions sont compilées dans des requêtes SQL sans aucune itération, tout cela se fait assez rapidement et en toute sécurité. En règle générale, l'échange d'un répertoire de marchandises de 100 à 200 000 enregistrements prenait quelques minutes. Dans le même temps, étant donné que PostgreSQL est versionné, aucun blocage du travail utilisateur ne se produit pour le moment.
De la même manière, les prix des fournisseurs, les matrices d'assortiment, les calendriers de commande et les autres informations nécessaires au travail sont constamment synchronisés. Ici, cependant, un problème peut survenir que la logique de domaine dans l'ancien système ne coïncide pas avec la nouvelle logique de domaine. Par exemple, dans notre système, nous avons un historique des versions matricielles et le concept des niveaux de produit à l'intérieur d'une matrice. Si dans l'ancien système, l'assortiment actuel de magasins est stocké à plat en tant que booléen pour le magasin et les marchandises, une matrice est créée pour chaque magasin avec exactement un niveau.

Le plus souvent, nous permettons à l'action de synchroniser tous les répertoires avec l'ancien système une fois par heure, tout en offrant à l'utilisateur la possibilité de démarrer l'échange manuellement.

Le processus

Dans le commerce de détail, nous divisons généralement le processus de traduction verticalement entre les magasins et simultanément horizontalement des processus de magasin aux processus de bureau.

La première étape consiste à choisir un magasin où le transfert vers le nouveau système commencera. Importe les soldes courants et les prix des magasins de l'ancien système sous forme de documents entrants avec les quantités et les prix correspondants:


Quelques semaines avant le démarrage du magasin, l'importation de l'implémentation à partir des systèmes POS est connectée. Cela est nécessaire pour qu'il y ait des données historiques pour la formation des commandes dans les premiers jours de travail.

Très souvent, le processus de production propre est transféré un peu plus tard que les processus principaux. Dans ce cas, le déchargement dans l'ancien système de documents sur le mouvement des matières premières et l'importation de produits finis à partir de là est mis en œuvre.

Le jour du transfert, l'importation commence la nuit, puis le personnel du service client et notre première ligne d'assistance sont envoyés au magasin. Ils aident les utilisateurs à démarrer dans le nouveau système sans même avoir à suivre une formation préalable. Dans ce cas, généralement pendant un certain temps, la modification de documents dans l'ancien système ne se ferme pas, car les gens se trompent et doivent pouvoir corriger les erreurs. Après quelques semaines, les restes sont réimportés, puis une interdiction de modifications de l'ancien système est déjà en place.

Après que tous les problèmes décrits ci-dessus ont été identifiés et résolus dans le premier magasin, après environ deux semaines, 2-3 autres magasins sont transférés. Encore une fois une itération d'identification et de résolution des problèmes. Et puis tous les autres sont traduits très rapidement, en fonction des ressources du service client du client. Pendant tout ce temps, les données de base continuent d'être entrées dans l'ancien système afin que les magasins puissent fonctionner sur l'ancien système.

Ensuite, lorsque tous les magasins sont transférés, progressivement ou tous désactivent immédiatement les importations de l'ancien système, et les utilisateurs commencent à saisir les données de base dans le nouveau système.

Les informations récapitulatives des anciens et nouveaux systèmes sont obtenues soit en comptabilité soit dans le système BI, où les deux systèmes sont téléchargés en même temps. Là, vous pouvez obtenir des rapports récapitulatifs pour l'intervalle, qui inclut le temps dans les anciens et les nouveaux systèmes.

Conclusion

Malgré la complexité apparente de la transition d'un système à un autre, après avoir parcouru ce chemin plusieurs dizaines de fois, vous comprenez qu'avec un schéma débogué, tout n'est en fait pas si effrayant. Plus de problèmes surviennent avec le fait que la plupart des employés du client sont assez conservateurs et, à la moindre occasion, exigent de faire «comme ça». Et ici, il est très important que le client dispose d'une personne suffisamment compétente pour comparer les anciens et les nouveaux processus, déterminer ceux qui sont les plus optimaux et être capable de «casser» les employés. Ou modifiez le processus selon le schéma «tel quel», s'il s'avère l'inverse.