In vielen, wahrscheinlich den meisten großen Unternehmen, die eine Supply Chain betreiben, hat die IT-Abteilung jahrelangen Rückstand. Der Rückstand besteht aus einer Vielzahl von Fehlern, Inkonsistenzen oder Fragilitäten, die behoben werden könnten, aber nicht behoben werden. Neben der Schaffung umfangreicher bürokratischer Überlastungen demotiviert diese endlose Serie sinnloser Ärgernisse alle. Die Supply Chain, die sich direkt in der Mitte der Anwendungsumgebung befindet, ist besonders betroffen. Anekdotisch gesehen repräsentiert der Supply Chain-Bereich1 häufig die Hälfte des gesamten IT-Rückstands des Unternehmens.

Die Rolle der IT in Ihrer Supply Chain

Schlimmer noch, der Rückstand wird häufig durch einen Großen Übergang verdeckt, typischerweise ein ERP Upgrade. Dies ist die direkte Folge davon, dass erwartet wird, dass der Große Übergang alle Probleme löst, die in den letzten zehn Jahren nicht angegangen wurden. Diese Erwartung ist jedoch fehl am Platz. Tatsächlich wird der Große Übergang, selbst wenn er erfolgreich abgeschlossen wird2, auch nach einem halben Jahrzehnt viele neue Probleme eingeführt haben, selbst wenn er einige der alten Probleme beseitigen kann.

Der Große Übergang hat zwei Nebenwirkungen: Erstens bringt er alle Abteilungen - außer der IT - zum Schweigen, wenn es um Softwareangelegenheiten geht; zweitens wirkt er wie ein schwarzes Loch, das alle Budgets und Energien absorbiert. Das zweite ist eine Folge des ersten.

Aufgrund seiner Natur ist der Große Übergang sehr technisch. Niemand - außer IT-Spezialisten - versteht wirklich die Feinheiten der Migration von einem Datenbanksystem zu einem anderen und die subtilen Inkompatibilitäten, die zwischen den beiden bestehen. Sobald die anderen Abteilungen zum Schweigen gebracht sind, gibt es keinen Widerstand mehr gegen die Kanalisierung alles in Richtung des Großen Übergangs. Andere Abteilungen spielen normalerweise mit, in der irrtümlichen Hoffnung, dass dies den Großen Übergang beschleunigen wird. Das wird es nicht. Das Gegenteil passiert: Je größer das Budget, desto langsamer die Initiative.

Bei großen Unternehmen ist dieser Ansatz in den letzten zwei Jahrzehnten vorherrschend gewesen. Die Ergebnisse sind ernüchternd. Unternehmen zahlen immer noch übertriebene Gebühren für CRUD-Apps3, die vor mehr als einem Jahrzehnt über Open Source zu Commodities hätten werden sollen. Die Implementierungsverzögerungen waren noch nie so lang. Das Tüpfelchen auf dem i: Die Leistung und Reaktionsfähigkeit von Unternehmenssoftware ist immer noch so schlecht wie eh und je, während die zugrunde liegende Hardware tausendmal leistungsfähiger ist als vor zwei Jahrzehnten.

Diese Situation erfordert eine grundlegende Lösung: Die IT-Abteilung muss aufhören, wie der Große Architekt im Namen aller anderen Abteilungen zu handeln. Stattdessen muss die IT-Abteilung ein Coach für die anderen Abteilungen werden und sich ausschließlich auf die Infrastruktur4 konzentrieren, während sie den Rest den Abteilungen selbst mit einer Ermöglicher-Mentalität überlässt.

Die Position des Großen Architekten ist unhaltbar: Selbst kollektiv kann die IT nicht alles wissen, was es über Finanzen, Marketing, Vertrieb, Gehaltsabrechnung, Produktion, Buchhaltung, Transport, Planung, Compliance, Recht usw. zu wissen gibt. Der Hansdampf in allen Gassen vermasselt die meisten seiner Initiativen. Jede halbherzige Lieferung führt zu weiteren Problemen, die später behoben werden müssen. Die Entstehung von Rückstand ist sowohl unvermeidlich als auch endlos. Da Software mit jedem Jahr immer verbreiteter wird, wird der Rückstand jedes Jahr unüberschaubarer.

Die Lösung ist einfach5: Verzichten Sie auf den Großen Architekten und positionieren Sie die IT-Abteilung als Ermöglicher und Mentor für alle softwarebezogenen Initiativen, die von anderen Abteilungen durchgeführt werden. Wenn Abteilungen wie die Supply Chain für ihre eigenen Softwareinitiativen verantwortlich sind, zwingt sie dies dazu, ihre eigenen Ambitionen zu überdenken: Keine Sündenböcke mehr für den außer Kontrolle geratenen Rückstand. Die Abteilung trägt sowohl ihre Erfolge als auch ihre Misserfolge.

Die Lösung wird jedoch fast nie umgesetzt.

Die Neupositionierung der IT als Ermöglicher würde bedeuten, dass ihre Budgets um die Hälfte oder mehr gekürzt werden müssten, was eine direkte Folge eines deutlich reduzierten operativen Fußabdrucks im Unternehmen wäre. Dies ist für den Leiter der IT-Abteilung, dessen Position während des Großen Übergangs oft machtmäßig mit der des CEO konkurriert, inakzeptabel.

Dies würde auch bedeuten, dass Abteilungsleiter für ihre eigenen Softwareinitiativen - oder deren Fehlen - zur Rechenschaft gezogen werden müssten. Es ist bequem, die Schuld auf die IT abzuwälzen, wenn ein Projekt schiefgeht - ein häufiges Ereignis in der Softwareentwicklung. Es ermöglicht den Abteilungen auch, das heikle Thema der Einstellung von IT-Talenten zu umgehen, was seit Jahrzehnten eine Herausforderung darstellt.

Dennoch verliert die Perspektive des Großen Architekten allmählich an Bedeutung, da Unternehmenssoftware zunehmend zu SaaS (Software as a Service) übergeht und Anbieter sich um Hosting, Backups, Upgrades usw. kümmern. Dadurch werden Abteilungsleiter, wenn auch unbeabsichtigt, allmählich dazu gezwungen, für ihre Softwareentscheidungen verantwortlich zu sein, und die IT-Abteilung wird allmählich dazu gezwungen, ihre früheren Verantwortlichkeiten abzugeben.

Die Unternehmenssoftware ist ein Jahrzehnt zu spät zur SaaS-Party gekommen. Ich prognostiziere, dass es noch ein weiteres Jahrzehnt dauern wird, bis die meisten großen Unternehmen aus der Denkweise des Großen Architekten aussteigen.


  1. Der Rückstand in der Supply Chain nimmt viele Formen an: Schatten-IT ist weit verbreitet, Excel ist überall, Betriebsabläufe / Kunden / Lieferanten werden im Dunkeln gehalten, Bestände / Bestellungen / Sendungen sind nicht ordnungsgemäß zwischen Systemen synchronisiert, manuelle Eingaben dominieren anstelle von Automatisierung usw. ↩︎

  2. Bei diesen Großen Übergängen gibt es nur einen Gewinner: den Softwareanbieter, der den Prozess anführt. In 15 Jahren habe ich noch nie gesehen, dass ein mehrjähriges Upgrade etwas mehr als dünn inkrementelle Verbesserungen bringt. Ich habe jedoch immer wieder gesehen, wie Softwareanbieter spektakuläre Gewinne mit diesen Operationen erzielen. ↩︎

  3. Create, Read, Update, Delete. CRUD-Anwendungen sind das Brot und Butter der Unternehmenssoftware. Nahezu alle Workflow-Anwendungen und Transaktionsanwendungen sind CRUD. ↩︎

  4. Netzwerke, Identitätsföderation, Betriebssysteme, Backups usw. ↩︎

  5. Bis in die 2000er Jahre hinein war es schwierig, Unternehmenssoftware über das Internet zu verbinden. Daher war es vor den 2000er Jahren keine wirkliche Option, verschiedene Softwarelösungen einzuführen und sie anschließend zu verbinden - schon gar keine kostengünstige. Frühe Unternehmenssysteme waren aus Notwendigkeit als Monolithen konzipiert, nicht als Wahlmöglichkeit. Daher wurde die oben genannte “Lösung” erst in den frühen 2010er Jahren zu einer realistischen Option. ↩︎