Der Nicht-euklidische Horror (Supply Chain Antipattern)

Der nicht-euklidische Horror ist aus den Tiefen der IT-Systeme des Unternehmens aufgetaucht. Zu langes Starren auf den nicht-euklidischen Horror kann zu einem dauerhaften Verlust des Verstandes führen.

Kategorie: Organisation

Problem: Im Laufe der Jahre hat das Unternehmen viele unterschiedliche Systeme etabliert. Heute gibt es ein ERP, ein WMS (Warehouse Management System), ein CRM (Customer Relationship Management), einen BI Cube (Business Intelligence), eine E-Commerce-Plattform usw. Zwischen der Einführung all dieser Systeme wurden auch interne Komponenten entwickelt, um spezialisiertere Aufgaben zu erfüllen. Die Komplexität der IT-Landschaft hat im Laufe der Jahre stark zugenommen, da jede zusätzliche App mit jeder anderen, bereits implementierten App kommunizieren muss. Jede Abteilung ist betroffen, aber supply chain, die zwischen Vertrieb, Einkauf, Finanzen und Produktion liegt, ist am stärksten betroffen. Veränderungen erfolgen schleppend, und fast alle supply chain Initiativen verfehlen ihre Deadlines. Niemand versteht mehr, was in den Unternehmenssystemen vor sich geht.

Anekdotische Evidenz: Der physische Umzug von einem Lager zu einem in der Nähe gelegenen Lager hätte in zwei Wochen erfolgen können. Was die Software betrifft, wird die tatsächliche IT-Migration, die zur Integration des neuen Lagers notwendig ist, jedoch mehr als 6 Monate in Anspruch nehmen.

Kontext: Vor langer Zeit startete jede Unternehmensabteilung mit einer eigenen Softwarelösung. Die Integration war mangelhaft, und schließlich wurde beschlossen, ein ERP-System einzuführen, um „alle zu beherrschen“. Das ERP-System wurde implementiert, konnte jedoch mit dem rasanten Wandel in der Softwarebranche nicht Schritt halten. Was die supply chain betrifft, wurde ein WMS (Warehouse Management System) eingerichtet, um die Produktivität und Zuverlässigkeit zu verbessern; und dies funktionierte relativ gut. Andere Abteilungen folgten einem ähnlichen Ansatz, indem sie eigene, bereichsspezifische Apps einführten, die besser passten als das ursprüngliche ERP. Die Geschäftswelt verändert sich jedoch schneller denn je, und heutzutage beinhalten intelligentere supply chain operations eine Vielzahl von Interaktionen zwischen all diesen verschiedenen Apps.

Angebliche Lösung: Jedes Mal, wenn sich eine neue Herausforderung abzeichnet, werden die IT-Systeme minimal angepasst, um die erwarteten Ergebnisse zu liefern. Für supply chain Zwecke wurde eine Ad-hoc-Integration mit dem CRM eingerichtet, um Inputs vom Vertriebsteam zu sammeln, und eine weitere Ad-hoc-Integration mit dem BI Cube wurde implementiert, da dies der einzige Weg ist, um Kennzahlen zu erhalten, die mit denen der Finanzabteilung übereinstimmen. Logistikdienstleister und Lieferanten benötigten einige eigene Integrationen. Infolgedessen hat das supply chain Team gelernt, dass je größer die IT-Änderung ist, desto wahrscheinlicher es ist, dass die Initiative das Budget sprengt und die Deadlines verfehlt. Daher werden nun enge, inkrementelle Änderungen stark gegenüber substantiellen Weiterentwicklungen bevorzugt.

Resultierender Kontext: Der U-Bahn-Plan von Tokio wirkt einfach, verglichen mit der Darstellung der verschiedenen IT-Interaktionen im Unternehmen. Es gibt Hunderte von subtilen Abhängigkeiten zwischen all den Systemen im Unternehmen. Das Gesamtbild der IT-Landschaft ist bestenfalls sehr unscharf. Für die supply chain besteht ein ständiger Kampf, Zugang zu allen relevanten Informationen zu erhalten, wie neue Produkte, Aktionen, Bestellungen, die „fast“ abgeschlossen sind, die Historie von Lagerbeständen und Fehlbeständen, usw. Jede kleine Überarbeitung der supply chain Abläufe, bei der ein Prozess durch die Nutzung eines zusätzlichen Informationsstücks verbessert werden soll, zieht sich endlos hin. Dateneingaben sind inkonsistent, Systeme fallen ständig aus und es gibt Ausnahmen, die manuell verwaltet werden müssen.

Verführerische Kräfte: Das Unternehmen hat auf die harte Tour gelernt, dass je größer die IT-Initiative ist, desto wahrscheinlicher sie scheitert. Daher haben sich alle Praktiken allmählich in Richtung kleinerer und fokussierterer Initiativen entwickelt, die leichter auszurollen sind, während Budget und Zeitpläne unter Kontrolle bleiben. Das Unternehmen konnte frühzeitig Erfolge erzielen – genau durch solche kleinschrittigen Initiativen, bei denen positive Ergebnisse mit minimalen Budgets erreicht wurden.

Warum dies zum Scheitern führt: Jede inkrementelle Änderung erhöht die Kosten und die Komplexität aller weiteren Änderungen. Da die Unternehmenspraktiken Änderungen bevorzugen, die so klein und inkrementell wie möglich sind, mangelt es ständig am Blick für das „große Ganze“. In gewisser Weise handelt es sich hierbei um ein Beispiel für die „Tragödie der Allmende“, bei der die individuellen Interessen (die einzelnen Abteilungen des Unternehmens) nicht mit den gemeinsamen Interessen des Unternehmens als Ganzes übereinstimmen. Das Problem wird zusätzlich verschärft, da die negativen Effekte typischerweise erst lange nach der Änderung sichtbar werden. Während jede einzelne Änderung profitabel erscheint, häuft das Unternehmen weiterhin „technische Schulden“ an, wodurch kurzfristige Gewinne mit der Zeit in Verluste umgewandelt werden.

Positive Muster zur Bewältigung des Problems: Grundsätzlich ist die Umsetzung inkrementeller Änderungen ein vernünftiger Ansatz. Jede Änderung sollte jedoch so durchgeführt werden, dass jede nachfolgende Änderung billiger oder einfacher wird – die beiden Eigenschaften sind in der Praxis stark miteinander verknüpft. Das impliziert, dass jede Initiative den Preis der Allmende zahlen muss, wobei nicht nur das primäre Ziel der Initiative erreicht, sondern auch das sekundäre Ziel verfolgt wird, die nachfolgenden Änderungen zu erleichtern.

Beispiel: Contoso ist ein nationaler E-Commerce-Führer in Deutschland in einem speziellen B2C-Segment. Das Unternehmen startete Anfang der 2000er Jahre und entwickelte damals ein maßgeschneidertes Frontend – die App, die es den Menschen ermöglicht, online zu kaufen. In den frühen Jahren des Unternehmens wurden nahezu alle IT-Bedürfnisse über das kontinuierlich wachsende Frontend gelöst. Die Verwaltung von Lieferanten und Bestellungen war für diese maßgeschneiderte App jedoch einfach zu umfangreich. Folglich entschied sich Contoso, in ein Mid-Market-ERP zu investieren und alle Back-Office-Prozesse auf dieses ERP-System auszulagern, einschließlich des Großteils der entstehenden supply chain Praktiken. Eine Zeit lang wurden die Lagerbestände sowohl im Frontend als auch im ERP verwaltet, aber da dies chaotisch wurde, gelang es Contoso letztlich, das Frontend erfolgreich von seinen übergreifenden Verantwortlichkeiten zu entlasten.

Anfänglich erfüllte das ERP seine Funktion, doch als das Unternehmen weiter wuchs – und trotz der besten Bemühungen des technischen Teams, das für die ERP-Entwicklung verantwortlich war – konnte das ERP nicht alle Anforderungen des Geschäfts abdecken. Das Reporting war unzureichend, und die Finanzabteilung beschloss, ein eigenes BI (Business Intelligence) Portal einzurichten, während die meisten anderen Abteilungen ähnliche eigene Apps einführten. Die supply chain startete eine Reihe von EDI-Integrationen, um ihre Bestellungen an die Lieferanten zu übermitteln, doch die Einbindung aller Daten in das ERP wurde zunehmend frustrierend, da das ERP nicht in der Lage war, alle Feinheiten der supply chain Abläufe von Contoso abzubilden.

Da Contoso zu einem nationalen Marktführer geworden ist, hatte es nun Zugang zu einer breiten Palette von Beschaffungsoptionen. Die lokalen deutschen Distributoren, die ursprünglich eine Schlüsselrolle beim frühen Erfolg von Contoso gespielt hatten, erwiesen sich nun als zunehmend teuer, da Contosos Wettbewerber die Preise senkten. Die Zeiten, in denen Kunden bereit waren, „extra“ für Online-Einkäufe zu zahlen, waren längst vorbei. Infolgedessen musste Contoso schrittweise alternative Beschaffungsoptionen in den Workflow integrieren, typischerweise unter Zuhilfenahme weiter entfernter, manchmal sogar ausländischer Lieferanten. Nach einigen Monaten des erfolglosen Versuchs, die Multi-Sourcing-Logik in das ERP zu zwängen, entschied das supply chain Team, dass es an der Zeit sei, ein eigenes System einzurichten, das vom ERP getrennt ist. Das supply chain Team entschied sich für eine fortschrittliche Sourcing-App, aber die Einrichtung dauerte viel länger als erwartet. Die neue Lösung war nicht fehlerhaft – es war die Integration mit dem ERP, die zu einer Reihe unerwarteter Schwierigkeiten führte. So stellten die supply chain Teams beispielsweise drei Monate nach dem Start der neuen Lösung fest, dass die auf der Kundenwebsite angezeigten Versandverzögerungen nicht vom ERP, sondern weiterhin vom Frontend verwaltet wurden. Folglich hatte das Einspeisen überarbeiteter Versandverzögerungen – dynamisch aktualisiert basierend auf dem ausgewählten Lieferanten – in das ERP keinerlei Einfluss auf die auf der Website angezeigten Kennzahlen.

Der Ansatz erwies sich als etwas unübersichtlich, und obwohl ursprünglich geplant war, die Sourcing-App innerhalb von 3 Monaten einzuführen, dauerte es ganze 9 Monate, bis sie „live“ ging. Dennoch lohnte sich die Investition, da das Multi-Sourcing zu einer Senkung der durchschnittlichen Einkaufspreise um 15% führte, was einen erheblichen Schub für das Geschäft darstellte.

Springen wir in die Gegenwart. Contosos Einkaufsteam, das nun von der supply chain-Abteilung getrennt ist, hat vorteilhafte, wenn auch leider komplexe Vereinbarungen mit seinen größten Lieferanten ausgehandelt. So könnte der Lieferant beispielsweise am Ende jedes Quartals erhebliche Geldbeträge zurückerstatten, sofern bestimmte Quoten erfüllt werden – typischerweise in Form einer Kombination aus Verkaufsvolumen in Euro und abgenommenen Stückzahlen. Vor 12 Monaten startete das supply chain Team eine Initiative, um solche Vereinbarungen bei der Auswahl des profitabelsten Lieferanten für jede Bestellung zu berücksichtigen. Allerdings ist die Initiative weitgehend ins Stocken geraten. Die vertraglichen Bedingungen des Lieferanten befinden sich im Einkaufssystem, die finanziellen Elemente sind nur in den BI-Systemen zu finden, während einige andere lieferantenbezogene Informationen im Frontend verbleiben, und es wurde nie ein internes Upgrade abgeschlossen, um die einzelnen Puzzleteile zusammenzufügen. Der tatsächlich nötige Änderungsaufwand ist gering, doch scheint es, als wären alle Systeme im Unternehmen involviert. Die Moral ist niedrig, und die Mitarbeiter konzentrieren sich zunehmend auf ihre nächste Aufgabe, da kein positives Ergebnis in Sicht ist.