Datenvorbereitung in supply chain

00:00:03 Überblick über die Datenaufbereitung in Data Science.
00:00:46 Unterschätzung der Komplexität der Datenaufbereitung.
00:02:01 Typische Projektdauer der Datenaufbereitung.
00:03:19 Herausforderungen in Geschwindigkeit und Genauigkeit der Datenaufbereitung.
00:06:07 Bedeutung der Dokumentation der Datenaufbereitung.
00:08:00 Interpretation des ‘Bestelldatums’ in supply chains.
00:09:02 Komplikationen bei der Dateninterpretation infolge von Systemupgrades.
00:10:07 Verständnis der Datensemantik zur Vermeidung von Fehlern.
00:10:15 Fallstudie: Besonderheiten von supply chain Systemen.
00:14:53 Notwendigkeit der Datendokumentation in Geschäftsprozessen.
00:16:01 Bedeutung der Datennachverfolgung in supply chains.
00:17:24 Erweiterung des Datenspektrums in automatisierter Entscheidungsfindung.
00:18:42 Risiken, wenn man sich auf Einzelpersonen zur Datenwiedergabe verlässt.
00:19:02 Herausforderungen und Erwartungen in der Datenaufbereitung.
00:20:13 Datenaufbereitung als unternehmensweite Anstrengung.
00:21:56 Bewertung der Korrektheit der Dateninterpretation anhand der praktischen Wirksamkeit.
00:23:02 Konsequenzen falscher Dateninterpretation und Bedeutung der Rückverfolgbarkeit.
00:24:37 Schwierigkeiten und Folgen mangelhafter Datenaufbereitung.
00:24:49 Das Konzept der ‘guten’ Datenaufbereitung.

Zusammenfassung

In dieser Lokad TV Folge diskutieren Moderator Kieran Chandler und Lokad-Gründer Joannes Vermorel die Feinheiten der Datenaufbereitung in Data Science, ein Prozess, der oft unterschätzt wird, aber aufgrund der DSGVO-Einhaltung derzeit Priorität genießt. Vermorel betont, dass die Datenaufbereitung, die häufig mehrere Monate und erhebliche Ressourcen beansprucht, unerlässlich ist, um das “Garbage in, garbage out”-Problem zu vermeiden. Dies erfordert, inkonsistente oder unvollständige Daten in ein verständliches Format zu überführen, was eine gründliche Dokumentation voraussetzt. Der Prozess ist komplex, geprägt durch die facettenreiche Natur von Geschäftsproblemen und den historischen Kontext der Daten. Vermorel plädiert für einen dezentralen Ansatz, der verschiedene Organisationsteams einbezieht, und ist der Ansicht, dass eine effektive Datenaufbereitung zugänglich sein und eine klare Entscheidungsfindung ermöglichen sollte.

Erweiterte Zusammenfassung

In der Lokad TV Folge, moderiert von Kieran Chandler, diskutieren er und Joannes Vermorel, der Gründer von Lokad, die komplexe, aber entscheidende Rolle der Datenaufbereitung im Bereich der Data Science. Mit dem Aufkommen von DSGVO-Vorgaben rücken Daten zunehmend in den Fokus vieler Führungskräfte, wobei Schätzungen zufolge Unternehmen derzeit über 450 Milliarden Dollar allein für die Datenaufbereitung ausgeben. Ziel der Datenaufbereitung ist es, rohe, häufig inkonsistente oder unvollständige Daten in ein Format zu überführen, das leicht zu interpretieren und anzuwenden ist.

Vermorel geht auf die häufige Unterschätzung der Komplexität der Datenaufbereitung ein. Trotz erheblicher Investitionen der Unternehmen in diesen Bereich liegen viele Projekte hinter dem Zeitplan zurück oder überschreiten das Budget. Laut Vermorel können die meisten IT-Systemfehler auf Probleme in der Datenaufbereitung zurückgeführt werden. Er erklärt, dass die vielschichtige Natur geschäftlicher Probleme sich in den Schritten der Datenaufbereitung widerspiegelt und so zur Komplexität der Aufgabe beiträgt.

Bezüglich der Zeitpläne schlägt Vermorel vor, dass groß angelegte Datenaufbereitungsprojekte mindestens einige Monate dauern können, oft bis zu sechs Monate. Obwohl man annehmen könnte, dass verbesserte Werkzeuge oder skalierbarere Software den Prozess beschleunigen sollten, ist seiner Ansicht nach der Mangel an Reife im Ökosystem der Grund für die Verzögerungen. Um das “Garbage in, garbage out”-Problem wirklich zu vermeiden, müssen die Daten zunächst dokumentiert und geklärt werden. Dieser Prozess trägt, so argumentiert er, zu dem verlängerten Zeitrahmen bei.

Auf die Frage, ob es möglich sei, diesen Prozess zu beschleunigen, erklärt Vermorel, dass es nicht so einfach sei, einfach mehr Ressourcen einzusetzen. Die Daten, mit denen gearbeitet wird, wurden ursprünglich nicht zur Datenaufbereitung produziert, sondern sind ein Nebenprodukt von Unternehmenssystemen. Zum Beispiel beschreibt er, wie die Hauptfunktion eines Kassensystems darin besteht, Kundenzahlungen zu verarbeiten und nicht, Daten zu sammeln. Dennoch erzeugen auch diese Systeme Daten, die aufgrund praktischer betrieblicher Gründe, wie z. B. Barcode-Fehler, inkonsistent oder fehlerhaft sein können. Diese Inkonsistenzen erfordern umfangreiche Vorarbeiten, um sie in der supply chain optimization effektiv nutzen zu können.

Vermorel spricht auch über die Bedeutung der Dokumentation in der Datenaufbereitung. Bei Lokad beginnt ein Datenaufbereitungsprojekt üblicherweise mit weniger als einer Zeile Dokumentation pro Feld und Tabelle und endet mit einer Seite Dokumentation pro Feld und Tabelle. Diese umfassende Dokumentation ist entscheidend, um zu verhindern, dass mangelhafte Eingangsdaten zu mangelhaften Ergebnissen führen – das sogenannte “Garbage in, garbage out”-Problem. Der sechsmonatige Zeitrahmen für die Datenaufbereitung umfasst daher auch den Prozess der Erstellung dieser umfangreichen Dokumentation.

Vermorel beginnt damit, die Komplexität und mögliche Fehlinterpretationen zu erläutern, die von einem einzigen Datenelement ausgehen können: dem Datum einer historischen Bestellung. Er erklärt, dass “Datum” nicht so eindeutig ist, wie es auf den ersten Blick erscheinen mag, da es mehrere mögliche Interpretationen gibt, wie z. B. den Zeitpunkt, an dem der Kunde auf ein Produkt geklickt hat, den Moment der Bestellbestätigung, den Zeitpunkt der Zahlungsabwicklung oder wann die Ware im Lager bereitgestellt wurde.

Er weist darauf hin, dass sich die Interpretation solcher Daten im Laufe der Zeit durch Systemupgrades oder Änderungen in den Geschäftsprozessen ändern kann. Daher ist es entscheidend, nicht nur die Daten selbst zu verstehen, sondern auch den historischen Kontext, in dem sie entstanden sind. Werden diese Komplexitäten nicht berücksichtigt, kann es zu einem “Garbage in, garbage out”-Problem kommen, bei dem falsche Interpretationen zu schlechten Entscheidungen führen.

Vermorel hebt eine Fallstudie mit einem der Lokad-Kunden hervor, um seinen Standpunkt zu veranschaulichen. Dieser Kunde betreibt einen anspruchsvollen industriellen Betrieb mit kurzen lead times, bei dem es essenziell ist, die genaue Menge der bestellten Waren zu erhalten. Das System des Kunden verfügt über eine Funktion, bei der, wenn die gelieferte Menge nicht exakt der Bestellung entspricht, die gesamte Bestellung abgelehnt und zurückgesendet wird. Dies führt zu einem Dilemma, bei dem, wenn sie etwas mehr als bestellt erhalten, die ursprüngliche Bestellung im System angepasst werden muss, um der gelieferten Menge zu entsprechen. Diese Umgehungslösung ermöglicht es ihnen, die Lieferung anzunehmen und

so Störungen in ihren industriellen Abläufen zu vermeiden.

Allerdings wird dieser Prozess von scharfsinnigen Zulieferern ausgenutzt, die nun etwas mehr liefern als bestellt, da sie wissen, dass es akzeptiert wird. Dies führt zu Bestellungen, die im Vergleich zu den tatsächlichen Bedürfnissen aufgebläht erscheinen, und erzeugt Datenartefakte, die die Leistung des Einkaufsteams falsch darstellen. Vermorel betont, dass diese Komplexität dokumentiert werden muss, um Fehlinterpretationen zu vermeiden. Er besteht darauf, dass die Probleme nicht auf eine schlechte Leistung des Einkaufsteams zurückzuführen sind, sondern auf Beschränkungen im System und darauf, wie die Nutzer mit diesen Einschränkungen umgingen.

Im weiteren Verlauf wendet sich Vermorel der Frage zu, wer sich außer Lokad, einem Unternehmen, das es für probabilistic forecasts nutzt, um historische Daten kümmert. Er weist darauf hin, dass Unternehmen ihre Einnahmen und Ausgaben genau im Auge behalten, wobei diejenigen, die dies nicht tun, im Laufe der Zeit verschwinden. Dies ist, wie er sagt, eine Form des unternehmerischen “Darwinismus”.

Das Gespräch wendet sich wieder der Datenaufbereitung zu. Vermorel betont, dass Daten nicht von Natur aus “sauber” oder vollständig verständlich sind. Er schlägt vor, dass die Datenaufbereitung nicht ausschließlich ein IT-Problem sei; es gehe darum, alle Aspekte der Geschäftsdaten zu verstehen, um alle Blickwinkel des Geschäfts abzudecken. Die IT-Abteilung kann seiner Meinung nach nicht erwarten, jeden geschäftlichen Aspekt zu beherrschen und sollte nicht die alleinige Verantwortung für die Datenaufbereitung tragen.

Vermorel schlägt einen dezentralen Ansatz vor, bei dem verschiedene Teams mit unterschiedlicher Expertise innerhalb der Organisation eingebunden werden. Daten, die für den Einkauf relevant sind, sollten beispielsweise die Einkaufsabteilungen einbeziehen. Ebenso sollten Daten, die für ein Lieferanten-Scorecard benötigt werden, die Beschaffungsteams einbeziehen. Dieser Ansatz nutzt die notwendigen Erkenntnisse für eine effektive Datenaufbereitung.

Er erläutert, wie man sich über die richtige Dateninterpretation sicher sein kann, besonders wenn Informationen unvollständig vorliegen. Vermorel zieht dabei einen Vergleich zu wissenschaftlichen Theorien; es ist unmöglich zu wissen, dass eine Theorie richtig ist, aber sie kann validiert werden, wenn sie Prüfungen standhält. Die Korrektheit der Datenaufbereitung wird dadurch bestätigt, dass die aus der Interpretation abgeleiteten Entscheidungen stimmen. Führt falsche Datenaufbereitung zu unsinnigen Entscheidungen, kann die Ursache zurückverfolgt, korrigiert und neu bewertet werden.

Vermorel beschreibt daraufhin, wie eine gute Datenaufbereitung aussehen sollte, insbesondere in komplexen supply chain Szenarien. Er vergleicht sie mit einem gut geschriebenen Buch, das relevante Geschäftseinblicke und Perspektiven liefert und nicht nur technische Details umfasst. Sie sollte zugänglich und in der gesamten Organisation verbreitet sein, um ein gemeinsames Verständnis zu fördern. Dies erfordert einen kontinuierlichen Aufwand zur Dokumentation, Pflege und zum Verständnis der Daten.

Abschließend betont Vermorel, dass die Datenaufbereitung als Interpretation eines fundierten Verständnisses der Daten selbst zu sehen ist. Sobald dieses Verständnis etabliert und aufrechterhalten ist, sind die logischen Operationen an den Daten relativ unkompliziert. Gute Datenaufbereitung stellt somit sowohl ein gut geschriebenes Handbuch als auch ein gemeinsames Verständnis dar, das klare und effektive Entscheidungen in der supply chain ermöglicht.

Vollständiges Transkript

Kieran Chandler: In der heutigen Folge werden wir über die Datenaufbereitung sprechen, einen der Grundpfeiler der Data Science. Angesichts der aktuellen DSGVO-Vorgaben stehen Daten für viele Führungskräfte ganz oben auf der Agenda. Es ist auch ein großes Geschäft, wie eine kürzlich durchgeführte Umfrage zeigt, wonach Unternehmen allein über 450 Milliarden Dollar für die Datenaufbereitung ausgeben. Datenaufbereitung bedeutet, rohe Daten in ein leicht verständliches Format zu überführen, damit sie nützlich verwendet werden können. Dies ist keine leichte Aufgabe, wenn man bedenkt, dass die Daten aus vielen verschiedenen Quellen stammen und oft inkonsistent, unvollständig und fehlerhaft sein können. Also Joannes, warum sprechen wir heute über Datenaufbereitung? Wenn diese Unternehmen über 450 Milliarden Dollar investieren, sollte das doch inzwischen verstanden sein.

Joannes Vermorel: Ja, absolut. Datenaufbereitung ist ein Bereich, der zwar weithin bekannt, aber systematisch in Bezug auf Veränderungen unterschätzt wird. Es ist interessant, denn die meisten Datenaufbereitungsprojekte verpassen ihre Termine und verursachen Budgetüberschreitungen. Das Kernproblem ist, dass viele tatsächliche Fehler in IT-Systemen, Enterprise Software im Allgemeinen, auf Probleme in der Datenaufbereitung zurückzuführen sind. Es ist extrem komplex. Obwohl es ein wohlbekanntes Problem ist, liegt das Grundproblem darin, dass sich geschäftliche Komplexitäten in den Schritten der Datenaufbereitung wieder widerspiegeln und so zu einem unbeschränkten Aufgabenbereich werden. Es gibt kein abschließendes Rezept für die Datenaufbereitung.

Kieran Chandler: Wie lange sollte es also dauern, eine beträchtliche Menge an Daten aufzubereiten?

Joannes Vermorel: Ich habe noch nie ein groß angelegtes Datenaufbereitungsprojekt gesehen, das weniger als ein paar Monate gedauert hat. Üblicherweise dauert es eher sechs Monate. Manche mögen argumentieren, dass es mit besseren Werkzeugen und skalierbarerer Software schneller gehen sollte. Jedoch ist die Realität, dass es im gesamten Ökosystem an Reife mangelt, sodass – fast jedes Unternehmen, abgesehen von einigen Datenchampions wie Google – die Daten zunächst dokumentiert und geklärt werden müssen. Es gibt so viele Dinge, die mit diesen Daten gemacht werden müssen, um das “Garbage in, garbage out”-Problem zu vermeiden. Daher dauert es ein paar Monate, und sechs Monate sind ein realistisches Ziel, wenn eine komplexe supply chain involviert ist.

Kieran Chandler: Sechs Monate klingen nach einer ziemlich langen Zeitspanne. Gibt es einen Weg, diesen Prozess zu beschleunigen? Wenn ich ein großes Unternehmen bin, kann ich da nicht einfach mehr Leute einsetzen?

Joannes Vermorel: Hier stößt man auf ein spezielles Problem: Kann man mit neun Frauen in einem Monat ein Baby machen? Die Herausforderung besteht darin, die Art der Probleme zu verstehen, mit denen man es zu tun hat. Zunächst einmal wurden die Daten, die Ihnen vorliegen, nicht dafür produziert, Daten zu sein. Es handelt sich um ein Nebenprodukt Ihres Unternehmenssystems, das Ihr Unternehmen betreibt. Nehmen wir zum Beispiel eine Kassensoftware in einem Supermarkt. Ihre Hauptfunktion besteht darin, Kunden zu bedienen, die den Laden verlassen möchten, während sie den korrekten Preis zahlen. Wenn ein Barcode aus irgendeinem Grund nicht erkannt wird, wird die Kassiererin wahrscheinlich ein ähnlich bepreistes Produkt zweimal scannen. Am Ende zahlen Sie den richtigen Preis, aber was die Daten betrifft, wird ein Produkt doppelt gezählt.

Kieran Chandler: Ein Produkt, das gar nicht gezählt wird, kann Probleme im Hinblick auf das Bestandsmanagement verursachen, weil Ihre elektronischen Aufzeichnungen durcheinander geraten. Das ist keine gute Lösung, und es ist ratsam, dies zu vermeiden. Aber die Tatsache ist, dass, wenn Sie die Wahl haben zwischen der Lösung eines Datenproblems und einem reibungslosen Betrieb des Unternehmens, diejenigen vor Ort, die Menschen, die supply chains physisch betreiben, immer eine Lösung bevorzugen, die den Fluss von Waren, Kunden, Service und allem anderen nicht stört. Der Betrieb des Unternehmens hat Vorrang, und Daten sind nur ein sekundäres Nebenprodukt. Sie werden niemals als eigenständiger Aspekt behandelt. Deshalb gibt es immer so viel Arbeit, die erledigt werden muss, weil die Daten nicht ausschließlich zum Zweck der Optimierung der supply chain gesammelt wurden. Kommt es deshalb zu all diesen Herausforderungen?

Joannes Vermorel: Genau, darum entstehen all diese Veränderungen.

Kieran Chandler: Lass uns über jene Dokumentation sprechen, die du zuvor erwähnt hast. Was erwartest du in dieser Dokumentation zu sehen und wie hilft sie? Nur um zu verstehen: Wenn wir auf den Sechsmonatszeitraum zurückblicken, mit welchem Dokumentationsumfang rechnen wir?

Joannes Vermorel: Als Faustregel gilt, dass wir bei Lokad typischerweise, wenn wir ein Projekt starten, weniger als eine Zeile Dokumentation pro Tabelle pro Feld haben. Üblicherweise haben wir das nicht einmal. Wir beginnen viele Projekte, in denen wir nicht einmal eine Zeile Dokumentation pro Tabelle im ERP, MRP, WMS oder welchem System auch immer zur Steuerung deines supply chain verwendet wird, haben. Wenn wir fertig sind, haben wir am Ende eine Seite Dokumentation pro Feld pro Tabelle. Also, wenn du 20 Tabellen mit 20 Feldern hast, sprechen wir von 400 Seiten Dokumentation. Ja, es dauert sechs Monate, diese 400 Seiten Dokumentation zu erstellen.

Kieran Chandler: Das klingt nach einer riesigen Menge an Dokumentation. Wird das wirklich alles benötigt?

Joannes Vermorel: Es wird alles benötigt, wenn man vermeiden will, dass Müll hereinkommt und Müll herauskommt.

Kieran Chandler: Warum ist das so?

Joannes Vermorel: Betrachten wir einen praktischen Fall: Nehmen wir an, ich habe eine Tabelle namens “orders”. Sie enthält meine historischen Bestellungen und besitzt ein Datum. Aber ist das einfach? Sprechen wir wirklich darüber, um welche Art von Datum es sich handelt? Ist es das Datum, an dem der Kunde auf ein Produkt geklickt hat, um es in den Warenkorb auf der E-Commerce-Seite zu legen? Oder, wann der Kunde den Warenkorb validierte und die Zahlung durchführte? Oder, wann die Zahlung vom Kreditkartenprozessor validiert wurde? Oder, wann die Eingabe in das System aufgenommen wurde? Oder, wann die Bestellung zuletzt im System geändert wurde? Es gibt etwa 20 verschiedene Interpretationen nur für dieses “date”-Feld.

Außerdem, wenn dein Unternehmen mehr als ein Jahrzehnt an Geschichte hat, stehen die Chancen gut, dass die feinen Unterschiede in der Interpretation des “order date” im Laufe der Jahre verändert wurden. Es kann passieren, dass du in eine Situation gerätst, in der ein System-Upgrade stattgefunden hat und sich die Semantik dieser Spalte geändert hat.

Es ist auch nicht selbstverständlich, dass es über die gesamte historische Periode vollständig homogen ist. Dann können weitere Komplikationen auftreten, wie beispielsweise Randfälle. Zum Beispiel sollte dieses Datum das Datum sein, an dem der Kunde den Warenkorb validierte – außer, wenn die Zahlung letztlich als Betrug abgelehnt wurde. In diesem Fall ist es das Datum und die Uhrzeit, an dem die Bestellung als Betrug abgelehnt wurde.

Nochmals, es ist eigentlich kein besonders gutes Design, aber Unternehmen, die komplexe supply chains betreiben, haben komplexe Systeme und eine lange Geschichte. Daher wurde IT nicht unbedingt von Anfang an perfekt umgesetzt, und du musst mit all diesen historischen Komplikationen umgehen. Sie finden ihren Ausdruck in dieser Dokumentation. Wenn du es versäumst, all diese Komplikationen zu berücksichtigen, wirst du Probleme bekommen, wann immer du diese Daten analysieren möchtest.

Kieran Chandler: Um eine optimierte Entscheidung für deine supply chain zu treffen, kann es zu einem “Garbage in, garbage out”-Problem kommen, wenn du die Daten falsch interpretierst. Was du damit sagen willst, ist, dass es im Wesentlichen darum geht, die Semantik der Daten zu klären, oder?

Joannes Vermorel: Genau. Du musst verstehen, dass Daten mehr sind als nur Zahlen. Sie repräsentieren verschiedene Faktoren, die in einer Zelle kombiniert werden können. Es geht nicht nur darum, die Software, die die Daten erzeugt, zu verstehen, sondern auch, wie Menschen mit der Software interagieren. Deine Dokumentation muss den menschlichen Aspekt dessen berücksichtigen, was die Leute tun.

Kieran Chandler: Hast du ein gutes Beispiel dafür, wie einer deiner Kunden in der Vergangenheit mit diesem Problem konfrontiert wurde und wie es ihr Unternehmen beeinflusst hat?

Joannes Vermorel: Ja, ich kann ein Beispiel geben. Wir hatten einen Kunden, der einen hoch anspruchsvollen Betrieb führte, der ein hohes Maß an Verfügbarkeit erforderte. Sie haben Bestellungen mit sehr kurzen Vorlaufzeiten an ihre Lieferanten übermittelt. Ihr System verfügte über ein interessantes Designmerkmal: Wenn die gelieferte Warenmenge nicht mit der ursprünglich angeforderten Menge übereinstimmte, musste die gesamte Bestellung abgelehnt und an den Lieferanten zurückgesendet werden.

Angenommen, du bestellst 1.000 Einheiten, aber der Lieferant liefert 1.050 Einheiten, dann müsstest du sie ablehnen. Das Problem dabei ist, dass eine Ablehnung zu ernsthaften betrieblichen Problemen führen könnte. Das System erlaubte es ihnen nicht, die Menge anzupassen, sodass letztlich das passiert ist, dass sie die ursprüngliche Bestellung modifizierten, um die gelieferte Menge widerzuspiegeln.

Kieran Chandler: Also sagst du, dass sie die ursprüngliche Bestellung ändern würden, um der gelieferten Menge zu entsprechen?

Joannes Vermorel: Genau. Allerdings eröffnete dies ein weiteres Problem. Die Lieferanten bemerkten diese Praxis. Sie erkannten, dass sie mehr liefern konnten, als bestellt wurde, in dem Wissen, dass das Unternehmen diese Lieferungen benötigte. Sie würden keine absurden Mengen liefern, sondern etwas, das das Unternehmen als akzeptabel ansehen würde.

In den Daten würde es so erscheinen, als ob die ursprüngliche Bestellung für die größere Menge aufgegeben wurde. Das führte zu seltsamen Daten, bei denen die Bestellungen zu groß erschienen im Vergleich zu dem, was tatsächlich benötigt wurde, was den Eindruck erweckte, dass das Einkaufsteam schlecht darin sei, die richtigen Mengen zu wählen. Allerdings lag das Problem nicht beim Einkaufsteam, sondern bei den Einschränkungen des Systems und wie die Menschen mit diesen Einschränkungen umgingen.

All diese Details mussten dokumentiert werden, um zu vermeiden, dass falsche Schlüsse gezogen werden. Das Einkaufsteam war nicht schlecht in seinem Job. Das Problem war, dass sie ein System mit Einschränkungen hatten, mit dem sie geradezu navigieren mussten.

Kieran Chandler: Das System erzeugt all diese bizarren Nebeneffekte. Es benötigt eine Erklärungsseite, wenn man einen Sinn darin erkennen will, aber es gibt kein Entkommen. Es ist einfach die Komplexität des Geschäfts selbst, die sich in diesen Daten widerspiegelt. Lassen wir diese hinterhältigen Lieferanten beiseite. Das ist definitiv ein unterhaltsames Beispiel. Du hast also den Aspekt des Menschen erwähnt. Offensichtlich nutzen wir bei Lokad historische Daten, um probabilistische Prognosen für die Zukunft zu erstellen. Wen sonst kümmert es sich tatsächlich um die historischen Daten, außer uns?

Joannes Vermorel: Typischerweise zog alles, was wirklich den Geldbetrag betraf, den man erwarten musste zu erhalten oder zu zahlen, viel Aufmerksamkeit auf sich. Es ist nicht so, dass die Leute nicht aufmerksam waren, aber Unternehmen, die das Geld, das sie erhalten sollten, nicht genau überwachten, tendierten dazu, im Laufe der Zeit zu verschwinden. Das ist wie Darwinismus in Aktion. Wenn man dem nicht Beachtung schenkt, verschwindet man einfach. Deshalb wurde, wie vor fünf Jahrhunderten, die doppelte Buchführung von einigen italienischen Mönchen erfunden. Wenn man nicht aufpasst, bricht dein Kloster einfach aufgrund von schlechten Buchhaltungspraktiken zusammen. Es ist kein neues Problem, aber es gibt viele Daten, die wir in der Vergangenheit nicht als geschäftskritisch betrachteten und die jetzt geschäftskritisch werden.

Um dir ein Beispiel zu geben: Um in der Vergangenheit stock-outs ordnungsgemäß zu berücksichtigen, hast du das, was du eingekauft hast, in Betracht gezogen, damit du weißt, was du deinen Lieferanten zahlen solltest, und das, was du verkaufst, damit du weißt, was deine Kunden dir zahlen sollten. Aber wie steht es um das Nachverfolgen der historischen stock-outs? Solange du eine supply chain-Fachkraft hast, die die zu bestellenden Mengen manuell festlegt und sich daran erinnert, dass es bizarre Perioden mit stock-outs gab, brauchst du diese historischen Aufzeichnungen nicht zu führen. Sie sind Teil deines Systems.

Das Problem ist, dass sobald du zu etwas übergehen möchtest, das quantitativer ist – wie das, was wir bei Lokad mit automatisierten Entscheidungen für all diese alltäglichen Aufgaben tun, wie zum Beispiel zu entscheiden, wie viel bestellt werden soll – genaue Aufzeichnungen über die historischen stock levels viel wichtiger werden. Andernfalls wird deine Automatisierung die Interpretation dessen, was der Verkauf ist und was einem Nachfrageausfall entspricht, falsch verstehen.

Wenn du eine höhere Automatisierung in deinem Unternehmen haben möchtest, dann musst du auf ein breiteres Spektrum an Daten achten, nicht nur auf das reine Buchhaltungsding. Dein Buchhalter kümmert sich nicht um deine Tage mit stock-outs, aber deine supply chain-Optimierungssoftware schon. Du musst den Kreis der Daten erweitern, die wirklich zu deinem Aufgabenbereich gehören, die dokumentiert sind und für die du Qualitätskontrolle und -sicherung benötigst.

Kieran Chandler: Also, wir sind ziemlich auf diese einzelne Person angewiesen, die sich an die vergangenen Ereignisse erinnert. Sollten wir nicht besser auf die ankommenden Daten vorbereitet sein? Sollte nicht die IT-Abteilung oder jemand anderes diese Daten vorbereiten und dafür sorgen, dass sie von Anfang an sauber sind? Es scheint ein einfacherer Weg zu sein, die Dinge zu erledigen.

Joannes Vermorel: Ja, aber das Problem liegt nicht in der IT-Kompetenz. Es gibt so etwas wie saubere Daten nicht. Der Punkt ist, dass Daten nicht von Natur aus mit ausreichender Tiefe verstanden werden und nicht alle geschäftlichen Perspektiven angemessen abgedeckt sind.

Kieran Chandler: Es wird oft gesagt, dass Unternehmen Milliarden in AI investieren, aber die Realität ist, dass es die Komplexität des Geschäfts selbst ist, die in dieser Aufgabe, dieser Herausforderung der Datenaufbereitung, zum Vorschein kommt. Und zu sagen: “Oh, die IT-Abteilung sollte sich darum kümmern”, ist gleichbedeutend mit der Erwartung, dass die IT das Unternehmen führt und in jedem einzelnen geschäftlichen Bereich bewandert ist.

Joannes Vermorel: Absolut, das schafft plötzlich ein organisatorisches Problem, denn man erwartet, dass die IT ebenso ein Experte in den Bereichen Personalwesen, Marketing, Einkauf und so weiter ist. Ich meine, man erwartet von der IT-Abteilung vollständige Beherrschung aller geschäftlichen Aspekte. Aber das ist zu viel verlangt. Die IT-Abteilung muss sich bereits mit all den IT-Veränderungen auseinandersetzen, daher sollte von ihr nicht erwartet werden, jedes einzelne Geschäftsproblem im Unternehmen zu lösen. Alternativ könntest du die IT umdefinieren und sie als dein gesamtes Unternehmen betrachten, aber das würde den Zweck verfehlen.

Zurück zum eigentlichen Fall: Die Datenaufbereitung muss eine ziemlich verteilte Anstrengung innerhalb des Unternehmens sein, denn letztlich sind es nur die Leute, die das nötige Maß an Einsicht bieten können, um die relevanten Daten vorzubereiten – sagen wir mal für den Einkauf – nämlich die Einkaufsteams. In ähnlicher Weise, wenn du eine Lieferanten-Scorecard etablieren und die Daten mit ausreichender Genauigkeit vorbereitet haben möchtest, sodass sie wirklich Sinn ergeben, musst du mit deinen Teams sprechen, die für das Sourcing verantwortlich sind.

Jedes Mal, wenn du ein Problem angehst, musst du die Personen einbeziehen, die in diesem Problem Spezialisten in deinem Unternehmen sind, denn sie sind diejenigen, die dir die Einsicht liefern, die notwendig ist, um die Daten verständlich vorzubereiten. Es ist nicht ausschließlich ein IT-Problem. Es geht darum, all das erforderliche Verständnis zu sammeln, damit du bei der Datenverarbeitung nicht mit Daten landest, die im Hinblick auf das zu lösende Geschäftsproblem keinen Sinn ergeben.

Kieran Chandler: Also, nach dem, was es klingt, sind wir noch nicht ganz am Ziel. Einige Unternehmen sind dort, aber sie sind die Ausnahme, nicht die Regel. Wie kannst du sicher sein, wenn dir nicht alle Informationen vorliegen und du Lücken interpretierst, dass deine Interpretation die richtige ist? Es könnte viele Möglichkeiten geben.

Joannes Vermorel: Absolut, und das ist ein interessanter Punkt, denn es ist ähnlich wie bei wissenschaftlichen Theorien. Du weißt nie, dass deine Theorie richtig ist, du weißt nur, dass sie gut genug ist und, wenn sie in der Praxis herausgefordert wird, funktioniert sie. Du hast nichts Besseres, um sie noch besser funktionieren zu lassen.

Was bedeutet das also für die Datenaufbereitung? Es bedeutet, dass du weißt, dass deine Datenaufbereitung korrekt ist, wenn am Ende der Datenpipeline die Entscheidungen, die du basierend auf dieser Interpretation automatisch generierst, korrekt sind. Wenn deine Entscheidungen korrekt sind, bedeutet das, dass deine Optimierungslogik effizient ist, deine Maschinelles Lernen Schichten genau sind und vieles mehr. Grundsätzlich ist es einfach nicht möglich, zu korrekten Entscheidungen zu gelangen, die von einer falschen Interpretation erzeugt wurden. Normalerweise, wenn du deine Daten nicht korrekt interpretierst und aufbereitest, werden deine Ergebnisse so gravierend verfälscht, dass es keine Chance gibt, dass es funktioniert.

Unterm Strich gibt es keinen Trick, außer die Vorbereitung zu machen, sich sicher zu sein und dann die Entscheidungen zu generieren. Wenn die Entscheidungen unsinnig sind, gehst du zurück, verfolgst das Problem bis zu seiner Ursache – häufig ist es die Datenaufbereitung – und behebst es. Wenn am Ende des Tages die Entscheidungen, die aus deinem System hervorgehen, für einen Praktiker, der seinen eigenen menschlichen Verstand zur Bewertung nutzt, Sinn ergeben, dann weißt du, dass du es richtig gemacht hast.

Kieran Chandler: Man könnte sagen, ich glaube, dass sie richtig vorbereitet sind, aber normalerweise ist es alles eine Frage von Graustufen. Die supply chain-Fachkraft könnte sagen: “Es ist eine gute Entscheidung, aber sie könnte noch weiter verbessert werden. Zum Beispiel, wenn wir den Preis unserer Wettbewerber berücksichtigen würden, weil das ungewöhnliche Ausschläge oder Einbrüche in der Nachfrage erklärt – und wir diese Daten noch nicht haben.” Also, es ist keine Schwarz-Weiß-Situation.

Joannes Vermorel: Wir haben bereits ziemlich viel über die Schwierigkeiten der Datenaufbereitung und wie schlechte Datenaufbereitung aussieht, gesprochen. Aber um es zusammenzufassen: Wie sieht gute Datenaufbereitung aus? In einer moderat komplexen supply chain-Situation würde gute Datenaufbereitung wie ein gut strukturiertes Buch aussehen. Stellen wir uns das vor wie ein 400-seitiges Buch mit einer Seite pro Tabelle oder zwanzig Feldern in 20 Tabellen. Aber es reicht nicht, wenn es nur ein Buch ist; es muss ein gut geschriebenes Buch sein.

Wenn du etwas unglaublich Langweiliges schreibst, wird es niemand lesen und es wird keinerlei Auswirkung auf dein Unternehmen haben. Daher muss es gut geschrieben sein. Und mit gut geschrieben meine ich, es sollte lesbar sein. Es muss auch aus einer geschäftlichen Perspektive verfasst sein. Es ist keine IT-Dokumentation. Datenaufbereitung ist wirklich kein IT-Problem, sondern vielmehr eine Frage, alle geschäftlichen Einsichten zu haben.

Die gültige Perspektive im Geschäft ist immer etwas, das sich ändert. Wenn sich die Wettbewerbssituation in deiner Branche verändert, ändert sich auch die gültige Perspektive auf ein bestimmtes Problem. Daher muss dieses Buch gut geschrieben und gepflegt werden.

Dies ist eine sehr verteilte Anstrengung in deinem Unternehmen, denn zum Beispiel hat nur das Merchandising-Team die nötige Einsicht und Perspektive, um zu wissen, wie die Merchandising-Tabellen überhaupt dokumentiert werden sollten. Diese Datenaufbereitung sieht aus wie sauberes, gut geschriebenes Material, das in deinem Unternehmen weit verbreitet und zugänglich ist.

Das Interessante daran ist, dass sobald man all diese Erkenntnisse gewonnen hat, die Datenumwandlung, also Logik, zu einer klaren Interpretation des fundierten Verständnisses der Daten selbst wird. Man muss enormen Aufwand betreiben, um die Daten zu verstehen, zu dokumentieren, aufzuschreiben und zu pflegen. Aber sobald all das erledigt ist, wird das Schreiben der Logik unkompliziert. Wie sieht also gute Datenvorbereitung aus? Es ist wie ein gut geschriebenes Buch, ein geteiltes Verständnis, eine Art supply chain bible, die intern in Ihrem Unternehmen genutzt wird.

Kieran Chandler: Klingt gut! Also, Datengrautöne – wird das ein neuer Bestseller von der Organisation?

Joannes Vermorel: Vielleicht, wer weiß?

Kieran Chandler: Also, wir hoffen, dass Ihnen die heutige Episode über Datenvorbereitung gefallen hat. Wie immer, melden Sie sich, wenn Sie noch weitere Fragen haben, und wir sehen uns das nächste Mal wieder bei Lokad TV. Auf Wiedersehen für jetzt.