Die Datenextraktionspipeline

Dieses Dokument soll IT-Abteilungen als Leitfaden dienen, um eine Pipeline zu konstruieren, die Daten aus bestehenden Geschäftssystemen extrahiert und diese Daten innerhalb 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 Ansatz, den Lokad empfiehlt, einschließlich des Umfangs der zu extrahierenden und auf der Lokad-Plattform verfügbaren Daten, des Formats der Daten 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) automatisiert angesichts von Herausforderungen in der Supply Chain. 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:

• Entscheiden über Lagerbestandsmengen zur Auffüllung
• Entscheiden über Lagerbestandsmengen zur Produktion
• Entscheiden darüber, ob die Preise erhöht oder gesenkt werden sollen
• Entscheiden darüber, ob Bestände im Netzwerk verschoben werden sollen

Wenn das Unternehmen erfolgreich ist, diese Entscheidungen zu optimieren, 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, Liquidität und Service zu überarbeiten, um sie besser mit seiner Gesamtstrategie für die Supply Chain in Einklang zu bringen.

Das numerische Rezept, das das interessierende Problem angeht, soll in Lokad implementiert werden. Daher erfordert das numerische Rezept, dass relevante Unternehmensdaten auf der Lokad-Plattform verfügbar gemacht werden. Dies führt zu folgenden Fragen:

• Welche Daten sollten an Lokad übertragen werden?
• In welchem Format sollten die Daten vorliegen?
• Welche Übertragungsmuster sollten verwendet werden, um die Daten zu aktualisieren?

Obwohl die oben aufgeführten Probleme vielfältig sind, sind die relevanten Eingabedaten sehr ähnlich und werden in der Regel über die Kerntransaktionshistoriedaten des Unternehmens bereitgestellt (zum Beispiel historische Verkaufszahlen).

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

Sobald die Datenextraktionspipeline erstellt ist, sind auf der Lokad-Seite Ingenieure - die als Supply Chain Scientists bezeichnet werden - für den Aufbau und die Wartung des numerischen Rezepts verantwortlich. Diese Ingenieure werden häufig von Lokad im Rahmen einer “Plattform+Experten”-Servicevereinbarung bereitgestellt, aber es ist auch möglich, dass der Kunde diese Kompetenz internalisiert. Selbst wenn solche Ingenieure intern 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 Schicht, die über den bestehenden Transaktionssystemen des Kunden arbeitet. Mit anderen Worten, Lokad ersetzt nicht das ERP; es ergänzt es um prädiktive Optimierungsfähigkeiten, 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 typischerweise 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 bis zu dem Punkt betrifft, an dem 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), sodass die IT-Abteilung in dieser Hinsicht einen gewissen Spielraum hat.

Sobald die Daten Lokad zur Verfügung stehen, verarbeiten eine Reihe von Envision-Skripten (Envision ist die von Lokad entwickelte domänenspezifische Programmiersprache) diese und generieren die optimierten Supply-Chain-Entscheidungen von Interesse.

Es gibt mehrere praktische Anwendungen einer solchen Datenextraktion, viele davon gehen über die Supply-Chain-Optimierungsinitiative von Lokad hinaus. Marketing-, Finanz- und Vertriebsteams - um nur drei zu nennen - sind potenzielle Nutznießer derselben historischen Verkaufsdaten, die Lokad schließlich verarbeitet. 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 Drittanbieter-Analyse-Systeme (wie die Plattform von Lokad) reserviert ist.

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

Der Umfang relevanter Daten

Die Supply Chain dreht sich um die Optimierung von 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 beschreiben, welche Flüsse innerhalb des Unternehmens stattfinden. Diese Daten finden sich typischerweise in den transaktionalen Geschäftssystemen des Kunden.

Wie bereits erwähnt, ist die Plattform von Lokad in ihren Verarbeitungsmöglichkeiten recht flexibel, daher gibt es keine harten Anforderungen an 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, da 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 beschreiben - aus der Perspektive der Supply Chain - 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, da Verkäufe fast immer die beste Annäherung sind, die das Unternehmen hat, um die Marktnachfrage abzuschätzen. Diese Daten sollten die mit den Transaktionen verbundenen Geldbeträge enthalten, da die Optimierung der Supply Chain aus finanzieller Sicht durchgeführt werden sollte. (Diese finanzielle Perspektive wird später detaillierter behandelt.) Wenn möglich, ist es (immer) vorzuziehen, Rohauftragstransaktionen bereitzustellen, anstatt tägliche/wöchentliche/monatliche Aggregationen. (Dieser Punkt wird unten auch detaillierter erörtert.) Der Verkaufsauftragsverlauf kann zurückgestellte Aufträge, stornierte Aufträge, verschobene Aufträge, geänderte Aufträge, Rücksendungen usw. enthalten, die alle potenziell relevante Datenpunkte sind. Wenn Kunden in diesen Daten identifiziert sind, werden die anonymisierten Kundenkennungen relevant. (Personenbezogene Daten haben ihren eigenen Abschnitt unten.)

Einkaufsaufträge: Die Liste der historischen Einkaufsaufträge des Kunden sowie der ausstehenden Einkaufsaufträge (die noch nicht eingegangen sind). Diese Liste ist wichtig, da Einkaufsaufträge fast immer die beste Annäherung sind, um Lieferanten-Lieferzeiten und deren Servicequalität abzuschätzen. Ausstehende Einkaufsaufträge spiegeln den “Bestand in Bestellung” wider. Die Einkaufsaufträge sollten auch die mit den Transaktionen verbundenen Geldbeträge enthalten. Wenn möglich, ist es auch (immer) vorzuziehen, die Rohauftragshistorie anstelle von Aggregationen bereitzustellen. Die Einkaufsauftragshistorie sollte, wenn 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, da diese Aufträge den Transformationsfluss der Güter widerspiegeln, der innerhalb des Unternehmens stattfindet, und es uns ermöglicht, die Engpässe zu identifizieren, die in der Supply Chain vorhanden sein können. Je nach Situation kann die Produktion variable Ausbeuten haben oder manchmal können Chargen aufgrund von Qualitätsproblemen aussortiert werden. Diese Ereignisse sind relevant.

Bestandsbewegungen: Die Liste der historischen Bestandsbewegungen des Kunden, wenn mehrere Standorte vorhanden sind. Diese Liste ist wichtig, da sie Aufschluss über den Ursprung des Bestands gibt, der entweder zur Auslösung von Produktionsprozessen oder zur Bedienung von Kunden verwendet wird. Je nach Situation können die Vorlaufzeiten für diese Bewegungen variabel sein. Wenn dies der Fall ist, sind auch die Feinheiten der Daten (Überweisungsdatum, Versanddatum, Empfangsdatum) relevant.

Bestandsniveaus: Die Liste aller SKUs (Stock-Keeping Unit) 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-Niveaus. Verfallsdaten können ebenfalls vorhanden sein. Ein Teil oder der gesamte Bestand kann auf Seriennummerebene verfolgt werden. Wenn ein Serieninventar verwendet wird, sind die gesamte Liste der Seriennummern und ihre zugehörigen Standorte relevant. Allgemeiner gesagt sind alle Elemente relevant, die den aktuellen Zustand der Lagerbestände des Unternehmens beschreiben.

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

Auch Schnappschüsse vergangener Lagerbestände, vergangener Preisschilder und ausstehender Kaufaufträge sind für die meisten Zwecke in der Supply Chain relevant (diese Daten sind jedoch selten in Geschäftssystemen verfügbar). Sobald eine Datenextraktionspipeline eingerichtet ist, können solche Schnappschüsse 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 mehr relevante Datenquellen als hier aufgeführt. Als Faustregel gilt: Wenn eine Information für die Supply-Chain-Abteilung nützlich ist, ist sie höchstwahrscheinlich auch für Zwecke der prognostischen Optimierung relevant und sollte an Lokad weitergeleitet werden.

Priorisiertes Schema der vorbereiteten Daten

Die Liste der oben genannten potenziell relevanten Datentabellen soll nicht überwältigen. In der Praxis ist es wichtig zu identifizieren, welche Tabellen erforderlich sind, um die Initiative zur Produktion zu ergreifen, im Gegensatz dazu, was nett zu haben ist. Es ist auch wichtig, Extraktionen ordnungsgemäß priorisieren, um den Supply Chain Scientists zu ermöglichen, über die Datenextraktionsphase hinaus in die Optimierungsphase zu gelangen.

Daher empfiehlt Lokad als Teil 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 sollten. Dieses Dokument listet die Tabellen - und ihre Felder - auf, die am Ende des Datenbereitstellungssegments verfügbar sein sollen. Dieses Dokument listet auch die jeweiligen Prioritäten aller angeforderten Felder auf.

Dieses Schema bietet eine Wunschliste auf hoher Ebene für die zu extrahierenden Daten. Dieses Dokument sollte jedoch nicht als Spezifikation für die Dateien missverstanden werden, die im Stadium der Datenextraktion generiert werden. Die Supply-Chain-Scientists sind für die Datenbereitstellung verantwortlich. Es ist akzeptabel (und üblich), wenn das Schema der Daten, wie es von der Datenextraktionspipeline zur Verfügung gestellt wird, erheblich von dem “idealisierten” Schema abweicht, das mit den vorbereiteten Daten verbunden ist. Dieser Punkt wird im Abschnitt “Rohtransaktionsextrakte” unten 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önnten, die für die Bewertung der langfristigen Entwicklung der Supply Chain relevant sein könnten. Filter werden ohnehin Lokad-seitig als Teil der Datenbereitstellung implementiert, daher führt das Übertragen von mehr Daten nicht unbedingt zu mehr Rechenressourcen für Lokad.

In Bezug auf die historische Tiefe 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. Die Supply-Chain-Praktiker, die die interessierenden Entscheidungen treffen müssen, bevor die Lokad-Initiative startet, sind jedoch an 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. Mitarbeiter innerhalb der Organisation schaffen es jedoch trotzdem, 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 verfügbar ist - genauso wie es Mitarbeiter tun. Dieser Ansatz steht im Gegensatz zur Mainstream-Unternehmenssoftware, die mit endgültigen Datenanforderungen geliefert wird und nicht funktioniert, es sei denn, alle Anforderungen sind erfüllt.

In unserer Erfahrung gibt es zwei große Klassen von “fehlenden” Daten, die unterschieden werden sollten: Erstens Daten, die in das Geschäftssystem integriert werden sollten; zweitens Daten, die für das analytische System (wie Lokad) als äußerst nützlich erachtet werden.

Mindestbestellmengen (MOQs), Preisnachlässe und Lieferanten-Schließwochen 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) und die Verwendung von Ad-hoc-Tabellenkalkulationen (die bei Lokad hochgeladen werden). Sobald das numerische Rezept einsatzbereit ist, wird Lokad die IT-Abteilung des Kunden einbeziehen, um die Daten in die Geschäftssysteme 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, sind eine Kategorie, die als äußerst nützlich angesehen wird, aber unserer Erfahrung nach ist dies nicht selbstverständlich. Anekdotisch betrachtet ist der Erhalt dieser Art von Daten oft mit erheblichen Kosten verbunden, sonst würden Unternehmen dies bereits tun. Aus diesem Grund ist es keine Voraussetzung, 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.

Rohdatenauszüge aus Transaktionen

Wir empfehlen nachdrücklich, die ursprüngliche Form der Daten zu erhalten. Die Daten, die an Lokad übermittelt werden, sollten nichts anderes als Rohkopien der Originaltabellen und -spalten sein, wie sie in den RDBMS zu finden sind, die die Geschäftssysteme des Unternehmens unterstützen. Die gesamte Datenbereitstellung sollte an die Lokad-Plattform delegiert werden, die speziell für die Datenbereitstellung entwickelt wurde.

Der Versuch, die Daten vorzubereiten, führt zwangsläufig zu Datenverlust. 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 Lokad-Plattform erreichen, kann dieser Verlust nicht wiederhergestellt werden. Rohdatenauszüge stellen sicher, dass die gesamte im Geschäftssystem verfügbare Information innerhalb von Lokad zugänglich wird.

Darüber hinaus führt die Datenbereitstellung eine eigene Schicht von Komplexität über die Komplexität der Geschäftssysteme selbst hinaus ein. Zugegeben, das numerische Rezept, das die gewünschte Supply-Chain-Optimierung liefert, kann nicht umhin, sich mit Klassen von inhärenter Komplexität auseinanderzusetzen. Wenn dieses numerische Rezept jedoch auch mit der zufälligen Komplexität umgehen muss, die durch die vorherige Datenbereitstellung eingeführt wurde, wird aus einem bereits schwierigen Problem ein unvernünftig schwieriges. Rohdatenauszüge stellen sicher, dass Lokad nicht mit einem noch größeren Problem konfrontiert wird, als das, das gelöst werden muss.

Von einem IT-Perspektive aus betrachtet sind Rohdatenauszüge einfach. Einfache Tabellenkopien sollten 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 involviert sind, und performant, da kein Join involviert ist. Sehr große Tabellen erfordern jedoch etwas spezielle 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 Spiegelfunktionen. Wir empfehlen, diese Funktionen bei der Einrichtung des Data Lakes zu nutzen. Darüber hinaus ist das Spiegeln von Daten wesentlich einfacher als die Datenbereitstellung - insbesondere aus der Sicht der IT-Abteilung, da die Datenbereitstellung stark von dem spezifischen Problem abhängt, das gelöst werden soll.

Das BI-Extraktions-Antimuster

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, normalerweise 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 z. B. mehrzeilige Aufträge, aus Business Intelligence-Systemen (wie BI-Cubes) eliminiert. Diese Details sind wertvoll, da sie das Wesen 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 transaktionale Dateneinträge sind selten und treten in der Regel einmal oder zweimal pro 1000 Einträge auf. Wenn Barcodes oder ähnliche Geräte verwendet werden, ist die Fehlerquote noch geringer. Das eigentliche Problem liegt darin, dass die Software falsche Annahmen über die Daten trifft, anstatt dass die Daten selbst schlecht sind.

Die Lagerbestände in großen B2C-Einzelhandelsnetzen sind fast immer ungenau. Aus Lokads Perspektive handelt es sich jedoch bei dieser Situation um lauter Daten, nicht um schlechte Daten. Wenn solche Lagerbestände (fälschlicherweise) als präzise angesehen werden, ergeben die Ergebnisse keinen Sinn. Wir betrachten diese spezifische Situation mit einer probabilistischen Sicht auf Lagerbestände, indem wir Unsicherheit annehmen, anstatt sie abzulehnen.

Letztendlich wurden Lokads Systeme so konzipiert, dass sie Daten empfangen und es dem Kunden ermöglichen, ihre Supply Chain zu betreiben, ohne sich über diese Probleme Gedanken machen zu müssen. Lokad etabliert eine Daten-Semantik, um diese Probleme anzugehen, und dies stellt den herausforderndsten Teil der Datenbereitungsphase 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ögen zu behandeln. Wir raten dringend davon ab, persönliche Daten an Lokads Plattform zu übertragen. In der Praxis bedeutet dies in der Regel, die Datenbankspalten (siehe Diskussion unten) zu filtern, die persönliche Identifikatoren enthalten (z. B. Name, Adresse, Telefonnummer, E-Mail usw.).

Diese persönlichen Identifikatoren können durch undurchsichtige anonyme ersetzt werden - wenn die Informationen aus Supply-Chain-Sicht relevant sind. Beispielsweise sind undurchsichtige Kundenidentifikatoren nützlich, da sie Lokad ermöglichen, Muster in Bezug auf die Kundentreue zu identifizieren - wie den negativen Einfluss von Lagerausfällen. Im Gegensatz zu den meisten Prognosetechnologien, die nur mit einer Zeitreihenperspektive arbeiten können, kann Lokads Plattform von ultra-granularen historischen Daten profitieren, bis hin zur Transaktionsebene.

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

Finanzdaten

Die monetären Beträge für Waren, die vom Kunden gekauft, umgewandelt und verkauft werden, sind für die von Lokad bereitgestellte Optimierung der Lieferkette von größter Bedeutung. Tatsächlich betont Lokad eine finanzielle Perspektive auf die Lieferkette, die Dollarrenditen über Fehlerprozentsätze optimiert.

Im Gegensatz zu Anbietern, die nur Daten zu Lagerbeständen berücksichtigen, nutzt Lokad die finanziellen Daten eines Kunden - sofern verfügbar. Logischerweise konzentrieren sich die meisten belastenden Kosten der Lieferkette an den Extremen; unerwartet hohe Nachfrage führt zu Lagerausfällen; und unerwartet niedrige Nachfrage führt zu Bestandsabschreibungen. Dazwischen rotiert der Bestand ganz gut. Um also wirklich optimale Lagerentscheidungen 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. Dieses Setup 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 ab dem ersten Tag installiert wird. Teilweise einmalige Extraktionen zur Identifizierung relevanter Tabellen können jedoch nützlich sein. Dieser Punkt wird in den folgenden Abschnitten erörtert.

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

Erstens ist aus der Sicht des Supply-Chain-Praktikers eine 3 Wochen alte Datenlage bereits Geschichte. Die Ergebnisse, die aus veralteten Daten gewonnen werden, sind für die heutigen Lieferkettenentscheidungen 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 zu gewinnen, die tägliche Variabilität zu bewältigen.

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

Es dauert in der Regel zahlreiche geplante Durchläufe, 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 Leistung des gesamten Sequenzprozesses von Anfang bis Ende zu bewerten, einschließlich derjenigen, die zu der Bereitstellung empfohlener Lieferkettenentscheidungen 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, Verzögerungen bei der Initiative einzuführen und Lokad daran zu hindern, mögliche Problemeklassen so früh wie möglich zu identifizieren (wie im vorherigen Absatz beschrieben).

Datenextraktionsfrequenz

Wir empfehlen, alle Datenpipelines - die Extraktionssegmente sowie die analytischen Segmente - 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 Abschluss des Geschäftstages des aktuellen Tages 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 sind ab dem Beginn des nächsten Arbeitstages verfügbar.

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

Wenn die Daten zu groß sind, um täglich vollständig in Lokad 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 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 scheitern - unabhängig von Lokad. Nach unserer Erfahrung erleben selbst ausgezeichnete IT-Abteilungen 1-2 Pipeline-Ausfälle pro Jahr. 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), bleibt Lokad mit einer teilweise korrupten Datenhistorie zurück. Das Beheben dieses Problems auf der Lokad-Seite erfordert eine zweite manuelle Intervention der IT-Abteilung, zusätzlich zur Behebung dessen, was die ordnungsgemäße Ausführung der Datenextraktionspipeline verhindert hat. Diese “Datenhistorienkorrektur” wird wahrscheinlich um einige Tage verzögert - da dies ein ungewöhnlicher Vorgang für die IT-Abteilung ist. In der Zwischenzeit sind die von Lokad zurückgegebenen Ergebnisse negativ beeinflusst, da einige aktuelle Daten teilweise korrupt 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, am nächsten Tag von einer vollständigen Wiederherstellung. Tatsächlich wird die Wiederherstellung des normalen Betriebszustands voraussichtlich innerhalb eines Arbeitstages erfolgen, da die Datenextraktionspipeline Teil der Routineoperationen ist, die von der IT-Abteilung abgedeckt werden. Diese Wiederherstellung erfordert keine spezifische Interaktion zwischen der IT-Abteilung und entweder dem Supportpersonal von Lokad oder den Endbenutzern der Lokad-Lösung. Die Datenkorrektur wird automatisch durch die Überschreibungen geliefert, die täglich im 2+1-Zeitfenster erfolgen.

Die 2+1-Regel spiegelt einen Kompromiss basierend auf Lokads Erfahrung wider: Je länger das Zeitfenster ist, desto widerstandsfähiger wird die Datenextraktionspipeline gegenüber vorübergehenden Problemen. Obwohl wir hoffen können, dass alle 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, solange die IT-Abteilung die Pipeline innerhalb von zwei Wochen reparieren kann, die Operationen wie gewohnt mit möglichst geringen Auswirkungen auf die Optimierungsinitiative fortgesetzt werden können. 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 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. Während Web-APIs existieren können, liefern solche APIs in unserer Erfahrung selten eine zufriedenstellende Leistung, wenn es um geplante Extraktionen des vollständigen Verlaufs geht. Im Gegenteil, das direkte Abfragen der Datenbank über SQL erweist sich häufig als einfach umzusetzen und auch ziemlich 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 betrachtet 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 selten 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 dieses Fachwissens der einfachste Weg, um die relevanten Tabellen in der Datenbank zu identifizieren. Wenn jedoch kein Experte vorhanden ist, kann das Reverse Engineering der Datenbank, um die interessanten Bereiche zu identifizieren, in der Regel in einer Woche oder zwei durchgeführt werden (auch bei einem recht komplexen System). Neben der Nutzung aller verfügbaren technischen Dokumentationen zum betreffenden System schlagen wir vor, 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 schlagen vor, mit einer genaueren Untersuchung der größten Tabellen zu beginnen, da dort in der Regel die relevantesten zu finden sind (für eine optimierte Supply-Chain-Initiative). Um eine Tabelle zu untersuchen, schlagen wir eine visuelle Inspektion von einigen Dutzend Datensätzen vor. Die Beobachtungen sollten in der Tabelle festgehalten werden, während die Arbeit fortschreitet.

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 Übertragungen

Die Lokad-Plattform unterstützt einfache Textdateien, flache Dateiformate (typischerweise CSV- oder TSV-Formate) sowie Microsoft Excel-Tabellen, 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 ziemlich vielfältige Auswahl an Formatierungsoptionen unterstützt, empfehlen wir Folgendes:

• Einfacher Text 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.
• Der Punkt (.) ist der Dezimaltrenner für Bruchzahlen.
• Datumsangaben haben alle das gleiche Format in allen Tabellen.
• Monetäre Beträ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 Lokad-Seite, um die extrahierten Dateien abzulegen.

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

Für den Transfer 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 bequem 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 denselben “Datumswert” haben (der dem im Dateinamen gefundenen entspricht), empfehlen wir, diese “Datumsspalte” als Teil der Datei zu belassen.

Microsoft Excel

Lokads Plattform unterstützt das Lesen von Daten aus Microsoft Excel-Tabellen, solange die Tabelle einem tabellarischen Format folgt (die erste Zeile enthält die Überschriften, dann ein Datensatz pro Zeile). Die Datenextraktionspipeline sollte jedoch vermieden werden, Tabellen an Lokad zu übertragen.

Tabellen 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, um manuell hochgeladene Dateien zu empfangen, nach Konvention.

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 enthält:

• eine einzelne Spalte mit dem Namen LastTransfer
• eine einzelne Datumszeile (zwei Zeilen, wenn der Header gezä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, Datenintegritäts-Dashboards zu implementieren. 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 umreißen und die spätere Lösung durch die IT-Abteilung zu beschleunigen. Diese Implementierung, wie der Rest des numerischen Rezepts, das die optimierte Supply Chain-Initiative antreibt, soll 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. Dieses Dokument sollte alle erwarteten Dateien und ihre Spalten sowie den Zeitplan für die Datenextraktion auflisten. Die Stabilisierung der Datenpipeline soll innerhalb von sechs Monaten nach dem Start der Initiative erfolgen. Dieses Dokument sollte von der IT-Abteilung und der Supply Chain-Abteilung gemeinsam vereinbart werden. Dieses Dokument enthält die Feinheiten der Daten, die von der IT-Abteilung zeitnah der 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 am Datenformat oder am zugehörigen Zeitplan informiert. Im Allgemeinen sollte, sobald die Spezifikation vereinbart wurde, von den Betriebsabläufen der Supply Chain erwartet werden, dass sie sich für Produktionszwecke auf die Integrität der Datenextraktion verlassen. Daher sollte die Supply Chain-Abteilung im Falle von Änderungen einen angemessenen “Gnadenzeitraum” erwarten, der ausreicht, um die Logik innerhalb von 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 stabilisiert ist. In unserer Erfahrung unterliegt die Pipeline - sowohl ihre Datenextraktion als auch ihre analytischen Segmente - während der ersten Monate einer schnellen Entwicklung. Diese schnelle Entwicklung wird wahrscheinlich frühe Versuche zur Erstellung einer solchen Spezifikation obsolet machen.

Rückkopplungsschleife

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

In unserer Erfahrung ist die Einrichtung der Rückkopplungsschleife eine viel kleinere Herausforderung als die Einrichtung der Datenextraktionspipeline. Beispielsweise wird erwartet, dass die Zahlen, wie sie innerhalb von Lokad produziert werden, maßgeblich und endgültig sind; wenn weitere Regeln angewendet werden müssen, um diese Zahlen in handlungsfähige Zahlen umzuwandeln (z. B. angewandte MOQs), dann ist das numerische Rezept unvollständig und muss auf der Lokad-Seite behoben werden. Andererseits hat die Plattform von Lokad die Kapazität, jede Form von Daten zu verarbeiten und zu produzieren, solange sie vernünftigerweise tabellarisch ist. Daher ist die Einfachheit der Rückkopplungsschleife darauf ausgelegt, die Einfachheit der Supply Chain-Entscheidungen widerzuspiegeln. Beispielsweise 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 verbunden 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 wieder in die Geschäftssysteme zu importieren. Dies stellt sicher, dass ein potenzieller Sicherheitsverstoß des Lokad-Kontos nicht dazu verwendet werden kann, auf andere Systeme innerhalb des Unternehmens zuzugreifen. Außerdem bietet dies die Möglichkeit, diese Rückkopplungsoperation zu verschieben, wenn sie mit einer anderen von der IT über den Geschäftssystemen durchgeführten Operation in Konflikt steht.

Da die Rückkopplungsschleife per Definition Daten zu realen Supply Chain-Operationen umfasst, empfehlen wir die Erstellung einer Spezifikation, die diesem Prozess gewidmet ist. 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.