Reply ist der ideale Ort, um eine unglaubliche Vielfalt von enthusiastischen, leidenschaftlichen und ideenreichen Menschen zu treffen, die etwas bewegen und verändern wollen.Möchtest du mehr erfahren?
Häufig scheitern Business-und IT Projekte daran, die gesteckten Ziele zu erreichen. Der Grund dafür (oder die Ausrede dafür) liegt oftmals darin, dass die Projekte nicht auf die Strategie der Organisation ausgerichtet oder mit dieser verknüpft sind. Enterprise-Architektur (EA) ist zwar ein Teil des Lösungsansatzes für dieses Problem, kann es aber nicht vollständig zu lösen. In vielen Fällen ist EA trotz beträchtlicher Investitionen nicht imstande, sein volles Potenzial gewinnbringend auszuschöpfen; dies liegt vor allem an den Prämissen sowie an der Umsetzung der EA. Woran liegt das? EA ist oftmals dadurch gekennzeichnet, dass die durch die IT-Projekte bereitgestellten Dienste und die Anforderungen in keinerlei Zusammenhang stehen. Diese Lücke muss geschlossen werden. Ein Capability-gestützter Ansatz kann bei der Planung von Unternehmensarchitekturen diese Lücke schließen: dem Unternehmen wird eine Struktur zur Verfügung gestellt um einen direkten geschäftsrelevanten Nutzen aus den IT-Investitionen zu ziehen und somit IT-Dienst und Geschäftsziele miteinander zu verbinden.
Wie entstehen diese Lücken zwischen Projekt-Delivery und den Geschäftszielen bei der Implementierung der EA? Dafür gibt es eine Reihe von Gründen:
Um sicherzustellen, dass alle Projekte und Programme einen messbaren Mehrwert für das Unternehmen liefern, müssen zuerst die wichtigsten geschäftlichen Einflussfaktoren und Geschäftsziele des Unternehmens geklärt werden. Diese sind zwar oft gut definiert, doch sind sie nicht immer so strukturiert, dass sie sinnvoll in einem Programm-Delivery-Prozess eingebunden werden können. Die Geschäftsziele und Unternehmensstrategien bestimmen die „Capabilities“, die für das Erreichen der Unternehmensmission notwendig sind. Ein weit verbreiteter Fehler liegt darin, mit den bereits vorliegenden Prozessen und der bestehenden Technik zu beginnen, denn dies führt zu einschränkenden Denkmustern und sorgt dafür, dass Projektgrenzen nicht mehr durchlässig sind.
IT-Architekten werden oft darum gebeten, den Ist-Zustand der IT Technik und der Geschäftsprozesse einer Organisation zu beschreiben. Jedoch geschieht dies häufig, ohne dass ihnen die Pläne und Designs im Original zur Verfügung stehen. Im Ergebnis erhält man so eine Reihe von Skizzen und Modellen, die eher Impressionen des derzeitigen Zustandes sind als eine akkurate Beschreibung der Ziele, die die IT und ihre Prozesse erreichen sollten, so dass die Ausgangssituation der Planung den tatsächlichen Ist-Zustand nicht reflektiert.
Viele Architekturen werden zu Konfektionsware, denn die IT Architekturen werden zwar entwickelt, doch die Arbeit, die tatsächlich notwendig ist, um diesen Prozess zu unterstützen, wird nicht gemacht. Dies führt dazu, dass die IT Architektur den Usern nicht das zur Verfügung stellt, was diese von ihr erwarten. Man kann das mit dem Kauf eines 10-Kanal-Surround-Sound-Systems vergleichen, das dann nicht an das Fernsehgerät angeschlossen wird. Nur wenn die Lösung in die Umgebung integriert wird, kann eine Architektur gewinnbringend genutzt werden.
Üblicherweise wird die Architektur vom IT-Team für die Geschäftsprozesse entwickelt. Trotz aller Bemühungen der Projektteams wird das Ergebnis häufig mit zu vielen technischen Fachausdrücken präsentiert, so dass die Aufmerksamkeit der Benutzer auf die Details des Systems und der Applikation gelenkt wird und dabei der Fokus auf die Ergebnisse, die das Unternehmen erzielen will, verloren geht. Dies führt dazu, dass das Team – die eigentliche Zielgruppe, für die die Architektur entwickelt wurde – den Kontakt zum Business verliert.
Für fortschrittliche Unternehmen stellt Capability Architecture einen Weg da, um dafür zu sorgen, dass sowohl das Business-Programm als auch die ITEA-Projektportfolios einen gemeinsamen Startpunkt haben. Capability Architecture ist auf dem Vormarsch, trotzdem müssen wir Sie warnen: Der Capability-gestützte Planungsansatz kann nur dann erfolgreich eingesetzt werden, wenn die IT-Abteilung einer Organisation eng und zielgerichtet mit dem Management anderer Bereiche des Unternehmens zusammenarbeitet. Um den Erfolg zu gewährleisten, muss der Business-Bereich viele der Elemente der Capability Architecture „besitzen“ und nicht die IT-Funktion.
Capability Architecture stellt einen Rahmen zur Verfügung, mit der die Welt mit Begriffen beschrieben werden kann, die auch das „Business“ versteht. Durch die Verwendung einer gemeinsamen Sprache soll ein Unternehmen oder eine Organisation über funktionale Grenzen hinweg vereint werden; dies geschieht durch einfache Aussagen, mit denen Aktivitäten, Ansätze und Resultate miteinander verbunden werden. Eine Capability ist eine Beschreibung dessen, welches Ziel der Geschäftsbetrieb erreichen will. Dieses Ziel wird dabei oft von den globalen Unternehmenszielen abgeleitet, die üblicherweise eine übergeordnete strategische Vision beschreiben, die die Richtung der Unternehmensentwicklung vorgibt. So könnte zum Beispiel eine Business Capability darin bestehen, die Verfügbarkeit der Betriebs- und Geschäftsausstattung zu verbessern und für mehr Sichtbarkeit der einzelnen Posten und Anlagen zu sorgen. Dabei basiert jedes Geschäftsziel auf einer Reihe von Capabilities. Nur wenn diese vorhanden sind, kann das Geschäftsziel umgesetzt werden. Denn wenn mit einem Geschäftsziel das „Warum“ beschrieben wird, d.h. das, was der Geschäftsbetrieb umzusetzen versucht, so beschreibt die Capability das „Wie“ und „Was“ mit diesem Ziel erreicht werden kann. Um wie im oben genannten Beispiel die Verfügbarkeit der Betriebs- und Geschäftsausstattung zu verbessern (Geschäftsziel) muss die Capability darin bestehen, die logistischen Abläufe für die Betriebs- und Geschäftsausstattung sowohl in der Vor- als auch in der Rückschau betrachten zu können (Capability). Somit sind das Mission Statement und die Geschäftsziele der Schlüssel-Input für die Capability Architecture.
Im Unterschied zu einem Technologie-gestützten Ansatz, bei dem eine Bottom-up-Betrachtung der „Kunst des Machbaren“ dominiert, sorgen die Capability-gestützten Planungskonzepte dafür, dass bei einer Capability Architecture in einem Top-down-Prozess definiert wird, wie und warum der Geschäftsbetrieb auf die Kundenbedürfnisse und das Geschäftsumfeld reagieren muss. Dabei sollten Geschäftsziele und Capabilities spezifisch und maßnahmenorientiert sein und die Capability sollte in strukturierter Weise definiert sein. Die Umsetzung einer vorhandenen Capability stellt sich jedoch nicht ganz so unkompliziert dar. Und genau an diesem Punkt geht die Schere zwischen IT und Business auseinander: Während die IT das „WAS“ in dem oben dargestellten Diagramm versteht, bleiben das „WARUM“ und das „WIE“ der Interpretation überlassen. In diesem Zusammenhang geht es nicht um einfache Anforderungen (die oftmals systemorientiert sind), sondern um die Gestaltung der Business Capability, die auf eine bestimmte Weise ausgeführt werden muss, um ein bestimmtes qualitatives oder quantitatives Ergebnis zu erzielen. Und um die Situation noch komplexer zu gestalten, kann es passieren, dass Capabilities über verschiedene Teile des Unternehmens verteilt sind, was zu Interessenkonflikten und Kontroversen zwischen den unterschiedlichen Abteilungen und Unternehmensbereichen führen kann. So bot zum Beispiel ein bekannter Einzelhändler für Mobiltelefone und Anbieter von Wireless-Diensten im Rahmen einer verkaufsfördernden Maßnahme seinen Kunden einen kostenlosen Laptop an, wenn diese einen Vertrag für das Breitbandpaket des Unternehmens unterzeichneten. Das Problem lag dabei jedoch darin, dass die Verkaufsstellen nicht über genügend Platz verfügten, um die Computer anzunehmen, zu lagern und auszustellen. Die Capability, die notwendig gewesen wäre, um das Ziel zu erreichen, den Marktanteil am Breitbandmarkt auszuweiten, wurde nicht definiert. Zudem wurden keine Pläne erstellt, um die Unzulänglichkeiten der bestehenden Capabilities zu beseitigen. Daher müssen wir bei der Definition von Capability und der Design-Attribute Strukturen und Regeln anwenden.
Capabilities müssen eindeutig beschrieben werden und dürfen keine Restriktionen beinhalten. Das heißt, dass Capability-Statements kein „und“ oder andere Konjunktionen enthalten dürfen. So bezieht sich die Fähigkeit, Bestellungen anzunehmen und Lieferungen auszuführen auf zwei völlig unterschiedliche Operationen, die nicht in einem einzigen Statement zusammengefasst werden sollten. Darüber hinaus sieht diese Planungsstufe kein Statement für Business- oder IT-Lösungen vor. Um für den Design-Prozess ausreichend Informationen zur Verfügung zu stellen, muss ein Capability Statement definiert und validiert werden. Das Statement sollte sich auf die Geschäftsziele beziehen.
Dass ein Change-Programm nur von einem Unternehmensbereich ausgeht, ist eher die Ausnahme. Um ein solches Programm mit Erfolg abschließen zu können, betreffen die Veränderungen oft mehrere Bereiche des Unternehmens. Dabei kann es sein, dass die Enterprise-Architektur zu komplex ist. Mit Capability Architecture sind wir in der Lage exakter zu definieren und einem pragmatischeren Ansatz zu folgen, wie in dem einfachen vierstufigen Prozess, der nachstehend dargestellt wird, zu sehen ist:
Eine Capability-gestützte Architektur hat zahlreiche Vorteile:
In der Praxis hat sich gezeigt, dass Capability Architecture und Capability-gestützte Planung erfolgreich eingesetzt werden können. Reply hat viele seiner Kunden aus den unterschiedlichsten Branchen dabei unterstützt, diesen Ansatz umzusetzen und einen fassbaren Mehrwert für die Unternehmen zu generieren. Für einen anerkannten Hersteller und Service-Provider aus der Luftfahrtindustrie haben wir einen robusten Mechanismus entwickelt und bereitgestellt, mit dem eine auf die Unternehmensstrategie ausgerichtete Capability-Planung für die Verbesserung der Geschäftsabläufe vorgenommen werden kann. Von entscheidender Bedeutung war dabei, dass unsere Lösung sicherstellte, dass die Planung der Verbesserung der Geschäftsergebnisse und nicht den Bereitstellungen von IT-Leistungen diente. Dadurch wurde die strategische „Sichtverbindung“ geschaffen, die notwendig war, um Investitionen angemessen zu priorisieren und die Konzentration der Organisationsstruktur zur verbessern. Mit unserem Capability Architecture-Ansatz haben wir einem der großen globalen Telekommunikationskonzerne geholfen, das System seiner bestehenden Dienste zu aktualisieren und mit einer neuen Retail-Capability zu kombinieren. Dieser Top-down-Ansatz sorgte dafür, dass eine angemessene und konsistente Granularität der Dienste geschaffen wurde; zudem konnten mit dieser Methode alle notwendigen Business-Dienste identifiziert werden, wodurch das Potenzial für die Wiederverwendung maximiert wurde. Bei zwei führenden Lebensmittelhändlern wurde unser Capability Architecture-Ansatz dazu verwendet, gemeinsame Capability-Anforderungen zu identifizieren, die auf der Unternehmensstrategie basieren. Dieser Prozess wurde über mehrere Geschäftseinheiten und Kundenkanäle hinweg angewendet. Dabei haben wir das Framework der CA, die Target Architecture sowie die langfristige Business- und IT-Roadmap entwickelt, mit der die erforderlichen Business Capabilities über einen kombinierten Veränderungsprozess im Business- und IT-Bereich bereitgestellt werden sollten.
Viele Organisationen betreiben EA, aber nur wenigen gelingt es, dies gut zu tun. Die Schere zwischen Business- und IT-Strategien scheint eine weit verbreitete Ursache dafür zu sein, dass das Programm-Portfolio und die IT-Delivery nicht in der Lage sind, den richtigen Mehrwert für das Unternehmen zu schaffen. Indem ein Capability-gestützter Planungsansatz genutzt wird, der tatsächlich unabhängig von der Technik operiert, werden IT-Dienste und Business-Anforderungen wieder miteinander verknüpft. Wir sind davon überzeugt, dass ein Capability-gestützter Ansatz dazu fähig ist, einen tatsächlichen wirtschaftlichen Mehrwert für das Unternehmen zu schaffen, wenn ein exakter und strukturierter Rahmen geschaffen wurde. Durch die Schaffung eines gemeinsamen Lexikons und die Verringerung der Komplexität des Programm-Portfolios sorgen Capability Architecture & Capability Planning dafür, dass man sich auf das konzentrieren kann, was für die Erreichung der Geschäftsziele und damit für den Geschäftserfolg tatsächlich notwendig ist.