El ERP no debería ser la puerta de entrada para cada dato maestro

El caso práctico

El escenario se repite con distintos maestros: clientes y sucursales, proveedores, materiales y servicios. Las áreas usuarias necesitan crear o modificar información; diferentes responsables deben revisarla; y el ERP debe recibir únicamente aquello que ya superó las reglas y aprobaciones definidas.

Cuando ese proceso no está diseñado, aparecen síntomas conocidos:

• Solicitudes por correo o archivos sin una versión única.
• Datos obligatorios incompletos o interpretados de forma distinta.
• Aprobaciones difíciles de reconstruir.
• Cambios directos en el ERP sin suficiente contexto de negocio.
• Aplicaciones que consultan repetidamente el sistema central.
• Errores de integración que se descubren cuando el proceso ya se detuvo.

1. Un único punto de entrada

Las áreas solicitantes deberían iniciar las altas y modificaciones desde un canal común. Esto permite definir datos obligatorios, adjuntar sustento, identificar al responsable y mantener una versión controlada de la solicitud.

Centralizar la entrada no significa concentrar todas las decisiones en TI. El negocio debe conservar la responsabilidad sobre el significado, calidad y aprobación del dato.

2. Validar antes de publicar

El gestor centralizado debe aplicar reglas de completitud, formato, duplicidad y coherencia antes de enviar información al ERP.

Las validaciones técnicas son necesarias, pero no reemplazan las reglas empresariales: quién puede solicitar, quién debe aprobar y qué condiciones hacen aceptable un dato.

SAP Master Data Governance emplea solicitudes de cambio, staging, workflow, aprobación, activación y distribución. No es la única manera de implementar este patrón, pero sí una referencia útil para comprender sus responsabilidades.

3. Aprobar según la propiedad del dato

No todos los campos pertenecen a la misma función. Finanzas puede decidir condiciones de pago; compras puede validar información del proveedor; comercial puede responsabilizarse por atributos del cliente; y operaciones puede gobernar datos logísticos.

La arquitectura debe reflejar esa propiedad. Un flujo genérico para todo puede ser tan problemático como no tener flujo: simplifica la herramienta, pero oculta quién responde por cada decisión.

4. Publicar de manera controlada

Solo una solicitud aprobada debería transformarse en una creación o modificación en el ERP. El publicador necesita registrar qué intentó enviar, qué respondió el sistema de destino y cuál es el estado final.

Si una publicación falla, el proceso debe continuar siendo observable y recuperable; no puede depender de que alguien encuentre un mensaje perdido.

• Idempotencia para evitar duplicados.
• Reintentos seguros.
• Tratamiento explícito de errores.
• Conciliación entre origen y destino.
• Monitoreo y alertas operativas.

5. Evitar que cada consumidor golpee el ERP

Una vez publicado el dato, las aplicaciones que únicamente necesitan consultarlo no deberían convertirse automáticamente en nuevos accesos directos al ERP.

Según la criticidad y frescura requerida, puede exponerse una vista autorizada, un servicio de consulta o una proyección de lectura administrada por la capa central.

Esta decisión reduce acoplamiento, protege el sistema transaccional y permite aplicar políticas de acceso y observabilidad fuera del núcleo operativo. No significa crear una segunda verdad: la fuente oficial continúa definida y la capa de consumo debe mantener sincronización y trazabilidad con ella.

Gobierno antes que tecnología

Antes de seleccionar una plataforma, conviene responder:

• ¿Quién es propietario de cada dominio y quién puede aprobarlo?
• ¿Qué reglas determinan que el dato es publicable?
• ¿Cuál es el sistema de registro para cada atributo?
• ¿Qué aplicaciones necesitan escribir y cuáles únicamente consultar?
• ¿Cómo se detectan, recuperan y concilian los errores?
• ¿Qué evidencia quedará para auditoría y mejora continua?

Qué medir

El éxito no debería evaluarse únicamente por la cantidad de solicitudes procesadas. Un tablero útil puede observar:

• Tiempo desde la solicitud hasta la publicación.
• Solicitudes rechazadas por información incompleta.
• Duplicados detectados antes de llegar al ERP.
• Publicaciones fallidas y tiempo de recuperación.
• Cambios sin propietario o aprobación identificable.
• Consultas directas al ERP que fueron retiradas o controladas.

Conclusión accionable

Gobernar datos maestros no es poner un formulario delante del ERP. Es definir quién decide, bajo qué reglas, cómo se publica y cómo se demuestra lo ocurrido.

El primer paso puede ser pequeño: elegir un dominio crítico, mapear la solicitud, identificar propietarios, documentar reglas y diseñar el flujo de publicación y recuperación. Después, ese aprendizaje puede convertirse en un patrón reutilizable para los demás maestros.

Cuando el dato entra por un proceso gobernado y las aplicaciones consumen una capa controlada, el ERP deja de ser el lugar donde todo se resuelve. Vuelve a cumplir su función principal: ejecutar de forma confiable las operaciones del negocio.