Modelo de Información en la Nube

La entidad Proveedor en el Modelo de Información en la Nube (CIM) es un Rol de Parte especializado: describe una parte (una organización o un individuo) que desempeña la función de suministrar bienes o servicios a la empresa. Debido a que CIM separa la parte (la identidad duradera de una empresa o persona) del rol que desempeña, la misma parte puede ser simultáneamente un Cliente, un Proveedor y un Socio sin duplicar datos maestros. Esta es la promesa central de interoperabilidad del modelo: un vocabulario compartido e independiente de las aplicaciones que permite que los sistemas de adquisiciones, ERP, logística y análisis se pongan de acuerdo sobre qué es un “proveedor”.

La entidad Proveedor incluye dos amplias familias de atributos: identidad y clasificación (quién es el proveedor) y puntuación de desempeño (qué tan bien se desempeña el proveedor). Los atributos de puntuación se agrupan en tres categorías ponderadas —contrato, satisfacción y competitivo— que se resumen en un único supplierScore. Comprender cómo encajan esas piezas es esencial para cualquiera que implemente cuadros de mando de proveedores, datos maestros de proveedores o análisis de adquisiciones sobre CIM.

Conclusiones clave

• El Proveedor es un Rol de Parte, no una entidad independiente. Hereda la identidad de la Parte y agrega atributos específicos del rol, por lo que nunca se bifurcan los datos maestros del proveedor de los datos maestros del cliente.
• La puntuación es un modelo ponderado de tres categorías. Las medidas de contrato, satisfacción y competitividad tienen cada una un weightPercent y un weightScore; el supplierScore general los combina.
• La mayoría de los campos de tasa se expresan como números enteros que representan porcentajes o recuentos, lo que mantiene el modelo simple pero traslada las decisiones de redondeo y normalización a la implementación.
• id y activeFromDate son obligatorios. Cada registro de proveedor necesita una clave primaria GUID estable y una fecha de inicio para su período activo.
• isCarrier es una bandera de especialización ligera que permite que la lógica logística identifique a los transportistas (por ejemplo, FedEx, UPS) sin una entidad separada.
• CIM está diseñado para ser extendido. El modelo es de código abierto y está pensado para ser bifurcado y adaptado, por lo que debe tratar estos atributos como un contrato base, no como un esquema cerrado.

Por qué el Proveedor se modela como un Rol de Parte

La decisión de diseño más importante en CIM es la división Parte / Rol de Parte, un patrón que también se encuentra en modelos empresariales establecidos como el Marco de Información (SID) del TM Forum y en la práctica de gestión de datos maestros en general. Una Parte es el elemento persistente: una entidad jurídica, una organización o una persona. Un Rol de Parte es una relación limitada en el tiempo que dicha parte tiene con la empresa.

Esto es importante porque las empresas reales desempeñan muchas funciones. Un fabricante por contrato puede venderle productos terminados (Proveedor), comprarle componentes (Cliente) y desarrollar conjuntamente un producto (Socio).

Si modela cada uno como un registro separado, obtendrá registros maestros de proveedores/clientes duplicados, pesadillas de conciliación y jerarquías inconsistentes. Al convertir al Proveedor en un rol, CIM le permite asignar una única Parte a múltiples roles y mantener un único registro maestro (“golden record”).

Implicaciones prácticas:

Relacionado: Fivetran — El proceso ELT totalmente gestionado que sigue funcionando.

• La deduplicación ocurre a nivel de Parte. Dos registros de Proveedor que apuntan a la misma Parte son la misma entidad legal.
• Los roles son temporales. Los campos activeFromDate y activeToDate permiten que la relación con un proveedor comience y finalice sin borrar el historial.
• Los datos específicos del rol permanecen con el rol. La clasificación de proveedores y las métricas del cuadro de mando pertenecen al Proveedor, no a la Parte, porque solo tienen sentido en el contexto del proveedor.

Atributos de identidad y clasificación

Los atributos de identidad son deliberadamente mínimos, lo cual es típico de un modelo compartido que debe mapearse claramente en muchos sistemas fuente.

• id (guid, obligatorio): la clave primaria. El uso de un GUID en lugar de una clave natural evita colisiones al fusionar registros de múltiples sistemas.
• activeFromDate (fecha, obligatorio): cuándo se activó la relación con el proveedor.
• activeToDate (fecha): cuándo finalizó, si es que ocurrió.
• supplierType (cadena): una clasificación de texto libre como Minorista, Distribuidor, Fabricante o Comerciante.
• isCarrier (booleano): verdadero cuando el proveedor es un transportista como FedEx o UPS.
• supplierSpend (entero): costo total gastado en la adquisición de productos del proveedor.

Una nota sobre supplierType: debido a que es una cadena simple, es un vocabulario controlado por convención, no por esquema. En una implementación real, debe restringirlo con una enumeración o una lista de datos de referencia; de lo contrario, “Fabricante”, “fabricante” y “Mfg” fragmentarán sus informes. Esta es una compensación clásica en los modelos compartidos —flexibilidad versus consistencia— y CIM se inclina hacia la flexibilidad, esperando que los implementadores la ajusten.

De manera similar, supplierSpend como un número entero plantea una cuestión de moneda y escala. El modelo no especifica una moneda o una convención de unidades menores, por lo que debe decidir (por ejemplo, almacenar unidades menores y vincular el campo con un código de moneda de su propia extensión) antes de agregar el gasto entre regiones.

Nuestra elección: Workato — iPaaS basada en automatización que los equipos empresariales pueden aprovechar.

El cuadro de mando del proveedor: contrato, satisfacción y competitividad

El corazón de la entidad Proveedor es su cuadro de mando, una combinación ponderada de tres categorías de medición. Cada categoría tiene un weightPercent (cuánto cuenta para el total) y un weightScore (la puntuación asignada después de analizar las medidas de esa categoría). El supplierScore general se define como:

(ponderación del contrato × puntuación) + (ponderación de la satisfacción × puntuación) + (porcentaje de peso de costo/competitividad × puntuación)

Medidas de desempeño del contrato

Estas son métricas operativas objetivas vinculadas al acuerdo de compra:

• contractOnTimeDeliveryRate — entregas a tiempo según las fechas prometidas ÷ entregas totales.
• contractDeliveryCorrectnessRate — entregas con la cantidad correcta ÷ entregas totales.
• contractProductQualityRate — porcentaje de productos con defectos.
• contractProductReturnRate — porcentaje de productos devueltos.
• contractInvoiceAccuracyRate — frecuencia con la que las facturas fueron incorrectas en los últimos 12 meses.
• contractSLAIssueRate — cuántas veces se incumplió un SLA en los últimos 12 meses.
• contractBudgetCostRate — variación porcentual del costo unitario por encima del precio de la orden de compra acordado.
• contractSourcingCycleDays — días desde el inicio del abastecimiento hasta la firma del contrato.

Medidas de satisfacción

Estas son calificaciones más subjetivas y orientadas a las relaciones:

• satisfactionCustomerServiceRank — cómo se enrutan y resuelven los problemas de administración de cuentas.
• satisfactionTechnicalSupportRank — cómo se califican la capacitación y la documentación.
• satisfactionEthicsRank — prácticas laborales, condiciones de trabajo seguras y elegibilidad de distribución.

Medidas competitivas

Estas capturan cómo el proveedor se compara con las alternativas:

• competitiveCostAvoidanceRank — valor entregado a través de capacitación gratuita, entrega y concesiones similares.
• competitiveMarketingRank — grado de buena voluntad asociado con el proveedor.
• competitiveProductPriceRank — probabilidad de recibir primeros o mejores precios durante la vida de la relación.
• competitiveWarrantyRank — garantía proporcionada en relación con otros proveedores.

Luego, cada categoría contribuye con competitiveWeightPercent / competitiveWeightScore, contractWeightPercent / contractWeightScore y satisfactionWeightPercent / satisfactionWeightScore al resumen.

Relacionado: Matillion — ELT push-down creado para almacenes de datos en la nube.

Un ejemplo trabajado

Supongamos que un equipo de adquisiciones pondera las tres categorías de la siguiente manera y asigna a cada una una puntuación de 0 a 100:

Categoría	Peso %	Puntuación	Contribución ponderada
Contrato	50	90	45.0
Satisfacción	20	80	16.0
Competitivo	30	70	21.0
Total (supplierScore)	100	—	82.0

La disciplina clave es que los tres valores de weightPercent deben sumar 100. CIM no exige esto, por lo que su implementación debe validarlo. Si no suman 100, la puntuación compuesta no tiene sentido como cifra normalizada.

Un enfoque de gobernanza común es fijar las ponderaciones de manera centralizada (digamos, 50/20/30) para que las puntuaciones sean comparables en toda la base de proveedores, y ajustar las ponderaciones solo para categorías de productos específicos donde las compensaciones realmente difieren.

Si estás de compras: Boomi AtomSphere — iPaaS empresarial para la integración híbrida de la nube a las instalaciones.

Cómo decidir: orientación práctica para los implementadores

Cuando adopte la entidad Supplier, algunas decisiones determinan si su cuadro de mando es confiable.

• Normalice antes de ponderar. Los campos de tasa bruta son porcentajes y recuentos en diferentes escalas. Convierta cada medida a una escala común de 0 a 100 (o de 0 a 1) antes de aplicar pesos, o un único conteo de alta magnitud prevalecerá.
• Decida la direccionalidad explícitamente. Para la mayoría de los campos, cuanto más alto es mejor, pero contractProductReturnRate, contractSLAIssueRate, contractInvoiceAccuracyRate (como “veces incorrecto”) y contractBudgetCostRate (como variación por encima del precio acordado) son de menor es mejor. Inviértalos durante la puntuación.
• Maneje los datos faltantes deliberadamente. Un nuevo proveedor no tiene un historial de 12 meses. Decida si excluir la categoría, imputar una puntuación neutral o marcar al proveedor como “datos insuficientes” en lugar de calificarlo silenciosamente como cero.
• Conserve las medidas brutas. Guarde las tasas subyacentes junto con la puntuación compuesta para poder volver a ponderarlas y auditarlas más adelante. Un único supplierScore sin procedencia no es defendible en una revisión de abastecimiento.
• Versione sus pesos. Si cambia los pesos, las puntuaciones históricas se vuelven incomparables. Registre el conjunto de pesos en vigor cuando se calculó cada puntuación.

Integración de datos de proveedores en todos los sistemas

Debido a que CIM es independiente de la aplicación, la entidad Supplier es más valiosa como objetivo canónico para la integración. Una canalización típica extrae maestros de proveedores de un ERP (SAP, Oracle, Microsoft Dynamics), datos de cuadros de mando de una herramienta de adquisiciones o SRM y banderas de transportistas de un sistema de gestión de transporte, y luego los asigna todos a la forma de Supplier de CIM.

• Asigne claves naturales a id. Cada sistema fuente tiene su propio número de proveedor; mantenga una tabla de referencias cruzadas con el GUID de CIM.
• Concilie a nivel de Party. Utilice la entidad Party como ancla de deduplicación para que la misma entidad jurídica no se cuente dos veces.
• Trate isCarrier como una sugerencia de ruta. La lógica logística posterior puede derivarse de él para aplicar un manejo específico del transportista.
• Publique el modelo como un contrato. Herramientas como dbt, Apache Atlas y catálogos de datos pueden documentar el mapeo de CIM para que los analistas sepan qué significa cada campo.

Para los equipos que formalizan esto, la naturaleza de código abierto de CIM significa que pueden bifurcar el modelo y agregar entidades o atributos que su negocio necesite —por ejemplo, un código de moneda para supplierSpend o una enumeración controlada para supplierType— manteniendo intacta la estructura principal de Party/Role. Los estándares relacionados con los que vale la pena alinearse incluyen el TM Forum Information Framework (SID) para patrones de party/role y GS1 para identificadores de productos y ubicaciones, ya que los datos de proveedores y productos frecuentemente viajan juntos.

Consideraciones de gobernanza y calidad de los datos

Un cuadro de mando de proveedores es tan bueno como los datos que lo alimentan, y los datos de los proveedores son notoriamente desordenados porque se originan en muchos sistemas y cambian con el tiempo.

• Propiedad. Asigne un administrador de datos para los datos maestros del proveedor; los campos del cuadro de mando a menudo tienen un propietario diferente (adquisiciones) que los campos de identidad (finanzas o MDM).
• Actualidad. Las ventanas de 12 meses en los campos de precisión de factura y SLA implican un recálculo continuo. Defina la cadencia de actualización y hágala visible.
• Auditabilidad. Debido a que las puntuaciones impulsan las decisiones de abastecimiento, mantenga un registro de auditoría de las entradas, ponderaciones y salidas calculadas.
• Ética y cumplimiento. El campo satisfactionEthicsRank aborda las prácticas laborales y las condiciones de trabajo seguras, áreas cada vez más sujetas a la regulación de debida diligencia de la cadena de suministro. Trátelo como una señal de cumplimiento, no solo como una calificación subjetiva.

Preguntas frecuentes

¿Qué es la entidad Supplier en el Cloud Information Model?

Supplier es un Party Role en CIM que describe a una parte que suministra bienes o servicios a la empresa. Hereda la identidad de la entidad Party y agrega atributos específicos del proveedor, como supplierType, isCarrier, supplierSpend y un cuadro de mando de rendimiento completo. Modelarlo como un rol en lugar de una entidad independiente permite que una parte actúe como proveedor y cliente sin duplicar los datos maestros.

¿Cómo se calcula el supplierScore?

El supplierScore combina tres categorías ponderadas: contrato, satisfacción y competitividad. Cada categoría aporta su weightPercent multiplicado por su weightScore, y los resultados se suman. Para que el compuesto sea significativo, los tres porcentajes de ponderación deben sumar 100, y cada medida subyacente debe normalizarse a una escala común antes de la ponderación.

¿Qué campos de Supplier son obligatorios?

Solo dos campos son obligatorios: id (una clave primaria GUID) y activeFromDate (la fecha en que la relación con el proveedor se volvió activa). Todo lo demás, incluidos activeToDate, supplierType y todos los atributos del cuadro de mando, es opcional, lo que permite cargar registros parciales de forma incremental.

¿Qué significa el flag isCarrier?

isCarrier es un booleano que es verdadero cuando el proveedor es un transportista, como FedEx o UPS. Proporciona una forma ligera para que la lógica de logística y envío identifique a los transportistas sin requerir una entidad o subtipo separado, manteniendo el modelo compacto.

¿Por qué la mayoría de los campos del cuadro de mando son enteros?

Los campos de tasa y rango están tipados como enteros, representando normalmente porcentajes o recuentos. Esto mantiene el modelo simple y portátil entre sistemas, pero significa que los implementadores deben decidir por sí mismos las convenciones de redondeo, escala y normalización en lugar de depender de que el esquema las imponga.

¿Puedo extender la entidad Supplier?

Sí. CIM es un modelo de código abierto destinado a ser adaptado, por lo que puede agregar atributos —por ejemplo, un código de moneda para supplierSpend o una enumeración controlada para supplierType— o agregar nuevas entidades. Las extensiones deben preservar la estructura central de Party/Party Role para que se mantenga la interoperabilidad con otros sistemas basados en CIM.