Systèmes internes obsolètes : les réparer ou les reconstruire ?

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

Les entreprises qui utilisent le même système interne depuis plus de dix ans se retrouvent presque toujours dans la même situation. Le système fonctionne toujours. Il n'y a pas non plus d'incidents graves. Simplement, une demande mineure prend deux semaines et il n'y a qu'une seule personne dans toute l'entreprise capable de s'en occuper.

Cet état est dangereux car le problème s'aggrave progressivement. Un système qui s'arrête brusquement reçoit immédiatement un budget. En revanche, un système qui devient un peu plus lent et un peu plus coûteux à maintenir chaque année est traité avec un « cette année encore, nous avons réussi à nous en sortir ». Lorsque plusieurs années s'accumulent ainsi, trois circonstances se présentent simultanément.

Première : la personne qui connaît le système prend sa retraite ou quitte l'entreprise, emportant avec elle les règles de gestion qui n'ont jamais été documentées. Deuxième : le support de sécurité de la technologie de base prend fin ; les versions de langage ou de base de données non supportées ne reçoivent pas de correctifs même si des vulnérabilités sont découvertes. Troisième : il devient impossible d'incorporer de nouvelles exigences ; des demandes telles que l'accès mobile, l'intégration avec des services externes ou l'analyse de données sont rejetées encore et encore avec un « avec le système actuel, cela n'est pas possible ».

Au moment où les trois circonstances coïncident, la seule option qui reste est la reconstruction complète. Et la reconstruction complète est l'option la plus coûteuse et la plus risquée.

Cinq signes qu'il est temps d'envisager un remplacement

Si trois ou plusieurs des points suivants se vérifient, il est temps de commencer l'étude de remplacement.

1. Le coût du changement est asymétrique. Ajouter un seul champ à un écran prend plusieurs jours. Si le délai de développement d'une demande que l'utilisateur perçoit comme triviale ne diffère guère de celui d'une demande importante, la structure n'est plus capable d'assumer les changements.

2. Il n'y a qu'une seule personne pour la maintenance. Un système que seule une personne spécifique peut toucher rend ses vacances et son éventuel départ risqués pour l'entreprise. Ce n'est pas un problème de ressources humaines, mais un problème structurel.

3. Le support de la technologie de base a pris fin. Vérifiez les dates officielles de fin de support de l'environnement d'exécution du langage, du framework et de la base de données que vous utilisez. Si elles sont déjà dépassées, l'incident de sécurité n'est qu'une question de temps.

4. Les données ne peuvent pas être extraites. Si, pour obtenir les chiffres nécessaires à la prise de décision, quelqu'un doit écrire des requêtes à la main ou ouvrir plusieurs écrans et additionner manuellement, le système retient les données.

5. Les processus parallèles augmentent. Si le domaine commercial gère dans des feuilles de calcul un champ de plus en plus large au lieu de le faire dans le système, cela signifie que le système ne reflète pas le travail réel. Comme ces solutions alternatives ne sont enregistrées nulle part, en ne regardant que le système, le problème n'est pas perçu.

Calculez le coût de maintenance

La raison pour laquelle le débat sur le remplacement n'avance pas est souvent l'argument « si cela fonctionne, pourquoi dépenser de l'argent ». Pour répondre à cette question, il faut prouver par des chiffres que le maintien génère également des coûts. Additionnez les quatre postes suivants.

Les trois premiers postes sont des coûts déjà engagés mais qui ne figurent dans aucun compte. Le quatrième est un coût qui ne s'est pas encore produit, mais qui s'accumule en termes probabilistes.

Ce qui suit est un exemple hypothétique destiné à montrer la méthode de calcul ; les valeurs réelles varient selon les conditions de chaque entreprise. Si 30 demandes de changement sont reçues par an, avec une attente moyenne de 10 jours par demande, et que le coût d'opportunité quotidien de cette attente est estimé à 150.000 KRW, le coût du retard s'élève à 45.000.000 KRW par an. Si l'on ajoute que deux départements consacrent chacun cinq heures par semaine à la double gestion dans des feuilles de calcul, avec un coût total du travail par heure de 25.000 KRW, cela ajoute 13.000.000 KRW par an.

Si le total est de 58.000.000 KRW par an, en trois ans cela représente 170.000.000 KRW. C'est à ce moment-là qu'apparaît pour la première fois un chiffre comparable au coût du remplacement. Maintenir n'est pas gratuit : c'est une dépense pour laquelle aucune facture n'arrive.

Pourquoi la reconstruction complète est risquée

Une fois la décision de remplacer prise, la première méthode qui vient à l'esprit est la reconstruction complète : arrêter l'ancien, construire le nouveau et tout changer d'un coup à une date déterminée. C'est intuitif, mais cela comporte trois risques.

Le bénéfice est nul jusqu'à l'achèvement du projet. Dans une reconstruction de douze mois, pendant onze mois, l'organisation ne paie que des coûts et ne perçoit aucune amélioration. Si l'environnement commercial change pendant cette période, le projet est sous pression d'annulation.

Les exigences vieillissent en cours de route. Les exigences définies au début ne correspondent pas aux besoins du domaine commercial un an plus tard. Si cette différence est incorporée, le calendrier est retardé ; si elle n'est pas incorporée, ce qui est livré est un système déjà obsolète.

Le risque se concentre au moment du changement. Comme toutes les fonctionnalités changent en même temps, s'il y a un problème le jour de la transition, il n'y a pas de moyen simple de revenir en arrière. Et le problème survient presque toujours, car dans l'ancien système, il reste sans aucun doute des règles d'exception que personne ne se rappelle.

La migration incrémentale comme alternative

Au lieu du remplacement complet, il est possible de maintenir le système existant et de transférer les fonctionnalités une par une. L'ordre est le suivant.

Phase 1 — Définir les frontières

Divisez le système actuel en blocs fonctionnels. Séparez-les par unités commerciales —commandes, inventaire, facturation, ressources humaines—, mais tracez la ligne en fonction de qui est le propriétaire des données. Si plusieurs blocs modifient directement la même table, ce point deviendra plus tard le plus grand obstacle.

En traçant les frontières, suivez le flux des données et non l'organigramme. Bien que les départements soient séparés, s'ils modifient ensemble les mêmes données, ils forment un seul bloc ; et même s'il s'agit d'un seul département, si les données sont complètement séparées, il est possible de le diviser.

Phase 2 — Séparer d'abord la lecture

La première initiative la plus sûre est les fonctionnalités de consultation. Les tableaux de bord, les statistiques et les rapports, qui ne font que lire des données, peuvent être construits dans le nouveau système sans affecter l'existant. Même s'ils échouent, l'ancien écran reste disponible, ce qui rend le retour en arrière simple et le domaine commercial perçoit immédiatement l'amélioration.

Cette phase apporte également un effet secondaire. En construisant les fonctionnalités de consultation, les problèmes des données existantes apparaissent : clients dupliqués, dates avec un format cassé, lignes avec la valeur de code vide. Il est important de connaître ces problèmes avant de transférer les fonctionnalités d'écriture.

Phase 3 — Migrer les fonctionnalités d'écriture

Une fois la vérification effectuée par la consultation, les fonctionnalités de création et de modification sont transférées. Comme pendant un certain temps les deux systèmes géreront les mêmes données, désignez l'un d'eux comme source. Si la modification est autorisée des deux côtés, des divergences apparaîtront, et les localiser prend plus de temps que la migration elle-même.

En ce qui concerne l'ordre, il est prudent de commencer par les fonctionnalités peu utilisées et à portée limitée. Cependant, si l'on commence par des fonctionnalités que personne n'utilise, aucune vérification ne sera possible, de sorte que le meilleur point de départ est une fonctionnalité réellement utilisée mais qui peut être arrêtée pendant un jour.

Phase 4 — Réduire le système existant

Les fonctionnalités déjà migrées doivent être supprimées du système existant. Si elles sont laissées, une partie de l'aire d'affaires continuera à utiliser les anciennes interfaces, et les deux systèmes seront maintenus indéfiniment. Le report de cette phase est la cause la plus fréquente de l'échec d'une migration incrémentale.

Si la suppression s'avère difficile, bloquez au moins l'accès et laissez-les en mode lecture seule. Et fixez une date précise pour leur retrait définitif. Un plan de nettoyage sans date ne sera pas exécuté.

Lequel des deux choix choisir

La reconstruction complète n'est pas toujours une erreur. Si la portée est limitée, les règles métier sont documentées par écrit et quelques heures d'interruption sont acceptables, tout changer en une seule fois est plus rapide et plus économique. Le critère n'est pas l'ancienneté du système, mais où sont enregistrées les règles.

Lo que realmente causa problemas en la migración de datos

La causa de los retrasos en el calendario no suele ser el desarrollo de funcionalidades, sino los datos. En los sistemas antiguos se acumulan estados como los siguientes.

• Un mismo cliente registrado varias veces con grafías distintas
• Formatos de fecha, de teléfono y de número de identificación fiscal que difieren según la época
• Filas con campos obligatorios vacíos
• Datos que siguen referenciando valores de código ya suprimidos
• Filas marcadas como eliminadas que en realidad permanecen mezcladas con el resto

Si estos problemas se descubren durante la fase de migración, el calendario se retrasa sin remedio. Investíguelos de antemano, antes de empezar, y determine primero qué ámbito se depura y cuál se descarta. Si se pretende depurar a la perfección todos los datos históricos, la migración no terminará nunca. En muchos casos resulta más realista depurar únicamente los últimos años y conservar el resto en modo de solo consulta.

Una oportunidad para rediseñar la seguridad y los permisos de acceso

La sustitución es también una ocasión poco frecuente para ordenar el sistema de seguridad. Los sistemas antiguos suelen tener una separación laxa de permisos y funcionan con la mayoría del personal en disposición de ver más datos de los necesarios. Defina los siguientes puntos durante el proceso de migración.

Minimización de los permisos de acceso. Diferencie los accesos de modo que cada rol vea únicamente los datos que necesita. Si se traslada tal cual la estructura de permisos del sistema existente, con ella se trasladan también sus defectos.

Ubicación de almacenamiento y plazo de conservación de los datos personales. Determine qué datos personales se almacenan, dónde y cuándo se destruyen. En caso de migrar a la nube, hay que verificar además en qué país quedan almacenados los datos.

Conservación del registro de operaciones. Deje constancia de quién modificó qué y cuándo. Es frecuente que los sistemas antiguos carezcan de este registro y que, ante un problema, no sea posible rastrear su origen.

Cómo convencer a la dirección

El presupuesto de sustitución no suele aprobarse con argumentos técnicos. Explicaciones como «la estructura está obsoleta» o «el soporte técnico ha finalizado» no transmiten urgencia a quien firma. Preséntelas transformadas en los tres puntos siguientes.

El importe que se está perdiendo ahora. Es la suma de los costes de retraso, de procesos paralelos y de errores calculados anteriormente. Lo esencial es que ya se están desembolsando aunque no se sustituya nada.

Lo que no se está pudiendo hacer. Elabore la lista de las peticiones rechazadas durante el último año con el argumento de que «no es posible con el sistema actual». Si alguna de ellas está vinculada a la facturación o a la pérdida de clientes, colóquela en primer lugar. El lucro cesante es un argumento más potente que el coste de mantenimiento.

El peor escenario. Calcule el plazo y el coste de recuperación en caso de que la única persona responsable deje la empresa o de que se produzca un incidente en un componente sin soporte. Aunque la probabilidad sea baja, una magnitud elevada mueve la decisión.

Tras presentar los tres puntos, solicite la aprobación únicamente de la primera fase de la migración incremental. Si se pide todo el presupuesto de una vez, el periodo de estudio se alarga y, entretanto, la situación empeora.

Cómo planificar el calendario y los recursos

En la migración incremental, lo que más a menudo se desvía es el calendario. Incorpore de antemano tres consideraciones.

Incluya en el calendario el tiempo del área de negocio. En un proyecto de migración, el recurso más escaso no son los desarrolladores, sino las personas del área de negocio que conocen las reglas. Como participan sin dejar sus tareas habituales, si no se acuerda previamente el tiempo disponible, el calendario se retrasará en cada fase de verificación.

Incluya en el cálculo el periodo de operación en paralelo. Incluso después de trasladar una funcionalidad hay que operar ambos sistemas conjuntamente durante un tiempo. En ese periodo la carga operativa aumenta en lugar de disminuir. Si no se refleja en el calendario y el presupuesto, en la última fase faltará personal.

Reserve un periodo específico para la depuración de datos. Los problemas de integridad de los datos que se tratan más adelante pueden abordarse en paralelo al desarrollo, pero requieren tiempo y personas propias. Si se ocultan dentro del calendario de desarrollo, el retraso es seguro.

Qué verificar al trabajar con un proveedor externo

En muchos casos resulta difícil llevar a cabo la migración únicamente con recursos internos. Si valora recurrir a un proveedor externo, verifique lo siguiente antes de firmar.

¿Los entregables incluyen documentación? Si solo se recibe el código, el mismo problema se repetirá al cabo de unos años. Los entregables deben incluir la definición de las reglas de negocio, la descripción de la estructura de datos y el manual de procedimientos operativos.

¿Está definida la forma de traspaso posterior a la migración? Una vez finalizada la implantación, el personal interno debe poder operar el sistema. Especifique en el contrato el periodo de traspaso y el alcance de la formación.

¿Es posible contratar por fases? Si se contrata todo de una vez, resulta difícil cambiar de rumbo a mitad de camino. Un esquema en el que se ejecuta la primera fase y después se decide sobre las siguientes es más seguro para ambas partes.

¿Están claros los derechos sobre nuestros datos? Si durante el desarrollo se utilizan datos reales, establezca por escrito qué datos se desplazan, adónde y cómo se destruyen una vez finalizado el trabajo.

Qué preparar antes de empezar

Con independencia del método elegido, asegure estos tres puntos antes de empezar.

Documentación de las reglas de negocio vigentes. Las reglas que solo existen en el código se pierden sin falta durante la migración. No hace falta una especificación perfecta, pero deje por escrito al menos la gestión de excepciones y las condiciones de aprobación.

Revisión de la integridad de los datos. Examine el estado actual conforme a los puntos recogidos anteriormente y determine el ámbito de depuración.

Plan de reversión. Establezca para cada fase cómo se da marcha atrás si surge un problema. Una fase que no se puede revertir es, por eso mismo, una fase demasiado grande, y constituye la señal de que hay que dividirla en partes más pequeñas.

Resumen

El coste de un sistema obsoleto no se manifiesta en forma de averías, sino en forma de retraso y dependencia. Por eso se percibe tarde.

• Revise las cinco señales: coste del cambio, concentración del conocimiento en una persona, fin del soporte técnico, accesibilidad de los datos y procesos paralelos.
• Calcule el coste de mantener con las cuatro partidas —retraso, procesos paralelos, errores y riesgo— y conviértalo en una cifra comparable con el coste de la sustitución.
• Si las reglas solo existen en el código, la reconstrucción completa es arriesgada.
• Empiece migrando las funcionalidades de consulta y elimine sin falta del sistema existente todo lo ya migrado.
• Investigue la integridad de los datos antes de empezar y fije de antemano el ámbito de depuración.
• Aproveche la ocasión para rediseñar a la vez los permisos de acceso y la política de conservación de datos personales.

Más importante que decidir si sustituir o no es no aplazar la decisión. Si concurren tres de las cinco señales, iniciar el estudio dentro de este año sale más barato que acometer una reconstrucción completa el año que viene.