“¿Se supone que debemos migrar dos años de historial, verdad?” Esa es la pregunta que siempre me hacen, en relación a la migración de datos, los desconcertados gerentes de TI al comienzo de una implementación. Lo último que quieren es la temida respuesta de “Depende…” de los consultores. Pero si alguna vez ha habido una respuesta más verdadera, no la conozco. Hay muchos enfoques para la migración de datos, pero un enfoque altamente práctico me ha funcionado bien durante años. La pregunta con la que siempre comienzo es “¿El antiguo sistema desaparecerá el día que se ponga en marcha el nuevo sistema?” A veces la respuesta es legítimamente “sí”, ya sea porque es un sistema SaaS (en la nube) o porque la licencia se desactiva de alguna otra manera. Pero la gran mayoría de mis clientes responden “no”, y entonces entramos en lo que cariñosamente llamo “negociaciones de datos”.
Negociación de Datos 1 – Registros Maestros
Esta es la parte más fácil, por eso es la primera. Los registros maestros suelen consistir en proveedores, clientes, productos, empleados, cuentas de libro mayor (la lista no es exhaustiva). La mayoría de las veces necesitas estas cosas en tu nuevo sistema. Y la mayoría de las veces hay más de una docena de ellos, por lo que quieres exportarlos de tu antiguo sistema y llevarlos al nuevo. Claro, hay mucha discusión sobre “¿Deberíamos mantener esos terribles números de clientes antiguos o darles nuevos y brillantes?” y discusión sobre si migrar registros maestros que no se han utilizado durante media docena de años. Pero esta es la parte más fácil porque necesitas proveedores, clientes, productos, etc. para dirigir tu negocio. Simple. Los importamos.
Negociación de Datos 2 – Registros de Soporte
Ahora estamos empezando a complicarnos un poco. Los registros de soporte incluyen almacenes, ubicaciones de inventario, condiciones de pago, precios de compra, códigos de pago, etc. Esta lista es larga, y los registros de soporte en tu antiguo sistema probablemente no se mapean de manera simple 1:1 la mayor parte del tiempo. Pero la buena noticia es que aunque la lista en sí es larga, la carga de entrada de datos de estos elementos probablemente sea bastante ligera en comparación con los registros maestros. Así que a menos que tengas mil almacenes (y es posible que los tengas), la mayoría de estos elementos son buenos candidatos para la entrada manual en una “plantilla dorada” (la versión del software utilizada para copiar de un entorno a otro con muchas configuraciones agradables completadas). Un poco más complicado porque hay mucha variedad, módulos, etc. aquí, pero aún relativamente sencillo porque tenemos una regla general. Ingrésalos a menos que haya muchos.
Negociación de Datos 3 – Transacciones Abiertas/Actuales
Esta se trata de la eficiencia de la conversión. Las transacciones abiertas serían cosas como pedidos de venta no enviados o parcialmente enviados, trabajo en proceso de producción, facturas de proveedores impagas, costos/cantidades de inventario disponibles o saldos de cuentas de libro mayor del año en curso. La migración de datos puede ser fácil o difícil dependiendo de una infinidad de factores. Uno que me viene a la mente es el mapeo masivo de datos. Si estás cambiando sustancialmente la estructura de tus artículos de inventario, puede ser un verdadero dolor construir una traducción en las herramientas de conversión de datos para decirle al sistema cómo traducir los antiguos números de artículos en los nuevos. En ese caso, si solo tienes 100 pedidos de venta abiertos con un promedio de diez líneas cada uno, podría tener sentido dedicar un fin de semana a ingresar esos datos para el cambio. Por otro lado, si tus artículos no han cambiado mucho o en absoluto y tienes 1,000 pedidos abiertos, vale la pena el esfuerzo de poder construir la importación con anticipación y simplemente presionar el botón en el momento de la puesta en marcha. Otro factor a considerar es dónde están los cuellos de botella en el proyecto. Si tu gerente de TI también es tu gerente de proyecto Y la persona encargada de la migración de datos, es probable que esté un poco ocupado en el momento de la puesta en marcha. Por lo tanto, puede que no tenga sentido migrar cosas que son muy fáciles de ingresar, como los saldos de libro mayor, las facturas de proveedores abiertas, etc. Durante años, he enseñado a personas con poca o ninguna capacitación cómo ingresar esos datos y hacerlo. Puede llevar más tiempo en general, pero si puedes sentar al gerente de ventas, al CEO y a la recepcionista, en una habitación durante cuatro horas y hacer que ingresen todos esos datos con solo quince minutos de instrucción, puede ser una gran victoria para ese gerente de TI crítico y limitado. Nuestra regla general aquí es evaluar el volumen y la complejidad para determinar si importar o ingresar manualmente.
Negociación de Datos 4 – Historial
Y ahora finalmente surge la pregunta del historial. Esta es la más complicada porque a menos que el antiguo sistema desaparezca de inmediato, tiene que haber una muy buena razón comercial para migrar los datos. ¿No es suficiente con que el director financiero diga “Debes tener dos años de historial financiero”? Probablemente no. El criterio para el historial es “¿Impedirá que el negocio pueda operar? Si es así, ¿cuáles son las alternativas?” Veamos algunos ejemplos divertidos. El historial de saldos mensuales del libro mayor es el más fácil. Empecemos por ahí. Yo: “¿Por qué lo necesitamos?” Director financiero: “Informes financieros comparativos.” Yo: “¿Es tenerlo en el sistema la única forma de lograr eso? No.” Director financiero: “¿Cómo más podríamos hacerlo?” Yo: “Bueno… podrías hacer que tu asistente del controlador exporte los informes financieros a Excel y ponga manualmente la comparación del año anterior durante un año después de la puesta en marcha (doce veces).” Director financiero: *se atraganta en silencio* Sé que esto suena desagradable, pero es un ejemplo importante de una pregunta comercial. ¿El costo de que el asistente del controlador haga eso doce veces es mayor que el costo de la consultoría y el tiempo de TI para migrar esos datos? ¿Hay un riesgo comercial al tener ese proceso como manual en lugar de algo que esté en el sistema? Soy una persona de software; mi cerebro dice: “¡Por favor, por favor, por favor, ponlo en el software donde pertenece!” Pero no siempre tiene sentido comercial. Hagamos otro ejemplo. Detalle de transacciones del libro mayor. Los mismos actores. Yo: “¿Por qué lo necesitamos?” Director financiero: “Porque tal vez necesitemos buscar algo algún día.” Yo: “¿Es tenerlo en el nuevo sistema la única forma de lograr eso? No.” Director financiero: “Ok. Creo que ya te entiendo. Me vas a decir que lo busque en el antiguo sistema, ¿verdad?” Yo: *pulgar arriba* A menos que tus auditores, un gobierno u otra autoridad te exijan migrar el historial de transacciones del libro mayor O tu antiguo sistema desaparezca, generalmente hay muy poca ganancia comercial en migrar ese tipo de historial. Ok. Último ejemplo, lo prometo. Historial de ventas. Este es el mejor (o peor, dependiendo de cómo lo veas). Observa los nuevos actores y la audiencia más amplia. Yo: “¿Por qué lo necesitamos?” Gerente de compras: “¡Porque nuestro equipo de compras mira lo que vendimos el año pasado y hace un montón de cálculos complicados para decidir qué comprar TODOS LOS DÍAS!” Yo: “¿Sabes lo que voy a decir, verdad?” Gerente de compras: “Sí, sí, eso se puede hacer fuera del sistema. Pero eso serán 1,825 días de miseria durante los próximos cinco años al combinar todos esos


