Cloud-Informationsmodell

Die Entität Supplier (Lieferant) im Cloud Information Model (CIM) ist eine spezialisierte Party Role (Parteirolle) – sie beschreibt eine Partei (eine Organisation oder Einzelperson), die die Rolle der Lieferung von Waren oder Dienstleistungen an das Unternehmen übernimmt. Da CIM die Party (die dauerhafte Identität eines Unternehmens oder einer Person) von der Role (Rolle) trennt, die sie spielt, kann dieselbe Partei gleichzeitig Customer, Supplier und Partner sein, ohne dass Stammdaten dupliziert werden. Dies ist das zentrale Interoperabilitätsversprechen des Modells: ein gemeinsames, anwendungsunabhängiges Vokabular, das es Beschaffungs-, ERP-, Logistik- und Analysesystemen ermöglicht, sich darüber zu einigen, was ein „Supplier“ ist.

Die Supplier-Entität umfasst zwei große Familien von Attributen: Identität und Klassifizierung (wer der Lieferant ist) und Leistungsbewertung (wie gut der Lieferant abschneidet). Die Bewertungsattribute sind in drei gewichtete Kategorien gruppiert – Vertrag, Zufriedenheit und Wettbewerb –, die in einem einzigen supplierScore zusammengefasst werden. Für jeden, der Supplier-Scorecards, Lieferantenstammdaten oder Beschaffungsanalysen auf Basis von CIM implementiert, ist es essenziell zu verstehen, wie diese Teile zusammenpassen.

Wichtige Erkenntnisse

• Supplier ist eine Party Role, keine eigenständige Entität. Sie erbt die Identität von Party und fügt rollenspezifische Attribute hinzu, sodass Sie Lieferantenstammdaten niemals von Kundenstammdaten abspalten (fork).
• Die Bewertung ist ein gewichtetes Modell mit drei Kategorien. Vertrags-, Zufriedenheits- und Wettbewerbsmaße verfügen jeweils über einen weightPercent und einen weightScore; der gesamte supplierScore kombiniert diese.
• Die meisten Rate-Felder werden als Ganzzahlen (Integers) ausgedrückt, die Prozentsätze oder Zählungen darstellen, wodurch das Modell einfach bleibt, Rundungs- und Normalisierungsentscheidungen jedoch in die Implementierung verlagert werden.
• id und activeFromDate sind obligatorisch. Jeder Supplier-Datensatz benötigt einen stabilen GUID-Primärschlüssel und ein Startdatum für seinen aktiven Zeitraum.
• isCarrier ist ein leichtgewichtiges Spezialisierungs-Flag, mit dem die Logistiklogik Transportunternehmen (z. B. FedEx, UPS) ohne separate Entität identifizieren kann.
• CIM ist für Erweiterungen konzipiert. Das Modell ist Open Source und dazu gedacht, geforkt und angepasst zu werden; behandeln Sie diese Attribute daher als Basisvertrag und nicht als geschlossenes Schema.

Warum Supplier als Party Role modelliert wird

Die wichtigste Designentscheidung in CIM ist die Aufteilung Party / Party Role, ein Muster, das auch in etablierten Unternehmensmodellen wie dem Information Framework (SID) des TM Forums und allgemein in der Stammdatenverwaltung zu finden ist. Eine Party ist das persistente Objekt – eine juristische Person, eine Organisation oder eine Person. Eine Party Role ist eine zeitlich begrenzte Beziehung, die diese Partei zum Unternehmen unterhält.

Dies ist wichtig, weil Unternehmen in der Realität viele Rollen einnehmen. Ein Lohnfertiger kann Ihnen Fertigwaren verkaufen (Supplier), Komponenten von Ihnen kaufen (Customer) und gemeinsam ein Produkt entwickeln (Partner).

Wenn Sie jeden als separaten Datensatz modellieren, erhalten Sie doppelte Lieferanten-/Kundenstammdaten, Abstimmungsalbträume und inkonsistente Hierarchien. Indem CIM den Supplier zu einer Rolle macht, können Sie eine einzelne Party mehreren Rollen zuordnen und einen einzigen „Golden Record“ führen.

Praktische Implikationen:

Verwandte: Fivetran — Die vollständig verwaltete ELT-Pipeline, die einfach weiterläuft.

• Die Deduplizierung erfolgt auf Party-Ebene. Zwei Supplier-Datensätze, die auf dieselbe Party verweisen, sind dieselbe juristische Person.
• Rollen sind temporal. Die Felder activeFromDate und activeToDate ermöglichen es, dass eine Lieferantenbeziehung beginnt und endet, ohne die Historie zu löschen.
• Rollenspezifische Daten bleiben bei der Rolle. Lieferanten-Rankings und Scorecard-Metriken gehören zum Supplier, nicht zur Party, da sie nur im Kontext des Lieferanten sinnvoll sind.

Identitäts- und Klassifizierungsattribute

Die Identitätsattribute sind bewusst minimal gehalten, was typisch für ein gemeinsames Modell ist, das sauber auf viele Quellsysteme abgebildet werden muss.

• id (guid, obligatorisch) – der Primärschlüssel. Die Verwendung einer GUID anstelle eines natürlichen Schlüssels vermeidet Kollisionen beim Zusammenführen von Datensätzen aus mehreren Systemen.
• activeFromDate (date, obligatorisch) – wann die Lieferantenbeziehung aktiv wurde.
• activeToDate (date) – wann sie endete, falls dies der Fall ist.
• supplierType (string) – eine Freitext-Klassifizierung wie Retailer, Distributor, Manufacturer oder Merchant.
• isCarrier (boolean) – true, wenn der Lieferant ein Transportunternehmen wie FedEx oder UPS ist.
• supplierSpend (integer) – Gesamtkosten für die Beschaffung von Produkten vom Lieferanten.

Ein Hinweis zu supplierType: Da es sich um einen einfachen String handelt, ist es ein kontrolliertes Vokabular durch Konvention, nicht durch Schema. In einer realen Bereitstellung sollten Sie es mit einer Aufzählung (Enumeration) oder einer Referenzdatenliste einschränken, da ansonsten „Manufacturer“, „manufacturer“ und „Mfg“ Ihre Berichterstattung fragmentieren. Dies ist ein klassischer Kompromiss bei gemeinsamen Modellen – Flexibilität gegenüber Konsistenz – und CIM tendiert zur Flexibilität und erwartet von den Implementierern, diese zu präzisieren.

Ähnlich wirft supplierSpend als Integer Fragen zu Währung und Skalierung auf. Das Modell spezifiziert keine Währung oder Konvention für kleinste Einheiten (minor units), daher müssen Sie dies entscheiden (z. B. kleinste Einheiten speichern und das Feld mit einem Währungscode aus Ihrer eigenen Erweiterung koppeln), bevor Sie Ausgaben über Regionen hinweg aggregieren.

Wenn Sie einkaufen: Boomi AtomSphere — Enterprise iPaaS für die Hybrid-Cloud-to-On-Premise-Integration.

Die Supplier-Scorecard: Vertrag, Zufriedenheit und Wettbewerbsfähigkeit

Das Herzstück der Supplier-Entität ist ihre Scorecard, eine gewichtete Zusammensetzung aus drei Messkategorien. Jede Kategorie hat einen weightPercent (wie stark sie in die Gesamtsumme einfließt) und einen weightScore (die Punktzahl, die zugewiesen wird, nachdem die Maße dieser Kategorie analysiert wurden). Der gesamte supplierScore ist definiert als:

(Vertragsgewicht × Punktzahl) + (Zufriedenheitsgewicht × Punktzahl) + (Kosten-/Wettbewerbsgewichtsprozentsatz × Punktzahl)

Vertragliche Leistungsmaße

Dies sind objektive, operative Kennzahlen, die an die Kaufvereinbarung gebunden sind:

• contractOnTimeDeliveryRate — pünktliche Lieferungen gegenüber versprochenen Terminen ÷ Gesamtlieferungen.
• contractDeliveryCorrectnessRate — Lieferungen mit korrekter Menge ÷ Gesamtlieferungen.
• contractProductQualityRate — Prozentsatz der Produkte mit Mängeln.
• contractProductReturnRate — Prozentsatz der zurückgegebenen Produkte.
• contractInvoiceAccuracyRate — wie oft Rechnungen in den letzten 12 Monaten fehlerhaft waren.
• contractSLAIssueRate — wie oft ein SLA in den letzten 12 Monaten gebrochen wurde.
• contractBudgetCostRate — prozentuale Abweichung der Stückkosten über dem vereinbarten Bestellpreis.
• contractSourcingCycleDays — Tage vom Beginn der Beschaffung bis zur Vertragsunterzeichnung.

Zufriedenheitsmessungen

Dies sind eher subjektive, beziehungsorientierte Bewertungen:

• satisfactionCustomerServiceRank — wie Probleme im Account-Management weitergeleitet und gelöst werden.
• satisfactionTechnicalSupportRank — wie Schulungen und Dokumentationen bewertet werden.
• satisfactionEthicsRank — Arbeitspraktiken, sichere Arbeitsbedingungen und Vertriebsberechtigung.

Wettbewerbsmessungen

Diese erfassen, wie der Lieferant im Vergleich zu Alternativen abschneidet:

• competitiveCostAvoidanceRank — Mehrwert durch kostenlose Schulungen, Lieferung und ähnliche Zugeständnisse.
• competitiveMarketingRank — Grad des mit dem Lieferanten verbundenen Goodwills.
• competitiveProductPriceRank — Wahrscheinlichkeit, im Laufe der Beziehungsdauer die ersten oder besseren Preise zu erhalten.
• competitiveWarrantyRank — bereitgestellte Garantie im Vergleich zu anderen Lieferanten.

Jede Kategorie trägt dann competitiveWeightPercent / competitiveWeightScore, contractWeightPercent / contractWeightScore und satisfactionWeightPercent / satisfactionWeightScore zum Rollup bei.

Verwandte: Matillion — Push-Down-ELT für Cloud-Data-Warehouses.

Ein praxisnahes Beispiel

Angenommen, ein Beschaffungsteam gewichtet die drei Kategorien wie folgt und weist jeder eine Punktzahl von 0–100 zu:

Kategorie	Gewicht %	Score	Gewichteter Beitrag
Vertrag	50	90	45,0
Zufriedenheit	20	80	16,0
Wettbewerb	30	70	21,0
Gesamt (supplierScore)	100	—	82,0

Die entscheidende Disziplin besteht darin, dass die drei weightPercent-Werte zusammen 100 ergeben müssen. CIM erzwingt dies nicht, daher sollte Ihre Implementierung dies validieren.

Wenn sie nicht 100 ergeben, ist der zusammengesetzte Score als normalisierter Wert bedeutungslos. Ein gängiger Governance-Ansatz besteht darin, die Gewichte zentral festzulegen (z. B. 50/20/30), sodass die Scores über die gesamte Lieferantenbasis hinweg vergleichbar sind, und die Gewichte nur für spezifische Warenkategorien anzupassen, bei denen die Trade-offs tatsächlich unterschiedlich sind.

Leserfavorit: Airbyte — Open-Source-ELT mit einer Managed-Cloud-Option.

Entscheidungshilfe: Praktische Anleitung für Implementierer

Wenn Sie die Supplier-Entität übernehmen, bestimmen einige Entscheidungen, ob Ihre Scorecard vertrauenswürdig ist.

• Normalisieren Sie, bevor Sie gewichten. Die Rohratenfelder sind Prozentsätze und Zählwerte auf unterschiedlichen Skalen. Konvertieren Sie jedes Maß in eine gemeinsame Skala von 0–100 (oder 0–1), bevor Sie Gewichte anwenden, da sonst ein einzelner Zählwert mit hoher Größenordnung dominieren wird.
• Legen Sie die Richtung explizit fest. Für die meisten Felder ist ein höherer Wert besser – aber contractProductReturnRate, contractSLAIssueRate, contractInvoiceAccuracyRate (als „Häufigkeit von Fehlern“) und contractBudgetCostRate (als Abweichung über dem vereinbarten Preis) sind „je niedriger, desto besser“. Invertieren Sie diese bei der Bewertung.
• Gehen Sie bewusst mit fehlenden Daten um. Ein neuer Lieferant hat keine 12-Monats-Historie. Entscheiden Sie, ob Sie die Kategorie ausschließen, einen neutralen Score imputieren oder den Lieferanten als „unzureichende Daten“ kennzeichnen, anstatt ihn stillschweigend mit Null zu bewerten.
• Behalten Sie die Rohmaße bei. Speichern Sie die zugrunde liegenden Raten zusammen mit dem zusammengesetzten Score, damit Sie diese später neu gewichten und prüfen können. Ein einzelner supplierScore ohne Herkunftsnachweis ist in einer Beschaffungsprüfung nicht vertretbar.
• Versionieren Sie Ihre Gewichte. Wenn Sie Gewichte ändern, werden historische Scores unvergleichbar. Protokollieren Sie den Gewichtungssatz, der zum Zeitpunkt der Berechnung jedes Scores gültig war.

Integration von Lieferantendaten über Systeme hinweg

Da CIM anwendungsagnostisch ist, ist die Supplier-Entität am wertvollsten als kanonisches Ziel für die Integration. Eine typische Pipeline ruft Lieferantenstammdaten aus einem ERP (SAP, Oracle, Microsoft Dynamics), Scorecard-Daten aus einem Beschaffungs- oder SRM-Tool und Carrier-Flags aus einem Transportmanagementsystem ab und bildet diese dann alle auf die CIM-Supplier-Struktur ab.

• Natürliche Schlüssel der id zuordnen. Jedes Quellsystem hat seine eigene Lieferantennummer; pflegen Sie eine Querverweistabelle zur CIM-GUID.
• Abgleich auf Party-Ebene. Verwenden Sie die Party-Entität als Deduplizierungsanker, damit dieselbe juristische Person nicht zweimal gezählt wird.
• Behandeln Sie isCarrier als Routing-Hinweis. Die nachgelagerte Logistiklogik kann darauf verzweigen, um eine carrierspezifische Handhabung anzuwenden.
• Veröffentlichen Sie das Modell als Vertrag. Tools wie dbt, Apache Atlas und Datenkataloge können das CIM-Mapping dokumentieren, sodass Analysten wissen, was jedes Feld bedeutet.

Für Teams, die dies formalisieren: Die Open-Source-Natur von CIM bedeutet, dass Sie das Modell forken und Entitäten oder Attribute hinzufügen können, die Ihr Unternehmen benötigt – zum Beispiel einen Währungscode für supplierSpend oder eine kontrollierte Aufzählung für supplierType – während die Kernstruktur von Party/Role intakt bleibt. Zu den verwandten Standards, an denen man sich orientieren sollte, gehören das TM Forum Information Framework (SID) für Party/Role-Muster und GS1 für Produkt- und Standortkennungen, da Lieferanten- und Produktdaten häufig gemeinsam übertragen werden.

Überlegungen zu Governance und Datenqualität

Eine Lieferanten-Scorecard ist nur so gut wie die Daten, die sie speisen, und Lieferantendaten sind bekanntermaßen unübersichtlich, da sie aus vielen Systemen stammen und sich im Laufe der Zeit ändern.

• Ownership. Weisen Sie einen Data Steward für Lieferantenstammdaten zu; Scorecard-Felder haben oft einen anderen Verantwortlichen (Beschaffung) als Identitätsfelder (Finanzen oder MDM).
• Aktualität. Die 12-Monats-Fenster in den Feldern für Rechnungsgenauigkeit und SLA implizieren eine rollierende Neuberechnung. Definieren Sie den Aktualisierungszyklus und machen Sie ihn sichtbar.
• Prüfbarkeit. Da Scores Beschaffungsentscheidungen steuern, führen Sie einen Audit-Trail über Eingaben, Gewichte und berechnete Ausgaben.
• Ethik und Compliance. Das Feld satisfactionEthicsRank betrifft Arbeitspraktiken und sichere Arbeitsbedingungen – Bereiche, die zunehmend Sorgfaltspflicht-Regulierungen in der Lieferkette unterliegen. Behandeln Sie dies als Compliance-Signal, nicht nur als weiche Bewertung.

Häufig gestellte Fragen

Was ist die Supplier-Entität im Cloud Information Model?

Supplier ist eine Party Role in CIM, die eine Partei beschreibt, die Waren oder Dienstleistungen an das Unternehmen liefert. Sie erbt die Identität von der Party-Entität und fügt lieferantenspezifische Attribute wie supplierType, isCarrier, supplierSpend und eine vollständige Performance-Scorecard hinzu. Die Modellierung als Rolle statt als eigenständige Entität ermöglicht es einer Partei, sowohl als Lieferant als auch als Kunde zu agieren, ohne dass doppelte Stammdaten entstehen.

Wie wird der supplierScore berechnet?

Der supplierScore kombiniert drei gewichtete Kategorien: Vertrag, Zufriedenheit und Wettbewerbsfähigkeit. Jede Kategorie trägt ihren weightPercent multipliziert mit ihrem weightScore bei, und die Ergebnisse werden summiert. Damit der zusammengesetzte Wert aussagekräftig ist, sollten sich die drei Gewichtsprozentsätze auf 100 summieren, und jedes zugrunde liegende Maß sollte vor der Gewichtung auf eine gemeinsame Skala normiert werden.

Welche Supplier-Felder sind obligatorisch?

Nur zwei Felder sind obligatorisch: id (ein GUID-Primärschlüssel) und activeFromDate (das Datum, an dem die Lieferantenbeziehung aktiv wurde). Alles andere, einschließlich activeToDate, supplierType und alle Scorecard-Attribute, ist optional, was das inkrementelle Laden von Teildatensätzen ermöglicht.

Was bedeutet das isCarrier-Flag?

isCarrier ist ein boolescher Wert, der wahr ist, wenn der Lieferant ein Transportunternehmen ist, wie zum Beispiel FedEx oder UPS. Dies bietet der Logistik- und Versandlogik eine einfache Möglichkeit, Frachtführer zu identifizieren, ohne dass eine separate Entität oder ein Untertyp erforderlich ist, wodurch das Modell kompakt bleibt.

Warum sind die meisten Scorecard-Felder Ganzzahlen?

Die Rate- und Rank-Felder sind als Ganzzahlen (Integers) typisiert und stellen normalerweise Prozentsätze oder Zählungen dar. Dies hält das Modell einfach und systemübergreifend portierbar, bedeutet jedoch, dass Implementierer selbst über Rundungs-, Skalierungs- und Normalisierungskonventionen entscheiden müssen, anstatt sich darauf zu verlassen, dass das Schema diese erzwingt.

Kann ich die Supplier-Entität erweitern?

Ja. CIM ist ein Open-Source-Modell, das für die Anpassung vorgesehen ist. Sie können also Attribute hinzufügen – zum Beispiel einen Währungscode für supplierSpend oder eine kontrollierte Aufzählung für supplierType – oder neue Entitäten hinzufügen. Erweiterungen sollten die Kernstruktur von Party/Party Role beibehalten, damit die Interoperabilität mit anderen CIM-basierten Systemen gewahrt bleibt.