Governance und Changemanagement

In vielen Unternehmen sind die Aufbau- und Ablauforganisationen weitgehend von einer vertikalen Transparenz und Verantwortungsstruktur geprägt. Eine erfolgreiche Prozess- und Service-Orientierung gemäß BPM und SOA erfordert jedoch eine stärker horizontal geprägte Sichtweise. Mit ihr sollen die Kooperation und die Kommunikation der verschiedenen Projektteilnehmer verbessert werden. Diese Anforderungen werden durch Governance abgedeckt.

Unter Governance wird grundsätzlich ein Rahmenwerk verstanden, welches für ein bestimmtes Gebiet, zum Beispiel das Unternehmen selbst oder nur einen seiner Teilaspekte, wie die IT, gilt. Sie legt Regeln fest, definiert Organisationsstrukturen, Rollen und Verantwortungen und beschreibt Prozesse, Vorgangsweisen und Methoden. Die Governance ist dem eigentlichen Geschäftszweck und den Unternehmenszielen verpflichtet. Für die IT-Governance bedeutet dies nicht nur die Definition der IT-Rahmenbedingungen, sondern schließt die Betrachtung von Wirtschaftlichkeitsaspekten und die Unterstützung und Kontrolle der Geschäftsziele mit ein. Das heißt, die wesentliche Zielsetzung der Governance ist es, Regeln anhand von Geschäftszielen zu definieren und Maßnahmen der Steuerung und Kontrolle zu etablieren.

Das Thema Governance für serviceorientierte Architekturen wird ausführlich im SOA-Leitfaden besprochen. Governance wird als Erfolgsfaktor für den Aufbau serviceorientierter Architekturen bewertet. Obwohl die SOA-Governance bereits wesentliche Elemente der Prozesssicht enthält, ist sie im Kern IT-technisch geprägt und leitet sich aus den Vorgaben der IT-Governance ab. „SOA-Governance erweitert die Prozesse der Corporate Governance und der IT-Governance. SOA-Governance etabliert Governance-Strukturen und Mechanismen, die im Lebenszyklus eines Service entscheidend sind – die Identifizierung von Services gehört dazu.“

Zwei Aspekte der Governance sind in Bezug auf die Einführung von BPM-Mechanismen entscheidend. Zum einen geht es bei den direkten Zielen nahezu ausschließlich um die Gestaltung und Optimierung der Geschäftsprozesse. Diese Ziele leiten sich aus der Corporate Governance ab und sind in der Regel nicht IT-technisch. Zum anderen kommt einem weiteren Aspekt im Kontext umfassender BPM- und SOA-Modelle eine herausragende Bedeutung zu: dem Business-IT-Alignment.

BPM und SOA kombinieren bereits konzeptionell die Fachseite mit der IT-Organisation. Daher ist es entscheidend, die SOA-Governance-Strukturen, um den Aspekt des BPM zu erweitern und ein integriertes Governance-Modell bestehend aus SOA- und BPM-Governance aufzubauen.

Während BPM an sich als unternehmensweite Initiative die Erfassung, Analyse, Optimierung und Umsetzung der (Geschäfts-)Prozesse zum Ziel hat, umfasst die BPM-Governance die Schaffung der Rahmenbedingungen, die die Erreichung dieses Zieles unterstützen bzw. erst ermöglichen. Dazu gehört die Definition der Regeln, Standards sowie der Rollen einschließlich der dazugehörigen Verantwortlichkeiten. Darüber hinaus definiert die BPM-Governance Prozesse, welche die gesamte BPM-Initiative begleiten und deren Erfolg sicherstellen. Solche Governance-Prozesse könnten die folgenden Aktivitäten umfassen:

• Definition der Ziele und der Reichweite (Unternehmen, Bereich, Abteilung) des BPM-Vorhabens
• Benennung der BPM-Verantwortlichen
• Bestimmung des BPM-Reifegrades
• Definition des Fahrplans und der Meilensteine (Roadmap)
• Definition der BPM-Rollen und der Organisation
• Festlegung der Standards, Richtlinien und der Werkzeuge
• Planung des BPM-Skill-Aufbaus und der Trainings für den Einsatz der BPM-Werkzeuge
• Kommunikation der o. g. Festlegungen und Bestimmungen (z. B. im Intranet-Portal/ Wiki)
• Monitoring und Kontrolle der Erreichung der Ziele

Neben Prozessen für die Gesamtinitiative benötigt jeder spezifische Geschäftsprozess einen individuellen BPM-Governance-Prozess. Für einen einzelnen Geschäftsprozess wird ein Vorgehensmodell definiert, das den gesamten Lebenszyklus des Prozesses umfasst und somit Fach- und IT-Abteilung einbezieht. Dieses Vorgehensmodell definiert Abfolgen und Verantwortlichkeiten und insbesondere die Vorgänge beim Übergang von Fach- zu IT-Abteilung. Auch die Vorgänge von der Übernahme durch die IT-Abteilung über die technische Umsetzung, Produktivsetzung und Außerbetriebnahme bzw. Einführung einer Nachfolgeversion werden von diesem Modell vorgegeben. Eine Werkzeugunterstützung besonders zur Verwaltung von Abhängigkeiten zwischen Prozessen und deren Versionen und anderen SOA-Artefakten ist analog zur SOA-Governance unabdingbar.

Gerade im Kontext innovativer Strategien wie SOA und BPM, die strukturelle und organisatorische Änderungen im Unternehmen bedingen, sind Change-Management-Strategien elementar wichtig. In diesem Rahmen werden die angestoßenen Anpassungen als Ganzes betrachtet. Sie geben außerdem vor, wie die beteiligten Mitarbeiter eingebunden werden können. Wichtigste Faktoren sind die Transparenz sowie die Kommunikation der Vorteile für das Unternehmen und für die einzelnen Mitarbeiter. Hierfür sind vorab Konzepte auszuarbeiten, wie die Nutzenargumentation im Bezug auf die Mitarbeiter und deren Umsetzung in Form einer internen Marketingstrategie zu gestalten sind. In größeren Projekten müssen diese internen Marketingaktivitäten in Form spezifischer Rollen von Mitarbeitern „full time“ ausgeführt werden.

Eine Schlüsselrolle bei der BPM-Governance und beim Change-Management spielt das BPM-Kompetenz-Center, das auf die Einhaltung wichtiger Prinzipien bei der Umsetzung achtet, z. B.:

• Einhaltung der Geschäftsziele und -metriken
• Nachhaltigkeit und Qualitätssicherung der Änderungen durch den gesamten Lebenszyklus eines Geschäftsprozesses
• Sicherstellung, dass alle Änderungen, sowohl fachlich als auch durch IT initiiert, auf fachlicher Seite konsolidiert und berücksichtigt werden
• Aufstellung von Regeln für die Definition von Datenmodellen zur Vermeidung unnötiger und duplizierter Aufwände, z. B. primäre Definition der fachlichen Daten im fachlichen Repository, der technischen im technischen Repository (dabei ist eine Verlinkung sinnvoll, während eine Doppelpflege auf jeden Fall zu vermeiden ist)
• Erkennen gemeinsamer fachlicher Muster und deren einheitliche und effiziente Realisierung auf IT-Seite
• Berücksichtigung technischer Standards und nicht-funktionaler Anforderungen im Rahmen der fachlichen Modellierung durch Anpassung der Modellierungskonventionen

Um eine produktive Zusammenarbeit zwischen Fachbereich und IT im BPM-Kontext zu ermöglichen, ist es empfehlenswert, dass das BPM-Kompetenz-Center (s. Kapitel „Zusammenspiel zwischen Fachabteilungen und IT") regelmäßigen Austausch mit den wichtigsten Beteiligten hat. Die Häufigkeit ist von der Änderungsintensität bzw. Reife der gelebten BPM-Disziplin abhängig, sollte aber mindestens monatlich stattfinden. Wichtige Teilnehmer sind der Prozess-Owner, der leitende Business-Analyst, der Solution Architect sowie der Process-Engineer. Eine Einbindung des Projektsponsors ist in Form von Protokollierung der Entscheidungen möglich sowie durch direkte Einladung zur Teilnahme bei wichtigen Meilensteinen. Im Letzteren unterscheidet sich eine BPM-Projekt-Governance kaum von den allgemeinen Projektmanagement-Best-Practices. Der wesentliche Unterschied besteht in der deutlich engeren Kooperation an der Schnittstelle zwischen Fachbereich und IT.

Kultur/Organisation/Vorgehen

Aus der Implementierung ergeben sich wie dargestellt konkrete Veränderungen. Diese beziehen sich meist auf drei wesentliche Aspekte einer Organisation.

Die Unternehmenskultur stellt die verhaltensbeeinflussenden Werte und Normen eines Unternehmens dar, die durch das menschliche Zusammenwirken gemeinsam definiert und gelebt werden. Durch das Change-Management kann sie beeinflusst werden. Die Organisation selbst, also die arbeitsteiligen Bereiche, die Struktur, die Arbeitsprozesse, deren Reihenfolge der Abarbeitung und die dafür zuständigen Organisationseinheiten, werden mittels einer integrierten Governance an den Zielen von BPM und SOA ausgerichtet. Veränderungen der Kultur und der Organisation bewirken somit in den meisten Fällen Anpassungen auf Seiten der Ressourcen. Diese werden unter anderem durch die beteiligten Rollen und deren Verantwortungen repräsentiert.

Abbildung 6: Von Änderungen betroffene Ebenen eines Unternehmens

Klassische Sichtweisen definieren auf einer grob gerasterten Ebene Rollen, die sich im allgemeinen Sprachgebrauch etabliert haben. Die prozesszentrische Sicht eines BPM-Ansatzes erfordert im Kontrast zu einer system- und applikationszentrischen Sicht die Übernahme der Verantwortung für einen bestimmten Prozess und nicht für eine bestimmte Applikation. Diese Verantwortung ist durch die Rolle des „Process Owner" beschrieben. Der „Process Owner" ist vor allem für die fachseitig optimale Ausführung des Prozesses verantwortlich: Das heißt, er verantwortet, dass der Geschäftsprozess die fachseitigen Anforderungen und Ziele optimal erfüllt. Diese Verantwortung umfasst den kompletten BPM-Kreislauf inklusive Modellierung, Implementierung, Monitoring und Analyse. Damit fallen auch technische (Teil-)Aspekte wie die technische Modellierung mit BPMN und die Orchestrierung in den Verantwortungsbereich des Process-Owner. Der „Business Analyst" unterstützt primär die Analyse, Definition und Optimierung der Geschäftsprozesse. Es handelt sich hier um eine allgemein anerkannte Rolle, die in den Unternehmen jedoch sehr unterschiedlich interpretiert wird oder unter Umständen noch gar nicht vorhanden ist. Im Kontext der technischen Unterstützung von BPM und SOA durch ein BPM-System ist diese Rolle jedoch notwendig. Ebenfalls notwendig ist eine Rolle, die die Prozessmodellierung faktisch ausführt und im Kontext moderner Modellierungsstandards bereits über technische Fähigkeiten verfügen muss. Diese Rolle wird in der Regel mit „Process Engineer" bezeichnet. Je nach individueller Sichtweise betrifft das Aufgabengebiet des „Process Engineer" auch die Prozessimplementierung und Orchestrierung. An dieses Aufgabengebiet knüpfen die Konzeption und das Management des Service Designs und der Serviceschnittstellen an. Auch für die klassischen Aufgabengebiete der IT-Seite, primär im Bereich der IT-Architektur und der Software-Entwicklung, ergeben sich neue Aspekte. Betroffen davon ist die Rolle des „Service Developer“. Sie muss unter der Vorgabe der fachlichen Aspekte und unter Berücksichtigung der technischen Aspekte die Implementierungsarbeit leisten. Der „End User“ umfasst die Durchführung von (Geschäfts-)Prozessen unter Zuhilfenahme von Fachanwendungen. Tabelle 1 stellt die Rollen und ihre Aufgaben in komprimierter Form dar.

Tabelle 1: Rollen- und Aufgabendefinition

Individuelle Methoden und Vorgehensweisen

Methoden und Vorgehensweisen richten sich an den individuellen Unternehmenszielen aus. Sie werden durch das entsprechende Governance-Rahmenwerk beschrieben. BPM ist ein langfristig ausgelegter Transformationsprozess. Obwohl es in den Unternehmen sehr unterschiedliche Ausgangspunkte, Erfahrungen und Vorkenntnisse gibt, steht bei der Wahl der Mittel die Akzeptanz aller beteiligten Mitarbeiter im Mittelpunkt. Dies ist alles andere als trivial. Während die fachlich orientierte Seite versucht mit den wechselnden Marktanforderungen Schritt zu halten und eine hohe Agilität fordert, muss die IT den Anforderungen wie der Wiederverwendbarkeit und damit eher einer gewissen Statik genügen.

Bedingt durch unterschiedliche Ziele, ergeben sich im Bereich der Implementierung von SOA und BPM unterschiedliche Vorgehensweisen. Das Top-down-, das Bottom-up- und das Meet-in-the-Middel-Verfahren wurden bereits im Abschnitt „Ansätze für die BPM-Einführung" erläutert.

Die Vorgehensweise zur Umsetzung erfordert ein hohes Maß agiler Kooperation und Koordination. In Projekten zur Implementierung einer fachabteilungsgetriebenen Service-Orientierung ergeben sich häufige Änderungen in den Projektanforderungen. Neue Methoden müssen den in Tabelle 2 dargestellten Gegebenheiten begegnen.

Abbildung 7: Gegenüberstellung Prozess- und Service-Design

Tabelle 2: Vergleich traditioneller und neuer Herausforderungen im Projektmanagement

Besonders Änderungen durch den Kunden stellen größere Herausforderungen dar. Um diesen zu begegnen, wurden unterschiedliche Projektmanagementmethoden entwickelt. Vor allem agile Projektmanagementmethoden wie Scrum erhöhen die Erfolgsaussichten und erfreuen sich in diesem Bezug großer Beliebtheit. Neben der sehr agilen Herangehensweise verbessern sie die Integration von IT- und Fachseite.

Der Faktor der Kommunikation wird durch die Schaffung eines gemeinsamen Sprachraums unterstützt. Vorschläge zur Umsetzung hierfür finden sich unter anderem im Bereich des „Domain-driven Design" wieder. Da die Umsetzung von BPM und SOA in vielen Fällen in der Designphase mit der Modellierung verknüpft ist, bietet sich zur Unterstützung des gemeinsamen Sprachraums eine einheitliche Modellierung an. Hierfür bieten sich, wie in Tabelle 3 dargestellt, unterschiedliche Modelltypen an.

Tabelle 3: Beschreibung der Modelltypen

Auf der integrierten Modellebene stehen das synchronisierte und das Einzelmodell zur Verfügung. Beide Arten haben in den letzten Jahren eine hohe Aufmerksamkeit erfahren. So finden sich im Bereich der synchronisierten Modelle Möglichkeiten zur Überspielung von Fachmodellen mit den Notationen erweiterte Ereignisgesteuerte Prozessketten (eEPK) oder BPMN in technische Modelle mit der BPEL-Notation. Schwierigkeiten ergeben sich hierbei vor allem in der Modelltransformation. Eine mögliche Lösung bietet der zukünftige BPMN 2.x-Standard an. Durch ihn wird die Verwendung eines Einzelmodells zwischen IT- und Fachabteilungen möglich. Als Resultat wird die Kommunikation erleichtert und deren Qualität verbessert.

Der gemeinsame und abgestimmte Einsatz von agilen Projektmanagementmethoden und integrierten Modellen stellt die methodische Basis für die Implementierung von BPM und SOA dar. Ein solches Vorgehen deckt den Bedarf an Kommunikation, Koordination und Kooperation während und über die Projektdauer hinausgehend ab. Die Einführung neuer Methoden sollte zudem sowohl im Change-Management als auch in der integrierten Governance beachtet werden.

Weiter zum nächsten Artikel „BPM-Vorgehen aus Implementierungssicht“