Material o Socio de Negocio: dónde los proyectos de SAP MDG se complican de verdad

El error que retrasa los proyectos

Un equipo termina Material. Ha ido razonablemente bien. El blueprint tardó más de lo previsto, pero el diseño se sostuvo, el flujo de trabajo funciona, el negocio lo ha adoptado. Así que Socio de Negocio se dimensiona por analogía: duración similar, mismo equipo, mismo enfoque.

Entonces llega el primer taller y alguien pregunta qué es en realidad un socio de negocio. Tres horas después hay cuatro respuestas incompatibles en la sala y ninguna decisión. Esa pregunta nunca surgió en Material, porque todo el mundo ya sabía qué era un material.

Esa es la diferencia en una frase: en Material se negocia quién controla el dato. En Socio de Negocio se negocia qué representa siquiera el dato.

Material: la pelea es por lo que significa "común"

Los datos de Material se dividen claramente en dos. Hay campos básicos compartidos por todo el grupo, y hay campos que pertenecen a un centro, una organización de ventas o una sociedad concretos. La división técnica es obvia. La organizativa no.

Los datos comunes pertenecen al grupo, no al centro

Aquí es donde los proyectos de Material pierden sus semanas. Los datos básicos tienen que ser acordados por todos: cada centro, cada empresa, cada país. Y cada uno de ellos lleva años tratando esos campos como propios, porque en la práctica nadie se lo ha impedido.

Pedirle a un centro que acepte una definición de tipo de material a nivel de grupo, o una unidad de medida base que no eligió, no es un ejercicio de modelado de datos. Es una negociación sobre autonomía, y avanza exactamente tan despacio como suena. El trabajo técnico es trivial; conseguir el acuerdo no lo es.

Una jerarquía, no cuatro

La clasificación y las jerarquías merecen una mención especial, porque aquí la negociación se hace explícita. Ventas quiere una jerarquía que refleje cómo vende. Marketing quiere una que refleje cómo posiciona. Compras quiere una que refleje cómo compra. Cada una es legítima en sus propios términos.

Pero los datos maestros gobernados necesitan una única jerarquía, mantenida una sola vez, con la que todos convivan. Decidir qué lógica prevalece —o diseñar una estructura que sirva a las tres sin volverse inmanejable— es una de las conversaciones más difíciles de todo el programa, y no puede delegarse en TI.

Las unidades de medida, en silencio

Las unidades base y las unidades alternativas con sus factores de conversión parecen un detalle de configuración hasta que dejan de serlo. Se propagan a precios, planificación, logística y valoración de existencias. Si se definen mal a nivel de grupo, el error aparece meses después, en un lugar que nadie relaciona con los datos maestros.

Y luego llegan los datos locales, que sí son extensos de verdad

Una vez acordada la capa común, llegan los datos de centro y organización de ventas, y aquí la amplitud es real. Lo importante es que las reglas no son uniformes: un centro de producción, un centro de distribución, una empresa solo de ventas y una entidad financiera necesitan campos genuinamente distintos, con lógicas de obligatoriedad distintas.

El instinto de diseño debería ser simplificar —gobernar menos, no más— con una premisa innegociable: lo que se deje fuera no debe impedir que el proceso transaccional funcione para esa entidad concreta. Una regla que es elegante a nivel de grupo y que bloquea a un centro la salida de mercancías no es una buena regla.

Socio de Negocio: la pelea es por qué es siquiera un SN

Socio de Negocio tiene menos campos que Material. Aun así, suele ser el dominio más difícil, porque el propio objeto está en disputa.

Pregunta a diez personas, obtén diez respuestas

Pruébalo en un taller. ¿Es un socio de negocio todo el grupo corporativo, incluyendo cada NIF que posee en cada país? ¿Es un SN por país, con una jerarquía que enlaza cada entidad local con una matriz global? ¿Es la entidad legal? ¿Es la tienda individual?

El retail lo ilustra bien. Una gran cadena con cientos de puntos de venta: ¿un SN para la marca, uno por entidad legal, o uno por tienda? Cada tienda tiene su propia dirección de entrega, a veces su propio comportamiento de pedido, a veces su propia facturación. Si la respuesta es un SN por tienda, en la práctica se ha decidido que un socio de negocio es una dirección de entrega en lugar de una organización, lo cual es una elección defendible, pero una elección con consecuencias que llegan hasta precios, gestión de crédito e informes.

Entonces, ¿qué cuenta como duplicado?

La pregunta sobre la definición produce de inmediato una segunda. Si el mismo grupo corporativo existe como cinco SN en cinco países, ¿es eso duplicación o un modelado correcto? Si un cliente aparece dos veces con dos direcciones de entrega, ¿es un registro con dos direcciones o dos registros?

La mayoría de las organizaciones terminan aceptando una duplicación deliberada a lo largo de un eje —normalmente país o entidad legal— mientras la prohíben en otros. Es un resultado razonable. Lo que no es razonable es descubrir la regla a mitad de la construcción de la verificación de duplicados, que es cuando suele descubrirse.

Roles: una entidad con varios sombreros

Solo una vez definido el objeto pueden asignarse los roles. Y el mismo socio es con frecuencia cliente y proveedor a la vez, a veces también competidor.

Para los equipos que migran desde maestros de Cliente y Proveedor separados, esta es la ruptura conceptual. El modelo de datos lo soporta. La organización, a menudo, no: dos departamentos distintos han mantenido a ese socio de forma independiente durante años, con datos distintos, procesos distintos e ideas distintas de quién es el propietario. El modelo tiene que soportar el solapamiento, y también debe hacerlo el proceso de gobernanza, incluyendo quién aprueba qué cuando un registro tiene ambos roles.

Sociedad y área de ventas: los mismos campos, mundos distintos

Después, Socio de Negocio se encuentra con el mismo problema que tuvo Material, visto desde el otro lado. Los datos de sociedad y área de ventas usan los mismos campos en todas partes, pero los valores y las reglas cambian según el país: requisitos fiscales y legales, condiciones de pago, retenciones, acuerdos comerciales, obligaciones de informes locales.

Parece un único diseño. En realidad son tantas variantes como países con reglas significativamente distintas, y hay que tratarlo así en la planificación.

Dos dominios, dos tipos de dificultad

Material es un problema de acuerdo. El objeto se entiende; la dificultad está en conseguir que muchas entidades cedan el control local sobre campos compartidos, y luego en gestionar la amplitud genuina de la capa local.

Socio de Negocio es un problema de definición. Una vez definido, el resto avanza razonablemente bien, pero esa definición es una decisión de negocio con consecuencias comerciales y legales, y no puede resolverse en un taller técnico.

Necesitan personas distintas en la sala. Material necesita representación de centros y cadena de suministro con autoridad para ceder. Socio de Negocio necesita a comercial, legal y finanzas desde el principio, antes de modelar un solo campo.

Qué significa esto para la planificación

En la práctica: no dimensiones el segundo dominio a partir del primero. Presupuesta el tiempo de definición de Socio de Negocio como una fase distinta, en lugar de integrarlo en el blueprint, y espera que el trabajo de variación local en Material sea más amplio de lo que sugiere la lista de campos.

Lo tranquilizador es que la plataforma no es la limitación. MDG se adapta a cualquier modelo al que se llegue —un SN por grupo o uno por tienda, una jerarquía o unas pocas controladas—. Lo que determina si el proyecto avanza según lo previsto es lo pronto que se tomen esas decisiones, y quién las tome.