Migración de datos ERP: dimensionamiento del esfuerzo

Los procesos de migración de datos durante los cambios de los sistemas de gestión empresarial ERP son procesos muy complicados, los cuales tienden a minusvalorarse, al pensar que son una cuestión menor y sin dificultad. Además, pueden suponer la diferencia entre el éxito y el fracaso de un proyecto en función del grado de confianza y fiabilidad logrado en el proceso. Si bien el cliente es capaz de percibir que una migración manual de datos llevada a cabo por sus usuarios puede conllevar bastante tiempo (y por tanto coste económico), no tiene la misma percepción cuando esa labor ha de realizarla una organización externa.

También se tiende a pensar que la migración consiste en un «traslado» íntegro del sistema anterior al nuevo, es decir, maestros, datos vivos e histórico de todos los movimientos. Normalmente la cotización de las migraciones se realiza en tres ámbitos en función del nivel de completud exigido: algunos maestros (clientes, artículos, tarifas, stocks, etc.); transacciones vivas (pedidos pendientes de servir, albaranes pendientes de facturar, registros contables, etc.); todo el sistema (absolutamente todos los registros). El 50-60% de los clientes piensan que una migración implica el «traslado» de todo el histórico, y que no tienen que alimentar para nada el nuevo sistema. Hay que realizar una cierta labor didáctica en este sentido. Además, las migraciones suelen tener un precio «político», pues no puede cobrarse realmente el esfuerzo que significa.

Lógicamente, el nivel de complejidad, y por tanto el coste derivado, va en aumento en base a lo anterior, aunque también se debe al nivel de pruebas y test que hay que realizar para garantizar que la información estadística cuadra entre los dos sistemas, los registros contables, de facturación, de stocks, etc.

Para dimensionar el esfuerzo de migración de datos en un ERP hay que conocer y cuantificar muchas variables, pero éstas podrían resumirse en tres: grado de conocimiento del sistema de origen, grado de conocimiento del sistema destino y actividades propias de la migración.

Grado de conocimiento del sistema de origen

Normalmente la colaboración del proveedor anterior no suele ser habitual, dado que los cambios suelen ser en parte provocados por falta de entendimiento con el cliente. En cualquier caso, tengamos esa colaboración o no, debemos tener en cuenta los siguientes factores:

• Datos acceso al sistema. La accesibilidad al sistema debe estar garantizada.
• Estructura de tablas y campos: no siempre es fácil e inteligibles la organización dentro de la base de datos.
• Relaciones entre tablas: las referencias cruzadas entre las tablas suele ser muy diversa, por lo que suele complicar la migración.
• Tipos de datos de cada campo: las equivalencias incluso por tipos de datos (carácter a entero por ejemplo), dificultan igualmente el proceso.

Esto suponiendo que toda la información puede ser migrada desde un sistema estructurado, si bien, en ocasiones hay información dispersa en otras bases de datos, hojas de cálculo, etc.

Grado de conocimiento del sistema de destino

En este caso, se da por supuesto, que ésta existe, pues normalmente el mismo implantador suele ser la organización que realizará la migración. Tendremos en cuenta los siguientes factores:

• Estructura equivalente de tablas y campos. A mayor conocimiento de las analogías, más fácil será el proceso.
• Triggers de base de datos que se desencadenan al cargar datos. Su desconocimiento puede desencadenar datos (o falta de éstos) necesarios para el tratamiento correcto de la información en el futuro.
• Procedimientos, jobs, paquetes, etc, que deberán ejecutarse con posterioridad a la carga de datos para dejar consistente la base de datos.

Actividades propias de la migración

Suponiendo que ya somos capaces de conocer con una cierta profundidad ambos sistemas, ahora toca realizar:

• Mapeado de campos entre ambos sistemas (equivalencias entre origen y destino)
• Conversiones de datos (alfanumérico en origen, numérico en destino por ejemplo)
• Agregaciones (varios campos en origen dan por resultado un valor agregado en campo destino)
• Desagregaciones (al contrario del anterior)
• Reemplazos de valores (un valor en origen debe convertirse en un valor distinto en destino)
• Filtros a aplicar (registros a migrar)
• Integridad referencial. Ésta merece un punto aparte que comentamos a continuación.
• …

Ya está, ya tenemos todo esto, pero aun queda algo más. ¿Es compatible la carga de datos con la integridad referencial del nuevo sistema?

Esta pregunta es uno de las mayores preocupaciones en cada migración. Para cargar clientes, previamente ha debido ser cargada otras tablas maestras (países, provincias, formas de pago, …), bien por el propio proceso de migración o de forma manual por el cliente. Para cargar facturas, previamente han debido ser cargados los clientes, las formas de pago, los artículos, etc. Y así sucesivamente con la mayoría de tablas, donde cobra especial relevancia el orden en que deben ser cargadas.

Si esta carga adicional se hace durante el mismo proceso de migración, el coste se multiplica. Ahora bien, si lo dejamos en manos del cliente para que lo haga mediante carga manual, y a pesar de poner suficiente énfasis en la importancia de hacerlo bien, puede incurrir en errores al obviar algunos registros, recodificar datos, etc. En este caso, lograr que la carga automática no provoque errores de integridad referencial, es cuanto menos, imposible.

En definitiva, dimensionar un proyecto de migración, solo puede hacerse «haciéndolo». Es decir, es imposible cuantificarlo con un grado suficiente de certeza debido a todos los factores antes mencionados. Solo conociendo todos los detalles anteriores podría cuantificarse de una forma suficientemente precisa el coste de la migración, solo que llegados a ese punto, el esfuerzo ya está realizado a un 90%.

En mi vida profesional he realizado múltiples migraciones, unas con mayor éxito y otras siendo un rotundo fracaso. El cliente tiende a pensar que una migración es el proceso de darle a un botón y replicar los datos de un sistema a otro, sin embargo, hay que convencerle de la complejidad que supone estos procesos entre sistemas que «hablan distintos idiomas», y que no siempre es aconsejable realizar algunas migraciones, para evitar ciertas herencias nada aconsejables del sistema anterior. En este aspecto, es por tanto, mejor ofrecer la migración como un proyecto aparte del proyecto de cambio del ERP, que haga entender cual es el verdadero esfuerzo de una migración.

Solo he hecho dos migraciones completas en mi vida. La primera hace muchos años y no sabría decir el tiempo que se dedicó. La última, hace un par de años, y requirió 2 desarrolladores a tiempo completo durante 2.5 meses. Estaba cotizada aparte, pero ni que decir tiene que el margen fue negativo.

(En el Master en Software Libre de Gestión: Open Source & ERP II, estamos analizando situaciones como la que aquí acabamos de mostrar).

Autor: Sergio Martínez

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly

Email