Ein Artikel von unserem erfahrenen Interim Manager und Partner Heinrich Schülen
Welcher CIO kennt sie nicht, Glaubenssätze wie: "Diese veraltete Software zur Geschäftsprozess-Steuerung ist doch tot. Damit beschäftigt sich heute niemand mehr!" – "Die Hersteller-Unterstützung für den PSA-Tool-Stack läuft bald aus. Bis dahin müssen wir alles migriert haben!" – "Wir machen damit aber noch drei Viertel unseres Umsatzes. Diese Tools sind nicht so schlecht, wir müssen sie nur richtig einsetzen." – "Bloß keine neue IT-Architektur, die uns Anwendungsentwickler gängelt. Mit vernünftigen Anforderungen wissen wir selbst sehr gut, was wir zu programmieren haben."
Derartige Meinungen führen oft zu verhärteten Fronten zwischen Fachbereichen und IT sowie innerhalb der IT. Jedes Argument hat irgendwo seine Berechtigung und doch muss die IT-Führung dafür sorgen, dass alle an einem Strang ziehen und das große Ganze im Blick behalten. Effizienz, Flexibilität und Innovation lassen sich nicht unter virulenten Generationenkonflikten erreichen.
Im System-Dschungel
In einem kürzlich abgeschlossenen Mandat herrschte eine kaum überschaubare Vielzahl von gewachsenen IT-Systemen. Jede der drei Sparten hatte ihre aktuellen und ihre Alt-Systeme. Einzelne Segmente innerhalb der Sparten hatten wiederum eigene Systeme, meist in mehreren Generationen. Konzern-Systeme wie das zentrale Rechnungswesen mussten von allen Sparten-Systemen bedient werden. Migration und Abschalten der Systeme zugekaufter Tochtergesellschaften zogen sich hin.
Vor gut zehn Jahren hatte das Unternehmen in einem ersten Anlauf zwar schon einige arbeitsaufwändige und systemübergreifende Prozesse mittels Prozess- und Service-Architektur (PSA) und eines zentralen Tool-Stacks mit Service-Bus, Process-Engine etc. automatisiert. So sollte verhindert werden, dass die Zahl der Schnittstellen tendenziell mit dem Quadrat der Zahl der Systeme steigt. Jedoch kam es aufgrund des hohen Termindrucks in der Software-Entwicklung bei späteren Anpassungen zu zahlreichen "Abkürzungen". Den daraus im Tool entstandenen Abweichungen vom Ursprungskonzept, folgten die in solchen Fällen typischen Konsequenzen wie eingeschränkte Release-Fähigkeit, erschwerte Fehlersuche sowie aufwändige Testläufe. Folgerichtig war zur Automatisierung weiterer Prozesse nur wenig Kapazität vorhanden und die Flexibilität zur Entwicklung neuer Produkte ziemlich gering.
Wenn dann Entwicklungsarbeiten mit neueren Entwicklungs- und Laufzeit-Umgebungen sowie Prinzipien wie Micro Services schneller und einfacher gehen, aber einige Kollegen die bisherigen, traditionellen Konzepte eingeführt haben, entstehen zwangsläufig Konflikte und Lagerbildungen zwischen den unterschiedlichen IT-Prinzipien.
Moderation ist der Schlüssel
Neben allen technischen und architektonischen Fragen war es deshalb eine Hauptaufgabe dieses Mandates, Fronten aufzuweichen und die Kolleginnen und Kollegen miteinander über die richtigen Themen sprechen zu lassen und die richtigen Ergebnisse zu erzielen. Es ging darum, eine wichtige Voraussetzung zu schaffen, die eigentlichen Ziele des Mandats, nämlich Flexibilisierung und Verbesserung der Handhabbarkeit und Skalierbarkeit der IT-Landschaft zu erreichen. Der Interim Manager war hier nicht nur fachlicher Koordinator der Weiterentwicklung der IT-Architektur, sondern vor allem auch Moderator des Gesamtprozesses. Mit strikter Sach- und Zielorientierung und Rückendeckung der Führungsmannschaft konnte er die oft emotionslastige Diskussion wieder versachlichen und gegenseitige Offenheit der beteiligten Akteure herstellen. In den Workshops zur IT-Architektur ging es daher zunächst um Akzeptanz und den Abbau von Berührungsängsten.
Inhaltlich galt es, vor allem das Prinzip der „losen Kopplung“ und damit die zahlreichen Vorteile einheitlicher und systemunabhängiger Schnittstellen zu vermitteln, z. B.:
- Übergaben von Daten und Zuständen von einem System zu mehreren anderen (z. B. zur Umwandlung eines Angebots in Aufträge mehrerer Sparten) nicht jedes Mal gesondert, sondern nur einmal zu programmieren, erspart Programmier- und Pflegeaufwand. Wenn etwa ein CRM-System mit mehreren Auftrags-Systemen verschiedener Sparten verknüpft werden soll, programmiert man die CRM-Schnittstelle nur einmal und nicht mehr einzeln für jede Sparte.
- Kapselt man Systeme durch systemunabhängige Schnittstellen, so wirken sich Veränderungen innerhalb eines Systems nur dann auf andere Systeme aus, wenn sich an den zu übergebenden Daten inhaltlich etwas ändert.
- Beim Wechsel eines Herstellers schreibt man nur die Schnittstellen des einen betroffenen Systems neu, nicht die vielen zu den zahlreichen Umsystemen.
Diese klaren Nutzenvorteile haben die Anwendungsentwickler aller Sparten in zahlreichen Diskussionen akzeptiert und schrittweise verinnerlicht. Einzelfragen, wie z. B. wann ein System ein anderes direkt aufrufen darf, ohne über die Service-Vermittlungsebene zu gehen, konnten die Kolleginnen und Kollegen gezielt adressieren und gemeinsam lösen. Auf diese Weise hat sich das Unternehmen das Rüstzeug für den effektiven Einsatz aktueller Software-Techniken erarbeitet.
Koexistenz der Systeme
In zehn sogenannten Arbeitsaufträgen legte das Team fest, wie die Architektur so konkretisiert werden soll, dass sie für alle Anwendungsentwickler unmittelbar nutzbar ist. Dazu gehören z. B. API-Guidelines, die Auswahl eines API-Gateways, Standards für Datenmodelle und eingesetzte Techniken, Standards und Verantwortlichkeiten von (Micro-) Services, die Festlegung, welche Services den Unternehmenseinheiten zentral angeboten werden (z. B. Auswahl und Instanziierung des für den jeweiligen Geschäftsfall richtigen Prozesses, ggf. Routing schwieriger Geschäftsfälle sowie Prozesshistorie, -status und -reporting).
Ein wichtiger Aspekt war hier, die Koexistenz von „bisheriger“ und „neuer“ Welt sicherzustellen, so dass bestehende Services für die neuen aufrufbar und ausführbar sind und umgekehrt. Denn selbst mit dem stringentesten Migrationsplan dauert diese Koexistenz meistens einige Jahre. Daraus folgte auch die Notwendigkeit, das bisherige zentrale PSA-Tool noch einige Jahre weiterzuführen und zu pflegen. Das erforderte im Wesentlichen vier Aktivitäten:
- Entfernen nicht oder nur selten verwendeter Komponenten und Entflechtung der gegenseitigen Aufrufe. Viele Module konnten ohne Schaden entfernt werden. Einige Elemente waren bereits in anderen Modulen sehr ähnlich enthalten und konnten deshalb mit geringem Aufwand zusammengelegt werden.
- Eindeutige Vergabe der Governance für jedes Modul. Die Verantwortlichen koordinieren und kanalisieren alle notwendigen Änderungen, so dass Strukturen und Konzepte der Module erhalten bleiben.
- Mit der verbreiteten Annahme, dass das o. g. PSA-Tool bald abgelöst werde, wurde lange nicht mehr in Modernisierungen investiert und musste der Versionsrückstand entsprechend aufgeholt werden.
- Die stark gewachsene Last konnte das monolithische PSA-Tool nicht mehr bewältigen. Zur besseren Skalierbarkeit und Reduzierung von Wartezeiten und Timeouts wurde es auf mehrere Server verteilt.
Organisatorische Verankerung
Die Verantwortung für das bisherige zentrale PSA-Tool wurde erweitert, um die Einheitlichkeit der Kommunikation zwischen den zahlreichen Einzelsystemen in einer zentralen Verantwortung zu bündeln. Denn ein zentrales Ziel des Mandates lautete, eine architekturkonforme Nutzung aller zentralen Tools, ihrer Services (s. o.) und Datenmodelle sicherzustellen. Hier mussten die Entscheider sowohl inhaltliche und sparten-spezifische Kriterien als auch Kompetenzen und Erfahrungen der Mitarbeiter im Umgang mit verschiedenen Technologien sowie spezielle Kenntnisse von Tools und Systemen einbeziehen.
Mit Hilfe des gesamten Maßnahmenpakets und der unvoreingenommenen Moderation und Unterstützung des Interim Managers ist dem Kunden ein großer Schritt nach vorne gelungen. So hat sich das Unternehmen für die nächste Generation des Business Process Management gerüstet und das gemeinsame Verständnis der gesamten IT gestärkt, um künftig fachlichen Anforderungen flexibel entsprechen zu können. Die Bündelung zu einem konsolidierten Programm ermöglicht die systematische Nachverfolgung und kontinuierliche Verbesserung aller Maßnahmen.
Autor: Partner der taskforce Heinrich Schülen
Mobil: +49 171 2424984
E-Mail:
