Quantitative SCM vs Classic APS

Joannes Vermorel

Während die Supply Chains bereits in den 80er und 90er Jahren mit elektronischem Bestandsmanagement und EDI (Electronic Data Interchange) einen frühen Start in der Digitalisierung hatten, gerieten viele Softwareanbieter - und somit die meisten ihrer Kunden - in den beiden darauffolgenden Jahrzehnten allmählich ins Hintertreffen. Während es relativ einfach ist, Benutzeroberflächen zu aktualisieren, zum Beispiel Desktop-Anwendungen in Web-Anwendungen umzuwandeln, ist es in der Regel viel schwieriger, die grundlegenden architektonischen Designentscheidungen zu überdenken, die eine Software unterstützen. Die meisten dieser Lösungen waren nie für Cloud Computing, maschinelles Lernen oder eine mobile-first Benutzererfahrung entwickelt worden - um nur einige zu nennen.

Lokad setzt auf Prozesse und Technologien, die das Beste aus dem liefern, was moderne vernetzte Rechenleistung für Lieferketten durch bessere vorhersagende Optimierungen bieten kann. Wir bezeichnen diesen Ansatz als die Perspektive der “Quantitativen Supply Chain”. Für Lieferkettenpraktiker kann diese Botschaft jedoch etwas verwirrend sein, denn die “Quantitative Supply Chain” ist keine Variation der alten Methoden zur Optimierung der Lieferkette, sondern ein völlig anderer Ansatz.

Daher werfen wir einen genaueren Blick auf die traditionellen “Module”, wie sie in führenden¹ APS (Advanced Planning and Scheduling)-Systemen üblicherweise zu finden sind, mit einem besonderen Interesse an der Bestandsauffüllung in einem 2-Ebenen-Netzwerk - z.B. Lagern und Geschäften - und vergleichen diese Module mit der Art und Weise, wie Lokad vorhersagende Optimierung liefert. Der Einfachheit halber beziehen wir uns im Folgenden abwechselnd auf die “Quantitative Supply Chain” (die Vision) oder auf Lokad (die Softwareimplementierung).

Kalendermodul

Ein “Kalendermodul” bietet Mechanismen zur Feinabstimmung von Bestellsituationen, d.h. zur Entscheidung “wann” gekauft werden soll, wenn ein festgelegter Bestellzyklus unvermeidbar ist.

Die Vorstellung, dass Lieferkettenpraktiker ihren Bestellplan feinabstimmen sollten, ist der falsche Ansatz. Bestellungen gehen mit verschiedenen Arten von Einschränkungen einher: Kalender, Mindestbestellmengen, Budget usw. Einige Einschränkungen können locker sein, wie “kein Zeitplan, jeder Tag außer dem 4. Juli und dem 25. Dezember ist möglich”, oder eng, wie “der Container muss genau voll sein”. In jedem Fall sollte das System - innerhalb aller möglichen Bestelloptionen - diejenigen suchen, die den ROI maximieren. Dieser Prozess, die “Optimierung”, muss strikt automatisiert sein. Es gibt keinen Grund, irgendetwas manuell feinabzustimmen. Leistungsfähige numerische Solver waren in den 80er Jahren noch nicht routinemäßig verfügbar, aber heutzutage ist dies nicht mehr der Fall.

Daher erfassen wir bei Lokad alle relevanten Einschränkungen, die selbst als Daten behandelt werden, d.h. als “Datenbank” autorisierter Bestellpläne, und setzen dann die geeigneten numerischen Solver ein, um die Aufgabe zu erledigen.

Siehe auch Menschen in modernen Lieferketten.

Ereignismodul

Das “Ereignismodul” verwaltet Nachfragespitzen und -einbrüche aufgrund geplanter Ereignisse wie Einführungen neuer Produkte, Werbung, Preisaktionen, Katalogverteilungen und Flyer.

Die frühesten Prognosemodelle (z.B. Holt-Winters), die in den 50er und 60er Jahren entdeckt wurden, waren alle auf Zeitreihen ausgerichtet. Daher haben die meisten APS eine zeitreihenzentrierte Perspektive übernommen. Leider lassen sich Supply-Chain-Probleme nicht einfach in Zeitreihen einordnen: Fehlbestände, Aktionen, Einführungen und Ausphasungen sind Phänomene, die nicht in das traditionelle mathematische Rahmenwerk der Zeitreihen passen. Um mit fehlerhaften Zeitreihen-Prognosemodellen umzugehen, greifen APS auf manuelle “Korrekturen” zurück, die sowohl auf historische Daten angewendet werden - z.B. Glättung des Anstiegs vergangener Aktionen - als auch auf Nachfrageprognosen - Einführung von Verzerrungen in zukünftige Schätzungen.

Bei Lokad behandeln wir diese “Störungen” als einfache historische Daten. Wir werden nie sicher wissen, was passiert wäre, wenn eine vergangene Aktion nicht ausgelöst worden wäre. Das Einzige, was wir sicher wissen, ist die Charakteristik der Aktion - d.h. Start- und Enddatum, Rabattmechanismus, Umfang usw. - und der resultierende Umsatz. Das statistische Modell muss also so konstruiert sein, dass es die historischen Daten so verarbeitet, wie sie existieren, anstatt mit einer engen Zeitreihenperspektive “festzustecken”.

Lokad erfasst die relevanten Ereignisse und verarbeitet all diese Daten mit statistischen Modellen, die auf hochdimensionale Probleme ausgerichtet sind und typischerweise unter den generischen Oberbegriff “Machine Learning”-Algorithmen fallen. Die neueste Version unserer Prognosetechnologie basiert auf “Differentiable Programming”. Es handelt sich jedoch immer noch um eine laufende Entwicklung, da sich das Gebiet des Machine Learning selbst schnell weiterentwickelt. Die Notwendigkeit, die Prognoseergebnisse manuell anzupassen, sollte als Softwarefehler betrachtet werden, der behoben werden muss, und nicht als Gelegenheit, Supply-Chain-Experten als “menschliche Coprozessoren” einzusetzen.

In der Praxis besteht die Hauptaufgabe darin, die relevanten Daten zu vergangenen und zukünftigen Ereignissen (z.B. geplante Aktionen) zu sammeln - was wenig mit Statistik zu tun hat. Die analytischen Systeme, sei es Lokad oder ein APS, sind nicht der richtige Ort, um große Mengen manueller Dateneingaben durchzuführen. Diese Dateneingaben gehören in den transaktionalen Bereich - auch bekannt als das ERP - das alle “Fakten”² über die Supply Chain sammelt.

Modul zur Beschleunigung der Auftragsabwicklung

Ein “Modul zur Beschleunigung der Auftragsabwicklung” dient als Frühwarnsystem und bietet den Einkäufern einen täglich aktualisierten Überblick über überfällige Aufträge und unvollständige Lieferungen.

Die gesamte Herangehensweise an “Ausnahmen” und “Warnungen” ist eine eher veraltete Perspektive zur Problemlösung in komplexen Systemen in der Softwarebranche. Diese Herangehensweise wurde in den 80er und 90er Jahren von Softwareanbietern stark übernommen, da “Ausnahmen” und “Warnungen” einfach auf einer SQL-Datenbank implementiert werden können. Es genügt eine SELECT-Anweisung mit einigen WHERE-Bedingungen. Diese Herangehensweise nutzt jedoch insgesamt die knappen Ressourcen, die Supply-Chain-Experten darstellen, schlecht aus, da sie sie schnell überlastet, sodass Warnungen nicht mehr als “Warnungen” wahrgenommen werden und das Gefühl von Dringlichkeit oder Handlungsbedarf verloren geht.

Lokad bevorzugt und liefert eine strikte ROI-basierte Priorisierung der für Supply-Chain-Experten interessanten “Elemente”. Als Faustregel gilt: 1 Million Zahlen pro Tag zu produzieren ist einfach, 10 Zahlen zu produzieren, die von einem Menschen gelesen werden, ist schwierig. Überfällige Aufträge sind nicht immer relevant: Vielleicht sind die Lagerbestände sowieso noch hoch oder es handelt sich nur um ein wiederkehrendes Problem bei diesem Lieferanten, das schon immer besteht. Unvollständige Lieferungen sollten ebenfalls automatisch bearbeitet werden, um die Lieferantenzahlungen entsprechend zu korrigieren, erfordern jedoch nicht immer eine sofortige Reaktion. Damit ein “Element” einen ROI hat, sollte das “Element” “handlungsrelevant” sein und der ROI repräsentiert den damit verbundenen geschätzten ROI der Maßnahme. Lokad glänzt durch die Bereitstellung maßgeschneiderter Priorisierungen, die genau auf die Besonderheiten der jeweiligen Supply Chain zugeschnitten sind.

Modul für Geschäfte/Vorabkäufe

Die Arten von Modulen für “Geschäfte/Vorabkäufe” ermöglichen es dem Käufer, die Geschäftsdaten vor dem Geschäftszeitraum in das System einzugeben. Dadurch kann das System Auffüllbestände kaufen, die zum Geschäftszeitraum passen, Vorabkaufmengen berechnen und bestimmen, wann diese Mengen gekauft werden sollen.

Die meisten APS wurden ursprünglich mit einer naiven Perspektive implementiert, bei der der “Stückpreis” als ausreichend angesehen wurde, um eine optimierte Bestellmenge zu berechnen. Die Realität war jedoch detaillierter. Lieferanten haben häufig komplexe Preisstrukturen: Mindestbestellmengen, Preisstaffeln, Rabatte auf vierteljährliche Quoten, temporäre Angebote usw.

Lokad behandelt all diese Elemente als “Eingabedaten und Eingabebeschränkungen” und nutzt eine direkte numerische Lösung eines begrenzten Problems, um eine “optimierte” Bestellmenge zu liefern. Zum Beispiel bietet ein temporärer Rabatt auf die Lieferung einen wirtschaftlichen Anreiz für das Unternehmen, vorübergehend zu überbestücken: Die Bestellmenge wird zum numerischen Kompromiss zwischen dem zusätzlichen Rabatt (lineare Gewinne) und dem Risiko der Überbestückung (superlineare Kosten). Wir liefern die Bestellmenge, die diesen Kompromiss direkt optimiert, zusätzlich zu allen anderen relevanten wirtschaftlichen Kräften.

Modul zur Auftragsanalyse

Die Module zur “Auftragsanalyse” identifizieren potenzielle Lagerbestandsengpässe. Diese Module liefern die aktuellen Informationen, die benötigt werden, um den Lagerbestand für Artikel wie Importe oder kundenspezifische Fertigung - langfristige Artikel, für die oft zwei, drei oder mehr Bestellungen ausstehen - zu verstehen.

Dies ist ein weiterer Fall von etwas simplistischem “ease-of-implementation” Software-Design. In den 80er Jahren war es schwierig, jede Art von netzwerkweiter Analyse durchzuführen. Daher haben die meisten Softwareanbieter standardmäßig ein Software-Design übernommen, das eine “SKU-Isolation” erzwingt. Jeder SKU wird isoliert verarbeitet und die berechneten statistischen Schätzer - wie die erwartete Wahrscheinlichkeit eines Lagerbestandsengpasses für den nächsten Bestellzyklus - sind alle vollständig spezifisch für den interessierenden SKU.

Bei Lokad stellen wir fest, dass jeder einzelne SKU mit allen anderen SKUs um das Budget des Unternehmens konkurriert. Daher spielt es keine Rolle, ob die Lagerbestandsengpasswahrscheinlichkeit eines bestimmten SKUs hoch oder niedrig ist. Das Einzige, was zählt, ist, ob der Return on Investment (ROI) für die Bestellung mehr dieses SKUs hoch genug ist, um von keiner anderen Alternative - d.h. mehr von einem anderen SKU zu bestellen - ausgestochen zu werden, die dem Unternehmen zur Verfügung steht. Wenn beispielsweise der SKU mit einem Produkt verbunden ist, das hohe Kosten, eine sehr niedrige Marge und nur von einem einzigen großen Unternehmenskunden gekauft wird, der laut Vertriebsteam kurz davor steht zu gehen, ist die Aufrechterhaltung des Servicelevels für diesen SKU ein sicheres Rezept für die Schaffung von totem Lagerbestand.

Bei Lokad werden priorisierte Bestellmengen geliefert, die direkt die End-to-End-Wirtschaftlichkeit der Supply Chain widerspiegeln.

Überbestands-Transfermodul

Überbestands-Transfer-Module helfen den Einkäufern, Überbestände in den Lagern zu verwalten. Es ermöglicht den Einkäufern, überschüssigen Lagerbestand von einem Ort an einen anderen zu transferieren, der eine ausreichende Nachfrage hat, um zusätzliche Einkäufe beim Lieferanten zu vermeiden.

In der Supply Chain ist es fast immer möglich, aber in der Regel nicht profitabel, etwas von Ort A nach Ort B zu bewegen. Daher ist es nur natürlich, jede Lagerbewegung zwischen zwei Standorten als eine potenzielle Entscheidung zu behandeln, wenn man es mit einem Netzwerk zu tun hat, in dem dasselbe Produkt an vielen Standorten gelagert werden kann.

Daher verfügt Lokad über integrierte Fähigkeiten zur netzwerkweiten Optimierung dieser Art, bei der alle verfügbaren Optionen für Lagerbewegungen durchprobiert werden. Der anspruchsvollste Teil des Unterfangens besteht darin, die mit der Lagerbewegung verbundenen wirtschaftlichen Reibungsverluste angemessen abzubilden. Tatsächlich werden die Reibungsverluste in der Regel nicht angemessen durch Lagerbewegungen auf SKU-Ebene widergespiegelt. Zum Beispiel sind Transportkosten in der Regel stark nichtlinear: Wenn ein LKW losgeschickt werden muss, nutzen wir das verfügbare Ladevolumen optimal aus.

Leider wächst die Anzahl der Optionen viel schneller als die Anzahl der SKUs. Betrachten wir ein Netzwerk, das 2000 Artikel in 10 Lagern enthält, was insgesamt 10 x 2000 = 20.000 SKUs ergibt. Die Gesamtzahl der zu berücksichtigenden Kanten für die Lagerbewegungen beträgt 10 x (10 - 1) * 2000 = 180.000 Kanten, eine Zahl, die viel größer ist als die ursprüngliche Anzahl der SKUs. Für die Leser, die mit Algorithmen vertraut sind, handelt es sich um einen Fall von quadratischer Komplexität.

Doch wenn man die heutzutage verfügbare Rechenleistung betrachtet, ist dieser spezielle Fall von quadratischer Komplexität größtenteils unproblematisch - vorausgesetzt, die zugrunde liegende Software wurde für diese Art von numerischer Exploration ordnungsgemäß entwickelt. Tatsächlich überschreiten Supply Chain-Netzwerke sehr selten 10.000 Standorte, selbst wenn man die größten Unternehmen betrachtet; und einige Heuristiken können verwendet werden, um die Anzahl der zu erkundenden Kanten in der Praxis dramatisch zu reduzieren, da viele Standortpaare unsinnig sind, wie z.B. die Neuausrichtung von Beständen zwischen Paris und Sydney.

Allerdings hatten APS in den 80er und 90er Jahren aufgrund der damals verfügbaren Hardware bereits Schwierigkeiten, mit der Anzahl der SKUs umzugehen. Natürlich war es in diesem Kontext undenkbar, mit Problemen quadratischer Komplexität umzugehen.

Heutzutage mussten viele Anbieter separate Module einführen, um mit jeder Art von Problem zu bewältigen, das eine netzwerkweite Optimierung erfordert. Es gibt keine wirkliche geschäftliche Motivation für ein separates Modul. Dieser Zustand spiegelt größtenteils wider, dass der ursprüngliche Anbieter sein Softwareprodukt mit Klebeband repariert hat, um mit einer Klasse von Problemen umzugehen, die im Widerspruch zu Designentscheidungen stehen, die vor zwei Jahrzehnten getroffen wurden.

Im Gegensatz dazu hat Lokad beschlossen, diese Klasse von Problemen frontal anzugehen, die in unserem Software-Stack erstklassige Bürger sind. Natürlich erfordert die tatsächliche Lösung der Herausforderung immer noch Anstrengungen in der Praxis, da alle Transportkosten und -beschränkungen explizit gemacht werden müssen.

Planungsmodul

Planungs-Module ermöglichen es Vertriebs- oder Marketingteams, Bestellungen für bestimmte Ereignisse wie Promotionen oder Sonderbestellungen im Voraus zu planen. Teams können eine geplante Bestellung im System mehr als ein Jahr im Voraus des geplanten Bestelldatums erstellen.

Lokads Ansatz beginnt mit einer klaren Trennung zwischen Fakten und Vorhersagen. Betrachten wir ein B2B-Einzelhandelsnetzwerk. Wenn ein Kunde am 10. Februar ankündigt, dass er 1000 Einheiten bestellen wird, mit einem voraussichtlichen Lieferdatum am 1. März, dann ist diese Ankündigung ein Fakt. Wenn dieser Kunde die Angewohnheit hat, sein beabsichtigtes Lieferdatum in letzter Minute zu überdenken - typischerweise um eine Woche zu verschieben - dann muss dieses Muster berücksichtigt werden. Diese Musteranalyse fällt jedoch in den Bereich der Vorhersagen.

Lokad geht diese Art von Problemen mit einer Technologie an, die allgemeine probabilistische Prognosen liefert und nicht nur nachfrageprobabilistische Prognosen. Jede Aussage über die Zukunft, wie ein erwartetes Ankunftsdatum, ist tendenziell in gewissem Maße unsicher. Lieferketten erfordern vielseitige hochdimensionale Vorhersagewerkzeuge, genau aus diesem Grund hat sich Lokad für den Weg des differenzierbaren Programmierens entschieden.

Außerdem dürfen Fakten nicht von der Analyseebene erfasst werden, weder von Lokad noch von der APS. Nicht, weil die Software es nicht kann. Die Gestaltung einer Software zur Erfassung von Fakten ist relativ einfach, aber sie erzeugt eine hohe Menge an zufälliger Anbieterbindung. Tatsächlich wird ein System im Unternehmen, sobald Daten eingehen, zum de facto Master-Controller dieser Daten.

Unsere Erfahrung bei Lokad zeigt, dass veraltete Analyseebenen oft noch mindestens ein Jahrzehnt nach ihrem Obsoleszenzpunkt bestehen bleiben, aus keinem anderen Grund, als dass geschäftskritische Daten verloren gehen würden, wenn dieses System ausgeschaltet würde. In der Zwischenzeit erhebt der ursprüngliche Softwareanbieter weiterhin Wartungsgebühren, was dem Anbieter einen großen Anreiz gibt, das Problem von Anfang an zu schaffen.

Prognosemodul

Die Prognose-Module ermöglichen es Käufern, Berichte zu erstellen, die zukünftige Nachfrage und zukünftige Einkäufe bis zu einem Jahr im Voraus projizieren. Diese Prognosen können mit den Lieferanten geteilt werden, um ihnen zu ermöglichen, ihre jeweiligen Lieferkapazitäten genauer zu planen.

Nackte Prognosen sind schädlich und können nicht mehr als vernünftige Supply-Chain-Praxis angesehen werden. Lesen Sie das Antipattern der nackten Prognosen für weitere Informationen. Das bedeutet nicht, dass Lokad keine Prognosefähigkeiten hat, das haben wir. Wir sind jedoch der Meinung, dass der klassische Zeitreihenprognoseansatz einfach falsch ist und beendet werden muss. Klassische Zeitreihen können für sehr hohe Volumina, sehr stabile Produkte funktionieren, aber für alles andere - insbesondere für unregelmäßige oder intermittierende Nachfrage - ist die probabilistische Prognose der richtige Weg.

Darüber hinaus wiesen historische Zeitreihenprognosemodelle - wie Holt-Winters oder Arima - massive Mängel auf, wenn die Produktgeschichte zu kurz, zu unregelmäßig, zu atypisch, zu geringvolumig usw. war. Die meisten Softwareanbieter reagierten auf diese Probleme mit zwei Ansätzen, die beide auf ihre eigene Weise dysfunktional waren:

• Menschliche Coprozessoren: Da das Prognosemodell häufig zu unsinnigen Ergebnissen führt, werden menschliche Bediener - d.h. Planer - vom System als “Coprozessoren” verwendet, um Prognosen manuell zu überschreiben, wann immer die “Zahlen nicht stimmen”. Leider ist die Aufgabe endlos, da Prognosen kontinuierlich aktualisiert werden müssen und Planer in einen endlosen Zyklus manueller Überschreibungen gezwungen werden. Eine solche Aufgabe hat auch unerwünschte Nebenwirkungen, bei denen menschliche Bediener dazu verwendet werden, anzunehmen, dass Prognosen falsch sind, und dazu neigen, sie auch dann zu korrigieren, wenn sie es nicht sind, oft basierend auf reinem Bauchgefühl.
• Modellwettbewerb: Da jedes Zeitreihenprognosemodell seine eigenen Stärken und Schwächen hat, sollte ein Wettbewerb vieler Prognosemodelle - so die Überlegung - gute Ergebnisse liefern, indem das System das beste Modell in jeder einzelnen Situation “auswählt”. Leider scheitert dies aus zwei Gründen. Erstens beruhen alle Modelle auf einem Zeitreihen-Framework und unterliegen somit allen gleichen Einschränkungen. Zweitens sind alle Modelle “klassisch” und liefern keine probabilistischen Prognosen, die die Supply Chain erfordert.

Darüber hinaus geht es bei der Prognose nicht nur um die Nachfrage. Auch die Vorlaufzeiten sollten prognostiziert werden. Auch die Struktur der Supply Chain ist wichtig. Im B2B-Bereich kann ein stetiger Strom von Verkäufen verbergen, dass alle Bestellungen vom selben Kunden stammen. Wenn dieser Kunde verloren geht, werden viele Artikel sofort überbestückt, wenn nicht sogar als Tote Lagerbestände. Eine ordnungsgemäße vorhersagende Optimierung der Supply Chain muss dieses Risiko berücksichtigen. Die Technologie von Lokad wurde entsprechend entwickelt.

In Bezug auf die gemeinsame Nutzung von Prognosen mit Lieferanten haben wir festgestellt, dass erfolgreiche prognosegesteuerte Koordinationen zwischen Unternehmen selten sind. Lieferanten haben sowieso viele eigene Kunden³. Selbst wenn die von den lokalen Käufern gelieferten Prognosen genau wären, hat der Lieferant keine Möglichkeit, all diese unterschiedlichen Prognosen in Einklang zu bringen: die Summe der Prognosen ist NICHT die Prognose der Summe.

Sicherheitsmodul

Überraschenderweise sind für einige APS Sicherheitsfunktionen nicht standardmäßig im System enthalten, sondern werden als separates Modul bereitgestellt. Der Zweck eines Sicherheitsmoduls besteht darin, den Zugriff für bestimmte Benutzer zu verhindern. Es ermöglicht auch dem Management, Komponentenaktionen zu sichern und Ansichten für wichtige Bereiche des Systems, wie Unternehmenssteuerungsfaktoren, Artikelwartung, Lieferantenwartung, Bestellungen, Deals und andere Komponenten, einzuschränken.

In der Software-Jargon sprechen wir hier von den übergreifenden Anliegen der Authentifizierung und Autorisierung.

• Die Authentifizierung stellt sicher, dass Endbenutzer, die im System etwas tun, wirklich die Person sind, für die das System sie hält. Lokad verfolgt hier den modernen Ansatz, dass die Authentifizierung möglichst delegiert werden sollte. Endbenutzer sollten nicht noch ein Passwort haben müssen. Stattdessen nutzt Lokad SAML als den de facto Industriestandard, um die Authentifizierung an das föderierte Identitätsmanagement (FIM) zu delegieren.
• Die Autorisierung ermöglicht die fein abgestimmte Kontrolle darüber, wer was tun kann innerhalb des Systems. Lokad verfügt hier über ein umfangreiches kanonisches ACL (Access-Control List) System, das auch die de facto Praxis moderner Unternehmenssysteme ist. Lokad verfügt auch über einige Personalisierungsmöglichkeiten, die das ACL aus einer Benutzererfahrungsperspektive ergänzen.

Lokad aktiviert standardmäßig alle seine Sicherheitsfunktionen, unabhängig davon, welches Paket ursprünglich an einen unserer Kunden verkauft wurde. Wir sind der Meinung, dass optionale Sicherheit⁴ eine schreckliche Praxis von Softwareanbietern ist. Die Sicherung von Software ist bereits äußerst schwierig; eine solche Praxis macht es nur noch schlimmer.

Um fair zu sein, ist der ACL-Aspekt wahrscheinlich das am wenigsten herausfordernde Anliegen der gesamten Frage der Software-Sicherheit. Eine interessantere Frage ist: Wie viel Sicherheit durch Design liefert die Architektur des Systems selbst? Die Beantwortung dieser Frage geht jedoch über den Rahmen des vorliegenden Artikels hinaus.

Export nach Excel

Das Modul Export nach Excel bietet eine einfache Möglichkeit, Daten für die Verwendung in anderen Systemen oder für die Analyse zu transportieren.

Da es recht einfach ist, Excel-Tabellen zu erstellen⁵, bieten viele Anbieter - einschließlich Lokad - Funktionen in diesem Bereich an. Bei genauerer Betrachtung zeigt sich jedoch, dass die meisten Anbieter nur halbherzige Funktionen bieten. Lassen Sie uns die wichtigsten Punkte guter Export-to-Excel-Implementierungen überprüfen:

• Vollständige Historisierung: Das System sollte die Möglichkeit bieten, jede einzelne jemals exportierte Excel-Tabelle zu verfolgen und erneut herunterzuladen. Tatsächlich wird es bei falschen Zahlen in der Tabelle - ein Problem, das aufgrund falscher Dateninputs auftritt - äußerst kompliziert, zeitaufwändig und manchmal sogar unmöglich sein, das Problem zu debuggen und zu beheben, wenn der Codepfad, der diese Tabelle generiert hat, nicht vollständig nachvollziehbar ist.
• Maximale Ausnutzung der Tabellenkalkulationsfunktionen: Anwender erwarten, dass sie umfangreiche Tabellenkalkulationen mit bis zu 1 Million Zeilen⁶ erstellen können, was dem Limit von Excel selbst entspricht. Das System sollte also in der Lage sein, umfangreiche Tabellenkalkulationen zu generieren, um Anwendern, die ihre eigenen Datenanalysen mit einem vertrauten Tool durchführen möchten, nicht im Weg zu stehen. Selbstverständlich erwarten Anwender auch, dass diese umfangreichen Exporte schnell erfolgen.
• Integrierter Schutz vor Tabellenkalkulationsangriffen: Excel ist ein gefährlicher Angriffsvektor für große Organisationen. Leider kann die Sicherung der vom System generierten Tabellenkalkulationen nicht als nachträglicher Gedanke betrachtet werden, sondern muss von Anfang an integraler Bestandteil des Designs sein.
• Programmatische Konfigurierbarkeit der Exporte: Die Arbeit mit zwei Softwarekomponenten - nämlich dem APS und Excel - ist für die Supply-Chain-Experten bereits schmerzhaft genug. Die Situation sollte nicht dadurch verschlimmert werden, dass Tabellenkalkulationen immer eine zusätzliche Nachbearbeitung erfordern, um sie verwendbar zu machen. Dies bedeutet, dass alles vor der Extraktion im APS geschieht. Das APS benötigt also programmatische Fähigkeiten, um die Tabellenkalkulationen vor dem Export ordnungsgemäß vorzubereiten.

Lokad bietet all dies, während die meisten unserer Konkurrenten dies nicht tun. Der Teufel steckt im Detail.

Fazit

Unsere Überzeugung ist, dass Lokad eine einfachere Software ist als die meisten APS auf dem Markt. Dennoch ist unsere Fähigkeit, Leistung in der Lieferkette durch prädiktive Technologien zu liefern, größer. Tatsächlich ist die meiste Komplexität des APS zufällig, die aus Software-Designentscheidungen resultiert, die vor Jahrzehnten getroffen wurden und sich mit längst vergangenen softwarebezogenen Problemen befassen. Die meisten architektonischen Softwareentscheidungen können jedoch nicht rückgängig gemacht werden.