Modello informativo cloud

L’entità Supplier (Fornitore) nel Cloud Information Model (CIM) è un Party Role (Ruolo della Parte) specializzato: descrive una parte (un’organizzazione o un individuo) che svolge il ruolo di fornire beni o servizi all’impresa. Poiché il CIM separa la parte (l’identità durevole di un’azienda o di una persona) dal ruolo che svolge, la stessa parte può essere contemporaneamente un Cliente, un Fornitore e un Partner senza duplicare i dati anagrafici. Questa è la promessa fondamentale di interoperabilità del modello: un vocabolario condiviso e indipendente dall’applicazione che consente ai sistemi di approvvigionamento, ERP, logistica e analisi di concordare su cosa sia un “fornitore”.

L’entità Supplier presenta due ampie famiglie di attributi: identità e classificazione (chi è il fornitore) e punteggio delle prestazioni (quanto bene si comporta il fornitore). Gli attributi del punteggio sono raggruppati in tre categorie ponderate — contratto, soddisfazione e competitività — che confluiscono in un unico supplierScore. Comprendere come questi elementi si incastrano tra loro è essenziale per chiunque implementi scorecard dei fornitori, dati anagrafici dei fornitori o analisi degli approvvigionamenti su CIM.

Punti chiave

• Supplier è un Party Role, non un’entità autonoma. Eredita l’identità da Party e aggiunge attributi specifici del ruolo, in modo da non biforcare mai i dati anagrafici del fornitore da quelli del cliente.
• Il punteggio è un modello ponderato a tre categorie. Le misure di contratto, soddisfazione e competitività portano ciascuna un weightPercent e un weightScore; il supplierScore complessivo li combina.
• La maggior parte dei campi dei tassi è espressa come numeri interi che rappresentano percentuali o conteggi, il che mantiene il modello semplice ma sposta le decisioni di arrotondamento e normalizzazione all’implementazione.
• id e activeFromDate sono obbligatori. Ogni record del fornitore necessita di una chiave primaria GUID stabile e di una data di inizio per il suo periodo attivo.
• isCarrier è un flag di specializzazione leggero che consente alla logica logistica di identificare i trasportatori (ad esempio, FedEx, UPS) senza un’entità separata.
• CIM è progettato per essere esteso. Il modello è open source e destinato a essere biforcato e adattato, quindi considera questi attributi come un contratto di base, non uno schema chiuso.

Perché Supplier è modellato come un Party Role

La decisione progettuale più importante nel CIM è la suddivisione Party / Party Role, un modello presente anche in modelli aziendali consolidati come l’Information Framework (SID) del TM Forum e nella pratica di gestione dei dati master in generale. Un Party è l’elemento persistente: un’entità legale, un’organizzazione o una persona. Un Party Role è una relazione limitata nel tempo che tale parte ha con l’impresa.

Questo è importante perché le imprese reali ricoprono molti ruoli. Un produttore a contratto può venderti prodotti finiti (Supplier), acquistare componenti da te (Customer) e co-sviluppare un prodotto (Partner). Se li modelli come record separati, otterrai anagrafici fornitori/clienti duplicati, incubi di riconciliazione e gerarchie incoerenti. Rendendo Supplier un ruolo, il CIM consente di associare una singola Parte a più ruoli e mantenere un unico “golden record”.

Implicazioni pratiche:

• La deduplicazione avviene a livello di Party. Due record Supplier che puntano alla stessa Parte sono la stessa entità legale.
• I ruoli sono temporali. I campi activeFromDate e activeToDate consentono a una relazione con un fornitore di iniziare e terminare senza eliminare la cronologia.
• I dati specifici del ruolo rimangono legati al ruolo. La classifica del fornitore e le metriche della scorecard appartengono a Supplier, non a Party, perché hanno senso solo nel contesto del fornitore.

Attributi di identità e classificazione

Gli attributi di identità sono volutamente minimi, il che è tipico di un modello condiviso che deve mappare in modo pulito su molti sistemi di origine.

Correlato: Fivetran — La pipeline ELT completamente gestita che continua a funzionare.

• id (guid, obbligatorio) — la chiave primaria. L’utilizzo di un GUID anziché di una chiave naturale evita collisioni durante l’unione di record provenienti da più sistemi.
• activeFromDate (data, obbligatorio) — quando il rapporto con il fornitore è diventato attivo.
• activeToDate (data) — quando è terminato, se è accaduto.
• supplierType (stringa) — una classificazione in testo libero come Retailer, Distributor, Manufacturer o Merchant.
• isCarrier (booleano) — true quando il fornitore è un trasportatore come FedEx o UPS.
• supplierSpend (intero) — costo totale speso per l’acquisto di prodotti dal fornitore.

Una nota su supplierType: poiché è una stringa semplice, è un vocabolario controllato per convenzione, non per schema. In una distribuzione reale dovresti vincolarla con un’enumerazione o un elenco di dati di riferimento, altrimenti “Manufacturer”, “manufacturer” e “Mfg” frammenteranno i tuoi report. Questo è un classico compromesso nei modelli condivisi — flessibilità contro coerenza — e il CIM pende verso la flessibilità, aspettandosi che gli implementatori la restringano.

Allo stesso modo, supplierSpend come numero intero solleva una questione di valuta e scala. Il modello non specifica una valuta o una convenzione per le unità minori, pertanto è necessario decidere (ad esempio, memorizzare le unità minori e abbinare il campo a un codice valuta della propria estensione) prima di aggregare la spesa tra diverse regioni.

La scorecard del fornitore: contratto, soddisfazione e competitività

Il cuore dell’entità Supplier è la sua scorecard, un composto ponderato di tre categorie di misurazione. Ogni categoria ha un weightPercent (quanto conta nel totale) e un weightScore (il punteggio assegnato dopo l’analisi delle misure di quella categoria). Il supplierScore complessivo è definito come:

La nostra scelta: Workato — IPaaS basato sull'automazione su cui i team aziendali possono effettivamente basarsi.

(peso contratto × punteggio) + (peso soddisfazione × punteggio) + (percentuale peso costo/competitivo × punteggio)

Misure di performance del contratto

Queste sono metriche oggettive e operative legate al contratto di acquisto:

• contractOnTimeDeliveryRate — consegne puntuali rispetto alle date promesse ÷ consegne totali.
• contractDeliveryCorrectnessRate — consegne con quantità corretta ÷ consegne totali.
• contractProductQualityRate — percentuale di prodotti con difetti.
• contractProductReturnRate — percentuale di prodotti restituiti.
• contractInvoiceAccuracyRate — frequenza con cui le fatture erano errate negli ultimi 12 mesi.
• contractSLAIssueRate — quante volte un SLA è stato violato negli ultimi 12 mesi.
• contractBudgetCostRate — variazione percentuale del costo unitario rispetto al prezzo dell’ordine di acquisto concordato.
• contractSourcingCycleDays — giorni dall’inizio del sourcing alla firma del contratto.

Misure di soddisfazione

Queste sono valutazioni più soggettive e orientate alle relazioni:

• satisfactionCustomerServiceRank — come vengono indirizzati e risolti i problemi di gestione dell’account.
• satisfactionTechnicalSupportRank — come vengono valutate la formazione e la documentazione.
• satisfactionEthicsRank — pratiche di lavoro, condizioni di lavoro sicure e ammissibilità alla distribuzione.

Misure competitive

Queste catturano il modo in cui il fornitore si confronta con le alternative:

• competitiveCostAvoidanceRank — valore fornito attraverso formazione gratuita, consegna e concessioni simili.
• competitiveMarketingRank — grado di goodwill associato al fornitore.
• competitiveProductPriceRank — probabilità di ricevere i primi o i migliori prezzi nel corso della durata del rapporto.
• competitiveWarrantyRank — garanzia fornita rispetto ad altri fornitori.

Ciascuna categoria contribuisce quindi con competitiveWeightPercent / competitiveWeightScore, contractWeightPercent / contractWeightScore e satisfactionWeightPercent / satisfactionWeightScore al rollup.

Un esempio pratico

Supponiamo che un team di procurement pesi le tre categorie come segue e assegni a ciascuna un punteggio da 0 a 100:

Correlato: Matillion — ELT push-down creato per data warehouse su cloud.

Categoria	Peso %	Punteggio	Contributo ponderato
Contratto	50	90	45,0
Soddisfazione	20	80	16,0
Competitivo	30	70	21,0
Totale (supplierScore)	100	—	82,0

La disciplina chiave è che la somma dei tre valori weightPercent deve essere 100. CIM non lo impone, quindi la tua implementazione dovrebbe convalidarlo. Se non sommano a 100, il punteggio composito non ha significato come cifra normalizzata.

Un approccio di governance comune consiste nel fissare i pesi a livello centrale (ad esempio, 50/20/30) in modo che i punteggi siano comparabili in tutta la base fornitori, e adeguare i pesi solo per specifiche categorie di commodity in cui i compromessi differiscono effettivamente.

Come decidere: guida pratica per gli implementatori

Quando adotti l’entità Supplier, alcune decisioni determinano se la tua scorecard è affidabile.

Se stai facendo acquisti: Boomi AtomSphere — Enterprise iPaaS per l'integrazione ibrida da cloud a on-premise.

• Normalizza prima di pesare. I campi dei tassi grezzi sono percentuali e conteggi su scale diverse. Converti ogni misura in una scala comune 0–100 (o 0–1) prima di applicare i pesi, altrimenti un singolo conteggio di elevata grandezza prevarrà.
• Decidi esplicitamente la direzionalità. Per la maggior parte dei campi, più alto è meglio — ma contractProductReturnRate, contractSLAIssueRate, contractInvoiceAccuracyRate (come “volte errate”) e contractBudgetCostRate (come varianza rispetto al prezzo concordato) sono più basso è meglio. Invertili durante il calcolo del punteggio.
• Gestisci deliberatamente i dati mancanti. Un nuovo fornitore non ha uno storico di 12 mesi. Decidi se escludere la categoria, attribuire un punteggio neutro o contrassegnare il fornitore come “dati insufficienti” anziché assegnargli silenziosamente un punteggio pari a zero.
• Conserva le misure grezze. Memorizza i tassi sottostanti insieme al punteggio composito in modo da poterli riponderare e ri-auditare in seguito. Un singolo supplierScore senza provenienza non è difendibile in una revisione del sourcing.
• Versiona i tuoi pesi. Se cambi i pesi, i punteggi storici diventano incomparabili. Registra il set di pesi in vigore al momento del calcolo di ciascun punteggio.

Integrazione dei dati dei fornitori tra i sistemi

Poiché CIM è indipendente dall’applicazione, l’entità Supplier è estremamente preziosa come target canonico per l’integrazione. Una pipeline tipica estrae i master dei fornitori da un ERP (SAP, Oracle, Microsoft Dynamics), i dati delle scorecard da uno strumento di procurement o SRM e i flag del vettore da un sistema di gestione dei trasporti, per poi mapparli tutti sulla forma Supplier di CIM.

• Mappa le chiavi naturali su id. Ogni sistema sorgente ha il proprio numero di fornitore; mantieni una tabella di riferimenti incrociati al GUID di CIM.
• Riconcilia a livello di Party. Utilizza l’entità Party come ancora di deduplicazione in modo che la stessa entità legale non venga conteggiata due volte.
• Tratta isCarrier come un suggerimento di routing. La logica logistica a valle può ramificarsi su di esso per applicare una gestione specifica per i vettori.
• Pubblica il modello come contratto. Strumenti come dbt, Apache Atlas e i cataloghi di dati possono documentare la mappatura CIM in modo che gli analisti sappiano cosa significa ogni campo.

Per i team che formalizzano questo processo, la natura open source di CIM significa che puoi creare un fork del modello e aggiungere entità o attributi necessari per il tuo business — ad esempio, un codice valuta per supplierSpend o un’enumerazione controllata per supplierType — mantenendo intatta la struttura core Party/Role. Gli standard correlati a cui vale la pena allinearsi includono il TM Forum Information Framework (SID) per i pattern party/role e GS1 per gli identificatori di prodotto e di posizione, poiché i dati di fornitori e prodotti viaggiano spesso insieme.

Considerazioni sulla governance e sulla qualità dei dati

Una scorecard del fornitore è valida quanto i dati che la alimentano, e i dati dei fornitori sono notoriamente disordinati perché originano da molti sistemi e cambiano nel tempo.

• Proprietà. Assegna un data steward per i dati anagrafici dei fornitori; i campi della scorecard hanno spesso un proprietario diverso (procurement) rispetto ai campi di identità (finanza o MDM).
• Freschezza. Le finestre di 12 mesi nei campi di precisione delle fatture e SLA implicano un ricalcolo rolling. Definisci la cadenza di aggiornamento e rendila visibile.
• Auditabilità. Poiché i punteggi guidano le decisioni di sourcing, mantieni una traccia di audit degli input, dei pesi e degli output calcolati.
• Etica e conformità. Il campo satisfactionEthicsRank tocca le pratiche di lavoro e le condizioni di lavoro sicure — aree sempre più soggette a normative di due diligence della supply chain. Trattalo come un segnale di conformità, non solo come una valutazione qualitativa.

Domande frequenti

Cos’è l’entità Supplier nel Cloud Information Model?

Supplier è un Party Role in CIM che descrive una parte che fornisce beni o servizi all’impresa. Eredita l’identità dall’entità Party e aggiunge attributi specifici del fornitore come supplierType, isCarrier, supplierSpend e una scorecard completa delle prestazioni. Modellarlo come un ruolo piuttosto che come un’entità autonoma consente a una parte di agire sia come fornitore che come cliente senza duplicare i dati anagrafici.

Come viene calcolato il supplierScore?

Il supplierScore combina tre categorie ponderate: contratto, soddisfazione e competitività. Ogni categoria contribuisce con il proprio weightPercent moltiplicato per il proprio weightScore, e i risultati vengono sommati. Affinché il valore composito sia significativo, le tre percentuali di peso dovrebbero sommare a 100 e ogni misura sottostante dovrebbe essere normalizzata su una scala comune prima della ponderazione.

Quali campi di Supplier sono obbligatori?

Solo due campi sono obbligatori: id (una chiave primaria GUID) e activeFromDate (la data in cui la relazione con il fornitore è diventata attiva). Tutto il resto, inclusi activeToDate, supplierType e tutti gli attributi della scorecard, è opzionale, il che consente il caricamento incrementale di record parziali.

Cosa significa il flag isCarrier?

isCarrier è un booleano che è vero quando il fornitore è un vettore di trasporto, come FedEx o UPS. Fornisce un modo leggero per la logistica e la logica di spedizione per identificare i vettori senza richiedere un’entità o un sottotipo separato, mantenendo il modello compatto.

Perché la maggior parte dei campi della scorecard sono interi?

I campi di tasso (rate) e classificazione (rank) sono tipizzati come interi, rappresentando in genere percentuali o conteggi. Ciò mantiene il modello semplice e portabile tra i sistemi, ma significa che gli implementatori devono decidere autonomamente le convenzioni di arrotondamento, scala e normalizzazione, invece di fare affidamento sullo schema per imporle.

Posso estendere l’entità Supplier?

Sì. CIM è un modello open-source destinato a essere adattato, quindi è possibile aggiungere attributi — ad esempio un codice valuta per supplierSpend o un’enumerazione controllata per supplierType — o aggiungere nuove entità. Le estensioni dovrebbero preservare la struttura core Party/Party Role in modo che l’interoperabilità con altri sistemi basati su CIM sia mantenuta.