6

Die IT-Organisation im Unternehmen

Wie sieht die IT-Organisation aus, um die Digitalisierung und den Betrieb gleichermaßen zu gewährleisten? Wie helfen Anleihen aus agilen Methoden? Fragen, die mich aktuell ganz persönlich bewegen und auf die ich eine Antwort brauche.

Weißt Du was mir momentan ein wenig Kopfschmerzen bereitet? Es ist der Balanceakt zwischen den unterschiedlichen Aufgabenfeldern. Im Grunde: Die IT-Organisation meines Unternehmens.

In den Folgen 52, 49 und 47 haben wir beide über die Rolle der IT gesprochen. Ich habe Dir drei große Aufgabenblöcke skizziert:

1. Regelungsgeber: Unternehmensweite, verbindliche Vorgaben für Compliance, Sicherheit, Datenschutz, Architektur und den Weg, wie IT ins Unternehmen kommt. Und natürlich die IT-Strategie.
2. Innovationskatalysator: Die IT ist Business Analyst, Demand Manager, Berater, Moderator, Ideengeber, Sparringspartner und Prototypenzurverfügungsteller.
3. Service Broker: Die IT kennt die Anforderungen des Business und setzt diese mit Hilfe externer und interner Provider in Business-Services um. Sie steht im engen Austausch mit den Fachabteilungen und steuert die Provider.

Konkret konkurrieren bei mir der Innovationskatalysator und der Service Broker um die knappen Ressourcen. Wie Du weißt, und da ist das bei mir keine Ausnahme, schlägt dringend wichtig. Bedeutet, dass Betriebsthemen Vorrang haben. Insbesondere, wenn sie ungeplant auftreten.

Es stört einfach

Du kennst das: Der Hersteller Deiner Abrechnungssoftware bringt kurz vor der Gehaltsabrechnung ein neues Update, welches unbedingt eingespielt werden muss. Sonst gibt es kein Geld.

Natürlich ohne Vorankündigung. Das bringt mehrere Aufgaben mit sich:

1. Der anstehende Change darf geplant werden.
2. Je nach Umfang der Veränderung darf es einmal im Testsystem aktualisiert und getestet werden und dann noch im produktiven System.
3. Eindringliches Nachfragen beim Hersteller, warum auch dieses Update wieder ohne Vorwarnung gekommen ist.

Ach ja, und dann noch 4. die Probleme, die nach dem Update auftauchen, weil vieles an der Lohnabrechnung nicht wirklich getestet werden kann.

Nur ein Beispiel von vielen. Du kennst sie sicher alle: Eskalationen, Sicherheitsvorfälle, größere Ausfälle und so weiter.

Das frisst Zeit, viel Zeit.

Das alleine wäre nicht so schlimm, wenn es planbar wäre. Eigentlich hatte ich für den Tag die Vorbereitung eines Workshops für HR-Self-Services geplant.

Bi-Modale IT-Organisation?

Mir geht die Frage durch den Kopf, wie meine IT-Organisation und ich damit besser umgehen können.

Mein Kopf kramt dann gleich einen Begriff von Gartner hervor: bi-modale IT. Oder auch die IT der zwei Geschwindigkeiten.

Kurz erläutert: Gartner meint, dass es einen Teil der IT gibt, der sich auf den Betrieb bzw. die Service-Brokerage kümmert und somit Werte wie Zuverlässigkeit, Sicherheit, etc. in den Vordergrund stellt.

Und es soll einen Teil geben, der agil, schnell, wendig ist, der sich mit den neuen Ideen des Business auseinandersetzt.

Dazu habe ich vor längerer Zeit schon mal im Blog etwas geschrieben bzw. einen Vortrag für Dich aufgezeichnet. 

Ich postulierte damals, dass es beide Betriebsmodi geben muss und dass dazu keine zwei Organisationseinheiten notwendig sind. Eine IT-Abteilung kann beide Modi abbilden. So meine These.

Diese deckt sich wieder mit Forrester. Diese warnen vor einer bi-modalen IT. Warum? Auf der einen Seite, weil sich die Mode-1 Kollegen (also stabil und langsam) zurückgesetzt fühlen im Gegensatz zu den Mode-2 Kollegen. Des Weiteren weil so die IT auseinanderläuft und die Mode-2ler neue Dinge schaffen und die alten Backendsysteme unangetastet lassen. Mehr dazu hier.

Es kommt noch ein Punkt dazu: Meiner Meinung nach liegt das Ziel in Crossfunktional-Teams zusammen mit dem Business. Was auch leicht wieder in bereichseigene IT-Einheiten ausarten kann.

Du merkst, ein schwieriges Thema. Lass uns mal zu bi-modal zurückkommen.

Ich sehe aktuell bei mir keine Möglichkeit beide Betriebsmodi so auszubilden, dass ich damit zufrieden bin. Zufrieden bedeutet für mich, dass alle Betriebsthemen und alle Projekte zur Zufriedenheit der Kunden gelöst werden.

Ich zweifle daran, dass es unter einem Hut funktioniert.

Mehr von weniger?

Jetzt könntest Du sagen: Robert, entweder mach weniger Projekte oder stell mehr Leute ein.

Das glaube ich, ist ein nicht ganz richtiger Schluss. Ich bin überzeugt, dass mehr Leute genauso beschäftigt sind, solange sie beide Hüte aufhaben.

Auch mutmaße ich, dass die Reduktion der Projekte keinen nennenswerten Effekt bringt.

Es gibt den Spruch: „Arbeit breitet sich in der zur Verfügung stehenden Zeit aus.“ Oder: „Eine Aufgabe dauert solange, wie Zeit vorhanden ist.“

Bedeute, es geht um Prioritäten und Deadlines, oder?

Lass uns das jetzt mal bi-modal durchspielen:

Es gibt ein Team Mode 1, das sich um den Betrieb, die Provider und die Nutzer kümmern. Sie sorgen dafür, dass alles gut läuft und die beste Leistung zu den geringsten Kosten erbracht wird. Erwartungshaltung erfüllt.

Die Kollegen des Mode 2 Teams sitzen dem Business auf dem Schoß und probieren mit denen viele neue Dinge aus. Projekte werden gestartet und abgearbeitet.

Jetzt kommt der Moment, dass das Projekt abgeschlossen ist und in den Betrieb überführt werden soll. Changeantrag, Planung der Transition und des After-Launch-Supports.

Das dauert. Die Mode 2 Kollegen wundert’s nicht, sie ärgern sich. Der Kunde wird unzufrieden. Und dann: Der Betrieb sagt, geht nicht, passt nicht mit den aktuellen Systemen zusammen. Oder: können wir erst umsetzen, wenn das und das und das erledigt ist – also in 2 Monaten.

Treffen die zwei Welten aufeinander, dann kracht es. Es entsteht eine weitere IT-Landschaft usw.

Genau das ist der Grund, warum ich postulierte, dass die Betriebsmodi der IT sinnvoll und notwendig sind und auf keinen Fall getrennt werden dürfen.

Doch wie bekommen wir das zusammen? Oder müssen wir es doch trennen?

Du merkst, ich habe dafür keine Lösung. Ich glaube, da gibt es auch nicht die Lösung. Es ist sehr davon abhängig, was von der IT erwartet wird.

Die drei Rollen (Regelungsgeber, Innovationskatalysator und Service Broker) kommen in jeder IT in unterschiedlich starker Ausprägung zur Geltung.

In einem fleischverarbeitendem Unternehmen dominiert wahrscheinlich der Service Broker. In einer Bank oder Versicherung sollte es viel mehr Innovationskatalysator sein. Genau wie bei einem Automobilhersteller.

Welche Rolle – wie stark?

Im ersten Schritt darfst Du klären und regelmäßig überprüfen, welchen Mix der drei Rollen Dein Unternehmen braucht.

Danach richtet sich dann auch die Organisationsform.

Nehmen wir die ING-DIBA. Im Juli 2015 las ich dazu auf CIO.de: „ING-DiBa-CIO Željko Kaurin treibt die Digitalisierung vehement voran. Eine IT-Abteilung brauche sein Haus dazu in fünf Jahren allerdings nicht mehr.“ Der Artikel ist lesenswert. Link dazu findest Du in den Shownotes.

Aus Sicht der Bank bin ich mir sicher, dass das genau das richtige Ziel ist. Crossfunctional-Teams bestehend aus Business und IT. Das hat Potential. Da kommen bestimmt tolle Produkte zusammen.

Doch was passiert dann im Backend? Schnittstellen, gemeinsame Plattform und so weiter. Ganz ohne Zentrale wird es nicht gehen. Zumindest darf die Rolle Regelungsgeber stark ausgeprägt sein. Es braucht ein wirklich gutes und vor allem durchsetzungsstarkes Architekturmanagement.

Welches durchaus als Community of Practice aus den Menschen in den einzelnen Teams bestehen kann. Es bedarf einer zentralen Verantwortung und Führung. Ähnlich sehe ich das für die Rolle Service Broker. Auch da kommen die Kosteneffekte nur durch Standardisierung und Einkaufsmengen.

Also doch wieder eine Two-Speed-IT? Leider habe ich seit Juli 2015 nichts mehr von diesem Vorhaben gehört oder gelesen. Wer Insights hat, mag mich bitte kontaktieren.

Mehr als die Summe des Ganzen

Meiner Meinung nach geht nichts an Crossfunctional-Teams vorbei. 

Ein Crossfunctional-Team ist ein Team, welches gemeinsam (!!!) alle Fähigkeiten besitzt, um das Ziel zu erreichen.

Das geht meiner Meinung damit nach einher, dass wir Teams nicht mehr nach Technologien aufstellen, sondern entlang von Services oder Kunden.

Bedeutet, dass ein Team alle Fähigkeiten hat, um den Service „Rechnung stellen“ zu erbringen. Also es gibt im Team die Skills für Navision, SQL-Server, Windows, VMware, Netapp und Cisco. Natürlich abhängig von der Fertigungstiefe.

Oder es hat alle Fähigkeiten um alle Services für einen Kunden zu erbringen.

In der Softwareentwicklung nennt man das den Wandel von den „component-based teams“ zu den „feature-based teams“. In unserem Kontext sind Komponenten die Applikationen, Hardware und was sonst noch dazu gehört. Features sind die Services.

Auch hier stellt sich jetzt die Frage, wie das mit den zentralen Vorgaben und Richtlinien verhält. Wäre ja Blödsinn, wenn der eine Storageadministrator Netapp kauft und der andere EMC. Und das wird sich in vielen weiteren Kleinigkeiten zeigen.

Da kommen wieder die Community of Practices ins Spiel. Quasi die Arbeitsgruppe aller Storagadministratoren, die sich um die Standards dieser Komponenten kümmern.

Beide Konzepte habe ich in meinem „Whitepaper „7 Agile Praktiken“ ausführlicher beschrieben.

Wenn Du Mitglieder der Servicenerds.Bibliothek bist, findest Du es dort im Regal „Service-Management-Werkzeugkasten“.

 

Jetzt löst das nicht mein eigentliches Problem. Mein Problem ist, dass der Betrieb die Zeit für die Innovation kanabalisiert. Oder einfach auffrisst.

Agile Adaption

Dann dürfen wird uns im nächsten Schritt ein weiteres Mal von den agilen Methoden inspirieren lassen: Im Scrum gibt es den Product Owner. Der ist der Übermensch, der sowohl vom Business Ahnung hat, als auch von der Entwicklung. Er übersetzt Kundeanforderungen in Epics und Storys, priorisiert diese, nimmt die ab und steuert so den Entwicklungsprozess.

Da war jetzt ein klein wenig Polemik dabei, da ich aus eigener Erfahrung sehr viel Hochachtung vorn POs habe, die wirklich allen Anforderungen und Aufgaben gerecht werden. Es ist schon sehr vielschichtig.

Das übertragen wir jetzt auch auf das Service Management und etablieren eine Rolle namens Service Owner.

Diese Rolle ist für einen Service vollumfänglich verantwortlich. Sowohl für den Betrieb als auch die Weiterentwicklung.

Er nimmt alles was reinkommt: Projekte, Anforderungen, Changes, Tickets, Probleme und Sonderaufgaben. Priorisiert diese entsprechend der Wichtigkeit für das Business und gibt diese ins Team zur Abarbeitung. Er kontrolliert die Umsetzung und nimmt das Ergebnis ab.

Das heißt, aus all den Eingangskanälen, die man so in der IT hat, wird für das Service Team ein einziger, priorisierter Kanal, der abgearbeitet werden kann.

In der Softwareentwicklung funktioniert das wirklich gut. Dort sprechen bei den Interationen oder Sprints von Zeiträumen von ein bis vier Wochen. In dieser Zeit bleibt der Plan fix und es ändert sich was in wirklichen Notfällen.

Das Team kann konzentriert arbeiten.

Wie lange?

Wie lang soll die Iteration in einem Service Team sein? 1 Tag, 3 Stunden? Wäre auszutesten.

Oder wir bedienen uns dann bei Kanban. Dort gibt es keine Planung einer Iteration, sondern wer fertig ist, fragt Kollegen, ob er helfen kann und wenn nicht, nimmt er die nächste Karte. Da kann der Service Owner beliebig oft umpriorisieren.

Gewinnt dann nicht auch wieder der Betrieb und die Projekte bleiben liegen?

Bleibt mir noch das Team im Wechsel zu teilen: Es gibt immer einen oder mehrere Verantwortliche, die den Support sicherstellen. Sind wir wieder bei der Trennung.

Huh – die Folge ist länger geworden, als ich gedacht hatte.

Wie ist Deine Erfahrung? Wie gehst Du mit diesem Widerspruch um? Wie gestaltest Du den Arbeitsablauf, die Organisation? Lass uns darüber einfach diskutieren. Schreibe bitte Deine Erfahrung und Meinung in die Kommentare.

In 14 Tagen werde ich den Service Owner wieder aufgreifen und eine Rollenklärung und Abgrenzung zum Service Manager versuchen.