Komplexe IT-Transformation in messbaren Geschäftserfolg überführen

Beides — und der Vertrag sagt vor der Unterschrift, welches von beidem. Die übliche Form ist, dass benannte erfahrene Leute in Ihrer Programmstruktur sitzen und nicht daneben: ein Transformationsprogrammleiter, dem Plan, Governance und die Berichterstattung an Ihre Geschäftsführung gehören, dazu leitende Architekten auf der fachlichen und der IT-Seite. Wo die Arbeit eine Bewertung und keine Umsetzung ist, ist sie Beratung und endet mit Bericht und Maßnahmenplan. In den größeren Programmen haben wir die Gremien geleitet, die wir selbst entworfen hatten, und im Namen des Kunden mit der Gegenseite verhandelt — das ist Führen, nicht Beraten.

Dort, wo zwei Sätze von Dokumenten aufeinandertreffen. Von der abgebenden Seite ein vorbereiteter Trennungsvorschlag je Systemdomäne. Von Ihrer Seite drei Dinge, die vorliegen müssen, bevor irgendein Entwurf beginnt: die Zielarchitektur, die Anwendungslandschaft und das Zielbetriebsmodell. Diese treffen in Grobkonzept-Workshops zusammen, Domäne für Domäne — Kern-ERP, Arbeitssteuerung und Entscheidungsunterstützung, Messwesen, Betriebsführung, Dokumentenmanagement, Infrastruktur — und laufen in einem einzigen Transitionsentwurf samt Fahrplan zusammen. Gibt es keine Transaktion und wird Ihre eigene Landschaft umgebaut, ist der entsprechende erste Schritt eine Aufnahme von Organisation, Prozessen, Verträgen und Kennzahlen im Ist-Zustand, danach eine Lückenanalyse — bevor jemand ein Zielbild zeichnet.

Der Termin hört auf, eine Frist zu sein, und wird zu der Randbedingung, die über der fachlichen Vorliebe steht. Bei einer von uns geführten Herauslösung war die Leitlinie von vornherein als zwei Dinge zugleich formuliert — der Stichtag und ein funktionierender Betrieb am Morgen danach —, und daraus wurde die Trenntiefe je Systemklasse abgeleitet statt einheitlich: Verwaltungssysteme logisch getrennt, Betriebsführungssysteme gemischt, weil alles physisch zu trennen zeitlich nicht gelandet wäre. Als die Gegenseite später die vollständige physische Trennung der Betriebsführungssysteme zum Stichtag verlangte, wurde das weder abgelehnt noch einfach durchgewinkt: Es durchlief drei ausgesprochene Prüfungen — günstiger über die Gesamtkosten, gefährdet den Termin nicht, technisch zukunftsfähig — und nur eine Änderung, die alle drei bestand, ging weiter. Geplant wurde parallel in einer gemeinsamen Architektenarbeitsgruppe im festen Zwei-Wochen-Takt, damit eine Umfangsfrage in vierzehn Tagen beantwortet war und nicht in einer Änderungswarteschlange.

Drei erfahrene Rollen — und wir schlagen in der Regel alle drei vor, statt eine Auswahl anzubieten. Ein Transformationsprogrammleiter: Programmplan, Governance, Berichterstattung an Ihre Geschäftsführung sowie die Koordination Ihrer Fachteams und Ihrer Lieferanten. Ein leitender Business-Architekt: der Soll-Prozesskatalog, die Fit-Gap-Analyse und Umfangskontrolle mitsamt Vereinfachungsvorschlägen. Ein leitender IT-Architekt: die Architektur-Roadmap, Integrationsentwurf und -validierung sowie die Arbeitsbeziehung zu Ihrer IT-Leitung. Bei engem Zeitplan schlagen wir alle drei in Vollzeit vor und nicht in Teilzeit — in einem knapp getakteten Programm brechen Teilzeit-Seniorrollen als Erstes.

Der Cutover ist die Umstellung selbst — die Stunden und Tage, in denen Systeme, Daten und Geschäftsprozesse tatsächlich wechseln — und er braucht einen eigenen Plan, weil kein einzelner Anwendungsstrang die Abhängigkeiten zwischen den anderen sieht. Er läuft in vier Stufen. Planung: Jeder Strang erarbeitet sein eigenes Migrationsverfahren und dessen technische Bedingungen, ein eigenes Cutover-Team führt sie zusammen, klärt die Anomalien dazwischen oder gibt sie als Aufgaben an den zuständigen Strang zurück. Probe: Die Migrationen werden in den Strängen getestet und nachgezogen, der Cutover-Plan wird an dem angepasst, was tatsächlich passiert ist. Produktivstart: geführt aus einem konsolidierten Fahrplan mit einem Dashboard je System, damit der Stand von allem gleichzeitig sichtbar ist. Und „Babysitting“: rund drei Wochen danach für die langlaufenden Aufgaben, abgeschlossen durch eine formale Übergabe an Ihren Regelbetrieb — nicht beim Produktivstart.

Er wird benannt gemeldet, mit der Folge daneben, und ein Umweg wird entworfen, bevor daraus eine Krise wird. Die Voraussetzungen werden auf einem konsolidierten Fahrplan mit datierten Meilensteinen verfolgt, und jeder Bereich wird über alle beteiligten Organisationen hinweg gemeldet als nicht betroffen, im Plan oder verrutschend — mit einer Bemerkung, warum, in klaren Worten, einschließlich „diese Beschaffung wurde noch nicht begonnen“. In einem Programm, in dem die Beschaffung der Produktionshardware nicht angelaufen war, enthielt derselbe Bericht sowohl einen dokumentierten Ausweichplan, damit die abhängige Arbeit ohne sie weiterlaufen konnte, als auch die Notiz, dass die andere blockierte Abhängigkeit eskaliert worden war. Und die nachgelagerte Folge stand geschrieben statt angedeutet: Verrutschen diese Meilensteine, verschiebt sich die nächste Welle mit. Das ist der Satz, der ein Steuerungsgremium handeln lässt.

Ein PMO verfolgt den Plan. Was großen Programmen meist fehlt, ist etwas, dem die Nahtstellen zwischen den Strängen gehören, und ein Gremium mit der Befugnis zu entscheiden. Drei Dinge kommen hinzu. Ein Cutover-Team, das zu keinem Strang gehört und dessen ganze Aufgabe der Raum dazwischen ist. Ein Architekturforum mit Vorsitz, festem Termin, Entscheidungsblatt und Entscheidungsregister — und mit schriftlich festgehaltenem Entscheidungsrahmen sowie dem, was beim Projektleiter bleibt, damit beide nicht im vierten Monat kollidieren. Und eine Verantwortungsmatrix über Unternehmensgrenzen hinweg — Sie, Ihre IT-Servicegesellschaft, die Gegenseite — bewusst abgeglichen mit den Verantwortlichkeiten, die im Trennungsvertrag bereits stehen, damit beide einander nicht widersprechen können.

Die Governance ist so gebaut, dass sie übergeben und nicht abgezogen wird. Ein Architekturforum liefern wir als Regelwerk, das Ihnen gehört: wer den Vorsitz führt, wie oft es tagt, wie ein Tagesordnungspunkt aussieht, samt Vorlagen für Entscheidungsblatt, Entscheidungsregister und Protokoll — einschließlich der Regel, dass ein Projekt nicht geschlossen werden kann, solange der Architekturbestand nicht aktualisiert ist. Genau das verhindert, dass die Dokumentation im Monat nach unserem Weggang zu verfallen beginnt. Ein Cutover endet nach der Babysitting-Phase mit einer definierten Übergabe an Ihren Regelbetrieb, nicht beim Produktivstart. Und in der Beratungsarbeit sind der Analyserahmen und die Vorlagen von Anfang an auf Wiederverwendung ausgelegt und werden an Ihre Organisation angepasst übergeben — nicht an unsere.

Zwei Formen, und absichtlich unterschiedlich bepreist. Eine abgegrenzte Bewertung — IT-Organisation, Governance, Verträge, Prozesse — ist ein Festpreis für eine genannte Anzahl Wochen. Ein Transformationsprogramm wird nach Rolle bepreist, in Vollzeitzuordnung, mit einem günstigeren Satz oberhalb einer Mindestbindung — denn das sind monatelange Rollenbesetzungen und keine Liefergegenstände, und etwas anderes zu behaupten hilft niemandem. Zur Größenordnung: Programme dieser Art laufen in Wellen, und die von uns geführten umspannten rund zwei Jahre von der ersten Planung bis zum Produktivstart der letzten Welle, wobei einzelne Cutover etwa acht Monate vor dem Umstellungstermin geplant wurden.

An der Berichterstattung, bevor Sie es anderswo erfahren. Die Unterlagen für das Steuerungsgremium tragen je Bereich einen roten, gelben oder grünen Status, mit der Begründung in klaren Worten und ausgesprochener Folgewirkung — dass ein Verzug hier die nächste Welle verschiebt. Wo etwas wirklich blockiert ist, hält dieselbe Unterlage fest, dass eskaliert wurde und worin der Ausweichplan besteht, statt das Problem still in die nächste Sitzung mitzunehmen. Und was niemand auf einer Folie sehen möchte, steht auf der Folie: In einem Programm haben wir vorab festgehalten, dass die komplexeste Welle zu komplex für eine durchgehende Generalprobe war. Diesen Satz lässt ein Lieferant gern weg — und genau ihn braucht ein Steuerungsgremium früh genug, um damit zu planen.