Migración
¿Se puede cambiar de ERP sin perder el histórico de lecturas?
·9 min de lectura
Sí se puede, y el histórico es de lo primero que hay que mover, no de lo último. La razón es poco obvia: una lectura sola no significa nada — sólo vale contra la anterior.
El dato que casi nunca se migra a tiempo
En una migración de ERP todo el mundo se acuerda de los clientes, de los equipos y de los contratos. El histórico de lecturas se deja «para después», porque parece información de consulta.
No lo es. Y la razón es aritmética:
«Este equipo marca 482,300 páginas» no dice cuánto se imprimió. El consumo del periodo es esa lectura menos la anterior. Sin la anterior, no hay consumo; sin consumo, no hay excedente; sin excedente, no hay factura.
Por eso la primera factura del sistema nuevo depende del último dato del sistema viejo. Si el histórico entra después de empezar a facturar, el primer periodo sale mal en todo el parque a la vez, y corregirlo hacia atrás es bastante más caro que haberlo traído antes.
El orden que sí funciona
- Clientes y sedes. Con las direcciones reales, porque de ahí cuelga después el servicio en campo.
- Equipos, por número de serie. La serie es la llave de todo lo demás. Si viene con errores de captura, todo lo que se pegue encima hereda el error.
- Contratos, con su volumen incluido, su precio de excedente y sus fechas de corte — que no son iguales para todos.
- Histórico de lecturas, colgado de cada serie. Ahora sí tiene dónde pegarse.
- Saldos contables, por corte y no reconstruyendo el pasado. Eso tiene su propio procedimiento, distinto del de las lecturas.
Invertir el orden no es un detalle de estilo: una lectura sin equipo al cual pegarse simplemente no se puede cargar, y un contrato sin cliente tampoco.
Cuánto histórico traer, de verdad
| Cuánto | Qué habilita |
|---|---|
| La última lectura de cada equipo | El mínimo indispensable: sin ella no se puede facturar el primer periodo |
| 12 meses | Juzgar si una lectura nueva es creíble, y ver la tendencia de consumo del cliente |
| 24 meses | Rentabilidad por equipo con estacionalidad, y renegociar contratos con datos |
| Todo lo que exista | Normalmente más trabajo que beneficio, salvo que haya un litigio o una auditoría de por medio |
Por qué el histórico también sirve para no equivocarse
Hay un segundo uso del histórico que se descubre tarde: sirve para juzgar la lectura nueva. Un equipo que llevaba dos años imprimiendo entre 4,000 y 6,000 páginas al mes y de pronto reporta 61,000 no está imprimiendo doce veces más: casi siempre es un contador reiniciado, un dígito de más al teclear, o una lectura que quedó asignada al equipo equivocado.
Sin histórico no hay manera de sospecharlo, y esa lectura se convierte en una factura que el cliente va a rechazar. Con histórico, el sistema la detiene antes.
Hay un efecto secundario que conviene conocer: los errores de lectura rara vez vienen solos. Si el periodo anterior quedó mal cerrado, el siguiente hereda el arranque equivocado, y el siguiente también. Lo que parecen treinta anomalías sueltas suele ser una sola, repetida hacia adelante. Por eso se revisan en cadena y en orden, y no de una en una.
Lo que de verdad no se recupera
Los datos se migran. Lo que no se migra es lo que nunca estuvo escrito:
- el acuerdo verbal con un cliente de que a él no se le cobra cierto excedente;
- el criterio con el que alguien decidía qué lectura rara se aprobaba y cuál no;
- la razón por la que ese contrato tiene un precio distinto al de todos los demás.
Nada de eso está en la base de datos del sistema anterior. La migración es un buen momento para escribirlo, porque es el único momento en que alguien está obligado a mirar cada contrato de frente.
El paralelo: útil, y con fecha de término
Correr un periodo completo en los dos sistemas es la forma más honesta de comprobar que el nuevo llega al mismo número que el viejo. Dos recomendaciones prácticas:
- Hazlo con los contratos difíciles, no con los fáciles. Los fáciles siempre cuadran y no prueban nada.
- Ponle fecha de término desde el principio. Dos sistemas vivos durante meses acaban con dos verdades, y decidir cuál manda se vuelve una discusión en lugar de un hecho.
La comparación tiene que ser contra el número final facturado, equipo por equipo. Que los totales del mes coincidan no prueba nada: dos errores en sentido contrario se cancelan y el total se ve perfecto.
Preguntas frecuentes
¿Se pierde el histórico de lecturas al cambiar de ERP?
No tiene por qué perderse, pero sí se pierde a menudo, por una razón evitable: se migra al final, cuando ya se está facturando en el sistema nuevo. El histórico debe entrar antes que la primera factura, porque el excedente del primer periodo se calcula contra la última lectura del sistema viejo.
¿Por qué importa tanto la lectura anterior?
Porque una lectura sola no significa nada. «Este equipo marca 482,300 páginas» no dice cuánto se imprimió: eso sale de restarle la lectura previa. Sin el dato anterior no hay consumo, no hay excedente y no hay forma de saber si la lectura nueva es creíble.
¿En qué orden se migra?
Clientes y sedes, luego equipos por número de serie, luego contratos, y sólo entonces el histórico de lecturas —que se cuelga de la serie— y los saldos contables por corte. Invertir el orden obliga a rehacer trabajo: una lectura sin equipo al cual pegarse no se puede cargar.
¿Cuánto histórico hace falta traer?
Como mínimo, la última lectura de cada equipo: sin ella no se puede facturar el primer periodo. Para que sirva de algo más —juzgar anomalías, ver tendencia de consumo, calcular rentabilidad— conviene de doce a veinticuatro meses. Traer diez años suele ser más trabajo que beneficio.
¿Qué es lo que de verdad no se puede recuperar después?
Lo que nunca estuvo escrito: los acuerdos verbales con clientes, las excepciones que alguien recordaba y el criterio con el que se aprobaban lecturas raras. Eso no está en ninguna base de datos del sistema viejo, y si la persona que lo sabía se va antes de la migración, se fue con ella.
¿Hay que correr los dos sistemas en paralelo?
Un periodo completo en paralelo es la forma más segura de comprobar que el sistema nuevo llega al mismo número que el viejo, y conviene hacerlo con los contratos más complicados, no con los fáciles. Lo que no conviene es dejarlo abierto: dos sistemas vivos mucho tiempo terminan con dos verdades distintas.
Esto es lo que SUMI hace todos los días.
En una demo de 30 minutos lo vemos con tu operación: tus contratos, tus lecturas y tu cierre de mes.