¿Necesitas SAP MDG? Un diagnóstico honesto antes de decidir

La gobernanza no es una herramienta. Es una capacidad.

Aquí es donde la mayoría de las evaluaciones se equivocan. La gobernanza se trata como algo que se compra, cuando en realidad es algo que se construye: un conjunto de decisiones sobre quién es propietario de qué datos, cómo es un registro completo, qué reglas son innegociables y quién aprueba qué.

SAP MDG no toma esas decisiones por ti. Las hace cumplir, a escala, de forma consistente y con un registro de auditoría. Eso es un valor enorme, pero solo una vez que las decisiones ya existen. Instalar una plataforma de gobernanza sobre una organización que no ha acordado qué es un cliente equivale a automatizar el desacuerdo.

Dicho claramente: la herramienta ejecuta la gobernanza. No la inventa. Si hoy nadie es propietario de los datos maestros, comprar MDG no creará un propietario; creará un sistema costoso sin nadie que lo dirija.

Lo que necesitas antes de la herramienta

Un pequeño equipo dedicado, o como mínimo propietarios designados por dominio, con autoridad suficiente para decir que no. Una definición acordada de tus objetos principales. Una idea aproximada de la calidad actual de tus datos —no una auditoría completa, pero sí honesta—. Y una razón clara de por qué la forma actual de trabajar no es sostenible.

Si tienes esas cuatro cosas, una plataforma de gobernanza las multiplicará. Si no las tienes, expondrá su ausencia de una forma incómodamente visible.

Cuándo SAP MDG es realmente la respuesta correcta

Suponiendo que exista el trabajo previo, hay algunas situaciones en las que MDG deja de ser una opción entre varias y se convierte en la evidente.

Ya utilizas SAP

El argumento de la integración no es marketing. Los datos maestros gobernados en MDG residen en el mismo modelo de datos que el sistema transaccional al que alimentan, usando las mismas definiciones de campo, las mismas tablas de verificación, el mismo customizing. No hay nada que traducir ni mapear en el límite entre sistemas. Cualquiera que haya mantenido una capa de middleware entre una herramienta de MDM de terceros y un backend de SAP sabe exactamente cuánto esfuerzo continuo consume ese límite, y con qué silencio se va desincronizando.

No utilizas SAP ERP, y aun así puede tener sentido

Esto sorprende a la gente. MDG puede funcionar como un centro de gobernanza independiente, gestionando registros de forma centralizada y distribuyéndolos a cualquier sistema que los consuma, sea SAP o no. La evaluación se reduce entonces a si la profundidad de su modelo de datos y su motor de reglas justifica la licencia frente a una herramienta de MDM más ligera y genérica.

A veces no la justifica, y una plataforma más sencilla es la decisión correcta. Pero si tus datos maestros son genuinamente complejos —materiales multiplanta, socios de negocio que desempeñan varios roles en distintas entidades legales—, esa complejidad tiene que residir en algún lugar. Las herramientas genéricas tienden a modelarla de forma superficial, y esa brecha reaparece más tarde como desarrollo a medida.

Necesitas gobernar el proceso, no solo el registro

Este es el argumento que menos se comenta y el que más importa.

El gobierno de datos maestros suele presentarse como un ejercicio de calidad de datos: menos duplicados, registros más completos, mejores informes. Todo cierto, todo secundario. El valor real es el control sobre lo que la empresa puede o no puede hacer.

No debería poder crearse un pedido de compra contra un proveedor que no ha superado los controles de cumplimiento. No debería ser posible un pedido de venta para un material que no está liberado para esa organización de ventas. Un material no debería llegar a un centro al que nunca fue extendido. Cada uno de esos casos es una decisión de gobernanza expresada como un estado en un registro maestro, y aplicada antes de la transacción, no descubierta después en un informe de excepciones.

Planteado así, el estado del dato maestro se convierte en un mecanismo de control para toda la cadena de procesos. No estás limpiando datos. Estás definiendo qué puede y qué no puede ejecutar tu organización.

Cuándo la respuesta es no, o todavía no

Hay situaciones en las que lo decimos directamente.

• Nadie es propietario de los datos. Si los datos maestros son responsabilidad de todos y trabajo de nadie, arregla eso primero. No cuesta nada y cambia más que cualquier herramienta.

  
  

• El problema real es acotado. Si el ochenta por ciento del dolor viene de proveedores duplicados creados porque la búsqueda es incómoda, un programa de gobernanza es una forma cara de resolver un problema de localización.

  
  

• El volumen no lo justifica. Gobernar unos cientos de registros creados al año raras veces justifica una plataforma de este peso. Un proceso claro y un formulario bien diseñado pueden bastar durante mucho tiempo.

  
  

• No hay disposición a aceptar las reglas. MDG funciona haciendo imposibles ciertas cosas. Si la organización no está dispuesta a aceptar fricción en el momento de la creación, el flujo de trabajo se elude y la inversión se desperdicia.

Ninguno de estos es un veredicto permanente. Son cuestiones de secuenciación. La mayoría de las empresas a las que decimos "todavía no" vuelven en un plazo de dieciocho meses, y el proyecto va mejor porque el trabajo de base ya está hecho.

La cuestión del coste, planteada correctamente

Las comparaciones de coste en este ámbito suelen ser engañosas, porque comparan las cosas equivocadas.

Licencia

MDG suele tener un coste de licencia más alto que una herramienta de MDM ligera, y más bajo que las grandes plataformas especializadas. Pero rara vez es una comparación limpia: si ya tienes licencias de SAP, parte del derecho de uso puede estar cubierto, y eso cambia el panorama considerablemente. Vale la pena revisar tus acuerdos existentes antes de dar nada por sentado.

Implementación

Aquí es donde reside la verdadera diferencia, y funciona en ambas direcciones. Implementar MDG sobre un panorama SAP existente suele ser más rápido, porque el modelo de datos, las tablas de verificación y el customizing ya están en su sitio: estás configurando gobernanza sobre estructuras que ya existen, no reconstruyéndolas. Implementar una herramienta que no es de SAP en un panorama SAP suele ser más barato de licenciar y considerablemente más caro de integrar, y ese coste de integración nunca desaparece del todo.

La cifra que importa no es la licencia ni la implementación por separado. Es el coste total a cinco años, integración y mantenimiento incluidos, y, en el otro lado de la balanza, el coste de las transacciones que tu configuración actual permite y no debería.

Entonces, ¿cómo se decide?

No a partir de una tabla comparativa de proveedores. La secuencia útil es más acotada que eso.

Empieza por lo que realmente duele, en concreto: qué registros, qué procesos, qué decisiones salen mal y cuánto cuesta eso. Después, establece si hoy tienes capacidad de gobernanza o si necesitas construirla. Solo entonces pregunta qué herramienta encaja, momento en el que la pregunta suele responderse sola, porque los requisitos se han vuelto concretos.

Saltar directamente a la herramienta es lo que produce el patrón que vemos una y otra vez: un sistema bien configurado, una construcción técnica sólida y una organización que nunca lo adoptó porque el trabajo de base nunca se hizo.