Warum die Gratwanderung so schwierig ist – und wie sie gelingen kann

Robuste IT – oder flexible IT?

Horst Schmidt
©Shutterstock/Tompet

Die perfekte IT ist immer topaktuell, kann alles, ist flexibel, in höchstem Maße sicher und kostet nichts. Schade nur, dass Perfektion im wahren Leben so selten anzutreffen ist. IT-Manager und Planer sind ständig zwischen verschiedensten Anforderungen hin- und hergerissen. Das Spannungsfeld zwischen Bestandsstabilisierung und schneller Reaktion auf neue Trends ist dabei wohl die größte Herausforderung. Oft fehlt jedoch der methodische, systematische Kompass als Mittel der Komplexitätsreduktion. Dabei sind es eigentlich nur wenige Grundregeln, die zu beachten sind. Eigentlich …!

Die IT-Landschaften heutiger Unternehmen sind oftmals über Jahrzehnte gewachsene Strukturen, an denen jedoch ständig Änderungen und Umbauten stattfinden. Und genau hier entsteht das Spannungsfeld: Selbst wenn die IT-Landschaft aus vielen „robusten“, sprich stabilen und sicheren Einzelbestandteilen besteht, wird deren Integration mit wachsender Anzahl zunehmend komplex, und genau diese Komplexität bedroht die Robustheit. Flexibilität bedroht diese Robustheit gleich doppelt: durch schnelle Anpassungen der Einzelbestandteile wird deren individuelle Robustheit, wie auch die der Gesamtintegration, gefährdet. Flexibilität bedeutet ebenso schnellen Austausch oder Integration von IT-Systemen, was auch wieder die Integrationsrobustheit gefährdet. Der Versuch, beide Anforderungen gleichermaßen zu bedienen, ist fast immer die schlechteste Alternative. Das Ergebnis ist eine unflexible und fragile IT. Auf welches Pferd ist also zu setzen? Die Antwort liegt nicht in der IT selbst – sie liegt im Business. Und Business kann IT leider oftmals nicht.

IT Strategy und Master Planning als Managementansatz

Um der stetig wachsenden Komplexität der IT-Systeme Herr zu werden, ist eine systematische und methodische Arbeitsweise notwendig. Dabei haben sich drei grundsätzliche Ansätze herauskristallisiert: Applikationsportfoliomanagement (APM), Technologieportfoliomanagement (TPM) und IT Strategy und Master Planning (ITSMP). Diese Ansätze stehen nicht in Konkurrenz zueinander – eine Organisation mit hohem Reifegrad in den IT-Managementprozessen setzt sie alle ein. Sie haben aber unterschiedliche Schwerpunkte, und von daher ist je nach Problemstellung eine unterschiedliche Schwerpunktsetzung notwendig.

Applikationsportfoliomanagement hat die Beherrschbarkeit (Governance) der Applikationslandschaft als Schwerpunkt. Zentrale Bestandteile sind Modellierungskonventionen und die Festlegung von Kennzahlensystemen und Analyserastern. Ebenso stehen dabei Prozesse zur fortwährenden Aktualisierung der bekannten Informationen im Fokus. APM dient dazu, die laufende Evolution des Portfolios zu strukturieren, etwa durch Etablieren eines ordentlichen Versionsmanagements. Die Zielsetzung ist nicht notwendigerweise ein kleines Portfolio mit reduzierter Applikationszahl, sondern eine passende, beherrschbare Struktur.

Technologieportfoliomanagement (TPM) hingegen betreibt eine Planung der IT basierend auf den eingesetzten Technologien. Hier stehen Fragen der Zukunftssicherheit und Stabilität der Technologien im Vordergrund. Da jede im Unternehmen eingesetzte Technologie Ressourcen bindet – von direkten Kosten wie Lizenzen und Wartung bis hin zum Vorhalten von Personal für Betriebs- und Weiterentwicklungsaufgaben – sind Unternehmen bemüht, die Anzahl der Technologien niedrig zu halten, ohne dabei jedoch ihre Innovations- und Reaktionsfähigkeit auf neue Trends zu vernachlässigen.

IT Strategy und Master Planning (ITSMP) hat nochmals einen anderen Fokus: Applikationsverwendung. Dazu wird erfasst, welche IT von welchem Teil des Business (Fachbereiche, Abteilungen …) für welche Aufgaben (Prozesse oder Geschäftsfähigkeiten) eingesetzt wird. Diesem Istzustand wird eine aus Businessvorgaben abgeleitete Ziellandschaft gegenübergestellt – welche IT vom Business wofür verwendet werden sollte. Dieser Teil macht das IT Strategy Planning aus. Basierend darauf wird im IT Master Planning die Operationalisierung der Strategie geplant, wie die Lücke zwischen „Ist“ und „Ziel“ geschlossen werden kann. Der Kerntreiber des ITSMP ist das Bereitstellen einer möglichst passenden IT-Unterstützung für das Business, beispielsweise standardisiert, wo immer Standardisierung sinnvoll ist sowie flexibel, immer dort, wo das Geschäftsmodell dies erfordert.

Aufmacherbild: Child’s cubes on white background von Shutterstock / Urheberrecht: Tompet

[ header = Seite 2: IT bezieht ihre Berechtigung aus dem Business ]

IT bezieht ihre Berechtigung aus dem Business

Vielen Kollegen aus dem Business ist die IT nach wie vor ein Buch mit sieben Siegeln. Der Jargon ist schon fast eine eigene Sprache, die Inhalte sind fremd, was da genau gemacht wird und warum – es bleibt intransparent. Man braucht die IT, kann aber oftmals nur hoffen, dass sie auch das Richtige tut und die Kosten angemessen sind. Nicht wenigen IT-Verantwortlichen ist dieser Zustand auch durchaus recht. Dabei ist er unhaltbar.

Letztlich hat alles innerhalb eines Unternehmens nur eine einzige Daseinsberechtigung: Es muss dem Unternehmen nützen; einen Wertbeitrag leisten. Damit verbunden ist der Anspruch an Messbarkeit, denn gerade in kompetitiv herausfordernden Situationen wird und muss jedes Unternehmen an der Optimierung der eigenen Potenzialrealisierung arbeiten. Final gibt es da nur zwei Optionen: Entweder können Verantwortliche aufgrund von guter Datenlage präzise Entscheidungen treffen, oder es werden Pauschalentscheidungen aus dem Bauch heraus getroffen. Im Fall von Budgetkürzungen ist das konkret die Wahl zwischen präzisen Schnitten oder der Rasenmähermethode.

Es sollte im ureigenen Interesse der IT liegen, dem Business gegenüber transparenter zu werden, um eben solchen Pauschalmaßnahmen wie der Rasenmähermethode zu entgehen. Die IT muss erklären können:

  • Was machen wir für das Business?
  • Warum machen wir das für das Business?
  • Welche Veränderungen stehen an und warum? Und was hat das Business davon?

Aus der Beantwortung dieser Fragen lässt sich vieles andere herleiten – allem voran die Frage nach der Angemessenheit der Kosten. Die Beantwortung scheitert meist an zwei Dingen: Erstens spricht die IT oft genug nur unzureichend die Sprache des Business, vor allem aber werden diese Fragen innerhalb der IT selbst viel zu selten gestellt.

Business IT Alignment: Kommunikation ist der Schlüssel

Um dem Business die IT erklären zu können, muss die IT zunächst einmal das Business verstehen. Hierfür sind Prozess- oder Domänenmodelle notwendig, da sie die Businessaktivitäten in einem Referenzmodell abstrahieren. Des Weiteren ist es notwendig, zu verstehen, wer im Business was macht – also welche Organisationen welche Prozesse durchführen. Dann kann die derzeit eingesetzte IT gegen diese beiden Referenzobjekte positioniert werden, d. h. welcher Fachbereich setzt welche Anwendungen ein, um welche Aufgaben durchzuführen. Das lässt sich in einer Matrix auch hervorragend visualisieren, wie Abbildung 1 zeigt.

Abb. 1: Prozess-/Organisationsmatrix für Ist-, Soll- und Zielzustände

Damit kann die IT die ersten beiden essenziellen Fragen beantworten: Was machen wir für das Business? Und warum? Dies ist aber nur der Anfang – die Erklärung des Istzustands. Grundsätzlich lässt sich so auch ein Zielzustand abbilden – in der Tat wird genau die Visualisierung der Zielarchitektur in solchen Matrizen dringend empfohlen. Was dem aber noch vorausgeht ist die Identifikation der idealen Zielarchitektur, beispielsweise im Spannungsfeld robust vs. flexibel. Diese Zielarchitektur muss den Businessvorgaben folgen, die selten explizite IT-Vorgaben sind. Es ist die Kunst des IT-Managements, diese aus reinen Businessvorgaben zu destillieren.

[ header = Seite 3: Strategiededuktion im Näherungsverfahren ]

Strategiededuktion im Näherungsverfahren

Die Destillation einer IT-Strategie sollte als deduktives Verfahren durchgeführt werden. Dabei sollten zu Beginn die Axiome der gesamten Unternehmensstrategie herausgearbeitet werden. Folgende Fragen sind hierzu hilfreich:

  • Sind wir in einer Wachstums- oder Konsolidierungsphase?
  • Wie ist das generelle operative Modell? „Gemischtwarenladen“ oder föderativ mit immer wieder ähnlichem Geschäftsmodell?
  • Sind wir in einer Merger-Situation?
  • Wie stark ist die Integration mit Partnern? Wie ist hier die Strategie?
  • Welches sind unsere Kernbereiche/Differenzierungsmerkmale?

Aus den Antworten auf diese und ähnliche Fragen lassen sich gleich die Eckdaten für die IT-Strategie ableiten. Ein Unternehmen auf Expansionskurs muss seine IT flexibel gestalten, um sich neuen Märkten schnell anpassen und eventuelle Zukäufe zeitnah integrieren zu können. Ein Unternehmen unter hohem Kosten- und Konsolidierungsdruck – eventuell nach einer solchen Expansionsphase – benötigt eine passende IT-Strategie, etwa Portfolio- und Komplexitätsreduktion durch Standardisierung. Zur Ausbildung der Axiome müssen aber alle Faktoren gegeneinander gestellt werden, da für Teile des Business eine Standardisierung das richtige Mittel sein kann, während für andere Teile Flexibilität passender ist, genauso wie Kürzungen in Querschnittsfunktionen durchaus mit Investitionen in Kernbereichen gekoppelt werden können.

In den nächsten Schritten sollte dann eine sukzessive Verfeinerung vom Allgemeinen zum Konkreten stattfinden. So kann beispielsweise bei einer Expansion heruntergebrochen werden, welche Unternehmensteile in welchen Märkten und mit welchen Produkten expandieren sollen. Daraus lassen sich dann konkrete IT-Vorgaben ableiten. Letztlich muss es das Ziel sein, dass alle geplanten IT-Aktivitäten (Investitionen) auf solche Businessvorgaben rückführbar sind, bzw. direkt aus der Businessvorgabe heraus initiiert wurden. Über ein solches Mapping kann dann auch leicht festgestellt werden, welcher Anteil der IT-Ausgaben tatsächlich strategischen Zwecken dient und welche der bloßen Bestandspflege.

Dieser Deduktionsprozess erfordert ein enges Zusammenspiel von Business und IT. Viele der Fragen kann nur das Business beantworten. Es ist wichtig, dass sie auch von der IT gestellt werden. Nicht umsonst heißen die dafür Verantwortlichen in der IT meist Unternehmensarchitekten.

IT Strategy und Master Planning: Die Kunst der Bebauungsplanung

Nachdem über Strategiededuktion im Zusammenspiel mit dem Business die wichtigsten Anforderungen an die IT herausgearbeitet wurden, gilt es nun, die Zielarchitektur zu definieren. Dies hat zwei Facetten: zum einen die Planung der künftigen IT-Verwendung und zum zweiten die High-Level-Planung der Integration der künftigen IT-Landschaft. Hier empfiehlt sich eine Vorgehensweise in der Art der TOGAF-Methodik. Hierbei werden zunächst „Building Blocks“ aus funktionaler Perspektive geschnitten, die dann bis hin zur Implementierungsplanung weiter verfeinert und ausdifferenziert werden. Generell ist es zu empfehlen, die optimale Ziellandschaft zunächst mit Platzhaltern zu beschreiben, diese funktional zu spezifizieren und dann zu vergleichen, welche Elemente aus der Istarchitektur damit verknüpft werden können und wo Lücken sind. Die funktionale Beschreibung der Platzhalterobjekte ist dann gleichzeitig der Einstieg in die Suche nach einer passenden Lösung auf dem Markt.

Aus der Verknüpfung der Istarchitektur mit der Ziellandschaft ergibt sich damit automatisch eine Kennzeichnung der Istarchitektur als strategisch signifikanter oder abzulösender Altbestand. Genau deshalb ist es wichtig, die Ziellandschaft immer vollständig zu beschreiben und nicht lediglich das Delta zur Istlandschaft zu dokumentieren. Die strategische Signifikanz von IT-Investitionen ist in vielen Unternehmen eine maßgebliche Kennzahl in der Projektbudgetierung und der vorgeschlagene Ansatz bietet die Möglichkeit, diese wirklich zu messen, anstatt bloß zu behaupten.

Jetzt klaffen Istarchitektur und Ziellandschaft – insbesondere bei anspruchsvolleren Strategien – oft ziemlich weit auseinander. Hier kommt das Master Planning – auch Bebauungsplanung oder Roadmapping genannt – ins Spiel. Viele Strategien sind nicht in einem Schritt umsetzbar. Sollen mehrere verschiedene CRM-Lösungen, die global im Einsatz sind, durch eine gemeinsame Lösung ersetzt werden, sind meist Zwischenkonsolidierungen notwendig. Nimmt man den Begriff des Roadmapping einmal wörtlich, besteht die Kernaufgabe im Festlegen der Zwischenstationen vor dem Endzustand, also erst regionale Konsolidierung, dann kontinental, dann global.

[ header = Seite 4: Top-down vs. Bottom-up ]

Top-down vs. Bottom-up

Das Erstellen der IT-Strategie ist eine klassische Top-down-Arbeitsweise. Es wird aus allgemeinen Businessvorgaben über Deduktion herausgearbeitet, welche IT wo und wofür eingesetzt werden soll. Mit der Bebauungsplanung kommt das „Wann“ hinzu, da hier der Roll-out geplant wird. Dieser findet zunächst und im Groben vom Ziel aus statt, ist also auch ein Element der Top-down-Planung.

Gleichzeitig steht die Weiterentwicklung des IT-Portfolios nicht still. Laufende Anforderungen aus dem operativen Geschäft verändern die IT ständig. Diese können fachlicher und technischer Natur sein, hinzukommen immer wieder regulatorische Anforderungen. Dies geschieht entsprechend Bottom-up.

Damit stehen die IT-Planer in der Bebauungsplanung vor einem Dilemma: Sie planen einerseits gegen eine strategische Zielposition die Umsetzung dieser, andererseits ändert sich ihre Planungsbasis – die Istlandschaft – dauernd. Letztlich ist die Kunst in der Bebauungsplanung genau das Zusammenbringen dieser beiden Welten. Das kann nur gelingen, wenn es ein rigides IT-Projektportfoliomanagement gibt, in dem operative Anforderungen auf ihre Strategiekonformität hin überprüft werden. Es passiert in der Realität nur zu oft, dass aus dem Business heraus Anforderungen an bestehende Systeme gestellt werden, die entgegen der vorher festgelegten Strategie sind. Oftmals sind sich die Fachbereiche dessen gar nicht bewusst. Durch das Abprüfen der Strategiekonformität der operativen Anforderungen kann dann sowohl ressourcenschonend gearbeitet werden, indem etwa ein Abschaltkandidat nicht ein Jahr vor dem geplanten Ende nochmals erweitert wird oder dass mit dem Fachbereich kommuniziert wird. Die Anforderungen werden dann eben nicht aus IT-Gründen abgelehnt, sondern weil sie der mit dem Business abgestimmten Strategie widersprechen, inklusive des Verweises, um welchen Teil der Strategie es sich dabei handelt (Abb. 2).

Abb. 2: Top-down- und Bottom-up-Planung mittels ITSMP, damit strategische und operative Planung sinnvoll zusammenfinden

An dieser Stelle ist bei den Unternehmensarchitekten viel Augenmaß und Fingerspitzengefühl gefordert. Dazu gehört es, abzuwägen, welche taktischen Zwischenlösungen sinnvoll wären. Vor allem müssen sie bei sämtlichen nicht konformen Anforderungen zumindest andenken, ob die Zielarchitektur an dieser Stelle genauso stehen bleiben kann. Gerade bei regulatorischen Anforderungen ist ein Anpassen der Zielarchitektur meist unabdingbar, aber auch bei fachlichen und technischen Anforderungen kann dies der Fall sein.

Ist ja eigentlich einfach – wo ist das Problem?

Im Kern sind die bisher vorgetragenen Empfehlungen sehr einfach und lassen sich zusammenfassen unter: „Rede mit dem Business. Versteh, was es macht und machen will. Erkläre ihm, wie du es jetzt unterstützt und plane, wie du es unterstützen willst. Rede auch darüber mit ihm.“ Warum wird es dann so selten gut gemacht?

Ein massives Hemmnis ist, dass sich fast immer ein Henne-Ei-Problem auftut. Der hier vorgeschlagene Ansatz wird üblicherweise als „Integrated IT Strategy und Master Planning“ bezeichnet, seine Vorteile kommen also erst voll zum Vorschein, wenn aus dem Gesamten mehr als die Summe seiner Teile wird. IT-Projektportfoliomanagement beispielsweise kann nicht sein volles Koordinierungspotenzial entfalten, wenn es kein definiertes strategisches Ziel gibt, auf das man zuarbeiten kann. Ebenso ist das Ausarbeiten einer IT-Strategie Elfenbeinturmarbeit, wenn man es nicht mit effektivem Roadmapping kombiniert. Selbst die Herstellung der Transparenz der Istlandschaft – wohl der Block mit dem größten Einzelwert – ist kein befriedigendes Ergebnis ohne die Integration mit der gezielten Planung der weiteren Evolution.

Daneben ist die Aufwandsfrage ein häufiger Stopper. Die intensivierte Kommunikation mit dem Business kostet Zeit. Gerade am Anfang kann das viel Zeit sein. Die Ergebnisse sind nicht direkt greifbar, beziehungsweise brauchen sie Jahre bis zu ihrer Realisierung. Zudem sind sie oftmals nicht finanziell messbar. Wenn IT-Kosten um einen bestimmten Prozentsatz gesenkt werden, versteht den Vorteil jeder. Worin aber besteht der finanzielle Mehrwert einer flexibleren IT? Haben die x Millionen, die in die Verbesserung der CRM-Tools gesteckt wurden, die CRM-Prozesse um den entsprechenden Faktor verbessert? Werden deshalb jetzt x Millionen mehr umgesetzt?

Ein dritter Faktor sind auch Denkmuster, die sich unter den entsprechenden Mitarbeitern finden lassen. Die Einsicht, dass die IT ihre Daseinsberechtigung aus dem Business bezieht, ist vergleichbar mit der Einsicht, dass das Gehalt am Monatsende letztlich nicht vom Chef kommt, sondern von den Kunden bezahlt wird. Auf einer abstrakten Ebene versteht es eigentlich jeder, aber wirklich verinnerlicht? Wie sehr lassen wir uns im Alltag wirklich davon leiten, ob die Ergebnisse unserer Arbeit wirklich im Sinne ihrer Kunden sind?

Nicht zuletzt spielt die Werkzeugfrage eine wichtige Rolle. Wenn alles in Spreadsheets, Foliensätzen und ähnlichem Medien geschieht – die Referenzmodelle, die Erfassung und die Verknüpfung der IstlLandschaft, die Definition der Ziellandschaft – kann der Prozess über ein rudimentäres Stadium kaum hinauskommen. Hier sind integrierte IT-Managementlösungen gefragt, die die Datensammlung unterstützen, vor allem aber die Daten in sinnvolle Beziehung zueinander setzen und dadurch die damit verbundene Komplexitätsreduktion, Beherrschbarkeit und Planbarkeit schaffen.

[ header = Seite 5: Was tun? ]

Was tun?

Wenn man die Unternehmen betrachtet, die einen höheren Reifegrad im ITSMP erreichen, so stellt man zuerst eins fest: Sie haben sich entsprechend organisational aufgestellt. Es gibt klar definierte Teams und Verantwortlichkeiten. Verbunden mit den klaren Zuständigkeiten ist auch ein klar definierter Prozessablauf und -zyklus. Der besteht aus einem jährlichen Release der Zielarchitektur, was einerseits zeitnahes Reagieren der Strategieplaner auf aktuelle Entwicklungen ermöglicht, andererseits den Kollegen im Roadmapping ausreichend Planungssicherheit für die Roll-out-Planung gibt.

Ein weiteres Merkmal ist die aktive Kommunikation der IT. Reife IT-Organisationen sind nicht nur in der Lage, zeitnah Anfragen aus dem Business zu beantworten. Sie kommunizieren proaktiv, beispielsweise über regelmäßige Zustands- und Fortschrittsberichte. Und es werden möglichst Informationsbedarfe antizipiert, man bereitet sich darauf vor, nicht nur die immer gestellten Fragen zu beantworten, sondern auch die damit verwandten. Sie folgen letztlich einer alten Entertainerweisheit: Um im Bedarfsfall ein Ass aus dem Ärmel ziehen zu können, muss man sicherstellen, ein Ass im Ärmel zu haben.

Ein entscheidender Erfolgsfaktor ist die richtige Platzierung beim Management. Nur dann, wenn das Management die Vorteile des Ansatzes kennt, wird es bereit sein, die notwendigen Anpassungen von Organisationen und Prozessen mit zu tragen. Da die übergreifende Kommunikation essenziell ist, reicht es auch nicht aus, das Thema innerhalb der IT zu platzieren. Mithilfe des Managements müssen alle Stakeholder an einen gemeinsamen Tisch gebracht werden.

Im Endeffekt gibt es zum Auflösen von Henne-Ei-Problemen und sonstigen Hindernissen immer nur eine Möglichkeit, den Punkt mit den am schnellsten zu erzielenden Vorteilen zu identifizieren und anzufangen. Sobald ein Teil bereits Ergebnisse liefert, ist es viel leichter zu argumentieren, dass sich mit etwas Zusatzaufwand deutlich mehr herausholen lässt, als wenn noch gar nichts vorhanden ist.

Geschrieben von
Horst Schmidt
Horst Schmidt
Horst M. Schmidt beschäftigt sich bereits seit dem Studium mit der Analyse von IT-Strategien und deren Umsetzung. Seit 2008 ist er bei der alfabet AG tätig und berät internationale Konzerne in allen Fragen der Unternehmensarchitektur. Sein Spezialgebiet ist ITSMP.
Kommentare

Schreibe einen Kommentar

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