Lieferantenstammdaten-Plattform: Funktionsweise und tägliche Nutzung

Eine Lieferantenstammdaten-Plattform führt für jeden Lieferanten einen einzigen vertrauenswürdigen Datensatz und verteilt ihn an alle Systeme, die von diesem Lieferanten kaufen oder diesen bezahlen. Dieser Artikel erklärt, wie die Plattform funktioniert, warum Hersteller und Distributoren eine brauchen – auch wenn sie selbst Lieferanten sind –, wie die tägliche Arbeit aussieht und welcher Aufwand für die Implementierung anfällt. Vorausgesetzt wird, dass Sie bereits mit einem ERP-Lieferantenstamm vertraut sind.

Zentrale Erkenntnisse

• Die meisten Lieferantendatenprobleme entstehen bei der Erfassung. Eine Duplikatsprüfung vor der Anlage eines Lieferanten dauert Sekunden, während das Zusammenführen zweier Datensätze mit offenen Bestellungen und Zahlungshistorie Tage dauert.
• Bankdatenänderungen sind dort, wo schlechte Lieferantendaten zu Geldverlust führen. Ein gesteuerter Änderungsworkflow mit Rückruf unter einer bekannten Nummer ist die kostengünstigste Betrugskontrolle, die ein Finanzteam hat.
• Lieferanten brauchen selbst auch Lieferanten-MDM. Die Compliance-Fragebögen ihrer Kunden fragen nach Unter-Lieferanten, und nur strukturierte Lieferantendaten beantworten diese schnell.
• KI hilft beim Matching und beim Lesen von Dokumenten – solange eine Person das Ergebnis genehmigt.
• Der Implementierungsaufwand wächst mit der Anzahl der Quellsysteme und mit dem Anteil der Datensätze ohne Umsatzsteuer-ID oder Registrierungsnummer, da diese in manuelle Überprüfung gehen.
• Der Implementierungsstil bestimmt mehr als die Funktionsliste. Lieferanten zuerst in der Plattform zu erstellen, bringt Kontrolle. Das ERP weiterhin erstellen zu lassen, bringt Geschwindigkeit.

Was eine Lieferantenstammdaten-Plattform leistet

Stammdaten sind die sich langsam ändernden Referenzdaten, auf die Transaktionen verweisen: Lieferanten, Kunden, Produkte, Materialien. Stammdatenverwaltung (MDM) ist die Menge an Regeln und Software, die eine autorisierte Version jedes Datensatzes vorhält und steuert, wie dieser sich ändert.

Ein Lieferantendatensatz ist selten eine einzelne Zeile. Gute Modelle trennen die juristische Person von ihren Standorten, Bankkonten, Ansprechpartnern und Zertifikaten, weil jedes davon nach eigenem Zeitplan ändert und einen anderen Besitzer hat. Unser Artikel zum Lieferantenstammdatenmodell behandelt diese Struktur. Hier liegt der Fokus auf dem, was die Plattform damit tut.

Die Plattform zieht Lieferantendatensätze aus jeder Quelle: ein oder mehrere ERP-Lieferantenstämme, die Beschaffungssuite, das AP-Tool und die Tabellen, die die Beschaffung zur Seite hält. Sie standardisiert Formate, sodass „GmbH" und „Gesellschaft mit beschränkter Haftung" nicht mehr zwei Unternehmen sind. Sie gleicht Datensätze ab, die denselben Lieferanten beschreiben, und führt sie in einen Golddatensatz zusammen – die einzige Version, die jedes System verwenden sollte. Überlebensregeln entscheiden, welcher Wert für jedes Feld gewinnt. Dann publiziert die Plattform den Golddatensatz an die verbrauchenden Systeme zurück, mit einer globalen Lieferanten-ID als gemeinsamer Schlüssel.

Governance sitzt oben drauf. Wer einen Lieferanten anlegen darf und wer eine Bankänderung genehmigt, werden zu Regeln, die die Software durchsetzt. Eine Wiki-Seite mit denselben Regeln ist leichter zu schreiben und leichter zu ignorieren.

Die Plattform überlappt mit Tools, die die meisten Unternehmen bereits bezahlen, was Budgetdiskussionen verwirrt. Ein ERP-Lieferantenstamm hält das, was dieses eine ERP braucht, um Rechnungen zu buchen. Er hat keinen Blick auf das zweite ERP in der Anlage, die vor drei Jahren akquiriert wurde. Ein Lieferantenportal sammelt Daten von Lieferanten und endet dort. Eine Source-to-Pay-Suite führt Beschaffungsprozesse durch und enthält häufig ein Lieferantenmodul, das gut funktioniert, wenn die Suite das einzige System ist, das Lieferanten berührt. In den meisten Herstellern ist es eines von mehreren.

Zwei Implementierungsstile decken die meisten Lieferantenprojekte ab. In einer zentralisierten Einrichtung wird jeder neue Lieferant zuerst in der Plattform angelegt und dann ans ERP gepusht. Die Kontrolle beim Onboarding ist stark, und jeder neue Lieferant wartet jetzt auf den Workflow der Plattform. In einer Koexistenz-Einrichtung erstellt das ERP Lieferanten immer noch, und die Plattform gleicht ab, bereinigt und synchronisiert das Ergebnis zurück. Der Rollout ist schneller, und Duplikate werden nach der Erstellung statt davor gefangen. Viele Unternehmen starten mit Koexistenz, dann verschieben sie neue Lieferantenerstellung und Bankdaten zum zentralisierten Modell, sobald die Workflows stabil sind.

Warum Lieferantendaten ohne Plattform zusammenbrechen

Suchen Sie den Lieferantenstamm eines Unternehmens, das mehr als ein ERP betreibt, nach seinem größten Stahllieferanten. Sie finden oft mehr als einen Datensatz. Jedes Werk erstellte die Version, die es brauchte. Eine Akquisition brachte ihre eigene Lieferantenliste. Jemand nutzte den Handelsnamen, jemand anders den Firmennamen.

Duplikate haben direkte Kosten. Ausgaben teilen sich auf IDs auf, daher arbeitet der Einkäufer, der Mengenrabatte aushandelt, mit der Hälfte der tatsächlichen Summe. Viele AP-Duplikatsprüfungen vergleichen Rechnungen innerhalb einer Lieferanten-ID, daher kann dieselbe Rechnung unter zwei IDs eingegeben zweimal bezahlt werden.

Dann driften die Kopien auseinander. Lieferantendaten ändern sich ständig, und jede Änderung landet zuerst in einem System. Ein Lieferant verlegt sein Lager, Logistik aktualisiert sein Tabellenblatt, und Bestellungen aus dem ERP gehen weiter an die alte Adresse. Ein Lieferant vereinbart neue Zahlungsbedingungen, Finanz aktualisiert ein ERP, und das andere bezahlt weiter nach dem alten Schema. Niemand hat etwas falsch gemacht. Die anderen Systeme haben einfach nicht davon erfahren.

Compliance-Daten altern genauso. Zertifikate verfallen, ohne dass es jemand bemerkt, weil das Verfallsdatum in einem PDF in einem gemeinsamen Ordner sitzt. Elektronische Rechnungen enthalten die Umsatzsteuer-ID des Lieferanten, und ein Mismatch mit dem Lieferantenstamm stoppt automatische Rechnungsabstimmung für einen Lieferanten, der nichts falsch gemacht hat.

Jedes dieser Probleme führt auf eine Lücke zurück: kein System ist Eigentümer des Lieferanten. Eine Lieferantenstammdaten-Plattform führt einen Datensatz pro Lieferant und jedes verbundene System liest von ihm.

Warum Lieferanten selbst Lieferanten-MDM brauchen

Die meisten Hersteller und Distributoren kaufen und verkaufen in der gleichen Lieferkette. Ein Hersteller von Hydraulikventilen kauft Gussteile und Dichtungen und verkauft an Maschinenbauer, deren Beschaffungsteams ihre eigenes Lieferanten-MDM betreiben.

Diese Mittlerposition bedeutet, dass Kunden Fragen stellen, die nur die eigenen Lieferantendaten des Lieferanten beantworten können. Sorgfaltspflicht-Gesetze wie Deutschlands LkSG verlangen, dass große Unternehmen Menschen- und Umweltrechtsrisiken bei ihren Lieferanten beurteilen, und diese Unternehmen geben die Fragen die Kette hinunter. Der Ventilhersteller wird gefragt, welche Gießereien seine Gussteile gießen und ob diese Gießereien die Zertifikate halten, die der Kunde verlangt.

Eine flache Lieferantenliste kann das nicht beantworten. Die Fragen kommen pro Produkt, daher braucht jeder Lieferantendatensatz Links zu seinen Standorten und zu den Materialien, die jeder Standort liefert, mit Zertifikat- und Screening-Status auf dem richtigen Datensatz. Sie kommen auch im Format jedes Kunden-Fragebogens, denselben Fakten in einem anderen Layout. Ein Lieferant, der diese Fakten einmal hält, als strukturierte Felder auf gesteuerten Datensätzen, füllt jeden Fragebogen aus einer Quelle. Einer, der jede Antwort aus E-Mail-Threads zusammenstellt, antwortet spät oder falsch, und der nächste Kunde fragt nochmal.

Stromaufwärts hat der Lieferant die Probleme jedes Käufers: doppelte Lieferanten und veraltete Bankdaten. Im Vertrieb, wo Margen dünn sind, erreichen diese Fehler schnell die Gewinn- und Verlustrechnung.

Wie Teams eine Lieferanten-MDM-Plattform täglich nutzen

Datensätze aus mehreren Quellen konsolidieren

Konsolidierung ist das erste Projekt und ein wiederkehrendes. Jede Akquisition oder ERP-Migration bringt eine andere Lieferantenliste.

Die Reihenfolge der Arbeiten ist wichtig. Importieren Sie zuerst alles in einen Staging-Bereich, unberührt. Normalisieren Sie Namen, Rechtsformen, Adressen und Ländercodes. Gleichen Sie auf harten Identifiern ab, bevor alles andere: Umsatzsteuer-ID, Registrierungsnummer, DUNS-Nummer oder LEI. Führen Sie dann Fuzzy-Matching auf Name und Adresse für Datensätze ohne Identifiern aus. Senden Sie unsichere Übereinstimmungen in eine Überprüfungswarteschlange statt sie automatisch zusammenzuführen. Entscheiden Sie Überlebensregeln pro Attributgruppe vor der ersten Zusammenführung, zum Beispiel Bankdaten aus dem finanzverantwortlichen System und Kontakte aus Beschaffung. Eine falsche Zusammenführung rückgängig zu machen, nachdem Zahlungen gegen den Golddatensatz gebucht wurden, ist langsame Arbeit.

In AtroCore läuft dieser Fluss auf drei Schichten. Source-Entitäten halten die importierten Datensätze, wie sie ankamen oder nah dran. Datenpipelines mappen sie in eine Contributor-Entität, die die Datenmodell der Master-Entität spiegelt ohne obligatorische oder eindeutige Felder und dient als Staging-Schicht für Vereinigung und Duplikaterkennung. Die Master-Entität hält die Golddatensätze. Ein geplanter Job gruppiert wahrscheinliche Duplikate in Cluster basierend auf den Matching-Regeln. Ein Steward bestätigt oder lehnt jedes Cluster-Element ab, oder der Job bestätigt Elemente automatisch, wenn ihr Matched-Score einen konfigurierten Mindestwert erreicht. Während der Bestätigung entscheidet ein Konsolidierungsskript, welche Werte in den Master-Datensatz gelangen. Mit automatischen Master-Updates eingeschaltet, fließen später Änderungen an einem Contributor-Datensatz ohne weitere Bestätigung in den Master-Datensatz (Details im AtroCore-Hilfecenter).

Onboarding eines neuen Lieferanten

Ein Einkäufer fordert einen neuen Lieferanten mit einem Mindestdatensatz an. Bevor irgendetwas erstellt wird, durchsucht die Plattform existierende Golddatensätze nach Umsatzsteuer-ID, Registrierungsnummer und normalisiertem Namen. Dies fängt Anfragen für Lieferanten, die ein anderes Werk bereits nutzt.

Validierung läuft bei der Eingabe. Die Umsatzsteuer-ID passt zu dem Formatierungsmuster ihres Landes und wird für EU-Nummern gegen den VIES-Dienst abgerufen. Die IBAN besteht ihre Checksumme. Obligatorische Felder hängen vom Lieferantentyp ab. Der Lieferant vervollständigt dann den Rest über ein Self-Service-Formular und lädt Dokumente hoch. Beschaffung und Finanz genehmigen hintereinander, und nur dann wird der Datensatz aktiv und erhält seine ERP-Lieferantennummer.

Das ERP wird einen dritten Datensatz für denselben Lieferanten ohne Einwand erstellen. Es hat keine Meinung dazu. Die Plattform schon.

Passen Sie den Aufwand ans Risiko an. Ein einmaliger Kauf für Konferenzcatering sollte nicht den gleichen 40-Feld-Prozess durchlaufen wie ein alleiniger Lieferant von sicherheitskritischen Teilen. Wenn Onboarding für alle schwer ist, leiten Einkäufer es mit Einmal-Lieferantenkonten um, und da kommen Duplikate und Betrug zurück.

Zertifikate und Compliance-Daten aktuell halten

Jedes Zertifikat ist sein eigener Datensatz mit Typ, Umfang, Ausstellungsdatum, Verfallsdatum und Besitzer. Die Plattform sendet Erinnerungen lange vor Ablauf und verschiebt den Lieferanten auf einen eingeschränkten Status, wenn ein obligatorisches Zertifikat verfällt. Ein Automobilzulieferer ohne gültiges IATF-16949-Zertifikat sollte keine neuen Bestellungen erhalten, und das System sollte das durchsetzen, ohne dass jemand sich erinnern muss.

Sanctions-Screening läuft nach Plan und nochmal, wann immer der Firmenname oder Besitz sich ändert. Due-Diligence-Antworten funktionieren besser als strukturierte Felder statt PDF-Anhänge. Dann wird eine Anfrage wie „zeige alle Lieferanten, die Kobalt aus einem bestimmten Land beziehen" zu einem Filter statt einer E-Mail-Kampagne.

Ausgabenanalyse und Sourcing-Entscheidungen

Über-unter-Hierarchien rollen Ausgaben auf Gruppenniveau auf. Klassifizierungscodes wie UNSPSC oder ECLASS gruppieren sie nach Kategorie. Zusammen zeigen sie, wenn vier „verschiedene" Lieferanten zu einer Gruppe gehören, was die Verhandlung ändert.

Auf Produktebene treffen sich Lieferantendaten mit Produktdaten, und Sourcing-Entscheidungen hängen von beiden ab. In Projekten, die wir umsetzten, verwaltete Activate Scientific, ein europäischer Lieferant chemischer Bausteine für Arzneimittelforschung, mehr als 150.000 SKUs, die von vielen Lieferanten gekauft wurden, deren Preise sich oft änderten. Einkäufer verglichen Quellen per Hand und Verkaufspreise wurden manuell neu berechnet. Die Grundlage der Lösung ist ein Datenmodell, das jedes Produkt mit seinen Lieferanten verknüpft – Kaufpreis, Bestand und Lieferantenbewertung, täglich aus dem ERP aktualisiert. Ein Auswahlalgorithmus läuft oben drauf. Er kennzeichnet nicht-optimale Lieferanten und schlägt einen Ersatz mit neu berechneten Verkaufspreisen vor, automatisch angewendet oder nach einer manuellen Überprüfung in Excel.

Das ERP und andere Systeme füttern

Distribution entscheidet, ob der Golddatensatz wichtig ist. Jedes Attribut hat ein besitzendes System, und die anderen nur Lesezugriff. Kritische Änderungen wie ein Zahlungsblock oder neue Bankdaten gehen als Events innerhalb von Minuten. Low-Risk-Felder wie Job-Titel eines Ansprechpartners können in einem nächtlichen Batch fahren. Eine Kreuztabelle verknüpft jede ERP-Lieferantennummer mit der globalen Lieferanten-ID. Wenn ein ERP eingestellt wird, sagt diese Tabelle, welche Datensätze zu migrieren sind und welche totes Gewicht.

Wo KI in Lieferanten-MDM hilft

Matching ist die reifste Anwendung, weil Regeln bei Abkürzungen und transliterierten Namen kämpfen. Forscher der Universität Mannheim fanden, dass die besten großen Sprachmodelle keine oder nur wenige Trainingsbeispiele brauchen, um Entitätsdatensätze genauso gut zu matching wie Sprachmodelle, die auf Tausenden beschrifteten Paaren feinabgestimmt wurden, und sie handhaben unfamiliar records besser (Quelle: Peeters, Steiner and Bizer, Entity Matching using Large Language Models). Dieselbe Studie fand, dass Prompts für jedes Modell und Datensatz abgestimmt werden müssen, und sie testete auf öffentliche Benchmark-Daten. Führen Sie einen Test auf Ihren eigenen Lieferantendatensätzen durch, bevor Sie einer Accuracy-Zahl trauen.

Dokumentenarbeit ist die andere praktische Verwendung. Ein Modell kann ein PDF-Zertifikat lesen und sein Verfallsdatum und Umfang ausfüllen, oder einen Kategoriencode aus Bestellungstext vorschlagen. In beiden Fällen schlägt das Modell vor, und ein Steward entscheidet. Die Plattform protokolliert, wer jeden Wert genehmigt hat, daher sieht der Audit Trail gleich aus, ob eine Person oder ein Modell den ersten Entwurf schrieb.

Was Implementierung kostet

Der Aufwand hängt mehr von den Daten und Systemen um die Plattform als von der Plattform selbst ab, daher ist es leichter, vom Treiber abzuschätzen als von einer generischen Vendor-Timeline. Die Haupt-Treiber sind die Anzahl der Quellsysteme, die Anzahl der Systeme, die Lieferantendaten verbrauchen, die Länder im Scope mit ihren Umsatzsteuer- und Adressformaten und der Anteil der Datensätze ohne harten Identifizierer.

Dieser letzte Treiber setzt die Größe der Überprüfungswarteschlange, daher rechnen Sie die Zahlen vor der Zusage eines Termins. Angenommen, Profiling findet 20.000 Lieferantendatensätze über drei ERPs, und Fuzzy-Matching sendet 3.000 Kandidatenpaare zur Überprüfung. Angenommen, etwa eine Minute pro Paar, das sind 50 Stunden fokussierter Steward-Arbeit. Stewards haben auch Tagesaufgaben, daher die Stunden über Wochen.

Die Arbeit läuft normalerweise in dieser Reihenfolge:

• Profiling und Entscheidungen: zähle Datensätze pro Quelle, messe, wie oft Umsatzsteuer-ID und Registrierungsnummer gefüllt sind, und vereinbare Attributbesitz und Überlebensregeln mit Finanzen und Beschaffung. Diese Phase bewegt sich schnell, wenn Entscheidungsträger verfügbar sind, und staut, wenn sie nicht sind.
• Modell und Regeln: konfiguriere Entitäten, Validierungen und Matching-Regeln, dann stimme Matching auf einem Sample ab, bis Finanz die False-Match-Rate akzeptiert.
• Erste Konsolidierung: importiere in Staging, gleiche ab, räume die Überprüfungswarteschlange, und führe zusammen. Die Überprüfungswarteschlange setzt das Tempo.
• Integration: verbinde jedes ERP und das AP-Tool, lade die Kreuztabelle alter Lieferantennummern, und teste gegen einen vollen Zahlungslauf in einem Testsystem vor Go-Live.
• Workflows: schalte zuerst Bankänderungen und neue Lieferantenerstellung an, weil sie das meiste Risiko tragen. Zertifikat-Tracking und Due-Diligence-Felder können in einem zweiten Release folgen.
• Steady State: budgetiere Steward-Zeit für die täglichen Warteschlangen. Matching, das niemand überprüft, staut schnell auf.

Zwei Entscheidungen kürzen jede Phase. Nennen Sie die Stewards, bevor das Projekt startet. Und begrenzen Sie das erste Release auf die Felder, von denen Payment- und Purchasing-Entscheidungen heute abhängen. Ein 200-Feld-Lieferantenformular bei Go-Live verlangsamt jede Phase danach.

Was Sie bei der Wahl einer Lieferantenstammdaten-Plattform überprüfen sollten

Die Anforderungen unterscheiden sich je nach Unternehmen, aber diese Überprüfungen trennen Plattformen, die für Lieferantendaten funktionieren, von denen, die nur gut vorführen:

• Datenmodell: juristische Person, Standort, Bankkonto und Zertifikat als separate verknüpfte Entitäten, mit neuen Feldern ohne Warten auf ein Vendor-Release.
• Matching: Regeln auf harten Identifiern plus Fuzzy-Name- und Adressvergleich, eine Staging-Fläche und eine Überprüfungswarteschlange für unsichere Übereinstimmungen.
• Workflow und Berechtigungen: Genehmigungsketten und Feld-Level-Zugriff, daher Bankdaten ihre eigenen Regeln folgen.
• Audit Trail: alter Wert, neuer Wert, Benutzer und Zeitstempel für jedes Feld mit finanziellem oder Compliance-Relevanz.
• Integration: vollständige API-Abdeckung und ereignisgesteuerte Synchronisation mit Ihren tatsächlichen ERP-Versionen, einschließlich des alten, das nur Datei-Imports akzeptiert.
• Deployment und Lizenzierung: Cloud oder vor Ort, Open Source oder proprietär, und wer ist Besitzer der Konfiguration, wenn die Vendor-Beziehung endet.

Die Trade-offs sind echt. Ein MDM-Modul von Ihrem ERP-Vendor passt zu diesem ERP nah, und die Passform neigt zu schwächer werdend, sobald Systeme von anderen Vendors beitreten. Eine Standalone-Plattform verbindet sich mit Alles mit einer API, und diese Flexibilität bedeutet mehr Integrations-Design vorher. Keine Wahl weist Besitz zu. Eine Plattform ohne benannte Datenstew arts wird eine gut indexierte Kopie des alten Durcheinanders.