Modelo de Informações em Nuvem

A entidade Fornecedor no Cloud Information Model (CIM) é uma Função da Parte (Party Role) especializada — ela descreve uma parte (uma organização ou indivíduo) que desempenha a função de fornecer bens ou serviços para a empresa. Como o CIM separa a parte (a identidade durável de uma empresa ou pessoa) da função que ela desempenha, a mesma parte pode ser simultaneamente um Cliente, um Fornecedor e um Parceiro sem duplicar dados mestres. Esta é a principal promessa de interoperabilidade do modelo: um vocabulário compartilhado e independente de aplicações que permite que sistemas de compras, ERP, logística e análise concordem sobre o que é um “fornecedor”.

A entidade Fornecedor carrega duas grandes famílias de atributos: identidade e classificação (quem é o fornecedor) e pontuação de desempenho (quão bem o fornecedor desempenha suas funções). Os atributos de pontuação são agrupados em três categorias ponderadas – contrato, satisfação e competitividade – que se consolidam em um único supplierScore. Compreender como essas peças se encaixam é essencial para qualquer pessoa que implemente scorecards de fornecedores, dados mestres de fornecedores ou análises de compras sobre o CIM.

Principais Conclusões

• Fornecedor é uma Função da Parte, não uma entidade autônoma. Ele herda a identidade da Parte e adiciona atributos específicos da função, para que você nunca bifurque dados mestres de fornecedores a partir de dados mestres de clientes.
• A pontuação é um modelo ponderado de três categorias. As medidas de contrato, satisfação e competitividade carregam, cada uma, um weightPercent e um weightScore; o supplierScore geral as combina.
• A maioria dos campos de taxa é expressa como números inteiros representando porcentagens ou contagens, o que mantém o modelo simples, mas transfere as decisões de arredondamento e normalização para a implementação.
• id e activeFromDate são obrigatórios. Todo registro de fornecedor precisa de uma chave primária GUID estável e uma data de início para seu período ativo.
• isCarrier é um sinalizador de especialização leve que permite que a lógica de logística identifique transportadoras (ex: FedEx, UPS) sem a necessidade de uma entidade separada.
• O CIM foi projetado para ser estendido. O modelo é de código aberto e destinado a ser bifurcado e adaptado; portanto, trate esses atributos como um contrato de linha de base, não como um esquema fechado.

Por que o Fornecedor é Modelado como uma Função da Parte

A decisão de design mais importante no CIM é a divisão Parte / Função da Parte, um padrão também encontrado em modelos empresariais estabelecidos, como o Information Framework (SID) do TM Forum e na prática geral de gestão de dados mestres. Uma Parte é a coisa persistente — uma entidade legal, uma organização ou uma pessoa. Uma Função da Parte é um relacionamento com limite temporal que essa parte tem com a empresa.

Isso é importante porque empresas reais desempenham muitos papéis. Um fabricante contratado pode vender produtos acabados (Fornecedor), comprar componentes de você (Cliente) e co-desenvolver um produto (Parceiro).

Se você modelar cada um como um registro separado, terá duplicatas de mestres de fornecedores/clientes, pesadelos de reconciliação e hierarquias inconsistentes. Ao tornar o Fornecedor uma função, o CIM permite vincular uma única Parte a múltiplas funções e manter um único registro mestre (“golden record”).

Implicações práticas:

Related: Fivetran — O pipeline ELT totalmente gerenciado que continua funcionando.

• A desduplicação ocorre no nível da Parte. Dois registros de Fornecedor que apontam para a mesma Parte são a mesma entidade legal.
• As funções são temporais. Os campos activeFromDate e activeToDate permitem que um relacionamento de fornecedor comece e termine sem excluir o histórico.
• Os dados específicos da função permanecem com a função. O ranking de fornecedores e as métricas de scorecard pertencem ao Fornecedor, não à Parte, porque só fazem sentido no contexto de fornecimento.

Atributos de Identidade e Classificação

Os atributos de identidade são deliberadamente mínimos, o que é típico de um modelo compartilhado que deve ser mapeado de forma limpa em muitos sistemas de origem.

• id (guid, obrigatório) — a chave primária. Usar um GUID em vez de uma chave natural evita colisões ao mesclar registros de vários sistemas.
• activeFromDate (data, obrigatório) — quando o relacionamento com o fornecedor tornou-se ativo.
• activeToDate (data) — quando terminou, se for o caso.
• supplierType (string) — uma classificação de texto livre, como Varejista, Distribuidor, Fabricante ou Comerciante.
• isCarrier (booleano) — verdadeiro quando o fornecedor é uma transportadora, como FedEx ou UPS.
• supplierSpend (inteiro) — custo total gasto na aquisição de produtos do fornecedor.

Uma observação sobre supplierType: por ser uma string simples, é um vocabulário controlado por convenção, não por esquema. Em uma implantação real, você deve restringi-lo com uma enumeração ou lista de dados de referência; caso contrário, “Fabricante”, “fabricante” e “Mfg” fragmentarão seus relatórios. Este é um compromisso clássico em modelos compartilhados — flexibilidade versus consistência — e o CIM inclina-se para a flexibilidade, esperando que os implementadores a reforcem.

Da mesma forma, supplierSpend como um número inteiro levanta uma questão de moeda e escala. O modelo não especifica uma moeda ou convenção de unidades menores, portanto, você deve decidir (por exemplo, armazenar unidades menores e emparelhar o campo com um código de moeda de sua própria extensão) antes de agregar os gastos entre regiões.

Se você estiver comprando: Boomi AtomSphere — Enterprise iPaaS para integração híbrida de nuvem local.

O Scorecard do Fornecedor: Contrato, Satisfação e Competitividade

O coração da entidade Fornecedor é seu scorecard, um composto ponderado de três categorias de medição. Cada categoria tem um weightPercent (quanto ela conta para o total) e um weightScore (a pontuação atribuída após a análise das medidas daquela categoria). O supplierScore geral é definido como:

(peso do contrato × pontuação) + (peso de satisfação × pontuação) + (porcentagem de peso de custo/competitividade × pontuação)

Medidas de desempenho do contrato

Estas são métricas operacionais objetivas vinculadas ao contrato de compra:

• contractOnTimeDeliveryRate — entregas no prazo em relação às datas prometidas ÷ total de entregas.
• contractDeliveryCorrectnessRate — entregas com quantidade correta ÷ total de entregas.
• contractProductQualityRate — porcentagem de produtos com defeitos.
• contractProductReturnRate — porcentagem de produtos devolvidos.
• contractInvoiceAccuracyRate — frequência com que as faturas estavam incorretas nos últimos 12 meses.
• contractSLAIssueRate — quantas vezes um SLA foi descumprido nos últimos 12 meses.
• contractBudgetCostRate — variação percentual do custo unitário acima do preço do pedido de compra acordado.
• contractSourcingCycleDays — dias desde o início do sourcing até a assinatura do contrato.

Medidas de satisfação

Estas são classificações mais subjetivas e orientadas ao relacionamento:

• satisfactionCustomerServiceRank — como os problemas de gestão de contas são encaminhados e resolvidos.
• satisfactionTechnicalSupportRank — como o treinamento e a documentação são avaliados.
• satisfactionEthicsRank — práticas trabalhistas, condições de trabalho seguras e elegibilidade de distribuição.

Medidas competitivas

Estas capturam como o fornecedor se compara a alternativas:

• competitiveCostAvoidanceRank — valor entregue por meio de treinamento gratuito, entrega e concessões semelhantes.
• competitiveMarketingRank — grau de goodwill associado ao fornecedor.
• competitiveProductPriceRank — probabilidade de receber os primeiros ou melhores preços ao longo da vida do relacionamento.
• competitiveWarrantyRank — garantia fornecida em relação a outros fornecedores.

Cada categoria então contribui com competitiveWeightPercent / competitiveWeightScore, contractWeightPercent / contractWeightScore e satisfactionWeightPercent / satisfactionWeightScore para o rollup.

Related: Matillion — ELT push-down desenvolvido para data warehouses em nuvem.

Um exemplo prático

Suponha que uma equipe de compras pondere as três categorias da seguinte forma e atribua a cada uma uma pontuação de 0 a 100:

Categoria	Peso %	Pontuação	Contribuição ponderada
Contrato	50	90	45,0
Satisfação	20	80	16,0
Competitivo	30	70	21,0
Total (supplierScore)	100	—	82,0

A disciplina fundamental é que os três valores weightPercent devem somar 100. O CIM não impõe isso, portanto, sua implementação deve validá-lo. Se não somarem 100, a pontuação composta não terá sentido como um valor normalizado.

Uma abordagem comum de governança é fixar os pesos centralmente (por exemplo, 50/20/30) para que as pontuações sejam comparáveis em toda a base de fornecedores, e ajustar os pesos apenas para categorias específicas de mercadorias onde as compensações realmente difiram.

Favorito do leitor: Airbyte — ELT de código aberto com opção de nuvem gerenciada.

Como Decidir: Orientação Prática para Implementadores

Ao adotar a entidade Supplier, algumas decisões determinam se o seu scorecard é confiável.

• Normalize antes de ponderar. Os campos de taxa bruta são porcentagens e contagens em escalas diferentes. Converta cada medida para uma escala comum de 0 a 100 (ou 0 a 1) antes de aplicar os pesos, caso contrário, uma única contagem de alta magnitude dominará.
• Decida a direcionalidade explicitamente. Para a maioria dos campos, quanto maior, melhor — mas contractProductReturnRate, contractSLAIssueRate, contractInvoiceAccuracyRate (como “vezes incorretas”) e contractBudgetCostRate (como variação acima do preço acordado) são quanto menor, melhor. Inverta-os durante a pontuação.
• Trate dados ausentes deliberadamente. Um novo fornecedor não possui histórico de 12 meses. Decida se deve excluir a categoria, imputar uma pontuação neutra ou sinalizar o fornecedor como “dados insuficientes” em vez de pontuá-lo silenciosamente como zero.
• Mantenha as medidas brutas. Armazene as taxas subjacentes junto com a pontuação composta para que você possa reponderar e reauditar posteriormente. Um único supplierScore sem procedência não é defensável em uma revisão de sourcing.
• Versione seus pesos. Se você alterar os pesos, as pontuações históricas tornam-se incomparáveis. Registre o conjunto de pesos em vigor quando cada pontuação foi computada.

Integrando Dados de Fornecedores Entre Sistemas

Como o CIM é agnóstico em relação à aplicação, a entidade Supplier é mais valiosa como um alvo canônico para integração. Um pipeline típico extrai dados mestres de fornecedores de um ERP (SAP, Oracle, Microsoft Dynamics), dados de scorecard de uma ferramenta de procurement ou SRM e sinalizadores de transportadora de um sistema de gestão de transporte, mapeando todos eles para a forma Supplier do CIM.

• Mapeie chaves naturais para id. Cada sistema de origem tem seu próprio número de fornecedor; mantenha uma tabela de referência cruzada para o GUID do CIM.
• Reconcilie no nível da Party. Use a entidade Party como âncora de desduplicação para que a mesma entidade legal não seja contada duas vezes.
• Trate isCarrier como uma dica de roteamento. A lógica de logística downstream pode ramificar-se com base nisso para aplicar o manuseio específico de transportadoras.
• Publique o modelo como um contrato. Ferramentas como dbt, Apache Atlas e catálogos de dados podem documentar o mapeamento do CIM para que os analistas saibam o que cada campo significa.

Para equipes que estão formalizando isso, a natureza de código aberto do CIM significa que você pode fazer um fork do modelo e adicionar entidades ou atributos que seu negócio precise — por exemplo, um código de moeda para supplierSpend ou uma enumeração controlada para supplierType — mantendo intacta a estrutura central de Party/Role. Padrões relacionados que valem a pena alinhar incluem o TM Forum Information Framework (SID) para padrões de party/role e o GS1 para identificadores de produtos e locais, já que dados de fornecedores e produtos frequentemente trafegam juntos.

Considerações de Governança e Qualidade de Dados

Um scorecard de fornecedor é tão bom quanto os dados que o alimentam, e os dados de fornecedores são notoriamente desorganizados porque se originam em muitos sistemas e mudam com o tempo.

• Propriedade. Atribua um data steward para os dados mestres de fornecedores; os campos do scorecard geralmente têm um proprietário diferente (procurement) do que os campos de identidade (finanças ou MDM).
• Atualidade. As janelas de 12 meses nos campos de precisão de fatura e SLA implicam recálculo contínuo. Defina a cadência de atualização e torne-a visível.
• Auditabilidade. Como as pontuações orientam decisões de sourcing, mantenha uma trilha de auditoria de entradas, pesos e saídas computadas.
• Ética e conformidade. O campo satisfactionEthicsRank aborda práticas trabalhistas e condições de trabalho seguras — áreas cada vez mais sujeitas a regulamentações de due diligence da cadeia de suprimentos. Trate-o como um sinal de conformidade, não apenas como uma avaliação subjetiva.

Perguntas Frequentes

O que é a entidade Supplier no Cloud Information Model?

Supplier é uma Party Role no CIM que descreve uma parte que fornece bens ou serviços à empresa. Ela herda a identidade da entidade Party e adiciona atributos específicos do fornecedor, como supplierType, isCarrier, supplierSpend e um scorecard de desempenho completo. Modelá-la como uma role em vez de uma entidade autônoma permite que uma parte atue tanto como fornecedor quanto como cliente sem duplicidade de dados mestres.

Como é calculado o supplierScore?

O supplierScore combina três categorias ponderadas: contrato, satisfação e competitividade. Cada categoria contribui com seu weightPercent multiplicado por seu weightScore, e os resultados são somados. Para que o composto seja significativo, as três porcentagens de peso devem somar 100, e cada medida subjacente deve ser normalizada para uma escala comum antes da ponderação.

Quais campos de Supplier são obrigatórios?

Apenas dois campos são obrigatórios: id (uma chave primária GUID) e activeFromDate (a data em que o relacionamento com o fornecedor tornou-se ativo). Todo o resto, incluindo activeToDate, supplierType e todos os atributos do scorecard, é opcional, o que permite que registros parciais sejam carregados incrementalmente.

O que significa a flag isCarrier?

isCarrier é um booleano que é verdadeiro quando o fornecedor é uma transportadora, como FedEx ou UPS. Ele fornece uma maneira leve para a logística e a lógica de envio identificarem transportadoras sem exigir uma entidade ou subtipo separado, mantendo o modelo compacto.

Por que a maioria dos campos do scorecard são inteiros?

Os campos de taxa (rate) e classificação (rank) são tipados como inteiros, normalmente representando porcentagens ou contagens. Isso mantém o modelo simples e portátil entre sistemas, mas significa que os implementadores devem decidir por conta própria as convenções de arredondamento, escala e normalização, em vez de depender do esquema para impô-las.

Posso estender a entidade Supplier?

Sim. O CIM é um modelo de código aberto destinado a ser adaptado, portanto você pode adicionar atributos — por exemplo, um código de moeda para supplierSpend ou uma enumeração controlada para supplierType — ou adicionar novas entidades. As extensões devem preservar a estrutura central de Party/Party Role para que a interoperabilidade com outros sistemas baseados em CIM seja mantida.