Von Joannes Vermorel, Juni 2015Der nicht-euklidische Horror taucht aus den Tiefen der IT-Systeme in Unternehmen auf. Betrachtet man den nicht-euklidischen Horror zu lange, kann die zum permanenten Verlust des Verstands führen.Kategorie: Unternehmen
Problem: Über die Jahre hinweg wurden im Unternehmen verschiedenen Systeme eingerichtet. Zurzeit gibt es ein ERP, ein LVS (Lagerverwaltungssystem), ein CRM (für das Kundenbeziehungsmanagement), ein BI-Cube (Business Intelligence) und eine E-Commerce-Plattform, etc. Zwischen der Umsetzung all dieser Systeme wurden auch interne Komponenten zur Ausführung bestimmter Aufgaben entwickelt, da jede App mit allen bereits im Unternehmen integrierten Apps kommunizieren muss. Jede Abteilung ist involviert, doch die Lieferkette, die zwischen dem Vertrieb, dem Einkauf, der Finanzabteilung und der Produktion sitzt, ist am meisten davon betroffen. Änderungen geschehen nur im schleppenden Tempo und praktisch alle Projekte im Bereich Lieferkette halten ihre Deadlines nicht ein. Außerdem versteht keiner mehr so recht, was im Unternehmenssystem passiert.
Einzelberichte: Die tatsächliche Bewegung von einem Lagerhaus in ein anderes in der Nähe könnte innerhalb von zwei Wochen erfolgen. Doch, was die Software betrifft, nimmt die eigentliche IT-Migration zur Integration des neuen Lagers über 6 Monate in Anspruch.
Kontext: Vor langer Zeit hatte jede Abteilung im Unternehmen ihre eigene Software-Lösung. Die Integration war nicht weit verbreitet und so entschloss man sich, ein ERP-System einzuführen, das „über alle regieren sollte“. Das ERP-System wurde umgesetzt, doch es konnte nicht mit den raschen Veränderungen der Software-Industrie mithalten. Was die Lieferkette betrifft, wurde zur höheren Zuverlässigkeit ein LVS (Lagerverwaltungssystem) eingerichtet, was auch ziemlich gut funktioniert hat. Andere Abteilungen nahmen ähnliche Schritte vor und richteten spezifische Apps für ihre Tätigkeitsfelder ein, die besser als das ursprüngliche ERP funktionierten. Doch der Handel ändert sich rascher denn je, und so erfordern heute intelligente Abläufe im Bereich Lieferkette einen umfangreichen Austausch zwischen all diesen unterschiedlichen Apps.
Vermutete Lösung: Jedes Mal, wenn sich eine neue Herausforderung ergibt, werden IT-Systeme geringfügig angepasst, um die erwarteten Ergebnisse zu erhalten. Für die Lieferkette wurde somit eine ad-hoc Integration im CRM erstellt, um Inputs vom Vertrieb zu sammeln, sowie eine weitere ad-hoc Integration zum BI-Cube, da dies die einzige Möglichkeit bot, Zahlen im Einklang mit denen der Finanzabteilung zu erhalten. Logistikdienste und Lieferanten haben auch einige eigene Integrationen benötigt. Folglich hat das Lieferkettenteam gelernt, dass Änderungen im IT-Bereich bei wachsender Größe mit höherer Wahrscheinlichkeit das Budget überschreiten und die Deadlines nicht einhalten. Daher werden kleinere zunehmende Veränderungen zurzeit bevorzugt statt umfangreicheren Entwicklungen eingesetzt.
Resultierender Kontext: Verglichen mit den Schnittstellen der verschiedenen IT-Systeme innerhalb eines Unternehmens, sieht der U-Bahnplan Tokios Kinderleicht aus. Hier bestehen Hunderte subtiler Abhängigkeiten zwischen all den Systemen des Unternehmens. Somit ist der Gesamtüberblick der IT bestenfalls unscharf. Für die Lieferkette bedeutet dies ständige Schwierigkeiten beim Zugriff auf relevante Daten wie neue Produkte, Aktionen, Bestellungen, die „fast durchgeführt “ sind, Historie der Bestandshöhen und Fehlbestände, usw. Jede kleine Überarbeitung der Operationen der Lieferkette, bei der ein Vorgang durch zusätzliche Information verbessert werden soll, scheint sich ewig in die Länge zu ziehen. Die Dateneingabe ist nicht konsistent, die Systeme schlagen immer wieder fehl, Ausnahmen müssen überall manuell angepasst werden.
Anziehungskräfte: Das Unternehmen hat auf die harte Tour gelernt, umso größer das IT-Projekt, desto wahrscheinlicher scheitert es. Daher richten sich nach und nach alle Lösungen auf kleinere und spezifischere Projekte mit einer einfacheren Umsetzung, bei denen das Budget und die Zeitpläne eingehalten werden. Und gerade durch solche geringfügigen Projekte ¬konnte das Unternehmen bald Erfolge erzielen, wobei diese positiven Ergebnisse auf kleinere Budgets zurückzuführen sind.
Warum dies zum Scheitern verurteilt ist: Jede zunehmende Veränderung erhöht die Kosten und die Komplexität aller künftiger Änderungen. Da aber das Unternehmen so kleine und zunehmende Änderungen wie möglich favorisiert, wird der „Gesamtüberblick“ ständig vernachlässigt. Dies ist in gewisser Hinsicht ein Fall der „Tragödie des Allgemeinguts“, wo individuelle Interessen (der getrennten Abteilungen im Unternehmen) nicht mit den gemeinsamen Interessen des Unternehmens als Ganzes im Einklang stehen. Das Problem verstärkt sich zusätzlich, weil die negativen Auswirkungen gewöhnlich erst lange nach den Veränderungen beobachtet werden. Obwohl jede Änderung rentabel scheint, häufen sich im Unternehmen immer mehr „technische Schulden“ an, die kurzfristige Gewinne zu langfristigen Verlusten machen.
Positive Muster zur Aufmerksamkeit auf das Problem: Grundsätzlich ist die Umsetzung von zunehmenden Änderungen ein vernünftiger Ansatz. Doch jede Veränderung sollte so umgesetzt werden, dass die folgenden Veränderungen günstiger oder einfacher werden – zwei Eigenschaften, die in der Praxis korrelieren. Dies bedeutet, dass jedes Projekt die
Steuer für das Allgemeingut entrichten muss, bei der nicht nur die Hauptziele des Projekts erfüllt werden, sondern auch zweitrangige Ziele, die darin bestehen, den Weg für künftige Veränderungen zu bereiten.
Beispiel: Contoso ist der bundesweite Führer eines bestimmten B2C-Segments im Bereich E-Commere Deutschlands. Das Unternehmen nahm seine Tätigkeit Anfang der 2000er auf und entwickelte zu dieser Zeit ein maßgeschneidertes Front-End, also die „App “, über die Kunden online kaufen können. In den ersten Jahren wurden alle Bedürfnisse im Bereich IT über ein unendlich wachsendes Front-End gelöst. Doch die Verwaltung von Lieferanten und Bestellung war einfach zu viel für diese maßgeschneiderte App. So entschloss sich Contoso, in ein ERP der Mittelklasse zu investieren und alle Backoffice-Prozesse, sowie die aufkommenden Aufgaben der Lieferkette darauf laufen zu lassen. Eine Zeit lang wurden Bestandshöhen sowohl im Fron-End, als auch im ERP verwaltet. Doch weil dieser Vorgang als chaotisch erkannt wurde, beschloss Contoso erfolgreich, das Front-End von seinen übergreifenden Zuständigkeiten zu befreien.
Das ERP hat seine Funktion anfänglich erfüllt. Doch bei wachsender Größe des Unternehmens und trotz der Bemühungen des technischen Teams, das für die Entwicklung des ERPs zuständig war, konnte das ERP nicht mit allen Anforderungen des Unternehmens mithalten. Die Berichterstellung reichte nicht aus, weshalb das Finanzteam beschloss, sein eigenes BI-Portal (Business Intelligence) einzurichten. Ähnlich dazu führten die meisten anderen Abteilungen eigene Apps ein. Für die Lieferkette wurde eine Reihe EDI-Integrationen eingeführt, um ihre Bestellungen an ihre Lieferanten zu schicken. Doch alles in das ERP zu leiten wurde immer frustrierender, da das ERP einfach nicht all die Nuancen der Lieferkettenoperationen Contosos erfassen konnte.
Da Contoso zum führenden Unternehmen Deutschlands geworden war, hatte es nun Zugang auf eine ganze Auswahl an Beschaffungsoptionen. Die lokalen deutschen Vertreiber, die anfänglich eine bedeutende Rolle im Erfolg Contosos gespielt hatten, wurden nach und nach ziemlich teuer, in Anbetracht dessen, dass Contosos Konkurrenten die Preise senkten. Die Tage, an denen Kunden bereit waren, für den Online-Kauf „extra“ zu zahlen, waren längst vorbei. Folglich musste Contoso nach und nach alternative Beschaffungsoptionen in Ihren Workflow einbauen und dabei oft die Dienste von Lieferanten aus entfernteren Orten, oder sogar aus Übersee in Anspruch nehmen. Nachdem einige Monate lang erfolglos versucht wurde, die Multi-Sourcing Logik im ERP umzusetzen, beschloss das Lieferkettenteam, dass es an der Zeit war, ihr eigenes vom ERP getrenntes System einzuführen. Das Lieferkettenteam entschloss sich für eine erweitere Beschaffungs-App, doch das Setup dauerte länger als erwartet. Dies lag nicht an der neuen Lösung, sondern an der Integration im ERP, die zu unvorhersehbaren Schwierigkeiten führte. So entdeckte das Lieferkettenteam drei Monate nach Einführung der neuen Lösung, dass die auf der Kundenseite angezeigten Versandverzögerungen nicht vom ERP verwaltet wurden, sondern noch vom Front-End. Daher flossen diese „angezeigten Versandverzögerungen“ vom Front-End zum ERP, doch die umgekehrte Verbindung war nicht eingerichtet worden. So hatte die Eingabe der überprüften Versandverzögerungen in das ERP, die dynamisch auf Grundlage des gewählten Lieferanten aktualisiert wurden, keinen Einfluss auf die angezeigten Zahlen auf der Webseite. Das ERP hatte bereits ein ziemlich komplexes Setup erreicht und da Contosos IT-Team mit dem Front-End, das ja intern entwickelt wurde, vertrauter war, beschlossen das Lieferketten- und das IT-Team gemeinsam, die überprüften Versandverzögerungen direkt in das Front-End einzuspeisen.
Dieser Ansatz erwies sich als etwas chaotisch. Obwohl die Umsetzung der Beschaffungs-App innerhalb von drei Monaten vorgesehen war, erfolgte der „Livegang&dquo; erst neun Monate später. Doch die Investition hat sich gelohnt, da durch das Multi Sourcing der durchschnittliche Kaufpreis um etwa 15% gesenkt werden konnte, was dem Unternehmen einen deutlichen Aufschwung verschaffte.
Spulen wir schnell zum heutigen Tage vor. Contosos Einkaufsteam, eine Abteilung, die jetzt von der Lieferkette getrennt ist, hat günstige, jedoch komplexe, Verträge mit seinen größten Lieferanten ausgehandelt. So können die Lieferanten beträchtliche Summen am Ende eines Quartals erstatten, wenn bestimmte Vorgaben erreicht werden. Diese setzen sich gewöhnlich als Kombination von Absatzvolumen in Euro und der Menge der eingekauften Einheiten zusammen. Vor 12 Monaten hat das Lieferkettenteam ein Projekt ins Leben gerufen, um solche Verträge bei der Wahl des günstigsten Lieferanten für jede Bestellung, zu berücksichtigen. Doch das Projekt liegt größtenteils auf Eis. Die Vertragsbedingungen der Lieferanten befinden sich im System des Einkaufs. Die finanziellen Angaben lassen sich nur an den BI Systemen ablesen, während weitere Informationen der Lieferanten weiterhin im Front-End vorliegen. Bisher wurde auch kein internes Upgrade vorgenommen, um diese verschiedenen Elemente zu vereinen. Eigentlich sind die nötigen Änderungen ziemlich klein, doch wie es scheint, wäre jedes der Systeme im Unternehmen involviert. Die Arbeitsmoral ist nicht besonders hoch und die Mitarbeiter konzentrieren sich hauptsächlich auf ihre nächsten Aufträge, da keine positiven Ergebnisse in Sicht sind.
