20100708g Detecon Logical Business Architecture verbindet BPM und SOA

»manage it« als

E-Paper 5-6 2011
E-Paper 3-4 2011
E-Paper 1-2 2011
E-Paper 11-12 2010
E-Paper 9-10 2010
E-Paper 7-8 2010
E-Paper 5-6 2010

Logical Business Architecture verbindet BPM und SOA

Brückenschlag zwischen zwei Welten

Flexibilisierung des eigenen Geschäfts in volatilen Märkten und Kostenreduktion, auch in der IT: Die derzeitigen Unternehmensstrategien ähneln sich. Dennoch schaffen es einige Akteure, sich durch besondere Services und Produkte abzuheben. Andere sind schlicht schneller mit neuen Angeboten beim Kunden als ihre Mitbewerber. Dies gelingt nur, wenn Business und IT am gleichen Strang ziehen. Sowohl auf Seiten der Geschäfts- als auch der IT-Prozesse gibt es seit Jahren umfassende Initiativen und Strategien, diesen Brückenschlag zu bewerkstelligen. Es ist an der Zeit, ihn mittels Business-Architekturen zu vollenden.

er Einsatz von Business Process Management (BPM) für Geschäftsabläufe und von serviceorientierten Architekturen (SOA) für die IT zeigt zwar schon Erfolge im Hinblick auf optimierte, agile und standardisierte Prozesse und deren IT-Unterstützung. Immer noch fehlt jedoch eine nachhaltige Integration dieser beiden Bereiche.

Eine Detecon-Studie von 2009 zeigt, dass nur 14 Prozent der befragten Unternehmen von sich selbst behaupten, die Lücke zwischen Geschäftsstrategie und IT-Aktivitäten nicht nur geschlossen, sondern gut verzahnt zu haben [1]. Daher ist es nicht verwunderlich, dass die Hälfte der Umfrageteilnehmer in ihren Unternehmen ein hohes bis sehr hohes Verbesserungspotenzial bei der Ausrichtung der IT-Strategie auf die Unternehmensstrategie sieht. Sie verorten erhebliches Optimierungspotenzial bei einer verbesserten Ausrichtung der IT- auf die Unternehmensstrategie: Nur 11 Prozent bezeichnen dieses Potenzial als »gering«, 36 Prozent als »mittel«, 39 Prozent als »hoch« und 11 Prozent sogar als »sehr hoch«.

Dass Business und IT also noch nicht gleich getaktet sind, ist bei weitem nicht alleine Versäumnissen der IT zuzuschreiben. So investieren viele Unternehmen enorm viel Geld, um mit BPM-Maßnahmen sowohl strategisches Alignment als auch Prozessqualität in den Geschäftsabteilungen deutlich zu steigern. Zur gleichen Zeit führen sie serviceorientierte Architekturen ein, also Konzepte für flexible IT-Architekturen, die historisch gewachsene Barrieren in der IT-Landschaft überwinden und die erforderliche Zeit zur Adaption neuer Geschäftsanforderungen verringern sollen. Das Problem: Der Austausch von Informationen und Ergebnissen zwischen den Fach- und IT-Abteilungen scheitert oft daran, dass aufgrund einer fehlenden gemeinsamen Sprache das Verständnis darüber fehlt, welche Ergebnisse, Informationen und Datenobjekte denn nun tatsächlich en detail gegenseitig abzustimmen sind.

SOA = IT.

Serviceorientierte Architekturen (SOA) galten ursprünglich als Universalrezept für die flexible Gestaltung von Geschäftsprozessen. Doch das SOA-Konzept litt von Anfang an darunter, dass es herstellergetrieben und zu stark technisch orientiert war. Gleichwohl lag das Scheitern vieler SOA-Projekte auch in organisatorischen Unzulänglichkeiten begründet. Oft versäumten Initiatoren und Verantwortliche, den Geschäftsnutzen einer SOA zu transportieren, und unterschätzten die Auswirkungen auf die Unternehmensorganisation. Fehlende Unterstützung durch das Top-Management war ein weiteres ausschlaggebendes Element.

SOA kann jedoch nur dann funktionieren, wenn die Geschäfts- und Fachbereiche aktiv als »Treiber« mitwirken und der Fokus auf Geschäftsprozessen, Change Management und Markterfordernissen beziehungsweise den Kundenanforderungen liegt. SOA erfordert nicht nur eine gemeinsame »Sprache« zwischen IT- und Fachbereichen, sondern auch eine Synchronisierung zwischen Unternehmenszielen und IT-Struktur bei den Kerngeschäftsfähigkeiten (Capabilities) sowie den zugehörigen Geschäftsprozessen. Somit ist SOA ein Managementthema, und keinesfalls eine reine Technikdomäne.

Um die Lücke zwischen BPM und SOA zu schließen, bedarf es zunächst eines gemeinsamen Vorgehens von Geschäfts- und IT-Management. Ein umfassender Lösungsansatz verlangt, dass Experten beider Seiten zusammen ein sogenanntes Bridging Framework definieren. Dieses enthält eine einfache gemeinsame Taxonomie sowie Artefakte, die die konkrete Übergabe von Informationen und Datenobjekten in klar definierter Sprache beschreiben.

Nichts anderes beschreibt der Ansatz einer Logical Business Architecture. Um ein solches, unternehmensspezifisches Framework aufzubauen, sollten CIO oder COO ein Initialprojekt unter Leitung der zentralen Unternehmensarchitekten starten. Wichtig ist, dass die methodische Vorarbeit in einem solchen Einführungsprojekt auf ein Minimum reduziert wird, das heißt maximal innerhalb von zwei Monaten oder sogar parallel zu einem Pilotprojekt durchgeführt wird. Nach dieser ersten Phase können die so entstandenen Komponenten des Frameworks nutzenbringend in Projekten zwischen Fach- und IT-Bereichen (aber auch zwischen verschiedenen Fach- oder IT-Bereichen) eingesetzt werden und mit den dabei erworbenen Erkenntnissen in weiteren Feedbackschleifen optimiert werden (Abbildung 1).

Abbildung 1: Implementierung einer Logical Business Architecture für das Alignment von Business und IT

Die DNA des Geschäftserfolgs: Business Capabilities.

Die Logical Business Architecture schlägt die Brücke zwischen den Welten der Prozesse und denen der IT. Idealerweise wird das gesamte Geschäftsmodell des Unternehmens in transparente und leicht handhabbare Einheiten heruntergebrochen, die einer klaren Geschäftslogik folgen. Doch wie lassen sich solche Einheiten inhaltlich strukturieren? Abbildung 2 zeigt anhand eines Auszugs, wie sich Einheiten in High-Level-Domains wie CRM und detailliertere Business Capabilities unterteilen lassen.

Die Capabilities stellen immer Einheiten aus Informationen, Prozessschritten und Ressourcen (Personen und IT-Systeme) dar. Sie bilden keine prozessualen Abläufe ab, sondern repräsentieren die wettbewerbsrelevanten Kernfähigkeiten und ihre Beziehungen untereinander, die sich in einer »Capability Map« abbilden lassen. Häufig sind die Kerngeschäftsfähigkeiten auf verschiedene Organisationsbereiche im Unternehmen verteilt. So entstehen etwa im Zuge von Fusionen und Übernahmen sehr oft Redundanzen. Dann gilt es für COO oder CIO, ein Domänenmodell als Ordnungsrahmen von Kerngeschäftsfähigkeiten seines Unternehmens zu entwickeln und ihnen überschneidungsfrei die entsprechenden Capabilities von Fachseite und IT zuzuordnen.

Da die Identifikation der Capabilities top-down und unabhängig von konkreten und aktuellen Details des Prozesskontextes erfolgt, sollte sich das Ergebnis im Zeitablauf durch hohe Stabilität auszeichnen. Die eigentliche Identifikation der Business Capabilities lässt sich pragmatisch sowohl anhand von Daten, funktionalen und Geschäftsstrategie-Aspekten durchführen. Dies befreit die Betrachtungsweise sowohl vom Ballast der aktuellen Prozessstruktur der Organisation als auch von Restriktionen, die die derzeit im Einsatz befindlichen IT-Applikationen auferlegen. Zusätzlich zur Zuordnung der Business Capabilities zu übergeordneten Domänen werden jeder Capability weiterhin auch mehrere Business Objects (etwa das Geschäftsobjekt ‚Vertrag’) zugeordnet. Schließlich gehören auch Leistungsindikatoren (KPI) als zusätzliche Charakteristik zu jeder spezifischen Business Capability, um Fortschritte in der Entwicklung der Geschäftsfähigkeit messen zu können.

Beispielhafter Auszug einer Logical Business Architecture mit Domänen, Business Capabilities, Business Objects und KPIs.

Entwicklung und Pflege von Geschäftsfähigkeiten.

Damit eine Logical Business Architecture tatsächlich sowohl Agilität steigert als auch Kosten reduziert, müssen neben inhaltlichen Kriterien zur Abgrenzung von Business Capabilities auch Designprinzipien zu deren Pflege existieren. Das Design einer Capability sollte so konzipiert sein, dass sie einerseits autonom existieren kann, ohne andererseits isoliert und ohne Interaktion mit anderen Funktionalitäten zu sein. Es sollte also eine unabhängige Entwicklung von Business Capabilities ermöglichen, aber gleichzeitig ein nahtloses Zusammenspiel in Geschäftsprozessen gewährleisten. Nur dies ermöglicht einen hohen Grad an Standardisierung bei gleichzeitig künftiger Agilität. Folglich lassen sich die Designprinzipien dann auch als Toolbox zur Entwicklung von IT Services nutzen, die dann in flexibler Komposition zur automatisierten Ausführung von Prozessen dienen. Hat das Einführungsprojekt auf diese Weise einen hohen Grad an umfassender Standardisierung von Komponenten erreicht, sind bald mögliche Ersparnisse in den Aufbaukosten für zusätzliche und geänderte Prozesse sowie in den Integrationskosten für neue IT-Komponenten sichtbar und lassen sich realisieren.

Welches sind die wichtigsten Designprinzipien für Business Capabilities, so dass mehr Flexibilität, aber auch Kosteneffizienz durch Standardisierung erreicht werden kann? Zunächst ermöglichen Prinzipien der Wiederverwendbarkeit und Abstraktion den Einsatz einer Capability in verschiedenen Geschäftsprozessen frei von organisatorischen Einschränkungen. Weitere wichtige Designprinzipien für Business Capabilities beinhalten eine Unabhängigkeit von spezifischen Status sowie Modularität und Granularität. Nur auf diese Weise lassen sich Business Capabilities auf der strikten Basis der struktureller Logik aus den geschäftlichen Anforderungen entwickeln, so dass sie vom konkreten Kontext von heutigen Prozessen und Organisation befreit sind, keinen Ballast aktuell implementierter IT-Applikationen mit sich tragen müssen und ein Mapping zwischen Geschäftsprozessen, Capabilities, IT-Services und Applikationen möglich wird. Eben dieses Mapping ermöglicht dann eine integrierte Sicht von Prozessen und IT-Architektur sowie auch eine standardisierte Sprache zwischen Business und IT. Nur diese trägt auch zu einfacheren Vereinbarungen in der Kommunikation zwischen Partnern und Lieferanten bei. Die entstehende Transparenz lässt sich dann nutzen, um Kosteneffekte zu realisieren, indem auch im Geschäftsprozessbereich Standardisierungsaktivitäten vorangetrieben werden. Weiterhin lassen sich Investitionen in die IT gezielter steuern, wenn deutlich ist, wie kritisch die IT-unterstützten Prozesse für das Geschäft sind.

Fortschritte des Brückenbaus messen.

Der Erfolg einer solchen Logical Business Architecture steht und fällt mit der konkreten Messbarkeit des Business-IT-Alignments und seines Reifegrades – zumal bisher nur eine Minderheit der Unternehmen entsprechende Steuerungsmechanismen implementiert hat. Hier besteht der dringendste Handlungsbedarf. Es ist davon auszugehen, dass mit solchen Metriken und den darauf basierenden belastbaren Aussagen die Verzahnung von Business und IT gestärkt wird: sei es durch eine stärkere Beteiligung der IT-Verantwortlichen bei der Definition der Geschäftsstrategie oder durch einen kontinuierlicheren und systematischeren Austausch der beiden Seiten. Diese Interaktion bedeutet nicht, dass Fachseite und IT auch organisatorisch weiter miteinander verschmelzen. Die erwähnte Detecon-Studie zeigt deutlich, dass dies nicht der Realität in den meisten Unternehmen entspricht.

Vor allem unterstützen messbare Ergebnisse dabei, jene Hürden zu nehmen, die dem Erfolg von Business-IT-Alignment vor allem im Weg stehen: fehlende Priorität beim Top-Management, politische Widerstände und fehlende Ressourcen zur Operationalisierung. In allen drei Fällen sind aussagekräftige Zahlen ein geeignetes Mittel, um bestehende Widerstände des kennzahlenorientierten Managements zu überwinden.

Logical Business Architecture – ein Beispiel.

Ein multinationaler Telekommunikationskonzern hat bereits zur Entwicklung einer Zielstruktur für seine CRM-Landschaft den Ansatz der Logical Business Architecture genutzt. Sie ermöglichte ihm über alle Geschäfts- und IT-Einheiten der Festnetz- und Mobilfunkdivisionen ein gemeinsames Verständnis und gemeinsame Ziele und Visionen zu entwickeln. Während eines fünfmonatigen Konsolidierungsprojekts wurde die übergreifende CRM-Zielarchitektur auf Basis architektonischer Guiding-Principles erstellt und eine Roadmap von Implementierungsinitiativen gestartet. Das strikt auf Business Capabilities basierende Anforderungsmanagement ermöglichte eine enge Kontrolle über hochkomplexe, existierende IT-Landschaften mit über 400 Applikationen und reflektierte die unterschiedlichen Anforderungen der beteiligten Geschäftsabteilungen aus Marketing, Sales- und Kundenservice. Mit der Logical Business Architecture konnten Synergien, Abhängigkeiten und notwendigen Adaptionen schnell identifiziert, spezifiziert und in Maßnahmen überführt werden, die schließlich eine Reduktion der Verwaltungs- und Betriebskosten um 18 Prozent bewerkstelligte.

Schon nach Abschluss dieses Projekts ließ sich das Portfolio Management der Business Capabilities als strategischer Planungsprozess für die CRM-Landschaft integriert zwischen Business und IT ausführen. Dies brachte ein sowohl Prozess- als auch IT-Aspekte übergreifendes Einführungsmanagement für neue Prozesse mit sich. Das Unternehmen kann nun auf plötzlich auftretende Marktänderungen während der Einführung der Zielarchitektur reagieren, was auch insgesamt die Reaktionsfähigkeit und Agilität der Organisation deutlich erhöht hat.

Top-down ist Pflicht.

Das Management dieses Projekts verfolgte stets einen Top-down-Ansatz beim Design und der Spezifikation der Logical Business Architecture. Denn dies ist der einzige Weg, um zu gewährleisten, dass die identifizierten Business Capabilities die von der Unternehmensstrategie abgeleiteten Anforderungen erfüllen.

Ein weiterer Erfolgsfaktor bei der Implementierung einer Logical Business Architecture besteht darin, dass aktuelle organisatorische Rahmenbedingungen und IT-Restriktionen während des Customizing-Prozesses keine Rolle spielen dürfen. Dreh- und Angelpunkt sind vielmehr die Business Capabilities, die innerhalb der Logical Business Architecture jene Geschäftsfunktionalitäten beschreiben, die für die Einführung eines Geschäftsmodells erforderlich sind.

Eine Logical Business Architecture unterstützt nicht nur die Kommunikation und Koordination zwischen der Geschäfts- und IT-Seite, sondern erfüllt dieselbe Funktion auch zwischen mehreren Geschäftseinheiten. Demnach müssen Repräsentanten aller Einheiten bei der Entwicklung des Frameworks teilhaben. Dies ist wichtiger, als zu viel Zeit darauf zu verwenden, das Konzept in allen Details auszuarbeiten. Schon nach einer relativ kurzen Phase zur Definition der Architekturelemente und Top-Level-Business-Objekte, sollten diese schnell einem Test in der Praxis, etwa in Projekten, unterzogen werden.

Erfolgsfördernd ist darüber hinaus eine Prozedur für Änderungsanfragen (Change Requests), die diese in den Capabilities koordiniert einführen kann. Dieser Prozess sollte zudem Teil einer übergreifenden Governance sein, die Repräsentanten von Geschäfts- und IT-Einheiten für die Verwaltung und Evolution der Logical Business Architecture einbezieht. Organisatorisch gesehen könnte ein Architektur-Board diese Governance verantworten, indem es mit einem Mandat für wesentliche Entscheidungen ausgestattet ist.

Last, but not least, erhöht starker Support durch das Senior Management beim Kommunikationskonzept die Akzeptanz einer Logical Business Architecture. Nur so kann diese tatsächlich dann auf breiter Basis auch jenseits tagesaktueller organisatorischer Anforderungen angewandt werden.

Dr. Verena Schmidtmann, Frank Lorbacher

____________________________________

Dr. Verena Schmidtmann (verena.schmidtmann@detecon.com) und Frank Lorbacher (frank.lorbacher@detecon.com), beide Senior Consultant bei der ICT-Management-Beratung Detecon International (www.detecon.com).

[1] (www.detecon.com/business_it)

Folgen Sie »manage it«

auf Google+

Copyright © 2003-2012 ap Verlag GmbH