Die Datenextraktions-Pipeline

Dieses Dokument ist als Leitfaden für IT-Abteilungen gedacht, um eine Pipeline zu erstellen, die Daten aus bestehenden Geschäftssystemen extrahiert und diese Daten innerhalb von Lokads Plattform verfügbar macht. Der Aufbau einer Datenpipeline ist eine der frühesten Phasen einer Initiative der Quantitative Supply Chain. Das Dokument behandelt den von Lokad empfohlenen Ansatz, einschließlich des Umfangs der zu extrahierenden und auf der Lokad-Plattform verfügbaren Daten, des Datenformats und der Strategien zur Datenübertragung.

Motivation und Kontext

Lokad definiert eine Initiative der Quantitative Supply Chain als eine, die ein numerisches Rezept liefert, das Entscheidungen (oder zumindest Empfehlungen) angesichts von supply chain Herausforderungen automatisiert. Lokad bietet eine programmatische Plattform, die zur Lösung von prädiktiven Optimierungsproblemen im Zusammenhang mit supply chain entwickelt wurde.

Typische Probleme umfassen:

• Entscheiden, welche Lagerbestände aufgefüllt werden sollen
• Entscheiden, welche Lagerbestände produziert werden sollen
• Entscheiden, ob Preise erhöht oder gesenkt werden sollen
• Entscheiden, ob Bestände innerhalb des Netzwerks verschoben werden sollen

Wenn es dem Unternehmen gelingt, diese Entscheidungen zu optimieren, kann es in der Regel seine Betriebskosten senken, seinen Bedarf an Working Capital reduzieren und seine Servicequalität erhöhen. Mindestens sollte das Unternehmen in der Lage sein, diese Mischung aus Kosten, Liquidität und Service dahingehend anzupassen, dass sie stärker mit seiner übergeordneten supply chain-Strategie in Einklang steht.

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.

Sobald die Datenextraktions-Pipeline erstellt wurde, sind Lokad-seitige Ingenieure - bezeichnet als Supply Chain Scientists - für den Aufbau und die Wartung des numerischen Rezepts verantwortlich. Diese Ingenieure werden häufig von Lokad im Rahmen eines “Platform+Experts”-Servicevertrags bereitgestellt, es ist jedoch auch möglich, dass der Kunde diese Kompetenz intern aufbaut. Selbst wenn diese Ingenieure inhouse tätig sind, empfehlen wir, sie in der supply chain-Abteilung und nicht in der IT-Abteilung anzusiedeln.

Unabhängig davon, ob dieser Teil der supply chain-Initiative ausgelagert ist oder nicht, bleibt die in diesem Dokument dargelegte Perspektive gleich.

Technische Perspektive auf hoher Ebene

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 Lokad zur Verfügung gestellt werden, verarbeiten eine Reihe von Envision-Skripten (Envision ist die von Lokad entwickelte domänenspezifische Programmiersprache) diese und erzeugen die optimierten supply chain-Entscheidungen von Interesse.

Es gibt mehrere praktische Anwendungen dieser Datenextraktion, von denen viele über Lokads supply chain-Optimierungsinitiative hinausgehen. Marketing-, Finanz- und Vertriebsteams – um nur drei zu nennen – sind potenzielle Nutznießer derselben historischen Verkaufsdaten, die Lokad letztendlich verarbeitet. Aus diesem Grund empfiehlt Lokad, die transaktionalen Daten in einer dedizierten Servicing-Schicht – einem “data lake” – zu konsolidieren, die ausschließlich für die Bereitstellung solcher Daten an entsprechende Teams und Drittanbieter-Analysetools (wie Lokads Plattform) vorgesehen ist.

Die Erstellung eines data lake ist keine Voraussetzung für die Nutzung von Lokad, sondern lediglich eine potenzielle Architektur, die die Abläufe im Unternehmen erleichtert. Es ist anzumerken, dass ein data lake auch die Entstehung einer “data practice” innerhalb eines Unternehmens begünstigt – sofern eine solche Praxis nicht bereits existiert.

Der Umfang relevanter Daten

supply chain dreht sich darum, Entscheidungen im Zusammenhang mit dem Fluss von physischen Gütern (Einkauf, Transport, Produktion, Vertrieb usw.) zu optimieren. Folglich sind die relevantesten Daten für eine prädiktive Optimierungsinitiative fast immer jene Daten, die sämtliche im Unternehmen ablaufenden Flüsse beschreiben. Diese Daten finden sich typischerweise in den transaktionalen Geschäftssystemen des Kunden.

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 (bzw. Artikel, Teile), die das Unternehmen kauft, transformiert, montiert und/oder verkauft. Diese Liste ist von Bedeutung, da viele Entscheidungen auf “Produktebene” getroffen werden. Die Hierarchie (z. B. Kategorien, Familien, Unterfamilien), falls vorhanden, ist sowohl für Berichts- als auch für Analysezwecke relevant. Strukturierte Attribute (z. B. Farbe, Größe, Gewicht, Form), die die Produkte charakterisieren, sind ebenfalls nützlich. Als Faustregel gilt: Jegliche Daten, die die Produkte – aus supply chain Perspektive – beschreiben, sind relevant. Beziehungen zwischen Produkten – wie Stücklisten (BOMs, bills of materials) – sind ebenso von Bedeutung.

Verkaufshistorie: Die Liste der historischen Verkaufsaufträge des Kunden. Diese Liste ist relevant, da Verkäufe fast immer der beste Annäherungswert sind, den das Unternehmen zur Abschätzung der Marktnachfrage hat. Diese Daten sollten die mit den Transaktionen verbundenen Geldbeträge umfassen, da supply chain-Optimierung aus finanzieller Perspektive durchgeführt werden sollte. (Diese finanzielle Perspektive wird später noch ausführlicher behandelt.) Wo möglich, ist es (immer) vorzuziehen, Rohdaten der Aufträge bereitzustellen, anstatt Tages-/Wochen-/Monatsaggregate. (Auch dieser Punkt wird weiter unten detailliert diskutiert.) Die Verkaufshistorie kann aufgestaute, stornierte, verschobene, geänderte Aufträge, Rücksendungen usw. umfassen, die alle potenziell relevante Datenpunkte darstellen. Falls in diesen Daten Kunden identifiziert werden, werden die anonymisierten Kundenkennungen relevant. (Personenbezogene Daten haben einen eigenen Abschnitt weiter unten.)

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 der historischen Produktionsaufträge des Kunden (falls zutreffend) sowie der ausstehenden Produktionsaufträge (noch auszuführen). Diese Liste ist von Bedeutung, da diese Aufträge den Umwandlungsfluss von Gütern widerspiegeln, der im Unternehmen stattfindet, und uns darüber hinaus ermöglicht, Engpässe in der supply chain zu identifizieren. Je nach Situation kann die Produktion variable Erträge aufweisen oder manchmal werden Chargen aufgrund von Qualitätsproblemen verworfen. Diese Ereignisse sind relevant.

Lagerbewegungen: Die Liste der historischen Lagerbewegungen des Kunden, falls mehrere Standorte vorhanden sind. Diese Liste ist relevant, da sie Aufschluss über die Herkunft des Bestands gibt, der entweder Produktionsprozesse auslöst oder Kunden bedient. Je nach Situation können die Durchlaufzeiten für diese Bewegungen variieren. In diesem Fall sind auch die Details der Daten (Umschlagsdatum, Versanddatum, Empfangsdatum) relevant.

Lagerbestände: Die Liste aller SKUs (Stock Keeping Units) des Kunden mit ihrem aktuellen Lagerbestand. Diese Liste ist wichtig, da sie den aktuellen Zustand der supply chain charakterisiert. Je nach Branche kann die Darstellung des Inventars komplexer sein als einfache SKU-Werte. Verfallsdaten können ebenfalls vorhanden sein. Ein Teil oder das gesamte Inventar kann auf Seriennummernbasis verfolgt werden. Falls Serieninventar verwendet wird, ist die vollständige Liste der Seriennummern und deren zugeordneten Standorte relevant. Allgemein sind alle Elemente, die den aktuellen Zustand der im Unternehmen gehaltenen Lagerbestände beschreiben, relevant.

Preisschilder: Die Liste der vom Kunden angewendeten Preise bei der Bearbeitung der Waren (und möglicherweise der dazugehörigen Dienstleistungen). Diese Liste ist von Bedeutung, da die aktuelle Preisstrategie des Kunden von früheren abweichen kann. Neue Preise beeinflussen die künftige Nachfrage, aber auch die Rentabilität der supply chain-Entscheidungen. Aktionen, Preisnachlässe oder Preismodelle können ebenfalls vorhanden sein. Alle Elemente, die zur Berechnung dessen beitragen, was den Kunden in Rechnung gestellt wird, sind relevant.

Schnappschüsse vergangener Lagerbestände, früherer Preisschilder und ausstehender Einkaufsaufträge sind ebenfalls für die meisten supply chain-Zwecke relevant (diese Daten sind jedoch in Geschäftssystemen selten verfügbar). Sobald eine Datenextraktions-Pipeline eingerichtet ist, können solche Schnappschüsse direkt innerhalb von Lokad implementiert werden – ohne direkten Eingriff der IT-Abteilung des Kunden.

Obwohl diese Liste bereits umfangreich ist, gibt es in Unternehmen in der Regel mehr relevante Datenquellen, als hier aufgeführt wurden. Als Faustregel gilt: Wenn eine Information für die supply chain-Abteilung nützlich ist, ist sie höchstwahrscheinlich auch für prädiktive Optimierungszwecke relevant und sollte an Lokad weitergeleitet 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.

Daher empfiehlt Lokad im Rahmen unserer supply chain-Praxis, dass die Supply Chain Scientists ein priorisiertes Schema der vorbereiteten Daten erstellen und dieses Dokument zu Beginn der Initiative mit der IT-Abteilung des Kunden teilen. Dieses Dokument listet die Tabellen – und deren Felder – auf, die am Ende des Datenvorbereitungssegments verfügbar sein sollen. Zudem enthält es die jeweiligen Prioritäten aller angeforderten Felder.

Dieses Schema stellt eine grobe Wunschliste für die zu extrahierenden Daten dar. Allerdings sollte dieses Dokument nicht als Spezifikation der Dateien verstanden werden, die in der Datenextraktionsphase erzeugt werden. Die Supply Chain Scientists sind für die Datenaufbereitung verantwortlich. Es ist akzeptabel (und üblich), wenn das Schema der Daten, wie es durch die Datenextraktions-Pipeline bereitgestellt wird, erheblich von dem “idealisierten” Schema der vorbereiteten Daten abweicht. Dieser Punkt wird im Abschnitt “Raw transactional extracts” weiter unten ausführlicher behandelt.

Historische Tiefe der Daten

Bei der historischen Tiefe der zu extrahierenden Daten gibt es in der Regel zwei unterschiedliche Aspekte. Zum einen: Wie weit in die Vergangenheit sollte die Datenextraktion reichen? Zum anderen: Was ist die minimale historische Tiefe, die erforderlich ist, damit die supply chain-Initiative Erfolg hat?

Grundsätzlich empfehlen wir, die gesamte verfügbare Historie für alle Tabellen zu extrahieren, die weniger als 1 Milliarde Zeilen umfassen. Eine Kürzung der Historie würde bedeuten, Daten zu verlieren, die für die Beurteilung der langfristigen Entwicklung der supply chain relevant sein könnten. Filter werden seitens Lokad im Rahmen der Datenaufbereitung implementiert, sodass das Übertragen von mehr Daten nicht zwangsläufig zu einem höheren Bedarf an Rechenressourcen bei Lokad führt.

Was die historische Tiefe betrifft, gibt es keine Mindestanforderung. Wenn die Systemhistorie kurz ist (z. B. sechs Monate), können bestimmte statistische Muster wie Saisonalität nicht erfasst werden. Allerdings unterliegen die supply chain-Praktiker, die die interessanten Entscheidungen treffen müssen, bereits vor der Lokad-Initiative denselben Einschränkungen. Das numerische Rezept von Lokad wird so implementiert, dass es die verfügbare historische Tiefe bestmöglich nutzt, selbst wenn sie für den Kunden dürftig erscheinen mag.

Fehlende Daten

Während moderne Geschäftssysteme typischerweise umfangreich sind, gibt es unvermeidlich viele Daten, die zu fehlen scheinen. Da die Daten als fehlend wahrgenommen werden, wird die Tragfähigkeit der die Quantitative Supply Chain Initiative in Frage gestellt. Allerdings schaffen es Mitarbeiter in der Organisation, unabhängig davon, wie viele Daten als „fehlend“ erscheinen, trotzdem die Entscheidungen zu treffen, die erforderlich sind, damit die supply chain funktioniert. Kurz gesagt, es gibt einen Weg. Lokads technologischer Ansatz beruht darauf, mit dem, was verfügbar ist, das Maximum herauszuholen – ganz so, wie es die Mitarbeiter tun. Dieser Ansatz ist das Gegenteil von Mainstream-Unternehmenssoftware, die endgültige Datenanforderungen vorgibt und erst arbeitet, wenn alle Anforderungen 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), Preisstaffelungen und die geschlossenen Wochen der Lieferanten sind Daten, die häufig in Geschäftssystemen fehlen. Dennoch sind diese Daten aus der Perspektive der supply chain Optimierung wertvoll. Solche Daten könnten in Tabellenkalkulationen und E-Mails verstreut sein, was eine direkte strukturierte Analyse seitens Lokad verhindert. Angesichts dieser Situationen schlagen wir vor, Heuristiken zu verwenden (die von Lokad codiert werden sollen) und ad-hoc Tabellenkalkulationen zu nutzen (die zu Lokad hochgeladen werden sollen). Sobald das numerische Rezept betriebsbereit ist, wird Lokad die IT-Abteilung des Kunden einbinden, um die Daten in das/die Geschäftssystem(e) zu integrieren. Darüber hinaus klärt das numerische Rezept selbst, welche Daten wirklich von Bedeutung sind und in welchem Ausmaß.

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.

Rohtransaktionale Extrakte

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.

Der Versuch, die Daten aufzubereiten, führt unweigerlich zu Datenverlust. Ob dieser Verlust akzeptabel ist oder nicht, hängt von den spezifischen supply chain Entscheidungen ab. Wenn die Daten bereits verloren sind, wenn sie die Lokad Plattform erreichen, kann nichts unternommen werden, um diesen Verlust wiederherzustellen. Rohtransaktionale Extrakte stellen sicher, dass die Gesamtheit der in den Geschäftssystemen verfügbaren Informationen innerhalb von Lokad zugänglich wird.

Darüber hinaus bringt die Datenaufbereitung eine eigene Komplexitätsebene zusätzlich zur Komplexität der Geschäftssysteme selbst mit sich. Zugegeben, das numerische Rezept, das die gewünschte supply chain Optimierung liefert, kann die inhärente Komplexität nicht vermeiden. Wenn jedoch dieses numerische Rezept auch mit der zufälligen Komplexität, die durch vorherige Datenaufbereitung eingeführt wurde, zurechtkommen muss, verwandelt es ein ohnehin schwieriges Problem in ein unzumutbar schwieriges. Rohtransaktionale Extrakte stellen sicher, dass Lokad sich nicht mit einem noch größeren Problem auseinandersetzen muss, als es zu lösen gilt.

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.

Darüber hinaus werden viele schwer zu visualisierende, aber relevante Komplikationen, wie z.B. mehrzeilige Bestellungen, aus Business Intelligence Systemen (wie BI-Cubes) eliminiert. Diese Details sind wertvoll, da sie das Wesentliche von supply chain Situationen widerspiegeln, die angegangen werden müssen.

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.

Letztlich wurden Lokads Systeme so entwickelt, dass sie Daten empfangen und den Kunden ermöglichen, ihre supply chain zu betreiben, ohne sich über diese Belange den Kopf zu zerbrechen. Lokad etabliert eine Daten-Semantik, um diese Probleme anzugehen, und das stellt den herausforderndsten Teil der Datenaufbereitungsphase dar.

Personenbezogene Daten

Eine supply chain Initiative benötigt fast niemals personenbezogene Daten für den Betrieb. Daher empfehlen wir aus supply chain Sicht, personenbezogene Daten als Belastung und nicht als Vermögenswert zu behandeln. Wir raten dringend davon ab, personenbezogene Daten an Lokads Plattform zu übertragen. In der Praxis bedeutet dies in der Regel, die Datenbankspalten herauszufiltern (siehe Diskussion unten), die persönliche Identifikatoren enthalten (z.B. Name, Adresse, Telefonnummer, E-Mail usw.).

Diese persönlichen Identifikatoren können durch undurchsichtige, anonyme ersetzt werden – sofern die Information aus supply chain Sicht relevant ist. Zum Beispiel sind undurchsichtige Kundenkennungen nützlich, da sie Lokad ermöglichen, Muster im Zusammenhang mit Kundenloyalität zu erkennen – wie etwa die negativen Auswirkungen von Lagerengpässen. Im Gegensatz zu den meisten Prognosetechnologien, die nur mit einer Zeitreihenperspektive arbeiten können, kann Lokads Plattform von ultrafeingranularen historischen Daten profitieren, bis hinunter zur Transaktionsebene.

Wenn Sie sich über Lokads Position zu persönlich identifizierbaren Informationen (PII) nicht sicher sind, wird dieses Thema in den Abschnitten 1, 3 und 4 unseres security Dokuments behandelt.

Finanzdaten

Die Geldbeträge für vom Kunden gekaufte, verarbeitete und verkaufte Waren sind von primärer Relevanz für die supply chain Optimierung, die Lokad bietet. Tatsächlich legt Lokad einen finanziellen Fokus auf die supply chain, der dollars of return over percentages of error optimiert.

Im Gegensatz zu Anbietern, die ausschließlich Daten zu Lagerbeständen berücksichtigen, nutzt Lokad die finanziellen Daten eines Kunden – sofern diese zur Verfügung stehen. Logischerweise konzentrieren sich die beunruhigendsten supply chain Kosten an den Extremen; unerwartet hohe Nachfrage führt zu Lagerengpässen und unerwartet geringe Nachfrage zu Inventarabwertungen. Dazwischen rotiert das Inventar einwandfrei. Um Bestandsentscheidungen wirklich zu optimieren, muss daher ein finanzieller Kompromiss in Bezug auf diese Risiken gefunden werden. Lokad verwendet die finanziellen Daten eines Kunden, um einen angemessenen Kompromiss zu berechnen.

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, aus der Sicht eines supply chain Praktikers sind drei Wochen alte Daten uralte Geschichte. Die aus veralteten Daten gewonnenen Ergebnisse sind für aktuelle supply chain Entscheidungen irrelevant. Eine One-Shot-Extraktion würde Ergebnisse basierend auf einem einzigen Schnappschuss der Geschäftshistorie des Kunden liefern, was zu Ergebnissen von begrenztem Wert führt. Zudem müssen supply chain Praktiker das analytische System in Aktion sehen, um Vertrauen in dessen Fähigkeit zu gewinnen, die tägliche Variabilität zu bewältigen.

Zweitens, obwohl die Entwicklung einer hochzuverlässigen Datenpipeline schwierig ist, ist sie den Alternativen vorzuziehen. Eine unzuverlässige Datenpipeline gefährdet die gesamte die Quantitative Supply Chain Initiative, da keine Menge an Analysen grundlegende Datenprobleme beheben kann, wie z.B. den fehlenden Zugang zu aktuellen Lagerbeständen.

In der Regel sind zahlreiche geplante Läufe erforderlich, um den Extraktionsprozess zu perfektionieren, da einige Probleme nur sporadisch auftreten. Der sicherste Weg, diese Probleme zu beheben, besteht darin, die Datenpipeline so früh wie möglich in Betrieb zu nehmen, sodass Lokad Probleme identifizieren und lösen kann. Insbesondere sind geplante Läufe auch eine der sichersten Optionen, um die End-to-End-Leistung der gesamten Prozesskette zu bewerten, einschließlich derjenigen, die zur Bereitstellung empfohlener supply chain Entscheidungen führen.

Drittens, nach unserer Erfahrung ist die häufigste Ursache für verzögerte die Quantitative Supply Chain Initiativen der verspätete Aufbau der Datenextraktions-Pipeline. Wir erkennen an, dass IT-Abteilungen häufig unter großem Druck stehen, viele Projekte gleichzeitig zu realisieren, und der Aufbau einer Datenextraktions-Pipeline eine weitere Aufgabe ist, mit der sie sich auseinandersetzen müssen. Daher ist es verlockend – vor allem für die IT-Abteilung –, den Pipeline-Teil aufzuschieben und stattdessen mit einer Reihe von One-Shot-Extraktionen zu beginnen. Auch wenn dieser Ansatz machbar ist, birgt er das Risiko, Verzögerungen in der Initiative zu verursachen und Lokad daran zu hindern, ganze Klassen potenzieller Probleme so früh wie möglich zu identifizieren (wie im vorherigen Absatz beschrieben).

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 Extraktionsroutine, die ein vollständiges Datenbild bis zum Ende des aktuellen Geschäftstages liefert (z.B. das Extrahieren am Donnerstagabend von allen relevanten historischen Daten bis zum Geschäftsschluss am Donnerstag). Die Datenextraktions-Pipeline läuft am Ende des Arbeitstages, und die analytische Verarbeitung – innerhalb der Lokad Plattform – folgt. Frische Ergebnisse stehen ab dem Beginn des nächsten Geschäftstages zur Verfügung.

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 Datenextraktions-Pipeline wird ab und zu einmal fehlschlagen – unabhängig von Lokad. Nach unserer Erfahrung erleben selbst hervorragende IT-Abteilungen 1-2 Pipeline-Ausfälle pro Jahr. Wenn der tägliche Upload fehlschlägt, ist der letzte Tag der Daten beeinträchtigt. Deckt jeder tägliche Upload nur einen einzelnen Tag ab (ohne Überschneidungen zwischen den Uploads), bleibt Lokad mit einer teilweise korrupten Datenhistorie zurück. Die Korrektur dieser Historie auf Seiten von Lokad erfordert einen zweiten manuellen Eingriff der IT-Abteilung, zusätzlich zur Behebung dessen, was den Betrieb der Datenextraktions-Pipeline ursprünglich verhindert hat. Diese „Datenhistorik-Reparatur“ verzögert sich voraussichtlich um einige Tage, da dies ein ungewöhnlicher Vorgang für die IT-Abteilung ist. In der Zwischenzeit werden die von Lokad gelieferten Ergebnisse negativ beeinflusst, da einige der jüngsten Daten teilweise korrupt sein können.

Im Gegenteil, wenn jeder tägliche Upload die letzten zwei vollständigen Geschäftswoche sowie die aktuelle Woche abdeckt, profitiert ein fehlerhafter täglicher Lauf der Datenextraktions-Pipeline am nächsten Tag von einer vollständigen Wiederherstellung. Da die Datenextraktions-Pipeline Teil der routinemäßigen Abläufe der IT-Abteilung ist, wird der normale Betriebszustand voraussichtlich innerhalb eines Geschäftstages wieder aufgenommen. Diese Wiederherstellung erfordert keine spezifische Interaktion zwischen der IT-Abteilung und entweder dem Support-Personal von Lokad oder den Endanwendern der Lokad-Lösung. Die Datenkorrektur wird automatisch durch die täglichen Überschreibungen im Rahmen des 2+1-Zeitfensters erreicht.

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.

Damit muss, sobald ein Geschäftssystem (z. B. ERP) als relevante Datenquelle für die Initiative eingestuft wurde und vorausgesetzt, dass auf die zugrunde liegende relationale Datenbank zugegriffen werden kann, die spezifische Auswahl der relevanten Tabellen und Spalten identifiziert werden. Viele Geschäftssysteme enthalten Hunderte von Tabellen und Tausende von Spalten, von denen die meisten für die supply chain Initiative irrelevant sind. Als Faustregel gilt, dass für den Start einer supply chain Initiative selten mehr als ein Dutzend Tabellen benötigt werden und nur wenige Dutzend, um einen hohen Grad an Datenabdeckung zu erreichen.

Wenn das Unternehmen Zugang zu einem Experten hat, der mit dem Datenbankschema des Geschäfts vertraut ist, ist die Nutzung dieser Expertise der einfachste Weg, die relevanten Tabellen innerhalb der Datenbank zu identifizieren. Sollte jedoch kein Experte zur Verfügung stehen, kann das Reverse Engineering der Datenbank zur Identifizierung der Interessensbereiche in der Regel innerhalb einer oder zwei Wochen durchgeführt werden (selbst bei einem ziemlich komplexen System). Zusätzlich zur Nutzung jeglicher verfügbarer technischer Dokumentation über das betreffende System schlagen wir vor, mit einer vollständigen Schemaextraktion der Datenbank zu beginnen, einschließlich:

• der Tabellenname
• der Spaltenname
• der Spaltentyp
• die Tabellengröße

Wir schlagen vor, diese Informationen in einer Tabelle zusammenzustellen. Die potenziellen Tabellen können anhand ihrer Namen und Größen identifiziert werden. Wir empfehlen, mit einer genaueren Untersuchung der größten Tabellen zu beginnen, da hier in der Regel die relevantesten Tabellen für eine optimierte supply chain Initiative zu finden sind. Um eine Tabelle zu inspizieren, schlagen wir vor, eine visuelle Überprüfung von einigen Dutzend Datenzeilen durchzuführen. Die Beobachtungen sollten im Verlauf der Arbeit in die Tabelle eingetragen werden.

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 unterstützt Klartext, flache Dateiformate (typischerweise CSV- oder TSV-Formate) sowie Microsoft Excel-Tabellen, sowohl für Lese- als auch für Schreibvorgänge. Der Abschnitt Read and Write Files dokumentiert Lokads I/O-Fähigkeiten. Obwohl Lokad eine recht vielfältige Palette an Formatierungsoptionen unterstützt, 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. Die Lokad-Plattform selbst kann eingesetzt werden, um die Ausgabe der Extraktions-Pipeline zu überwachen und die Integrität, Vollständigkeit und Aktualität der extrahierten Daten zu bewerten. Daher empfehlen wir, als allererster Schritt der Pipeline innerhalb von Lokad Dashboards zur Datenqualität zu implementieren. Diese Dashboards sind für die IT-Abteilung vorgesehen (obgleich nicht zwingend deren Verantwortung). Ihr gemeinsamer Zweck besteht darin, etwaige Datenprobleme aufzuzeigen und die letztendliche Behebung durch die IT-Abteilung zu beschleunigen. Diese Umsetzung, wie auch der Rest des numerischen Rezepts, das die optimierte supply chain Initiative antreibt, soll idealerweise von einem Supply Chain-Experten, möglicherweise vom Lokad-Team (im Falle eines Platform+Experts-Abonnements), durchgeführt werden.

Spezifikation der Datenextraktion

Sobald die Datenextraktions-Pipeline stabilisiert ist, empfehlen wir, eine Spezifikation für die Datenextraktion zu erstellen. Dieses Dokument sollte alle erwarteten Dateien und deren Spalten sowie den Zeitplan für die Datenextraktion auflisten. Die Stabilisierung der Datenpipeline wird voraussichtlich innerhalb von sechs Monaten nach Beginn der Initiative erfolgen. Dieses Dokument sollte gemeinsam von der IT-Abteilung und der supply chain Abteilung abgestimmt werden. Es enthält die Details zu den Daten, die zeitgerecht von der IT-Abteilung der Lokad-Plattform zur Verfügung gestellt werden sollen.

Das Datenformat kann zu einem späteren Zeitpunkt noch überarbeitet werden, aber es wird erwartet, dass die IT-Abteilung die supply chain Abteilung vor jeglicher Änderung des Datenformats oder des zugehörigen Zeitplans informiert. Im Allgemeinen sollte man, sobald die Spezifikation vereinbart wurde, davon ausgehen, dass der Betrieb der supply chain für Produktionszwecke auf der Integrität der Datenextraktion beruht. Daher sollte im Falle von Änderungen die supply chain Abteilung mit einer angemessenen „Nachfrist“ rechnen, die ausreicht, um die Logik innerhalb von Lokad anzupassen (um das überarbeitete Datenformat zu berücksichtigen).

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.

Feedback Loop

Die supply chain Entscheidungen (z. B. Bestandsauffüllungen), die innerhalb der Lokad-Plattform generiert werden, können als flache Dateien exportiert und in die Geschäftssystem(e) reintegriert werden. Dieser Mechanismus wird als Feedback Loop bezeichnet. Unsere Erfahrung zeigt, dass der Feedback Loop wahrscheinlich nicht innerhalb der ersten vier Monate nach dem Start der Initiative implementiert wird. Das Vertrauen in das numerische Rezept, das es ermöglicht, auch nur einen Teil der supply chain im Autopilotmodus laufen zu lassen, ist erheblich und benötigt mehrere Monate, um aufgebaut zu werden. Daher stellt der Feedback Loop zu Beginn der Initiative kein Problem dar.

Nach unserer Erfahrung ist die Einrichtung des Feedback Loop eine wesentlich kleinere Herausforderung als die Einrichtung der Datenextraktions-Pipeline. Beispielsweise sind die in Lokad erzeugten Zahlen als maßgeblich und endgültig anzusehen; falls weitere Regeln angewendet werden müssen, um diese Zahlen in umsetzbare Werte umzuwandeln (z. B. angewandte MOQs), ist das numerische Rezept unvollständig und muss auf der Lokad-Seite korrigiert werden. Andererseits ist die Plattform von Lokad in der Lage, jede Form von Daten zu verarbeiten und zu erzeugen, solange sie in einem vernünftig tabellarischen Format vorliegen. Dadurch spiegelt die Einfachheit des Feedback Loop die Einfachheit der supply chain Entscheidungen wider. Beispielsweise kann es Dutzende von Einschränkungen geben, die definieren, ob eine gegebene Bestellung gültig ist oder nicht, doch der Inhalt der finalen Bestellung ist eine einfache Liste von Mengen, die den Artikelnummern zugeordnet sind.

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 der Feedback Loop definitionsgemäß Daten umfasst, die sich auf reale supply chain Operationen beziehen, empfehlen wir, eine eigene Spezifikation für diesen Prozess zu erstellen. Diese Spezifikation spiegelt die der Datenextraktion wider, allerdings mit Daten, die in die entgegengesetzte Richtung übertragen werden. Auch dieses Dokument sollte gemeinsam von der IT- und der supply chain Abteilung abgestimmt werden.