Gobierno de datos maestros en el kickoff de S/4HANA: checklist
Checklist de preparación para el PMO y el sponsor: qué debe demostrar el gobierno de datos maestros antes del kickoff de S/4HANA y qué hacer con cada brecha.
El gobierno de datos maestros está listo para el kickoff de un proyecto S/4HANA cuando cada punto crítico puede respaldarse con una evidencia: roles nombrados por objeto, una política mínima aprobada, un foro de decisión con plazos, una línea base de calidad medida y un criterio de calidad por objeto para pasar de fase. Lo que no esté listo no tiene por qué retrasar el proyecto, pero necesita responsable y fecha antes de los talleres de Explore.
Es habitual que el kickoff de un proyecto S/4HANA llegue con cronograma, plan de comunicación, matriz de riesgos y equipo asignado, y ni una línea sobre quién decide sobre los datos. La presentación muestra las fases, los workstreams y las fechas de las cargas de prueba. Cuando alguien pregunta quién aprobará el estándar de descripción de materiales, la respuesta suele ser "eso lo vemos en Explore".
Ya en Explore, el taller de compras se detiene porque nadie en la sala puede decir si un campo es obligatorio. El consultor propone un estándar, el área lo acepta para no frenar el avance, y tres meses después la primera carga de prueba vuelve con errores en buena parte de los proveedores. La conversación pasa a ser "los datos del cliente están mal", cuando lo que faltó fue una decisión tomada antes por alguien con autoridad para tomarla.
¿Qué prevé SAP Activate para los datos maestros?
SAP Activate, la metodología de implementación de SAP, organiza el proyecto en workstreams. Según SAP Learning, uno de los workstreams sugeridos es Data Management, que abarca la carga, la limpieza y la gestión del ciclo de vida de los datos, con tres subflujos: Data Migration, Data Volume Management y Master Data Management. El objetivo descrito para Master Data Management es una alta calidad de los datos, su unificación y su gestión eficiente (SAP Learning, Discovering the Workstreams).
La misma lección describe, dentro del workstream Project Management, el Signoff: cómo verificar si el proyecto está listo para avanzar (los Q-Gates) y con qué criterios. También presenta el gobierno del proyecto como el marco en el que el jefe de proyecto y los sponsors toman decisiones, lo que incluye establecer roles, responsabilidades y autoridades de gobierno y decidir escalamientos; quien establece ese gobierno debe identificar a las personas clave que formarán parte de él. La lección habla de gobierno del proyecto y no utiliza el término "gobierno de datos". Por eso el checklist de este artículo es una recomendación para encajar el gobierno de datos maestros en ese esquema, no una exigencia de la metodología.
Un punto de la lección explica por qué los nombres deben existir pronto. En la tabla de roles del proyecto por workstream, la fila Data Management incluye, del lado del cliente (negocio), Business Data Owner (que SAP describe como data custodian), Data Preparation Expert, Master Data Change Requestor, Master Data Maintainer y Master Data Sponsor; del lado del cliente (TI), Data Extraction Expert, DVM ALM Process Owner y Master Data Manager (descrito como data steward); y, del lado del socio implementador, Data Migration Architect, Data Migration Developer y Data Volume Management Consultant. Estos nombres de SAP no corresponden uno a uno a los roles de owner y steward descritos en el artículo sobre quién es el data owner y quién es el data steward, y cada empresa ajusta la nomenclatura. Entre los órganos de gobierno del proyecto, el nivel 3 incluye un Integrating Committee, que toma decisiones sobre integración y gestión de datos maestros entre proyectos (SAP Learning, Discovering the Workstreams). Si la propia SAP enumera roles de datos maestros del lado del cliente, tiene sentido que tengan nombre antes del kickoff.
¿Cómo saber si el gobierno de datos maestros está listo para el kickoff?
La pregunta útil para el PMO y el sponsor es: ¿qué existe ya y se puede mostrar? Una respuesta del tipo "lo estamos alineando" no cuenta. Cada punto necesita una evidencia que alguien pueda abrir: una lista firmada, un acta, un informe con fecha.
Paso 1: enumere los objetos en alcance
Material, proveedor, cliente, servicio, activo. El checklist se aplica por objeto, porque uno puede estar listo y otro no. Es habitual que el material tenga un responsable claro y que el cliente no tenga a nadie.
Paso 2: pida la evidencia de cada punto
Use la tabla siguiente. Para cada fila y cada objeto, marque "existe" o "no existe". Evite el "en curso": o la evidencia está lista, o el punto queda como pendiente con responsable y fecha.
Paso 3: decida qué hacer con cada brecha
No toda brecha retrasa el kickoff. La columna "Si no está listo" ofrece una salida para cada punto y su plazo límite, que casi siempre es el final de Prepare o el inicio de los talleres de Explore.
Paso 4: lleve el resultado al foro de decisión del proyecto
Los pendientes se convierten en tareas del plan del proyecto, con responsable, fecha y seguimiento en el mismo foro que trata riesgos y alcance. Así entran en la conversación del Q-Gate en lugar de aparecer en la primera carga de prueba.
Checklist de preparación del gobierno de datos maestros
| Punto | Evidencia que lo demuestra | Quién la aporta | Riesgo si falta | Si no está listo |
|---|---|---|---|---|
| Roles nombrados por objeto | Lista con el nombre del data owner y del data steward de cada objeto en alcance, validada por el sponsor | Sponsor y directores de las áreas de negocio | Las decisiones sobre datos quedan en manos del consultor o de TI; los talleres no tienen quién responda por el negocio | Nombrar un responsable interino por objeto antes del final de Prepare, con fecha para el titular |
| Política mínima aprobada | Documento breve, aprobado y publicado, con puntos como quién solicita un registro, quién lo aprueba, qué es un campo obligatorio y dónde está el estándar de cada objeto | Líder de datos maestros, con aprobación del sponsor | Cada equipo del proyecto crea sus propias reglas y se contradicen | Aprobar una versión mínima con lo que afecta a los talleres de Explore y registrar el resto con responsable y fecha |
| Foro de decisión con escalamiento y plazos | Registro de quién decide sobre los datos, en cuánto tiempo responde y a quién se escala un bloqueo | PMO y sponsor | Los pendientes de datos se acumulan y solo aparecen en las cargas de prueba | Usar el foro de gobierno del proyecto con un punto fijo de datos hasta que exista un foro propio |
| Estándares de datos por objeto | Estándar de descripción, campos obligatorios y reglas de llenado definidos, o con responsable y fecha para definirlos | Data owners, con apoyo de los data stewards | El estándar se decide con prisa en el taller, por quien esté en la sala | Listar los estándares abiertos, cada uno con responsable y fecha anterior al taller del objeto |
| Línea base de calidad medida | Informe con indicadores del sistema heredado por objeto (completitud, duplicados de material, vigencia de documentos de proveedores) y fecha de medición | Líder de datos maestros, con la extracción a cargo de TI | Nadie puede dimensionar la limpieza ni demostrar mejoras después | Medir al menos completitud y duplicados en los objetos principales durante Prepare |
| Criterio de calidad por objeto para pasar de fase y para las cargas de prueba | Criterio escrito por objeto, aceptado por el PMO como parte del Q-Gate del proyecto | PMO con los data owners | La carga se aprueba porque se ejecutó, no porque los datos sean correctos | Definir un criterio provisional antes de la primera carga de prueba y revisarlo con la línea base |
| Responsable del mapeo y de las reglas de transformación | Nombre del responsable por objeto y un único lugar donde se mantienen el mapeo de campos y las reglas | Data owners con el equipo de migración | Las reglas de conversión las decide quien escribe el programa de carga | Registrar el responsable de cada objeto antes del final de Explore |
| Regla para crear registros durante el proyecto | Decisión escrita: congelamiento a partir de una fecha o doble mantenimiento con responsable y control | Sponsor, operaciones y PMO | Los registros creados en el sistema heredado después de la última carga de prueba quedan fuera o entran sin tratamiento | Decidir antes de la primera carga de prueba y comunicarlo a las áreas que crean registros |
| Plan de gobierno para Run | Definición de quién mantiene cada objeto después del go-live, con flujo de solicitud y aprobación | Sponsor y líder de datos maestros | Los datos maestros vuelven a deteriorarse poco después del go-live | Incluirlo como entregable del proyecto, con responsable y fecha antes del cutover |
| Usuarios clave habilitados en conceptos de datos maestros antes de Explore | Agenda de la habilitación y lista de asistencia | PMO y líder de datos maestros | Los talleres dedican tiempo a explicar conceptos en lugar de decidir | Programar la habilitación al inicio de Explore, antes de los talleres Fit-to-Standard |
Tres observaciones sobre la tabla. Pide que los roles estén nombrados, no que la matriz de responsabilidades esté completa; para elegir quién es owner y quién es steward, consulte el artículo sobre data owner y data steward en datos maestros. La línea base pide pocos indicadores y una fecha; el cálculo de cada uno está en cómo medir la calidad de los datos maestros. Y la tabla no decide qué limpiar antes de la conversión; para los materiales, esa clasificación está en el artículo sobre el maestro de materiales antes de la conversión a S/4HANA.
¿Cómo se aplica el checklist en un caso concreto? (ejemplo hipotético)
Ejemplo hipotético, creado solo para ilustrar el uso del checklist. No es un caso de cliente y las cifras son ilustrativas.
Una empresa industrial va a iniciar un proyecto S/4HANA con tres objetos en alcance: material, proveedor y cliente. Tres semanas antes del kickoff, el PMO aplica el checklist con el sponsor.
- Material: tiene un data owner nombrado (el gerente de abastecimiento), un estándar de descripción definido y una medición de duplicados hecha el año anterior. Faltan el criterio de calidad para las cargas de prueba y la regla de creación de registros durante el proyecto.
- Proveedor: tiene steward, pero no se ha nombrado owner, porque compras y finanzas no se ponen de acuerdo sobre quién responde. No hay línea base de documentos vencidos ni de datos registrales que no coinciden con los registros oficiales.
- Cliente: no existe ninguno de los puntos.
En este recuento hipotético, la mayoría de las 30 combinaciones (10 puntos por 3 objetos) queda como "no existe". El sponsor no aplaza el kickoff. Nombra un owner interino para proveedor y otro para cliente, aprueba una política mínima de una página, establece que el foro del proyecto tendrá un punto fijo de datos con cinco días hábiles de plazo para decidir y convierte la línea base de proveedor y cliente en un entregable de Prepare. Las demás brechas reciben responsable y fecha antes de los talleres de Explore.
Lo que sale de la reunión es una lista corta de brechas, cada una con su responsable, que el PMO sigue como cualquier otro riesgo del proyecto.
Por dónde empezar
- Enumere los objetos de datos maestros en el alcance del proyecto y, para cada uno, quién crea, modifica y aprueba los registros hoy.
- Aplique la tabla anterior con el PMO y el sponsor, objeto por objeto, marcando solo "existe" o "no existe".
- Mida la línea base de los objetos principales antes del kickoff, aunque sea con dos o tres indicadores.
- Convierta cada brecha en una tarea del plan del proyecto, con responsable y fecha anterior a los talleres de Explore.
- Si clientes y proveedores están en el alcance, revise también los puntos sobre datos maestros de Business Partner en S/4HANA, para que el estándar llegue listo a los talleres.
- Para entender cómo encajan la migración y el saneamiento en las fases del proyecto, consulte la página de migración de datos a SAP S/4HANA.
Preguntas frecuentes
¿Se puede iniciar el proyecto sin que el gobierno de datos maestros esté listo?
Sí, siempre que las brechas sean visibles y cada una tenga responsable y fecha. El riesgo está en empezar sin saber qué falta. La recomendación es cerrar los puntos que afectan a los talleres (roles, foro de decisión y estándares por objeto) antes del final de Prepare, y los puntos de calidad (línea base y criterio por objeto) antes de la primera carga de prueba.
¿Quién debe ser el sponsor del gobierno de datos en el proyecto?
Alguien con autoridad sobre las áreas que crean y usan los datos, además de TI. En muchos proyectos tiene sentido que sea el propio sponsor del proyecto, que ya arbitra los conflictos entre áreas. Lo que no funciona es dejar el rol en manos del jefe de proyecto del socio implementador, que no responde por el negocio después del go-live.
¿Necesito SAP MDG para tener gobierno de datos maestros en S/4HANA?
Los puntos del checklist son decisiones sobre roles, reglas y criterios, y ninguno depende de una herramienta específica. La elección de la herramienta viene después de esas decisiones. Para comparar alternativas, consulte el artículo sobre SAP MDG o un MDM complementario.
¿El gobierno de datos es lo mismo que el gobierno del proyecto?
No. En SAP Learning, el gobierno del proyecto es el marco en el que el jefe de proyecto y los sponsors toman decisiones, con roles, responsabilidades, autoridades y escalamiento del proyecto. El gobierno de datos maestros responde quién decide sobre los datos, con qué reglas y con qué criterio de calidad, y continúa después del go-live. Ambos se encuentran en el foro de decisión y en el Q-Gate; por eso el checklist sugiere usar el foro del proyecto mientras no exista uno propio.
¿Qué cambia entre greenfield y brownfield para el gobierno de datos?
Los puntos del checklist valen en ambos casos; cambia dónde está el peso. Cuando se convierte el sistema actual, los datos maestros existentes siguen con el proyecto, así que la línea base y la decisión sobre qué limpiar antes pesan desde el principio. Cuando los datos vienen de uno o varios sistemas heredados hacia un entorno nuevo, el mapeo de campos, las reglas de transformación y los estándares de destino exigen más atención. Confirme con el equipo del proyecto qué enfoque se eligió antes de priorizar los puntos.
Cómo 4MDG puede ayudar
En la migración de datos a SAP, 4MDG trabaja con criterio de aceptación en cada fase de SAP Activate, informes de calidad con métricas antes y después del saneamiento y gobierno continuo en la fase Run, después del go-live. Si el checklist mostró brechas, empiece por el diagnóstico gratuito: se hace sobre una muestra real de su base, sin instalar nada, y muestra con números cuánto está duplicado, incompleto o irregular. ¿Prefiere conversar antes? Escríbanos desde la página de contacto.
Fuentes
- SAP Learning, curso Discovering SAP Activate: Implementation Tools and Methodology, lección "Discovering the Workstreams". https://learning.sap.com/courses/discovering-sap-activate-implementation-tools-and-methodology/discovering-the-workstreams_e34f1cd2-362f-4008-a6bd-8085da9caabe. Consultado el 30/10/2026.
- 4MDG, Migración de datos a SAP S/4HANA. https://4mdg.com.br/es/migracao-sap-s4hana. Consultado el 30/10/2026.
- 4MDG, Consultoría y diagnóstico. https://4mdg.com.br/es/consultoria-e-diagnostico. Consultado el 30/10/2026.