Quantitatives SCM vs Klassisches APS

Joannes Vermorel

Während supply chains in den 80er und 90er Jahren mit elektronischem inventory management und EDI (Electronic Data Interchange) einen frühen Start in die Digitalisierung hatten, gerieten viele software vendors – und damit die meisten ihrer Kunden – in den folgenden zwei Jahrzehnten allmählich ins Hintertreffen. Obwohl es relativ einfach ist, Benutzeroberflächen zu modernisieren, beispielsweise indem Desktop-Anwendungen in Web-Anwendungen umgewandelt werden, ist es in der Regel viel herausfordernder, die Kernentscheidungen der Architektur zu überdenken, die ein piece of software unterstützen. Die meisten dieser Lösungen waren nie für Cloud Computing, Machine Learning oder eine Mobile-first-Benutzererfahrung – um nur einige zu nennen – konzipiert.

Lokad plädiert für Prozesse und Technologien, die das Beste aus der modernen vernetzten Rechenleistung für supply chains herausholen, durch bessere prädiktive Optimierungen. Wir bezeichnen diesen Ansatz als die Quantitative Supply Chain-Perspektive. Allerdings kann diese Botschaft für supply chain Praktiker etwas verwirrend sein, da Quantitative Supply Chain nicht eine Abwandlung der alten Wege zur Optimierung von supply chain darstellt, sondern etwas ganz anderes ist.

Lasst uns also einen genaueren Blick auf die traditionellen Module werfen, wie sie üblicherweise in führenden¹ APS (Advanced Planning and Scheduling) Systemen zu finden sind, mit einem besonderen Interesse an Lager replenishments in einem 2-Ebenen-Netzwerk – z.B. warehouses und Filialen – und vergleichen wir diese Module mit Lokads Art, prädiktive Optimierungen zu liefern. Der Kürze halber beziehen wir uns im Folgenden austauschbar auf die die Quantitative Supply Chain (die Vision) oder auf Lokad (die Softwareimplementierung).

Kalendermodul

Ein Kalender-Modul bietet Mechanismen, um Bestellsituationen feinzujustieren, d.h. zu entscheiden, wann gekauft wird, falls ein fester Bestellzyklus unvermeidlich ist.

Allein die Idee, dass supply chain Praktiker ihren Bestellplan feinjustieren sollten, greift das Problem aus der falschen Perspektive an. Bestellungen unterliegen mehreren Arten von Beschränkungen: Kalender, MOQs, Budget usw. Manche Beschränkungen können locker sein, wie etwa „kein fester Plan, jeder Tag ist möglich, außer dem 4. Juli und dem 25. Dezember“, oder streng, wie „der Container muss exakt voll sein“. In jedem Fall sollte das System – innerhalb aller machbaren Bestelloptionen – diejenige auswählen, die den ROI maximiert. Dieser Prozess, die „Optimierung“, muss strikt automatisiert erfolgen. Es gibt keinen Grund, irgendetwas manuell nachzujustieren. Leistungsfähige numerische Lösungsverfahren waren in den 80er Jahren nicht routinemäßig verfügbar, aber heute ist dies nicht mehr der Fall.

Daher sammeln wir bei Lokad alle relevanten Beschränkungen, die selbst als Daten behandelt werden, d.h. als die „Datenbank“ der zugelassenen Bestellpläne, und setzen dann die entsprechenden numerischen Lösungsverfahren ein, um die Aufgabe zu bewältigen.

Siehe auch Humans in modern supply chain.

Event-Modul

Das Event-Modul steuert Nachfragespitzen und -rückgänge, die durch geplante Ereignisse verursacht werden, wie z.B. new product Einführungen, Werbung, Preis-promotions, Katalogveröffentlichungen und Prospekte.

Die frühesten Prognosemodelle (z.B. Holt-Winters), die in den 50er und 60er Jahren entdeckt wurden, konzentrierten sich alle auf time-series. Folglich übernahmen die meisten APS time-series-zentrierte Perspektiven. Leider lassen sich supply chain problems nicht einfach in time-series einbetten: stock-outs, Promotions, Einführungen und Ausphasierungen sind Phänomene, die nicht in das traditionelle mathematische Rahmenwerk von time-series passen. Um den von vornherein fehlerhaft konstruierten time-series-Prognosemodellen zu begegnen, greifen APS auf manuelle „Korrekturen“ zurück, die sowohl auf historische Daten – z.B. zur Glättung des Effekts vergangener Promotions – als auch auf Nachfrageprognosen – zur Einführung von Verzerrungen in zukünftige Schätzungen – angewendet werden.

Bei Lokad besteht unser Ansatz darin, diese „Störungen“ als gewöhnliche historische Daten zu behandeln. Wir werden niemals mit Sicherheit wissen, was passiert wäre, wenn eine vergangene Promotion nicht ausgelöst worden wäre. Das Einzige, was wir mit Sicherheit wissen, sind die Eigenschaften der Promotion – d.h. Start- und Endtermine, Rabattmechanismen, Gültigkeitsbereich usw. – und die daraus resultierenden Umsätze. Daher muss das statistische Modell so konzipiert werden, dass es die historischen Daten so verarbeitet, wie sie vorliegen, anstatt in einer engen time-series-Perspektive „gefangen“ zu sein.

Lokad sammelt die relevanten Ereignisse und verarbeitet all diese Daten mit statistischen Modellen, die auf hochdimensionale Probleme ausgerichtet sind und typischerweise unter den allgemeinen Begriff der „machine learning“-Algorithmen fallen. Die neueste Version unserer Prognosetechnologie basiert auf differentiable programming. Allerdings ist sie nach wie vor ein in Arbeit befindlicher Prozess, da sich das machine learning-Feld selbst noch rasant weiterentwickelt. Der Bedarf, die Prognoseergebnisse manuell anzupassen, sollte als Softwarefehler betrachtet werden, der behoben werden muss, und nicht als Gelegenheit, supply chain Praktiker als „human coprocessors“ einzusetzen.

In der Praxis besteht der Großteil der Herausforderung darin, die relevanten Daten sowohl über vergangene Ereignisse als auch über zukünftige (z.B. geplante Promotions) zu erfassen – was nur wenig mit Statistik zu tun hat. Außerdem sind die Analysesysteme, sei es Lokad oder ein APS, nicht der Ort, um große Mengen manueller Dateneingaben vorzunehmen. Diese Dateneingaben gehören zum transaktionalen Bereich – alias das ERP –, das alle facts² über die supply chain sammelt.

Order Expedite Management Modul

Ein Order Expedite Management dient als Frühwarnsystem und stellt den Einkäufern einen täglich aktualisierten Überblick über überfällige Bestellungen und Teillieferungen zur Verfügung.

Der gesamte Ansatz von exceptions und alerts ist eine eher veraltete Herangehensweise, um Probleme innerhalb komplexer Systeme in der Softwareindustrie zu mildern. Dieser Ansatz wurde in den 80er und 90er Jahren von Softwareanbietern stark übernommen, da exceptions und alerts mit einer SQL-Datenbank einfach zu implementieren sind. Es bedarf nur eines SELECT-Statements mit wenigen WHERE-Bedingungen. Insgesamt führt dieser Ansatz jedoch zu einer schlechten Nutzung der knappen Ressource, die supply chain Praktiker darstellen, da er sie schnell überlastet, bis hin zu dem Punkt, an dem Alerts nicht mehr als solche wahrgenommen werden und das Gefühl von Dringlichkeit oder Handlungsbedarf verloren geht.

Lokad bevorzugt und liefert eine strenge ROI-basierte Priorisierung der „Items“ von Interesse, die den supply chain Praktikern präsentiert werden. Als Faustregel gilt, dass es einfach ist, 1 Million Zahlen pro Tag zu produzieren, während es schwierig ist, 10 Zahlen zu erzeugen, die es wert sind, von einem Menschen gelesen zu werden. Überfällige Bestellungen sind nicht immer von Bedeutung: Vielleicht sind die stock levels sowieso noch hoch, oder es handelt sich lediglich um ein wiederkehrendes Problem bei diesem Lieferanten, das schon ewig besteht. Teillieferungen sollten ebenfalls automatisch verarbeitet werden, um die Zahlungen an den Lieferanten entsprechend zu korrigieren, aber sie erfordern nicht immer eine sofortige Reaktion. Damit ein „Item“ einen ROI erzielt, muss das „Item“ actionable sein, und der ROI repräsentiert den damit verbundenen geschätzten ROI der Maßnahme. Lokad überzeugt, indem es maßgeschneiderte Priorisierungen liefert, die genau auf die Spezifika der jeweiligen supply chain zugeschnitten sind.

Deal/Forward Buy Modul

Die Deal/Forward Buy-Module ermöglichen es dem Einkäufer, Angebotsdaten in das System einzuspeisen, noch bevor der Angebotszeitraum beginnt. Dies erlaubt es dem System, Auffüllbestände anzuschaffen, die dem Angebotsfenster entsprechen, Forward Buy Mengen zu berechnen und zu bestimmen, wann diese Mengen zu kaufen sind.

Die meisten APS wurden ursprünglich mit einer naiven Perspektive implementiert, bei der der unit price als in sich abgeschlossen – preislich – angenommen wurde, um eine optimierte Bestellmenge zu berechnen. Die Realität weist jedoch ein höheres Detaillierungsniveau auf. Lieferanten haben häufig komplexe Preisstrukturen: MOQs, Mengenrabatte, Rabatte auf Quartalsquoten, temporäre Angebote usw.

Lokad behandelt all diese Elemente als input data and input constraints und nutzt eine direkte numerische Lösung eines beschränkten Problems, um eine optimized Bestellmenge zu liefern. Zum Beispiel bietet ein temporärer Rabatt des Lieferanten einen wirtschaftlichen Anreiz für das Unternehmen, vorübergehend Überbestände aufzubauen: Die Bestellmenge wird zum numerischen Abwägungspunkt zwischen dem zusätzlichen Rabatt (lineare Gewinne) und dem Risiko von Überbeständen (überlineare Kosten). Wir liefern die Bestellmenge, die diesen Kompromiss direkt optimiert, neben allen anderen relevanten wirtschaftlichen Faktoren.

Order Analysis Modul

Die Order Analysis-Module identifizieren potenzielle Fehlbestände. Diese Module liefern die aktuellen Informationen, die benötigt werden, um den Lagerstatus für Artikel wie Importe oder individuell hergestellte Produkte – langvorlaufende Artikel, für die häufig zwei, drei oder mehr Bestellungen offenstehen – zu verstehen.

Dies ist ein weiteres Beispiel für ein etwas simplistisches, auf einfache Implementierung ausgerichtetes Softwaredesign. In den 80er Jahren war es schwierig, jegliche Art von netzwerkweiten Analysen durchzuführen, weshalb die meisten Softwareanbieter standardmäßig ein Softwaredesign verfolgten, das eine „SKU-Isolation“ erzwingt. Jede SKU wird isoliert bearbeitet, und die berechneten statistischen Schätzer – wie die erwartete Fehlbestandswahrscheinlichkeit für den nächsten Bestellzyklus – sind vollständig spezifisch für die jeweilige SKU.

Bei Lokad stellen wir fest, dass jede einzelne SKU mit allen anderen SKUs um das Budget des Unternehmens konkurriert. Daher spielt es keine wesentliche Rolle, ob die Fehlbestandswahrscheinlichkeit einer bestimmten SKU hoch oder niedrig ist. Entscheidend ist einzig, ob sich die Investition in eine höhere Bestellmenge für diese SKU so rentiert, dass sie nicht von einer alternativen Option – d.h. der Bestellung einer anderen SKU – übertroffen wird, die dem Unternehmen zur Verfügung steht. Zum Beispiel: Wenn die SKU einem Produkt zugeordnet ist, das hohe Kosten, eine sehr geringe Marge und ausschließlich von einem großen Firmenkunden gekauft wird, der laut Vertriebsteam kurz davor steht zu wechseln, dann ist die Aufrechterhaltung des service level für diese SKU ein sicheres Rezept dafür, tote Lagerbestände zu schaffen.

In der Praxis liefert Lokad prioritized order quantities, die die End-to-End-Ökonomie der supply chain direkt widerspiegeln.

Overstock Transfer Modul

Overstock transfer-Module helfen den Einkäufern, Überbestände in den Lagern zu verwalten. Sie ermöglichen es den Einkäufern, überschüssige Lagerbestände von einem Standort zu einem anderen mit ausreichender Nachfrage zu verlagern, um zusätzliche Einkäufe beim Lieferanten zu vermeiden.

In supply chain ist es nahezu immer möglich – aber in der Regel nicht profitabel – etwas von Standort A zu Standort B zu verlagern. Daher ist es bei einem Netzwerk, in dem derselbe Artikel an vielen Orten gelagert werden kann, nur folgerichtig, jede Lagerbewegung zwischen zwei Standorten als eine potenzielle Entscheidung zu behandeln.

Daher verfügt Lokad über integrierte Fähigkeiten, um Optimierungen auf Netzwerkebene dieser Art durchzuführen, indem im Grunde alle verfügbaren Optionen für Lagerbewegungen durchprobiert werden. Der herausforderndste Teil dieser Aufgabe besteht darin, die mit der Lagerbewegung verbundenen economic friction angemessen abzubilden. Tatsächlich werden die Reibungsverluste in der Regel nicht angemessen auf der Ebene der SKU dargestellt. Zum Beispiel neigen Transportkosten dazu, hochgradig nicht-linear zu sein: Wenn ein LKW eingesetzt werden muss, sollte dessen verfügbare Kapazität bestmöglich genutzt werden.

Leider wächst die Anzahl der options viel schneller als die Anzahl der SKUs. Betrachten wir ein Netzwerk, das 2000 Artikel in 10 Lagern umfasst, was insgesamt zu 10 x 2000 = 20.000 SKUs führt. Die Gesamtzahl der edges, die für die Lagerbewegungen berücksichtigt werden müssen, beträgt 10 x (10 - 1) * 2000 = 180.000 edges – eine Zahl, die viel größer ist als die ursprüngliche Anzahl der SKUs. Für Leser, die mit Algorithmen vertraut sind, handelt es sich um ein klassisches Beispiel quadratischer Komplexität.

Angesichts der heutzutage verfügbaren Rechenleistung ist dieser spezifische Fall quadratischer Komplexität jedoch größtenteils kein Problem – vorausgesetzt, die zugrunde liegende Software wurde für diese Art von numerischer Exploration ordnungsgemäß entwickelt. Tatsächlich überschreiten supply chain Netzwerke selten 10.000 Standorte, selbst bei den größten Unternehmen; und einige Heuristiken können genutzt werden, um die Anzahl der in der Praxis zu untersuchenden edges dramatisch zu reduzieren, da viele Standortpaare schlichtweg unsinnig sind, wie etwa das Umverteilen von Beständen zwischen Paris und Sydney.

Doch in den 80er und 90er Jahren, bedingt durch die damals verfügbare Rechenhardware, hatten APS bereits Schwierigkeiten, mit der Anzahl der SKUs zurechtzukommen. Natürlich war es in diesem Zusammenhang schlicht und einfach unmöglich, Probleme quadratischer Komplexität zu bewältigen.

Springen wir in die Gegenwart: Viele Anbieter mussten separate Module einführen, um jegliche Art von Problemen mit netzwerkweiter Optimierung zu bewältigen. Es gibt keinen echten geschäftlichen Anreiz für ein separates Modul. Dieser Zustand spiegelt vor allem wider, dass der ursprüngliche Anbieter sein Softwareprodukt notdürftig zusammengeflickt hat, um mit einer Problemklasse umzugehen, die im Widerspruch zu Designentscheidungen steht, die vor zwei Jahrzehnten getroffen wurden.

Im Gegensatz dazu hat sich Lokad entschieden, diese Problemklasse, die in unserem Software-Stack erstklassig behandelt wird, direkt anzugehen. Natürlich erfordert die tatsächliche Lösung der Herausforderung in der Praxis weiterhin Anstrengungen, da alle Transportkosten und -beschränkungen explizit erfasst werden müssen.

Planning Modul

Planning-Module ermöglichen es Vertriebs- oder Marketingteams, Bestellungen für spezifische Ereignisse wie Promotions oder Sonderbestellungen vorzuplanen. Teams können im System bereits mehr als ein Jahr vor dem geplanten Bestelldatum eine geplante Bestellung anlegen.

Lokads Ansatz beginnt damit, eine klare Trennung zwischen Fakten und Vorhersagen herzustellen. Nehmen wir ein B2B-Retail-Netzwerk als Beispiel. Wenn ein Kunde am 10. Februar ankündigt, dass er 1000 Einheiten bestellen wird, mit einem erwarteten Liefertermin am 1. März, dann ist diese Ankündigung ein Fakt. Wenn dieser Kunde die Angewohnheit hat, den vorgesehenen Liefertermin in letzter Minute zu überdenken – typischerweise indem er ihn um 1 Woche verschiebt – muss dieses Muster berücksichtigt werden. Allerdings fällt diese Musteranalyse in den Bereich der Vorhersagen.

Lokad geht dieses Problemfeld mit einer Technologie an, die allgemeine probabilistische Prognosen liefert und nicht nur nachfragebezogene probabilistische Prognosen. Jede Aussage über die Zukunft, etwa ein erwartetes Ankunftsdatum, ist gewissermaßen mit Ungewissheit behaftet. supply chains erfordern vielseitige, hochdimensionale prädiktive Werkzeuge, weshalb Lokad den Pfad des differenzierbaren Programmierens eingeschlagen hat.

Außerdem dürfen Fakten nicht von der Analytics-Schicht erhoben werden, weder von Lokad noch vom APS. Nicht, weil die Software es nicht vermag. Software zu entwerfen, die Fakten sammelt, ist relativ unkompliziert, aber weil dies zu einem hohen Maß an accidentellem Vendor Lock-in führt. Denn sobald Dateneingaben durch ein System im Unternehmen fließen, wird dieses System zum de facto Hauptkontrolleur dieser Daten.

Unsere Erfahrungen bei Lokad zeigen, dass veraltete Analytics-Schichten häufig noch ein zusätzliches Jahrzehnt über ihren Obsoleszenzzeitpunkt hinaus bestehen bleiben, nur weil geschäftskritische Daten nicht verloren gehen würden, wenn dieses System abgeschaltet würde. Inzwischen kassiert der ursprüngliche Softwareanbieter weiterhin Wartungsgebühren, was diesem einen großen Anreiz verschafft, das Problem überhaupt erst zu erzeugen.

Projections module

Die Projektionen-Module ermöglichen es Käufern, Berichte zu erstellen, die zukünftige Nachfrage und zukünftige Käufe bis zu einem Jahr im Voraus projizieren. Diese Prognosen können mit den Lieferanten geteilt werden, um ihnen eine präzisere Planung ihrer jeweiligen Lieferkapazitäten zu ermöglichen.

Bloße Prognosen sind schädlich und können nicht länger als sinnvolle supply chain-Praxis betrachtet werden. Weitere Informationen finden Sie im Antimuster der bloßen Prognosen. Dies bedeutet nicht, dass Lokad keine Prognosefähigkeiten besitzt, wir tun es. Wir sind jedoch der Auffassung, dass der klassische Ansatz der Zeitreihenprognose einfach falsch ist und ein Ende finden muss. Klassische Zeitreihen können bei sehr hohen Mengen und sehr konstanten Produkten funktionieren, aber bei allem anderen – und insbesondere bei schwankender oder intermittierender Nachfrage – ist probabilistische Prognose der richtige Weg.

Zudem wiesen historische Zeitreihenprognosemodelle – zum Beispiel Holt-Winters oder Arima – erhebliche Schwächen auf, wenn die Produktgeschichte zu kurz, zu unbeständig, zu untypisch, zu volumenarm, … war. Die meisten Softwareanbieter reagierten auf diese Probleme mit zwei Ansätzen, die beide auf ihre Weise gleichermaßen dysfunktional sind:

• Human coprocessors: Da das Prognosemodell häufig unsinnige Ergebnisse liefert, werden menschliche Bediener – also Planer – vom System als „coprocessors“ eingesetzt, um Prognosen manuell zu übersteuern, sobald „die Zahlen nicht stimmig erscheinen“. Leider ist diese Aufgabe endlos, da Prognosen kontinuierlich aktualisiert werden müssen, was Planer in einen endlosen Kreislauf manueller Übersteuerungen zwingt. Eine solche Aufgabe führt auch zu unerwünschten Nebeneffekten, indem die Bediener dazu angeregt werden, Prognosen grundsätzlich für falsch zu halten und sie selbst dann zu korrigieren, wenn sie es nicht sind – oft basierend auf reinem Bauchgefühl.
• Model competition: Da jedes Zeitreihenprognosemodell seine eigenen Stärken und Schwächen hat, sollte – so die Überlegung – ein Wettbewerb vieler Prognosemodelle gute Ergebnisse liefern, indem das System in jeder einzelnen Situation das beste Modell auswählt. Leider scheitert dieser Ansatz aus zwei Gründen. Erstens beruhen alle Modelle auf einem Zeitreihen-Rahmenwerk und unterliegen somit denselben Einschränkungen. Zweitens sind alle Modelle „klassisch“ und können nicht die probabilistischen Prognosen liefern, die supply chain benötigt.

Außerdem geht es bei Prognosen nicht nur um die Nachfrage. Auch Durchlaufzeiten sollten prognostiziert werden. Zudem spielt die Struktur der supply chain eine Rolle. Im B2B-Bereich kann ein stetiger Verkaufstrend verbergen, dass alle Bestellungen von demselben Kunden ausgehen. Wenn dieser Kunde verloren geht, werden viele Artikel sofort überbestückt, wenn nicht gar zu Toten Lagerbeständen. Eine richtige prädiktive Optimierung der supply chain muss dieses Risiko berücksichtigen. Die Technologie von Lokad wurde dafür entsprechend entwickelt.

Betrachtet man den spezifischen Aspekt, Prognosen mit Lieferanten zu teilen, so ist – auch wenn eine bessere Koordination zwischen Käufern und Lieferanten immer wünschenswert wäre – festzustellen, dass erfolgreiche prognosegesteuerte Koordinationen zwischen Unternehmen äußerst selten sind. Lieferanten haben ohnehin viele eigene Kunden³. Selbst wenn die von den lokalen Käufern gelieferten Prognosen exakt wären, fehlt dem Lieferanten eine Möglichkeit, all diese unterschiedlichen Prognosen in Einklang zu bringen: Die Summe der Prognosen ist NICHT die Prognose der Summe.

Sicherheitsmodul

Erstaunlicherweise sind bei einigen APS nicht alle Sicherheits-Funktionen standardmäßig im System integriert, sondern werden als separates Modul bereitgestellt. Der Zweck eines Sicherheitsmoduls besteht darin, den Zugriff für bestimmte Benutzer zu unterbinden. Es ermöglicht auch dem Management, Komponentenaktionen abzusichern und Ansichten für wichtige Bereiche des Systems einzuschränken, wie z. B. Unternehmenssteuerungsfaktoren, Artikelpflege, Lieferantenpflege, Bestellungen, Geschäftsabschlüsse und andere Komponenten.

Im Softwarejargon sprechen wir hier von den querliegenden Aspekten der Authentifizierung und Autorisierung.

• Die Authentifizierung stellt sicher, dass die Endbenutzer, die im System agieren, tatsächlich die Person sind, von der das System annimmt, dass sie es sind. Hierbei folgt Lokad dem modernen Ansatz, dass die Authentifizierung wann immer möglich delegiert werden muss. Endbenutzer sollten nicht noch ein weiteres Passwort verwalten müssen. Stattdessen setzt Lokad auf SAML als den de facto Industriestandard, um die Authentifizierung an das föderierte Identitätsmanagement (FIM) zu delegieren.
• Die Autorisierung ermöglicht die detaillierte Steuerung, wer was im System tun darf. Hier verfügt Lokad über ein umfassendes, kanonisches ACL (Access-Control List)-System, das ebenfalls als de facto Praxis moderner Unternehmenssysteme gilt. Darüber hinaus bietet Lokad einige Personalisierungsfunktionen, die das ACL aus Sicht der Benutzererfahrung ergänzen.

Lokad aktiviert standardmäßig alle seine Sicherheitsfunktionen, egal welches Paket ursprünglich an einen unserer Kunden verkauft wurde. Wir sind der Meinung, dass optionale Sicherheit⁴ eine schreckliche Praxis von Softwareanbietern ist. Software abzusichern ist bereits außerordentlich schwierig; eine solche Praxis verschlimmert das Ganze nur.

Um fair zu sein, ist der ACL-Aspekt wahrscheinlich die am wenigsten herausfordernde Sorge im gesamten Bereich der Softwaresicherheit. Eine interessantere Frage ist: Wie viel Sicherheit durch Design liefert die Architektur des Systems? Allerdings geht die Beantwortung dieser Frage über den Rahmen dieses Artikels hinaus.

Export nach Excel

Das Export nach Excel-Modul bietet eine einfache Möglichkeit, Daten für den Einsatz in anderen Systemen oder für Analysen zu transportieren.

Da es relativ unkompliziert ist, Excel-Tabellen zu erstellen⁵, bieten viele Anbieter – einschließlich Lokad – Funktionen in diesem Bereich an. Eine genauere Betrachtung zeigt jedoch, dass die meisten Anbieter nur halbfertige Lösungen liefern. Lassen Sie uns die wesentlichen Punkte guter Export-nach-Excel-Implementierungen betrachten:

• Komplette Historisierung: Das System sollte die Möglichkeit bieten, jede einzelne jemals exportierte Excel-Tabelle nachzuverfolgen und erneut herunterzuladen. Tatsächlich wird es zwangsläufig zu fehlerhaften Zahlen in der Tabellenkalkulation kommen – ein Problem, das auftreten wird (wenn auch nur aufgrund falscher Dateneingaben) –, und das Fehlen einer vollständigen Rückverfolgbarkeit des Codepfads, der letztlich diese Tabelle generiert hat, wird jeglichen Versuch zur Fehlersuche und Behebung des Problems erheblich erschweren, verlangsamen – und manchmal sogar verhindern.
• Ausnutzung der Tabellenkalkulationsfunktionen: Die Praktiker erwarten, in der Lage zu sein, umfangreiche Tabellen mit bis zu 1 Million Zeilen⁶ zu erstellen – was tatsächlich die Grenze von Excel selbst darstellt. Daher sollte das System in der Lage sein, leistungsfähige Tabellen zu generieren, um Praktikern, die einfach in einem vertrauten Werkzeug ihre eigenen Datenanalysen durchführen möchten, nicht im Weg zu stehen. Es versteht sich von selbst, dass auch schnelle Exporte erwartet werden.
• Integrierter Schutz gegen Angriffe auf Tabellenkalkulationen: 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, sie muss ein integraler Bestandteil des Designs sein, quasi von Tag 1 an.
• Programmgesteuerte Konfigurierbarkeit der Exporte: Sich mit zwei Softwareprogrammen – nämlich dem APS und Excel – auseinandersetzen zu müssen, ist für die supply chain Praktiker bereits mühsam genug. Die Situation sollte nicht dadurch verschlimmert werden, dass Tabellen stets eine zusätzliche Nachbearbeitung nach der Extraktion erfordern, um nutzbar zu werden. Daraus folgt, dass alles vor der Extraktion innerhalb des APS erfolgen muss. Folglich benötigt der APS programmatische Fähigkeiten, um die Tabellen vor dem Export ordnungsgemäß vorzubereiten.

Lokad liefert all das, während die meisten unserer Wettbewerber das nicht tun. Der Teufel steckt im Detail.

Fazit

Wir sind überzeugt, dass Lokad eine einfachere Software ist als die meisten APS auf dem Markt. Dennoch ist unsere Fähigkeit, supply chain performance durch prädiktive Technologien zu liefern, größer. Tatsächlich ist der Großteil der APS-Komplexität akzidentell und resultiert aus vor Jahrzehnten getroffenen Softwaredesign-Entscheidungen, die sich mit mittlerweile vergangenen, intern gerichteten Softwareproblemen befassten. Allerdings können die meisten architektonischen Softwareentscheidungen, einmal getroffen, nicht rückgängig gemacht werden.