Ihre Daten sind besser als Sie denken

00:00:00 Daten besser als Sie denken
00:03:43 Warum „schlechte Daten“ zum Sündenbock werden
00:07:26 Transaktionale Fakten versus Parametermüll
00:11:09 Der Reporting-Layer „Cake“ behindert die Entscheidungsfindung
00:14:52 Entscheidungsorientierte Sicht auf nützliche Informationen
00:18:35 Parameter automatisieren: Durchlaufzeiten, Saisonalität, Neuheit
00:22:18 ERP-Komplexität sind keine schlechten Daten
00:26:01 Datumsfelder verbergen mehrere reale Bedeutungen
00:29:44 Semantik bewiesen durch generierte Entscheidungen
00:33:27 Ausreißer enthüllen schlechte Methoden, nicht schlechte Daten
00:37:10 Data Lakes sollten kopieren, nicht „verbessern“
00:40:53 Datenqualität in Dollar gemessen
00:44:36 KI-Bereitschaft: zuverlässige Transaktionen, Semantik an erster Stelle
00:48:19 Doppeldurchläufe erfordern vollautomatische Ausführung
00:52:02 Hersteller-Schuldzuweisungen: Lidl-SAP Warnstory
00:55:45 Qualität entspricht Eignung für Entscheidungen

Zusammenfassung

“Schlechte Daten” sind oft ein Sündenbock. Die transaktionalen Aufzeichnungen der meisten Unternehmen – was gekauft, verkauft, versandt, zurückgeschickt wurde – sind gut genug, sonst würden sie nicht überleben. Das eigentliche Chaos ist der Berg an manuell gepflegten Parametern und die Verwirrung darüber, was Felder tatsächlich bedeuten (Semantik), besonders in weitläufigen ERPs. Reinige die Realität nicht, um schwache Methoden zu retten: Ausreißer sind oft das Geschäft. Beurteile Daten anhand der Ergebnisse: Wenn Entscheidungen profitabel verbessert werden, waren die Daten ausreichend; wenn die Ergebnisse absurd sind, korrigiere die Interpretation.

Erweiterte Zusammenfassung

Eine bekannte Beschwerde im supply chain ist, dass “schlechte Daten” den Fortschritt blockieren. Doch vieles von dem, was als schlechte Daten bezeichnet wird, ist weder schlecht noch zentral für das Problem. Es ist oft eine praktische Ausrede – manchmal für Anbieter, die jemanden beschuldigen müssen, wenn ihre Software versagt, und manchmal für Analysten, die an ordentliche Klassenzimmer-Datensätze gewöhnt sind und vom schieren Umfang echter Unternehmenssysteme schockiert werden. Ein ERP mit Tausenden von Tabellen ist kein Beweis für schlechte Daten; es ist ein Beweis für Komplexität.

Das Gespräch zieht eine klare Grenze zwischen zwei Arten von “Daten”. Zum einen gibt es die transaktionale Realität: was gekauft, verkauft, versandt, zurückgegeben, verschrottet oder bezahlt wurde – Ereignisse mit finanziellen Konsequenzen. Diese Informationen sind in der Regel verlässlich, aus einem einfachen Grund: Unternehmen, die die grundlegende transaktionale Wahrheit nicht im Griff haben, überleben nicht lange. Märkte bestrafen solch ein Maß an Verwirrung schnell. Fehler gibt es, aber typischerweise in geringem Umfang.

Zum anderen gibt es einen Berg an manuell gepflegten Parametern – Service-Level-Ziele, Sicherheitsbestandskoeffizienten, Saisonalität Flags, Durchlaufzeiten von Sachbearbeitern eingegeben. Diese “numerischen Artefakte” sind routinemäßig veraltet, inkonsistent und teuer im Unterhalt, wenn man sie in großem Maßstab betreibt (Millionen von SKUs mal mehrere Parameter). Aber der wichtige Punkt ist, dass sie oft unnötig sind. Viele dieser Eingaben sollten aus der beobachteten Historie abgeleitet oder durch bessere Methoden automatisiert werden. Wenn man sie als “Kern-Daten” behandelt, schafft das eine selbst zugefügte Last.

Ein großes, verborgenes Problem ist die Semantik: was ein Feld bedeutet. Dieselbe Spalte kann im Laufe der Zeit, über Geschäftsprozesse hinweg oder sogar je nach Vorzeichen (Verkauf vs. Rückgabe) ihre Bedeutung ändern. Die Dokumentation ist anfangs meist dürftig. Der einzige verlässliche Weg, Semantik zu validieren, ist nicht endlose Workshops, sondern das Testen von Interpretationen: Generiere echte Entscheidungen – was zu kaufen, zu produzieren, zu lagern, zu bepreisen ist – und prüfe, ob die Ergebnisse absurd werden. Wenn dies der Fall ist, analysiert man den Ablauf rückwirkend, um die fehlerhafte Annahme zu finden.

Dies führt auch zu einer Neubewertung von “rauschenden Daten”. Wenn Kunden manchmal 1 und manchmal 100 bestellen, sind das keine schlechten Daten – das ist das Geschäft. Methoden, die unter Ausreißern zusammenbrechen, sind fehlerhaft; die Daten sollten nicht verfälscht werden, um schwache mathematische Modelle zu retten.

Schließlich, zur “KI-Bereitschaft”: Die Messlatte ist nicht die moralische Reinheit der Daten. Es geht um Eignung für den Zweck. Wenn Sie wissen, was Sie kaufen, herstellen und verkaufen, können Sie beginnen. Die eigentliche Arbeit besteht darin, systemweise die Semantik abzubilden und dann schnell zu iterieren, bis die Entscheidungen vernünftig sind. Letztlich ist Qualität kein Schlagwort; sie wird durch die wirtschaftliche Leistung der Entscheidungen gemessen.

Volles Transkript

Conor Doherty: Dies ist Supply Chain Breakdown, und heute werden wir aufschlüsseln, warum Ihre Daten tatsächlich besser sind, als Sie denken. Viele Unternehmen sagen uns, dass ihre Daten sie daran hindern, die Projekte zu starten, die sie sich wünschen. Nun, heute sind wir hier, um diese Idee in Frage zu stellen. Wir sind konstruktiv.

Conor Doherty: Wer sind wir? Nun, ich bin Conor, Marketing Director hier bei Lokad. Zu meiner Linken, wie immer, befindet sich Lokad-Gründer Joannes Vermorel. Bevor wir beginnen, lasst uns unten wissen: Zum einen, aus welchem Teil der Welt schaut ihr uns zu? Wir sind in Paris. Und zum anderen, seid ihr der Meinung – oder denkt ihr gar –, dass Stammdaten in der Tat ein Engpass für digitale Transformationsprojekte sind, in die Unternehmen heutzutage wirklich einsteigen wollen? Hinterlasst eure Kommentare und Fragen unten. Wir werden später darauf eingehen.

Conor Doherty: Und damit, Joannes, an die Diskussion. Bevor wir ins Detail gehen, ein wenig Kontext: Wie diese Diskussion zustande kam. Wie ihr wisst, lüfte den Vorhang: Am Ende jeder einzelnen Episode sage ich: “Hey, wenn ihr das Gespräch fortsetzen wollt, kontaktiert Joannes und mich privat. Wir sprechen gerne.” All das ist wahr. Manche Leute machen das eben. Sie wollen reden.

Conor Doherty: Und kürzlich, sowohl gemeinsam als auch einzeln, hatten wir Diskussionen, und ein wiederkehrendes Thema bei Praktikern ist das Klagen über den Zustand der Daten: so etwas wie, “Meine Stammdaten sind ein Durcheinander”, “Mein ERP ist wie Schweizer Käse”, was auch immer. Aber genau das ist das Problem. Das hindert mich daran, all die tollen Dinge zu tun, die ich tun möchte. Und so kamen wir zum heutigen Thema.

Conor Doherty: Also, Joannes, warum bekommen Daten im supply chain so einen schlechten Ruf?

Joannes Vermorel: Ich kann je nach Publikum an mehrere Gründe denken.

Für Software-Anbieter, sind schlechte Daten der ultimative Sündenbock. Es ist eine Möglichkeit, die Kunden höflich, aber bestimmt für jeden Fehler des Softwareprodukts verantwortlich zu machen. Daher ist es extrem praktisch, und gute Anbieter, talentierte Anbieter, schaffen es, die Kunden davon zu überzeugen, dass alles an ihnen liegt, wenn das Ganze auseinanderfällt, weil sie unzureichende Datenpraktiken, Qualitätskontrolle und dergleichen hatten.

Meine Meinung dazu: Es ist wirklich Schuldzuweisung. Das zweite Publikum sind data scientists, insbesondere data scientists, die – würde ich sagen – an Kaggle-Wettbewerben teilgenommen haben. Sie sind vor allem an der Universität an Datensätze gewöhnt, die super ordentlich und sauber sind, und halten dies für den Standard. Sie denken, dass es normal ist, einen Datensatz zu haben, in dem es fünf Tabellen gibt, jede mit fünf Feldern und umfangreicher Dokumentation zu jedem Feld, und alles ist sehr, sehr klar – für mich ist das ein Problem völlig unrealistischer Erwartungen.

In Unternehmen, wenn wir über mittelgroße ERPs sprechen, reden wir von 10.000 Tabellen. Einige Tabellen haben 50 Felder. Darum geht es. Hier haben data scientists völlig unrealistische Erwartungen daran, was Unternehmensdaten tatsächlich sind.

Und es gibt ein drittes Segment, nämlich die Praktiker. Es geht darum: Was sie betrachten, ist typischerweise die Parametrisierung ihres Geschäftssystems. Sie schauen sich in der Regel nichts Reales an, wie etwa: eine Einheit, die zu diesem Datum zu diesem Preis verkauft wurde. Darum geht es normalerweise nicht. Es betrifft nicht jene wesentlichen transaktionalen Ereignisse der Vergangenheit.

Was sie betrachten, ist: “Oh, aber seht mal, die Saisonalitätseinstellungen, die wir vor zwei Jahren im APS eingegeben haben, stimmen jetzt völlig nicht mehr, wegen diesem, wegen jenem.” “Schaut, wir haben so viele korrigierende Koeffizienten für die Sicherheitsbestand Formel, und auch diese stimmen völlig nicht mehr”, usw. Tatsächlich, wenn diese Praktiker sich über schlechte Daten beschweren, meinen sie sehr spezifisch die numerischen Artefakte – Dinge, die weder die Vergangenheit noch die Zukunft widerspiegeln. Sie stellen eine Art Parametrisierung der Unternehmensrichtlinien dar.

Und meiner Meinung nach: Wenn wir zum ersten Fall zurückkehren, nämlich dem Software-Anbieter, ist das Problem, dass wenn die von Ihnen verwendete Softwarelösung so stark von dieser manuell gepflegten Parametrisierung abhängt, es garantiert problematisch wird. Daher besteht die einzige Lösung darin, diese Dinge nicht als solche zu behandeln. Sie sollten nicht einmal Teil des Gesamtbildes sein, damit Sie nicht mit ihnen umgehen müssen.

Conor Doherty: Korrigiert mich ruhig, wenn ich falsch liege, aber es klingt, als würdest du sagen, dass es grundsätzlich zwei Kategorien von Daten gibt. Wenn Menschen den Begriff “Daten” verwenden, denken sie im Grunde an zwei Kategorien. Die eine ist das, was du als numerische Artefakte bezeichnest – die Dinge, die sie sich selbst gesetzt haben, bestimmte Zielwerte – die andere ist die eigentlichen rohen transaktionalen Daten, die du als viel, viel wichtiger erachtest.

Joannes Vermorel: Ja. Ich meine, die echten Transaktionsdaten sind die Ereignisse, die stattgefunden haben. Wiederum: Man hat verkauft oder nicht. Man hat den Lieferanten bezahlt, einen Auftrag erteilt, eine Einheit aus dem Lager entnommen, eine Einheit, die eigentlich verderblich war, nach Überschreiten ihrer Haltbarkeit zerstört usw. Diese sind transaktional, und das ist üblicherweise hervorragend.

Allerdings hat man in vielen Geschäftslösungen auch einen Berg von Parametern, die von Sachbearbeitern gepflegt werden sollen – Menschen, die das System lediglich bedienen. Und die Frage ist: Warum braucht man überhaupt diese Unmenge an Parametern? Denn sehr häufig sprechen wir von einer riesigen Anzahl an Parametern.

Um ein Gefühl für das Ausmaß zu geben: Ein Unternehmen, das eine Million SKUs hat – was eigentlich gar nicht so riesig ist – wenn man, sagen wir, 10 Parameter pro SKU hat, und ich bin hier konservativ, es kann noch mehr sein – 10 Parameter pro SKU, sprechen wir von 10 Millionen Parametern, die mehr oder weniger manuell gepflegt werden müssen. Und das ist Wahnsinn.

Danach sagen die Leute: “Oh, das ist Müll, weil wir es nicht wirklich pflegen können.” Ich würde sagen: Ja, absolut. Aber die Realität ist, dass man es eigentlich gar nicht braucht. Und all diese Dinge vermitteln keine wirkliche Information, da die Art und Weise, wie diese Parameter gesetzt wurden, ohnehin durch einen Blick auf die restlichen Daten erfolgte.

Wenn Leute zum Beispiel ein Service Level Ziel festlegen, tun sie das, indem sie einen Blick auf die Transaktionshistorie werfen. So sieht man, dass diese Information in der Tat völlig flüchtig ist und nicht als Teil Ihrer Kerndaten betrachtet werden sollte. Deshalb sage ich: Schlechte Daten sind ein Problem, das viel, viel kleiner ist, als die Leute erwarten. Es liegt einfach daran, dass sie einen großen Teil von dem, was sie als Daten behandeln, nicht behandeln sollten.

Es gibt auch einen zweiten Aspekt, aber das ist ein separates Problem. Es tritt auf, wenn Leute weitere Analysen auf Grundlage vorverarbeiteter Daten durchführen wollen, insbesondere derjenigen, die aus der Reporting-Layer gewonnen werden.

Nochmal: Ich unterteile Unternehmenssoftware in drei Klassen: Systeme der Aufzeichnung – das sind die ERPs ohne Planung, da keine Planung involviert ist – Systeme der Berichterstattung, also Business Intelligence und all jene Systeme für Dashboarding und Reporting, und dann Systeme der Intelligenz, die diejenigen, die Entscheidungsfindung ermöglichen.

Die einzige Wahrheit der Daten liegt in den Systemen der Aufzeichnung. Aber sehr häufig wollen die Leute – sei es, weil sie fehlgeleitet, beschäftigt oder aus welchem Grund auch immer – die Daten so nutzen, wie sie aus dem System der Berichterstattung präsentiert werden. Und hier befinden wir uns in einer Situation, die, bildlich gesprochen, der eines Kochs sehr ähnelt.

Man stellt sich eine Küche vor, in der man alle rohen Zutaten hat – Mehl, Zucker, Salz – und das ist ein System der Aufzeichnung, die rohen Zutaten. Und dann kann der Koch über das System der Berichterstattung einen Kuchen backen. Man hat einen Kuchen, er ist schön, man kann ihn verzehren. Er ist für den menschlichen Verzehr bestimmt, also funktioniert es.

Nun fragt man den Koch: “Nimm einfach diesen Kuchen und mach etwas anderes daraus.” Und genau das passiert, wenn man versucht, die Daten zu nutzen, die aus der Reporting-Layer stammen, um beispielsweise Entscheidungsprozesse zu steuern. Das geht sehr, sehr schlecht. Es ist nicht so, dass der Koch ein schlechter Koch wäre; es liegt einfach daran, dass, wenn man vom Kuchen ausgeht, man nichts anderes mehr tun kann. Es ist bereits das fertige Produkt. Den Zucker, das Mehl und dergleichen auseinanderzunehmen – alles geht verloren.

Man muss also zu den rohen Zutaten zurückkehren, wenn man etwas anderes machen möchte. Das ist auch ein typischer Fehler, den ich bei vielen Unternehmen beobachtet habe: Sie schauen sich die Daten in der Reporting-Layer an, die für den menschlichen Verzehr bestimmt sind, und versuchen, diese Daten zu extrahieren und für andere Zwecke neu zu verarbeiten. Das ist ein Fehler. Man muss zu den rohen Zutaten zurückkehren.

Conor Doherty: Nun, noch einmal, zu diesem Punkt – die Idee, zu den rohen Zutaten zurückzukehren, zu den grundlegenden Daten – ich habe tatsächlich einen… was man auch immer über die Quelle denken mag. Ich nutze sie nur als Hintergrund, um zu zeigen, dass wir hier nicht nur spekulieren.

Ich schaue mir gerade einen Gartner-Bericht an, in dem Hunderte sehr großer Unternehmen befragt wurden, und es wurde bestätigt, dass die meisten Unternehmen die Datenqualität nicht einmal konsistent messen. Tatsächlich entsteht einfach das Gefühl, dass unsere Daten schlecht sind, es ist aber nicht zwingend eine messbare Tatsache.

Es gibt also zwei Fragen. Zum einen: Überrasch dich das im Allgemeinen? Und zum anderen: Wie könnten Menschen schnell den Zustand ihrer Daten diagnostizieren?

Joannes Vermorel: Zunächst, wenn wir uns die transaktionalen Daten ansehen, ist die Antwort einfach: Macht Ihr Unternehmen Gewinne? Wenn ja, hat Ihr Unternehmen hochwertige Daten. Warum? Weil ich noch nie ein Unternehmen getroffen habe, das nicht wüsste, was es kauft, verkauft oder produziert, und dennoch überlebt.

Wenn du das nicht einmal weißt, wirst du schneller als das Licht bankrottgehen. Wenn du nicht weißt, was deine Lieferanten dir geschickt haben, dann wirst du mehrfach belastet. Wenn du nicht weißt, was deine Kunden tatsächlich gekauft haben, dann berechnest du ihnen tatsächlich nicht korrekt. Es geht sehr schnell. Es ist Darwinismus im Spiel. Märkte eliminieren diese Unternehmen rücksichtslos; sie sind weg.

Als Faustregel gilt: Wenn du in einem Unternehmen bist, das nicht kurz vor dem Bankrott wegen Missmanagement steht, ist die Transaktionshistorie höchstwahrscheinlich von sehr hoher Qualität. Ja, ein buchhalterischer Fehler kann sich einschleichen, wie jede von tausend Zeilen – typischerweise die Größenordnung, die ich in den meisten Unternehmen sehe. Du wirst, sagen wir mal, zwischen 0,1 % und manchmal bis zu 0,5 % buchhalterische Fehler haben, aber es ist sehr, sehr gering. Viele Unternehmen liegen sogar darunter.

Nun, wenn wir von all den optionalen Daten sprechen – zum Beispiel, du hast in deinem System eine Parametrisierung, die dir erlaubt, das Ziel-Service-Level für eine SKU zu bestimmen – was bedeutet es überhaupt, hier hochwertige Daten zu haben? Das ist Unsinn.

Wenn ich den Advocatus diaboli spielen würde, müsste ich prüfen, wie nah diese Einstellung daran ist, die Kapitalrendite der Lagerinvestition des Unternehmens zu maximieren, wenn dieser Parameter gesetzt ist. Wir werden das niemals tun. Es ist viel zu kompliziert. Wenn du tatsächlich die Idee annimmst, dass deine supply chain die Kapitalrendite maximieren sollte, großartig, aber dann wirst du sehr, sehr schnell all diese nichtökonomischen Ansätze verwerfen.

Fazit: Bei dieser Parametrisierung gibt es ja tendenziell eine Menge Müll. Tatsache ist, dass Unternehmen damit leben können, weil, sagen wir, ein Lagerplaner sich einfach das empfohlene replenishment ansieht, und es mag nicht allzu viel Sinn ergeben, aber derselbe Planer schaut sich die jüngste Historie an, ein paar Dinge, und in einer Minute sagt die Person: „Okay, bestell 50 Einheiten“, und als Nächstes schaue ich mir die nächste SKU an.

Also ja, wenn du auf Basis dieser Parametrisierungsdaten etwas robotisieren oder automatisieren möchtest, ist die Datenqualität sehr, sehr niedrig. Aber die einzige Lösung besteht darin, Softwaresysteme als intelligente Systeme zu betrachten, die nicht auf dieser Parametrisierung beruhen, welche lediglich unterstützende Fähigkeiten für einen workflowzentrierten Prozess darstellt.

Conor Doherty: Nun, ich schreibe nur einen Gedanken auf, um darauf zurückzukommen, denn wie gesagt, wo immer möglich, mag ich es, konstruktive Gedanken zu verstärken.

Unsere Perspektive, wie es jedem, der uns folgt, bekannt ist, lautet: Der Zweck von Daten, der Zweck, überhaupt in einem Unternehmen zu arbeiten, besteht darin, dass man bessere Entscheidungen trifft – bessere Entscheidungen, die tatsächlich mehr Geld einbringen. Nun, du hast da den Punkt gemacht, dass bessere Entscheidungen nicht im Berichtssystem verankert sind; sie liegen bereits in deinen Transaktionsdaten.

Im Wesentlichen, damit Menschen bessere Entscheidungen treffen können – definiert „besser“ wie immer ihr möchtet, so wie wir es als Maximierung der Kapitalrendite verstehen – aber für alle Zuhörenden: Wenn ihr Transaktionsdaten habt, könnt ihr bereits anfangen, positive Entscheidungen zu treffen.

Joannes Vermorel: Was mir bei nahezu allen Kunden von Lokad aufgefallen ist – und wir sprechen hier von mehr als 20 Milliarden jährlichem Warenfluss, den Lokad steuert – kommt 99 % der Informationen, und eigentlich sogar noch mehr, vermutlich 99,99 % der Informationsmenge, aus Transaktionssystemen.

Außerdem wirst du wahrscheinlich ein paar Dutzend Meta-Parameter – wirtschaftliche Treiber – haben, die manuell gepflegt werden müssen. Aber hier müssen wir sehr konservativ sein, und in der Praxis sind es nur wenige Dutzend. Deshalb muss die Datenqualität hier hoch sein. Es ist schwierig, aber wir sprechen von einer sehr kleinen Anzahl wichtiger Parameter – Parameter, die so bedeutend sind, dass sie mehrere Meetings pro Parameter wert sind.

Aber letztlich muss es sich um einen strategischen, wirtschaftlichen, hochrangigen Parameter handeln, nicht um etwas, das auf SKU-Ebene liegt. All das muss vollständig automatisiert werden, und das ist möglich.

Deshalb sage ich, dass die Daten normalerweise ausgezeichnet sind, denn was du brauchst, ist die Transaktionshistorie. Wenn du ein Problem richtig angehst, brauchst du nicht Millionen von Parametern in deinem System, die manuell gepflegt werden müssen und in so vielen Formen auftreten können.

Viele Systeme verlangen von Praktikern, dass sie die Durchlaufzeit eingeben. Aber warum musst du die Durchlaufzeit eingeben? Du beobachtest die Durchlaufzeiten deines Lieferanten. Durchlaufzeiten müssen prognostiziert werden, nicht vom Benutzer eingegeben.

Viele Systeme fordern den Benutzer auf, Dinge zu klassifizieren und beispielsweise zu sagen: „Ist das ein saisonales Produkt?“ Warum solltest du solche Dinge manuell erledigen, die vollständig automatisiert werden sollten, selbst wenn das Einzige, was du hast, das Produktetikett ist? Heutzutage mit LLMs war es nie einfacher, diese Art der Erkennung zu automatisieren. „Ich habe ein new product; wird dieses Produkt saisonale Muster aufweisen?“ Es ist ziemlich unkompliziert.

Du brauchst keinen Menschen, der eingreift, um zu sagen: „Oh ja, eine Ski-Kombination, oh ja, das wird saisonal sein. Okay, danke.“ Das ist die Realität: Das sind sehr grundlegende Fragen, und alle Systeme haben die Praktiker gebeten, immer wieder so viele Dinge einzugeben, die völlig offensichtlich sind und automatisiert werden könnten.

Sogar Dinge, die manchmal völlig verwirrend sind: Praktiker müssen manuell eingeben, ob es sich um ein neues Produkt handelt. Warum brauchen wir Menschen, die dem System sagen, dass es ein neues Produkt ist? Man sieht doch in der Historie, dass es keine Transaktion gab. Das Produkt wurde kürzlich im System angelegt, es gibt null Transaktionen – warum musst du es manuell als neues Produkt kennzeichnen? Das ist allerhand Unsinn.

Aber nochmals, meine Ansicht ist, dass all der Müll in diesem Bereich, in dieser Parametrisierung all dieser Richtlinien, eine veraltete Sichtweise auf supply chain widerspiegelt. Egal, welche schlechten Daten du in diesem Bereich hast, sie sind irrelevant. Was zählt, sind die Transaktionsdaten, und diese Transaktionsdaten sind gut – und sie sind gut, weil dein Unternehmen am Leben ist.

Conor Doherty: Nun, dazu – und nochmals, das ist, um etwas tiefer in die Ursachen dieser Wahrnehmung einzutauchen – denn es ist hilflos, wenn man einfach sagt: „Ich habe ein Problem.“ Vielmehr heißt es: „Okay, was sind die Ursachen dafür? Was ist der Kern davon?“

Wenn ich dir zuhöre, klingt es so, als gäbe es… okay, ich werde ein konkretes Beispiel geben, und dann kannst du darauf aufbauen. Ich habe – und ich weiß, dass du es auch gehört hast – eine Version davon gehört: „Mein ERP ist ein Chaos.“ Und das ist das System der Aufzeichnungen, über das gesprochen wird, das Buch der Transaktionsdaten: „Ich habe doppelte Tabellen, ich habe falsch benannte Spalten, es ist ein Chaos.“

Technisch gesehen sind alle Transaktionsdaten, die Rohdaten, vorhanden. Das Problem – wenn es ein Problem gibt, und das können wir diskutieren – ist: Okay, die ERP-Migration, die du durchgeführt hast, hat ein Chaos hervorgebracht. Und der Disclaimer dazu: Wir verkaufen kein ERP, wir können mit allem arbeiten, also haben wir keinerlei Eigennutz daran.

Aber meine Frage an dich lautet: Welche Rolle spielt die Auswahl der Software bei der Entstehung dieser Epidemie schlechter Daten?

Joannes Vermorel: Auch hier würde ich sagen, es handelt sich um falsche Erwartungen. Genau das war mein Fall, als ich die zweite Zielgruppe erwähnte – Datenwissenschaftler, Kaggle-Wettbewerb. Ich habe nicht behauptet, dass das ERP, die Systeme der Aufzeichnungen, ordentlich und sauber sein würden. Die Komplexität wird astronomisch sein, und das ist in Ordnung.

Das sind keine schlechten Daten. Das sind einfach sehr komplexe und sehr undurchsichtige Daten – unterschiedliche Probleme. Ja, wenn du 10.000 Tabellen hast, ist es sehr schwierig, den genauen Lagerbestand zu lokalisieren. Es ist mühsam, und es kann Wochen dauern, um herauszufinden, wo ein bestimmtes Datenelement im System tatsächlich zu finden ist. Aber nochmals, das sind keine schlechten Daten.

Dann gibt es tatsächlich ein weiteres Problem: Die Semantik für eine gegebene Spalte kann heterogen sein. Was meine ich? Ich meine, dass die Semantik, die du für eine bestimmte Daten-Spalte haben kannst, je nach Zeile variieren kann. Das ist eine Komplikation.

Nur ein Beispiel: Einige fehlgeleitete ERP-Anbieter haben vor Jahren beispielsweise entschieden, dass in der Bestell-Tabelle, wenn die Menge positiv ist, es sich um einen Verkauf handelt, also verkaufst du an einen Kunden, und das Datum ist das Transaktionsdatum für den Verkauf. Aber wenn die Menge negativ ist, handelt es sich um eine Rückgabe, also ist es das Datum der Rücksendung des Artikels. Das bedeutet, ich habe eine Spalte namens „order date“, nur dass es kein Bestelldatum ist, wenn die Menge negativ ist: Es ist eigentlich ein Rückgabedatum.

Das meine ich: heterogene Semantik – dass in derselben Spalte, je nach Zeile, je nach bestimmten Bedingungen, es manchmal so ist, dass das ERP ein Upgrade hatte und ab dem 1. Januar 2020 das Bestelldatum etwas anderes bedeutete. Aufgrund eines System-Upgrades hat sich die Semantik im Laufe der Zeit geändert.

Manchmal können es sogar die Teams im Unternehmen sein, die zu einem bestimmten Zeitpunkt beschließen, den Prozess zu ändern, und sie spezifizieren neu, was die Semantik eines bestimmten Feldes ist, sodass es eine neue Semantik erhält. Das ist also sehr komplex, ja, und das Aufdecken dessen – ja.

Aber nochmals, sind das schlechte Daten? Wenn du deinen ERP-Anbieter kennst, der vielleicht aufgrund geringerer Kompetenz im Software-Design entschieden hat, dass „order date“ entweder das Verkaufsdatum oder das Rückgabedatum sein könnte – ja, es ist fehlgeleitet, aber ist es wirklich schlecht? Ich würde sagen, die Daten sind einfach gut. Es ist lediglich eine verwirrende Semantik.

Wir kommen zurück zu der Tatsache, dass es viel Arbeit erfordert, dies neu zu etablieren, und dem stimme ich zu. Aber wenn mir Leute „schlechte Daten“ vorwerfen, antworte ich sehr häufig: Nein, deine Daten sind in Ordnung. Es ist nur so, dass wir ernsthaft daran arbeiten müssen, die tatsächliche Semantik deiner Daten neu zu definieren – und das ist viel Arbeit.

Als Faustregel gilt: Wenn wir mit Kunden beginnen, haben wir typischerweise nicht einmal eine einzige Zeile Dokumentation pro Feld, pro Tabelle. Wenn wir fertig sind, haben wir in der Regel eine Seite Dokumentation pro Feld, pro Tabelle für die Felder, die tatsächlich für die Lokad-Initiative relevant sind, nämlich supply chain optimization.

Nichts desto trotz, 20 Tabellen, 20 Felder – wir sprechen hier von 400 Seiten Dokumentation. Nicht IT-Dokumentation, sondern supply chain-Dokumentation, da wir die Semantik dessen, was dieses Feld aus supply chain-Perspektive bedeutet und impliziert, festhalten müssen. Also ja, das ist viel Arbeit.

Ich denke, dass es – wiederum unter dem Vorwand schlechter Daten – sehr häufig einfach daran liegt, dass viele Menschen den Aufwand, der in diese semantische Qualifizierung fließt, nicht erkannt haben. Darüber hinaus haben wir inkompetente Softwareanbieter, die dies gerne als Sündenbock für die Daten heranziehen, was eine höfliche Art ist, dem Kunden zu sagen: „Es ist deine Schuld.“

Conor Doherty: Nun, dazu – ich… du wusstest nicht, dass ich das machen würde, aber offensichtlich ist dein neues Buch erschienen, und zur Vorbereitung darauf bin ich tatsächlich zu deinem alten Buch zurückgegangen.

Und für die alten Hasen, die bereits beide Bücher von Joannes gelesen haben, könnt ihr jetzt euer Exemplar herausholen. Offensichtlich ist der Code in den letzten paar hundert Seiten dieses Buches heute vielleicht nicht mehr so relevant, aber die ersten… Ich sage, die ersten hundert Seiten sind immer noch sehr, sehr relevant.

Und für alle, die ihr Exemplar zur Hand haben: Auf Seite 60, zum Thema Semantik – und nochmals, das soll nur zeigen, dass es keine abstrakte Philosophie ist, die du da darlegst – werde ich gleich ein sehr konkretes Beispiel geben und dir eine sehr konkrete Frage stellen, aber ich werde daraus nur für einen kurzen Moment vorlesen, weil ich es sehr aufschlussreich finde.

Also hier, Seite 60: Wenn wir von der Menge pro Tag in Bezug auf ein bestimmtes Datum sprechen, bringt das Datum allein eine eigene Reihe von Mehrdeutigkeiten mit sich. Es könnte das Datum sein, an dem der Kunde eine Bestellung aufgegeben hat. Der Kunde hat eine Vorbestellung bestätigt. Das Produkt wurde an den Kunden versandt. Der Bestelleintrag ist schließlich im ERP angekommen. Der Bestelleintrag wurde zuletzt im ERP geändert. Die Zahlung des Kunden wurde schließlich erhalten. Du hast so etwas gesagt, usw. Aber man könnte auch sagen, wenn die Garantie- oder Rückgabefrist abgelaufen ist.

Nun, das sind alles konkrete semantische Bedeutungen für ein einfaches Datum.

Joannes Vermorel: Ja. Für ein einfaches Datum.

Conor Doherty: Genau. Aber mein Punkt ist: Was ist der Schaden, wenn ich einen der genannten auswähle? Ist das wie ein Entscheidungsbaum, bei dem sich die Entscheidungen, die ich treffen kann, plötzlich drastisch unterscheiden? Erkläre, warum, damit sie das verstehen.

Joannes Vermorel: Ja. Der Knackpunkt bei der Semantik ist, dass, wenn man sie falsch interpretiert, der einzige verlässliche Hinweis darauf, dass man falsch liegt, darin besteht, dass am Ende der Pipeline absurde Entscheidungen generiert werden.

Bis du eine vollständig automatisierte Pipeline hast, die Endspielentscheidungen generiert – Ressourcenzuweisung für die supply chain: was du kaufst, was du produzierst, wo du die Dinge lagerst, deine Preisgestaltung für jeden verkauften Artikel – solange du nicht eine vollautomatische data pipeline hast, ein numerisches Rezept, das diese Entscheidungen generiert, fehlt dir das Instrument, das du benötigst, um deine Semantik zu bewerten und anzufechten.

Wenn du es in deiner Dokumentation falsch festhältst – du denkst, dieses Bestelldatum sei der Zeitpunkt, an dem die Zahlung abgewickelt wurde; in Wirklichkeit ist es das nicht. Es ist der Zeitpunkt, an dem du bereit bist, den Artikel an den Kunden zu versenden – die Dokumentation ist falsch. Du wirst das nicht bemerken können. Niemand wird das bemerken können.

Vielleicht, wenn du nach zwei Tagen intensiver Analyse dieses Feldes tätig wirst, kannst du das korrigieren. Aber du musst wissen, dass von vornherein ein Fehler vorlag. Wir sprechen hier – selbst für eine kleine Initiative – von Hunderten von Feldern. Wirst du mehrtägige Workshops für jedes einzelne Feld durchführen, um sicherzustellen, dass deine Semantik korrekt ist? Das ist nicht vernünftig.

Die vernünftige Herangehensweise besteht also darin, euer Bestes zu geben, einen bestmöglichen Schätzwert zu ermitteln und dann die Entscheidung basierend auf dieser Interpretation generieren zu lassen. Tada – gelegentlich werden die Entscheidungen absurd sein. Wenn wir Initiativen starten, generieren wir eine Menge geradezu absurde Entscheidungen.

Dann schauen wir uns das an, und die Leute sagen: „Oh, diese Zahl ist Unsinn.“ Okay. Analysiere rückwärts, was uns zu dieser unsinnigen Entscheidung geführt hat, und indem wir zurückverfolgen, betreiben wir Reverse Engineering. Du musst dafür die entsprechenden Instrumente haben.

Am Ende wirst du sagen: „Ah, dieses Datum – oh, wir haben es missverstanden.“ Tatsächlich ist die in dieser Situation anwendbare Durchlaufzeit völlig anders, weil wir das Datum missverstanden haben. Okay, gut. Lass uns die Entscheidung mit einer korrigierten Interpretation für dieses Datum neu generieren. Oh, jetzt sieht es viel vernünftiger aus. Gut. Weiter.

Grundsätzlich besteht der einzige Weg, zu beurteilen, ob deine Semantik korrekt ist, letztlich darin, sie in der realen Welt zu testen: Generiere eine Entscheidung und lass die Praktiker sagen: „Ergibt das Sinn?“ Wenn nicht, musst du zurückgehen.

Der Fehler, den viele alternative Tools machen, ist, dass wenn die erzeugten Daten Unsinn sind, sie sagen: “Oh, du musst die Parameter anpassen.” Ich sage: absolut nicht. Du musst die Parameter nur anpassen, wenn diese tatsächlich als die Ursache des Problems angesehen werden, das du beobachtest. Andernfalls ist dies nicht die Lösung.

Sehr, sehr häufig, das Problem… Ich kann die Bedeutung von Semantik gar nicht hoch genug betonen. Es ist äußerst kompliziert. Der einzige Weg, dies zu tun, ist, sich die generierten Entscheidungen anzusehen – was noch problematischer ist, da viele Tools im Planungsbereich niemals Endentscheidungen generieren – und sich somit das Instrument zu berauben, das es ihnen ermöglichen würde, zu beurteilen, ob sie die richtige Semantik haben.

Conor Doherty: Richtig. Nun, nochmals, im Hinblick darauf, was du gerade erwähnt hast: die Idee der Daten – wir nutzen Daten, um Entscheidungen zu treffen, ganz gleich, ob man probabilistische Vorhersage einsetzt oder nicht –, das würde ein Lokad-Ansatz befürworten. Aber grundsätzlich werden die Daten verwendet, um zumindest einen Schritt zu erleichtern: die Prognose, nach der dann eine Entscheidung getroffen wird.

Aber eine der häufigsten Aussagen von Praktikern ist: “Die Daten enthalten viel Rauschen.” Im Zusammenhang mit der Prognose – sind verrauschte Daten ein Problem?

Joannes Vermorel: Absolut nicht. Wenn dein Geschäft beispielsweise unbeständig ist – du hast Kunden, die manchmal eins und manchmal 100 bestellen – dann ist das die Realität deines Geschäfts.

Viele supply chain Methoden, also numerische Methoden, sind äußerst fehlerhaft. Wenn sie auf etwas stoßen, das als statistischer Ausreißer gilt, gerät die numerische Methode außer Kontrolle. So hast du einen Ausreißer, und das Ganze entgleist und liefert völligen Unsinn.

Und dann sagen die Leute: “Oh, wir müssen zurückgehen und diese Historie verändern, Ausreißer bereinigen.” Sie sagen: “Diese Ausreißer sind schlecht, sie sind Symptome von schlechtem …” Hier bin ich völlig anderer Meinung. Wenn deine Kunden in der Vergangenheit tatsächlich 100 Einheiten bestellt haben, mag das ein Ausreißer sein, aber das ist Realität. Es ist passiert.

Offensichtlich, wenn du in deinem System einen Eintrag hast, der besagt, dass eine Million Einheiten bestellt wurden, aber eine solche Bestellung nie erstellt wurde, nun, das sind fehlerhafte Daten. Wir beziehen uns auf transaktionale Daten: Transaktionsdaten sind akkurat.

Aber wenn du eine numerische Methode hast, die dir verrückte Ergebnisse liefert, weil sie mit einem Ausreißer in den historischen Daten konfrontiert wird, liegt das Problem nicht bei den Daten. Das Problem ist die numerische Methode, die einfach Mist ist. Du hast es mit einer fehlerhaften Methode zu tun. Du solltest diese Methode verwerfen und etwas einsetzen, das numerisch besser funktioniert. Das ist der Kern.

Das ist typischerweise eine Situation, in der die Daten vollkommen in Ordnung sind und in der Anbieter, die hochgradig fehlerhafte Methoden vorschlagen, ihre eigenen Kunden tatsächlich davon überzeugen, dass sie ihre schlechten Daten manuell korrigieren müssen, während die Daten in Wirklichkeit absolut korrekt sind und der Fehler in der numerischen Methode selbst liegt.

Conor Doherty: Nun, das ist eigentlich eine perfekte Gelegenheit, zu wechseln zu … also, es sind einige … okay, zwei sind privat hereingekommen. Entschuldige, gib mir einen Moment, ich sortiere das und formuliere es als Frage.

Also, aus der Perspektive der Praktiker: “Wir haben bereits einen Data Lake gebaut und wir haben selbstverständlich auch unseren Katalog, aber unsere Benutzer, unsere Endnutzer, sagen, die Daten seien falsch. Was ist deiner Meinung nach der Engpass: Technik oder Semantik? Und wie vermeidet Joannes – beziehungsweise wie vermeidet Lokad – endloses Umbenennen?”

Weil du, wie bereits erwähnt, viel über Semantik und deren Bedeutung gesprochen hast. Es hängt davon ab, wie du deinen Data Lake aufbaust. Ist dein Data Lake eine perfekte Eins-zu-eins-Kopie deiner Aufzeichnungen im System der Aufzeichnungen? Kein Pre-Processing, keine Verbesserungen, keine Joins, kein Filter irgendeiner Art. Es ist buchstäblich Eins-zu-Eins. Möglicherweise gibt es eine kleine Verzögerung, weil die Daten nicht live aus dem ERP kopiert werden, aber abgesehen von dieser Kopierverzögerung ist es genau eine Kopie der Daten, wie sie existieren.

Joannes Vermorel: Wenn sich die Leute darüber beschweren, sind wir wieder beim zweiten Problem mit Data Scientists: “Oh, die Daten sind nicht ordentlich und sauber. Das ist nicht wie bei Kaggle-Experimenten. Wir sind verwirrt.” Ich sage: Leider ist das die Welt, in der du lebst. Du lebst in einer Welt, in der die Informationen in deinen Geschäftssystemen sehr komplex sind. Es gibt kein Entkommen. Es gibt keine Alternative.

Du magst dich darüber beschweren, aber es ist wie sich über die Schwerkraft zu beklagen. Es ist einfach eine Tatsache des Universums. Du musst damit leben.

Sehr häufig ist nicht das ideale Szenario gegeben, das ich für den Data Lake beschrieben habe – nämlich eine reine, unveränderte Kopie der verschiedenen Geschäftssysteme. Und du könntest fragen: Warum hast du einen Data Lake, wenn es nur eine Kopie ist? Die Kurzantwort lautet: Weil du dein ERP-System, dein Transaktionssystem, nicht zusätzlich belasten möchtest. Dein Transaktionssystem muss super flink bleiben.

Wenn du Leute hast, die abfragen: “Ich möchte alle Verkaufsaufträge der letzten fünf Jahre, schmeißt mir einfach alles raus”, wird das System verlangsamt. Das bedeutet, dass jemand, der versucht, etwas abzurufen, mehrere Sekunden warten muss, weil die Ressourcen aufgrund dieser massiven Datenextraktionsabfrage ausgelastet sind. Deshalb ist es Best Practice, eine Replikation zu erstellen und diese massiven Abfragen auf der Replik ausführen zu lassen, nicht auf der primären Instanz des Systems der Aufzeichnungen.

Zurück zum ursprünglichen Punkt: Was ich in vielen Data Lakes beobachte, ist, dass das IT-Team einen gravierenden Fehler macht. Sie verarbeiten die Originaldaten erneut. Sie wollen sie verbessern.

Was ist der Haken? Der Haken ist: Sie generieren nicht die Entscheidungen. Daher kennen sie die Semantik nicht. Somit ist die Transformation, die sie auf die Daten anwenden, garantiert fehlgeleitet, falsch, und als Ergebnis endest du mit Daten, die nicht das sind, was du erwartest, nicht das, was du benötigst – und es gibt keine Lösung.

Egal wie kompetent und engagiert sie sind, ihnen fehlt das entscheidende Instrument, nämlich die Rückentwicklung der irrwitzigen Entscheidungen. Per Definition ist dies nicht die Aufgabe der IT, diese Geschäftsentscheidungen zu generieren. Daher kann sich die IT nur um das technische Fundament kümmern: die Datenbanken einrichten, sicherstellen, dass die Instanzen sicher sind, dass sie über genügend RAM, Festplattenbandbreite und Infrastruktur verfügen – ja.

Aber wenn du Semantik willst, kann die IT sich nicht mit Semantik befassen. Die Semantik ist viel zu spezifisch für jede Branche. Es kann nicht erwartet werden, dass sie sowohl Buchhaltungsspezialisten, Marketingspezialisten, supply chain specialist, Rechtsspezialisten und dergleichen sind. Deshalb können die Semantiken nur in den Händen der Praktiker liegen. Per Definition wird es die IT überfordern, wenn du versuchst, diesen Kampf für dich auszutragen.

Conor Doherty: Nun, nochmals, es gab zwei vorherige Kommentare, die ich sowohl persönlich in Gesprächen als auch in Meetings erhalten habe, also entscheide ich, welcher der beste Nachtrag wäre.

Ich möchte auf der Idee des Konflikts zwischen IT und Ops aufbauen. Wörtlich hieß der Kommentar: “Die IT sagt, unsere Daten sind schrecklich, aber mein Ops, die Praktiker, die sie nutzen, sagen, sie sind in Ordnung”, denn wie du zuvor angemerkt hast, wenn du Entscheidungen triffst und Geld verdienst, ist es für das Geschäft in Ordnung.

Also lautet die Frage: Wie bewertet ihr – also wir – objektiv die Qualität und entscheidet, was jetzt repariert werden muss, was später, oder was einfach so ausgerollt wird?

Joannes Vermorel: Rendite der generierten Entscheidungen. Wenn du Daten hast, die angeblich schlecht sind, aber die daraus abgeleiteten Entscheidungen gut ausfallen, sind sie dann schlecht? Vielleicht nicht. Vielleicht sind sie völlig irrelevant. Uns ist es egal.

Wenn du ein Datenelement hast, das im Grunde genommen unbedeutend ist, spielt es keine Rolle, ob es korrekt ist oder nicht. Uns ist das egal. Deshalb bewerten wir bei Lokad die Datenqualität wirklich in Dollar: Was ist der Return on Investment, wenn man dieses Datenelement verbessert – was auch immer das bedeuten mag und je nach Fall variiert?

Wenn die Verbesserung dieser Daten Millionen Dollar pro Jahr einbringt, weil wir dadurch bessere Entscheidungen treffen, unglaublich. Das sollte Priorität haben. Wahrscheinlich sollten wir investieren. Wenn diese Daten sogar noch schlechter sein könnten und es keinen Unterschied macht, ist es uns egal.

Deshalb sage ich: Der einzige Weg, die Qualität der Daten zu beurteilen … deshalb kann die IT diese Bewertung nicht vornehmen, denn diese Bewertung fußt auf den Entscheidungen, die dein Unternehmen letztlich generiert. Sind sie schlecht oder nicht? Nun, das kommt darauf an.

Zum Beispiel kannst du ein Feld haben – in der Luft- und Raumfahrt gibt es viele Felder –, ein Feld, das bei 99 % der Artikel unvollständig ist, und sehr häufig gibt es eine Notiz, die etwa lautet: “Die C-Nummer befindet sich an dieser Stelle der Komponente.” Sind das gute oder schlechte Daten?

Die Realität ist, dass es bei quasi allen Flugzeugteilen völlig offensichtlich ist, wo sich die C-Nummer befindet. Du brauchst keine Notiz, die dir sagt, wo die C-Nummer ist. Du siehst sie einfach – sie ist offensichtlich, du liest sie. Aber in einigen seltenen Fällen ist es knifflig und sie befindet sich an einer Stelle, die etwas schwer zugänglich ist, häufig aus mechanischen Gründen. In diesem Fall kann eine kleine Notiz hilfreich sein, um zu zeigen, wo man suchen muss.

Aus IT-Sicht würdest du sagen: “Oh, du bist so inkonsistent bei deinen Dateneingaben. Schau dir dieses Feld an: Es ist nur bei etwa 0,5 % der Artikel gesetzt.” Aber die Realität ist: ja, aber es sind genau die wenigen Artikel, bei denen es tatsächlich eine Rolle spielt.

Nochmal, ich sage: Der einzige Weg, zu beurteilen, ob Daten gut oder schlecht sind, besteht darin, sie dem Test des Entscheidungsprozesses zu unterziehen.

Conor Doherty: Nun, das könnte in der Tat den nächsten Kommentar beantworten. Wiederum, das ist sehr, sehr spezifisch, aber es berührt ein Thema, das ich für den Elefanten im Raum halte: Heutzutage wollen die Leute ihre Daten für KI nutzen. Sie wollen KI-Projekte und dergleichen.

Das ist also von einem Freund des Kanals: “Wir betreiben über 40 Länder. Wir nutzen mehrere ERPs und WMS’s, um den Bestand zu verwalten für 40 Länder. Wann sind unsere Daten gut genug, um mit KI zu starten, und was macht ihr eigentlich in den ersten 90 Tagen – also im Wesentlichen im ersten Quartal?”

Joannes Vermorel: Wenn du ein Land hast, in dem du genau weißt, was du kaufst, was du produzierst und was du verkaufst, bist du für KI bereit. Das ist alles. Für uns war das schon immer so. Der Maßstab ist also nicht hoch. Das ist das Interessante.

Der Maßstab, um den Entscheidungsprozess zu robotisieren – ob du es nun KI nennst oder nicht, ganz gleich, welches Label du darauf setzen möchtest – ist ausreichend und genügt. Das ist es, was wir tun. Deshalb ist oft die Pflege von Parametern, die alle feinen Workflow-Aspekte regeln, damit Menschen die Arbeit manuell erledigen können, irrelevant, weil wir sie nicht verwenden werden.

Grundsätzlich stellt KI die Arbeitsteilung völlig in Frage. Der gesamte Workflow, in dem du Prognostiker, gefolgt von Planern, Budgetmanagern, Bestandsmanagern und so weiter hast, macht im Zeitalter der KI keinen Sinn mehr.

Die KI wird die Daten als Monolith verarbeiten, indem sie die Rohdaten aus dem System der Aufzeichnungen übernimmt, und sie wird direkt die Entscheidungen ausgeben – mit allen Instrumenten, die sie dabei unterstützen. Das werden die economic drivers sein, um zu erklären, warum diese Entscheidung getroffen wurde. Perfekt.

Dein KI-System – was ich die “Systems of Intelligence” nenne – ist im Grunde etwas wie ein Monolith, der Aufzeichnungen aufnimmt und Entscheidungen mit unterstützender Instrumentierung generiert, und das war’s.

Wenn mir Leute sagen, “Wir haben 40 ERPs”, würde ich sagen: Ich glaube nicht, dass jemand 40 hat. Das wäre … Ich habe Unternehmen gesehen … Ich habe ein Unternehmen gesehen, das 17 ERPs im selben Land hatte. Das ist der Rekordhalter. Ich werde den Namen dieses Unternehmens nicht nennen. Es ist ein sehr, sehr großes Unternehmen. Dasselbe Unternehmen, dasselbe Land. Da ging es wirklich drunter und drüber.

Fazit: Du wirst diesen Aufwand, die Semantik ERP für ERP wiederherzustellen, tragen müssen. Das wird schmerzhaft werden. Offensichtlich.

Er fragte nach den ersten 90 Tagen. Typischerweise dauert es bei uns zwei Monate, um die Semantik zu etablieren. Das ist etwas, das wir für ein Set von Geschäftssystemen tun, die beispielsweise ein Land betreiben. Aber die wirklichen Grenzen sind nicht unbedingt das Land. Sie hängen vielmehr davon ab, welche IT-Systeme wir in den Umfang einbeziehen müssen: ERP, WMS, e-commerce Plattform und dergleichen.

Unser Umfang wird stark von den Grenzen der IT-Systeme bestimmt, sehr häufig gerade weil es um die Etablierung der Semantik geht. Sobald wir dann die Semantik – also die erste Datenpipeline – haben, beginnen wir mit der Iteration der Entscheidungen, und typischerweise dauert das etwa zwei Monate.

Also: zwei Monate, um die Datenpipeline aufzubauen und eine erste fundierte Meinung zur Semantik jedes Feldes zu erhalten. Aber dann benötigst du weitere zwei Monate an Iterationen, um den gesamten Wahnsinn zu beseitigen – sehr häufig, indem du die Semantik identifizierst, die in der ersten Iteration falsch erfasst wurde.

Also, in 90 … typischerweise sind es nicht 90 Tage; es werden, sagen wir, 120 Tage sein. Dann kannst du – völlig ohne Wahnsinn – Entscheidungen in Produktionsqualität erzielen. Das ist eine typische Initiative von Lokad.

Aber der Kern ist: Du musst in der Lage sein, sehr schnell zu iterieren, typischerweise mehrmals am Tag, an diesen verrückten Entscheidungen, weil du so viele Probleme mit der Semantik der Daten erkennen wirst.

Conor Doherty: Nun, nochmals, und ich erwähne das nur, weil du das angesprochen hast: Du gibst ein explizites Beispiel, wie wir das machen könnten. Ein zentraler Punkt dabei ist, dass diese Dinge, die du beschreibst – die Implementierung – parallel laufen würden zu dem, was wir einen Dual Run nennen. Es läuft parallel zu dem, was du derzeit tust, sodass du mit eigenen Augen den Unterschied sehen kannst.

Joannes Vermorel: Ja. Genau da ist es völlig entscheidend, etwas völlig Unbeaufsichtigtes zu haben. Warum? Denn wenn dein Parallelprozess, dein Dual Run, – wenn der zweite Prozess viel Arbeitskraft erfordert – woher soll diese Arbeitskraft kommen?

Das Unternehmen, sagen wir, wenn es 15 Planer hat, sind diese alle zu 100 % ausgelastet. Wären sie nicht nahezu durchgehend beschäftigt, hätte das Unternehmen nur 12 oder 10 Planer. Per Definition haben Unternehmen keine Ersatzmitarbeiter, außer in besonderen Umständen. In der Regel gibt es bei den meisten Jobs keine Ersatzkräfte, die nichts tun und nur als Backup dazu da sind, das zusätzliche System zu testen.

Diese Personen benötigen bereits acht Stunden Arbeit, nur um ihre Arbeit am Tag zu erledigen. Sie können sich vielleicht täglich eine halbe Stunde dafür nehmen, um einen kurzen Blick auf ein anderes System zu werfen, nur um die Ausreißer, die schlechten Entscheidungen, die verrückten Entscheidungen zu identifizieren, aber sie können nicht acht Stunden in ihrem System und dann acht Stunden in einem anderen System verbringen, in dem sie den gleichen Workflow durchlaufen müssen.

Deshalb sage ich, dass es absolut kritisch ist, dass dieses neue Entscheidungsfindungssystem völlig unbeaufsichtigt sein muss; ansonsten werdet ihr operativ nicht in der Lage sein, es einzusetzen. Das ist etwas, das Lokad vor einem Jahrzehnt gelernt hat.

Conor Doherty: In Ordnung. Nun, ich habe die Liste der aufgeworfenen Kommentare abgearbeitet oder es wurde mir ausdrücklich gesagt: “Please ask you on the air.”

Um einen konstruktiven Abschluss zu finden: Wir haben dort viel abgedeckt. Was siehst du in der nächsten Woche – oder wähle einen beliebigen Zeithorizont, aber sag nicht ein Jahr – in den nächsten 30 Tagen beispielsweise, an Änderungen, die leicht umzusetzen sind und die die Menschen tatsächlich durchführen können, wenn auch nicht, um die Qualität zu verbessern, aber zumindest um die interne Wahrnehmung der Leistungsfähigkeit des aktuellen Zustands ihrer Daten zu steigern?

Joannes Vermorel: Ich bin mir nicht sicher, ob es kurzfristig etwas zu unternehmen gibt. Für mich geht es wirklich darum, zu erkennen, was als tatsächliche primäre Informationsquelle behandelt werden sollte und was als numerisches Artefakt gilt. Das ist nicht dasselbe.

Sobald Sie diese Trennung vornehmen und einen nüchternen Blick auf Ihre echten, ereignisgesteuerten Daten werfen – die Daten, die die tatsächlichen Ereignisse darstellen, welche eine finanzielle Auswirkung auf das Unternehmen haben – werden Sie höchstwahrscheinlich feststellen, dass diese Daten exzellent sind. Ja, sie werden chaotisch sein, aber sie sind hervorragend. Also ist dies nicht das Problem.

Das wäre meine Botschaft: Schlechte Daten in Unternehmen, die seit einem Jahrzehnt oder länger digitalisiert sind, sind niemals das Problem. Lokad hat in den letzten fünfzehn Jahren über hundert Implementierungen durchgeführt.

Manchmal hatten wir Probleme mit Systemen, die zu langsam waren, um die Daten zu extrahieren. Das war manchmal ein Problem. Übrigens, deshalb möchte man einen Data Lake hinzufügen, denn manchmal haben wir beispielsweise “SELECT * FROM table X” ausgeführt, und das System erzeugte tatsächlich einen Out-of-Memory-Fehler, wenn wir das gemacht haben.

Also, okay, wir hatten Fälle, in denen die Datenextraktion äußerst kompliziert war, weil das System zusammenbrach, wenn wir versuchten, die Daten aus dem System zu ziehen. Das ist ein reales Problem. Ich hoffe wirklich, dass Sie sich nicht in einer solchen Situation befinden, aber es könnte passieren. Das ist der Grund, warum Sie einen Data Lake haben möchten.

Abgesehen von diesen sehr technischen Problemen, die mit veralteter Infrastruktur zusammenhängen, hatten wir nie wirklich schlechte Daten. Was wir in Hülle und Fülle hatten, waren äußerst undurchsichtige, schwer verständliche Daten, aber grundsätzlich war es etwas, das auf der Lokad-Seite gelöst werden musste.

Ja, es war also ein großes Problem für uns, aber grundsätzlich war es nicht das Problem des Kunden. Der Kunde benutzte sein System einfach so, wie er es sollte. Das Ergebnis war: Für jemanden, der ein automatisiertes Entscheidungsfindungssystem darauf aufbauen möchte, stellt das eine Herausforderung dar. Aber nochmals: Die Herausforderung liegt in der korrekten Interpretation der Daten und nicht darin, dem Kunden die Schuld dafür zu geben, dass er diese Daten überhaupt gesammelt hat.

Conor Doherty: Nochmals, wir sind jetzt seit einer Stunde dabei, also denke ich, dass ich mir in Bezug auf das Marketing einen kleinen Kommentar erlauben kann, aber es ist ein entscheidender Punkt, der vermittelt werden muss.

Eine der Erkenntnisse, die ich persönlich aus vielen der Gespräche, die ich kürzlich geführt habe, gezogen habe, ist, dass den Leuten nicht unbedingt immer klar wird, dass, wenn wir sagen, “Hey, schau, deine Daten sind so gut, wie sie sind”, sie nicht erkennen, dass, wenn man mit Lokad – oder einem anderen kompetenten Anbieter – zusammenarbeitet, diese Last übernommen wird.

Also: Du gibst ihnen die Daten, du gibst uns die Daten. Es geht nicht darum, dass du diese verarbeiten musst. Und sie sollten… nochmals, wenn der Anbieter…

Joannes Vermorel: Wenn der Anbieter diese Last nicht selbst trägt, ist das ein Rezept für Sündenbock-Macherei.

Conor Doherty: Genau.

Joannes Vermorel: Der Anbieter wird einfach Ihnen die Schuld geben, und Sie werden in einer Situation enden, in der das Unternehmen in sieben Jahren eine halbe Milliarde verschwendet. Am Ende kommt der Bericht zu dem Schluss, dass es alles die Schuld von … war, und der Anbieter sagt nur: “No, nothing to see here. It’s not my fault. Come on.”

Übrigens, im Lidl-Fall ist das sehr interessant, denn sie gaben an, dass die Daten an einem bestimmten Punkt schlecht seien. SAP sagte: “Oh, Lidl, they drive their analysis on the purchase price, and we drive all our analysis on the selling price, and that was the cause.”

Für mich heißt das: Leute, das ist Semantik 101. Zunächst einmal ist es ein triviales Problem: Ist es der Verkaufspreis oder der Einkaufspreis? Ja, hier gibt es eine semantische Herausforderung: Über welchen Preis sprechen wir? Aber lassen Sie uns klarstellen: Es handelt sich nicht um einen sehr feinen Nuancenunterschied. Was semantische Unterscheidungen betrifft, so ist es eine sehr, sehr leicht zu bewältigende Unterscheidung.

Dann ist noch das, was für mich noch verwirrender ist: Offensichtlich braucht man beides. Man benötigt sowohl den Einkaufspreis als auch den Verkaufspreis, um die Marge zu kennen.

Die Vorstellung, dass der Anbieter nach sieben Jahren es schafft, dem Kunden die Schuld zuzuschieben und zu sagen: “Oh, you know what, they are organizing all their supply chain around the purchase price, it’s such a complication for us because we are expecting the selling price,” ist genau die Art von Unsinn, die man bekommt, wenn der Anbieter sich nicht dazu verpflichtet, wirtschaftlich leistungsfähige Entscheidungen zu liefern.

Das sollte der Ausgangspunkt sein; ansonsten wird man im supply chain-Bereich ganz schön viel Unsinn erleben. Am Ende des Tages, nach dem Ausgeben einer Menge Geld, wird es dem Anbieter gelingen, einem selbst die Schuld in Form von schlechten Daten zuzuschreiben.

Nochmals: Wenn wir nicht akzeptieren, dass nur Entscheidungen zählen, gibt es so viele Daten, die völlig unerheblich sind. Offensichtlich werden diese unerheblichen Datenstücke von sehr niedriger Qualität sein, und das ist völlig in Ordnung.

Ein ERP-System hat 10.000 Tabellen. Jede Tabelle enthält Dutzende von Feldern. Sollten all diese Daten ordentlich und sauber sein? Wahnsinn. Warum sollte man das jemals wollen? Es ist viel zu kostspielig.

Wenn Sie dieses Spiel mit schlechten Daten mit dem Anbieter spielen, wird der Anbieter immer der Gewinner sein, denn es wird immer viele Tabellen und viele Felder geben, in denen sie objektiv betrachtet miserabel und unerheblich sind. Das ist der entscheidende Punkt: unerheblich.

Conor Doherty: Okay. Zusammenfassend: Wählen Sie Ihren Anbieter sorgfältig aus, wenn Sie alles auf den Punkt bringen.

Joannes Vermorel: Ja. Und verstehen Sie wirklich: Wenn Sie von der Qualität des ERP sprechen, was ist dann die Absicht? Was ist beabsichtigt? Es gibt so etwas wie Reinheit eines ERP-Systems in moralischer Hinsicht für ein Unternehmen nicht. Es erfüllt einen Zweck.

Qualität bedeutet Eignung für den Zweck, und das war’s.

Conor Doherty: Das war’s. Vielen Dank. Mir gehen die Fragen aus. Wir sind seit einer Stunde dabei, also denke ich, dass die Zeit abgelaufen ist.

Wie immer, vielen Dank für eure Einsichten, und danke an alle, die teilgenommen und ihre Privatnachrichten geschickt haben. Wie ich gleich zu Beginn sagte und woher dieses Thema stammt, wenn ihr das Gespräch fortsetzen möchtet, wendet euch privat an Joannes und mich. Wir freuen uns immer, zu plaudern.

Wie ich letzte Woche sagte und jede Woche sagen werde, wir sind liebenswerte Menschen. Schaut uns an. In diesem Sinne, wir sehen uns nächste Woche. Ich habe ein spezielles Thema für nächste Woche, daher werden wir das am Montag ankündigen. Aber in diesem Sinne, macht euch wieder an die Arbeit.