Una fecha de carga no equivale a un plan de migración. Antes de comprometerla, conviene poder responder a tres preguntas: qué datos deben llegar al nuevo ERP, quién decidirá cómo prepararlos y quién tendrá disponibilidad para validarlos. Si alguna respuesta sigue abierta, hagámosla visible en la planificación, en lugar de darla por resuelta.
Para responsables de proyecto, dirección de sistemas y equipos de negocio, proponemos abordar la migración desde esas decisiones. No se trata de exigir certeza absoluta al inicio, sino de distinguir el trabajo que ya puede estimarse de aquel que depende de una regla, una responsabilidad o una disponibilidad todavía por confirmar.
La práctica ERP de OLING se centra en la definición inicial, la dirección y la estructuración de proyectos. Su enfoque consiste en delimitar el alcance y los retos, organizar los talleres y formalizar la hoja de ruta y los entregables antes de ampliar la intervención. Las orientaciones que siguen aplican ese marco de gobierno al trabajo de migración de datos; no constituyen una metodología técnica de ejecución.
Definir el alcance desde el uso futuro de los datos
«Migrar los datos» es un enunciado demasiado amplio para aprobar una carga de trabajo. Como punto de partida, recomendamos examinar cada conjunto de datos desde su uso en el sistema de destino, no solo desde su existencia en el sistema actual.
El primer taller debería permitir responder a estas cuestiones:
- Uso: ¿qué proceso necesitará estos datos en el nuevo ERP y qué área puede explicar esa necesidad?
- Selección: ¿qué información se propone trasladar y cuál quedaría fuera, sujetando esa decisión a la revisión de las necesidades de consulta y conservación?
- Preparación: ¿qué reglas de corrección o transformación deben acordarse antes de ejecutar el trabajo?
- Aceptación: ¿qué se comprobará y quién podrá dar la conformidad o solicitar correcciones?
Una matriz sencilla puede servir de soporte: conjuntos de datos en las filas; uso, responsable, decisión pendiente y criterio de aceptación en las columnas. Conviene leerla primero por sus huecos. Donde falte un responsable o un uso acordado, registremos una cuestión por resolver, no una fecha definitiva.
Evitemos tanto el «migrarlo todo» por defecto como la exclusión apresurada de información. Para cada elección, pidamos una justificación y dejemos constancia de las comprobaciones adicionales que exige. El objetivo inicial es disponer de un alcance argumentado, aunque algunos elementos sigan siendo provisionales.
Estimar el trabajo, pero también la disponibilidad
Para anticipar el esfuerzo, recomendamos separar las tareas técnicas de las decisiones y comprobaciones del negocio, manteniéndolas en un mismo plan. Además de identificar quién realizará la carga, hay que acordar quién podrá explicar una excepción, aprobar una correspondencia o revisar el resultado.
Un desglose inicial puede contemplar cinco bloques:
- Examinar los datos disponibles y documentar las dudas sobre su significado y uso.
- Acordar las reglas de selección, corrección y correspondencia con el modelo de destino.
- Preparar las extracciones, transformaciones y cargas previstas.
- Organizar las comprobaciones técnicas y la validación de las áreas de negocio.
- Reservar capacidad para resolver incidencias, tratar excepciones y repetir pruebas.
Para cada bloque, conviene indicar quién ejecuta, quién decide, qué debe estar resuelto antes y qué disponibilidad se está suponiendo. No demos por equivalentes el esfuerzo estimado y el plazo comprometido. Antes de asignar fechas, contrastemos la dedicación prevista con las personas implicadas.
Cuando una tarea dependa de una decisión funcional pendiente, presentemos su estimación como provisional y expliquemos la condición. Por ejemplo, si todavía no se ha acordado una regla de selección, no cerremos como definitivo el trabajo de preparación asociado. El comité de proyecto debería poder distinguir lo estimado, lo condicionado y lo pendiente de análisis.
Utilizar los talleres para cerrar decisiones, no solo para recoger dudas
OLING identifica entre las dificultades recurrentes de los proyectos ERP una gobernanza insuficientemente clara y una mala sincronización de las decisiones funcionales y organizativas. También señala dos puntos de atención: la subestimación de los impactos organizativos y la dispersión de las decisiones funcionales.
En la migración, proponemos traducir esa vigilancia en talleres con decisiones concretas que tomar. Ante registros que podrían representar una misma entidad, por ejemplo, la discusión puede centrarse en qué criterio se propone aplicar, quién tiene autoridad para aprobarlo y cómo se comprobará su aplicación. Es una cuestión de trabajo que debe resolverse en contexto, no una regla universal de depuración.
La síntesis del taller debería separar con claridad lo acordado de lo pendiente. Para cada asunto abierto, registremos quién coordinará su resolución, qué información falta y cuándo deberá volver a examinarse. Haber debatido una cuestión no equivale a haberla resuelto.
La práctica ERP de OLING recoge como factores de éxito una gobernanza compartida entre negocio y sistemas y la formalización rápida de las decisiones. Para aplicar ese principio, recomendamos documentar también sus consecuencias: qué cambia en el alcance, qué trabajo queda autorizado y qué debe revisarse en el plan.
Asignar una función concreta a cada entregable
Los entregables habituales de la práctica ERP de OLING son el documento de definición inicial, la síntesis de talleres y la hoja de ruta de despliegue. Para la migración de datos, proponemos darles funciones complementarias, evitando que sean tres versiones de la misma información.
Documento de definición inicial: establecer la base de trabajo
Debería recoger el alcance propuesto, las responsabilidades, las hipótesis de esfuerzo y las condiciones de aceptación que deban acordarse. Su función sería dejar claro sobre qué base se planifica y qué cuestiones permanecen abiertas.
Síntesis de talleres: conservar las decisiones
Conviene registrar las reglas examinadas, los acuerdos, las excepciones y los asuntos pendientes. Para una decisión relevante, incluyamos quién la valida y qué consecuencias tiene, de modo que pueda consultarse sin reconstruir toda la conversación.
Hoja de ruta: ordenar el trabajo y sus condiciones
Además de fechas, recomendamos indicar dependencias, participación requerida y condiciones previas a cada hito. Antes de programar una validación del negocio, acordemos qué se revisará, con qué criterio y quién podrá aceptar el resultado o pedir correcciones. La reunión puede figurar en la agenda; la capacidad para decidir debe confirmarse aparte.
Si hay que acelerar, explicitar qué se cambia
OLING contempla intervenciones de definición inicial, reanudación o aceleración de proyectos ERP. En un proyecto ya iniciado, proponemos comenzar la revisión de la migración contrastando el alcance aprobado con el trabajo que se está solicitando realmente a los equipos.
Antes de comprimir el calendario, conviene comprobar si siguen vigentes las hipótesis: ¿se mantiene el alcance?, ¿se han formalizado las reglas pendientes?, ¿está confirmada la disponibilidad de quienes validan?, ¿qué trabajo se plantea aplazar y con qué consecuencias?
Si aparece una nueva necesidad, hagamos explícita la decisión entre incorporarla, secuenciarla o revisar el plan. No tratemos una ampliación del alcance como un simple ajuste técnico. Del mismo modo, no demos por resueltos los cambios de proceso mediante la elección del ERP: revisemos las responsabilidades y las formas de trabajo previstas para su uso.
El punto de atención no es únicamente cuánto tiempo se quiere ganar, sino qué condiciones se modifican para hacerlo. Cualquier revisión debería permitir reconocer qué se mantiene, qué se aplaza y qué necesita una nueva validación.
Antes de comprometer la fecha, acordar la base del compromiso
Para iniciar el trabajo, recomendamos reunir a sistemas, proyecto y negocio alrededor de tres elementos: un alcance provisional de datos, una lista de decisiones abiertas y una primera hipótesis de dedicación por función. No hace falta presentarlos como definitivos; sí conviene indicar quién los confirmará y qué falta para hacerlo.
Si la migración todavía ocupa una única línea en el plan, el siguiente paso es desglosarla en decisiones, responsabilidades y trabajo verificable. Desde su práctica ERP, OLING estructura la definición inicial, los talleres y la hoja de ruta antes de ampliar la intervención. Ese marco ofrece un punto de partida para conversar sobre qué puede comprometer el proyecto y qué requiere revisión previa.