Yannick H.,
TLDR;
Viele IT-Probleme wie Shadow IT, unklare Verantwortlichkeiten und steigende Kosten sind keine Strategie-Fehler, sondern Organisationsfehler. Ein IT Operating Model klärt, wer was tut, was intern bleibt, was ausgelagert wird und wie Entscheidungen fliessen. Bevor du die nächste IT-Strategie schreibst, klär zuerst, wie deine IT-Funktion aufgestellt ist.
Vor ein paar Monaten sassen wir in einem Besprechungszimmer irgendwo in der Deutschschweiz. Produktionsunternehmen, gut 200 Mitarbeitende, zwei Standorte. Der IT-Leiter hatte uns eingeladen, weil "die IT-Strategie überarbeitet werden muss". Die Geschäftsführerin war auch da, der CFO, eine Teamleiterin aus der Produktion.
Die ersten zwanzig Minuten liefen wie erwartet. Zu viele Tools, das ERP kommt in die Jahre, Cloud ja oder nein, Budget reicht nie. Dann sagte die Teamleiterin etwas, das den ganzen Raum veränderte: "Ich weiss ehrlich gesagt gar nicht, an wen ich mich wenden soll, wenn ich ein IT-Problem habe. Manchmal schreibe ich dem IT-Leiter, manchmal dem Dienstleister direkt, manchmal löst es jemand aus meinem Team selbst."
Stille. Dann nickte der CFO. "Geht mir genauso. Und ich weiss auch nicht, ob das, was unser Dienstleister liefert, eigentlich gut ist."
Das war der Moment, in dem klar wurde: Das Problem hier war kein Technologieproblem. Es war ein Organisationsproblem. Die Frage war nicht, welche Tools die IT braucht. Die Frage war, wie die IT-Funktion überhaupt aufgestellt ist, damit sie liefern kann.
Willkommen beim Thema IT Operating Model.
Was damit gemeint ist und warum es fast überall fehlt
Ein IT Operating Model beantwortet eine einzige Frage: Wie ist deine IT-Funktion organisiert, um Leistung zu erbringen? Nicht was sie tun soll (das ist Strategie) und nicht welche Technologien sie nutzt (das ist Architektur). Sondern wie. Welche Rollen gibt es. Was sitzt intern, was extern. Wer entscheidet worüber. Wie IT-Leistungen zu den Geschäftsbereichen fliessen.
Wenn wir das mit Kunden besprechen, geht es fast immer um sehr konkrete Fragen:
Brauchen wir einen eigenen IT-Leiter, oder reicht ein externer CIO-as-a-Service?
Sollen Applikations-Teams zentral in der IT sitzen oder bei den Business Units?
Was soll unser Managed Service Provider übernehmen, und wo ist die Grenze?
Wer darf IT-Entscheidungen treffen, ohne dass es eskaliert werden muss?
Falsch beantwortet, kosten diese Fragen Geld, Zeit und Nerven. Und in den meisten Unternehmen werden sie gar nicht explizit gestellt. Sie werden implizit beantwortet, durch Gewohnheit und Zufall.
Zurück zu unserem Produktionsunternehmen. Drei IT-Leute intern, alles andere beim Dienstleister. Das klang auf dem Papier vernünftig. Aber die Realität sah so aus: Die drei verbrachten 80% ihrer Zeit mit operativem Tagesgeschäft. Tickets, Drucker, Passwörter zurücksetzen. Für strategische Themen blieb nichts. Die Geschäftsführung wusste nicht, wie es um die IT-Sicherheit stand. Das alternde ERP-System konnte niemand anfassen, weil keine Kapazität da war. Und parallel bauten Fachbereiche eigene Tools auf, von denen die IT nichts wusste.
Kein Kompetenzproblem. Ein Strukturproblem.
Was wir dort gemeinsam erarbeitet haben, war im Grunde eine Klärung auf zwei Ebenen. Die erste Ebene: Was bleibt intern, was geht nach aussen? Die Antwort klingt einfach, ist es aber nicht. Wir sehen zwei Extreme immer wieder. Unternehmen, die alles selbst machen wollen und ein IT-Team aufbauen, das strukturell nie gut genug aufgestellt sein kann. Und Unternehmen, die fast alles auslagern und intern das Know-how verlieren, um überhaupt beurteilen zu können, ob das Gelieferte stimmt.
Der gesunde Weg liegt dazwischen. Strategische Fähigkeiten, also IT-Leistungen, die Wettbewerbsvorteil schaffen oder echtes Risiko darstellen, gehören intern gesteuert. Auch wenn sie teilweise extern erbracht werden. Commodity-Leistungen wie Standard-Infrastruktur, Helpdesk, Patch-Management können bedenkenlos raus. (Wir haben dazu einen eigenen Artikel geschrieben: IT-Outsourcing spart wirklich Geld, oder doch nicht?)
Die zweite Ebene: Zentral oder verteilt? Die meisten Firmen denken binär. Entweder alles bei der IT-Abteilung, oder jede Business Unit macht ihr Ding. Beides hat Schwächen, die sich mit der Zeit verschärfen.
Volle Zentralisierung macht IT langsam. Das Business wartet auf Tickets, die IT kämpft mit Priorisierung, Frustration steigt. Und dann entsteht Shadow IT. Nicht weil die Leute rebellisch sind, sondern weil sie ihre Arbeit erledigen wollen. (Shadow IT ist meist das Symptom, nicht das Problem.)
Volle Dezentralisierung führt zu duplizierten Kosten, unterschiedlichen Stacks und einer Integrationshölle, die niemand mehr überblickt.
Was tatsächlich funktioniert, ist ein föderiertes Modell. Zentral gesteuert, was zentral sein muss: Security, Compliance, grundlegende Infrastruktur, Standards. Dezentral gelassen, was Geschwindigkeit braucht: Applikationen nah am Business, Teams, die direkt mit den Fachbereichen arbeiten.
Das fehlende Stück: Wer entscheidet eigentlich was?
Für unser Produktionsunternehmen war die grösste Erkenntnis nicht die Aufteilung intern/extern oder zentral/dezentral. Es war die Frage der Entscheidungsstrukturen. Denn dort lag der eigentliche Knoten.
In kleineren Unternehmen entscheidet oft die Geschäftsführung über IT, weil dort das Budget liegt. Das führt dazu, dass IT-Entscheidungen entweder zu lange dauern, weil die GF andere Prioritäten hat, oder auf Bauchgefühl getroffen werden. In grösseren Firmen gibt es zu viele Gremien. Ein IT-Lenkungsausschuss, ein Steering Committee, der CIO, der CDO. Irgendwo in diesem Konzert geht der Entscheid verloren.
Was geholfen hat: ein einfaches RACI-Modell für die fünf Entscheidungskategorien, die wirklich zählen. Strategische IT-Investitionen. Sicherheitsrelevante Entscheide. Sourcing und Vendorselektion. Architekturentscheide. Projektpriorisierung über Businessbereiche hinweg. Kein Bürokratie-Monster. Einfach Klarheit darüber, wer bei welchem Thema das letzte Wort hat.
Nach zwei Workshops hatten wir ein neues Zielbild. Die drei internen IT-Leute wurden als IT Business Partner positioniert, als Schnittstelle zwischen Fachbereichen und Dienstleister. Kein Tier-1-Support mehr, sondern Anforderungsmanagement und Vendor-Steuerung. Strategische Steuerung, also IT-Governance, Roadmap, Security-Oversight, blieb intern, wurde aber durch einen externen vCIO gestützt, der zwei Tage pro Woche zuarbeitete. Der operative Betrieb ging komplett an den Managed Service Provider, mit klarem SLA.
Das klingt nach einer grossen Umstellung. War es in Wirklichkeit nicht. Es war vor allem ein Klärungsschritt. Wer macht eigentlich was? Und warum?
Und genau das hängt auch mit dem zusammen, was viele Unternehmen "digitale Transformation" nennen. Wir haben das in einem eigenen Artikel beschrieben. Die Ursache liegt selten an fehlendem Willen. Sie liegt daran, dass die IT-Organisation nicht so aufgestellt ist, dass sie Transformation tragen kann. Zu viel im operativen Betrieb gefangen, keine Kapazität für Strategisches, keine klaren Entscheidungsstrukturen für bereichsübergreifende Projekte. Ein IT Operating Model ist die Voraussetzung, damit IT-Strategie überhaupt umsetzbar wird.
Zusammengefasst: Die meisten IT-Probleme, die wir antreffen, sind keine Technologieprobleme. Es sind Organisationsprobleme. Shadow IT, unklare Verantwortlichkeiten, schleichende Kosten, gescheiterte Transformationen. All das lässt sich auf eine gemeinsame Wurzel zurückführen: Es wurde nie explizit geklärt, wie die IT-Funktion aufgestellt sein soll. Bevor du die nächste Strategie schreibst, die nächste Toolentscheidung triffst oder den nächsten Dienstleister evaluierst, stell zuerst diese eine Frage: Passt unser Betriebsmodell noch zu dem, was wir von der IT erwarten? Die Antwort ist meistens aufschlussreicher als jede Technologie-Evaluation.
Wir machen genau das: gemeinsam mit IT-Verantwortlichen und Geschäftsführungen herausarbeiten, wie die IT-Funktion aufgestellt sein sollte. Ohne grossen Beratungsapparat. Pragmatisch, direkt, auf euren Kontext zugeschnitten. Mehr zu unserem Ansatz findest du hier.
