Solo lectura, siempre
Nada de lo que montemos escribe en ninguno de los dos ERP durante la transición. Ni un registro.
Migración · Continuidad del dato
Migrar de ERP sin quedarte ciego.
Durante una migración la información de gestión queda partida en dos: el histórico en el sistema que se apaga y la operación en el que arranca. Justo cuando más falta hace comparar, deja de poder hacerse. Se puede leer de ambos mientras dura la transición, y hay una tarea que solo puede hacerse ahora.
EL PLAN Y EL HUECO
Todo el proyecto mira al go-live. El día siguiente no lo mira nadie.
Una migración de ERP se planifica con cuidado. Alcance, maestros, saldos de apertura, parametrización, pruebas, formación, fecha de arranque. El partner sabe hacer eso y normalmente lo hace bien.
Lo que casi nunca aparece en el plan es qué pasa con la información de gestión durante los meses de convivencia y en los meses siguientes al arranque. No es mala suerte ni descuido del partner: no está en su alcance. Su entregable es un ERP funcionando, y un ERP funcionando no es lo mismo que una empresa que puede seguir comparando.
QUÉ SE MIGRA Y QUÉ NO
Se migran saldos y maestros. La serie histórica se queda.
En la práctica totalidad de las migraciones se llevan al sistema nuevo los maestros (clientes, artículos, proveedores) y los saldos de apertura. El histórico de movimientos se queda en el sistema viejo, y con buen criterio: arrastrarlo cuesta más de lo que aporta y ensucia el arranque.
Hay una segunda cosa que pasa siempre y se subestima más. La migración es la ocasión en la que por fin se limpian los maestros. Se reagrupan familias, se renumeran artículos, se unifican clientes duplicados, se rehace el plan de cuentas. Es lo correcto y hay que hacerlo.
También significa que el artículo 4471 de antes y el 4471 de ahora no son la misma cosa, y que la familia que en un sistema se llamaba de una manera en el otro está repartida en tres.
LO QUE SE PIERDE
No se pierden los datos. Se pierde la comparación.
Los datos siguen ahí. Lo que desaparece es la posibilidad de poner un mes al lado del otro.
El primer mes después del arranque alguien pide comparar contra el mismo mes del año pasado, y descubre que esa comparación vive en un sistema que ya nadie abre, con códigos que además cambiaron. A partir de ahí la empresa entra en un periodo de entre seis y doce meses sin capacidad de comparar contra el año anterior.
Ese periodo coincide con el momento en que más falta hace, y por una razón que no es obvia: es cuando hay que comprobar si el sistema nuevo está registrando bien. Cuando un número del ERP nuevo no cuadra con lo que la dirección recuerda, sin la serie histórica no hay forma de saber si el error está en el dato, en la parametrización o en el recuerdo. La discusión se convierte en una cuestión de quién tiene más autoridad en la sala.
CÓMO SE EVITA
Una capa de lectura sobre los dos sistemas, montada antes del arranque.
Técnicamente no tiene misterio y conviene decirlo así: se replica fuera de los dos ERP, en modo solo lectura, lo que la gestión necesita. Del sistema viejo, el histórico. Del nuevo, la operación desde el arranque. Encima se define una vez qué significa cada métrica y se responde con esa definición, sin importar de qué sistema salga cada fila. Es la arquitectura de datos con la que trabajamos siempre, aquí aplicada a una transición.
Tres condiciones para que esto no interfiera con la migración, que es la prioridad y no se toca.
Fuera del ERP
La réplica vive en su propia infraestructura, así que las consultas de gestión no compiten por recursos con el sistema que el equipo está probando y poniendo a punto.
Sin consumir al equipo
Si esto le quita horas a la gente que está migrando, sale mal y además retrasa el go-live. El único tiempo que pedimos es el de las decisiones de maestros que ya se están tomando.
LA TAREA CON FECHA
El mapeo entre el maestro viejo y el nuevo caduca.
Esta es la parte con fecha de caducidad, y la razón de escribir sobre esto antes del arranque y no después.
La persona que sabe que la familia de aberturas pasó a llamarse carpintería, que tres clientes duplicados se unificaron en uno y que dos códigos de artículo se fusionaron está en el proyecto hoy, con eso fresco. Dentro de un año esa persona ya no está en el proyecto, o está y no se acuerda, y reconstruir el mapeo cuesta mucho más que anotarlo mientras se decide.
Ese mapeo no se tira cuando termina la migración. Escrito una vez, es la definición común de la empresa: qué es un cliente, qué entra en cada familia, cómo se llama cada cosa. Sobrevive al sistema que lo originó y sirve para el siguiente que entre, que entrará.
Preguntas frecuentes
Lo que suele preguntarse durante una migración.
¿No conviene esperar a que la migración termine?
Esperar es lo habitual y es lo que produce el hueco. Después del arranque el histórico está en un sistema apagado y el conocimiento del mapeo se ha dispersado. El trabajo se puede hacer más tarde; cuesta más y sale peor.
¿Esto no interfiere con el proyecto del partner?
No debería, y por eso las tres condiciones: solo lectura, infraestructura aparte y sin consumir horas del equipo de migración. Lo que sí conviene es que el partner sepa que existe, para que nos avise de los cambios de maestros según los va decidiendo.
Ya arrancamos hace meses. ¿Sirve igual?
Sirve, con más trabajo. Se puede reconstruir el mapeo a partir de los maestros de ambos sistemas y de lo que recuerde el equipo, y recuperar la serie con las equivalencias que se puedan justificar. Lo que no se recupera es lo que nadie anotó y ya nadie recuerda.
El ERP nuevo trae su propio módulo de análisis. ¿No basta?
Ese módulo ve lo que hay dentro del ERP nuevo, que es precisamente lo que no incluye el histórico ni lo que vive en el CRM, el WMS o las hojas de cálculo. Para la operación del día a día está bien. Para comparar contra el año pasado, no puede.
Relacionado: Cuándo tiene que llegar un dato para que sirva · Ver el mes antes del cierre del mes · El mejor controller es el que no tiene que buscar los números · Seguridad y datos.
Encaje
Para qué proyectos encaja. Y para cuáles no.
Encaja bien si
- Tienes una migración de ERP en marcha, con fecha de go-live puesta.
- El histórico de movimientos se queda en el sistema que vas a apagar.
- Estáis reagrupando familias, renumerando artículos o unificando clientes.
- Dirección compara contra el año anterior y no piensa dejar de hacerlo.
Probablemente no lo necesitas si
- Vas a migrar el histórico completo de movimientos al sistema nuevo.
- Los códigos y las agrupaciones se mantienen idénticos en ambos sistemas.
- Ya tienes un almacén de datos fuera del ERP con la serie histórica cargada.
- Lo que buscas es ayuda con la migración en sí: eso lo hace tu partner, no nosotros.
El primer lunes después del arranque, cuando pregunten si vamos mejor que el año pasado, ¿con qué se responde?
En 30 minutos revisamos qué se queda en el sistema viejo, qué cambia en los maestros y qué hace falta para no perder la serie.
Reservar diagnóstico de 30 minutos