Sistema interno obsoleto: ¿reparar o reconstruir?

La situación a la que se enfrentan las empresas hoy en día

Las empresas cuyo sistema interno ha estado en funcionamiento durante más de diez años generalmente se encuentran en la misma situación. El sistema sigue funcionando. No hay fallos importantes que reportar. Sin embargo, la más mínima solicitud tarda dos semanas, y solo una persona en la empresa es capaz de gestionarla.

Este estado es peligroso porque el problema se degrada progresivamente. Un sistema que se detiene abruptamente obtiene inmediatamente un presupuesto. Pero un sistema que se ralentiza un poco y que requiere un poco más de trabajo cada año pasa la revisión anual bajo la fórmula: «este año más, hemos aguantado como hemos podido». Cuando estos años se acumulan, tres plazos ocurren al mismo tiempo.

Primero, el colaborador que conoce el sistema se jubila. Las reglas de negocio no documentadas desaparecen con él. En segundo lugar, el soporte de seguridad de las tecnologías base finaliza. Para un lenguaje o una versión de base de datos que ya no se mantiene, no aparece ningún parche cuando se descubre una vulnerabilidad. En tercer lugar, se vuelve imposible añadir nuevas necesidades. La adopción de móviles, la integración de servicios externos o el análisis de datos se enfrentan a un rechazo continuo: «no es posible con el sistema actual».

Cuando estos tres plazos se presentan simultáneamente, la única opción restante es la reestructuración completa. Sin embargo, la reestructuración completa es la opción más costosa y arriesgada.

Cinco señales que indican que se debe considerar el reemplazo

Si al menos tres de los siguientes puntos le conciernen, es momento de iniciar la revisión de un reemplazo.

1. El costo del cambio es asimétrico. Añadir un campo a una pantalla toma varios días. Cuando, desde el punto de vista del usuario, la duración de desarrollo de una solicitud menor y una solicitud mayor difieren poco, la estructura ya no soporta el cambio.

2. El mantenimiento recae en una sola persona. Un sistema al que solo una persona puede acceder convierte sus ausencias y su salida en un riesgo para la actividad. No se trata de un problema de recursos humanos, sino de un problema de estructura.

3. El soporte de las tecnologías base ha finalizado. Verifique las fechas oficiales de finalización del soporte del motor de ejecución del lenguaje, del marco y de la base de datos utilizados. Si ya han pasado, el incidente de seguridad es solo cuestión de tiempo.

4. Los datos no pueden ser explotados. Si obtener los números necesarios para una decisión de dirección obliga a un colaborador a escribir una consulta por sí mismo, o a abrir varias pantallas para sumar manualmente, es porque el sistema encierra los datos.

5. Los atajos se multiplican. Si el ámbito que los negocios gestionan en hojas de cálculo en lugar de en el sistema se expande, significa que el sistema ya no refleja el trabajo real. Este atajo no está registrado en ninguna parte, por lo que el problema permanece invisible mientras solo se observe el sistema.

Calcule el costo del mantenimiento

Si el debate sobre el reemplazo no avanza, generalmente es por una pregunta: «¿por qué gastar si aún funciona?». Para responder a esto, es necesario demostrar con cifras que el mantenimiento también genera costos. Sume los siguientes cuatro conceptos.

Los tres primeros conceptos corresponden a gastos ya incurridos pero que no aparecen en ninguna cuenta. El cuarto corresponde a un costo aún inexistente pero que se acumula en probabilidad.

Lo siguiente es un ejemplo hipotético destinado a ilustrar el método de cálculo; los valores reales varían según las condiciones propias de cada empresa. Con 30 solicitudes de modificación al año, un tiempo de espera promedio de 10 días por solicitud y un costo de oportunidad diario de la espera fijado en 150,000 KRW, el único costo de los retrasos alcanza 45,000,000 KRW al año. Si, además, dos servicios dedican cada uno cinco horas a la semana a una doble gestión en hojas de cálculo, se añaden 13,000,000 KRW al año sobre la base de un costo salarial completo por hora de 25,000 KRW.

Si el total se establece en 58,000,000 KRW al año, representa 170,000,000 KRW en tres años. Solo en ese momento aparece una cifra comparable al costo de un reemplazo. El mantenimiento no es gratuito: es un gasto para el cual no llega ninguna factura.

Por qué la reestructuración completa es arriesgada

Una vez decidido el reemplazo, el primer método que viene a la mente es la reestructuración completa: detener lo antiguo, construir lo nuevo y cambiar de golpe, en un día determinado. El enfoque es intuitivo, pero conlleva tres riesgos.

El beneficio permanece nulo hasta el final del proyecto. Para una reestructuración de doce meses, la organización paga durante once meses sin percibir la más mínima mejora. Si el contexto económico cambia durante este período, el proyecto sufre una presión para detenerse.

Los requisitos envejecen en el camino. Los requisitos establecidos al inicio difieren de las necesidades que los negocios expresan un año después. Repercutir esta discrepancia retrasa el calendario; no repercutirla resulta en un sistema ya obsoleto.

El riesgo se concentra en el momento del cambio. Todas las funciones cambian de una vez, por lo que apenas hay forma de retroceder si ocurre un incidente el día del cambio. Y un incidente casi siempre ocurre, ya que en el antiguo sistema persisten invariablemente reglas de excepción que nadie recuerda.

La migración progresiva como alternativa

En lugar de un reemplazo integral, existe un enfoque que consiste en transferir las funciones una a una mientras se conserva el sistema existente. El orden es el siguiente.

Paso 1 — Delimitar las fronteras

Divida el sistema actual en bloques funcionales. Divídalo por unidad de negocio: pedidos, inventarios, facturación, recursos humanos, pero trace las líneas según el propietario de los datos. Si varios bloques modifican directamente la misma tabla, este punto se convertirá más tarde en el principal obstáculo.

Para trazar estas fronteras, siga los flujos de datos y no el organigrama. Si dos servicios distintos modifican conjuntamente los mismos datos, forman un solo bloque; y si, dentro de un mismo servicio, los datos están completamente separados, la división es posible.

Paso 2 — Separar primero la lectura

El primer proyecto más seguro se refiere a las funciones de consulta. Tableros, estadísticas, informes: las funciones que solo leen los datos pueden construirse en el nuevo sistema sin afectar al existente. En caso de fallo, las pantallas existentes permanecen, la reversión es sencilla y los negocios perciben inmediatamente la mejora.

Este paso produce un efecto secundario adicional. Al construir las funciones de consulta, aparecen los defectos de los datos existentes: clientes duplicados, fechas en formato corrupto, líneas cuya valor de código está vacía. Es esencial descubrir estos defectos antes de transferir las funciones de escritura.

Paso 3 — Transferir las funciones de escritura

Una vez completada la verificación mediante la consulta, transfiera las funciones de entrada y modificación. Dado que dos sistemas estarán manipulando los mismos datos durante un tiempo, designe un solo lado como fuente de referencia. Permitir que ambos lados modifiquen simultáneamente produce incoherencias cuya búsqueda cuesta más tiempo que la migración misma.

Para el orden de transferencia, comenzar con funciones poco utilizadas y de bajo alcance es más seguro. Sin embargo, transferir primero funciones que nadie utiliza no permite ninguna verificación: una función realmente utilizada pero cuya interrupción de un día sería tolerable es el mejor punto de partida.

Paso 4 — Reducir el sistema existente

Las funciones transferidas deben ser eliminadas del sistema existente. Si se dejan en su lugar, parte del negocio seguirá utilizando las antiguas pantallas y la empresa terminará manteniendo dos sistemas indefinidamente. Retrasar este paso es la causa más frecuente de fracaso en una migración progresiva.

Si la eliminación es difícil, al menos bloquee los accesos y cambie la función a solo lectura. Luego, fije una fecha para su eliminación definitiva. Un plan de limpieza sin fecha nunca se ejecuta.

Qué opción elegir

El rediseño completo no siempre es una mala elección. Si el alcance es restringido, si las reglas de negocio están consignadas en documentos y si unas pocas horas de interrupción son tolerables, cambiar de una vez es más rápido y menos costoso. El criterio de decisión no es la antigüedad del sistema, sino el lugar donde están consignadas las reglas.

Ce qui pose réellement problème lors de la migration des données

Les retards de calendrier tiennent le plus souvent aux données et non au développement des fonctions. Les systèmes anciens accumulent des situations telles que les suivantes.

• Un même client enregistré plusieurs fois sous des libellés différents
• Des formats de dates, de numéros de téléphone et de numéros d'entreprise variant selon les périodes
• Des lignes vides sur des champs pourtant obligatoires
• Des données faisant référence à des valeurs de code désormais supprimées
• Des lignes seulement marquées comme supprimées mais physiquement conservées

Découverts pendant la phase de migration, ces problèmes décalent immanquablement le calendrier. Enquêtez en amont, avant le lancement, et déterminez d'abord ce qui sera nettoyé et ce qui sera abandonné. Vouloir assainir parfaitement l'intégralité des données historiques empêche la migration d'aboutir. Nettoyer les seules dernières années et conserver le reste en consultation seule est souvent l'option réaliste.

L'occasion de reconcevoir la sécurité et les droits d'accès

Un remplacement constitue aussi une occasion rare de remettre en ordre le dispositif de sécurité. Les systèmes anciens présentent généralement une séparation des droits relâchée, la plupart des collaborateurs pouvant consulter davantage de données que nécessaire. Traitez les points suivants au cours de la migration.

La minimisation des droits d'accès. Faites en sorte que chaque rôle ne voie que les données qui lui sont nécessaires. Reprendre telle quelle la structure de droits du système existant revient à transférer aussi ses défauts.

Le lieu de stockage et la durée de conservation des données à caractère personnel. Établissez quelles données personnelles sont stockées, où, et à quel moment elles sont détruites. En cas de migration vers le nuage, le pays de stockage des données doit également être vérifié.

La conservation de l'historique des traitements. Consignez qui a modifié quoi et quand. Faute de cet enregistrement, de nombreux systèmes anciens ne permettent pas de remonter à la cause lorsqu'un incident survient.

Comment convaincre la direction

Le budget d'un remplacement passe rarement sur une argumentation technique. « La structure est vieillissante », « le support technique a pris fin » : ces explications ne se traduisent pas en urgence pour un décideur. Reformulez-les selon les trois axes suivants.

Le montant qui fuit aujourd'hui. C'est le total des coûts de retard, de contournement et d'erreur calculés plus haut. Le point essentiel est que cette dépense est déjà engagée, remplacement ou non.

Ce que l'on ne parvient pas à faire. Dressez la liste des demandes rejetées au cours de l'année écoulée au motif que « le système actuel ne le permet pas ». Placez en tête celles qui touchent au chiffre d'affaires ou à la perte de clients. Le manque à gagner est un argument plus puissant que le coût de maintien.

Le pire scénario. Estimez la durée et le coût du rétablissement si l'unique responsable venait à partir ou si un incident survenait sur un composant en fin de support. Même à faible probabilité, une ampleur élevée fait bouger la décision.

Après avoir exposé ces trois axes, ne demandez l'approbation que pour la première étape de la migration progressive. Réclamer l'intégralité du budget en une fois allonge la durée d'examen, et la situation se dégrade entre-temps.

Comment établir le calendrier et les ressources

Dans une migration progressive, c'est souvent le calendrier qui dérape. Intégrez trois éléments par avance.

Inscrivez le temps des métiers au calendrier. Dans un projet de migration, la ressource la plus rare n'est pas le développeur mais le collaborateur métier qui connaît les règles. Ces personnes participent en parallèle de leur activité principale : sans accord préalable sur le temps qu'elles peuvent y consacrer, chaque phase de vérification prend du retard.

Intégrez au calcul la période d'exploitation en parallèle. Après le transfert d'une fonction, les deux systèmes doivent coexister pendant un certain temps. Pendant cette période, la charge d'exploitation augmente au lieu de diminuer. Ne pas en tenir compte dans le calendrier et le budget conduit à un manque de ressources lors de la dernière étape.

Prévoyez une période distincte pour le nettoyage des données. Les questions d'intégrité des données évoquées plus loin peuvent être traitées en parallèle du développement, mais elles réclament un temps et des personnes dédiés. Noyées dans le calendrier de développement, elles prendront du retard à coup sûr.

Ce qu'il faut vérifier avec un prestataire externe

Il est fréquent qu'une migration ne puisse être menée avec les seules ressources internes. Si vous envisagez un prestataire externe, vérifiez les points suivants avant la signature.

Les livrables comprennent-ils de la documentation ? Ne recevoir que du code fait réapparaître le même problème quelques années plus tard. Le référentiel des règles métier, la description de la structure des données et les procédures d'exploitation doivent figurer parmi les livrables.

Les modalités de transfert de compétences après la migration sont-elles définies ? Une fois la mise en œuvre achevée, les équipes internes doivent pouvoir exploiter le système. Précisez au contrat la durée du transfert de compétences et le périmètre de la formation.

Le contrat peut-il être découpé par étapes ? Contracter l'ensemble en une fois rend difficile tout changement de cap en cours de route. Réaliser la première étape puis décider de la suite est une structure plus sûre pour les deux parties.

Les droits sur nos données sont-ils clairs ? Si des données réelles sont utilisées durant le développement, fixez par écrit quelles données se déplacent, vers où, et comment elles sont détruites à la fin.

Ce qu'il faut préparer avant le lancement

Quelle que soit l'approche retenue, assurez-vous des trois éléments suivants avant le lancement.

La documentation des règles métier en vigueur. Les règles qui n'existent que dans le code sont immanquablement perdues au cours de la migration. Sans viser une spécification parfaite, consignez au moins par écrit la gestion des exceptions et les conditions d'approbation.

Le contrôle de l'intégrité des données. Examinez l'état actuel au regard des points énumérés plus haut et déterminez le périmètre du nettoyage.

Un plan de retour en arrière. Pour chaque étape, définissez comment revenir en arrière en cas de problème. Une étape irréversible est en elle-même une étape trop grande : c'est le signe qu'il faut la découper plus finement.

Synthèse

Le coût d'un système vieillissant ne se manifeste pas sous forme de pannes mais sous forme de retards et de dépendance. C'est pourquoi il est perçu tardivement.

• Examinez les cinq points suivants : coût du changement, concentration des compétences, fin du support technique, accessibilité des données, contournements.
• Calculez le coût du maintien selon les quatre postes retards, contournements, erreurs et risque, afin d'obtenir un chiffre comparable au coût d'un remplacement.
• Si les règles n'existent que dans le code, la refonte complète est risquée.
• Transférez d'abord les fonctions de consultation, et supprimez impérativement du système existant les fonctions transférées.
• Examinez l'intégrité des données avant le lancement et fixez à l'avance le périmètre du nettoyage.
• Profitez de cette occasion pour reconcevoir les droits d'accès et la politique de conservation des données à caractère personnel.

Plus important que la décision de remplacer est le fait de ne pas la repousser. Si trois des cinq signaux vous concernent, engager l'examen dans l'année revient moins cher qu'une refonte complète l'année suivante.