Migrando programas de gestión: problemas que no deberían aparecer

Ayer hablaba en la entrada de hardware. Hoy vamos a cambiar de tercio para hablar de software. Hace años cuando la blogosfera brillaba con luz propia sobre el Internet hispano muchas de las ideas para escribir entradas venían de artículo leídos allí. Ahora la influencia suele llegar por las redes sociales. Hoy me ha hecho abrir la libreta de entradas pendientes un cruce de tweets con @jhortelano. Vamos a tratar de ampliar el tema.

En Twitter hablábamos de cómo hay empresas pasando un verdadero calvario tras un “simple” cambio de plataforma de facturación, contabilidad o un ERP. He puesto simple por un motivo. En estos momentos con el desarrollo en software y hardware que tenemos cambiar una plataforma de software ya se ha hecho infinidad de veces. Y tenemos muchos profesionales cansados de hacerlo y de hacerlo bien. Así que no debería haber dificultades técnicas para llevarlo a cabo.

Sin embargo, sigo viendo y conociendo casos de empresas con grandes problemas tras el cambio su plataforma de gestión. Ahora mismo en la comarca conozco el caso de un par de Pymes que van de cabeza desde que a principios de año (hace ya 11 meses) cambiaron su programa de facturación y contabilidad.

Muchos de estos problemas llegan por la combinación de varios factores:

• Vendedores que solo están pensando en la comisión que ganarán: ofrecen el ERP que más margen les da y no se ponen a pensar en nada más.
• Gerentes que compran la opción que es más barata y que además acaben antes la implantación
• Empresas que rotan mucho a su personal y pierden pronto a los empleados expertos en este tipo de operaciones.
• Falta de previsión:
  • No se hace un plan de conversión
  • No hay análisis funcional para decidir la nueva plataforma a instalar.
  • No hay o se reduce al mínimo el plazo de convivencia entre sistema viejo y sistema nuevo
  • No se preparan planes de contingencia, viendo lo que puede ir mal y preparándose para resolverlo.
  • Por supuesto casi nunca hay un plan de vuelta atrás realista.

Reconozco que en mi caso parto de una situación de privilegio. En mi vida laboral estuve metido en muchas operaciones de este tipo. Y casi nunca en el mismo puesto. He pasado por:

• Cambio de aplicativo en Oficinas, afectando a más de 7.000 puestos, cuando en mi empresa de por las mañanas pasamos del teleproceso en modo texto a PCs con Windows
• Muchos cambios de aplicaciones departamentales
• Cambios de ordenador host de toda una entidad.
• Más de media docena de fusiones e integraciones entre entidades financieras.

Y todo eso deja un poso. Así cuando en alguno de los proyectos anteriores hemos tenido problemas se entienden los planes de contingencia. Que si no pasa nada parecen una pérdida de tiempo. Pero no te puedes arriesgar a dejar a una empresa parado por no tener nada previsto si sucede algo fuera del guion establecido.

Así que las veces que algún cliente nos ha pedido ayuda para una migración de plataforma los pasos que damos serían:

1. Analizar las necesidades actuales y futuras de la empresa para escoger la nueva herramienta de software.
2. Preparar un plan de migración.
3. Probar la conversión de datos de la plataforma antigua a la nueva. Validando el tiempo invertido y la calidad de la conversión.
4. Calcular el tiempo necesario para la conversión. Aquí se requiere medir el tiempo en la conversión digital y si hay necesidad de hacer conversiones manuales ver el tiempo que se requerirá hasta tener los datos cargados en el sistema nuevo.
5. Hacer un plan de formación para que toda la plantilla conozca la nueva herramienta antes de la conversión.
6. Realizar un plan de convivencia entre los dos sistemas: ir probando funciones de nuevo sistema antes del día de la migración definitiva.
7. Que empleados de diferentes departamentos y categoría prueban el nuevo sistema buscando errores.
8. Buscar puntos de comprobación automáticos donde poder hacer pruebas desatendidadas de la calidad de los datos migrados.
9. Procurar hacer la migración en algún periodo festivo largo: puentes de tres o cuatro días son ideales.
10. Adelantar todo el trabajo de migración que sea posible antes del día de la migración definitiva
11. Pensar siempre en lo que pueda salir mal… y seguir pensado en que algo puede salir mal

Algunos de los proyectos que conozco de cerca se han hecho de un día para otro, sin formación, sin planes de contingencia… y luego si paciencia. Y es complicado que salga bien sin tener la cosas bien planteadas. Si siguiendo una estricta planificación aparecen errores que no pasará si no se planifica nada.

Voy a poner dos ejemplos de errores que he visto en migraciones de sistemas. Que surgieron a pesar de que se hizo todo lo posible por evitarlos.

En una ocasión hicimos un cambio muy grande en los servidores de una parte importante de la red de la empresa (afectaba a más de 3.000 equipos). Recuerdo que una de las empresas proveedoras de una de las soluciones nuevas que implantamos nos ofreció apoyo técnico. Nos pasó una factura pequeña. Pero mis jefes decidieron que teníamos suficiente conocimiento interno y además todas las pruebas previas habían sido exitosas. Realizamos el despliegue. Y por si acaso (menos mal) empezamos de forma gradual. La idea era ir integrando más centros de trabajo semana a semana. Una vez llegada a una cifra crítica, si no fallaba nada se haría el despliegue de golpe para el resto. Las dos primeras semanas todo iba bien. Pero cuando llegamos a la tercera semana aquello comenzó a ir mal. Se paró la migración y se revisó todo… no localizábamos el error. Al final llamamos a la empresa que nos había ofrecido colaboración. Como ahora teníamos prisa el precio se triplicó. Pero en un par de días encontraron el error y lo resolvieron (por cierto uno de los técnicos que vino luego apareció en una de las fusiones futuras como el jefe máximo de IT…). El problema estaba en algunas de la conexiones de red ADSL de la época que se llevaban con una parte de la red. Como todas las pruebas se habían hecho en una zona geográfica cerrada que no presentaba esos problemas no se habían detectado a tiempo. Por lo menos al hacer la implantación de forma gradual el problema no afectó a muchos empleados.

En la última fusión de entidades financieras en la que trabajé nos salpicó un error tonto. Y además apareció a los meses de terminar el proceso de fusión. Pero el error que pudo ser tonto en origen generó problemas a más de 20.000 clientes. Y para resolverlo tuvimos que consumir muchas horas hombres.

El error fue un malentendido en la conversión de un fichero. El fichero tenía un campo numérico que tomaba valores enteros comprendidos entre 1 y 50. Cada valor numérico se relacionaba con una situación contable de la operación. En la entidad que se extinguía había una serie de situaciones contables “especiales” que no existían en la entidad que absorbía. En la entidad que absorbía había una regla en sus programas que decía que si la situación contable era superior a 20 la cuenta se paraba y no era operativa. Sin embargo, en la otra entidad cada código contable se evaluaba de forma independiente. Así un código 33 podía significar cuenta a revisar a futuro, pero no se paraba el funcionamiento de la cuenta. Además, eran cuentas que no eran las principales de los clientes. Recuerdo que en las conversaciones de la migración le dimos mucha importancia a la diferencia de tratamiento. Al final definimos una regla de conversión en el fichero para que las situaciones mayores de 20 que no bloqueaban se convirtiesen a códigos menores de 20 en la base de datos final.

Al final durante la noche de la conversión el proceso de ese fichero falló. Se revisó y volvió a fallar. Al final el supervisor cambio la regla de conversión por la genérica de mayor de 20 se bloquea la cuenta… Y de momento no pasó nada.

Tres meses después teníamos un alud de quejas de clientes con recibos no atendidos, intereses de demora… Al final montamos un equipo de emergencia que tuvo que hacer muchas horas extras para resolverlo en un tiempo record. Esto estaba previsto en el plan de contingencia y teníamos los recursos a la espera por si pasaba algo así.

Como podéis ver en estos dos casos el problema surgió después de la migración. Son problemas que aparecen a largo plazo y son los peores de detectar. Pero por lo menos en las historias que os cuento había planes para tratar de mitigar esos problemas.

Pero está claro que eso de ser previsor es complicado. Y además para muchos gerentes la informática es un mundo arcano. Y luego otro problema es no tener informáticos en la plantilla. Conozco casos cercanos de migraciones exitosas en Pymes. Pero aquí los que lideraron la migración eran los equipos internos de informáticos.