Toda conversión a S/4HANA tiene un momento en el que el proyecto se detiene y mira hacia los datos maestros. No porque alguien lo haya planificado, sino porque la conversión de interlocutor comercial rechaza registros con documento inválido, la carga de material reprueba una clasificación inexistente y la lista de errores llega con miles de líneas y mensajes que solo tienen sentido para quien escribió el programa.

En ese punto el proyecto suele tomar la decisión equivocada: corregir durante la carga. Funciona en el primer ciclo, crea deuda permanente y deja el origen tan sucio como estaba. El saneamiento de datos maestros no es una etapa de la migración: es trabajo que debe ocurrir antes, y que la migración apenas revela.

Qué significa «sucio» en la práctica

Un dato maestro malo casi nunca es un dato ausente. Es un dato plausible y equivocado, que pasó por todas las validaciones del sistema antiguo porque el sistema antiguo no validaba.

• Duplicidad. El mismo proveedor dado de alta tres veces, con grafías distintas, direcciones parecidas y a veces documentos diferentes porque alguien se equivocó al teclear una vez.
• Campo obligatorio en el destino, opcional en el origen. S/4 exige lo que ECC toleraba vacío, y la lista de nuevas exigencias es larga.
• Formato inconsistente. Documentos con y sin puntuación, dirección con el número en el campo de la calle, teléfonos con formatos de tres décadas distintas.
• Clasificación equivocada o ausente. Material sin grupo de artículos, código arancelario desactualizado, unidad de medida sin conversión registrada.
• Registro muerto. Cliente sin movimiento desde hace ocho años, material descontinuado, centro que ya no existe: todo activo, todo migrándose.
• Relación rota. El registro apunta a una condición, un banco o un centro que ya fue borrado.

En una conversión de ECC a S/4 en entorno RISE que acompañamos, con enfoque Bluefield —selectivo, en el que se elige qué atraviesa—, esa lista fue justamente lo que definió el alcance. Bluefield solo cumple su promesa si alguien decide qué no va; y para decidir hay que ver primero.

Ver antes de corregir

El primer entregable no es una corrección: es un indicador de calidad por objeto. Cuántos clientes, proveedores y materiales existen; cuántos están activos; cuántos tienen movimiento en los últimos veinticuatro meses; cuántos reprueban cada regla.

Ese panel cambia la conversación del proyecto, porque transforma «los datos están malos» en un número. Y casi siempre revela el hallazgo más útil de todos: la mayor parte del maestro no se usa. Un registro sin movimiento no necesita ser corregido: necesita ser bloqueado y dejado atrás.

Es la misma lógica de alcance que describimos en conversión de datos con IA: la pregunta que más ahorra es qué no va.

El diseño: n8n orquesta, el ERP sigue siendo el dueño

Usamos n8n en la infraestructura del cliente como director del ciclo: extrae el maestro, aplica las reglas, arma el contexto, llama al modelo para lo que exige criterio, presenta la propuesta y devuelve la corrección al ERP por el camino estándar. El dato maestro no sale de casa y la corrección entra por la puerta principal, con pista de auditoría.

Las reglas son código. Documento válido, campo obligatorio completado, formato normalizado, relación existente: todo eso es verificación determinística, tiene que dar el mismo resultado siempre y no debe pasar por ningún modelo.

La IA entra en tres lugares, todos donde la regla exacta es débil.

Deduplicación por similitud. «Comercial São Jorge Ltda», «Com. Sao Jorge LTDA» y «SÃO JORGE COMERCIAL» son el mismo proveedor para cualquier persona y tres claves distintas para una comparación exacta. El modelo agrupa por semejanza de razón social, dirección y documento, asigna una puntuación y propone el grupo, con el registro que debe sobrevivir y por qué. La fusión la confirma una persona, porque unificar registros equivocados hace estragos en el histórico.

Clasificación de lo que falta. Material sin grupo de artículos, sin código arancelario o sin unidad: el modelo lee la descripción, la compara con los artículos ya clasificados de la propia empresa y propone. El histórico interno es el maestro, y es mejor maestro que cualquier tabla genérica.

Traducción del error. El mensaje de rechazo de la carga suele ser críptico y a veces apunta al lugar equivocado. Con el registro y la regla a mano, el asistente explica qué falló realmente y qué corregir.

El ciclo, y por qué se repite

El saneamiento no es una sola pasada. Es un bucle que corre varias veces, y cada vuelta es más barata que la anterior.

1. Medir. Indicador de calidad por objeto y por regla, con la lista de rechazados exportable.
2. Descartar. Bloquear lo que no tiene uso ni obligación de conservación. Es el paso que más reduce esfuerzo y el que más resistencia encuentra.
3. Unificar. Deduplicar lo que quedó, con la aprobación registrada.
4. Completar. Llenar lo que el destino exige, con propuesta de la IA y revisión de quien es dueño del maestro.
5. Recargar y volver a medir. El mismo indicador, con el número nuevo al lado del antiguo.

En la conversión que acompañamos, ese bucle avanzó junto con los ciclos de prueba de carga: dos ciclos solo de carga, después uno con integraciones y tres integrados completos. Cada ciclo devolvía una lista de rechazos que se convertía en tarea de saneamiento en el origen, y el ciclo siguiente medía si la lista había encogido. El mandante saneado en un entorno separado es lo que hace esto posible sin tocar producción.

Quién decide qué es verdad

La parte que ninguna herramienta resuelve: el dato maestro necesita dueño. No el equipo de TI, que no sabe si dos clientes son el mismo grupo económico; y no el proyecto, que termina. Alguien del área que usa el maestro tiene que responder por las decisiones, y seguir respondiendo después del go-live.

Sin eso, el maestro vuelve a ensuciarse en meses, porque la causa nunca fue técnica: era la ausencia de criterio y de responsable. La automatización acorta el trabajo de corrección; no sustituye a la gobernanza.

Qué queda después de la migración

La ganancia inmediata es la carga que pasa y el cronograma que no se corre. Lo que dura son otras tres cosas.

Las reglas se vuelven verificación permanente. Lo que reprobaba en la migración pasa a correr sobre el maestro nuevo, periódicamente. La base nace con un criterio de calidad definido en vez de degradarse hasta la próxima migración.

El criterio queda escrito. Qué define un duplicado, qué justifica un bloqueo, cómo se clasifica un material nuevo: decisiones que estaban en la cabeza de quien da de alta se convierten en un documento consultable.

La trazabilidad responde a la auditoría. Para cada registro fusionado o bloqueado existe quién lo aprobó, cuándo y con qué base.

El límite honesto: el saneamiento no arregla el proceso de alta. Si cualquier persona sigue creando proveedores sin verificación, la base vuelve a ensuciarse; más despacio, pero vuelve. Sanear es el comienzo; la gobernanza es lo que lo sostiene. Es la misma disciplina de datos e integración, aplicada al maestro en vez de al flujo.

Si su conversión todavía se está diseñando, vale la pena leer antes el e-book de implementación en la Inove Academy, que muestra por qué la mayoría de los problemas de proyecto no son técnicos, y la guía de brownfield, greenfield y bluefield, para elegir el enfoque sabiendo qué exige cada uno de sus datos.