Die Datenextraktions-Pipeline

Dieser Leitfaden hilft IT-Abteilungen, eine Pipeline aufzubauen, die Daten aus bestehenden Geschäftssystemen extrahiert und auf der Lokad-Plattform bereitstellt. Das ist eine der ersten Phasen einer Initiative für Quantitative Supply Chain. Beschrieben wird der von Lokad empfohlene Ansatz: Umfang und Format der bereitzustellenden Daten sowie Strategien für ihre Übertragung.

Motivation und Kontext

Eine Initiative für Quantitative Supply Chain liefert nach Lokads Definition ein numerisches Rezept, das Entscheidungen oder zumindest Empfehlungen für Supply-Chain-Aufgaben automatisiert. Lokads programmierbare Plattform wurde für die prädiktive Optimierung solcher Aufgaben entwickelt.

Typische Probleme umfassen:

• Entscheiden, welche Mengen nachbestellt werden sollen
• Entscheiden, welche Mengen produziert werden sollen
• Entscheiden, ob Preise erhöht oder gesenkt werden sollen
• Entscheiden, ob Bestände innerhalb des Netzwerks verschoben werden sollen

Optimiert das Unternehmen diese Entscheidungen, kann es in der Regel Betriebskosten und Kapitalbedarf senken und die Servicequalität erhöhen. Zumindest sollte es die Abwägung zwischen Kosten, Liquidität und Service besser auf seine übergeordnete Supply-Chain-Strategie abstimmen können.

Das numerische Rezept, das das jeweilige Problem adressiert, soll innerhalb von Lokad implementiert werden. Folglich erfordert das numerische Rezept, dass relevante Unternehmensdaten innerhalb von Lokads Plattform verfügbar gemacht werden. Dies führt zu folgenden Fragen:

• Welche Daten sollten an Lokad übertragen werden?
• Welches Format sollte für die Daten verwendet werden?
• Welche Übertragungsmuster sollten verwendet werden, um die Daten zu aktualisieren?

Obwohl die oben aufgeführten Probleme vielfältig sind, sind die relevanten Eingangsdaten sehr ähnlich und werden gewöhnlich über die zentralen transaktionalen historischen Daten des Unternehmens bereitgestellt (zum Beispiel historische Verkaufsdaten).

Die IT-Abteilung des Kunden ist normalerweise für den Aufbau und die Wartung der Datenextraktions-Pipeline verantwortlich. In den folgenden Abschnitten wird im Detail erklärt, was konkret von der IT-Abteilung verlangt wird.

Nach dem Aufbau der Datenextraktions-Pipeline übernehmen die auf der Lokad-Seite tätigen Ingenieure, die Supply Chain Scientists, die Entwicklung und Pflege des numerischen Rezepts. Häufig stellt Lokad diese Experten im Rahmen eines „Platform+Experts“-Vertrags. Der Kunde kann die Kompetenz auch intern aufbauen. In diesem Fall empfehlen wir, die Experten der Supply-Chain-Abteilung und nicht der IT zuzuordnen.

Die Empfehlungen dieses Dokuments gelten unabhängig davon, ob dieser Teil der Supply-Chain-Initiative ausgelagert wird.

Technischer Überblick

Lokad ist eine analytische Schicht, die über den bestehenden transaktionalen Systemen des Kunden operiert. Mit anderen Worten, Lokad ersetzt das ERP nicht; es ergänzt es um prädiktive Optimierungsfähigkeiten, die realistisch gesehen nicht als Teil eines traditionellen transaktionalen Systems implementiert werden können.

Jeder Lokad-Account verfügt über ein Dateisystem, das über die SFTP- und FTPS-Protokolle zugänglich ist. Eine Web-Oberfläche steht ebenfalls zur Verfügung, obwohl diese Oberfläche in der Regel nicht für unsere IT-Zielgruppe gedacht ist (sondern für die Bereitstellung von Dashboards für nicht-spezialisierte Benutzer). Wir erwarten, dass die relevanten Daten, die typischerweise aus den zentralen transaktionalen Systemen des Unternehmens extrahiert werden, als Flachdateien exportiert (siehe unten) und in Lokads Dateisystem hochgeladen werden.

Sofern nicht anders vereinbart, ist die IT-Abteilung des Kunden für alles, was die Daten betrifft, verantwortlich – bis zu dem Punkt, an dem die Flachdateien in Lokads Dateisystem hochgeladen werden. Das Design von Lokads Plattform ist so ausgelegt, dass es Teilausfälle bei der Datenextraktion verarbeiten kann (siehe unten), weshalb die IT-Abteilung in dieser Hinsicht einen gewissen Spielraum hat.

Sobald die Daten vorliegen, verarbeiten Envision-Skripte sie und berechnen die gewünschten optimierten Supply-Chain-Entscheidungen. Envision ist die von Lokad entwickelte domänenspezifische Programmiersprache.

Die Datenextraktion bietet viele Einsatzmöglichkeiten über Lokads Supply-Chain-Optimierung hinaus. Beispielsweise können Marketing, Finanzen und Vertrieb dieselben historischen Verkaufsdaten nutzen. Lokad empfiehlt deshalb, Transaktionsdaten in einer eigenen Bereitstellungsschicht, einem „Data Lake“, zusammenzuführen. Diese Schicht dient ausschließlich dazu, die Daten den zuständigen Teams und externen Analysesystemen wie Lokad zur Verfügung zu stellen.

Ein Data Lake ist keine Voraussetzung für Lokad, sondern eine mögliche Architektur, die den Betrieb erleichtert. Er fördert außerdem einen systematischen Umgang mit Daten im Unternehmen, sofern dieser noch nicht etabliert ist.

Der Umfang relevanter Daten

In der Supply Chain werden Entscheidungen über den Fluss physischer Güter optimiert, etwa Einkauf, Transport, Produktion und Verkauf. Für eine prädiktive Optimierung sind daher fast immer jene Daten am wichtigsten, die diese Güterflüsse im Unternehmen beschreiben. Sie liegen üblicherweise in den transaktionalen Geschäftssystemen.

Wie bereits erwähnt, ist Lokads Plattform in ihren Verarbeitungskapazitäten sehr flexibel, weshalb es keine strikten Anforderungen in Bezug auf Daten gibt. Sehr wahrscheinlich wird der Kunde nicht in der Lage sein, viele der unten aufgeführten Datenpunkte bereitzustellen, und Lokad kann innerhalb dieser Einschränkungen arbeiten. Die unten stehende Liste versucht daher, so umfassend wie möglich die hilfreichen Datenquellen zu identifizieren, ohne die strikte Bereitstellung jedes einzelnen zu verlangen.

Produktkatalog: Die Liste der Produkte, Artikel oder Teile, die das Unternehmen einkauft, verarbeitet, montiert oder verkauft. Viele Entscheidungen fallen auf Produktebene. Eine vorhandene Hierarchie, etwa Kategorien, Familien und Unterfamilien, ist für Berichte und Analysen relevant. Strukturierte Eigenschaften wie Farbe, Größe, Gewicht oder Form sind ebenfalls nützlich. Als Faustregel gilt: Alle Daten, die Produkte aus Supply-Chain-Sicht beschreiben, sind relevant. Das gilt auch für Beziehungen zwischen Produkten, etwa Stücklisten (BOMs).

Verkaufsauftragshistorie: Die Liste der bisherigen Verkaufsaufträge des Kunden. Verkäufe sind fast immer der beste verfügbare Anhaltspunkt für die Marktnachfrage. Die Daten sollten die Geldbeträge der Transaktionen enthalten, denn Supply-Chain-Optimierung braucht eine finanzielle Perspektive. Darauf gehen wir später näher ein. Wenn möglich, sind die ursprünglichen Auftragstransaktionen stets Tages-, Wochen- oder Monatsaggregaten vorzuziehen; auch das wird unten erläutert. Rückständige, stornierte, verschobene oder geänderte Aufträge und Rücksendungen können relevant sein. Werden Kunden in diesen Daten identifiziert, sind anonymisierte Kundenkennungen nützlich. Personenbezogene Daten behandeln wir in einem eigenen Abschnitt.

Einkaufsaufträge: Die Liste der historischen Einkaufsaufträge des Kunden sowie der ausstehenden Einkaufsaufträge (noch nicht erhalten). Diese Liste ist relevant, da Einkaufsaufträge fast immer der beste Anhaltspunkt zur Abschätzung von Lieferzeiten der Zulieferer und deren Servicequalität sind. Ausstehende Einkaufsaufträge spiegeln den “Bestand auf Bestellung” wider. Die Einkaufsaufträge sollten auch die mit den Transaktionen verbundenen Geldbeträge enthalten. Wo möglich, ist es (immer) vorzuziehen, die Rohdaten der Aufträge anstelle von Aggregaten bereitzustellen. Die Einkaufshistorie sollte, sofern verfügbar, die relevanten Daten enthalten: Bestelldatum, Versanddatum, Lieferdatum usw.

Produktionsaufträge: Die Liste bisheriger und noch auszuführender Produktionsaufträge, sofern zutreffend. Sie beschreibt die Verarbeitung der Güter im Unternehmen und hilft, Engpässe in der Supply Chain zu erkennen. Schwankende Produktionsausbeuten oder Chargen, die wegen Qualitätsproblemen ausgesondert werden, sind ebenfalls relevant.

Bestandsbewegungen: Die Liste bisheriger Bestandsbewegungen, sofern mehrere Standorte bestehen. Sie zeigt, woher der Bestand stammt, der für Produktionsvorgänge oder Kundenlieferungen verwendet wird. Sind die Transportzeiten variabel, sind auch die genauen Termine wichtig: Datum des Umlagerungsauftrags, Versanddatum und Eingangsdatum.

Bestandsmengen: Die Liste aller SKUs (Stock Keeping Units) mit ihren aktuellen Beständen. Sie beschreibt den gegenwärtigen Zustand der Supply Chain. Je nach Branche reichen Mengen je SKU nicht aus. Verfallsdaten können vorliegen; ein Teil oder der gesamte Bestand kann nach Seriennummern verfolgt werden. Dann sind sämtliche Seriennummern und ihre Standorte relevant. Allgemein sind alle Angaben wichtig, die den aktuellen Zustand der Bestände des Unternehmens beschreiben.

Preise: Die Liste der Preise, die der Kunde für Waren und gegebenenfalls zugehörige Dienstleistungen berechnet. Die aktuelle Preispolitik kann von früheren Preisen abweichen. Neue Preise beeinflussen sowohl die künftige Nachfrage als auch die Rentabilität der Supply-Chain-Entscheidungen. Aktionen, Mengenrabatte und Preisoptionen können hinzukommen. Alle Angaben, die in den berechneten Kundenpreis eingehen, sind relevant.

Momentaufnahmen früherer Bestände, Preise und damals ausstehender Einkaufsbestellungen sind für die meisten Supply-Chain-Aufgaben ebenfalls relevant, aber in Geschäftssystemen selten verfügbar. Sobald die Datenextraktions-Pipeline steht, kann Lokad solche Momentaufnahmen selbst anlegen, ohne direkten Eingriff der IT-Abteilung.

Trotz dieser umfangreichen Liste besitzen Unternehmen meist noch weitere relevante Datenquellen. Als Faustregel gilt: Was der Supply-Chain-Abteilung nützt, ist wahrscheinlich auch für die prädiktive Optimierung relevant und sollte an Lokad übertragen werden.

Priorisiertes Schema der vorbereiteten Daten

Die Liste der oben genannten potenziell relevanten Datentabellen soll nicht überfordern. In der Praxis ist es wichtig zu identifizieren, welche Tabellen erforderlich sind, um die Initiative in die Produktion zu überführen, im Gegensatz zu solchen, die lediglich wünschenswert wären. Es ist auch wichtig, die Extraktionen richtig zu priorisieren, damit die Supply Chain Scientists über die Datenextraktionsphase hinaus in die Optimierungsphase übergehen können.

Lokad empfiehlt deshalb, dass die Supply Chain Scientists zu Beginn ein priorisiertes Schema der aufbereiteten Daten erstellen und der IT-Abteilung übergeben. Es listet die Tabellen und Felder auf, die am Ende der Datenaufbereitung vorliegen sollen, und nennt die Priorität jedes angeforderten Feldes.

Dieses Schema beschreibt die gewünschten Daten auf übergeordneter Ebene. Es ist keine Dateispezifikation für die Extraktion. Die Datenaufbereitung liegt bei den Supply Chain Scientists; die extrahierten Daten dürfen und werden häufig erheblich vom „idealisierten“ Schema der aufbereiteten Daten abweichen. Darauf geht der Abschnitt „Unveränderte Transaktionsdaten“ näher ein.

Historische Tiefe der Daten

Bei der historischen Tiefe sind zwei Fragen zu unterscheiden: Wie weit soll die Extraktion zurückreichen? Und welche Mindesthistorie braucht die Supply-Chain-Initiative, um erfolgreich zu sein?

Für Tabellen mit weniger als 1 Milliarde Zeilen empfehlen wir grundsätzlich die gesamte verfügbare Historie. Eine Kürzung verliert Daten, die für die langfristige Entwicklung der Supply Chain relevant sein könnten. Lokad filtert die Daten ohnehin bei der Aufbereitung; mehr übertragene Daten bedeuten daher nicht zwangsläufig mehr Rechenaufwand.

Eine Mindesthistorie gibt es nicht. Bei einer kurzen Historie, etwa sechs Monaten, lassen sich bestimmte Muster wie Saisonalität nicht schätzen. Die Supply-Chain-Praktiker, die diese Entscheidungen bereits vor Lokad treffen müssen, unterliegen jedoch denselben Grenzen. Lokads numerisches Rezept nutzt die vorhandene Historie bestmöglich, auch wenn sie dem Kunden dürftig erscheint.

Fehlende Daten

Auch umfangreiche moderne Geschäftssysteme scheinen viele Daten nicht zu enthalten. Das kann Zweifel an der Machbarkeit einer Initiative für Quantitative Supply Chain wecken. Dennoch treffen Mitarbeiter die Entscheidungen, die den Betrieb aufrechterhalten, unabhängig davon, wie viele Daten „fehlen“. Es gibt also einen Weg. Wie die Mitarbeiter nutzt Lokad die verfügbaren Informationen bestmöglich. Das steht im Gegensatz zu gängiger Unternehmenssoftware, die feste Datenanforderungen vorgibt und erst funktioniert, wenn diese vollständig erfüllt sind.

Nach unserer Erfahrung gibt es zwei breite Klassen von „fehlenden“ Daten, die unterschieden werden sollten: erstens Daten, die in das Geschäftssystem integriert werden sollten; zweitens Daten, von denen angenommen wird, dass sie für das analytische System (wie Lokad) höchst vorteilhaft sind.

Mindestbestellmengen (MOQs), Preisstaffeln und Betriebsferien von Lieferanten fehlen häufig in Geschäftssystemen, sind aber für die Supply-Chain-Optimierung wertvoll. Über Tabellenkalkulationen und E-Mails verstreute Angaben kann Lokad nicht unmittelbar strukturiert analysieren. Wir empfehlen dann von Lokad programmierte Heuristiken sowie eigens erstellte Tabellen, die zu Lokad hochgeladen werden. Sobald das numerische Rezept läuft, bindet Lokad die IT ein, um die Daten in die Geschäftssysteme zu übernehmen. Das Rezept selbst zeigt, welche Daten tatsächlich wichtig sind und in welchem Umfang.

Wettbewerbsinformationsdaten, wie die Preise der Wettbewerber, sind eine Kategorie, von der angenommen wird, dass sie höchst nützlich ist, was nach unserer Erfahrung jedoch nicht selbstverständlich ist. Erfahrungsberichten zufolge ist der Erhalt dieser Art von Daten oft mit erheblichen Kosten verbunden, andernfalls würden Unternehmen dies bereits tun. Aus diesem Grund ist die Bereitstellung solcher Daten keine Voraussetzung. In jedem Fall wird das numerische Rezept von Lokad maßgeblich dazu beitragen, den tatsächlichen finanziellen Gewinn, der mit zusätzlichen Daten verbunden ist, zu bewerten.

Unveränderte Transaktionsdaten

Wir empfehlen eindringlich, die ursprüngliche Form der Daten beizubehalten. Die an Lokad übermittelten Daten sollten nichts anderes als rohe Kopien der ursprünglichen Tabellen und Spalten sein, wie sie im RDBMS zu finden sind, das die Geschäftssysteme des Unternehmens unterstützt. Die gesamte Datenaufbereitung sollte der Lokad Plattform überlassen werden, die speziell für die Datenaufbereitung entwickelt wurde.

Eine vorgeschaltete Aufbereitung führt unweigerlich zu Datenverlust. Ob dieser vertretbar ist, hängt von den konkreten Supply-Chain-Entscheidungen ab. Was vor der Übertragung an Lokad verloren geht, lässt sich dort nicht wiederherstellen. Unveränderte Transaktionsdaten machen hingegen die gesamten Informationen der Geschäftssysteme für Lokad zugänglich.

Die Datenaufbereitung schafft zusätzliche Komplexität neben derjenigen der Geschäftssysteme. Das numerische Rezept kann die fachlich unvermeidbare Komplexität der Supply-Chain-Optimierung nicht umgehen. Muss es aber zusätzlich mit der nicht fachlich bedingten Komplexität einer vorgeschalteten Datenaufbereitung umgehen, wird eine ohnehin schwierige Aufgabe unnötig schwer. Unveränderte Transaktionsdaten verhindern, dass Lokad ein größeres Problem lösen muss als das eigentliche.

Aus IT-Sicht sind rohtransaktionale Extrakte einfach. Es sollten einfache Tabellenkopien verwendet werden (z.B. SELECT * FROM MyTable), was die einfachste Form von Abfragen über eine relationale Datenbank darstellt. Solche Abfragen sind simpel, da keine Filter involviert sind, und performant, weil kein Join verwendet wird. Sehr große Tabellen bedürfen jedoch besonderer Aufmerksamkeit. Dieser Punkt wird im Folgenden behandelt.

Wenn ein Data Lake vorhanden ist, sollte dieser die relationalen Daten so spiegeln, wie sie in den Geschäftssystemen zu finden sind. Alle gängigen Datenbanksysteme verfügen über integrierte Spiegelungsfunktionen. Wir empfehlen, diese Funktionen beim Einrichten des Data Lakes zu nutzen. Darüber hinaus ist das Spiegeln von Daten weitaus einfacher als die Datenaufbereitung – insbesondere aus der Perspektive der IT-Abteilung, da die Datenaufbereitung stark vom spezifischen Problem abhängt, das gelöst werden soll.

Das BI-Extraktions-Antimuster

Die an Lokad zu sendenden Daten sollten nicht aus einer sekundären Quelle stammen (z.B. einem Business Intelligence (BI) System), in dem die Daten bereits umfangreich modifiziert wurden, üblicherweise zum Nutzen des direkten Endanwenderkonsums. Obwohl das Extrahieren von Daten aus einem BI-System einfacher ist als aus einem ERP, schafft dies unweigerlich unlösbare Probleme später. Durch das Design gehen die transaktionalen Aspekte der Daten verloren, da diese in tägliche / wöchentliche / monatliche Zeitreihen aggregiert werden.

BI-Systeme wie BI-Cubes entfernen außerdem relevante, aber schwer darstellbare Zusammenhänge, etwa Bestellungen mit mehreren Positionen. Solche Details sind wertvoll, weil sie den Kern der zu lösenden Supply-Chain-Situationen ausmachen.

Schlechte Daten

Nach Lokads Erfahrung sind Fälle von schlechten Daten selten. Im Gegenteil, transaktionale Geschäftssysteme (wie ERPs) verfügen in der Regel über präzise Daten. Falsche transaktionale Dateneingaben sind selten und treten typischerweise einmal oder zweimal pro 1000 Einträgen auf. Wenn Barcode-Scanner oder ähnliche Geräte verwendet werden, ist die Fehlerquote sogar noch niedriger. Das eigentliche Problem liegt in der Software, die falsche Annahmen über die Daten trifft, anstatt dass die Daten selbst mangelhaft sind.

Die Lagerbestände im stationären Handel großer B2C-Einzelhandelsnetze sind fast immer ungenau. Aus Lokads Sicht handelt es sich dabei jedoch um rauschende Daten und nicht um schlechte Daten. Wenn solche Bestände (fälschlicherweise) als präzise angenommen werden, führen die Ergebnisse zu Unsinn. Wir gehen diese spezielle Situation mit einer probabilistischen Betrachtung der Lagerbestände an, indem wir die Unsicherheit annehmen, statt sie zu ignorieren.

Lokads Systeme sind darauf ausgelegt, die Daten zu übernehmen und den Kunden den Betrieb ihrer Supply Chain zu ermöglichen, ohne dass sie sich um diese Fragen sorgen müssen. Lokad legt dafür die Datensemantik fest. Das ist der anspruchsvollste Teil der Datenaufbereitung.

Personenbezogene Daten

Eine Supply-Chain-Initiative benötigt fast nie personenbezogene Daten. Wir empfehlen, sie als Risiko statt als Vermögenswert zu betrachten, und raten dringend von ihrer Übertragung an Lokad ab. Üblicherweise werden dafür Spalten mit personenbezogenen Kennzeichen wie Namen, Adressen, Telefonnummern und E-Mail-Adressen ausgeschlossen, wie unten beschrieben.

Soweit die Information für die Supply Chain relevant ist, lassen sich diese Kennzeichen durch anonyme Kennungen ohne personenbezogenen Informationsgehalt ersetzen. Solche Kundenkennungen machen etwa Muster der Kundentreue und negative Folgen von Fehlbeständen erkennbar. Während die meisten Prognosetechnologien nur Zeitreihen auswerten, kann Lokad sehr detaillierte historische Daten bis hin zur einzelnen Transaktion nutzen.

Lokads Umgang mit persönlich identifizierbaren Informationen (PII) erläutern die Abschnitte 1, 3 und 4 unseres Dokuments zur Sicherheit.

Finanzdaten

Die Geldbeträge eingekaufter, verarbeiteter und verkaufter Waren sind für Lokads Supply-Chain-Optimierung besonders wichtig. Lokad verfolgt eine finanzielle Perspektive und optimiert Erträge in Dollar statt Fehler in Prozent.

Anders als Anbieter, die nur Bestandsmengen betrachten, nutzt Lokad die verfügbaren Finanzdaten des Kunden. Die problematischsten Kosten entstehen an den Extremen: Unerwartet hohe Nachfrage führt zu Fehlbeständen, unerwartet geringe Nachfrage zu Abschreibungen. Dazwischen schlägt sich der Bestand problemlos um. Wirklich optimierte Bestandsentscheidungen erfordern deshalb eine finanzielle Abwägung dieser Risiken, die Lokad anhand der Finanzdaten berechnet.

Datenpipeline vs. One-Shot-Extraktion

Eine Datenextraktions-Pipeline aktualisiert automatisch die an Lokad übermittelten Daten. Diese Einrichtung stellt einen größeren Aufwand dar als eine One-Shot-Datenextraktion. Wenn möglich, empfehlen wir dringend, die Datenextraktion zu automatisieren, möglicherweise in Phasen, falls die Anzahl der relevanten Tabellen groß ist. Diese Automatisierung funktioniert am besten, wenn sie ab dem ersten Tag implementiert wird. Teilweise One-Shot-Extraktionen, die zur Identifizierung relevanter Tabellen verwendet werden, können jedoch nützlich sein. Dieser Punkt wird in den folgenden Abschnitten erörtert.

Es gibt drei Hauptgründe, die einen Datenpipeline-Ansatz unterstützen.

Erstens sind 3 Wochen alte Daten für Supply-Chain-Praktiker längst überholt. Ergebnisse daraus helfen bei heutigen Entscheidungen nicht. Eine einmalige Extraktion liefert nur eine Momentaufnahme der Geschäftshistorie und daher begrenzt nützliche Ergebnisse. Die Anwender müssen das analytische System in Aktion sehen, um seiner Fähigkeit zu vertrauen, tägliche Schwankungen zu bewältigen.

Zweitens ist eine verlässliche Datenpipeline zwar schwer zu entwickeln, den Alternativen aber vorzuziehen. Eine unzuverlässige Pipeline gefährdet die gesamte Initiative für Quantitative Supply Chain. Keine Analyse kann grundlegende Datenprobleme beheben, etwa fehlende aktuelle Bestandsmengen.

Die Extraktion braucht meist zahlreiche geplante Durchläufe, bis sie zuverlässig funktioniert: Manche Probleme treten nur gelegentlich auf. Ein möglichst früher Start erlaubt Lokad, diese zu erkennen und zu beheben. Regelmäßige Durchläufe sind außerdem eine der sichersten Methoden, die Leistung der gesamten Prozesskette bis hin zur Bereitstellung der empfohlenen Supply-Chain-Entscheidungen zu prüfen.

Drittens ist der verspätete Aufbau der Datenextraktions-Pipeline unserer Erfahrung nach die häufigste Ursache für Verzögerungen bei Initiativen für Quantitative Supply Chain. IT-Abteilungen stehen unter Druck, viele Projekte umzusetzen; die Pipeline ist eine zusätzliche Aufgabe. Es liegt daher nahe, sie aufzuschieben und zunächst mehrere einmalige Extraktionen durchzuführen. Das ist möglich, kann aber das Vorhaben verzögern und Lokad daran hindern, ganze Arten potenzieller Probleme frühzeitig zu erkennen.

Datenextraktionsfrequenz

Wir empfehlen, alle Datenpipelines – sowohl die Extraktionssegmente als auch die analytischen Segmente – mindestens einmal am Tag zu aktualisieren, selbst wenn monatliche oder vierteljährliche Berechnungen durchgeführt werden. Dies mag kontraintuitiv erscheinen, aber nach unserer Erfahrung sind häufige, automatisierte Aktualisierungen der einzige Weg, um einen hochzuverlässigen End-to-End-Prozess zu erreichen.

Für die meisten Supply-Chain-Situationen empfehlen wir eine Extraktion, die den vollständigen Datenstand bis zum Geschäftsschluss des laufenden Tages abdeckt. Am Donnerstagabend werden beispielsweise alle relevanten historischen Daten bis einschließlich Donnerstag extrahiert. Anschließend verarbeitet Lokad sie analytisch, sodass die Ergebnisse zu Beginn des nächsten Arbeitstages bereitstehen.

Datenextraktionstiefe: die 2+1-Regel für Inkremente

Wenn die Daten zu groß sind, um jeden Tag vollständig zu Lokad erneut hochgeladen zu werden, sollten inkrementelle Uploads verwendet werden. Wir empfehlen, dass solche Uploads der 2+1-Regel für Inkremente folgen: Das Zeitfenster des täglichen Uploads umfasst die letzten zwei vollständigen Wochen sowie die aktuelle Woche. Die Einhaltung dieser Regel ist wichtig, um die hohe Zuverlässigkeit der Lokad-Lösung zu gewährleisten.

Die Pipeline wird gelegentlich ausfallen, unabhängig von Lokad. Selbst ausgezeichnete IT-Abteilungen erleben nach unserer Erfahrung 1–2 Ausfälle pro Jahr. Dann fehlen die Daten des letzten Tages oder sind unvollständig. Deckt jeder Upload nur einen einzelnen Tag ohne Überschneidung ab, bleibt die Historie bei Lokad beschädigt. Ihre Reparatur erfordert einen zusätzlichen manuellen Eingriff der IT, neben der Behebung des ursprünglichen Ausfalls. Dieser ungewohnte Eingriff kann sich um einige Tage verzögern. Bis dahin beeinträchtigen die fehlerhaften jüngsten Daten Lokads Ergebnisse.

Deckt dagegen jeder Upload die letzten zwei vollständigen Arbeitswochen und die laufende Woche ab, wird ein ausgefallener Tageslauf am nächsten Tag vollständig ausgeglichen. Da die Pipeline zum regulären IT-Betrieb gehört, lässt sie sich voraussichtlich innerhalb eines Arbeitstages wiederherstellen. Dafür ist keine besondere Abstimmung mit Lokads Support oder den Endanwendern erforderlich. Das tägliche Überschreiben der Daten im 2+1-Fenster repariert die Historie automatisch.

Die 2+1-Regel spiegelt einen Kompromiss basierend auf Lokads Erfahrung wider: Je länger das Zeitfenster, desto widerstandsfähiger wird die Datenextraktions-Pipeline gegenüber vorübergehenden Problemen. Auch wenn wir hoffen können, dass alle Probleme mit der Datenextraktions-Pipeline innerhalb eines Geschäftstages gelöst werden, könnten der IT-Abteilung dringlichere Aufgaben bevorstehen. Tatsächlich könnte die fehlerhafte Datenextraktions-Pipeline nur ein Symptom eines schwerwiegenderen Problems sein, das von der IT-Abteilung priorisiert zu beheben ist. Daher kann die Wiederherstellung einige Tage in Anspruch nehmen. Die 2+1-Regel stellt sicher, dass der Betrieb, sofern die IT-Abteilung es schafft, die Pipeline innerhalb von zwei Wochen zu reparieren, mit möglichst geringem Einfluss auf die Optimierungsinitiative wieder aufgenommen werden kann. Sollte das Zeitfenster jedoch zu lang sein, wird der inkrementelle Upload in Bezug auf die Rechenressourcen zu aufwendig, was den eigentlichen Zweck der Einführung inkrementeller Uploads zunichtemacht.

Wenn die letzten drei Wochen weniger als 100MB Daten umfassen, empfehlen wir, die monatliche Variante der 2+1-Regel anzuwenden: Das Zeitfenster des täglichen Uploads umfasst die letzten beiden vollständigen Monate sowie den aktuellen.

Identifizierung der relevanten Tabellen und Spalten

Die überwiegende Mehrheit der Unternehmenssoftware wird auf relationalen Datenbanken aufgebaut. Obwohl Web-APIs existieren können, liefern diese in unserer Erfahrung selten eine zufriedenstellende Leistung, wenn es um geplante, vollständige Datenextraktionen geht. Im Gegenteil, das direkte Abfragen der Datenbank mittels SQL erweist sich häufig als sowohl leicht umsetzbar als auch ziemlich leistungsfähig, da die von Lokad empfohlenen SQL-Abfragen keinerlei Joins erfordern.

Ist ein Geschäftssystem wie das ERP als Datenquelle relevant und seine relationale Datenbank zugänglich, müssen die passenden Tabellen und Spalten ausgewählt werden. Viele Systeme enthalten Hunderte Tabellen und Tausende Spalten, die überwiegend nicht benötigt werden. Für den Start einer Supply-Chain-Initiative reichen meist höchstens ein Dutzend Tabellen; wenige Dutzend genügen für eine umfassende Datenabdeckung.

Ein Experte, der das Datenbankschema kennt, kann die relevanten Tabellen am einfachsten identifizieren. Ohne einen solchen Experten lassen sie sich meist durch Reverse Engineering innerhalb von ein bis zwei Wochen finden, auch bei recht komplexen Systemen. Neben der verfügbaren technischen Dokumentation empfehlen wir zunächst einen vollständigen Schemaauszug mit folgenden Angaben:

• Tabellenname
• Spaltenname
• Spaltentyp
• Tabellengröße

Diese Angaben sollten in einer Tabellenkalkulation gesammelt werden. Namen und Größen helfen, Kandidaten zu erkennen. Beginnen Sie mit den größten Datenbanktabellen; dort liegen häufig die für die Supply-Chain-Optimierung wichtigsten Informationen. Prüfen Sie jeweils einige Dutzend Datenzeilen visuell und ergänzen Sie Ihre Beobachtungen laufend in der Übersicht.

PostgreSQL Schema-Diagnose

Die Abfrage zum Extrahieren aller Tabellen und Spalten:

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name = '‘table_name'’;

Siehe auch https://stackoverflow.com/questions/20194806/how-to-get-a-list-column-names-and-datatypes-of-a-table-in-postgresql

Die Abfrage zum Extrahieren aller Tabellengrößen:

select table_name, pg_relation_size(quote_ident(table_name))
from information_schema.tables
where table_schema = '‘public'’

Siehe auch https://stackoverflow.com/questions/21738408/postgresql-list-and-order-tables-by-size

Die Abfragevorlage zum Extrahieren einer Stichprobe von Zeilen:

select column from table
order by RANDOM()
limit 10000

Siehe auch https://stackoverflow.com/questions/19412/how-to-request-a-random-row-in-sql

Oracle Schema-Diagnose

Die Abfrage zum Extrahieren aller Tabellen und Spalten:

SELECT table_name, column_name, data_type FROM ALL_TAB_COLUMNS

Die Abfrage zum Extrahieren aller Tabellengrößen:

SELECT table_name, num_rows FROM ALL_TABLES

Die Abfragevorlage zum Extrahieren einer Stichprobe von Zeilen:

set colsep ,
set headsep off
set pagesize 0
set trimspool on
spool c:/temp/oracle/output/foo_my_table.csv
SELECT * FROM FOO_MY_TABLE FETCH FIRST 10000 ROWS ONLY;
spool off

Dateiformate und Transfers

Die Lokad-Plattform liest und schreibt flache Textdateien, meist CSV oder TSV, sowie Microsoft-Excel-Tabellen. Der Abschnitt Dateien lesen und schreiben dokumentiert diese Ein- und Ausgabefunktionen. Trotz der vielen unterstützten Formatoptionen empfehlen wir Folgendes:

• Klartext wird anstelle von Tabellenkalkulationen verwendet (siehe Diskussion unten).
• Die erste Zeile enthält die Spaltenüberschriften und entspricht den ursprünglichen Spaltennamen.
• Spaltennamen enthalten keine Leerzeichen oder Bindestriche.
• UTF-8 wird für die Zeichenkodierung verwendet.
• Punkt (.) ist das Dezimaltrennzeichen für Bruchzahlen.
• Alle Datumsangaben haben in allen Tabellen dasselbe Format.
• Beträge trennen die Währung in einer separaten Spalte.
• Der Dateiname entspricht dem ursprünglichen Tabellennamen.
• /input ist der Lokad-seitige Ordner, der per Konvention für das Ablegen der extrahierten Dateien verwendet wird.

Immer wenn eine extrahierte flache Datei größer als 100MB ist, empfehlen wir, die Datei mit GZIP zu komprimieren.

Beim Transfer empfehlen wir die Verwendung von SFTP mit Public-Key-Authentifizierung.

Partitionierte Tabellen

Wir empfehlen, Tabellen zu partitionieren, die zu groß sind, um täglich vollständig bequem nach Lokad hochgeladen zu werden. Partitionierung ermöglicht in der Regel inkrementelle Uploads, falls die Partition das Alter der Daten widerspiegelt. Als Faustregel gilt, dass Tabellen mit weniger als 1 Million Zeilen in der Regel den Aufwand einer Partitionierung nicht wert sind.

Beim Partitionieren einer Tabelle in eine Liste von Dateien besteht das empfohlene Dateinamensmuster darin, die Dateien in einem eigenen Unterordner innerhalb von /input (benannt nach der jeweiligen Tabelle) zu sammeln und jede Datei mit dem entsprechenden extrahierten Segment zu versehen:

/input/mytable/mytable-2022-10-17.csv
/input/mytable/mytable-2022-10-18.csv
/input/mytable/mytable-2022-10-19.csv
/..

Auch wenn alle Zeilen in einer Datei denselben “Datum”-Wert aufweisen (entsprechend dem im Dateinamen gefundenen Wert), empfehlen wir, diese “Datum”-Spalte als Teil der Datei beizubehalten.

Microsoft Excel

Die Plattform von Lokad unterstützt das Auslesen von Daten aus Microsoft Excel-Tabellen, solange die Tabelle ein tabellarisches Format aufweist (die erste Zeile enthält die Überschriften, gefolgt von einem Datensatz pro Zeile). Allerdings sollte die Datenextraktions-Pipeline das Übertragen von Tabellenkalkulationen zu Lokad vermeiden.

Tabellenkalkulationen sind akzeptabel, wenn Dateien manuell hochgeladen werden, anstatt durch die automatisierte Datenextraktions-Pipeline übertragen zu werden. Manuelle Uploads sind akzeptabel, wenn:

• Die Daten existieren (noch) nicht in den Geschäftssystemen.
• Die Daten werden nur sehr selten aktualisiert.

/manual ist der Lokad-seitige Ordner, der per Konvention für den Empfang manuell hochgeladener Dateien verwendet wird.

Dateiüberschreibungen

Die Dateien im Lokad-Dateisystem repräsentieren die von Lokad betrachteten Daten. Das Überschreiben bestehender Dateien ist die empfohlene Methode, um die extrahierten, nicht partitionierten Tabellen zu aktualisieren. Im Falle einer partitionierten Tabelle wird standardmäßig erwartet, dass für jeden Zeitraum eine neue Datei erstellt wird (eine Datei pro Tag, Woche oder Monat).

Sobald alle zu erstellenden (oder zu überschreibenden) Dateien zu Lokad übertragen wurden, empfehlen wir, eine Datei namens /input/end-of-transfer.csv zu erstellen (oder zu aktualisieren), die Folgendes enthält:

• eine einzelne Spalte namens LastTransfer
• eine einzige Datenzeile (zwei Zeilen inklusive Kopfzeile) mit einem Zeitstempel der zuletzt erfolgten Übertragung

Diese Datei kann verwendet werden, um eine Projektsequenz zu starten, die die frisch aktualisierten Daten verarbeitet.

Datenqualität

Die Datenextraktions-Pipeline muss zuverlässig arbeiten. Lokad kann ihre Ausgaben überwachen und die Integrität, Vollständigkeit und Aktualität der Daten prüfen. Deshalb empfehlen wir als ersten Verarbeitungsschritt in Lokad Dashboards zur Datenqualität. Sie sind für die IT-Abteilung bestimmt, die sie aber nicht betreuen muss. Sie machen Datenprobleme sichtbar und beschleunigen deren Behebung durch die IT. Die Umsetzung übernimmt, wie beim übrigen numerischen Rezept, ein Supply-Chain-Experte, bei einem „Platform+Experts“-Abonnement gegebenenfalls das Lokad-Team.

Spezifikation der Datenextraktion

Sobald die Pipeline stabil läuft, empfehlen wir eine Spezifikation mit sämtlichen erwarteten Dateien, ihren Spalten und dem Extraktionszeitplan. Die Stabilisierung sollte innerhalb von sechs Monaten nach Projektbeginn erfolgen. IT- und Supply-Chain-Abteilung vereinbaren das Dokument gemeinsam. Es legt genau fest, welche Daten die IT der Lokad-Plattform zu welchen Zeitpunkten bereitstellen soll.

Das Datenformat darf später geändert werden, aber die IT muss die Supply-Chain-Abteilung vorher über Änderungen am Format oder Zeitplan informieren. Nach der Vereinbarung hängt der laufende Betrieb von der Integrität der Extraktion ab. Deshalb muss der Supply-Chain-Abteilung bei Änderungen eine angemessene Übergangsfrist bleiben, um die Logik in Lokad an das neue Format anzupassen.

Da die Erstellung einer detaillierten Spezifikation erheblichen Zeit- und Arbeitsaufwand erfordert, empfehlen wir, mit der Erstellung dieses Dokuments zu warten, bis die Pipeline stabilisiert ist. Unserer Erfahrung nach unterliegt die Pipeline – sowohl in ihrem Datenextraktions- als auch in ihrem Analysebereich – in den ersten paar Monaten einer raschen Entwicklung. Diese rasche Entwicklung lässt frühe Versuche, eine derartige Spezifikation zu erstellen, oft überflüssig werden.

Rückführung der Entscheidungen

Die in Lokad berechneten Supply-Chain-Entscheidungen, etwa Bestandsauffüllungen, können als flache Dateien exportiert und in die Geschäftssysteme zurückgeführt werden. Diesen Mechanismus nennen wir Rückkopplungsschleife. Erfahrungsgemäß wird er selten in den ersten vier Monaten umgesetzt. Selbst ein begrenzter Autopilotbetrieb erfordert erhebliches Vertrauen in das numerische Rezept, das erst über mehrere Monate wächst. Die Rückführung muss daher zu Beginn noch nicht behandelt werden.

Die Rückführung einzurichten ist wesentlich einfacher als der Aufbau der Extraktions-Pipeline. Lokads Zahlen sollen verbindlich und endgültig sein. Sind weitere Regeln nötig, um sie ausführbar zu machen, etwa die Anwendung von Mindestbestellmengen, ist das numerische Rezept unvollständig und muss auf Lokads Seite korrigiert werden. Die Plattform kann alle hinreichend tabellarischen Datenformate verarbeiten und erzeugen. Die einfache Rückführung entspricht damit der einfachen Form der endgültigen Entscheidungen: Dutzende Beschränkungen können die Zulässigkeit einer Bestellung bestimmen, doch die Bestellung selbst bleibt eine Liste von Mengen und Artikelnummern.

Wir empfehlen jedoch, dass der Lokad-Plattform kein direkter Zugriff auf die Geschäftssysteme des Kunden gewährt wird. Stattdessen sollten die Dateien zeitnah im Lokad-Dateisystem zur Verfügung gestellt werden. Die IT-Abteilung bleibt für das Wiedereinlesen dieser Daten in die Geschäftssysteme verantwortlich. Dies stellt sicher, dass ein potenzieller Sicherheitsverstoß des Lokad-Kontos nicht dazu genutzt werden kann, auf andere Systeme innerhalb des Unternehmens zuzugreifen. Außerdem bietet dies die Möglichkeit, diesen Feedback-Vorgang zu verschieben, falls er mit einem anderen von der IT durchgeführten Vorgang in den Geschäftssystemen kollidiert.

Da die Rückführung reale Supply-Chain-Vorgänge betrifft, empfehlen wir eine eigene Spezifikation. Sie entspricht der Extraktionsspezifikation, beschreibt aber die entgegengesetzte Übertragungsrichtung. Auch dieses Dokument sollten IT- und Supply-Chain-Abteilung gemeinsam vereinbaren.