Die Datenextraktionspipeline

Dieses Dokument soll IT-Abteilungen als Leitfaden dienen, um eine Pipeline zu erstellen, die Daten aus bestehenden Geschäftssystemen extrahiert und diese Daten in der Plattform von Lokad verfügbar macht. Der Aufbau einer Datenpipeline ist eine der frühesten Phasen einer quantitativen Supply Chain-Initiative. Das Dokument umfasst den von Lokad empfohlenen Ansatz, einschließlich des Umfangs der zu extrahierenden und auf der Lokad-Plattform verfügbaren Daten, des Datenformats und der Datenübertragungsstrategien.

Motivation und Kontext

Lokad definiert eine quantitative Supply Chain-Initiative als eine, die ein numerisches Rezept liefert, das Entscheidungen (oder zumindest Empfehlungen) im Angesicht von Herausforderungen in der Supply Chain automatisiert. Lokad verfügt über eine programmatische Plattform, die für die Lösung von prädiktiven Optimierungsproblemen im Zusammenhang mit der Supply Chain entwickelt wurde.

Typische Probleme sind:

• Entscheidung der Bestandsmengen zur Auffüllung
• Entscheidung der Bestandsmengen zur Produktion
• Entscheidung, ob die Preise erhöht oder gesenkt werden sollen
• Entscheidung, ob Bestände im Netzwerk verschoben werden sollen

Wenn das Unternehmen diese Entscheidungen optimiert, kann es in der Regel seine Betriebskosten senken, den Bedarf an Betriebskapital verringern und die Servicequalität erhöhen. Mindestens sollte das Unternehmen in der Lage sein, diese Mischung aus Kosten, Bargeld und Service so anzupassen, dass sie besser mit seiner gesamten Supply Chain-Strategie übereinstimmt.

Das numerische Rezept, das das interessierende Problem angeht, soll in Lokad implementiert werden. Daher erfordert das numerische Rezept, dass relevante Unternehmensdaten in der Plattform von Lokad 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 unterschiedlich sind, sind die relevanten Eingangsdaten sehr ähnlich und werden in der Regel über die Kerntransaktionshistorie des Unternehmens (z. B. historische Verkäufe) abgewickelt.

Die IT-Abteilung des Kunden ist in der Regel für die Einrichtung und Wartung der Datenextraktionspipeline verantwortlich. In den kommenden Abschnitten wird detailliert erläutert, was speziell von der IT-Abteilung benötigt wird.

Sobald die Datenextraktionspipeline erstellt ist, sind die auf der Lokad-Seite tätigen Ingenieure - als Supply Chain Scientists bezeichnet - für die Einrichtung und Wartung des numerischen Rezepts verantwortlich. Diese Ingenieure werden häufig von Lokad als Teil einer “Plattform+Experten”-Servicevereinbarung bereitgestellt, aber es ist auch möglich, diese Kompetenz intern beim Kunden zu verankern. Selbst wenn solche Ingenieure im Unternehmen tätig sind, empfehlen wir, sie in die Supply Chain-Abteilung und nicht in die IT-Abteilung zu integrieren.

Unabhängig davon, ob dieser Teil der Supply Chain-Initiative ausgelagert ist oder nicht, bleibt die in diesem Dokument skizzierte Perspektive dieselbe.

Technische Perspektive auf hoher Ebene

Lokad ist eine analytische Ebene, die auf den vorhandenen Transaktionssystemen des Kunden arbeitet. Mit anderen Worten, Lokad ersetzt nicht das ERP-System; es ergänzt es um prädiktive Optimierungsfunktionen, die realistischerweise nicht als Teil eines traditionellen Transaktionssystems implementiert werden können.

Jedes Lokad-Konto verfügt über ein Dateisystem, auf das über die SFTP- und FTPS-Protokolle zugegriffen werden kann. Eine Web-Schnittstelle ist ebenfalls verfügbar, obwohl diese Schnittstelle in der Regel nicht für unser IT-Publikum gedacht ist (sondern für die Bereitstellung von Dashboards für Nicht-Spezialisten). Wir erwarten, dass die relevanten Daten, die in der Regel aus den Kerntransaktionssystemen des Unternehmens extrahiert werden, als Flachdateien exportiert (mehr dazu unten) und in das Dateisystem von Lokad hochgeladen werden.

Sofern nicht anders vereinbart, ist die IT-Abteilung des Kunden für alles verantwortlich, was die Daten betrifft, bis die Flachdateien in das Dateisystem von Lokad hochgeladen werden. Das Plattformdesign von Lokad ist so konzipiert, dass es partielle Datenextraktionsfehler verarbeiten kann (mehr dazu unten), daher hat die IT-Abteilung in dieser Hinsicht einen gewissen Spielraum.

Sobald die Daten für Lokad verfügbar sind, werden sie von einer Reihe von Envision-Skripten verarbeitet (Envision ist die domänenspezifische Programmiersprache, die von Lokad entwickelt wurde) und generieren die optimierten Supply-Chain-Entscheidungen von Interesse.

Es gibt mehrere praktische Anwendungen für solche Datenextraktionen, von denen viele über die Supply-Chain-Optimierungsinitiative von Lokad hinausgehen. Marketing-, Finanz- und Vertriebsteams - um nur drei zu nennen - können potenzielle Nutznießer der von Lokad verarbeiteten historischen Verkaufsdaten sein. Aus diesem Grund empfiehlt Lokad, die Transaktionsdaten in eine dedizierte Servicierungsschicht - einen “Datensee” - zu konsolidieren, der ausschließlich für die Bereitstellung solcher Daten an geeignete Teams und Analyse-Systeme von Drittanbietern (wie Lokads Plattform) reserviert ist.

Die Erstellung eines Datensees ist keine Voraussetzung für die Verwendung von Lokad, sondern eine potenzielle Architektur, die den Betrieb für das Unternehmen erleichtert. Es ist erwähnenswert, dass ein Datensee auch das Entstehen einer “Datenpraxis” innerhalb eines Unternehmens erleichtert - sofern eine solche Praxis noch nicht vorhanden ist.

Der Umfang relevanter Daten

Die Supply Chain optimiert Entscheidungen im Zusammenhang mit dem Fluss von physischen Gütern (Einkauf, Transport, Produktion, Verkauf usw.). Daher sind die relevantesten Daten für eine prädiktive Optimierungsinitiative fast immer die Daten, die die innerhalb des Unternehmens stattfindenden Flüsse beschreiben. Diese Daten finden sich in der Regel in den Transaktionssystemen des Kunden.

Wie bereits erwähnt, ist die Plattform von Lokad in ihren Verarbeitungsmöglichkeiten recht flexibel, daher gibt es keine harten Anforderungen an die Daten. Wahrscheinlich wird der Kunde viele der unten aufgeführten Datenpunkte nicht bereitstellen können, und Lokad ist in der Lage, innerhalb solcher Einschränkungen zu arbeiten. Die folgende Liste versucht daher, so umfassend wie möglich hilfreiche Datenquellen zu identifizieren, ohne die strikte Bereitstellung jeder einzelnen zu erfordern.

Produktkatalog: Die Liste der Produkte (oder Artikel, Teile), die das Unternehmen kauft, umwandelt, montiert und/oder verkauft. Diese Liste ist wichtig, weil viele Entscheidungen auf der “Produkt”-Ebene getroffen werden. Die Hierarchie (z.B. Kategorien, Familien, Unterfamilien), falls vorhanden, ist relevant - sowohl für Berichtszwecke als auch für analytische Zwecke. Strukturierte Attribute (z.B. Farbe, Größe, Gewicht, Form), die die Produkte qualifizieren, sind ebenfalls nützlich. Als Faustregel gilt: Alle Daten, die die Produkte aus Sicht der Supply Chain beschreiben, sind relevant. Beziehungen zwischen Produkten - wie Stücklisten (Bills of Materials) - sind ebenfalls relevant.

Verkaufsauftragsverlauf: Die Liste der historischen Verkaufsaufträge des Kunden. Diese Liste ist wichtig, weil Verkäufe fast immer der beste Indikator für die Marktnachfrage des Unternehmens sind. Diese Daten sollten die mit den Transaktionen verbundenen Geldbeträge enthalten, da die Supply Chain-Optimierung aus finanzieller Sicht durchgeführt werden sollte. (Diese finanzielle Perspektive wird später noch ausführlicher behandelt.) Wenn möglich, ist es (immer) vorzuziehen, Rohbestelltransaktionen anstelle von täglichen/wöchentlichen/monatlichen Aggregaten bereitzustellen. (Dieser Punkt wird weiter unten ebenfalls ausführlicher erläutert.) Der Verkaufsauftragsverlauf kann zurückgestellte Aufträge, stornierte Aufträge, verschobene Aufträge, geänderte Aufträge, Rücksendungen usw. umfassen, die alle potenziell relevante Datenpunkte sind. Wenn Kunden in diesen Daten identifiziert werden, sind die anonymisierten Kundenkennungen relevant. (Personenbezogene Daten haben ihren eigenen Abschnitt unten.)

Bestellungen: Die Liste der historischen Bestellungen des Kunden sowie der ausstehenden Bestellungen (die noch nicht eingegangen sind). Diese Liste ist wichtig, weil Bestellungen fast immer der beste Indikator für die Lieferzeiten und die Qualität der Lieferanten sind. Ausstehende Bestellungen spiegeln den “Lagerbestand in Bestellung” wider. Die Bestellungen sollten auch die mit den Transaktionen verbundenen Geldbeträge enthalten. Wenn möglich, ist es auch (immer) vorzuziehen, die Rohbestellhistorie anstelle von Aggregaten bereitzustellen. Die Bestellhistorie sollte, sofern verfügbar, die relevanten Daten enthalten: Bestelldatum, Versanddatum, Lieferdatum usw.

Produktionsaufträge: Die Liste der historischen Produktionsaufträge des Kunden (falls zutreffend) und der ausstehenden Produktionsaufträge (die noch nicht ausgeführt wurden). Diese Liste ist wichtig, weil diese Aufträge den Transformationsfluss der Güter innerhalb des Unternehmens widerspiegeln und es uns ermöglichen, Engpässe in der Supply Chain zu identifizieren. Je nach Situation kann die Produktion variable Erträge haben oder manchmal Chargen aufgrund von Qualitätsproblemen verworfen werden. Diese Ereignisse sind relevant.

Bestandsbewegungen: Die Liste der historischen Bestandsbewegungen des Kunden, wenn mehrere Standorte vorhanden sind. Diese Liste ist wichtig, weil sie Aufschluss über den Ursprung des zur Auslösung von Produktionsprozessen oder zur Bedienung von Kunden verwendeten Bestands gibt. Je nach Situation können die Lieferzeiten für diese Bewegungen variabel sein. In diesem Fall sind auch die Details der Daten (Datum des Überweisungsauftrags, Versanddatum, Empfangsdatum) relevant.

Bestandsniveaus: Die Liste aller SKUs (Stock-Keeping Unit) des Kunden mit ihrem aktuellen Bestandsniveau. Diese Liste ist wichtig, weil sie den aktuellen Zustand der Supply Chain charakterisiert. Je nach Branche kann die Darstellung des Inventars komplexer sein als einfache SKU-Niveaus. Ablaufdaten können ebenfalls vorhanden sein. Ein Teil oder der gesamte Bestand kann auf der Seriennummerebene verfolgt werden. Wenn Serieninventar verwendet wird, ist die gesamte Liste der Seriennummern und ihrer zugehörigen Standorte relevant. Allgemeiner gesagt sind alle Elemente, die den aktuellen Zustand der vom Unternehmen gehaltenen Bestandsvermögenswerte beschreiben, relevant.

Preisschilder: Die Liste der vom Kunden angewendeten Preise beim Service der Waren (und möglicherweise der zugehörigen Dienstleistungen). Diese Liste ist wichtig, weil die aktuelle Preispolitik des Kunden von dem abweichen kann, was er früher berechnet hat. Neuere Preise wirken sich auf die zukünftige Nachfrage, aber auch auf die Rentabilität der Entscheidungen in der Supply Chain aus. Aktionen, Preisnachlässe oder Preisoptionen können ebenfalls vorhanden sein. Alle Elemente, die zur Berechnung dessen beitragen, was den Kunden in Rechnung gestellt wird, sind relevant.

Momentaufnahmen vergangener Bestandsniveaus, vergangener Preisschilder und ausstehender Einkaufsaufträge sind auch für die meisten Zwecke der Supply Chain relevant (diese Daten sind jedoch selten in Geschäftssystemen verfügbar). Sobald eine Datenextraktionspipeline vorhanden ist, können solche Momentaufnahmen innerhalb von Lokad selbst implementiert werden - ohne direktes Eingreifen der IT-Abteilung des Kunden.

Obwohl diese Liste bereits umfangreich ist, gibt es in Unternehmen in der Regel noch weitere relevante Datenquellen, die hier nicht aufgeführt sind. Als Faustregel gilt: Wenn eine Information für die Supply Chain-Abteilung nützlich ist, ist sie höchstwahrscheinlich auch für die Zwecke der vorausschauenden Optimierung relevant und sollte an Lokad weitergeleitet werden.

Priorisierte Struktur der vorbereiteten Daten

Die oben genannte Liste der potenziell relevanten Datenbanken soll nicht überwältigen. In der Praxis ist es wichtig zu identifizieren, welche Tabellen erforderlich sind, um die Initiative in die Produktion zu bringen, im Gegensatz zu denen, die nice to have sind. Es ist auch wichtig, Extraktionen ordnungsgemäß zu priorisieren, um den Supply Chain-Wissenschaftlern den Übergang von der Datenextraktionsphase in die Optimierungsphase zu ermöglichen.

Daher empfiehlt Lokad als Teil unserer Supply Chain-Praxis, dass die Supply Chain-Wissenschaftler ein priorisiertes Schema der vorbereiteten Daten erstellen und dieses Dokument zu Beginn der Initiative mit der IT-Abteilung des Kunden teilen. In diesem Dokument werden die Tabellen - und ihre Felder - aufgelistet, die am Ende des Datenbereitstellungssegments verfügbar sein sollen. In diesem Dokument werden auch die jeweiligen Prioritäten aller angeforderten Felder aufgelistet.

Dieses Schema stellt eine Wunschliste auf hoher Ebene für die zu extrahierenden Daten dar. Dieses Dokument sollte jedoch nicht als Spezifikation für die in der Datenextraktionsphase generierten Dateien missverstanden werden. Die Supply Chain-Wissenschaftler sind für die Datenbereitstellung verantwortlich. Es ist akzeptabel (und üblich), wenn sich das Schema der Daten, wie es von der Datenextraktionspipeline zur Verfügung gestellt wird, erheblich von dem “idealisierten” Schema unterscheidet, das mit den vorbereiteten Daten verbunden ist. Dieser Punkt wird weiter unten im Abschnitt “Rohdatenextrakte” ausführlicher behandelt.

Historische Tiefe der Daten

Wenn es um die historische Tiefe der zu extrahierenden Daten geht, gibt es in der Regel zwei unterschiedliche Anliegen. Erstens, wie weit in die Vergangenheit sollte die Datenextraktion gehen? Zweitens, welche minimale historische Tiefe ist für den Erfolg der Supply Chain-Initiative erforderlich?

Im Allgemeinen empfehlen wir, die gesamte verfügbare Historie für alle Tabellen zu extrahieren, die weniger als 1 Milliarde Zeilen haben. Das Bearbeiten der Historie bedeutet, dass Daten verloren gehen können, die für die Bewertung der langfristigen Entwicklung der Supply Chain relevant sein könnten. Filter werden ohnehin seitens Lokad als Teil der Datenbereitstellung implementiert, sodass das Übertragen von mehr Daten nicht unbedingt zu mehr Rechenressourcen für 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 geschätzt werden. Diejenigen, die vor der Lokad-Initiative die Entscheidungen von Interesse treffen müssen, sind jedoch durch die gleichen Einschränkungen gebunden. Das numerische Rezept von Lokad wird so implementiert, dass es von der verfügbaren Historientiefe profitiert, auch wenn sie für den Kunden möglicherweise spärlich erscheint.

Fehlende Daten

Moderne Geschäftssysteme sind in der Regel umfangreich, es fehlen jedoch immer wieder Daten. Wenn Daten als fehlend angesehen werden, wird die Machbarkeit der quantitativen Supply Chain-Initiative in Frage gestellt. Unabhängig davon, wie viele Daten “fehlen”, schaffen es Mitarbeiter in der Organisation immer noch, die für den Betrieb der Supply Chain erforderlichen Entscheidungen zu treffen. Kurz gesagt, es gibt einen Weg. Der technologische Ansatz von Lokad beruht darauf, das Beste aus dem zu machen, was vorhanden ist - genauso wie Mitarbeiter es tun. Dieser Ansatz steht im Gegensatz zur Mainstream-Unternehmenssoftware, die endgültige Datenanforderungen mitbringt und nicht funktioniert, es sei denn, alle Anforderungen werden erfüllt.

Unsere Erfahrung zeigt, dass zwei große Kategorien von “fehlenden” Daten unterschieden werden sollten: erstens Daten, die in das Geschäftssystem integriert werden sollten, und zweitens Daten, von denen angenommen wird, dass sie für das Analyse-System (wie Lokad) sehr nützlich sind.

Mindestbestellmengen (MOQs), Preisstaffelungen und geschlossene Wochen der Lieferanten sind Daten, die in Geschäftssystemen häufig fehlen. Diese Daten sind jedoch aus Sicht der Supply Chain-Optimierung wertvoll. Solche Daten können über Tabellenkalkulationen und E-Mails verstreut sein, was eine direkte strukturierte Analyse seitens Lokad verhindert. In solchen Situationen empfehlen wir die Verwendung von Heuristiken (die von Lokad codiert werden sollen) und die Verwendung von ad-hoc-Tabellenkalkulationen (die an Lokad hochgeladen werden sollen). Sobald das numerische Rezept einsatzbereit 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 wichtig sind und in welchem Umfang.

Wettbewerbsdaten wie die Preise der Mitbewerber gelten als sehr nützlich, aber in unserer Erfahrung ist dies nicht selbstverständlich. Es ist bekannt, dass das Erlangen solcher Daten oft mit erheblichen Kosten verbunden ist, sonst würden Unternehmen dies bereits tun. Aus diesem Grund ist es keine Anforderung, solche Daten bereitzustellen. In jedem Fall wird das numerische Rezept von Lokad dazu dienen, die tatsächlichen finanziellen Gewinne im Zusammenhang mit zusätzlichen Daten zu einem späteren Zeitpunkt zu bewerten.

Rohdatenextrakte von Transaktionen

Wir empfehlen nachdrücklich, die ursprüngliche Form der Daten beizubehalten. Die an Lokad übermittelten Daten sollten nichts anderes als Rohkopien der Originaltabellen und -spalten sein, wie sie in den RDBMS des Unternehmens für die Geschäftssysteme gefunden werden. Die gesamte Datenbereitung sollte an die Lokad-Plattform delegiert werden, die speziell für die Datenbereitung entwickelt wurde.

Der Versuch, die Daten vorzubereiten, führt zwangsläufig zu Datenverlusten. Ob dieser Verlust akzeptabel ist oder nicht, hängt von den spezifischen Supply Chain-Entscheidungen von Interesse ab. Wenn die Daten bereits verloren sind, wenn sie die Plattform von Lokad erreichen, kann nichts unternommen werden, um diesen Verlust wiederherzustellen. Rohdatenextrakte von Transaktionen stellen sicher, dass die gesamte in den Geschäftssystemen verfügbare Information innerhalb von Lokad zugänglich wird.

Darüber hinaus führt die Datenbereitung zu einer zusätzlichen Komplexität, die über die Komplexität der Geschäftssysteme selbst hinausgeht. Zugegeben, das numerische Rezept, das die gewünschte Supply Chain-Optimierung liefert, kann nicht umhin, sich mit Klassen intrinsischer Komplexität auseinanderzusetzen. Wenn dieses numerische Rezept jedoch auch mit der zufälligen Komplexität umgehen muss, die durch vorherige Datenbereitung eingeführt wird, wird aus einem bereits schwierigen Problem ein unvernünftig schwieriges Problem. Rohdatenextrakte von Transaktionen stellen sicher, dass Lokad nicht mit einem noch größeren Problem konfrontiert wird, als das, das gelöst werden muss.

Von einem IT-Standpunkt aus betrachtet sind Rohdatenextrakte von Transaktionen einfach. Es sollten einfache Tabellenkopien verwendet werden (z. B. SELECT * FROM MyTable), was die einfachste Form von Abfragen über eine relationale Datenbank ist. Solche Abfragen sind einfach, da keine Filter beteiligt sind, und leistungsfähig, da kein Join beteiligt ist. Sehr große Tabellen erfordern jedoch etwas besondere Aufmerksamkeit. Dieser Punkt wird weiter unten behandelt.

Wenn ein Data Lake vorhanden ist, sollte der Data Lake die relationalen Daten spiegeln, wie sie in den Geschäftssystemen gefunden werden. Alle gängigen Datenbanksysteme verfügen über integrierte Spiegelungsfunktionen. Wir empfehlen, diese Funktionen bei der Einrichtung des Data Lakes zu nutzen. Darüber hinaus ist die Spiegelung von Daten wesentlich einfacher als die Datenbereitung - insbesondere aus Sicht der IT-Abteilung, da die Datenbereitung stark von dem spezifischen Problem abhängt, das gelöst werden soll.

Das BI-Extrakt-Antipattern

Die Daten, die an Lokad gesendet werden sollen, sollten nicht aus einer sekundären Quelle stammen (z. B. einem Business Intelligence (BI)-System), in dem die Daten bereits umfangreich modifiziert wurden, in der Regel zum Vorteil der direkten Endbenutzer-Nutzung. Obwohl das Extrahieren von Daten aus einem BI-System einfacher ist als aus einem ERP, führt dies zwangsläufig zu unlösbaren Problemen in der Zukunft. Durch das Design gehen die transaktionalen Aspekte der Daten verloren, da die Daten in tägliche / wöchentliche / monatliche Zeitreihen aggregiert werden.

Darüber hinaus werden viele schwer zu visualisierende, aber relevante Komplikationen, wie zum Beispiel mehrzeilige Aufträge, aus Business Intelligence-Systemen (wie BI-Cubes) eliminiert. Diese Details sind wertvoll, da sie die Essenz von Supply Chain-Situationen widerspiegeln, die angegangen werden müssen.

Schlechte Daten

In Lokads Erfahrung sind Fälle von schlechten Daten selten. Im Gegenteil, transaktionale Geschäftssysteme (wie ERPs) haben in der Regel genaue Daten. Falsche Einträge von Transaktionsdaten sind selten und treten in der Regel einmal oder zweimal pro 1000 Einträge auf. Bei Verwendung von Barcodes oder ähnlichen Geräten ist die Fehlerquote noch geringer. Das eigentliche Problem liegt in der Software, die falsche Annahmen über die Daten trifft, nicht darin, dass die Daten selbst schlecht sind.

Die Lagerbestände in Filialen großer B2C-Einzelhandelsnetze sind fast immer ungenau. Aus Lokads Sicht handelt es sich jedoch bei dieser Situation um rauschende Daten, nicht um schlechte Daten. Wenn solche Lagerbestände (fälschlicherweise) als präzise angesehen werden, ergeben die Ergebnisse keinen Sinn. Wir betrachten diese spezielle Situation mit einer probabilistischen Sichtweise auf Lagerbestände und akzeptieren die Unsicherheit anstatt sie zu ignorieren.

Letztendlich wurden die Systeme von Lokad so konzipiert, dass sie Daten empfangen und dem Kunden ermöglichen, seine Supply Chain ohne Sorgen um diese Probleme zu betreiben. Lokad etabliert eine datensemantische Lösung, um diese Probleme anzugehen, und dies stellt den anspruchsvollsten Teil der Datenbereitung dar.

Persönliche Daten

Eine Supply Chain-Initiative benötigt fast nie persönliche Daten, um zu funktionieren. Daher empfehlen wir aus Supply Chain-Sicht, persönliche Daten als Haftung und nicht als Vermögenswert zu behandeln. Wir raten dringend von der Übertragung persönlicher Daten auf die Plattform von Lokad ab. In der Praxis bedeutet dies in der Regel, dass die Datenbankspalten (siehe Diskussion unten) herausgefiltert werden, die persönliche Identifikatoren enthalten (z. B. Name, Adresse, Telefonnummer, E-Mail usw.).

Diese persönlichen Identifikatoren können durch undurchsichtige anonyme Identifikatoren ersetzt werden - wenn die Informationen aus Supply Chain-Sicht relevant sind. Zum Beispiel sind undurchsichtige Kundenidentifikatoren nützlich, da sie Lokad ermöglichen, Muster im Zusammenhang mit Kundenloyalität zu identifizieren - wie zum Beispiel die negative Auswirkung von Lagerbeständen. Im Gegensatz zu den meisten Prognosetechnologien, die nur mit einer Zeitreihenperspektive arbeiten können, kann die Plattform von Lokad ultra-granulare historische Daten nutzen, bis hin zur Transaktionsebene.

Wenn Sie sich nicht sicher sind, wie Lokad zu personenbezogenen Daten (PII) steht, wird dieses Thema in den Abschnitten 1, 3 und 4 unseres Sicherheitsdokuments behandelt.

Finanzdaten

Die monetären Beträge für vom Kunden gekaufte, umgewandelte und verkaufte Waren sind von größter Bedeutung für die von Lokad bereitgestellte Optimierung der Supply Chain. Tatsächlich legt Lokad den Schwerpunkt auf eine finanzielle Perspektive der Supply Chain, die Dollar-Rendite vor Fehlerprozenten optimiert.

Im Gegensatz zu Anbietern, die nur Daten zu Lagerbeständen berücksichtigen, verwendet Lokad die finanziellen Daten eines Kunden - sofern verfügbar. Logischerweise konzentrieren sich die meisten belastenden Kosten der Supply Chain auf die Extreme; unerwartet hohe Nachfrage führt zu Lagerbeständen; und unerwartet niedrige Nachfrage führt zu Inventurabschreibungen. Dazwischen rotiert der Bestand problemlos. Um also wirklich optimale Bestandsentscheidungen zu treffen, muss ein finanzieller Kompromiss in Bezug auf diese Risiken eingegangen werden. Lokad nutzt die finanziellen Daten eines Kunden, um einen angemessenen Kompromiss zu berechnen.

Datenpipeline vs. einmalige Extraktion

Eine Datenextraktionspipeline aktualisiert automatisch die an Lokad übertragenen Daten. Dieser Aufbau erfordert einen größeren Aufwand als eine einmalige Datenextraktion. Wenn möglich, empfehlen wir dringend, die Datenextraktion zu automatisieren, möglicherweise mit einem gestaffelten Ansatz, wenn die Anzahl der relevanten Tabellen groß ist. Diese Automatisierung funktioniert am besten, wenn sie von Tag 1 an installiert wird. Teilweise einmalige Extraktionen zur Identifizierung relevanter Tabellen können jedoch nützlich sein. Dieser Punkt wird in den folgenden Abschnitten erläutert.

Es gibt drei Hauptgründe, die für einen Datenpipeline-Ansatz sprechen.

Erstens ist aus der Sicht des Supply Chain-Praktikers eine 3 Wochen alte Datenbasis längst überholt. Die Ergebnisse, die aus veralteten Daten gewonnen werden, sind für die heutigen Supply Chain-Entscheidungen irrelevant. Eine einmalige Extraktion würde Ergebnisse auf der Grundlage eines einzigen Schnappschusses der Geschäftshistorie des Kunden liefern. Dies würde Ergebnisse von begrenztem Wert erzeugen. Darüber hinaus müssen Supply Chain-Praktiker das analytische System in Aktion sehen, um Vertrauen in seine Fähigkeit zur Bewältigung der täglichen Variabilität zu gewinnen.

Zweitens ist es zwar schwierig, eine hochzuverlässige Datenpipeline zu konstruieren, aber es ist dennoch vorzuziehen. Eine unzuverlässige Datenpipeline gefährdet die gesamte quantitative Supply Chain-Initiative, da keine Analytik grundlegende Datenprobleme beheben kann, wie z. B. keinen Zugriff auf aktuelle Lagerbestände zu haben.

In der Regel sind zahlreiche geplante Durchläufe erforderlich, um den Extraktionsprozess zu perfektionieren, da einige Probleme nur intermittierend auftreten. Der sicherste Weg, diese Probleme zu beheben, besteht darin, die Datenpipeline so früh wie möglich zu starten, damit Lokad Probleme identifizieren und lösen kann. Insbesondere geplante Durchläufe sind auch eine der sichersten Optionen, um die End-to-End-Leistung der gesamten Sequenz von Prozessen zu bewerten, einschließlich derjenigen, die zur Bereitstellung empfohlener Supply Chain-Entscheidungen führen.

Drittens ist unserer Erfahrung nach die häufigste Ursache für verzögerte quantitative Supply Chain-Initiativen die späte Einrichtung der Datenextraktionspipeline. Wir erkennen an, dass IT-Abteilungen häufig unter großem Druck stehen, viele Projekte zu liefern, und der Aufbau einer Datenextraktionspipeline ist eine weitere Aufgabe, mit der sie sich auseinandersetzen müssen. Daher ist es verlockend - für die IT-Abteilung -, den Pipeline-Teil zu verschieben und stattdessen mit einer Reihe von einmaligen Extraktionen zu beginnen. Obwohl dieser Ansatz machbar ist, birgt er das Risiko von Verzögerungen bei der Initiative und verhindert, dass Lokad mögliche Problemeklassen so früh wie möglich identifiziert (wie im vorherigen Absatz beschrieben).

Häufigkeit der Datenextraktion

Wir empfehlen, alle Datenpipelines - sowohl die Extraktionssegmente als auch die Analysesegmente - mindestens einmal täglich zu aktualisieren, auch wenn es sich um monatliche oder vierteljährliche Berechnungen handelt. Dies mag kontraintuitiv erscheinen, aber unserer Erfahrung nach 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 Geschäftstages liefert (z. B. Extraktion am Donnerstagabend aller relevanten historischen Daten bis zum Geschäftsschluss am Donnerstag). Die Datenextraktionspipeline läuft am Ende des Arbeitstages und die analytische Verarbeitung - innerhalb der Lokad-Plattform - folgt. Frische Ergebnisse stehen ab dem Beginn des nächsten Arbeitstages zur Verfügung.

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

Wenn die Daten zu groß sind, um sie täglich vollständig in Lokad hochzuladen, 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 beiden vollständigen Wochen sowie die aktuelle Woche. Das Befolgen dieser Regel ist wichtig, um die hohe Zuverlässigkeit der Lokad-Lösung sicherzustellen.

Die Datenextraktionspipeline wird gelegentlich fehlschlagen - unabhängig von Lokad. Unsere Erfahrung zeigt, dass selbst ausgezeichnete IT-Abteilungen 1-2 Pipeline-Ausfälle pro Jahr haben. Wenn der tägliche Upload fehlschlägt, ist der letzte Tag der Daten kompromittiert. Wenn jeder tägliche Upload nur einen Tag abdeckt (keine Überlappung zwischen den Uploads), hat Lokad eine teilweise beschädigte Datenhistorie. Das Beheben dieser Historie erfordert eine zweite manuelle Intervention der IT-Abteilung, zusätzlich zur Behebung dessen, was die Datenextraktionspipeline daran gehindert hat, ordnungsgemäß zu funktionieren. Diese “Datenhistorienkorrektur” wird wahrscheinlich um einige Tage verzögert - da dies eine ungewöhnliche Operation für die IT-Abteilung ist. In der Zwischenzeit sind die von Lokad zurückgegebenen Ergebnisse negativ beeinflusst, da einige aktuelle Daten teilweise beschädigt sind.

Im Gegensatz dazu profitiert ein fehlgeschlagener täglicher Lauf der Datenextraktionspipeline, wenn jeder tägliche Upload die letzten beiden vollständigen Geschäftswochen sowie die aktuelle Woche abdeckt, von einer vollständigen Wiederherstellung am nächsten Tag. Da die Datenextraktionspipeline Teil der Routineoperationen ist, die von der IT-Abteilung abgedeckt werden, wird die Wiederaufnahme des normalen Betriebszustands voraussichtlich innerhalb eines Arbeitstages erfolgen. Diese Wiederherstellung erfordert keine spezifische Interaktion zwischen der IT-Abteilung und dem Support-Team von Lokad oder den Endbenutzern der Lokad-Lösung. Die Datenkorrektur wird automatisch durch die Überschreibungen geliefert, die im Rahmen des 2+1-Zeitfensters täglich erfolgen.

Die 2+1-Regel spiegelt einen Kompromiss auf der Grundlage der Erfahrung von Lokad wider: Je länger das Zeitfenster ist, desto widerstandsfähiger wird die Datenextraktionspipeline gegenüber vorübergehenden Problemen. Obwohl wir hoffen können, dass Probleme mit der Datenextraktionspipeline innerhalb eines Arbeitstages gelöst werden können, hat die IT-Abteilung möglicherweise dringendere Probleme. Tatsächlich kann die fehlerhafte Datenextraktionspipeline nur ein Symptom für ein schwerwiegenderes Problem sein, das die IT-Abteilung priorisiert. Daher kann die Wiederherstellung einige Tage dauern. Die 2+1-Regel stellt sicher, dass der Betrieb so schnell wie möglich wieder aufgenommen werden kann, solange die IT-Abteilung es schafft, die Pipeline innerhalb von zwei Wochen zu reparieren, mit möglichst geringen Auswirkungen auf die Optimierungsinitiative. Wenn das Zeitfenster jedoch zu lang ist, wird der inkrementelle Upload in Bezug auf die Rechenressourcen zu schwer, was den eigentlichen Grund für die Einführung von inkrementellen Uploads zunichte macht.

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

Identifizierung der relevanten Tabellen und Spalten

Die überwiegende Mehrheit der Unternehmenssoftware basiert auf relationalen Datenbanken. Obwohl Web-APIs existieren können, liefern solche APIs in unserer Erfahrung selten eine zufriedenstellende Leistung bei geplanten Extraktionen des vollständigen Verlaufs. Im Gegensatz dazu erweist sich die direkte Abfrage der Datenbank über SQL häufig als einfach zu implementieren und recht leistungsfähig, da die von Lokad empfohlenen SQL-Abfragen keine Joins erfordern.

Sobald ein Geschäftssystem (z. B. ERP) als relevante Datenquelle für die Initiative festgelegt wurde und vorausgesetzt wird, dass auf die zugrunde liegende relationale Datenbank zugegriffen werden kann, müssen die spezifischen 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 benötigt eine Supply-Chain-Initiative in der Regel nicht mehr als ein Dutzend Tabellen, um zu beginnen, und nur einige Dutzend, um einen hohen Grad an Datenabdeckung zu erreichen.

Wenn das Unternehmen Zugang zu einem Experten hat, der mit dem Datenbankschema des Unternehmens vertraut ist, ist die Nutzung dieser Expertise der einfachste Weg, um die relevanten Tabellen in der Datenbank zu identifizieren. Wenn jedoch kein Experte vorhanden ist, kann die Rückwärtsentwicklung der Datenbank zur Identifizierung der interessanten Bereiche in der Regel innerhalb einer oder zwei Wochen durchgeführt werden (auch bei einem recht komplexen System). Zusätzlich zur Nutzung aller zugänglichen technischen Dokumentationen zum System empfehlen wir, mit einer vollständigen Schemaextraktion der Datenbank zu beginnen, einschließlich:

• dem Tabellennamen
• dem Spaltennamen
• dem Spaltentyp
• der Tabellengröße

Wir schlagen vor, diese Informationen in einer Tabelle zu sammeln. 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 dort in der Regel die relevantesten (für eine optimierte Supply-Chain-Initiative) gefunden werden können. Um eine Tabelle zu untersuchen, schlagen wir eine visuelle Inspektion einiger Dutzend Datensätze vor. Die Beobachtungen sollten während der Arbeit in die Tabelle aufgenommen 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 Abfragenvorlage 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 Abfragenvorlage 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 Übertragungen

Die Lokad-Plattform unterstützt einfache Textdateien, flache Dateiformate (in der Regel CSV- oder TSV-Formate) sowie Microsoft Excel-Tabellenkalkulationen sowohl für Lese- als auch für Schreibvorgänge. Der Abschnitt Dateien lesen und schreiben dokumentiert die Ein- und Ausgabemöglichkeiten von Lokad. Obwohl Lokad eine recht vielfältige Auswahl an Formatierungsoptionen unterstützt, empfehlen wir Folgendes:

• Einfacher Text wird anstelle von Tabellenkalkulationen verwendet (siehe unten stehende Diskussion).
• 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 der Dezimaltrenner für Dezimalzahlen.
• Datumsangaben haben in allen Tabellen das gleiche Format.
• Währungsbeträge isolieren die Währung in einer separaten Spalte.
• Der Dateiname entspricht dem ursprünglichen Tabellennamen.
• /input ist der von Lokad verwendete Ordner auf der Serverseite zum Ablegen der extrahierten Dateien.

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

In Bezug auf die Übertragung empfehlen wir die Verwendung von SFTP mit einer öffentlichen Schlüsselauthentifizierung.

Partitionierte Tabellen

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

Bei der Partitionierung einer Tabelle in eine Liste von Dateien besteht das empfohlene Dateinamensmuster darin, die Dateien in einem dedizierten 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
/..

Selbst wenn alle Zeilen in einer Datei den gleichen “Datum”-Wert haben (der dem im Dateinamen gefundenen Wert entspricht), empfehlen wir, diese “Datum”-Spalte als Teil der Datei beizubehalten.

Microsoft Excel

Lokads Plattform unterstützt das Lesen von Daten aus Microsoft Excel-Tabellen, solange die Tabelle ein tabellarisches Format aufweist (die erste Zeile enthält die Überschriften, dann eine Aufzeichnung pro Zeile). Die Datenextraktionspipeline sollte jedoch vermeiden, Tabellenkalkulationen an Lokad zu übertragen.

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

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

/manual ist der von Lokad verwendete Ordner auf der Lokad-Seite, um manuell hochgeladene Dateien zu empfangen.

Dateiüberschreibungen

Die Dateien im Lokad-Dateisystem stellen die Daten dar, wie sie von Lokad gesehen werden. Das Überschreiben vorhandener Dateien ist der empfohlene Weg, um die extrahierten Tabellen zu aktualisieren, die nicht partitioniert sind. 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 an Lokad übertragen wurden, empfehlen wir, eine Datei mit dem Namen /input/end-of-transfer.csv zu erstellen (oder zu aktualisieren), die Folgendes enthält:

• eine einzelne Spalte mit dem Namen LastTransfer
• eine einzelne Datumszeile (zwei Zeilen, wenn der Header mitgezählt wird) mit einem Zeitstempel des letzten Transfers

Diese Datei kann verwendet werden, um eine Projektsequenz auszulösen, die die frisch aktualisierten Daten verarbeitet.

Datenintegrität

Die Datenextraktionspipeline muss zuverlässig funktionieren. Die Lokad-Plattform selbst kann verwendet werden, um die Ausgabe der Extraktionspipeline zu instrumentieren und die Integrität, Vollständigkeit und Aktualität der extrahierten Daten zu bewerten. Daher empfehlen wir als allerersten Schritt der Pipeline innerhalb von Lokad die Implementierung von Dashboards zur Datenintegrität. Diese Dashboards sind für die IT-Abteilung gedacht (obwohl von ihnen nicht erwartet wird, dass sie sich darum kümmern). Der gemeinsame Zweck der Dashboards besteht darin, etwaige Datenprobleme zu erläutern und die eventuelle Lösung durch die IT-Abteilung zu beschleunigen. Diese Implementierung, wie der Rest des numerischen Rezepts, das die optimierte Supply Chain-Initiative antreibt, sollte von einem Supply Chain-Experten durchgeführt werden, möglicherweise vom Lokad-Team (im Falle eines Platform+Experts-Abonnements).

Spezifikation der Datenextraktion

Sobald die Datenextraktionspipeline stabilisiert wurde, empfehlen wir, eine Spezifikation für die Datenextraktion zu erstellen. In diesem Dokument sollten alle erwarteten Dateien und ihre Spalten sowie der Zeitplan für die Datenextraktion aufgeführt sein. Die Stabilisierung der Datenpipeline wird innerhalb von sechs Monaten nach dem Start der Initiative erwartet. Dieses Dokument sollte von der IT-Abteilung und der Supply Chain-Abteilung gemeinsam vereinbart werden. Dieses Dokument enthält die Details der Daten, die von der IT-Abteilung in zeitnaher Weise für die Lokad-Plattform zur Verfügung gestellt werden sollen.

Das Datenformat kann zu einem späteren Zeitpunkt noch überarbeitet werden, aber von der IT-Abteilung wird erwartet, dass sie die Supply Chain-Abteilung vor jeder Änderung des Datenformats oder des zugehörigen Zeitplans benachrichtigt. Im Allgemeinen sollte nach Vereinbarung der Spezifikation erwartet werden, dass die Abläufe der Supply Chain für Produktionszwecke auf die Integrität der Datenextraktion angewiesen sind. Daher sollte die Supply Chain-Abteilung im Falle von Änderungen einen angemessenen “Grace-Period” erwarten, der ausreicht, um die Logik in Lokad zu aktualisieren (um das überarbeitete Datenformat anzupassen).

Da die Erstellung einer detaillierten Spezifikation erhebliche Zeit und Mühe erfordert, empfehlen wir, die Erstellung dieses Dokuments zu verschieben, bis die Pipeline stabil ist. Unsere Erfahrung zeigt, dass die Pipeline - sowohl die Datenextraktion als auch die analytischen Segmente - während der ersten Monate einer schnellen Entwicklung unterliegt. Diese schnelle Entwicklung wird voraussichtlich frühe Versuche zur Erstellung einer solchen Spezifikation überholen.

Feedback-Schleife

Die in der Lokad-Plattform generierten Supply Chain-Entscheidungen (z. B. Bestandsauffüllungen) können als Flachdateien exportiert und in das Geschäftssystem (e) wieder integriert werden. Dieser Mechanismus wird als Feedback-Schleife bezeichnet. Unsere Erfahrung zeigt, dass die Implementierung der Feedback-Schleife innerhalb von vier Monaten nach dem Start des Projekts unwahrscheinlich ist. Das Vertrauen in das numerische Rezept, das erforderlich ist, um auch einen Teil der Supply Chain im Autopilotmodus zu betreiben, ist erheblich, und dieses Maß an Vertrauen kann mehrere Monate dauern, um aufzubauen. Daher ist die Feedback-Schleife zu Beginn des Projekts kein Anliegen.

Unsere Erfahrung zeigt, dass die Einrichtung der Feedback-Schleife eine viel geringere Herausforderung darstellt als die Einrichtung der Datenextraktions-Pipeline. Zum Beispiel werden die in Lokad erstellten Zahlen als maßgeblich und endgültig angesehen. Wenn weitere Regeln angewendet werden müssen, um diese Zahlen in handlungsfähige Zahlen umzuwandeln (z. B. angewandte Mindestbestellmengen), ist das numerische Rezept unvollständig und muss auf der Lokad-Seite behoben werden. Auf der anderen Seite hat die Lokad-Plattform die Kapazität, jede Art von Daten zu verarbeiten und zu produzieren, solange sie vernünftig tabellarisch ist. Die Einfachheit der Feedback-Schleife ist also darauf ausgelegt, die Einfachheit der Supply Chain-Entscheidungen widerzuspiegeln. Zum Beispiel können Dutzende von Einschränkungen festlegen, ob eine bestimmte Bestellung gültig ist oder nicht, aber der Inhalt der endgültigen Bestellung ist eine einfache Liste von Mengen, die mit Teilenummern verknüpft sind.

Wir empfehlen jedoch, dass der Lokad-Plattform kein direkter Zugriff auf die Geschäftssysteme des Kunden gewährt wird. Stattdessen sollten Dateien rechtzeitig im Lokad-Dateisystem zur Verfügung gestellt werden. Die IT-Abteilung ist weiterhin dafür verantwortlich, diese Daten in die Geschäftssysteme zurückzuspielen. Dadurch wird sichergestellt, dass ein potenzieller Sicherheitsverstoß des Lokad-Kontos nicht dazu verwendet werden kann, auf andere Systeme im Unternehmen zuzugreifen. Außerdem besteht die Möglichkeit, diese Feedback-Operation zu verschieben, wenn sie mit einer anderen von der IT durchgeführten Operation über die Geschäftssysteme kollidiert.

Da die Feedback-Schleife per Definition Daten zu realen Supply Chain-Operationen umfasst, empfehlen wir, eine spezielle Spezifikation für diesen Prozess zu erstellen. Diese Spezifikation spiegelt die Datenextraktionsspezifikation wider, jedoch mit Daten, die in die entgegengesetzte Richtung übertragen werden. Es wird erwartet, dass dieses Dokument auch von der IT- und der Supply Chain-Abteilung gemeinsam vereinbart wird.