Suche
Architekturtransformation schneller gestalten

Mit WARP die richtigen Weichen stellen

Norman Brehme
©Shutterstock/arka38

Es gibt viele Möglichkeiten, gewachsene Anwendungslandschaften in Unternehmen zu verbessern. Welches Maßnahmenbündel das richtige sein wird, ist oft schwer zu entscheiden, denn die Zielsetzungen der Stakeholder sind scheinbar gegensätzlich: „Agilität steigern!“ „Kosten einsparen!“ und „Wertbeitrag steigern!“ verlangen die Fachbereiche von den IT-Bereichen. Den Fokus auf einen Aspekt zu lenken, hieße für den CIO, die anderen Ziele zu vernachlässigen. Die nachvollziehbare Identifikation von geeigneten Maßnahmen ist ein wesentliches Ziel des „Wide angle Application Rationalisation Program“-(WARP-)Ansatzes. Dieser zeigt, wie ein IT-Verantwortlicher effizient einen Maßnahmenplan entwickelt, der wiederum zu einer tragfähigen Unternehmensarchitekturtransformation führt.

Zwei Fallbeispiele aus realen Projektsituationen zeigen die schwierige Lage, in der sich IT-Verantwortliche befinden können, und wie sie sich aus dieser Lage am besten befreien. Zunächst das erste Fallbeispiel: Es waren die Kosten der IT, die dem CIO eines großen europäischen Finanzinstituts schlaflose Nächte bereiteten. Die IT war komplex, teuer und unflexibel geworden. Zeitgleich war das Unternehmen in den vergangenen Jahren so erfolgreich, dass in ca. zwanzig EU-Ländern neue Niederlassungen gegründet wurden, in denen die Bank ihren Kunden ein vergleichbares Produktportfolio offerierte. Das IT- und Businessmanagement der Landesgesellschaften war jedoch nicht einheitlich, was nicht ohne Auswirkung auf die IT-Landschaft blieb. So hatten sich eigene, dezentrale Insellösungen entwickelt. Die Kosten für die Einführung neuer Produkte und die Time-to-Market-Zeiten der IT wuchsen. Standardisierung schien die Lösung zu sein, doch die Antwort auf die Frage, welche Potenziale nun tatsächlich in welcher Reihenfolge zu heben waren, lag nicht direkt auf der Hand. Das Finanzinstitut führte daraufhin ein kurzläufiges IT-Assessment nach WARP durch: Das Vorgehen war erfolgreich, denn die Zielsetzung der Verantwortlichen – Kosten signifikant zu reduzieren – wurde erreicht. Sparpotenzial von etwa dreißig Prozent der aktuellen IT-Kosten wurde identifiziert – erreichbar innerhalb der kommenden drei Jahre. Die Verantwortlichen hatten am Ende des kurzen Projekts eine Transformationsroadmap mit kurz-, mittel- und langfristigen Maßnahmen, einen Business Case, sowie die Skizze der Zielarchitektur in der Hand. Im Kern der Maßnahmen stand die Reimplementierung von zentralen Anwendungen.

In einem zweiten Beispiel besaß ein großer deutscher Einzelhändler verschiedene Vertriebskanäle: ein ausgeprägtes Filialnetz in mehreren europäischen Ländern, mehrere Onlineshops und verschiedene Marken, unter denen der Händler am Markt auftrat. Der Händler hatte das Problem, dass die verschiedenen Vertriebskanäle nicht ausreichend miteinander vernetzt waren, das zeigte sich z. B. immer dann, wenn in Marketingkampagnen Onlinerabattaktionen angekündigt wurden, die in der Filiale nicht abgerechnet werden konnten, weil sie z. B. dem Kassensystem nicht bekannt waren. Um die verschiedenen Kanäle miteinander zu verbinden, waren im Laufe der letzten Jahre die oft individual entwickelten IT-Systeme kontinuierlich erweitert worden. Die dezentrale Organisation des Unternehmens hatte nicht zuletzt zu einer dezentralen IT geführt, bei gleichzeitig mangelnder Transparenz hinsichtlich vorhandener Funktionalität, tatsächlichen Kosten und dem IT-Portfolio. Transparenz als Grundlage für die Initialisierung weiterer Maßnahmen zu schaffen, war die Aufgabe des WARP. Am Ende wusste der Kunde, wie seine europaweit aufgestellte IT-Landschaft aussieht, welche funktionalen Redundanzen existieren und wie Maßnahmen zur Behebung derselben aussehen konnten.

Die Beispiele zeigen, wie scheinbar unterschiedlich die Ausgangssituationen für den Analyseansatz WARP sein können – im ersten Beispiel dominieren die hohen Kosten, und lange Time-to-Market-Zeiten, während im zweiten Beispiel ebenfalls hohe Kosten verbunden mit fehlenden Leistungsmerkmalen der IT ausschlaggebend sind.

Aber wie ist es möglich, mit einem WARP in kurzer Zeit aus einer diffusen Ausgangssituation zu einem sehr klaren Zielbild zu kommen?

Aufmacherbild: Chart of profit growth von Shutterstock / Urheberrecht: arka38

[ header = Seite 2: Wesentliche Ergebnisse eines WARP ]

Wesentliche Ergebnisse eines WARP

Das WARP-Vorgehen ist darauf konzipiert, effizient und effektiv die Voraussetzung für eine gelungene Transformation zu schaffen. Die wesentlichen Ergebnisse eines WARP sind ein Zielbild der Unternehmensarchitektur, die Roadmap vom Istzustand zum Zielbild und ein Business Case. 

Das Zielbild der künftigen Unternehmensarchitektur mit Schwerpunkt IT ist ein wesentliches Hilfsmittel, um die angestrebte Strukturierung der IT-Landschaft zu skizzieren. Die Beschreibung der Unternehmensarchitektur umfasst z. B. ein fachlich geschnittenes Domänenmodell, ergänzt um logische Anwendungslandschaftskomponenten, so genannte IT-Teilsysteme, eine Benennung und Zuordnung der Informationsystemservices (nach [2]).

Die Roadmap vom Istzustand zum Zielbild beschreibt die Schritte, die von der Ausgangssituation, dem Istzustand, zum Zielbild durchzuführen sind, um z. B. die Kostenziele zu erreichen. Die Schritte sind im Ergebnis inhaltlich skizziert und in eine zeitliche Reihenfolge gebracht. Abbildung 1 ist eine typische Visualisierung der Roadmap.

Abb 1.: Beispiel einer Transition Map: Maßnahmen werden über mehrere Jahre in verschiedenen Bereichen auf die Zeitachse verteilt

Der Business Case zur Erreichung des Zielbilds stellt die Kosten, den Nutzen sowie die Risiken für alle Maßnahmen als erste Indikation dar. Die Beschreibung ist so detailliert, dass Vergleiche vorgenommen und Entscheidungen getroffen werden können.

Eine wesentliche Erfahrung aus den WARP-Projekten ist, dass der Detaillierungsgrad der Ergebnisse geeignet gewählt werden sollte – nicht zu abstrakt, nicht zu detailliert – gerade ausreichend, um qualifizierte Aussagen über die weitere Vorgehensweise zu treffen.

Potenzialfelder finden

Die Probleme der Unternehmens-IT zeigen sich oft in zu hohen Kosten, mangelnder Agilität, oder einem zu geringen Wertbeitrag der IT zur gesamten Wertschöpfungskette. Die Ursachen für diese Probleme können in verschiedenen Bereichen, so genannten Potenzialfeldern, vermutet werden, die im Folgenden kurz erläutert werden:

• Das Feld der mangelnden Produktivität konzentriert sich auf die drei Themen Outsourcing, Industrialisierung in der IT und schlanke Prinzipien (Lean): Im Bereich Outsourcing stehen Aspekte der benötigten Fertigkeiten der IT, des globalen „Sourcings“ sowie der Produktivität des Faktors Mensch im Vordergrund. Mögliche Potenziale im Bereich Industrialisierung liegen in der IT-Prozessstandardisierung, der Prozessautomatisierung durch Werkzeuge in der IT-Entwicklung, sowie in der effizienten Nutzung von IT-Wissen. Typische Bereiche innerhalb des Potenzialfeldes der schlanken (Lean-) Prinzipien sind eine schlanke Kultur sowie schlanke Verfahren, zum Beispiel für Entwicklung, Betrieb und Wartung.

• Das Potenzialfeld der zu geringen Flexibilität konzentriert sich auf die Themen justierbare Kapazitäten, Regeln für die Zusammenarbeit und strukturiert für den Wandel: Das Thema justierbare Kapazitäten umfasst die Aspekte Anpassung von Leistungen und Ressourcen an tatsächliche Bedarfe, Ermittlungsverfahren für tatsächliche Servicekosten und allgemeine Serviceplanungsmechanismen. Mögliche Potenziale im Bereich Regeln für die Zusammenarbeit werden im Umfeld von betrieblicher „Governance“, Kennzahlennutzung und der Zusammenarbeit der Fachbereiche, zum Beispiel im Anforderungsmanagement mit der IT gesehen. Typische Bereiche innerhalb des Themas strukturiert für den Wandel sind eine Architekturvision, Architektur-Governance und Architekturrahmenbedingungen.

• Das Potenzialfeld des zu geringen Wertbeitrags der IT konzentriert sich auf die Themen Portfoliomanagement, dedizierte Industrielösungen und Transformationsfähigkeit: Beim Portfoliomanagement stehen die Aspekte Portfolioplanung, Business-Case-Orientierung und Business IT Value Engineering im Vordergrund. Zu den möglichen Potenzialen im Bereich dedizierter Industrielösungen gehören Geschäftsprozessanpassung hin zur IT-Anwendung sowie die Nutzung von vordefinierten Industriestandards. Typische Bereiche innerhalb des Potenzialfelds Transformationsfähigkeit sind die Geschäfts- und IT-Vision, die Strategie, das Transformationsframework sowie Mobilisierung und Ausführung der Geschäftstransformation.

Es hat sich gezeigt, dass die meisten Potenziale dem o. g. Rahmen aus 3 x 3 Feldern zugeordnet werden können. Das Ausschöpfen dieser führt schließlich zu den gewünschten Effekten hinsichtlich Kostensenkungen, Agilitätssteigerungen beziehungsweise der Wertsteigerung der IT insgesamt.

[ header = Seite 3: Fokussierung, Vernetzung und Einbindung als Erfolgskriterien ]

Fokussierung, Vernetzung und Einbindung als Erfolgskriterien

Bei der Initialisierung von Transformationsvorhaben gibt es eine Reihe von kritischen Faktoren, die für eine erfolgreiche Analyse entscheidend sind: Erstens Fokussierung auf wenige, das heißt, die wichtigsten Einflussgrößen bzw. Potenziale, zweitens die konsequente Einbindung der richtigen Stakeholder, drittens die Geschwindigkeit in der Analyse und viertens die vernetzten Sichtweisen in der Analyse. WARP adressiert diese Erfolgsfaktoren:

1. Die Fokussierung auf wenige Aspekte, die hypothetisch gesehen die größten Hebelwirkungen zeigen, ist im Gegensatz zu den häufig angewendeten und am Ende nicht erfolgreichen, breit angelegten Bewertungsansätzen ein wesentlicher Erfolgsgarant. Eine Stärke von WARP ist die im Grundsatz offene und weite Betrachtungsweise („Wide Angle“), die erst einmal vieles in Betracht zieht, um sie dann möglichst zügig wieder einzuschränken. Untersuchungspfade, die zu keinem großen Potenzial führen, werden so ausgelassen.

2. Der zweite Erfolgsfaktor sind die Stakeholder: Transformationen, die große Bereiche eines Unternehmens, wie die IT, betreffen, können nur dann gelingen, wenn die richtigen Verantwortlichkeiten an einem Tisch sitzen, sich aktiv beteiligen und auch die Verantwortung übernehmen. In der frühen Phase einer Transformation ist die Abstraktionsebene noch ziemlich hoch. Daher ist es sehr wichtig, bereits jetzt alle betroffenen Manager an einen Tisch zu bringen, die getroffene Entscheidungen später mittragen.

3. Drittens adressiert WARP die Geschwindigkeit: Die Weisheit, alles sei im Fluss und verändert sich ständig, gilt für Unternehmen und erst recht für die IT. Änderungen kommen von Innen und Außen und sie variieren je nach Branche. So mussten beispielsweise in der Finanzindustrie die Bankinstitute innerhalb weniger Jahre ihr Geschäftsmodell aufgrund europäischer Regularien dramatisch verändern. Transformationsprogramme müssen solche Rahmenbedingungen berücksichtigen und schnell die richtigen Maßnahmen definieren und umsetzen.

4. Der letzte Faktor ist die Vernetzung: Eine Analyse, die sich auf bestimmte Aspekte konzentriert und die Wechselbeziehungen außen vor lässt, greift zu kurz. Ziel muss es sein, Transformationen nicht nur innerhalb der IT zu betrachten, sondern zeitgleich das Geschäft einzubeziehen.

Fokussiert und parallel

WARP ist eine Methode, ein Vorgehensmodell, das die Ergebnisse liefert, die eine Transformation benötigt, um am Ende erfolgreich zu sein. Es ist das Ziel, schnell und fokussiert zu den richtigen Maßnahmen zu kommen. Ein sehr wichtiges Hilfsmittel zur Fokussierung sind Hypothesen. Diese beschreiben externe Treiber, die wiederum zu unternehmensinternen Herausforderungen führen, sowie die eine Lösungsrichtung eines Maßnahmenpakets. Sie enthalten eine grobe Schätzung der mit der Lösung verbundenen Nutzenpotenziale. Hypothesen stellen frühzeitig die richtigen Weichen – oder auch die falschen. Die Definition einer Hypothese ist das Ergebnis einer sehr intensiven Zusammenarbeit der wesentlichen Stakeholder zu Beginn eines WARP. Je weniger Hypothesen zu Beginn entwickelt werden, umso besser. Hier ein Beispiel einer Hypothese: Die Regulierung der Finanzmärkte als externer Treiber führt zu neuen Anforderungen an das Berichtswesen, die nicht schnell umgesetzt werden können. Da keine Kennzahlen vorliegen, werden Geschäfte durchgeführt, die gegen Regularien verstoßen, die wiederum von der Aufsichtsbehörde mit Auflagen versehen werden, ein interner Geschäftstreiber. Die IT-Systeme liefern nicht die richtigen Kennzahlen, dies wäre ein IT-Treiber. Die Implementierung eines Kennzahlensystems führt zu einer deutlich verbesserten regulatorischen Konformität mit entsprechenden Einsparungen in Höhe von x € und damit dem Nutzen. Die Hypothese ist das erste Arbeitsergebnis eines WARP und wird im Zuge der weiteren Bearbeitung analysiert.

WARP ist grundsätzlich parallel und agil angelegt, denn sechs untereinander stark vernetzte Aktivitätenstränge gewährleisten einerseits ein hohes Arbeitstempo und andererseits die Berücksichtigung von thematischen Abhängigkeiten. So werden alle wesentlichen Aspekte der Analyse der Unternehmensarchitektur erfasst. Die Stränge werden als APPS, AMBI, BIZZ, PATH, CASE und PLAN bezeichnet. Im Einzelnen gibt es zuallererst APPS: Dahinter steht eine statistische Analyse des Anwendungsportfolios, eine faktenbasierte Durchsicht von Metriken mit dem Ziel, belastbare und nachvollziehbare Grundlagen für intelligente Entscheidungen zu schaffen. Als AMBI gilt die Analyse des Anwendungskontexts, z. B. im Hinblick auf Produktivität, Flexibilität und Nutzen, mit dem Ziel, die Situation der IT gesamthaft einschätzen zu können. Hinter BIZZ steht die Analyse der Geschäftsprozesse und Organisation, die im Zusammenhang mit der Lösungsrichtung innerhalb der eingangs entwickelten Hypothesen stehen. Das heißt, nicht alle Geschäftsprozesse werden untersucht, sondern nur die von einer Änderung betroffenen. Der so genannte PATH ist der Entwurf der Zielarchitektur auf Basis der Hypothesen, eine Beschreibung und Bewertung möglicher alternativer Realisierungsszenarien. Dies ist der wichtigste Strang, da er letztlich die Lösung umschreibt. Mit CASE ist die Entwicklung eines „Business Case“ gemeint, also die Gegenüberstellung von Nutzen beziehungsweise Wertsteigerungen der IT sowie der Kosten und Risiken. Am Schluss steht der PLAN, der Entwurf einer pragmatischen „Roadmap“, die mit dem Projektportfoliomanagement abgestimmt ist.

Die Analyse der Unternehmensarchitektur mit WARP ist mit einem Trichter vergleichbar: Zu Beginn scheint die Anzahl möglicher Ansatzpunkte sehr groß. Die Entwicklung einer Hypothese führt zur Konzentration auf bestimmte Potenzialfelder – die Zahl der Ansatzpunkte ist reduziert. Innerhalb der Potentialfelder kommen bestimmte vordefinierte Analyseverfahren, so genannte Linsen, zum Einsatz. Beispiele für typische Linsen sind eine Portfolioanalyse, die Finanzanalyse, eine technische Redundanzanalyse oder die Risikoanalyse. 

Es stehen insgesamt elf Analyseverfahren zur Verfügung, denen allen gemein ist, dass Analysewerkzeuge existieren und die Ergebnistypen vordefiniert sind. Somit werden zum einen die Analyse selbst und zum anderen das gesamte Verfahren beschleunigt. Auch bei der Auswahl der Analyse kommt die Fokussierung zum Tragen: In Abhängigkeit von dem Potentialfeld und der Hypothese werden die Verfahren selektiert, z. B. kommen im Feld „Flexibilität“ die Analysetypen System Risk Analysis, Retirement Analysis, Architectural Alignment Analysis, Financial Analysis in der Regel zum Einsatz (Abb. 2).

Abb. 2: Risikoanalyse: Operational Risk Heat Map (Beispielauswertung)

[ header = Seite 4: Unternehmensarchitektur gestalten ]

Unternehmensarchitektur gestalten

Ein WARP ist der Beginn einer Transformation und nicht deren Ende. Die Istunternehmensarchitektur soll zu einer Zielarchitektur transformiert werden. Letztlich geht es meist um den langfristig tragbaren Umbau von Teilen der Anwendungslandschaft. Gestaltungsregeln der Unternehmensarchitektur – so genannte Architekturprinzipien – helfen dabei. Beispiele für Architekturprinzipien sind:

die Verwendung von Fertigsoftwarekomponenten vor Individualentwicklungen

eine Anwendungsintegration über fachlich geschnittene Services

die Etablierung von Datenhoheiten

die Trennung von Zuständigkeiten der Anwendungslandschaftskomponenten

und vieles mehr

Architekturprinzipien sind kategorisiert, z. B. nach Führungsprinzipien, Management und Organisationsprinzipien, Applikationsprinzipien, Prinzipien für Daten/Information und Technologie. Der Katalog der möglichen Architekturprinzipien ist lang. In einem WARP gilt es, die richtigen Grundsätze auszuwählen und bei der Entwicklung des Zielbilds zu berücksichtigen. Auch die langfristige Gestaltung der Unternehmensarchitektur kann im Zuge eines WARP als Maßnahme identifiziert werden. Die kontrollierte Weiterentwicklung der Anwendungslandschaft im Einklang mit den Anforderungen des Business ist eine wesentliche Aufgabe des „Enterprise Architecture Managements (EAM)“[2]. In diesem Fall werden im Zuge der Zielbildermittlung die Eckpfeiler der EAM-Prozesse definiert. Die Nutzung eines geeigneten Architekturframeworks, wie z. B. das Integrated Architecture Framework (IAF) [1], sichert die Vollständigkeit des Zielbilds ab. IAF hilft zu erkennen, welche Sichten bzw. Aspekte notwendig sind, um ein vollständiges Zielbild zu beschreiben. IAF unterscheidet die Aspekte Business, Information, Informationssystem und technische Infrastruktur in jeweils verschiedenen Abstraktionsebenen. Neben der reinen Systematik enthält ein Architekturframework auch ein Glossar, das die Kommunikation und damit das Verständnis innerhalb der eigenen Organisation für die komplexe Thematik Unternehmensarchitektur verbessert. Es gibt eine Reihe von Frameworks, die Ähnliches leisten und im Zuge eines WARP verwendet werden können, z. B. TOGAF (The Open Group Architecture Framework). Die zielorientierte Gestaltung der Unternehmensarchitektur stellt, egal welche Potenzialfelder identifiziert wurden, den Kern eines WARP dar.

Anpassungen vornehmen

Kaum ein WARP gleicht dem anderen, denn jeder Anwendungsfall ist anders. Nicht nur die Inhalte variieren, sondern auch die Vorgehensweise kann an die jeweilige Umgebung angepasst werden. Die Anpassung der benannten Aktivitätenstränge (z. B. PLAN, BIZZ) kann so weit gehen, bestimmte Stränge wegzulassen. Wenn beispielsweise die Ermittlung eines Business Case nicht im Vordergrund steht, wird BIZZ nicht durchgeführt. Wenn „nur“ die Analyse der Istanwendungslandschaft unter statistischen Gesichtspunkten notwendig ist, kann im Extremfall auch nur der Strang APPS durchgeführt werden. WARP ist ein universelles, anpassbares Werkzeug, um Potenziale zu identifizieren.

Und was kommt nach einem WARP?

Ein WARP stellt die Weichen. Die Ergebnisse werden benötigt, um eine erfolgreiche Transformation ins Leben zu rufen. Die Dynamik, die sich aus der fokussierten und vernetzten Vorgehensweise ergibt, sollte für den Start der Maßnahmen genutzt werden. Ein CIO, der dieses Werkzeug richtig nutzt, kann den Zielkonflikt auflösen. Der CIO hat dazu alles, was gebraucht wird: eine Zielarchitektur, zum Beispiel in Form der Integration einer „Commercial of the Shelf“-(COTS-)Lösung in die Anwendungslandschaft als Ersatz für eine Reihe von Altanwendungen, einer Roadmap, die aufzeigt, welche Maßnahmen in welcher Reihenfolge zur Abwicklung der Transformation notwendig sind, schließlich einen Business Case, der die Kosten der Roadmapumsetzung dem Nutzen und den Risiken gegenüberstellt. Der Maßnahmenplanung folgen dann die Entscheidung und – ganz im Sinne eines WARP-Antriebs – die zügige Umsetzung, bevor sich die Rahmenbedingungen wieder ändern. 

Kosten senken, Potenziale heben
Wer als IT-Verantwortlicher die Kosten fest im Blick hat und trotzdem ein echter Partner des Business sein möchte, der muss sich aus der Kostenfalle lösen und die Maßnahmen ergreifen, die Bewegungsfreiheit zurückzugeben. Mit WARP steht ein dynamischer, fokussierter und vernetzter Ansatz zur Verfügung, der aufzeigt, wie der Wertschöpfungsbeitrag der IT gesteigert werden kann.
Geschrieben von
Norman Brehme
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.