Marcar un campo como obligatorio garantiza que haya un valor, no que sea el correcto. Esta es la diferencia entre un formulario con validaciones y un maestro de materiales gobernado de verdad: reglas extraídas de tus propios datos, creación sin retecleo y validación continua sobre lo que ya existe.
¿Qué es el gobierno de datos maestros de materiales en SAP?
Es el conjunto de reglas, flujos de aprobación y controles que determinan quién puede crear o modificar un material, con qué información y bajo qué validaciones, antes de que ese registro exista en SAP. Incluye además la trazabilidad de cada cambio y la validación continua del maestro ya existente, no solo la definición de campos obligatorios.
Según Harvard Business Review, solo el 3 % de las empresas tiene datos que cumplen estándares básicos de calidad. El resto convive con un maestro que pasa todas las validaciones del formulario y falla después, en el proceso.
El material que se dio de alta bien y rompió el MRP tres semanas después
Pasó la validación. Todos los campos obligatorios estaban rellenos. Alguien de planta lo pidió por correo, alguien de datos maestros lo creó, y el flujo siguió.
Tres semanas más tarde, el MRP propuso 4.000 unidades de algo que se consume de seis en seis. La unidad de medida base era UN en lugar de KG. Un valor perfectamente válido. Un valor perfectamente incorrecto.
Nadie hizo nada mal, según el sistema. Y ahí está el problema: el sistema no estaba comprobando lo que creíamos que comprobaba.
Obligatorio no significa correcto
Marcar un campo como obligatorio garantiza una sola cosa: que haya un valor. No que sea el valor adecuado.
Lo que ocurre a continuación lo conoce cualquiera que haya mirado un maestro de materiales de más de cinco años:
XXX,N/A,.,PENDIENTE- El valor copiado del material anterior, porque «era parecido»
- Una descripción que empieza con el código del proveedor porque así se encontraba más fácil en 2017
- El grupo de artículos que eligió el primero de la lista desplegable
Todo eso pasa la validación. Todo eso falla después: en el almacén, en la planificación, en el inventario, en la factura que no casa. La validación llegó a tiempo para el formulario y tarde para el proceso.
Un campo obligatorio es un impuesto sobre el que rellena, no un control sobre el dato. Añade fricción al solicitante y no añade calidad al maestro. Y cuando el coste de hacerlo bien recae entero sobre la persona que menos contexto tiene, el resultado es predecible.
Hay una consecuencia de segundo orden, y es la cara: donde hay un maestro sucio, hay duplicados. El mismo rodamiento dado de alta tres veces con tres descripciones distintas significa tres stocks de seguridad, tres compras, tres ubicaciones. Sparetech estima que entre el 10 % y el 25 % del valor del stock puede ser redundante por materiales duplicados. Eso no es un problema de dato: es capital inmovilizado.
Excel y el sistema externo: el mismo problema, con más pasos
Cuando el estándar incomoda, aparecen dos salidas. Las dos se sienten como una solución y ninguna lo es.
La hoja de cálculo no valida nada. Un Excel que viaja por correo no comprueba si el grupo de artículos existe, si la vista de compras es coherente con el centro, si el material ya está dado de alta con otro nombre. No puede: no está conectado a SAP. Cuando alguien reteclea esa hoja en el sistema, la validación llega tarde y la hace una persona cansada a las seis de la tarde. El Excel no es el gobierno del dato; es el lugar donde el gobierno del dato se suspende temporalmente.
El sistema externo sí valida, pero hay que sincronizarlo. Y la sincronización es un segundo sistema que mantener: su propia latencia, sus propios conflictos, su propio proyecto cuando SAP cambie de versión. Se cambia un problema de calidad de dato por un problema de integración, que es más caro y menos visible. El maestro deja de tener una única fuente de verdad justo cuando más falta hace.
Hay una tercera vía, y es la aburrida: que el flujo viva dentro de SAP. Se pide, se aprueba y se crea desde lo que se aprobó. Sin retecleo, sin copia paralela, sin sincronización. No es espectacular. Es que no haya un segundo sitio donde el dato pueda estar mal.
Las reglas útiles no se escriben: se extraen del maestro que ya tienes
Aquí está la parte que casi todos los proyectos de calidad de datos hacen al revés.
Se convoca un comité, se redacta una nomenclatura, se publica un documento de 40 páginas y se pide a la organización que lo respete. Seis meses después, la nomenclatura la cumple quien la escribió.
El motivo es sencillo: nadie sabe de antemano qué combinaciones de características son válidas para un rodamiento, un reactivo o un repuesto de molienda. La teoría no lo sabe. El consultor no lo sabe. Pero el maestro actual sí: esos 40.000 materiales contienen el patrón real de cómo esa empresa concreta nombra, clasifica y describe lo que compra.
Extraer esas reglas del propio maestro —un trabajo asistido por IA, porque a esa escala la revisión manual no es viable— cambia la naturaleza del documento. Deja de ser una norma impuesta y pasa a ser una descripción de la práctica real de la casa. Es, literalmente, dejar que tus datos propongan las reglas. Y una regla que describe cómo ya trabaja la gente es una regla que la gente respeta, porque no le pide cambiar: le pide ser consistente.
Esa es la diferencia entre una nomenclatura que se cumple y una que se esquiva.
Descentralizar, automatizar, validar
Limpiar el maestro una vez y dejar abiertas las mismas vías de entrada garantiza que en 18 meses esté exactamente igual. El data cleaning no es un proyecto: es un estado. Y lo que sostiene ese estado es un orden concreto de tres movimientos.
Descentralizar con adopción. Quien conoce el material es quien lo pide: el ingeniero de mantenimiento, el responsable de planta, el comprador técnico. El cuello de botella aparece cuando esa persona tiene que atravesar una transacción pensada para un especialista. Se resuelve mostrándole solo lo que le toca —su tipo de solicitud, sus vistas, sus campos— y nada más.
Automatizar la creación. Una vez aprobada la solicitud, el material se crea en SAP en todas sus vistas a partir de lo aprobado. Sin que nadie vuelva a teclear. Cada retecleo entre la aprobación y la creación es una oportunidad de introducir exactamente el error que el flujo pretendía evitar.
Validar de forma continua. No solo en el alta: también sobre lo que ya existe. Vistas que faltan, campos mal informados, duplicados que entraron antes de que hubiera reglas. El maestro se degrada por sí solo; sin una validación que corra sobre el stock existente, cada limpieza es una foto que caduca.
Y por encima de los tres: trazabilidad. Quién pidió qué, quién lo aprobó, con qué motivo y cuándo. No por burocracia, sino porque es lo único que permite responder a la pregunta de la auditoría sin reconstruir un hilo de correos.
El coste de no hacerlo es difícil de ver en una línea del P&L, pero está medido: Gartner cifra en 12,9 millones de dólares al año el coste medio que la mala calidad de los datos supone para una empresa.
Cómo lo resuelve SiDM Materiales
SiDM Materiales es la aplicación de Innova para crear y gobernar datos maestros de materiales en SAP desde una única aplicación. Aplica reglas de negocio, asistidas por IA, para validar y corregir materiales existentes (limpieza de datos) y agilizar la creación de materiales nuevos, con flujos de aprobación y participación. Funciona en SAP ECC y S/4HANA.
Traducido a los tres movimientos anteriores:
| Lo que duele | Qué hace SiDM Materiales |
|---|---|
| Dar de alta un material tarda días | Solicitud única de creación, extensión o modificación; al aprobarse, SiDM crea el material en SAP en todas sus vistas |
| Demasiadas vistas, campos y transacciones | Cada tipo de solicitud muestra solo las vistas y campos que tocan; se copian datos de un material modelo |
| Materiales duplicados que inflan stock y compras | Búsqueda de repetidos por textos o características, campos de valor único y descripciones con máscaras |
| Aprobaciones por correo y Excel | Aprobación por niveles con estrategias propias y avisos en el idioma de cada usuario |
| Nadie sabe quién aprobó qué, ni por qué | Historial de cada cambio de estado con su motivo, y reporte de auditoría de solicitudes |
| Vistas que faltan o datos mal informados | Validación de vistas y campos contra reglas, con corrección de las vistas que falten |
Se despliega sobre SAP ECC y S/4HANA, en la arquitectura que ya tengas —Fiori, BTP o servidor web—, con implementación en 4–8 semanas y sin coste por usuario ni por sociedad. Forma parte de la Suite de Datos Maestros junto a SiDM Proveedores.
Si quieres el contexto estratégico previo —cómo plantear el proyecto antes de tocar una transacción—, está en estrategia de datos maestros en SAP.
Míralo funcionando antes de hablar con nadie
Hay un punto en el que las descripciones dejan de servir. Esto se entiende viéndolo.
Hay una demo interactiva de 30 pantallas con el recorrido completo de una solicitud de alta de material: desde que el solicitante parte de una variante y adopta un material modelo, hasta que la solicitud no se libera porque falta la lista de materiales, la hoja de ruta y la versión de fabricación.
Sin formulario, sin comercial, sin agenda. Pantalla a pantalla, a tu ritmo. Abre la demo interactiva de SiDM Materiales.
Preguntas frecuentes
¿Un campo obligatorio no sirve de nada entonces?
Sirve para asegurar presencia, no corrección. Es un componente válido dentro de un esquema de validación más amplio, pero por sí solo desplaza el coste al solicitante sin mejorar el maestro. El control útil comprueba el valor contra una regla, no contra el vacío.
¿Cómo se detectan materiales duplicados que ya están dados de alta?
Por coincidencia de textos y de características, no solo por código. A eso se suman campos de valor único y descripciones generadas con máscaras, que evitan que el mismo artículo vuelva a entrar con otro nombre. La detección sobre el maestro existente y la prevención en el alta son dos trabajos distintos: hacen falta los dos.
¿Hace falta migrar a S/4HANA para gobernar bien los datos maestros?
No. El gobierno del dato es independiente de la versión. Lo que sí cambia es el coste de no hacerlo: migrar con un maestro sucio traslada el problema y encarece el proyecto, porque la conversión de datos se convierte en el camino crítico.
¿Cuánto tarda en estar en productivo?
La implementación de las Apps de Innova es de 4–8 semanas. El factor que más alarga un proyecto de datos maestros no es la herramienta: es el acuerdo interno sobre las reglas. Extraerlas del maestro existente en lugar de redactarlas desde cero acorta justamente esa parte.
¿Qué papel juega la IA aquí?
Asistido, no autónomo. Sirve para encontrar patrones en un maestro de decenas de miles de registros —cómo se nombra, cómo se clasifica, qué combinaciones de características aparecen de verdad— y convertirlos en reglas propuestas. La decisión sobre qué regla se adopta sigue siendo del equipo de datos maestros.
¿Quieres ver estas reglas sobre tu propio maestro de materiales? Lo miramos con tus datos, no con un ejemplo.
