Der nicht-euklidische Horror (Supply Chain Antipattern)

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

Kategorie: Organisation

Problem: Im Laufe der Jahre hat das Unternehmen viele verschiedene Systeme eingerichtet. Sie haben jetzt ein ERP, ein WMS (Warehouse-Management-System), ein CRM (Customer-Relationship-Management), einen BI Cube (Business Intelligence), eine E-Commerce-Plattform usw. Zwischen der Implementierung all dieser Systeme wurden auch Inhouse-Komponenten entwickelt, um spezialisiertere Aufgaben zu erledigen. Die Komplexität der IT-Landschaft hat im Laufe der Jahre stark zugenommen, da jede zusätzliche App mit jeder bereits vom Unternehmen implementierten App kommunizieren muss. Jede Abteilung ist betroffen, aber die Supply Chain, die zwischen Vertrieb, Einkauf, Finanzen und Produktion sitzt, ist am stärksten betroffen. Änderungen sind träge, und fast alle Supply Chain-Initiativen scheitern daran, ihre Fristen einzuhalten. Niemand versteht wirklich, was in den Unternehmenssystemen vor sich geht.

Anekdotische Beweise: Der physische Umzug von einem Lager zu einem nahegelegenen Lager könnte in zwei Wochen erledigt werden. Was die Software betrifft, wird die tatsächliche IT-Migration, die für die Integration des neuen Lagers erforderlich ist, jedoch mehr als 6 Monate dauern.

Kontext: Vor langer Zeit hatte jede Unternehmensabteilung mit ihrer eigenen Softwarelösung begonnen. Die Integration war schlecht, und schließlich wurde beschlossen, ein ERP-System einzurichten, um “alle zu regieren”. Das ERP-System wurde implementiert, konnte jedoch mit dem raschen Tempo des Wandels in der Softwarebranche nicht Schritt halten. Was die Supply Chain betraf, wurde ein WMS (Warehouse-Management-System) eingerichtet, um die Produktivität und Zuverlässigkeit zu verbessern, und dies funktionierte relativ gut. Andere Abteilungen machten ähnliche Schritte, indem sie ihre eigenen domänenspezifischen Apps einrichteten, die besser geeignet waren als das ursprüngliche ERP. Das Geschäft ändert sich jedoch schneller als je zuvor, und heute erfordert eine intelligentere Supply Chain-Operation eine Vielzahl von Interaktionen zwischen all diesen verschiedenen Apps.

Vorgeschlagene Lösung: Jedes Mal, wenn eine neue Herausforderung entsteht, werden die IT-Systeme auf minimaler Ebene angepasst, um die erwarteten Ergebnisse zu liefern. Für die Supply Chain wurde eine ad-hoc Integration mit dem CRM eingerichtet, um Eingaben vom Vertrieb zu sammeln, und eine weitere ad-hoc Integration wurde mit dem BI Cube eingerichtet, weil dies der einzige Weg ist, um Zahlen zu haben, die mit denen der Finanzabteilung übereinstimmen. Logistikdienstleister und Lieferanten haben auch einige Integrationen benötigt. Als Ergebnis hat das Supply Chain-Team gelernt, dass je größer die IT-Änderung ist, desto wahrscheinlicher ist es, dass die Initiative das Budget überschreitet und die Fristen nicht einhält. Daher werden schmale inkrementelle Änderungen jetzt gegenüber wesentlichen Entwicklungen stark bevorzugt.

Ergebnisierender Kontext: Die U-Bahn-Karte von Tokio wirkt im Vergleich zur Darstellung der verschiedenen IT-Interaktionen im Unternehmen einfach. Es gibt Hunderte von subtilen Abhängigkeiten zwischen allen Systemen im Unternehmen. Das Gesamtbild der IT-Landschaft ist bestenfalls sehr unscharf. Für die Supply Chain besteht ein ständiger Kampf darin, Zugang zu allen relevanten Informationen wie neuen Produkten, Promotions, “fast” abgeschlossenen Bestellungen, dem Verlauf der Lagerbestände und Lagerausfällen usw. zu erhalten. Jede kleine Überarbeitung der Supply-Chain-Operationen, bei der ein Prozess durch Nutzung einer zusätzlichen Information verbessert werden soll, scheint sich endlos hinzuziehen. Die Dateninputs sind inkonsistent, Systeme fallen immer wieder aus und es gibt Ausnahmen, die überall manuell verwaltet werden müssen.

Verführungskräfte: Das Unternehmen hat auf die harte Tour gelernt, dass je größer die IT-Initiative ist, desto wahrscheinlicher ist es, dass die Initiative scheitert. Daher haben sich alle Praktiken allmählich zu kleineren und fokussierteren Initiativen entwickelt, die einfacher umzusetzen sind und das Budget und die Zeitpläne unter Kontrolle halten. Das Unternehmen konnte durch solche kleinskaligen Initiativen frühzeitig Erfolge erzielen, wobei positive Ergebnisse mit geringen Budgets erzielt 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, besteht eine ständige mangelnde Sorge um das “große Ganze”. In gewisser Weise handelt es sich hierbei um einen Fall des “Tragödie der Allmende”, bei dem die individuellen Interessen (die separaten Abteilungen des Unternehmens) nicht mit den gemeinsamen Interessen des Unternehmens als Ganzes übereinstimmen. Das Problem wird dadurch verschärft, dass die negativen Auswirkungen typischerweise erst lange Zeit nach der Änderung sichtbar werden. Während jede Änderung zunächst profitabel zu sein scheint, häuft das Unternehmen “technische Schulden” an und verwandelt kurzfristige Gewinne im Laufe der Zeit in Verluste.

Positive Muster zur Lösung des Problems: Grundsätzlich ist die Umsetzung inkrementeller Änderungen ein vernünftiger Ansatz. Jede Änderung sollte jedoch so ausgeführt werden, dass jede nachfolgende Änderung billiger oder einfacher wird; die beiden Eigenschaften sind in der Praxis stark miteinander korreliert. Dies bedeutet, dass jede Initiative die “Steuer der Allmende” zahlen muss, bei der nicht nur das Hauptziel der Initiative erfüllt werden muss, sondern auch das sekundäre Ziel, das darin besteht, die Dinge für die kommenden Änderungen zu erleichtern.

Beispiel: Contoso ist ein nationaler E-Commerce-Marktführer in Deutschland in einem bestimmten B2C-Segment. Das Unternehmen begann in den frühen 2000er Jahren mit dem Betrieb und entwickelte damals eine maßgeschneiderte Front-End-Lösung; das Front-End ist die “App”, mit der Menschen online einkaufen können. In den ersten Jahren des Unternehmens wurden nahezu alle IT-Anforderungen über ein ständig wachsendes Front-End gelöst. Die Verwaltung von Lieferanten und Bestellungen war jedoch für diese maßgeschneiderte App einfach zu viel. Daher beschloss Contoso, in ein ERP-System für den mittleren Markt zu investieren und alle Back-Office-Prozesse in dieses ERP-System auszulagern, einschließlich des Großteils der aufkommenden Supply-Chain-Praktiken. Eine Zeit lang wurden die Lagerbestände sowohl im Front-End als auch im ERP verwaltet, aber da sich dies als chaotisch erwies, gelang es Contoso letztendlich erfolgreich, das Front-End von seinen übergeordneten Verantwortlichkeiten zu befreien.

Das ERP erfüllte zunächst seine Funktion, aber da das Unternehmen weiter wuchs und trotz der besten Bemühungen des technischen Teams, das für die ERP-Entwicklung zuständig war, konnte das ERP nicht allen Anforderungen des Unternehmens gerecht werden. Die Berichterstattung war unzureichend, und die Finanzabteilung beschloss, ihr eigenes BI (Business Intelligence) Portal einzurichten, während die meisten anderen Abteilungen ähnliche Apps einführten. Die Supply Chain startete eine Reihe von EDI-Integrationen, um ihre Bestellungen an ihre Lieferanten zu senden, aber die Einbindung aller Informationen in das ERP wurde zunehmend frustrierend, da das ERP einfach nicht alle Feinheiten der Supply-Chain-Operationen von Contoso erfassen konnte.

Da Contoso zu einem nationalen Marktführer herangewachsen war, hatte es nun Zugang zu einer Vielzahl von Beschaffungsoptionen. Die lokalen deutschen Distributoren, die anfangs eine wichtige Rolle im frühen Erfolg von Contoso spielten, erwiesen sich nun als zunehmend teuer, da die Konkurrenten von Contoso die Preise drückten. Die Zeiten, in denen Kunden bereit waren, “extra” für Online-Einkäufe zu zahlen, waren längst vorbei. Als Folge davon musste Contoso allmählich alternative Beschaffungsoptionen in ihren Workflow integrieren, indem sie in der Regel die Dienste von entfernteren, manchmal überseeischen Lieferanten nutzten. Nach einigen Monaten erfolgloser Bemühungen, die Multi-Sourcing-Logik in ihr ERP zu quetschen, beschloss das Supply-Chain-Team, dass es an der Zeit war, ein eigenes System einzurichten, das vom ERP getrennt ist. Das Supply-Chain-Team entschied sich für eine fortschrittliche Beschaffungs-App, aber die Einrichtung dauerte viel länger als erwartet. Die neue Lösung war nicht das Problem, sondern die Integration mit dem ERP führte zu einer Reihe unerwarteter Schwierigkeiten. Zum Beispiel erkannte das Supply-Chain-Team drei Monate nach dem Start der neuen Lösung, dass die auf der Kundenseite angezeigten Versandverzögerungen nicht vom ERP, sondern immer noch vom Front-End verwaltet wurden. Daher flossen diese “angezeigten Versandverzögerungen” vom Front-End zum ERP, aber es wurde nichts unternommen, um dies umgekehrt zu unterstützen. Als Folge hatte das Einspeisen überarbeiteter Versandverzögerungen - dynamisch aktualisiert basierend auf dem ausgewählten Lieferanten für das Produkt - keine Auswirkungen auf die auf der Website angezeigten Zahlen. Das ERP hatte sich bereits zu einer ziemlich komplexen Einrichtung entwickelt, und da sich das IT-Team von Contoso mit dem Front-End, das intern entwickelt worden war, viel wohler fühlte, beschlossen das Supply-Chain- und das IT-Team gemeinsam, dass die Beschaffungslösung die überarbeiteten Versandverzögerungen direkt in das Front-End einspeisen würde.

Der Ansatz erwies sich als etwas chaotisch, und obwohl geplant war, die Beschaffungs-App innerhalb von 3 Monaten einzusetzen, dauerte es ganze 9 Monate, bis sie “live” ging. Dennoch war es die Investition wert, da das Multi-Sourcing zu einer Senkung der durchschnittlichen Einkaufspreise um 15% führte, was für das Unternehmen ein erheblicher Schub war.

Wir springen in die Gegenwart. Das Einkaufsteam von Contoso, das nun von der Supply-Chain-Abteilung getrennt ist, hat günstige, aber leider komplexe Vereinbarungen mit seinen größten Lieferanten ausgehandelt. Zum Beispiel könnte der Lieferant am Ende jedes Quartals erhebliche Geldbeträge zurückgeben, wenn bestimmte Quoten erfüllt werden, die in der Regel eine Kombination aus Verkaufsvolumen in Euro und gekauften Mengen sind. Vor 12 Monaten hat das Supply-Chain-Team eine Initiative gestartet, um solche Vereinbarungen bei der Auswahl des profitabelsten Lieferanten für jede Bestellung zu berücksichtigen. Die Initiative ist jedoch weitgehend ins Stocken geraten. Die vertraglichen Bedingungen des Lieferanten befinden sich im Beschaffungssystem, die Finanzelemente sind nur in den BI-Systemen zu finden, während einige andere lieferantenbezogene Informationen im Front-End verbleiben und kein interner Upgrade durchgeführt wurde, um die verschiedenen Teile dieses Puzzles zusammenzufügen. Der tatsächlich erforderliche Änderungsaufwand ist gering, aber es scheint, dass jedes einzelne System im Unternehmen involviert ist. Die Stimmung ist niedrig und die Leute konzentrieren sich zunehmend auf ihre nächste Aufgabe, da kein positives Ergebnis in Sicht ist.