Systèmes internes obsolètes : faut-il les réparer ou en construire de nouveaux ?

La situation à laquelle les entreprises sont confrontées aujourd'hui.

Les entreprises qui ont un système interne utilisé depuis plus de 10 ans se trouvent généralement dans la même situation. Le système fonctionne toujours. Il n'y a pas de grandes pannes. Cependant, une petite demande peut prendre deux semaines à traiter, et il n'y a qu'une seule personne dans l'entreprise capable de s'en occuper.

La raison pour laquelle cet état est dangereux est que les problèmes s'aggravent progressivement. Un système qui s'arrête soudainement reçoit immédiatement un budget alloué. Cependant, un système qui ralentit lentement et nécessite de plus en plus d'attention passe chaque année à "Cette année, ça a tenu bon". Au fil des années, trois problèmes se présentent simultanément.

Premièrement, un responsable qui connaît le système part. Les règles de travail non documentées disparaissent avec lui. Deuxièmement, le support de sécurité pour la technologie de base prend fin. Les langages ou versions de bases de données sans support ne recevront pas de correctifs même si des vulnérabilités sont découvertes. Troisièmement, il devient impossible d'ajouter de nouvelles exigences. Des demandes telles que la compatibilité mobile, l'intégration de services externes et l'analyse de données sont constamment rejetées avec "Cela n'est pas possible avec le système actuel".

Lorsque les trois problèmes surviennent en même temps, il ne reste plus que l'option d'une reconstruction complète. Et la reconstruction complète est l'option la plus coûteuse et la plus risquée.

Cinq signaux indiquant qu'un remplacement doit être envisagé

Si vous correspondez à trois des éléments suivants, il est temps de commencer à envisager un remplacement.

1. Les coûts de changement sont asymétriques. Ajouter un élément à l'écran peut prendre plusieurs jours. Si le temps de développement pour des demandes jugées mineures par l'utilisateur et pour des demandes majeures ne diffère pas beaucoup, cela signifie que la structure ne peut déjà plus supporter de changements.

Il n'y a qu'un seul personnel de maintenance. Un système qui ne peut être modifié que par une personne spécifique représente un risque commercial dès que cette personne prend des congés ou quitte l'entreprise. Ce n'est pas un problème de ressources humaines, mais un problème structurel.

3. Le support des technologies de base a pris fin. Vérifiez la date de fin de support officiel des langages, runtimes, frameworks et bases de données que vous utilisez. Si cela est déjà dépassé, un incident de sécurité n'est qu'une question de temps.

4. Impossible d'extraire les données. Si le responsable doit rédiger des requêtes pour obtenir des chiffres nécessaires à la prise de décision ou doit ouvrir plusieurs écrans pour faire des sommes manuellement, cela signifie que le système retient les données.

5. Les tâches de contournement augmentent. Si les opérations gèrent de plus en plus de domaines avec Excel au lieu du système, cela signifie que le système ne reflète pas réellement le travail. Ces tâches de contournement ne sont enregistrées nulle part, donc les problèmes ne sont pas visibles en regardant uniquement le système.

Calculez les coûts de maintenance

La raison pour laquelle les discussions sur le remplacement n'avancent pas est souvent "Pourquoi dépenser de l'argent alors que ça fonctionne encore ?" Pour répondre à cette question, il faut démontrer par des chiffres que des coûts de maintenance sont également engagés. Additionnez les quatre éléments suivants.

Les trois premiers éléments représentent des coûts déjà engagés mais qui ne sont attribués à aucun compte. Le quatrième élément concerne des coûts qui ne se sont pas encore produits mais qui s'accumulent de manière probabiliste.

L'exemple ci-dessous est une illustration fictive pour montrer la méthode de calcul, et les valeurs réelles varient selon les conditions de chaque entreprise. Si le nombre de demandes de changement par an est de 30, avec un délai moyen de 10 jours par demande, et un coût d'opportunité quotidien dû au retard fixé à 150 000 won, le coût de retard s'élève à 45 millions de won par an. Si deux départements consacrent chacun 5 heures par semaine à la double gestion sur Excel, cela ajoute 13 millions de won par an, basé sur un coût de main-d'œuvre total de 25 000 won de l'heure.

Si le total est de 58 millions de wons par an, cela représente 170 millions de wons sur 3 ans. C'est à ce moment-là que des chiffres commencent à apparaître, pouvant être comparés aux coûts de remplacement. Le maintien n'est pas gratuit, c'est une dépense sans facture.

Les raisons pour lesquelles une reconstruction complète est risquée

La première méthode qui vient à l'esprit après avoir décidé de remplacer est la reconstruction complète. Arrêter l'ancien, créer du nouveau et tout changer d'un coup. C'est intuitif mais comporte trois risques.

Les bénéfices sont de 0 jusqu'à la fin du projet. Pour une reconstruction de 12 mois, pendant 11 mois, l'organisation ne paie que des coûts sans ressentir aucune amélioration. Si l'environnement de gestion change pendant cette période, le projet subira des pressions pour être interrompu.

Les exigences deviennent obsolètes en cours de route. Les exigences définies au début ne correspondent plus à celles du terrain un an plus tard. Si vous les intégrez, le calendrier sera retardé, et si vous ne le faites pas, un système obsolète sera créé.

Le risque se concentre au moment de la transition. Comme toutes les fonctionnalités sont modifiées en même temps, s'il y a un problème le jour de la transition, il n'y a pas de moyen évident de revenir en arrière. Et les problèmes surviennent presque toujours, car il reste toujours des règles d'exception que personne ne se souvient dans le système existant.

Une alternative à la migration progressive

Au lieu d'un remplacement complet, il existe une méthode qui consiste à transférer par fonction tout en laissant le système existant en place. L'ordre est le suivant.

Étape 1 — Définir les limites

Divisez le système actuel en morceaux fonctionnels. Séparez les unités de travail comme les commandes, les stocks, la comptabilité et les ressources humaines, mais tracez la ligne en fonction de qui possède les données. Si plusieurs morceaux modifient directement la même table, ce point deviendra plus tard le plus grand obstacle.

Lorsque vous tracez des frontières, suivez le flux de données plutôt que l'organigramme. Même si les départements sont séparés, s'ils modifient ensemble les mêmes données, ils forment un tout, et si les données sont complètement séparées au sein d'un même département, elles peuvent être divisées.

Étape 2 — Séparation de la lecture

La première tâche la plus sûre est la fonction de recherche. Les fonctionnalités qui ne font que lire des données, comme les tableaux de bord, les statistiques et les rapports, peuvent être créées dans le nouveau système sans affecter l'ancien. Même en cas d'échec, l'interface existante reste intacte, ce qui facilite le retour en arrière, et les utilisateurs ressentent immédiatement l'amélioration.

Il y a un autre effet secondaire que vous obtenez à ce stade. En créant une fonction de recherche, les problèmes des données existantes se révèlent. Des clients en double, des dates mal formatées, des lignes avec des valeurs de code vides sont découverts ici. Il est important de connaître ces problèmes avant de transférer la fonction d'écriture.

Étape 3 — Migration de la fonctionnalité d'écriture

Une fois la validation par consultation terminée, nous transférons les fonctionnalités d'entrée et de modification. À ce moment-là, les deux systèmes traiteront les mêmes données pendant un certain temps, donc définissez-en un comme original. Si les deux peuvent être modifiés simultanément, des incohérences se produiront, et il faudra plus de temps pour les identifier que pour la migration elle-même.

Il est plus sûr de commencer par transférer les fonctionnalités qui sont peu utilisées et ont un impact limité. Cependant, si vous commencez par des fonctionnalités que personne n'utilise, cela ne sera pas validé, donc les fonctionnalités qui sont réellement utilisées mais peuvent être arrêtées pendant une journée constituent le meilleur point de départ.

Étape 4 — Réduction du système existant

Les fonctionnalités transférées doivent être supprimées du système existant. Si elles restent, certaines opérations continueront à utiliser l'ancienne interface, ce qui entraînera finalement le maintien permanent de deux systèmes. Reporter cette étape est la raison la plus courante de l'échec d'une migration progressive.

S'il est difficile de supprimer, au moins bloquez l'accès et passez en mode lecture seule. Et fixez une date pour savoir quand cela sera complètement retiré. Un plan de nettoyage sans date ne sera pas exécuté.

Quelle option allez-vous choisir ?

Une reconstruction complète n'est pas toujours une mauvaise idée. Si la portée est limitée, que les règles de travail sont documentées et qu'une interruption de quelques heures est acceptable, il est souvent plus rapide et moins coûteux de tout changer d'un coup. Le critère de jugement n'est pas l'âge du système, mais plutôt où les règles sont enregistrées.

Les véritables problèmes lors de la migration des données

Les raisons des retards dans le calendrier sont généralement liées aux données plutôt qu'au développement des fonctionnalités. Les anciens systèmes accumulent des états comme ceux-ci.

• Le même client est enregistré plusieurs fois avec des désignations différentes
• Les formats de date, de numéro de téléphone et de numéro d'entreprise varient selon les périodes.
• Il y a des lignes vides dans les éléments obligatoires
• Des données référencent des codes qui n'existent plus.
• Des lignes marquées comme supprimées mais qui sont en réalité encore présentes

Ces problèmes, s'ils sont découverts à l'étape précédente, retarderont inévitablement le calendrier. Faites des recherches à l'avance avant le démarrage et définissez d'abord la portée à organiser et celle à abandonner. Essayer de nettoyer toutes les données passées peut rendre la phase précédente interminable. Dans de nombreux cas, il est plus réaliste de ne nettoyer que les données des dernières années et de conserver le reste en mode consultation.

Une opportunité de repenser la sécurité et les droits d'accès

Le remplacement est également une rare occasion de réorganiser le système de sécurité. Les anciens systèmes ont généralement une séparation des droits laxiste, et la plupart des responsables ont accès à plus de données que nécessaire. Pendant le processus de transition, assurez-vous de définir les éléments suivants.

Minimiser les droits d'accès. Séparez les données nécessaires par rôle afin qu'elles ne soient visibles que pour ceux qui en ont besoin. Si vous transférez simplement la structure des droits de l'ancien système, vous emporterez également les anciens problèmes.

Emplacement de stockage des données personnelles et durée de conservation. Organisez quelles données personnelles sont stockées où et quand elles seront détruites. Si vous migrez vers le cloud, vous devez également vérifier le pays où les données sont stockées.

Conservation de l'historique des traitements. Indiquez qui a changé quoi et quand. Dans les anciens systèmes, il n'y a souvent pas de trace de ces enregistrements, ce qui rend difficile le suivi des causes en cas de problème.

Comment persuader la direction

Le budget de remplacement ne passe généralement pas par une logique technique. Des explications telles que "la structure est obsolète" ou "le support technique est terminé" ne sont pas perçues comme urgentes par les décideurs. Présentez-le sous forme de ces trois éléments.

Montant actuellement en cours de calcul. C'est le total des coûts de retard, de contournement et d'erreur calculés précédemment. L'essentiel est que ces coûts sont déjà engagés même sans remplacement.

Ce que vous ne pouvez pas faire. Dressez une liste des demandes rejetées au cours de l'année écoulée pour "impossible avec le système actuel". Si certaines de ces demandes sont liées à des pertes de revenus ou à des abandons de clients, placez-les en premier. La perte d'opportunités est un argument plus fort que les coûts de maintenance.

Dans le pire des cas. Estimez le temps et le coût nécessaires pour la récupération si le seul responsable part ou si un incident se produit sur un composant dont le support est terminé. Même si la probabilité est faible, si l'ampleur est grande, cela influence la prise de décision.

Après avoir présenté les trois éléments, demandez l'approbation uniquement pour la première étape de la migration progressive. Si vous demandez l'ensemble du budget d'un coup, la période d'examen sera prolongée et la situation pourrait empirer entre-temps.

Comment planifier les ressources et le calendrier

Le calendrier est souvent un point de friction lors de la migration progressive. Anticipez trois éléments à l'avance.

Intégrez le temps des opérations dans le calendrier. La ressource la plus manquante dans les projets précédents n'est pas le développeur, mais le responsable opérationnel qui connaît les règles de travail. Étant donné qu'ils participent tout en continuant leur travail principal, si le temps disponible n'est pas convenu à l'avance, le calendrier sera retardé à chaque étape de validation.

Incluez la période de fonctionnement parallèle dans vos calculs. Après avoir transféré les fonctionnalités, il faut encore faire fonctionner les deux systèmes ensemble pendant un certain temps. Pendant cette période, la charge opérationnelle augmente en fait. Si cela n'est pas pris en compte dans le calendrier et le budget, il y aura un manque de personnel à la dernière étape.

Veuillez prévoir une période distincte pour l'organisation des données. Les problèmes de cohérence abordés plus tard peuvent être traités en parallèle avec le développement, mais nécessitent du temps et une personne dédiée.

À vérifier lors de la collaboration avec des entreprises externes

Il est souvent difficile d'effectuer la transition uniquement avec des ressources internes. Si vous envisagez de faire appel à des entreprises externes, assurez-vous de vérifier les éléments suivants avant de signer un contrat.

Les documents sont-ils inclus dans les livrables ? Si vous ne recevez que le code, le même problème se reproduira des années plus tard. Un document de définition des règles de travail, une description de la structure des données et un manuel des procédures opérationnelles doivent être inclus dans les livrables.

Le mode de transfert a-t-il été défini depuis la dernière fois ? Une fois la construction terminée, le personnel interne doit être capable de l'exploiter. Veuillez spécifier la durée de la période de transfert et l'étendue de la formation dans le contrat.

Est-il possible de contracter par étapes ? Si vous contractez l'ensemble d'un coup, il sera difficile de changer de direction en cours de route. Avoir une structure où vous réalisez la première étape et décidez ensuite pour la suite est plus sûr pour les deux parties.

Les droits d'accès à nos données sont-ils clairs ? Si des données réelles sont utilisées durant le processus de développement, documentez comment les données se déplacent, où elles vont et comment elles sont détruites après la fin.

Préparations à faire avant le démarrage

Quel que soit le mode, assurez-vous d'obtenir les trois éléments suivants avant de commencer.

Documentation des règles de travail actuelles. Les règles qui ne figurent que dans le code seront nécessairement omises lors du processus de migration. Même si ce n'est pas une spécification parfaite, assurez-vous de consigner par écrit les conditions d'exception et d'approbation.

Vérification de la cohérence des données. En vous basant sur les éléments précédemment organisés, examinez l'état actuel et définissez la portée de l'organisation.

Prévoir un plan de retour. À chaque étape, définissez "que faire si un problème survient pour revenir en arrière". Les étapes irréversibles sont déjà trop importantes en soi, ce qui indique qu'elles doivent être divisées en étapes plus petites.

Organisation

Le coût des anciens systèmes se manifeste non pas par des pannes, mais sous la forme de retards et de dépendances. C'est pourquoi ils sont souvent reconnus trop tard.

• Vérifiez cinq éléments : coûts de changement, concentration des ressources humaines, fin du support technique, accessibilité des données, et contournement des tâches.
• Calculez le coût de maintenance en tenant compte de quatre éléments : retard, contournement, erreur et risque, et transformez-le en un chiffre comparable au coût de remplacement.
• Si les règles ne restent que dans le code, une reconstruction complète est risquée.
• Commencez par transférer la fonction de consultation, et assurez-vous de les fonctionnalités transférées du système existant.
• La cohérence des données doit être examinée avant le démarrage, et définissez à l'avance la portée de l'organisation.
• Profitez de cette occasion pour redéfinir les politiques d'accès et de conservation des données personnelles.

Ce qui est plus important que de décider de remplacer ou non, c'est de ne pas retarder le jugement. Si vous correspondez à trois des cinq signaux, il est préférable de commencer l'examen cette année plutôt que de procéder à une reconstruction complète l'année prochaine, car cela sera moins coûteux.