Schlechte Daten in supply chain

00:00:07 Schlechte Daten in supply chain-Projekten als Sündenbock einsetzen.
00:00:33 Warum schlechte Daten eine einfache Ausrede für das Scheitern von Projekten sind.
00:01:42 Herausforderungen mit schlechten Daten und Missverständnisse über ihre Qualität.
00:03:16 Schwierigkeiten beim Zugriff auf Daten aus ERP-Systemen und Herausforderungen mit Anbietern.
00:06:32 Probleme bei der Migration zwischen ERP-Systemen und Datenkorruption.
00:08:01 Fehlerhafte Dateneingaben beheben und ihre Auswirkungen auf ERP-Systeme.
00:09:48 Prognosen erstellen und Probleme in historischen Daten erkennen.
00:11:37 Wie sich ändernde Semantik und Definitionsänderungen zu Datenproblemen führen können.
00:12:20 Skalierungsprobleme und die Optimierung der Datenabfrage, wenn Unternehmen wachsen.
00:14:45 Herausforderungen bei der Erstellung sauberer täglicher Datenextraktionen und das Potenzial für Datenfehler.
00:16:02 Die Auswirkungen längerer Verarbeitungszeiten auf die Problemlösung in IT-Abteilungen.
00:17:15 Das Problem der Daten-Semantik und Missverständnisse bei der Dateninterpretation.
00:19:22 Die Bedeutung der Dokumentation jedes Datenfelds, um ein korrektes Verständnis sicherzustellen.
00:21:01 Die Rolle von Supply chain-Praktikern und der IT-Abteilung beim Verständnis der Datensemantik.
00:23:59 Die Bandbreite der Probleme im Zusammenhang mit schlechten Daten und die Identifizierung der zugrunde liegenden Ursachen.

Zusammenfassung

In diesem Interview diskutieren Kieran Chandler und Joannes Vermorel die Rolle von Daten in der supply chain optimization und die Herausforderungen, denen sich software vendors und Praktiker gegenübersehen. Vermorel hebt hervor, dass das Hauptproblem nicht die “schlechten Daten” sind, sondern vielmehr der Zugriff auf diese und deren effektive Nutzung. Herausforderungen umfassen veraltete Systeme, unzureichende Dokumentation und Verantwortlichkeiten beim Datenzugriff. Interessenkonflikte mit Integratoren, Probleme bei der Systemmigration, Prognosen und Skalierbarkeitsprobleme stellen ebenfalls Herausforderungen dar. Um das supply chain management zu optimieren, müssen Unternehmen die Datenprobleme verstehen und angehen, in eine ordnungsgemäße Dokumentation investieren, data semantics klären und realistische Erwartungen bewahren, anstatt die Daten für Misserfolge verantwortlich zu machen.

Erweiterte Zusammenfassung

In diesem Interview diskutieren Kieran Chandler und Joannes Vermorel, der Gründer von Lokad, die Rolle der Daten in supply chain optimization Projekten und die Herausforderungen, denen sich Softwareanbieter und Supply chain-Praktiker stellen. Sie beginnen damit, den Gedanken zu adressieren, dass “schlechte Daten” oft als Sündenbock für das Scheitern von supply chain Projekten herangezogen werden. Vermorel weist darauf hin, dass es bequem ist, die Schuld auf die Daten zu schieben, um nicht den Menschen die Schuld zu geben, die es persönlich nehmen und zurückschlagen könnten. Er betont jedoch auch, dass es entscheidend ist, die eigentliche Ursache des Problems zu verstehen.

Vermorel behauptet, dass datenbezogene Probleme wahrscheinlich die Hauptursache für das Scheitern von supply chain optimization Projekten sind, jedoch ist die Wahrnehmung von “schlechten Daten” oft fehlgeleitet. Er argumentiert, dass die meisten westlichen Unternehmen seit Jahrzehnten über präzise Daten verfügen, dank der Nutzung von Barcodes, Barcode-Scannern und anderer Technologien. Das eigentliche Problem, so Vermorel, ist nicht die Qualität der Daten an sich, sondern vielmehr die Herausforderungen beim Zugriff auf sie und ihrer Nutzung.

Eines der zentralen Probleme bei der effektiven Nutzung von Daten ist der Zugang zu ihnen. Viele Unternehmen nutzen seit Jahren verschiedene enterprise resource planning (ERP)-Systeme, warehouse Management-Systeme (WMS), Transportation Management Systems (TMS) und andere Softwarelösungen, aber diese Systeme können beim Export von Daten schwierig zu handhaben sein. Vermorel nennt einige Szenarien, in denen der Zugang zu Daten besonders problematisch sein kann:

1. Alte Systeme: Einige Unternehmen nutzen immer noch Systeme, die 40 Jahre alt sind, mit veralteten und proprietären Backends, die die Extraktion von Daten extrem erschweren.
2. Fehlende Dokumentation: Softwareanbieter stellen möglicherweise keine ausreichende Dokumentation für ihre Systeme bereit, wodurch es schwierig wird, die zahlreichen Tabellen und Felder in Datenbanken zu verstehen und zu navigieren.
3. Verantwortung und Zugang: Es kann eine Herausforderung sein, zu bestimmen, wer für die Gewährung des Zugangs zu Daten verantwortlich ist, da dabei mehrere Stakeholder innerhalb eines Unternehmens involviert sind, einschließlich des Softwareanbieters, der IT-Abteilung und Supply chain-Praktikern.

Das Interview unterstreicht die Bedeutung, datenbezogene Herausforderungen in supply chain optimization Projekten zu verstehen und anzugehen. Während die Datenqualität an sich normalerweise nicht das Problem ist, können Schwierigkeiten beim Zugriff und der Nutzung zu einem Scheitern dieser Projekte beitragen. Die Identifizierung und Behebung der zugrunde liegenden Ursachen dieser Herausforderungen ist entscheidend, um den Erfolg von supply chain optimization Initiativen zu gewährleisten.

Sie gehen auf Datenprobleme ein, die aus Beziehungen zu Anbietern, Systemintegrationen und Skalierbarkeitsproblemen entstehen können, wenn Unternehmen wachsen.

Eines der zentralen Themen, das sie ansprechen, ist das Potenzial für Interessenkonflikte mit Integratoren, die möglicherweise mehr daran interessiert sind, ihre eigenen supply chain optimization Lösungen zu verkaufen, als mit dem vom Unternehmen gewählten Anbieter zusammenzuarbeiten. Dies kann dazu führen, dass Unternehmen von ihren Integratoren als Geiseln gehalten werden, was den Zugriff auf ihre Daten oder deren effektive Nutzung erschwert.

Eine weitere Herausforderung tritt bei der Migration von einem Enterprise Resource Planning (ERP)-System zu einem anderen auf, was zu schlechter Datenqualität oder einer “Garbage-Integration” führen kann. Während einzelne Datensätze korrekt sein können, kann der Prozess der Migration historischer Daten zwischen Systemen Fehler einführen, da es oft keine direkte Eins-zu-eins-Zuordnung zwischen den Daten im alten und im neuen System gibt. Dies kann zu Datenkorruption führen, die zwar keinen bedeutenden Einfluss auf den täglichen Betrieb hat, jedoch bei Versuchen der supply chain optimization oder Datenanalyseprojekten wieder zum Problem werden kann.

Das Interview spricht auch Prognosen auf Basis historischer Daten an, die aufgrund der inhärenten Unsicherheit der Zukunft schwierig sein können. Probleme in historischen Daten zu erkennen, ist einfacher, wenn diese sichtbar sind, wie beispielsweise Lücken oder plötzliche Veränderungen in den Daten. Allerdings können subtile Veränderungen in der Semantik oder den Definitionen im Laufe der Zeit zu schwerer erkennbaren Problemen führen, insbesondere bei der Migration zwischen Systemen.

Mit dem Wachstum von Unternehmen können auch Skalierbarkeitsprobleme zu Datenproblemen führen. Bei kleineren Unternehmen passt der gesamte historische Datensatz oft auf ein Smartphone, sodass die Optimierung weniger im Vordergrund steht. Doch mit zunehmender Unternehmensgröße kann die schiere Menge an Daten zu einem Problem werden. Die Diskussion betont die Bedeutung, diese Datenprobleme zu verstehen und anzugehen, um das supply chain management effektiv zu optimieren.

Vermorel erklärt, dass Unternehmen oft Schwierigkeiten haben, Daten aus ihren Enterprise Resource Planning (ERP)-Systemen zu extrahieren, da diese Systeme nicht darauf ausgelegt sind, saubere tägliche Dateninkremente bereitzustellen. Dies führt zu komplexen Prozessen, die zu fehlerhaften Datenextraktionen und der Einführung von Bugs führen können. Das Debuggen und Beheben dieser Probleme kann aufgrund der großen Datenmengen und der langsamen Verarbeitungszeiten zeitaufwendig werden und Wochen statt Stunden in Anspruch nehmen.

Viele Unternehmen glauben, dass sie über gute Daten verfügen, doch in Wirklichkeit ist die Semantik der Daten oft unklar. Dies kann zu Missverständnissen und irreführenden Berechnungen führen. Beispielsweise kann ein “Bestelldatum” mehrere Interpretationen haben, wie etwa den Zeitpunkt, zu dem die Bestellung vom Kunden aufgegeben wurde, den Zeitpunkt, zu dem sie im System erfasst wurde, oder den Zeitpunkt, an dem die Zahlung bestätigt wurde. Um Fehlinterpretationen zu vermeiden, schlägt Vermorel vor, dass Unternehmen eine detaillierte Dokumentation für jedes Feld und jede Tabelle in ihren Datensystemen führen sollten, um die Komplexität ihres supply chain widerzuspiegeln.

Ein häufiges Problem in der supply chain optimization besteht darin, dass Praktiker möglicherweise nicht genügend Zeit darauf verwenden, ihre Daten zu qualifizieren, was dazu führt, dass Anbieter mit unvollständigen oder unklaren Informationen arbeiten. Dies kann zu einer “Garbage-In-Garbage-Out”-Situation führen, bei der die Daten nicht unbedingt falsch sind, aber aufgrund mangelhafter Dokumentation missverstanden werden.

Um diese Probleme anzugehen, betont Vermorel die Wichtigkeit, die zugrunde liegende Ursache des Problems zu identifizieren, die meist mit Menschen und organisatorischen Strukturen zusammenhängt. Unternehmen sollten verstehen, wer die Verantwortung für das Scheitern trägt, und daran arbeiten, die grundlegenden Probleme zu beheben, anstatt einfach die Daten zu beschuldigen. Anbieter sollten auch ehrlich über die Herausforderungen und den Zeitaufwand sein, der erforderlich ist, um die Datensemantik zu klären, anstatt übermäßig optimistisch zu sein, nur um Verträge abzuschließen.

Unternehmen müssen in eine ordnungsgemäße Dokumentation, klare Datensemantik und realistische Erwartungen investieren, um ihr supply chain zu optimieren und Misserfolge aufgrund von Datenproblemen zu verhindern.

Vollständiges Transkript

Kieran Chandler: Heute bei Lokad TV werden wir verstehen, warum dies eine so ungenaue Diagnose darstellt und auch, welche Datenherausforderungen sowohl von Softwareanbietern als auch von Supply chain-Praktikern begegnet werden können. Also Joannes, warum ist es so einfach, schlechte Daten als Ausrede zu benutzen?

Joannes Vermorel: Erstens, weil Daten sich nicht beschweren können. Niemand wird sie verteidigen, daher schiebt man einem Inerten die Schuld zu, was besser ist, als einem Kollegen die Schuld zu geben, der es persönlich nehmen und zurückschlagen würde. Aber die Realität ist, dass, wenn man zur Ursache geht, immer Menschen für das Problem verantwortlich sind. Die Schuld auf die Daten zu schieben, überspringt gewissermaßen den Schritt, die eigentliche Ursache des Problems zu identifizieren.

Kieran Chandler: Es ist definitiv einfach, sich über etwas zu ärgern, das nicht zurückschlägt. Wie können wir also präziser vorgehen? Was sind einige der Herausforderungen?

Joannes Vermorel: Datenbezogene Probleme sind wahrscheinlich die Hauptursache für das Scheitern von supply chain optimization Projekten. Aber es gibt einige Missverständnisse. Wenn von “schlechten Daten” gesprochen wird, sind damit korrupte oder fehlerhafte Zahlen gemeint. Allerdings verfügen die meisten westlichen Unternehmen seit Jahrzehnten über sehr präzise Daten. Fast niemand gibt falsche Teilenummern ein oder macht Tippfehler. Sie verwenden Barcodes, Barcode-Scanner und andere Tricks wie RFID. Daher ist der Anteil wirklich schlechter Daten in der Regel sehr gering und reicht nicht aus, um zu erklären, warum die meisten Initiativen, die an datenbezogenen Problemen scheitern, tatsächlich scheitern.

Kieran Chandler: Wenn die überwiegende Mehrheit der westlichen Unternehmen ziemlich gute Daten sammelt, welche Herausforderungen können auftreten, die uns glauben lassen, dass die Daten nicht so gut sind?

Joannes Vermorel: Das erste Problem ist der Zugang zu den Daten. Man wäre überrascht. Unternehmen betreiben seit Jahrzehnten ihre Geschäfte mit verschiedenen Varianten von ERPs, WMS, TMS oder anderer Unternehmenssoftware. Aber die meisten dieser Systeme sind nicht besonders benutzerfreundlich, wenn es um den Export von Daten geht. In manchen Fällen gibt es Systeme, die so veraltet sind, dass sie nicht einmal über eine ordnungsgemäße relationale SQL-Datenbank verfügen, die das System unterstützt. In einer solchen Situation ist es wirklich schwierig, die Daten zu extrahieren, weil das Backend typischerweise völlig veraltet und proprietär ist.

Kieran Chandler: Also, wer ist dafür zuständig?

Joannes Vermorel: Hier gibt es mehrere Verantwortlichkeiten. Zunächst kann es den Softwareanbieter geben, der keine aussagekräftige Dokumentation über das System bereitgestellt hat. Im schlimmsten Fall öffnet man die Datenbank und stellt fest, dass das ERP 2.000 Tabellen enthält, jede mit 20 bis 200 Feldern, und das ist ein Albtraum. Es ist schier riesig, und man weiß nicht, wo man anfangen soll. Selbst wenn es ein Problem damit gibt, nach den richtigen Informationen zu suchen, kann es auch ein Problem mit dem Integrator geben. Das Problem beim Integrator besteht darin, dass ein Interessenkonflikt vorliegen könnte. Einige Integratoren könnten ein starkes Interesse daran haben, Ihnen ihre eigene Rezeptur zur supply chain optimization zu verkaufen, sei es für dieses oder jenes Modul oder Ähnliches. Und wenn man sie bittet, im Grunde eine Datenextraktion für einen durchzuführen, sei es für Ihre internen Teams oder für eine Initiative, die Sie mit einem anderen Anbieter umsetzen möchten, kann es – es passiert, wir haben es schon oft gesehen – vorkommen, dass sie schlicht unkooperativ sind. Denn für sie liegt es strategisch genau darin, nicht konkurrenzfähig zu sein. Und hier hat man eine Art Geiselsituation, in der das Unternehmen faktisch von dem Integrator in Geiselhaft genommen wird. Das Unternehmen, die IT-Firma, die für die Konfiguration, manchmal auch das Hosting und insgesamt für die Wartung des ERP oder des anderen Computersystems des Unternehmens verantwortlich ist. Das ist also eine weitere Art von Datenproblem. Aber sehen Sie, es hat sehr wenig mit den Daten zu tun.

Kieran Chandler: Ja, definitiv. Der fehlende Zugang zu Ihren Daten klingt nach einem ziemlich großen Hindernis. Und wie sieht es mit den anderen Herausforderungen aus, die auftreten können? Ein großes Problem, das viele unserer Kunden haben, ist die Migration von einem ERP-System zu einem anderen ERP-System. Was kann das also mit den Daten machen?

Joannes Vermorel: Es kann nicht einfach abgeschlossen werden, ohne Probleme zu verursachen. Das ist die Art von Situation, in der man eine weitere Art von schlechten Daten haben kann. Aber hier besteht das Problem tatsächlich darin, dass die Daten schlecht sind, wenn man eine mangelhafte Integration hat. Ich sage, normalerweise sind die Dateneinträge korrekt, aber wenn man von einem ERP-System zu einem anderen wechselt – sei es durch den Anbieter, den Integrator oder vielleicht durch die interne IT-Abteilung –, dann versuchen sie im Grunde, die historischen Daten vom alten System ins neue System zu migrieren. Das Problem ist, dass es keine Eins-zu-eins-Zuordnung gibt zwischen dem, was im alten System als Verkauf erfasst wurde, und dem, was im neuen System als Verkauf gilt. Vielleicht sind die Dinge einfach anders organisiert, sodass es keinen klaren Weg gibt, AR vom alten System ins neue System zu übertragen. Und dann landet man möglicherweise bei vorläufigen Integrationen, die zu Datenkorruption führen können, denn wenn man, so würde ich sagen, eine unsachgemäße Re-Integration der Historie vornimmt, verhindert das nicht, dass das Unternehmen tagtäglich weiterarbeitet. Siehst du, wenn die East Oracle falsch in das neue System importiert wird, hat das für die meisten täglichen Vorgänge keine Auswirkungen. Und selbst wenn es Auswirkungen hat, wird normalerweise jemand schnell einen Fix für das Falsche vornehmen und weitermachen. Es mag eine Quelle dauerhafter Reibungen sein, aber erstens verschwindet es recht schnell, denn wenn beispielsweise Lieferantencodes falsch importiert werden – man hat ja nicht etwa eine Million Lieferanten – dann werden die 100 häufigsten Lieferanten aller Wahrscheinlichkeit nach innerhalb von zwei Wochen ab dem Datum, an dem das neue System in Betrieb genommen wird, korrigiert. Und vielleicht, sagen wir, drei Monate später ist nahezu jeder fehlerhafte Lieferanteneintrag berichtigt. Aber das Problem sind die historischen Codes; die Leute werden nicht zurückgehen und die historischen Daten korrigieren. Nehmen wir an, du hättest etwa fünf Jahre Historie, vielleicht drei

Kieran Chandler: Wie leicht lässt sich in Zukunft erkennen, dass solche Probleme in der Vergangenheit aufgetreten sein könnten?

Joannes Vermorel: Diese Probleme lassen sich leicht erkennen, wenn offensichtliche Mängel vorliegen, wie beispielsweise fehlende Daten über einige Monate. Allerdings kann es auch subtile Veränderungen geben, die schwerer zu bemerken sind – etwa Unterschiede darin, wie Verkäufe gezählt werden oder ob Betrug beziehungsweise Rücksendungen einbezogen werden. Das kann zu vielen Problemen in den historischen Daten führen, da sich die eigentliche Definition der betrachteten Daten im Laufe der Zeit ändert und es nicht offensichtlich ist, solange es keinen deutlichen Ausschlag oder Anstieg gibt.

Kieran Chandler: Ein weiteres Problem, das bei den Kunden, mit denen wir sprechen, häufig auftritt, ist die Skalierbarkeit. Wenn ein Unternehmen wächst, werden die Daten immer unübersichtlicher. Welche Probleme kann die Skalierbarkeit mit sich bringen?

Joannes Vermorel: Wenn keine Skalierbarkeitsprobleme bestehen, kann man täglich alle Daten des Unternehmens einfach kopieren. Für kleinere Unternehmen mag das machbar sein, da ihre gesamte Historie weniger als 10 Gigabyte betragen könnte. Aber bei größeren Unternehmen hat man wesentlich mehr Daten, und man muss auf inkrementelle Datenerfassung setzen. Das bedeutet, dass man jeden Tag einen Teil der Daten extrahiert, und manche Systeme sind nicht darauf ausgelegt, dies effizient oder präzise zu bewerkstelligen. Daher muss man komplizierte Maßnahmen ergreifen, um eine saubere tägliche Extraktion zu gewährleisten, wodurch man sich potenziellen Problemen aussetzt.

Kieran Chandler: Am Ende landet man also mit schlechten Daten, nur weil man die Datenerfassung inkrementell durchführen möchte – was insofern problematisch ist, als dass das System möglicherweise nicht für diese Aufgabe konzipiert wurde. Wenn man an Debugging denkt, möchte man schließlich einfach Daten von einem Ort zum anderen kopieren, und das ist ein sehr alltägliches Problem. Dauert der Prozess eine Minute, kann jemand in der IT-Abteilung in fünf Minuten den Vorgang anstoßen und sicher sein, dass er funktioniert. Dauert er jedoch sechs Stunden, wird der Vorgang zu einem sehr mühsamen Prozess. Kannst du die Herausforderungen in dieser Situation erläutern?

Joannes Vermorel: Sicher. Stell dir vor, du hast ein System, bei dem der Prozess sechs Stunden dauert. In deiner IT-Abteilung wird jemand den Prozess starten, nach zehn Minuten merken, dass es zu lange dauert, und dann etwas anderes tun – vielleicht sogar den Vorgang vergessen. Am nächsten Tag bemerkt man einen kleinen Fehler, der nach sechs Stunden zu einem Absturz geführt hat. Um das Problem erneut zu reproduzieren, verzögert sich alles nochmal um sechs Stunden. Infolgedessen entstehen Probleme, die eigentlich in nur wenigen Stunden behoben werden könnten, sich aber aufgrund der Komplexität und längeren Verarbeitungszeiten zu einem sehr mühsamen Prozess auswachsen, bei dem sich die Gesamtverzögerung auf Wochen beläuft. Nicht weil es Wochen an Arbeit bedeutet, sondern weil die Leute den Prozess anstoßen, ihn vergessen und erst am nächsten Tag wieder darauf zurückkommen. Das führt zu sehr langsamen Iterationen.

Kieran Chandler: Wie weit verbreitet würdest du sagen, sind diese Probleme? Gibt es viele Unternehmen, die glauben, sie hätten sehr gute Daten, die in Wirklichkeit aber, bei näherer Betrachtung, nicht so gut sind?

Joannes Vermorel: Ja, es gibt noch ein weiteres Problem, das wir noch nicht angesprochen haben, und das ist die Semantik selbst. Viele Unternehmen glauben, sie hätten gute Daten, doch in Wirklichkeit besitzen die Daten eine unbekannte Semantik. Damit meine ich beispielsweise, dass es bei einem Bestelldatum viele mögliche Interpretationen gibt. Es könnte das Bestelldatum des Kunden sein, der Zeitpunkt, zu dem die Bestellung auf der Website aufgegeben wurde, der Zeitpunkt der Registrierung im System oder sogar der Moment, in dem die Zahlung als gültig bestätigt wurde. Es könnte 20 verschiedene Interpretationen dessen geben, was dieses Bestelldatum bedeutet.

Wenn wir mit Kunden zu arbeiten beginnen, stoßen wir typischerweise auf Tabellen und Spalten mit wenig Dokumentation. Aber wenn wir die Datenaufbereitung abgeschlossen haben, verfügen wir über nahezu eine Seite Dokumentation pro Feld und Tabelle. Eine typische supply chain Situation umfasst etwa 20 Tabellen mit 20 Feldern – also sprechen wir von 400 Seiten an Dokumentation, nur um zu klären, was die Daten bedeuten. Die Leute sind in der Regel sehr überrascht, aber es ist notwendig, die Daten richtig zu verstehen.

Kieran Chandler: Joannes, kannst du etwas über die Bedeutung einer genauen Dateninterpretation in der supply chain optimization sagen?

Joannes Vermorel: Ja, allein die Komplexität eurer supply chain, die sich in diesen Daten widerspiegelt, zeigt, dass wenn man diese Arbeit nicht leistet, man mit Daten endet, die man nicht richtig versteht – und es gilt dann “Garbage in, Garbage out”. Es ist nicht so, dass die Daten an sich fehlerhaft sind, im Sinne von falschen Zahlen, sondern man weiß einfach nicht, was diese Daten bedeuten. Wenn du also ein Datum hast, das du nicht korrekt interpretieren kannst, führt jede Berechnung oder Modernisierung zwangsläufig zu irreführenden Ergebnissen. Deshalb sind die Semantiken der Daten der entscheidende Faktor, und die Dokumentation muss vorhanden sein, bevor ein Projekt überhaupt gestartet werden kann.

Kieran Chandler: Also, wer trägt die Schuld, wenn es um Semantik geht?

Joannes Vermorel: Ich würde sagen, dass die supply chain practitioners das Ruder übernehmen sollten. Die meisten würden behaupten, es sei ein IT-Problem. Aber wie man die Semantik der Daten sieht, hängt wirklich von dem Prozess ab, den man hat. Wenn du beispielsweise Produkte am Eingang des Lagers scannst, weil ein entsprechender Prozess existiert, und dabei die IT-Abteilung – die nicht vor Ort im Lager ist und daher nicht genau weiß, wie dein Prozess abläuft – involviert ist, dann wissen es nur diejenigen, die direkt im System arbeiten, denn diese Daten sind lediglich das Ergebnis eines Prozesses. Mein Punkt ist also: Erwarte nicht, dass die IT, die nur die Maschinen verwaltet und dafür sorgt, dass die Software über genügend Rechenleistung, Speicherbandbreite und Festplattenkapazität verfügt, auch das nötige Verständnis, die Einsichten und die Kompetenz hat, um zu wissen, was die Daten bedeuten. Was die Daten bedeuten, ist typischerweise ein sehr unternehmensspezifisches Problem und überhaupt kein IT-Problem. Daher liegt die Schuld oft auch bei den Praktikern, die nicht genug Zeit investiert haben, um die Daten in ihren eigenen Worten und ihrem Verständnis korrekt zu qualifizieren. So endet man bei dieser supply chain optimization mit einem Anbieter, der diese Daten halb blind behandelt – und das führt zu “Garbage in, Garbage out”.

Kieran Chandler: Kann also auch der Anbieter Schuld haben?

Joannes Vermorel: Ja, offensichtlich kann auch der Anbieter Schuld haben. Unternehmen wie Coke Ad, die supply chain optimization betreiben, und typischerweise, wenn der Anbieter verantwortlich gemacht wird, liegt das daran, dass dieser versucht, elegant aufzutreten. Meistens versuchen sie, ihre Herausforderungen zu minimieren, weil sie ein Problem verkaufen wollen. Sie sagen dann etwas in der Art: “Vertraue uns. Das wird ein Kinderspiel. Wir erledigen das in wenigen Wochen. Boom, so machen wir es, und es wird funktionieren.” Die Realität ist jedoch, dass wenn man einem supply chain director sagt: “Ich befürchte, dass es allein zur Qualifizierung eurer Daten sechs Monate dauern wird – und tut mir leid, ihr hättet es selbst machen sollen, aber ihr habt es nicht getan, also müssen wir es für euch übernehmen” – dann fällt es schwer, einen solchen Deal abzuschließen. Es ist also viel einfacher, übermäßig optimistisch zu sein, aber das ist ein Rezept für Misserfolg. Dann muss der Anbieter die Schuld auf sich nehmen, weil er es besser wissen sollte. Vielleicht weiß der Kunde es nicht besser, weil es das erste Mal ist, dass er ein predictive die Quantitative Supply Chain optimization project durchführt. Aber der Anbieter, der definitionsgemäß wahrscheinlich nicht zum ersten Mal so etwas macht, sollte es besser wissen. Daher, wenn die Diagnose zeigt, dass diese Art von Daten gar nicht vorhanden ist, dann sollten sie

Kieran Chandler: Dann sollten sie dem Kunden im Grunde mitteilen, dass es möglicherweise mehrere Monate an Aufwand erfordert, nur um die Semantik der Daten zu klären, damit die Daten als gut qualifiziert werden können. Aber es war nicht so, dass sie von Anfang an wirklich schlecht waren. Gut ist in dieser Situation also nicht das Gegenteil von schlecht; vielmehr ist gut eher das Gegenteil von Dark Data, unqualifizierten Daten oder chaotischen Daten.

Joannes Vermorel: Also, um heute abzuschließen, gibt es eine breite Palette von Problemen, die tatsächlich unter den Begriff schlechter Daten fallen. Ich würde sagen: Versuche unbedingt, die eigentliche Ursache des Problems zu identifizieren – und meistens sind es die Menschen. Natürlich will man nicht James aus der IT-Abteilung dafür verantwortlich machen, dass es chaotisch zugeht. Aber wenn ich sage, dass das Problem in den Menschen liegt, muss man genau verstehen, wer die Verantwortung für das Scheitern trägt, und vielleicht wurde diese Person tatsächlich in eine Situation gebracht, in der sie nichts anderes tun konnte, als zu scheitern.

Man kann also zu dem Schluss kommen, dass James aus der IT-Abteilung versagt hat, aber auch, dass die Organisation diesen armen James in eine Lage gebracht hat, in der er realistisch betrachtet keine andere Wahl hatte, als zu scheitern. Es ist also interessant, dass man das Problem aus einem Blickwinkel betrachtet, der wenigstens Hinweise darauf gibt, wie man es beheben kann, anstatt einfach zu sagen, die Daten seien schlecht – schlicht schlecht. Und wenn man dann eine weitere Initiative startet, wiederholt man exakt dasselbe Problem, dieselben Fehler, und endet am Ende des Tages mit demselben Scheitern.

Kieran Chandler: Okay, falls James’ Chef zuschaut, hoffe ich, dass er mitfühlend ist. Wie dem auch sei, das war alles für diese Woche. Vielen Dank fürs Einschalten, und bis zum nächsten Mal. Tschüss!