Software Architektur. Businessorientierte Architekturansätze. Kanban in Softwareprojekten. Pragmatic SOA Beschränken auf das Wesentliche.

Transkript

1 1.10 Deutschland: 14,90 Österreich: 16,80 Schweiz: sfr 29,80 Luxemburg: 16,90 Expertenwissen für IT-Architekten, Projektleiter und Berater Erl: SOA in a Box hat die Probleme verursacht Schwerpunkt: Software Architektur Businessorientierte Architekturansätze Kanban in Softwareprojekten Pragmatic SOA Beschränken auf das Wesentliche Servicesichten Den passenden Service finden People Change Management Änderungsprozesse erfolgreich meistern How does IT matter? Den Wertbeitrag der IT bestimmen Enterprise SOA Security Teil 1: Die Herausforderungen Aus alt mach neu Die 10 Regeln der Modernisierung

2 Change Management People Change Mangement in SOA und BPM-Projekten Änderungsprozesse im Team bewältigen Autoren: Dr. Dirk Krafzig, Elmar Barzen, Markus Mazur Ganz offensichtlich kann diese Zielsetzung nur erreicht werden, wenn SOA und BPM als Vorhaben verstanden werden, die auf Unternehmensebene Anwendung finden. Nehmen wir z. B. die Speicherung von Kundendaten. Die Komplexität heutiger IT-Anwendungslandschaften resultiert häufig aus der Tatsache, dass Kundendaten über duzende Datenbanken und Abteilungslösungen verteilt sind. Inkonsistenzen und Doppelentwicklungen sind die Folge. Im Gegensatz dazu liefert eine SOA standardisierte und wiederverwendbare Services, die es ermöglichen, diese Daten in verschiedenen Geschäftsprozessen entlang der gesamten Wertschöpfungskette zu verwenden. Der Übergang von einer durch Abteilungslösungen geprägte IT hin zu einer SOA ist ein komplexer Transformationsprozess, der Änderungen auf verschiedenen Ebenen erfordert. Neben neuen Technologien wie Web Services oder BPMN gilt insbesondere eine Berücksichtigung von Menschen und Organisation als herausragender Erfolgsfaktor. Obwohl dies bereits 2004 in der SOA und BPM sind die Zauberworte, wenn es um die nachhaltige Modernisierung von IT-Anwendungslandschaften geht. Sie versprechen eine Zukunft, die es den Fachbereichen erlaubt, sich aus einer Schatzkiste mit fachlichen Bausteinen zu bedienen, um neue Anwendungen und Geschäftsprozesse zu kreieren und diese viel schneller als heute in die Praxis zu transportieren. bt

3 Abb. 1: Was ist SOA und BPM? Traditionelle Silos werden in eine auf Unternehmensebene geordnete Struktur überführt. Dabei wird die Komplexität heutiger Punkt-zu- Punkt-Integration reduziert Abb. 2: Können Wollen: Das menschliche Verhalten wird von Faktoren auf unterschiedlichen Ebenen bestimmt Abb. 3: Druck und Sog bewirken Änderung Literatur [1] ausführlich beschrieben wurde, verharrt der Hauptfokus vieler SOA- und BPM-Initiativen bis heute auf der Umsetzung technischer Ziele. An dieser Stelle setzt der vorliegende Artikel an. Er befasst sich mit dem Transformationsprozess für die Menschen, die in SOA- und BPM-Initiativen involviert sind. Er liefert konkrete Vorschläge für Maßnahmen, um die Transformation nachhaltig zu gestalten. Kennen, Können, Wollen Der Ausgangspunkt unserer Diskussion ist gleichermaßen offensichtlich wie simpel. Die Menschen einer Organisation, die sich mit SOA oder BPM befassen, müssen den erforderlichen Transformationsprozess unterstützen. Offener und versteckter Widerstand, der die Umsetzung dringend benötigter Modernisierungsmaßnahmen blockiert, muss überwunden werden. Dies ist leichter gesagt als getan, denn die konsequente Einführung einer SOA-Implementierung bedeutet weit mehr als nur das Einführen einer neuen Programmiermethode. Es ist eher vergleichbar mit einer Revolution der Anwendungsentwicklung. Die neuen Möglichkeiten haben aber nicht nur großen Einfluss auf die Aufstellung der IT-Abteilungen, sondern auch auf die Geschäftsprozesse in Bezug auf Reaktions- und Veränderungsgeschwindigkeit den Erfolgsfaktoren im dynamischen Wettbewerb der Zukunft. Die Fachbereiche müssen lernen, eine aktive Rolle im Entwicklungsprozess zu übernehmen. Die Veränderungen in der IT und den Fachbereichen müssen nun durch Menschen umgesetzt werden. Jeder Mensch hat aber Gewohnheiten, Umgangsformen, Erfahrungen, die sein Verhältnis zur Welt bestimmen. Wir nennen sie Persönlichkeitsprogramme, persönliche Muster, Filter der Erfahrung, Paradigmen oder Komfortzonen. Solange ich mich im Gewohnten bewege, fühle ich mich sicher, habe die Dinge im Griff, die Sache läuft. Das Problem: Entwicklung, Neues, Erfolg ist meist außerhalb des Gewohnten angesiedelt. So ist es auch in den meisten BPM- oder SOA-Initiativen. Die Komfortzone des einzelnen Mitarbeiters wird die Grenze der persönlichen Entwicklung. Die kollektive Komfortzone des Teams begrenzt die Innovationschance der BPM- oder SOA-Initiative. Die Komfortzone zu verlassen, kann auf zwei Wegen geschehen: Pain oder Pleasure. Entweder baut man Druck von außen auf oder man erzeugt einen Sog bei Betroffenen durch eine positive Zukunftsvision, die durch persönliche Ziele unterstützt wird. Beides sind emotionale Lernprozesse (Abb. 2: Ebene 3 und 4). Bei erfolgreichem Change Management wird dieser emotionale Lernprozess sorgsam geplant und ggf. durch gezieltes Coaching unterstützt. Das Wollen geht dem Können voraus und muss nach Freisetzung im Team im Führungsprozess verankert werden. 86 bt

4 Wollen aktiv managen In komplexen Change-Projekten, wie es SOA und BPM-Vorhaben sind, kommt das Wollen nicht von allein. Es ist vielmehr eine vordringliche Aufgabe der Führungskräfte, das Wollen zu erzeugen. Hierbei muss die Ebene Einstellung und Persönlichkeit aller wichtigen Stakeholder angesprochen werden (Wollen), um in der konkreten Umsetzung (Können) Ergebnisse zu erzielen. In einer Kopplung aus Realität (Ziele, Druck, Anforderung, Pain) und positiver Zielprojektion (Sog, Vision, Pleasure) gilt es, die Akteure emotional anzusprechen und im Hinblick auf das gemeinsame Ziel auch Out of the box zu bringen. Aus Sicht der Autoren, die schon seit Jahren mit IT-Organisationen in Umbruchsituationen arbeiten, sind folgende kritische Erfolgsfaktoren besonders hervorzuheben: Zieldefinition: Der erste Erfolgsfaktor ist die klare Definition des Ziels. Auch wenn es ihnen offensichtlich erscheinen mag, was mit einer SOA- oder BPM-Initiative erreicht werden soll, so werden Ihre Kollegen, Kunden oder Lieferanten unter Umständen eine andere Vorstellung davon haben. Managementunterstützung: Gerade bei ambitionierten, längerfristigen Projekten ist die unbeugsame Absicht zur Zielerreichung von allen Verantwortlichen gefordert. Insbesondere ist die Unterstützung des Top-Managements ein wesentliches Moment zur Erzeugung einer konstruktiven Haltung vom Ob zum Wie. Ein Change-Projekt ist gefährdet, wenn die Akteure Ziele, Rahmenzeitpläne oder das grundsätzliche Vorgehen (= Bodenpunkte) im Laufe des Prozesses immer wieder in Frage stellen oder nur halbherzig zur Sache gehen. Strategische Ziele auf Mitarbeiterziele herunterbrechen: Um den Wandel in komplexen und großen Organisationen bewältigen zu können, ist es wichtig, die strategischen Ziele auch für virtuelle Teams bis zum Zielvereinbarungsgespräch des beteiligten Mitarbeiters abzubilden und den Umsetzungsgrad permanent nachzuvollziehen. Die Erfahrung hat gezeigt, dass ein so weitreichender Paradigmenwechsel wie die Umsetzung von SOA oder BPM in einer komplexen Organisation nur aus der Kombination von emotionalen Lernprozessen und strukturierter Umsetzung den gewünschten Erfolg bringt. Es macht natürlich sehr viel Sinn, die Umsetzung der Ziele in Change- Prozessen mithilfe von Tools sichtbar zu machen und so sicherzustellen, dass alle Beteiligten an Anzeige

5 den richtigen Themen konkret und in Synergie arbeiten (als Beispiel sei hier CSYSPERFORM genannt). Externe Sicht: Viele SOA- und BPM- Vorhaben werden von IT-Experten ohne entsprechende Ausbildung als Moderator von Änderungsprozessen vorangetrieben. Zudem sind die Protagonisten Teil des sozialen Systems, sodass eine kompetente externe Sicht in der Regel unabdingbar ist. Ausbildung, Kommunikation, Miteinbeziehung Sobald das Wollen im Team verankert ist, muss man sich dem Kennen und Können widmen. Die wichtigsten Gründe für Misserfolg sind Missverständnisse, Kommunikationsfehler oder schlicht und ergreifend ungenügende Informationen. Mitarbeiterinnen und Mitarbeiter, die nicht verstehen, welche Ziele mit den Konzepten verwirklicht werden sollen, werden nicht in der Lage sein, die im Sinne der Methoden richtigen Entscheidungen zu treffen. Auch das Eigeninteresse der Mitarbeiterinnen und Mitarbeiter kann Probleme bei der Umsetzung der Konzepte mit sich bringen. Nehmen wir z. B. einen erfolgreichen Entwickler, der in den vergangenen 20 Jahren Datenbanken und SQL als Werkzeug für die Integration von Anwendungen eingesetzt hat. Niemand kann ernsthaft erwarten, dass dieser Entwickler eine SOA-Initiative aktiv unterstützen wird, solange er in der neuen Welt, in der seine bisherigen Fähigkeiten eine untergeordnete Rolle spielen werden, nicht ebenso erfolgreich sein kann. Weiterhin besteht die Möglichkeit, dass die Mitarbeiterinnen und Mitarbeiter grundsätzlich eine niedrige Toleranz für Veränderungen mit sich bringen, weil sie daran interessiert sind, eine gewisse Stabilität in ihrer täglichen Arbeit zu erhalten. Was jedoch kann aktiv getan werden, um diesem Problemen adäquat zu begegnen? Die verfügbaren Möglichkeiten, die auch im Rahmen zahlreicher Projekte validiert wurden: Abb. 4: Ein Repository ermöglicht Kommunikation der verschiedenen Stakeholder auf Basis gesicherter und konsistenter Informationen Ausbildung: Die adäquate Ausbildung der Mitarbeiterinnen und Mitarbeiter (z. B. in Architektur, Prozessmodellierung oder Service Design) ist vordergründig dafür erforderlich, dass Projektteams neue Ergebnistypen produzieren können. Im Rahmen des Change-Prozesses hat die Ausbildung aber eine noch wichtigere Aufgabe. Sie ermöglicht es den Teammitgliedern, sich persönlich weiterzuentwickeln und damit eine Position von Stärke und Selbstbewusstsein einzunehmen, die Vorbehalte gegen den Wandel abbauen hilft. Kommunikation: Die beste Art und Weise, Widerstand zur Veränderung zu überwinden: Die Mitarbeiterinnen und Mitarbeiter über die Veränderungsbemühung vorher zu informieren. Dieses verringert unbegründete und falsche Gerüchte hinsichtlich der Effekte der Veränderung in der Organisation. Ebenso ist es wichtig, die Ziele der Initiative offen und aktiv zu kommunizieren sowie den jeweiligen Grad der Zielerreichung. Nur so kann jedes einzelne Teammitglied die eigenen Talente dafür einsetzen, die gesteckten Ziele zu erreichen. Miteinbeziehung: Wenn sie ihre Mitarbeiterinnen und Mitarbeiter in die Veränderungsbemühung einbeziehen, werden sie eher dazu bereit sein, die Veränderung anzunehmen, anstatt sich ihr zu widersetzen. Repository Das zentrale Organisationsund Informationsportal Schauen wir nun einmal näher auf ein wichtiges Detail auf der Ebene Kennen. Das Erfassen, Planen und Verwalten von Geschäftsprozessen in BPM-Projekten ist eine anspruchsvolle Aufgabe und kann schnell unübersichtlich werden. Ebenso ist bekannt, dass der Aufbau und Betrieb einer serviceorientierten Architektur eine Herausforderung sein kann. Die Mitarbeiterinnen und Mitarbeiter müssen stets den Status im Detail kennen und dürfen nicht den Überblick verlieren. Nur wie kann das vor dem Hintergrund der großen Komplexität von SOA- und BPM-Programmen geschehen? Hier wird der Einsatz eines Softwarewerkzeugs unabdingbar. Ein Repository ist das Informationsportal 88 bt

6 einer SOA- und BPM-Initiative [2]. Es ermöglicht den verschiedenen Stakeholdern im Unternehmen, aufgrund einer gemeinsamen Datenbasis miteinander zu kommunizieren. Wichtig ist dabei, dass ein Repository kein Tool sein darf, das ausschließlich die Belange der IT berücksichtigt. Es enthält die für den Erfolg eines Modernisierungsvorhabens so wichtigen Geschäftsprozesse sowie deren fachliche Bausteine. Es muss in der Lage sein, unterstützend zu wirken und eine Brücke zwischen den Menschen der IT und dem Fachbereich schlagen. Nur wenn dies gelingt, ist es möglich, erfolgreich Geschäftprozesse in Services abzubilden. Welche Anforderungen werden an ein Repository gestellt? Das Repository ist das Aushängeschild einer SOA- und BPM-Initiative. Im Repository sind alle bisherigen Arbeitsergebnisse und Verbesserungen dokumentiert. Das Repository macht die Ergebnisse im Unternehmen sichtbar also z. B. die bisher verfügbaren Services oder die Projekte, die bereits Services nutzen. Um das zu erreichen, muss sichergestellt sein, dass alle Ergebnisse in das Repository eingetragen werden und dass das Repository in die tägliche Arbeit möglichst vieler Mitarbeiter eingebunden wird. Dazu muss das Repository drei Anforderungen erfüllen: Es muss von unterschiedlichen Benutzergruppen bedient werden können: Jede Nutzergruppe verfolgt ein anderes Ziel bei der Verwendung des Repositories. Mitarbeiter aus der IT interessieren sich eher für die Beschreibung von technischen Schnittstellen. Mitarbeiter aus dem Business sind an Performance und Kosteninformationen interessiert. Komplexe Daten müssen vom Repository verständlich dargestellt werden können: An der Komplexität einer SOA- und BPM-Initiative lässt sich nichts ändern, da innerhalb solcher Initiativen schlichtweg zu viele Abhängigkeiten und Verknüpfungen existieren. Eine geeignete Darstellung der komplexen Daten kann das Management der Initiative jedoch um ein Vielfaches erleichtern und dazu beitragen durch einen klareren Blick auf die Gegebenheiten die richtigen Entscheidungen zu treffen. Um für die Benutzer eine Vereinfachung zu erzielen, muss das Repository unterschiedliche Sichtweisen und grafische Darstellungen bereithalten. Das Repository muss den Benutzern Spaß machen: Die Datenqualität im Repository ist äußerst wichtig. Gleichzeitig ist die Nutzung des Repositories für Ihre Mitarbeiterinnen und Mitarbeiter zusätzliche Arbeit. Nur wenn die Arbeit Spaß macht und der Nutzer direkten zusätzlichen Nutzen durch den Gebrauch des Repositories erfährt, wird der tägliche Blick in das Kommunkationswerkzeug Repository selbstverständlich, und die Datenqualität steigt automatisch. Zusammenfassung People Change Management ist eine der vordringlichsten Aufgaben in jeder SOA- und BPM-Initiative. Der Artikel zeigt, dass verschiedene Ebenen (Können und Wollen) berücksichtigt werden müssen, um die gewünschten Änderungsprozesse im Team bewältigen zu können. Dazu werden verschiedene Maßnahmen vorgeschlagen: Die Zielsetzung formulieren Das Wollen aktiv managen insbesondere emotionales Lernen fördern Ausbildungsmaßnahmen planen Alle Mitarbeiter gezielt informieren Das Team aktiv in den Veränderungsprozess einbeziehen Das Repository als gemeinsame Wissensbasis aufbauen Dr. Dirk Krafzig ist Gründer von SOAPARK. Als Sprecher auf Konferenzen und Autor von Artikeln und Büchern gilt Dr. Krafzig als ein Protagonist der serviceorientierten Architektur (SOA) und hat maßgeblich zu der Begriffsbildung in diesem Bereich beigetragen. Insbesondere die SOA-Fallstudien mit Deutscher Post, Credit Suisse, Halifax Bank of Scotland und Winterthur Versicherung in seinem Bestseller Enterprise SOA, Prentice Hall, 2004 haben viel Aufmerksamkeit auf sich gezogen. Elmar Barzen ist Associate Partner der CEVEYSYSTEMS GmbH in Tübingen. Neben 16 Jahren Führungserfahrung in der IT-Branche hat er den Markteintritt eines SOA-Anbieters in Central Europa begleitet. Vor dem Zusammenschluss mit CEVEYSYSTEMS 2008 war er geschäftsführender Gesellschafter der munich performance consulting GmbH. Markus Mazur arbeitet als SOAPARK-Berater in Repository-Projekten. Als Mittelsmann zwischen IT und Fachbereich kennt er die unterschiedlichen Bedürfnisse der verschiedenen Anwendergruppen und ist aktiv an der Gestaltung der Repositories beteiligt. Überzeugt davon, dass ein SOA Repository zentrales Planungs-, Überwachungs- und Kommunikationswerkzeug zum Aufbau einer SOA ist, beschäftigt er sich mit der Frage, wie das perfekte SOA Repository aussehen sollte. Sein zweites Thema ist die Servicemodellierung, die Markus Mazur vor seinem Hintergrund als Betriebswirt aus einer sehr fachlichen Sichtweise angeht. Er vertritt dieses Thema auch im Rahmen des SOAPARK- Schulungsprogramms. Links & Literatur [1] Krafzig, Dirk; Banke, Karl; Slama, Dirk: Enterprise SOA, Prentice Hall 2004 [2] Kotter, John P.; Schlesinger, Leonard A.: Harvard Business Review, Vol. 57, No. 2, March April 1979 [3] how-to-implement-an-soa-governance-strategy.htm bt

7 4 Ausgaben pro Jahr! Jetzt Expertenwissen für IT-Architekten, Projektleiter und Berater abonnieren: Die Schwerpunkte des Hefts: Enterprise Architecture Management Cloud Computing, SOA, BPM Agiles Projektmanagement Change Management Enterprise Integration IT Governance Open Source im Unternehmen