Der Umgang mit Problemen führt schnell zu der Aussage: „Ab diesem Moment wird es offiziell ein IT-Problem.“
Die Anforderungen sind formuliert und die Ausnahmen genehmigt. Und nun passiert folgendes: Der Zeitplan beginnt zu rutschen und plötzlich richtet sich der Blick nach hinten. Zu unserem verlässlichen Partner. Zur eigenen IT.
„Können wir das noch bauen?“ „Wie aufwendig ist das?“ „Warum dauert das so lange?“
Was dabei gerne übersehen wird: Die IT hat nichts entschieden. Sie hat umgesetzt.
Die eigentlichen Konflikte liegen ganz woanders:
- Welche Prozesse sind wirklich relevant?
- Welche Sonderfälle dürfen sterben?
- Wer entscheidet das verbindlich?
Stattdessen wird eskaliert. Meeting auf Meeting auf Meeting. Vielleicht auch mit anschließendem Ergebnisprotokoll.
Aber was ist die Erwartung? Die IT soll moderieren, priorisieren und, noch viel wichtiger, Kompromisse finden.
Kurz um: Sie soll fachliche Entscheidungen treffen, die fachlich nie getroffen wurden.
Spätestens jetzt wird es gefährlich. Denn wenn IT-Prozesse entscheidet, entscheidet am Ende niemand.
Der Hersteller wird zum Schiedsrichter. Der Projektplan bleibt grün. Die Komplexität explodiert leise.
Und während alle über Technik sprechen, bleibt der wahre Engpass unangetastet.
Standardsoftware scheitert nicht am Code. Sie scheitert an fehlender Führung.
Doch das auszusprechen ist unbequem.
Wie handhaben Sie das in Ihrem Projekt?
Gibt es klare Zuständigkeiten, die auch gelebt werden?
Ich freue mich auf regen Austausch dazu und bin gespannt, was Sie dazu beitragen, um die Einführung einer Standardsoftware besser zu gestalten bzw. wo Sie Unterstützungsbedarf sehen.
Es empfiehlt sich auch ein Blick in die Serie meines geschätzten Kollegen Jörg Rippchen hier bei uns im arcIVUM.