Suche
Scheibchen für Scheibchen

Die schlanke Übersetzung von Unternehmenszielen in IT-Projekte

Kim Nena Duggen, Stefan Toth
©Shutterstock/Sergey Nivens

Viele Projekte, die sich mit Unternehmensarchitektur beschäftigen, sind starr, aufwendig und ergebnisarm. Es wird viel Zeit auf hoher Flughöhe verbracht und sehr breit gearbeitet. Die beteiligten Personen entfernen sich dabei zunehmend von den eigentlichen Problemen der Umsetzungsprojekte und die Akzeptanz im Unternehmen sinkt. Das muss nicht so sein. In diesem Artikel zeigen wir, wie Sie priorisiert und iterativ an der Unternehmensarchitektur arbeiten können. Scheibchen für Scheibchen werden Aufwände fokussiert und der Weg zur Umsetzung verkürzt.

„Je üppiger die Pläne blühen, desto verzwickter wird die Tat.“ – Fast vierzig Jahre nach dem Tod von Erich Kästner planen wir auf vielen Unternehmensebenen trotzdem noch im Kreis. Wie wäre es zur Abwechslung mit kleinen Plänen? Was würden Sie sagen, wenn Sie aus dem großen Kontext des Unternehmens die wichtigsten Aspekte kleinteilig herausgreifen könnten? Statt langer Konzeptionsphasen zahlen sich kurze Umsetzungszyklen mit schnellen Erkenntnisgewinnen aus: Basierend auf einer groben, vollständigen Sicht lassen sich Veränderungspotenziale in der IT-Landschaft gut identifizieren und priorisieren. Danach führt der Weg direkt in die Umsetzung – zur letztendlichen Wahrheit; dem Platz für echte Erfahrungen. Wir arbeiten iterativ und an strategischen Zielen orientiert. Statt vollständiger Prozessanalyse fokussieren wir früh auf kritische Fähigkeiten (siehe Kasten „Was sind Capabilities“) des Unternehmens und priorisieren stetig nach Geschäftswert. All diese agilen Anleihen verdichten sich in einer freier gestalteten, verantwortungsvolleren Realisierung. Sukzessive entsteht eine bessere Anwendungs- und Prozesslandschaft – nicht nur ein Plan für eben diese.

Was sind Capabilities?
Menschen haben Kompetenzen, Organisationen haben Fähigkeiten. Capabilities, zu Deutsch Fähigkeiten, sind die Fertigkeit, Aktivitäten erfolgreich auszuführen [1]. Durch die Fähigkeit, geschäftliche Aktivitäten auszuführen, wird die Unternehmensstrategie im täglichen Tun erreicht [2]. Capabilities werden typischerweise sehr generell und grob granular beschrieben. Einige Fähigkeiten finden sich vergleichbar in vielen verschiedenen Unternehmen wieder (Bsp.: Buchhaltung, Personalführung), andere sind eher branchen- oder unternehmensspezifisch (Bsp.: Befähigung von Kunden, Produktion von Automobilteilen).
Capabilities eignen sich für die Beschreibung einer Unternehmensarchitektur und als Priorisierungsmittel besonders gut, weil sie das Was und nicht das Wie (Prozesse) betrachten. Dadurch sind sie stabiler und für Fachabteilungen wesentlich leichter aufzuzählen und zu beschreiben. Gleichzeitig sind sie detailliert genug, um vom Management schnell und einfach bewertet werden zu können. Viele etablierte Unternehmensarchitekturframeworks (wie z. B. TOGAF, DODAF, FEAF) verwenden Capabilities, um die Businessperspektive abzubilden.

Aufmacherbild: Silhouette of businesswoman against black wall with key hole von Shutterstock / Urheberrecht: Sergey Nivens

[ header = Seite 2: Das Vorgehen im Überblick ]

Das Vorgehen im Überblick

Abbildung 1 zeigt unser Vorgehen als Prozess. Nachdem Sie als Unternehmen erkannt haben, dass Sie, aufgrund von äußeren oder inneren Veränderungen, Ihre Unternehmensarchitektur anpassen müssen, beginnen Sie zunächst mit der Identifikation noch nicht bekannter Capabilities (Schritt 1). Äußere Veränderungen können zum Beispiel aus regulatorischen Verpflichtungen, Markttrends oder Kundenanforderungen resultieren. Stellen Sie fest, dass Ihre Anwendungslandschaft veraltet ist oder Ihre Abläufe nicht mehr zur Strategie passen, wären dies Beispiele für innere Veränderungen.

Abb. 1: Unser Vorgehen im Überblick

In Schritt 2 und 3 bewerten und analysieren Sie die identifizierten Capabilities. Anschließend beschreiben Sie den Kontext und die Inhalte der am höchsten priorisierten Capabilities (Schritt 4). In Schritt 5 und 6 gehen Sie in die Lösungsfindung, Projektierung und Umsetzung. Nach Abschluss des Umsetzungsprojekts sichern Sie Ihre Erkenntnisse über eine nochmalige Capability-Bewertung (Schritt 7). Wie die Schritte im Detail funktionieren, beschreiben wir in den folgenden Abschnitten.

Schritt 1: Capabilities identifizieren

Unser Vorgehen basiert auf der schrittweisen Verbesserung von Capabilities. Grundvoraussetzung dafür ist es, die Capabilities Ihres Unternehmens zu kennen. Hierfür gibt es verschiedene bewährte Vorgehensweisen.

Zunächst kann Ihnen ein Referenzmodell helfen. Dabei ist es irrelevant, ob Sie ein Referenzmodell finden, das sich konkret auf Ihr Geschäft bezieht, sich ein Branchenmodell zur Hilfe nehmen oder ganz generell nutzen, was andere Unternehmen als Capabilities beschreiben. Microsoft hat hierfür zum Beispiel eine Übersicht sehr allgemeiner Fähigkeiten entwickelt, die sich in nahezu allen For-Profit-Organisationen wiederfinden lassen sollten [1]. Sofern Sie beim Suchen im Web oder in Fachbüchern eine Übersicht von potenziellen Fähigkeiten finden, gehen Sie diese systematisch durch und übernehmen alle Capabilities, die Sie aus Ihrem eigenen Geschäft wiedererkennen.

Eine andere Variante besteht darin, das Organigramm des Unternehmens durchzugehen und aufzulisten, welche organisatorische Stelle was tut – bspw.: Abteilung Personal, Position Personalreferent, abgeleitete Fähigkeit: Recruiting. Dies kann auch über die Frage: „Welche Aktivitäten führen Sie aus?“ an einzelnen Repräsentanten Ihrer Fachabteilungen ermittelt werden.

Ein guter Vervollständigungsmechanismus besteht darin, anschließend die End-to-End-Prozesse (Kunde-zu-Kunde-Sicht) zu durchleuchten. Stellen Sie sich also die Fragen: „Welche Anforderungen kann ein Kunde potenziell stellen? Was muss dafür getan werden? Welches Resultat erhält der Kunde?“

Sie können Referenzmodelle, Organigramm und End-to-End-Betrachtung kombinieren. Es ist allerdings an dieser Stelle nicht unbedingt nötig, alle Capabilities vollständig erhoben zu haben, da Sie über die anschließende Bewertung und Analyse noch ausreichend Möglichkeiten erhalten, Ergänzungen vorzunehmen.

Achten Sie beim Sammeln der Capabilities vor allem darauf, eine vergleichbare Granularität zu erzielen, und nutzen Sie Mittel wie Schachtelung (z. B. Oberkategorie unterstützend, Capability-Gruppe Personalmanagement, Capability Personalentwicklung) und Kategorisierung (z. B. Management-, Kern- und unterstützende Capability). So lassen sich Capabilities in Paketstrukturen (vgl. UML-Paketdiagramm) und/oder in Tabellen einfach dokumentieren und anschließend bewerten.

Schritt 2: Capabilities bewerten

Haben Sie die Capabilities gesammelt, wissen Sie, was ihr Unternehmen leistet. Interessant ist nun, welche dieser Fähigkeiten Ihre nähere Aufmerksamkeit erfordern. Welche Capability sollten Sie als Erstes analysieren und verbessern? Im agilen Sinne ebnet eine priorisierte Liste von Capabilities den Weg zu einer iterativ inkrementellen Bearbeitung. So können Sie Schritt für Schritt strategisch wichtige Capabilities verbessern, regulatorisch notwendige Änderungen veranlassen oder Quick Wins verwandeln.

Ein erster Schritt zur Priorisierung von Capabilities ist deren Bewertung nach relevanten Kriterien. Wichtig sind dabei mindestens die Folgenden:

  • Geschäftliche Wichtigkeit: Wie hoch ist der Wertbeitrag der Fähigkeit zum Unternehmen und wie hoch ist der strategische Nutzen?
  • Reife: Wie gut ist die Capability, und entspricht die Reife den gesetzlichen oder regulatorischen Bestimmungen?
  • Potenzial: Wie gut wirken sich IT-Änderungen auf die Capability aus?
  • Abhängigkeit: Wie losgelöst ist die Capability bearbeitbar?

 Gehen Sie die Capabilities aus Schritt 1 nacheinander durch und bewerten Sie sie nach diesen Kriterien. Fragen können bei dieser Einschätzung helfen und sind als Beispiel in Tabelle 1 zu finden.

Tabelle 1: Beispielfragen für zentrale Capability-Kriterien

Das Bewertungsergebnis kann danach grafisch aufbereitet werden, um einen guten und schnellen Überblick zu gewinnen. Abbildung 2 zeigt eine mögliche Visualisierungsform für ein Capability-Bewertungsergebnis. In Anlehnung an so genannte „Heatmaps“ [11] werden die Werte eingefärbt, um auszudrücken, worauf fokussiert werden sollte: Rot kennzeichnet, dass eine hohe Aufmerksamkeit gefordert ist. Die Abstufung in Richtung grün bedeutet, dass die Capability in diesem Aspekt weniger spannend ist.

Abb. 2: Beispielvisualisierung von Kriterien-Levels für Capabilities

[ header = Seite 3: Auf Kernprobleme fokussieren ]

Schritt 3: Auf Kernprobleme fokussieren

Die Ergebnisse aus Schritt 2 können noch einmal kondensiert werden [1]. Wir empfehlen die Fokussierung auf drei Aussagen:

  • Wie kritisch ist die Bearbeitung der Capability? Kritisch sind vor allem Capabilities mit hoher geschäftlicher Wichtigkeit und niedriger Reife. Sie leisten einen hohen Beitrag zum Geschäftswert, sind strategisch wichtig und werden nicht ausreichend gut unterstützt. Eventuell sind sogar regulatorische Auflagen verletzt. Kritische Capabilities sollten in der Bearbeitungspriorität weit oben landen.
  • Wie risikoreich ist die Capability momentan? Risikoreiche Capabilities haben eine niedrige Reife und viele Abhängigkeiten zu anderen Capabilities. Wegen dieser Abhängigkeiten sind sie einerseits schwer zu verbessern, andererseits beeinflussen sie potenziell andere Capabilities negativ. Sind sogar externe Abhängigkeiten vorhanden, kann sich die Fähigkeit schädigend auf Kooperationen oder das Image auswirken. Schieben Sie risikoreiche Capabilities in der Bearbeitungspriorität generell weiter nach oben.
  • Wie einfach ist eine Verbesserung der Capability? Einfach zu bearbeitende Capabilities sind solche mit hohem Potenzial und wenig Abhängigkeiten. Sie können losgelöst und effektiv bearbeitet werden. Ohne großes Risiko sind diese Capabilities in kleinen Projekten schnell bearbeitbar. Diese Veränderungen werden auch als Quick Wins bezeichnet, sind gute „Pausenfüller“ und liefern schnell sichtbare Verbesserungen, die jede Unternehmensarchitektur-Initiative einfacher machen.

Schritt 4: Businessszenarien ableiten

Businessszenarien sind gemäß Business Dictionary [3] die Beschreibung eines künftigen Geschäftszustands. Sie eignen sich, um vor allem in frühen Phasen der Architekturarbeit geschäftliche Anforderungen zu strukturieren und mit Unternehmensstrategie und Zielen abzugleichen (vgl. TOGAF, das Architekturframework der Open Group [4]). Sie sind das Kernelement des Business-IT-Alignments, weil sie geschäftlichen Ziele, aktuelle Problemstellung, betroffene Capabilities und Prozesse vereinen und so einen Grundstein für geeignete Architekturlösungen und spätere IT-Umsetzungen legen.

In diesem Schritt betrachten Sie zunächst die prioritäre Capability und prüfen gleichzeitig, welche anderen Fähigkeiten wegen hoher Abhängigkeiten miteinbezogen werden müssen. Für diesen „Capability Cluster“ befüllen Sie nun das Businessszenario (Inhalte eines Businessszenarios, Abb. 3).

Abb. 3: Zusammenhang der Inhalte eines Businessszenarios (für Strukturierung siehe TOGAF)

Problem: Definieren Sie zunächst, warum die Capability/-ies zu verändern ist/sind und wie diese Einschätzung entstand. Beziehen Sie mit ein, wovon die betrachtete Capability beeinflusst wird und in welchem Unternehmenskontext sie steht.

Prozess: Um detailliert die Lücke zwischen Ist- und Sollarchitektur betrachten zu können, sollten Sie als Nächstes die den Capabilities zugrunde liegenden Prozesse analysieren. Wo bislang also lediglich das Was bekannt ist, wird nun das Wie betrachtet. Beschreiben Sie die betroffenen Abläufe im aktuellen und künftigen Zustand. Die Prozessbeschreibungen sollten Geschäftsobjekte, Beteiligte, Aktivitäten und Ereignisse beinhalten (z. B. mittels Business Process Diagrams, [5]). Die Lücke zwischen Ist- und Sollprozess beschreibt somit die fachlichen Anforderungen an die künftigen Geschäftsprozesse des Unternehmens.

Strategie und Ziele: Als Nächstes listen Sie die bereits existierenden messbaren Strategien und Ziele auf, die durch eine Veränderung der Capabilities adressiert würden.

Qualitätsszenarien: Als eine Ergänzung, die sich für uns in der Praxis bewährt hat, werden abschließend Qualitätsszenarien erarbeitet. Diese beschreiben die nicht funktionalen Anforderungen an die künftige Softwarearchitektur aus fachlicher Perspektive [6].

Schritt 5: Lücken identifizieren

Die Businessszenarien aus Schritt 4 bieten einen guten Überblick über Probleme und Ziele. Nun sind noch einige Fragen offen:

  • Welche Teile der IT-Unternehmensarchitektur sind betroffen?
  • Welche Größenordnung hat ein entsprechendes Veränderungsprojekt?
  • Und: Welche Kompetenzen sind für die Durchführung des Projekts gefragt?

Antworten finden sich in einer groben Gap-Analyse [4], in der man die Lücke zwischen der aktuellen Unternehmenslandschaft (Baseline) und der erforderlichen Unternehmenslandschaft (Target) identifiziert. Dabei sind die vier Hauptdomänen architektonischer Arbeit auf Unternehmensebene spannend [4], [7]:

  • Geschäft (Business): Auswirkungen auf Prozesse, Rollen und Businessservices
  • Anwendung (Application): Auswirkungen auf Softwareservices, Applikationen und Schnittstellen
  • Daten (Data): Auswirkungen auf die verarbeiteten Daten und Formate
  • Technologie (Technology): Auswirkungen auf Infrastruktur und Technologie(-standards)

Ziel des Schritts ist, die Auswirkungen von Anforderungen des Businessszenarios zu verstehen. Bestimmen Sie also die Größe der Lücke in den genannten Domänen. Damit wissen Sie, wo Veränderungen nötig sind, können den Aufwand abschätzen und die richtigen Leute für die Umsetzung identifizieren (siehe Tabelle 2: „Teambesetzung: Wen Sie brauchen …“). Es ist nicht nötig, die entsprechenden Architekturen zu planen oder gar detailliert zu entwerfen. Anders als im klassischen Vorgehen nach TOGAF soll hier nur bestimmt werden, wo Veränderungen zu erwarten sind, und wie umfangreich diese sein werden. Dieser schlanke Umgang mit Konzeption und Analyse erlaubt den schnelleren Weg in Umsetzungsprojekte, wo bessere und fundierte Aussagen auf Basis konkreter Lösungen möglich sind.

Tabelle 2: Teambesetzung: Wen Sie brauchen …

[ header = Seite 4: Agile Umsetzung ]

Schritt 6: Agile Umsetzung

Zu beschreiben, wie agile Projekte aufgesetzt und durchgeführt werden, liegt außerhalb des Fokus dieses Artikels. Wir wollen hier jedoch kurz beschreiben, welche Andockpunkte es für Umsetzungsprojekte gibt, was innerhalb des Projektfokus liegen sollte und wie Sie mit dem Erkenntnisrückfluss auf Unternehmensebene umgehen sollten.

  1. Andockpunkte: Aus den Businessszenarien (Schritt 4) lassen sich eine Projektvision und erste Anforderungen für Umsetzungsprojekte extrahieren. Analysieren Sie auch die grob identifizierten Lücken aus Schritt 5, um die initiale Backlog-Befüllung eines agilen Projekts zu erarbeiten. Der zweite Andockpunkt ist die agile Releaseplanung. Sie ersetzt die traditionelle Migrationsplanung. Nachdem Sie hier nicht riesige Change-Projekte, sondern fokussierte Capability-Verbesserungen planen, funktioniert die agile Herangehensweise mit einem groben ersten Plan und kurzem Planungshorizont meist gut. Die Umsetzung erfolgt iterativ, und der stetige Erkenntnisgewinn unterstützt dabei, Ihre Planung nach und nach zu verfeinern oder zu korrigieren.
  2. Projektfokus: Innerhalb des Fokus des Umsetzungsprojekts ist auch die Auswahl möglicher Lösungen und Optionen, um die in Schritt 5 analysierte Lücke zu schließen. Im klassischen TOGAF-Vorgehen passiert dies, wie auch die Migrationsplanung, losgelöst vor der Umsetzung und damit „im luftleeren Raum“ (siehe [4], Phase: E – Opportunities and Solutions). Ohne die Rückmeldung aus der eigentlichen Umsetzung ist die Auswahl möglicher Lösungen allerdings schwer, etwaige Probleme werden erst spät erkannt und bedingen unter Umständen eine Anpassung der bereits „fertigen“ Konzeption. Verschieben Sie also die Technologie- und Lösungswahl in das Umsetzungsprojekt und erlauben Sie eine freiere, integrierte Arbeit am Problem. Das senkt das Risiko und eventuelle Kosten durch zu späten Erkenntnisgewinn [8].
  3. Erkenntnisrückfluss: Achten Sie darauf, dass Erkenntnisse aus der Umsetzung auch auf Unternehmensebene bekannt sind, dass die erstellten Lösungen und Architekturen in das „Repository“ des Unternehmens überführt werden (vgl. [4]: Repository), und dass in der Umsetzung technologische und organisatorische Standards bekannt sind bzw. eingehalten werden. Transparenz ist das Stichwort – und zwar in beide Richtungen.

Schritt 7: Nächste Iteration vorbereiten

Das Umsetzungsprojekt aus Schritt 6 läuft iterativ ab, Iterationen sind aber auch auf Unternehmensarchitekturebene das Mittel der Wahl. Sammeln Sie Ergebnisse oder Erkenntnisse aus der Umsetzung und nutzen Sie diese für eine Neubewertung Ihrer Capabilities (siehe Schritt 2). Diese Neubewertung sollte auf parallel laufende Umsetzungsprojekte keine Auswirkungen haben.

Zusätzlich können neue Standards, die Überarbeitung bestehender Richtlinien oder die Anpassung von Referenzarchitekturen notwendig werden. Diese Themen beobachten Sie am besten schon über den gesamten Verlauf des Umsetzungsprojekts, beim Abschluss empfiehlt sich jedoch eine kondensierte Analyse. Als Basis für eine entsprechende Beobachtung können Architekturbewertungen dienen. In regelmäßigen Abständen wird so Transparenz und Austausch gefördert [9].

[ header = Seite 5: Was Sie bedenken sollten ]

Was Sie bedenken sollten

Wir haben im vorliegenden Artikel vor allem auf das iterative Vorgehen fokussiert und einige Themen lediglich gestreift. Grundvoraussetzung für die scheibchenweise Arbeit an Ihrer Unternehmensarchitektur ist etwa die Kenntnis der Strategie Ihrer Organisation. Das Management muss hierin klare Wege aufzeigen, wo es grundsätzlich und langfristig hingehen soll. Unser Vorgehen ist auf messbare Unternehmensziele angewiesen, die in den Businessszenarien verarbeitet werden (Schritt 4). Ein Business-IT-Alignment kann nur gelingen, wenn es Ihnen möglich ist, aufzuzeigen, welche konkreten Ziele Sie mit der Umsetzung erreichen und welchen Mehrwert Sie für das Unternehmen schaffen. Sind diese Voraussetzungen in Ihrem Unternehmen nicht gegeben, kann vorab die Erarbeitung eines Business Motivation Models (BMM, [10]) helfen.

Eine praktische Herausforderung unseres Vorgehens liegt auch in der Komplexität parallel laufender (Umsetzungs-)Projekte. Die Ressourcenverteilung (z. B. Personal) muss der Priorisierung der gleichzeitig bearbeiteten Projekte entsprechen. Achten Sie darauf, dass sowohl Projekte innerhalb des EAM als auch außerhalb (z. B. reguläre Wertschöpfungsprojekte für den Endkunden) gleichmäßig ausgestattet werden können und sich nicht gegenseitig behindern. Die Abstimmung zwischen den Projekten stellt hier die Crux dar. Quick Wins können aufgrund ihrer geringen Abhängigkeiten zu anderen Capabilities einfach parallel bearbeitet werden. Vorsicht ist vor allem bei kritischen und somit risikoreichen Projekten geboten, die hohe Abhängigkeiten zu anderen Capabilities oder bereits laufenden Projekten haben. Eine systematische und geregelte Abstimmung über alle Projekte hilft hier. Außerdem tun Sie sich einen großen Gefallen, wenn Sie vorab unternehmensweit definieren, nach welchen Regeln und Kategorien Sie Projektergebnisse, Best Practices und Vorgaben für andere Durchführungen zentral, einfach zugänglich und leicht auffindbar ablegen (Stichwort „schlanke Repositories“ [4]).

Fazit

Der vorgestellte Prozess kann zur Erarbeitung oder Verbesserung einer Unternehmensarchitektur eingesetzt werden. Durch die Priorisierung von Capabilities und die Kondensierung in möglichst unabhängige Businessszenarien wird eine iterative und parallele Bearbeitung möglich. Das ist der große Gewinn dieser Methode: Sie können kleinteilig arbeiten und Feedback aus der Umsetzung in die weitere Konzeption auf Unternehmensebene zurückfließen lassen. In der Praxis bewährt sich die enge Verknüpfung von Umsetzungsprojekten und strategischer Ebene. Gerade die farbige Darstellung von Kritikalität (in Heatmaps) ist ein guter Katalysator für wichtige Gespräche. Zum Abschluss noch eine Empfehlung: Fangen Sie klein an.

Geschrieben von
Kim Nena Duggen
Kim Nena Duggen
Kim Nena Duggen (kd@oose.de) arbeitet als Businessanalyst, Beraterin und Trainerin bei oose in Hamburg. Ihre Schwerpunkte liegen in der Analyse, Modellierung und Optimierung von Geschäftsprozessen und Unternehmensarchitekturen und dem Coaching von Businessanalysten.
Stefan Toth
Stefan Toth
Stefan Toth arbeitet als Entwickler, Softwarearchitekt und Berater bei der embarc GmbH. Seine Schwerpunkte liegen in der Konzeption und der Bewertung mittlerer bis großer Softwarelösungen sowie der Verbindung dieser Themen zu agilen Vorgehen. Er ist Autor zahlreicher Artikel und des Buchs "Vorgehensmuster für Softwarearchitektur". Kontakt: st@embarc.de
Kommentare
  1. Kristjan Alliaj2017-04-13 17:51:01

    Wie kommen Sie auf die Ergebnisse in der Heatmap?
    Wie werden die Punkte pro Kriterium aufsummiert?
    Wie viele Punkte gibt ein ja bzw. nein für ein Kriterium?

Schreibe einen Kommentar

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