Amazon und Alphabet: negativer Cashflow, lange Bindung
Eva Mickler
6 Min. Lesezeit Zwei der drei großen Cloud-Anbieter wiesen zuletzt negativen freien Cashflow aus. Amazon ...
Zum Beitrag
6 Min. Lesezeit
Lieferketten-Compliance scheitert selten an fehlendem Willen. Sie scheitert daran, dass Unternehmen ihre Lieferanten, Standorte und Nachweise nicht als zusammenhängende Datenbasis führen.
Das Wichtigste in Kürze
- Compliance scheitert an der Datenbasis, nicht am Willen. Lieferanten, Standorte und Nachweise liegen verstreut in Einkauf, Qualität und externen Portalen, mit eigenen Identifikatoren und Zyklen.
- Der Kreditorenstamm im ERP reicht nicht. Für Sorgfaltspflichten zählen Produktionsstandorte, Konzernstrukturen, Materialien und die Gültigkeit von Nachweisen, nicht nur die rechtliche Einheit.
- Traceability ist ein Beziehungsmodell, keine Liste. Bauteil verweist auf Material, Material auf Herkunft, Herkunft auf Lieferant und Risiko, jeweils mit Wirksamkeitsdatum und Versionierung.
- Die Vereinfachung 2026 schafft Zeit, keine Entlastung. Die materiellen Pflichten greifen erst 2029, doch große Kunden verlangen belastbare Nachweise schon heute entlang ihrer eigenen Kette.
Der Rechtsrahmen verschiebt die Priorität, nicht die Datenaufgabe
Die europäische Lieferkettenrichtlinie CSDDD wurde 2026 deutlich vereinfacht. Nach der aktuellen Fassung erfasst sie zunächst Unternehmen mit mehr als 5.000 Beschäftigten und mehr als 1,5 Milliarden Euro Nettoumsatz. Die Anwendung beginnt am 26. Juli 2029, die Mitgliedstaaten müssen die Vorgaben bis Juli 2028 umsetzen. Das nimmt kurzfristig Druck aus vielen Programmen. Es löst jedoch kein einziges Datenproblem.
In Deutschland gilt das Lieferkettensorgfaltspflichtengesetz weiter, bis die europäische Regelung in nationales Recht überführt ist. Die Berichtspflicht wurde politisch zurückgefahren und das BAFA nimmt gegenwärtig keine Berichte über sein Portal entgegen. Risikoanalysen, Prävention, Abhilfe, Beschwerdemechanismen und Dokumentation bleiben dennoch der Kern der Sorgfaltspflichten. Wer daraus nur ein Reporting-Projekt macht, baut eine kurzfristige Antwort auf ein dauerhaftes Steuerungsproblem.
Für viele mittelständische Zulieferer entsteht der Druck zudem nicht aus dem unmittelbaren gesetzlichen Anwendungsbereich. Große Kunden verlangen Herkunftsangaben, Risikoauskünfte, Zertifikate und belastbare Nachweise entlang ihrer eigenen Lieferkette. Damit wird die Fähigkeit, Daten schnell und konsistent bereitzustellen, zur Geschäftsbedingung.
Wer daraus nur ein Reporting-Projekt macht, baut eine kurzfristige Antwort auf ein dauerhaftes Steuerungsproblem.
Die Lücke liegt zwischen Kreditorenstamm und Lieferkette
Ein ERP-System kennt den Kreditor. Es kennt Rechnungen, Zahlungsbedingungen und häufig die rechtliche Einheit. Für Sorgfaltspflichten reicht das nicht. Relevant sind auch Produktionsstandorte, Konzernstrukturen, Warenströme, eingesetzte Materialien, Subunternehmer, Risikogebiete und die Gültigkeit von Nachweisen. Diese Informationen liegen oft in Einkauf, Qualitätsmanagement, Compliance, Nachhaltigkeit und externen Portalen. Sie folgen unterschiedlichen Identifikatoren und Aktualisierungszyklen.
Die erste Architekturentscheidung lautet deshalb: Was ist die kanonische Identität eines Lieferanten? Eine Lieferantennummer allein trägt diese Rolle selten. Ein Datenmodell muss juristische Einheit, wirtschaftliche Gruppe, Standort und Lieferbeziehung getrennt abbilden. Ein Konzern kann in mehreren Ländern produzieren. Ein Standort kann für verschiedene Kundengesellschaften liefern. Werden diese Ebenen vermischt, lassen sich Risiken weder präzise zuordnen noch nachvollziehbar bewerten.
CIOs sollten hierfür keinen weiteren Schattenstamm neben dem ERP schaffen. Sinnvoll ist ein führendes Lieferantenobjekt mit stabiler Kennung und klaren Beziehungen zu ERP, Beschaffung, Produktdaten und Risikoquellen. Die Daten müssen nicht physisch in einem System liegen. Entscheidend ist, dass jede Anwendung dieselbe Entität referenziert und Änderungen nachvollziehbar übernimmt.
Die Zahl hinter dem Aufschub
5.000 Beschäftigte und 1,5 Milliarden Euro Umsatz. Erst ab dieser Schwelle greift die CSDDD direkt, mit einheitlichem Start am 26. Juli 2029. Über die Verträge großer Kunden entsteht der Nachweisdruck schon deutlich früher.
Traceability beginnt bei den Beziehungen zwischen Daten
Die Forderung nach Transparenz bis in tiefere Lieferstufen verführt zu einem unrealistischen Zielbild: jede einzelne Vorlieferstufe vollständig abzubilden. Weder CSDDD noch LkSG verlangen eine lückenlose Weltkarte aller Geschäftsbeziehungen. Der Maßstab ist risikobasierte Sorgfalt. Die Architektur muss daher zeigen können, welche Daten vorliegen, welche Annahmen gelten und warum ein Unternehmen an einer Stelle vertieft prüft.
Dafür braucht es ein Beziehungsmodell statt einer Lieferantenliste. Ein Bauteil verweist auf Materialgruppen. Materialgruppen verweisen auf Herkunftsregionen oder Produktionsstandorte. Standorte stehen in Beziehung zu Lieferanten und Risikobewertungen. Hinzu kommen Zeitbezüge: Ein Zertifikat war zum Zeitpunkt der Freigabe gültig, kann heute aber abgelaufen sein. Ohne Wirksamkeitsdatum und Versionierung entsteht im Audit eine Sammlung plausibler Dateien, jedoch keine beweisbare Entscheidungskette.
Gerade bei indirekten Zulieferern sollte die IT zwischen bestätigten Fakten, Lieferantenselbstauskünften, externen Hinweisen und abgeleiteten Risikoeinschätzungen unterscheiden. Diese Herkunft der Information gehört ins Datenmodell. Sie entscheidet darüber, ob eine Ampel als belastbarer Hinweis oder als bloße Behauptung behandelt werden kann.
Der Nachweis braucht einen unveränderbaren Entscheidungsfaden
Compliance-Teams fragen nicht nur, welches Risiko bekannt war. Sie müssen zeigen, wer es wann bewertet hat, welche Maßnahme beschlossen wurde und ob deren Wirkung geprüft wurde. Diese Kette lässt sich nicht zuverlässig aus E-Mails, Präsentationen und Dateien in Team-Laufwerken rekonstruieren. Sie benötigt einen digitalen Vorgang mit eindeutiger Referenz auf Lieferant, Risiko, Entscheidung, Verantwortliche und Beleg.
Ein guter Entwurf trennt dabei operative Systeme von der Nachweislogik. Das ERP bleibt für Bestellungen und Lieferfreigaben zuständig. Das Beschaffungssystem steuert Ausschreibungen und Verträge. Eine Compliance- oder Datenplattform führt Risikoereignisse, Prüfungen, Maßnahmen und Evidenzen zusammen. Schnittstellen übertragen nur die Attribute, die jeweils benötigt werden. Das senkt Kopierfehler und verhindert, dass sensible Informationen unkontrolliert in Einkaufslisten oder Analysewerkzeugen landen.
Automatisierung lohnt sich vor allem bei wiederkehrenden Kontrollen: ablaufende Nachweise, fehlende Pflichtfelder, Änderungen an Unternehmensdaten, neue Länder- oder Warengruppenrisiken und überfällige Maßnahmen. Sie ersetzt keine Bewertung. Sie sorgt dafür, dass Fachbereiche ihre Zeit auf Fälle mit echter Relevanz verwenden. Jede automatische Regel braucht einen Eigentümer, eine Datenquelle und ein dokumentiertes Verfahren für Fehlalarme.
Viele Projekte scheitern an falscher Ownership
Die verbreitete Fehlannahme lautet, Compliance definiere die Anforderungen und die IT liefere ein Tool. In Wahrheit entscheidet das Betriebsmodell über die Datenqualität. Einkauf verantwortet viele Ausgangsdaten, Fachbereiche kennen Produkte und Lieferbeziehungen, Nachhaltigkeit bewertet Inhalte, Legal definiert den Rahmen und IT verantwortet Integration, Zugriff und Nachvollziehbarkeit. Fehlt diese Aufteilung, werden Pflichtfelder eingeführt, aber nicht gepflegt.
Ein zweiter Fehler ist der Versuch, alle Daten vor dem Start zu bereinigen. Stammdatenqualität verbessert sich selten durch ein einmaliges Großprojekt. Besser ist eine Priorisierung nach Risiko und Beschaffungsvolumen. Für die kritischsten Lieferbeziehungen gelten zuerst verbindliche Identitäten, Datenverantwortliche und Qualitätsregeln. Die gewonnenen Muster lassen sich danach auf weitere Gruppen übertragen.
Die nächsten 90 Tage sollten daher drei Ergebnisse liefern: ein verbindliches Datenmodell für Lieferant, Standort, Beziehung und Nachweis, eine Landkarte der führenden Systeme sowie einen Pilot für eine risikorelevante Warengruppe. Der Pilot zeigt früh, welche Informationen bei Lieferanten realistisch verfügbar sind und wo Vertragsklauseln oder Prozesse angepasst werden müssen.
Aus Compliance-Daten wird ein operatives Frühwarnsystem
Die Datenbasis kann mehr als regulatorische Pflichten erfüllen. Wer Lieferantenbeziehungen, Standorte, Materialgruppen und Nachweise konsistent verbindet, erkennt Abhängigkeiten früher. Ein Produktionsausfall, ein regionales Risiko oder ein auslaufendes Zertifikat wird dann einer konkreten Beschaffung, Produktlinie und Verantwortlichkeit zugeordnet. Das verbessert Gespräche zwischen Einkauf, Produktion und Risikomanagement.
Der operative Nutzen entsteht allerdings nur, wenn die Architektur in Entscheidungsprozesse eingebunden wird. Eine Risikobewertung, die nach Vertragsabschluss in einem separaten Portal verschwindet, schützt weder Lieferfähigkeit noch Reputation. Ein Risikosignal muss Beschaffungsfreigaben, Lieferantenentwicklung und Eskalationen erreichen. Datenarchitektur wird damit zum verbindenden Element zwischen Compliance und Steuerung.
Die regulatorische Vereinfachung 2026 ist deshalb kein Anlass, die Aufgabe zu vertagen. Sie schafft Zeit für eine bessere Umsetzung. CIOs sollten sie nutzen, um aus verstreuten Dokumenten eine prüfbare Datenkette zu machen. Wer erst bei einer Kundenanfrage oder einer Prüfung damit beginnt, bezahlt die fehlende Architektur unter Zeitdruck.
Häufig gestellte Fragen
Müssen wir Tier-2- und Tier-3-Lieferanten vollständig kennen?
Nein. Der maßgebliche Ansatz ist risikobasiert. Unternehmen brauchen belastbare Verfahren, um bei relevanten Risiken tiefer in die Lieferkette zu schauen. Das Datenmodell sollte indirekte Beziehungen deshalb abbilden können, aber klar kennzeichnen, ob Informationen bestätigt, vom Lieferanten angegeben oder aus einer Risikobewertung abgeleitet wurden.
Kann das ERP die Lieferketten-Compliance allein abdecken?
Meist nicht. ERP-Systeme sind führend für Kreditoren, Bestellungen und Warenbewegungen. Risikobewertungen, Nachweise, Maßnahmen und ihre Versionierung benötigen zusätzliche Objekte und Prozesse. Entscheidend ist keine neue Monolith-Plattform, sondern eine eindeutige Lieferantenidentität und belastbare Schnittstellen zwischen den beteiligten Systemen.
Welcher erste Schritt bringt für CIOs den größten Erkenntnisgewinn?
Ein Pilot mit einer risikorelevanten Warengruppe liefert mehr als ein unternehmensweites Zielbild. Er macht Datenlücken, unklare Verantwortlichkeiten und Integrationsprobleme sichtbar. Auf dieser Grundlage lassen sich Architekturprinzipien, Datenqualitätsregeln und ein realistischer Ausbauplan festlegen.
Bildquelle: KI-generiert (Juli 2026)
Weiterlesen auf Digital Chiefs
Digital ChiefsWas Beratungen über Transformation verschweigenDigital ChiefsNiemand braucht noch ein achtwöchiges KI-GutachtenDigital ChiefsDrei KI-Budgets, keine gemeinsame RechnungMehr aus dem MBF Media Netzwerk
cloudmagazinDer Stichtag, den viele Navision-Anwender verschlafen MyBusinessFutureWenn jede Bestellmail von Hand ins ERP wandert SecurityTodayLieferkettenrisiko ist ein Programm, keine Audit-Liste