Die Rolle von IT
In vielen, wahrscheinlich in den meisten Großunternehmen, die eine supply chain betreiben, hat die IT-Abteilung jahrelangen Rückstau. Der Rückstau besteht aus einer Vielzahl von Fehlern, Inkonsistenzen oder Schwachstellen, die könnten behoben werden, aber werden es nicht. Neben der Entstehung eines enormen bürokratischen Aufwands demotiviert diese endlose Reihe sinnloser Ärgernisse alle. Die supply chain, die direkt in der Mitte der applikativen Landschaft sitzt, ist besonders betroffen. Anekdotisch repräsentiert der supply chain-Teil1 häufig die Hälfte des gesamten IT-Rückstaus des Unternehmens.

Schlimmer noch, der Rückstau wird häufig durch irgendeine Große Transition verschleiert, typischerweise ein ERP-Upgrade. Dies ist die direkte Folge der Erwartung, dass die Große Transition all jene Probleme löst, die in den letzten zehn Jahren unbeachtet geblieben sind. Doch diese Erwartung ist fehlgeleitet. Tatsächlich wird selbst die Große Transition, selbst wenn sie erfolgreich abgeschlossen wird2, nach einem halben Jahrzehnt viele neue Probleme eingeführt haben, selbst wenn es gelingt, einige der alten zu beseitigen.
Die Große Transition hat zwei Nebeneffekte: Erstens bringt sie alle Abteilungen – außer der IT – zum Schweigen, wenn es um Softwareangelegenheiten geht; zweitens wirkt sie wie ein schwarzes Loch, das alle Budgets und Energien absorbiert. Letzteres ist eine Folge des Ersteren.
Aufgrund ihrer Natur ist die Große Transition höchst technisch. Niemand – außer IT-Spezialisten – versteht wirklich das Kleingedruckte der Migration von einem Datenbanksystem zu einem anderen sowie die subtilen Inkompatibilitäten, die zwischen beiden existieren. Sobald die anderen Abteilungen zum Schweigen gebracht werden, gibt es keinen Widerstand, alles in Richtung der Großen Transition zu lenken. Andere Abteilungen spielen gewöhnlich mit, in der fehlgeleiteten Hoffnung, dass sie die Große Transition beschleunigen wird. Das wird sie nicht. Im Gegenteil: Je größer das Budget, desto langsamer die Initiative.
Bei großen Unternehmen war dieser Ansatz in den letzten zwei Jahrzehnten vorherrschend. Die Ergebnisse sind miserabel. Unternehmen zahlen immer noch exorbitante Gebühren für CRUD-Apps3, die vor mehr als einem Jahrzehnt – via Open Source – zur Selbstverständlichkeit hätten werden sollen. Die Verzögerungen bei der Umsetzung waren nie länger. Das Sahnehäubchen: Die Leistung und Reaktionsfähigkeit der Unternehmenssoftware ist immer noch so schlecht wie eh und je, während die zugrundeliegende Hardware 1000-mal leistungsfähiger ist als noch vor zwei Jahrzehnten.
Diese Situation erfordert eine grundlegende Lösung: Die IT-Abteilung muss aufhören, wie der Grand Architect im Namen aller anderen Abteilungen zu agieren. Stattdessen muss sie zu einem Coach für die anderen Abteilungen werden, mit exklusivem Fokus auf die Infrastruktur4, während alle übrigen Aufgaben den Abteilungen selbst mit einem Enabler-Mindset überlassen werden.
Die Position des Grand Architect ist unhaltbar: Selbst kollektiv kann die IT nicht alles wissen, was es über Finanzen, Marketing, Vertrieb, Lohnabrechnung, Produktion, Buchhaltung, Transport, Planung, Compliance, Recht usw. zu wissen gibt. Der Alleskönner vermasselt die meisten Initiativen, die er unternimmt. Jede halbherzige Lieferung führt zu weiteren Problemen, die später behoben werden müssen. Die Entstehung von Rückstaus ist sowohl unvermeidlich als auch endlos. Während Software mit jedem Jahr allgegenwärtiger wird, wird der Rückstau jedes Jahr noch unüberschaubarer.
Die Lösung ist einfach5: Geben Sie den Grand Architect auf und repositionieren Sie die IT-Abteilung als Enabler und Mentor für alle softwarebezogenen Initiativen, die von anderen Abteilungen durchgeführt werden. Indem Abteilungen, wie der supply chain, die Verantwortung für ihre eigenen Softwareinitiativen übertragen wird, sind sie gezwungen, ihre eigenen Ambitionen zu überdenken: Keine Sündenböcke mehr, wenn der Rückstau außer Kontrolle gerät. Die Abteilung trägt die Verantwortung für ihre Erfolge und Misserfolge.
Allerdings wird die Lösung fast nie umgesetzt.
Die Neupositionierung der IT als Enabler würde bedeuten, ihre Budgets um die Hälfte oder mehr zu kürzen, was direkt aus einem stark reduzierten operativen Fußabdruck im Unternehmen resultiert. Dies ist inakzeptabel für den Leiter der IT-Abteilung, dessen Position oft, was die Macht betrifft, der des CEO während der Großen Transition ebenbürtig ist.
Dies würde auch bedeuten, dass Abteilungsleiter für ihre eigenen Softwareinitiativen – oder deren Fehlen – zur Rechenschaft gezogen werden müssten. Es ist tröstlich, die Schuld an der IT abwälzen zu können, wenn ein Projekt schiefläuft – ein in der Softwarebranche häufiges Vorkommnis. Es ermöglicht den Abteilungen auch, dem heiklen Thema der Rekrutierung von IT-Talenten auszuweichen, was seit Jahrzehnten eine Herausforderung darstellt.
Dennoch, da sich die Unternehmenssoftware in Richtung SaaS (Software as a Service) bewegt, verliert die Perspektive des Grand Architect allmählich an Bedeutung, da Anbieter sich um Hosting, Backups, Upgrades usw. kümmern. Somit werden Abteilungsleiter, wenn auch nur beiläufig, allmählich gezwungen, Verantwortung für ihre Softwareentscheidungen zu übernehmen, und die IT-Abteilung wird nach und nach gezwungen, ihre früheren Zuständigkeiten aufzugeben.
Unternehmenssoftware kam ein Jahrzehnt zu spät zur SaaS-Party. Ich prophezeie, dass es noch ein weiteres Jahrzehnt dauern wird, bis die meisten Großunternehmen aus der Mentalität des Grand Architect herauskommen.
-
Der Rückstau in der supply chain tritt in vielen Formen auf: Shadow IT ist weit verbreitet, Excel ist allgegenwärtig, Betrieb / Kunden / Lieferanten werden im Dunkeln gelassen, Bestände / Bestellungen / Lieferungen sind nicht ordnungsgemäß systemübergreifend synchronisiert, manuelle Eingaben dominieren anstelle von Automatisierung usw. ↩︎
-
In diesen Großen Transitions gibt es nur einen Gewinner: den Softwareanbieter, der den Prozess anführt. In 15 Jahren habe ich noch nie ein mehrjähriges Upgrade erlebt, das mehr als minimale, inkrementelle Verbesserungen brachte. Allerdings habe ich immer wieder gesehen, wie Softwareanbieter spektakuläre Renditen aus diesen Operationen erzielten. ↩︎
-
Create, Read, Update, Delete. CRUD-Apps sind das tägliche Brot der Unternehmenssoftware. Fast alle Workflow-Apps und transaktionalen Apps sind CRUD. ↩︎
-
Netzwerke, Identitätsföderation, Betriebssysteme, Backups usw. ↩︎
-
Bis zu den 2000er-Jahren war es schwierig, Unternehmenssoftware über das Internet zu verbinden. Daher war es vor den 2000er-Jahren – undenkbar kostengünstig – keine große Option, disparate Software einzubinden und sie anschließend zu verknüpfen. Frühe Unternehmenssysteme begannen notgedrungen als Monolith, nicht aus freier Wahl. Somit wurde die oben dargestellte “Lösung” erst in den frühen 2010er-Jahren zu einer realistischen Option. ↩︎