In diesem Artikel geht es um die Betrachtung der Vor- und Nachteile einer Matrix- und Produktorganisation und deren Einfluß auf die Unternehmensarchitekturen.

Beides sind Linienorganisationen. Die „Linien“ drücken dabei die Führungshierarchie zwischen den Organisationseinheiten aus.

Im folgenden wird die Matrix- und die Produktorganisation vorgestellt:

Schauen wir nun auf verschiedene Dimensionen in Bezug auf die Vor- und Nachteile der jeweiligen Organisationsformen:

Es ist gut zu erkennen, daß durch die Vermeidung von Konflikten und einem klaren Produktbezug der Ziele, die Führbarkeit und Flexibilität in einer Produktorganisation verbessert werden. Die Qualität der Entscheidung in einer Matrixorganisation wird durch die höhere Anzahl von Stakeholdern und Meinungen verbessert, es kann allerdings länger dauern bis ein Entschluss gefasst wird. Das Heben von Synergien durch Wiederverwendung von Funktionen und Kompetenzen ist in Matrixorganisationen begünstigt.

In der Realität sind die reinen bzw. idealtypischen Organisationsformen in einer größeren Unternehmung allerdings nicht anzutreffen. Meistens gibt es Mischformen. So nutzen Produktorganisationen auch Zentralfunktionen, wie Personalwesen oder Einkauf. Dies wird begünstigt durch eine hohe Allgemeingültigkeit dieser Sachgebiete.

Was sagt TOGAF®?

TOGAF ist das populärste Rahmenwerk für Enterprise Architektur und beinhaltet die Best Practices für den Umgang mit Unternehmensarchitekturen (Business und IT).

TOGAF gibt keine direkte Empfehlung, eine bestimmte Form der Linienorganisation aufzubauen. TOGAF macht aber Vorschläge, wie die Unternehmensarchitektur partitioniert werden kann, um gemeinsam mit verschiedenen Teams daran zu arbeiten ohne sich dauernd in die Quere zu kommen.

Die organisationsweiten Architekturen werden nach Kriterien wie Sachgebiet (Breite), Abstraktionsebene (Tiefe) und Zeit aufgeteilt. So kann es Organisationseinheiten geben, welche eine strategische  Architektur erstellen und diese dann als Vorlage an die Segmente der Organisation weitergeben. Es kann Organisationseinheiten für Produkte, Fachabteilungen, Dienstleistungen und Standorten geben. Auch sind zu verschiedenen Zeiten im Lebenszyklus einer Architektur verschiedene Organisationseinheiten involviert.

Interessant ist hier auch „Conway’s Law“:

„Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“

Die Organisationsform und Führungsstruktur, welche bei der Planung, Implementierung und dem Betrieb von Architektur eingebunden sind, beeinflussen also das Lösungs-Design mit.

Fazit

Die Vorteile einer Produktorganisation liegen auf der Hand: Gute Zielorientierung, schnelle Entscheidungsfindung, klare Kompetenzen. Dennoch läßt man Potential ungenutzt. Die Wiederverwendung ist eine wichtige Kenngröße und hohes Ziel in der Enterprise Architecture. Ein guter Baustein ist eben wiederverwendbar, sei es ein Architektur- oder Organisationsbaustein. Laut Conway gibt es hier sowieso eine große Selbstähnlichkeit.

Synergien, also die gegenseitige Förderung durch Zusammenarbeit, werden in Produktorganisationen zugunsten einer besseren Führbarkeit und zur Konfliktvermeidung nicht immer gehoben. Dadurch können kaum Unternehmensarchitekturen entstehen, welche ein hohes Maß an Wiederverwendung von Services, Komponenten und Know-How aufzeigen. Ich habe es schon erlebt, daß eine mögliche Wiederverwendung als Projektrisiko gewertet wurde, da die Komponente ausserhalb der eigenen Einfluß-Sphere lag. Mit dieser Denkweise läuft man Gefahr, das Rad mehrfach zu erfinden (nicht unbedingt besser) und es lassen sich nur schwer Cross-Selling-Produkte realisieren.

In einer Produktorganisation sind viele Dinge einfacher als in der Matrixorganisation dafür ergibt sich die Hebung von Synergien nicht so leicht.

Die Wiederverwendung von Services, Komponenten und Kompetenzen in der gesamten Unternehmung sowie die Konsistenz von Sub-Architekturen untereinander sind wichtige Ziele der Enterprise Architektur, egal ob Matrix- oder Produktorganisation!

Quellen:

Buch „Organisation der Unternehmung“ von Wilfried Krüger

Wikipedia Matrixorganisation, Divisionale Organisation

TOGAF® Architecture Partitioning

Informationsbedarf der Enterprise Architektur – Teil 2

In diesem Teil geht es konkret um die benötigten und anfallenden Informationen bei der Ausübung der Praktiken der Enterprise Architektur.

Teil 1 gab Überblick und Motivation für das Thema und kann hier gelesen werden.

Der ganze Beitrag ist in dem Buch „Erfolgsfaktor Informations Management“ (ISBN 978-3-00-053730-1) enthalten und kann hier bestellt werden.

Informationsbedarf der Enterprise Architektur

Einleitend möchte ich darauf hinweisen, dass es sich bei den folgenden Betrachtungen um die vollständige, maximale Informationsmenge handelt, wie sie von TOGAF beschrieben ist. Diese Vollständigkeit ist oft unnötig und nicht trivial in ihrer Verwaltung. Welche Informationsbereiche, zu welchem Zeitpunkt, in welcher Form abgebildet und verwaltet werden, hängt von den spezifischen Anforderungen in der Organization ab und kann nicht allgemein beantwortet werden.

Prinzipien, Leitlinien, Referenzarchitekturen und -modelle

Schon die erwähnten Leitsätze, die sogenannte Unternehmensprinzipien, und die Unternehmensstrategie selbst sind Bestandteil der Information die verwaltet und kommuniziert werden müssen. Daraus abgeleitet werden die Architekturprinzipen, welche wiederum maßgebend sind für Referenzarchitekturen und Architekturleitlinien, sogenannte Guidelines.

Des weiteren muss sich die Architektur an bestimmte Unternehmens- oder Industrie-Standards halten und teilweise komplexe regulatorische Auflagen erfüllen.

Architekturbeschreibungen

Bei der Planung der Architektur werden verschiedene Architekturbeschreibungen erstellt, überarbeitet und abgenommen. Im Idealfall enthält die Architekturbeschreibung weniger „Prosa“ als Artefakten, wie Diagramme, Aufzählungen und Tabellen. Diagramme sind eine wertvolle, wenn nicht die wertvollste, Repräsentation der Architektur. Sie sind leichter zu verstehen und vereinfachen die Kommunikation wesentlich. Zusätzlich läßt sich die strukturierte, mit einem Datenmodell unterlegte, Architekturbeschreibung leichter elektronisch verarbeiten als unstrukturierte textuelle Erklärungen.

Für verschiedene Gruppen von Beteiligten bei der Planung, der Umsetzung und dem Betrieb der Architektur gibt es eigene Artefakte mit spezifischem Inhalt. Dieser spezifische Inhalt wird als Blickpunkt (Viewpoint) auf die Architektur bezeichnet. General hat ein Viewpoint einen Zweck, eine damit verbunden Nutzergruppe (Stakeholders) sowie eine Abstraktionsebene die mehr oder weniger  viele Details der Architektur beinhalten. Die Verwendung von Viewpoints erlaubt den Blick auf die für die Nutzergruppe wesentlichen Informationen. Zur Steigerung der Effizienz werden nicht benötigte Informationen und Detailierungsebenen ausgeblendet.

Die Open Group bietet mit ihrer offenen EA Modellierungssprache „ArchiMate“ einen Lösungsvorschlag zur Standardisierung der Viewpoints, inklusive ihres Zweckes, Detailierungsgrades, der damit verbundenen Nutzergruppe sowie dem Inhalt.

Dabei wird der Zweck grob in drei Kategorien eingeteilt:

1. Entwerfen (Designing)
   Unterstützt primär Architekten bei der Planung der Architektur, sowie Experten und Entwickler bei der Umsetzung.
2. Entscheiden (Deciding)
   Unterstützt Projekt- und Linien-Management beim Entscheidungsprozess durch Aufzeigen von abteilungsübergreifenden Beziehungen und spezifischen Auswirkungen. Oft werden dabei alternative Entwürfe verglichen um die jeweiligen Vor- und Nachteile sowie Risiken zu erörtern.
3. Informieren (Informing)
   Unterstützt jegliche Nutzergruppe beim Verständnis der System-Architektur und erhöht die Unterstützung aller Beteiligten sowie deren Verbundenheitsgefühl zur Architektur.

Der Detailierungsgrad wird in drei Ebenen unterteilt:

1. Details
   Unterstützt das tiefgreifende Verständnis von Geschäftsprozesse, Informationsflüssen sowie deren Einfluss auf die Anwendungs-, Daten- und Technologie-Architektur.
2. Zusammenhang (Coherence)
   Zeigt deutlich die Beziehungen der Geschäftsprozesse zu Akteuren, Ereignissen, Informationen, Anwendungen, Kommunikationswegen und der Infrastruktur.
3. Übersicht (Overview)
   Zeigt logische Gruppen von Geschäftsfunktionen (Services), den Austausch und die Verwaltung von Geschäftsobjekte (Business Objects) sowie die grundlegende Anwendungs- und Infrastruktur-Architektur.

Die folgende Tabelle zeigt die Relation der Detailierungsebene und dem damit verbundenen Informationsbedarf der jeweiligen Nutzergruppe.

Die Tabelle zeigt eine Vereinfachung der Nutzergruppen. Die System-Architektur wird heute üblicherweise in vier Domänen aufgeteilt. In Business-, Daten-, Applikation- und technische Architektur. Analystin bezieht sich auf die Business-Analyse zum Zwecke des Anforderungsmanagements. Das Management umfasst Projekt- und Linienfunktionen. Zur Exekutiv-Ebene gehören CIO (Chief Information Officer), CTO (Chief Technology Officer) sowie Lead- und Enterprise-Architekten. Enterprise Architekten sollten aber auch ein ausreichendes Verständnis auf Detailebene besitzen um CIO/CTO wesentlich bei der Architektur-Steuerung zu unterstützen.

Wir halten also fest, dass eine Menge von Architektur-Informationen in unterschiedlicher Detailebenen und Versionen, einzeln oder in Beziehung zu einander, erstellt, überarbeitet und verwaltet werden müssen.
Ausserdem muss die Architektur-Information zumindest allen Stakeholdern gegenüber veröffentlicht werden. Hierbei ist zu Beachten, dass die Detailebene nicht über den Bedarf hinausgeht.
Frederic Vester, deutscher Systemforscher und Pionier des „Vernetzen Denkens“, zeigte mittels des nebenstehenden Bildes, dass eine grobe Detailebene in der Übersicht hilfreich ist. Vester gibt zu bedenken, dass auch wenn alle Details der Kästchen, wie Farbwert, Größe und Beschaffenheit, bekannt und korreliert sind, kann der gezeigten Staatenlenker nicht erkannt werden. Nur durch die Übersicht und einen gewissen Abstand ist hier das Konterfei von Abraham Lincoln zu erkennen.

Architektur-Steuerung (Governance)

Aufgabe der Governance ist die Begleitung der Implementierung. Dies erfolgt anfänglich mit dem vermitteln der grundlegenden Prinzipien, Richtlinien und Standards und setzt sich fort mit der Untersuchung der Konformität der Umsetzung zu den Entwurfsmustern. Auch die Qualitätssicherung der Planung und Implementierung sind typische Aufgaben der Architektur-Steuerung.

Die Erkenntnisse zur Konformität und Qualität der Implementierung werden regelmäßig in Zusammenfassung an den CIO/CTO, bzw. an ein Architektur-Gremium (Architecture Board)  unter deren Vorsitz, berichtet. Dabei werden Maßnahmen zur Unterstützung positiver und zur Gegensteuerung negativer Einflussgrößen diskutiert, beschlossen und begleitet.

Je nach Reife der Architektur-Funktion im Unternehmen, ist die Governance-Funktion objektivierbar. Im Idealfall basiert die Governance ganz auf den gleichen Prinzipen, Richtlinien und Standards, welche dem Planungs- und Implementierungs-Team zur Verfügung stehen. Es wird aber auch immer ein gewisses Maß an Ad-Hoc Goverance notwendig sein. Wichtig ist hierbei, dass auch die Ad-Hoc Governance ihre Entscheidungen veröffentlicht muss. Dies fördert die Nachvollziehbarkeit und erhöht die Wahrscheinlichkeit, dass Organizationsweit eine frühere Konformität zu den Ad-Hoc Entscheidungen entsteht, auch ohne eine Richtlinie, beziehungsweise vor deren Veröffentlichung. Ebenfalls Teil der zu publizierten Informationen aus der Governance sind die Ausnahmegenehmigungen oder Aufschübe für die Umsetzung der Konformität.

Je nach Größer der System-Landschaft und der Anzahl von Planungs- und Implementierung-Projekten, benötigt man einen „Fahrplan“ um die Governance-Funktion zur rechten Zeit am rechten Ort zur Verfügung stellen zu können.

Architektur-Funktion

Eine Architektur entsteht und verändert sich durch das Zusammenspiel verschiedener Tätigkeiten. Im (theoretischem) Idealfall ist das Resultat der Architektur-Funktion deterministisch. Gleiche Anforderungen und Rahmenbedingungen führen zur gleichen Architektur und Implementierung.  Dies setzt Prozesse, Rollen und Organization voraus. Die Architektur-Funktion einer Enterprise läßt sich, wie jeder andere Verbindung aus Prozessen, Akteuren und Organization, als eigenständige Architektur entwerfen, dokumentieren und publizieren. Dabei fallen die oben beschriebenen Architektur-Artefakte an.

Zusätzlich gibt es Informationen zur Ontologie der Fachbegriffe der Architektur-Funktion, Vorlagen für die Architekturbeschreibungen (View Point Library) und Beschreibungen der Rollen inklusive der Definition benötigen Kompetenzen.

Auch das verwendete Architektur-Rahmenwerk (Framework) sowie deren Zuschnitt auf die individuellen Gegebenheiten der Organization können als Information verwaltet und veröffentlicht werden.

Das „Architecture Repository“

Es werden verschiedenste Informationen bei der Planung, der Implementierung, dem Betrieb und der Evolution von Software-Architekturen benötigt und erzeugt. Wenn diese Informationen auf einem Daten- bzw. Meta-Modell basieren, kann man sie leichter elektronisch verwalten und und in Beziehung setzen.

Das folgende Diagramm zeigt das „Architecture Repository“ und dessen Umgebung, wie es von TOGAF vorgeschlagen wird:

Architecture Landscape

Hier wird ist die Beschreibung der gesamten Enterprise Architektur verwaltet.

Dies sind Architektur-Beschreibungen, welche eine Architektur einzeln und im Bezug zu anderen Architekturen in der Enterprise repräsentieren.

Beispiele sind:

• Zuordnung von Geschäfts-Funktionen, -Objekten und Akteuren zu Anwendungen
• Informations- und Datenflüsse zwischen Anwendungen
• Integration der Anwendungen (Schnittstellen, Protokolle, Technologien)
• Technische Infrastruktur für den Betrieb der Applikationen
• Meta Informationen wie Phase im Lebenszyklus oder Eigentümerschaft

Dabei wird auch die Historie bzw. die Veränderung der Enterprise Architektur verwaltet und repräsentiert. Auch zukünftige Versionen einer Enterprise Architektur lassen sich hier modellieren zum Zwecke der Planung und Simulation.

Die drei Detailierungsebenen im Architecture Repository, „Strategic“, „Segment“ und „Capability“, können den Detailierungsebenen der ArchiMate View Point Library zugeordnet werden.

Reference Library und Standards Information Base

Hier sollten alle Prinzipien, Standards, Leitlinien Referenz-Modelle und -Architekturen enthalten sein, welche für eine Architektur-Planung maßgeblich sind.

Dazu zählen beispielsweise:

• Auflagen des Gesetzgebers und der Aufsichtsorganen
• Industrieweite Kommunikationsmodelle (z.B. SWIFT und EDIFACT)
• Organizations- und Industrie-Richtlinien (Best Practices)
• Technologie Kataloge (Standard Technology-Stack)
• Vorlagen für die Architektur-Beschreibungen
• View-Point-Library

Die Reference Library und die Standards Information Base erlauben es den Architekturbeteiligten schon im Vorfeld für sie verpflichtende sowie hilfreiche Informationen zu identifizieren. Weiterhin ist die Governance-Funktion gut zu objektivieren, da zur Bestimmung der Konformität die gleichen Informationen herangezogen werden können wie bei der Planung.

Governance Log

Das Governance Log enthält Informationen welche bei der Steuerung der Architektur benötigt werden, beziehungsweise anfallen. Überwiegend ist die Governance-Funktion begleitend zur Implementierung aktiv um sicherzustellen, dass sie der Planung entspricht.

Dazu benötig man zuerst die Information über das Projekt selbst. Name und Umfang des Projekts sowie die verantwortlichen Ansprechpartner in ihren jeweiligen Rollen (Projektleitung, Architekt, Betrieb usw.).

Die getroffenen Entscheidungen bei Lösungsalternativen sowie die Abweichungen vom Standard sind wesentliche Informationen um die Architektur-Evolution nachvollziehbar zu machen und Verantwortlichkeiten zu dokumentieren.

Bei Erreichung bestimmter Meilensteine im Projektverlauf kann eine Bewertung der Konformität zu den geltenden Standards und Richtlinien zum Zwecke der Qualitätssicherung durchgeführt werden. Diese wohldefinierten Kontaktpunkte zwischen Projekt und Governance-Funktion werden durch einen Kalender planbar.

Bei der Einführung oder Änderung von Unternehmensarchitekturen kann es vorkommen, dass neue Fähigkeiten im Unternehmen benötigt werden. Seien es nun geschäftliche, technische oder planerische Fähigkeiten. Bei der Umsetzung der Architektur ist es Aufgabe der Governance-Funktion den Status der Einführung neuer Fähigkeiten regelmäßig zu erfassen und an die Führungsebene rückzumelden.

Ebenfalls regelmäßig wird die Leistungsfähigkeit und Vitalität der Architektur-Funktion innerhalb der Organization überwacht. So kann das „Architecture Charter“ die Leistungen und Reaktionszeiten der Architektur-Funktion selbst vorgeben. Die Erhebung von Soll- und Ist-Werten erlaubt es organisatorische Flaschenhälse früh zu erkennen und diesen Gegenzusteuern.

Architecture Capability und Metamodel

Die Fähigkeiten der Architektur- und Governance-Funktion ist ebenfalls im „Architecture Repository“ beschrieben. Hier werden die Strukturen und Prozesse hinterlegt, welche bei der Planung und der Umsetzung von Architekturen benötigt werden. Besonders Augenmerk liegt dabei auf der Zuordnung von Fähigkeiten zu Rollen. Um eine Rolle innerhalb der Architektur-Funktion zu erfüllen, wie zum Beispiel die Rolle des Daten-Architekten, wird ein spezifisches Wissen vorausgesetzt. Diese Zuordnung kann auch gezielt eingesetzt werden um das spezifische Wissen im Unternehmen oder in einer Behörde durch Schulungen aufzubauen.

Das im vorherigen Abschnitt erwähnte „Architecture Charter“, zu deutsch „Architektur-Vereinbarung“, ist ebenfalls Bestandteil der Dokumentation der Architektur-Funktion. Hier werden die Sponsoren (meist CIO), der Nutzen, die Ziele, sowie Beschränkungen und wichtige Anforderungen an die Architektur-Funktion dokumentiert.

Schließendlich befindet sich im „Architecture Repository“ auch das Meta-Model, welche die Datenstrukturen und ihre Beziehungen für den Inhalt des Repository selbst beschreibt.

Wechselwirkungen

Die oben aufgezeigten Elemente des „Architecture Repository“ stehen miteinander in Beziehung. Einige davon wurden bereits erwähnt, etwa die Wechselwirkung zwischen „Reference Library“ und „Standards Information Base“ mit der Architektur- und Governance-Funktion. Daraus ist ersichtlich welchen Verpflichtungen die Architektur erfüllt bzw. erfüllen muss.

Im weiteren gibt es auch Beziehungen zu Elementen ausserhalb des „Architecture Repository“.

Diese sind:

• Solution Repository
  Hier wird eine Beziehung zwischen der Architektur und der Software-Lösung hergestellt in einer Weise, dass feststellbar ist welcher Software-Baustein durch welchen Architektur-Baustein repräsentiert ist. Dies fördert die Wiederverwendung von Lösungen bei gleicher oder ähnlicher Architektur.
• Requirements Repository
  Anforderungs-Management wird in jeder Phase der Architektur-Funktion benötigt. Änderungen in den Anforderungen führen meist zu Änderungen der Architektur, deshalb gibt es eine starke Wechselwirkung zwischen Anforderungs-Management und „Architecture Repository“. Die Governance-Funktion überprüft die Konformität zu bestimmten Anforderungen oder formuliert eigene Anforderungen (Auflagen).
• Externe Quellen
  Standards und Referenzen von externen Quellen haben einen hohen Stellenwert, da sie den industrieweiten Datenaustausch begünstigen sowie bewährte Praktiken beschreiben. Auch Auflagen, zum Beispiel des Gesetzgebers, sind den externen Quellen zuzuordnen.
• Architecture Board
  Dieses Gremium übernimmt die Exekutive bei der Architektur-Steuerung und benötigt dabei Informationen aus dem „Architecture Repository“. Im Besonderen die strategische Perspektive der „Architecture Landscape“ und das „Governance Log“.

Im folgenden und letzten Teil geht es dann um die Unterstützung durch Werkzeuge.

Dieser Beitrag beschäftigt sich mit der zeitgemäßen Kundenkommunikation.

Im ersten Teil des Beitrags geht es um Anforderung an die Kundenkommunikation für eine individuelle und persönliche Ansprache zu realisieren des „Tante Emma-Prinzips“. Der zweite Teil erscheint demnächst und beschäftigt sich mit Lösungen und enthält das Fazit.

Der ganze Beitrag ist in dem Buch „Erfolgsfaktor Informations Management“ (ISBN 978-3-00-053730-1) enthalten und kann hier bestellt werden.

„Es ist viel teurer, einen neuen Kunden zu gewinnen, als einen vorhandenen Kunden zu halten.“

„Ein Großteil der verärgerten Kunden wechselt zur Konkurrenz.“

„Zufriedene Kunden sind die besten Werbeträger eines Unternehmens.“

Drei gute Gründe, um sich um die eigenen Kunden besonders liebevoll und möglichst individuell zu kümmern und sie nicht zur Konkurrenz zu treiben. Das ist keine neue Idee und wurde schon von der guten alten „Tante Emma“ praktiziert. Besonders in großen Unternehmen ist dies allerdings nicht mehr so ohne weiteres möglich, denn einem Kunden stehen in der Regel meist zahlreiche Mitarbeiter aus unterschiedlichen Verkaufs- bzw. Kommunikationskanälen gegenüber. Dies gilt ganz besonders im Geschäftskontakt mit Privatkunden. Trotz Massenkommunikation und neuen Medien möchte der Kunde immer als Individuum – eben wie bei Tante Emma – wahrgenommen werden.

Somit bedarf es eines ausgeklügelten Informationsmanagements, um über alle Kommunikationskanäle und über alle Unternehmensbereiche hinweg ein konsistentes und individuelles Auftreten gegenüber dem Kunden sicherzustellen.

Doch viele Unternehmen haben keinen vollständigen Überblick über die Kontakte mit ihren Kunden: Welcher Kunde wurde über welchen Kanal und mit welchen Inhalten kontaktiert – eine Frage die zumeist nicht befriedigend beantwortet werden kann. Verschiedene Geschäftsbereiche haben Kontakt zu ein und demselben Kunden mit unterschiedlichen Inhalten über verschiedene Kanäle, ohne voneinander zu wissen. In Folge hat man es mit verärgerten, unzufriedenen Kunden zu tun, die bei der nächsten Gelegenheit zur Konkurrenz wechseln werden.

Über die neuen Kanäle wie Internet, E-Mail und soziale Netzwerke hat sich das Kommunikationsverhalten der Kunden in den letzten Jahren stark verändert. Zusätzlich ist auch die Komplexität der angebotenen Produkte gestiegen. Diesen Veränderungen ist Rechnung zu tragen um im Wettbewerb bestehen zu können, denn das nächste Angebot ist meist nur einen „Klick weit“ entfernt.

Nach wie vor ist neben den neuen Medien auch das Telefon eine wichtige Säule im Kontakt mit dem Kunden. Doch bevor der Kunde heutzutage zum Hörer greift, hat meist vorher an anderer Stelle etwas nicht geklappt oder es blieben Fragen offen, die über die digitalen Kanäle nicht zufriedenstellend geklärt werden konnten. Umso wichtiger, dass das Servicecenter einen möglichst vollständigen Überblick über die vorherigen Kontakte und Kontaktkanäle hat.

Die Entwicklungen im digitalen Zeitalter stellen die Unternehmen immer wieder vor neue Herausforderungen. Das Kommunikationsmanagement muss darauf flexibel reagieren und sowohl mobiler und schneller, als auch individueller und kompetenter werden.

Ein Bild von der Lage machen und eine Vision entwickeln

Um herauszufinden, wie sich die Situation im eigenen Unternehmen darstellt, ist es sinnvoll, zunächst eine grobe Bestandsaufnahme bzw. Schwachstellenanalyse durchzuführen. Erste Ansatzpunkte können gefunden werden über:

• Befragung von Kunden (z.B. Interview, Fragebogenaktionen)
• Workshops, Befragung von Mitarbeitern aus tangierten Abteilungen z.B. Kundenservice, Beschwerdemanagement, Marketing, eCommerce, PR-Abteilung, Außendienst.
• Auswertung von strukturiert vorliegenden Informationen z.B. aus dem Kontakt- und Beschwerdemanagement.
• Nach Möglichkeit Auswertung oder Analyse aus Stichproben von unstrukturierten Informationen z.B. aus Chats, sozialen Netzwerken, Websites, Blogs etc…..
• Benchmarking (Konkurrenzbeobachtung)
• Beobachtung von neuen Trends und Entwicklungen

Im Ergebnis wird sich ein Bild der Stärken und Schwächen in der Kommunikation aus Kunden- und Abteilungssicht ergeben, aus welchem das weitere Vorgehen bzw. eine Vision abgeleitet werden kann. Hier ein Beispiel aus einer Kundenbefragung:

Aus diesem Beispiel der ermittelten Schwächen aus Kundensicht könnten z.B. folgende Anforderungen an die Kommunikation abgeleitet werden:

Kundenkommunikation ist eine strategische Unternehmensaufgabe

Die Art und Weise, wie ein Unternehmen mit seinen Kunden kommuniziert, ist von entscheidender strategischer Bedeutung für den langfristigen Erfolg und das Bestehen des Unternehmens im Wettbewerb. Bevor jedoch ein strategisches Projekt ins Leben gerufen wird, sollte gemeinsam mit der Geschäftsleitung eine Vision bzw. eine Strategie entwickelt werden. Wenn die Ziele des Projektes nicht klar definiert werden können und die Geschäftsleitung nicht hinter dem Projekt steht, wird der Erfolg zwangsläufig hinter den Möglichkeiten zurückbleiben. Fragestellungen sind beispielsweise:

• Was erwartet sich das Unternehmen von einer neu ausgerichteten Kundenkommunikation?
• Über welche Kanäle möchte das Unternehmen mit den Kunden kommunizieren?
• Zur Verfügung stehende Budgets und Ressourcen.
• Welche Inhalte, Prozesse und Rollen müssen geschaffen bzw. angepasst werden, um die Strategie umzusetzen?
• Anhand welcher Kennzahlen soll der Erfolg gemessen werden?
• Welche Technologien könnten hilfreich sein, um die Ziele zu erreichen?

Die genannten Fragen stellen nur eine Auswahl der zentralen Punkte dar, mit denen sich das Unternehmen zu Beginn des Projektes beschäftigen muss.

Von zentraler Bedeutung für den Erfolg des Vorhabens „Kundenkommunikation aus einem Guss“ ist  insbesondere die abteilungsübergreifende Kollaboration.

IT-Projekte: Nicht immer bemerkt man das Scheitern

Vor allem Marketing, Vertrieb und Kundenservice sind üblicherweise Silos innerhalb des Unternehmens. Die Stakeholder aus den relevanten Abteilungen müssen frühzeitig berücksichtigt und „abgeholt“ werden, um nicht von vorneherein eventuell mächtige Gegenspieler auf den Plan zu rufen. Da es beim Thema Kundenkommunikation zu großen Teilen um System- und Datenintegration geht, sollte auf jeden Fall auch die IT-Abteilung eine tragende Rolle spielen. Daher müssen zu Beginn des Projektes die unterschiedlichen Abteilungen auf ein gemeinsames Ziel eingestimmt werden, ohne bei der Lösungsfindung und Implementierung Zeit durch Reibungsverluste zu verlieren.

Komplexe IT-Projekte scheitern häufig an einer mangelhaften Zusammenarbeit zwischen IT-Abteilung und Fachbereichen. Beide Fraktionen sprechen zumeist eine andere Sprache und haben unterschiedliche Auffassungen von Projektarbeit. Oft wird der Fehler gemacht, dass die Fachbereiche zu Beginn eines Projektes ihre Lösungsanforderungen definieren, diese an die IT geben und sich dann nicht mehr weiter darum kümmern. Am Ende wird die Lösung zwar aus Sicht der IT den Anforderungen entsprechen, aus Sicht der Fachbereiche ist sie jedoch unvollständig, nicht praktikabel und im schlimmsten Fall unbrauchbar.

IT und Fachbereich sollten daher das Projekt gemeinsam leiten. Ein IT-Projektleiter und ein Co-Projektleiter aus dem Fachbereich (oder umgekehrt) sind im Idealfall mit klar gegeneinander abgegrenzten Kompetenzen gemeinsam verantwortlich. Im Projektteam sollten neben IT-Mitarbeitern auch Mitarbeiter aus den Fachbereichen vertreten sein, welche für die Dauer des Projektes von ihren eigentlichen Aufgaben ganz oder teilweise freigestellt sind. In regelmäßigen Abständen sind gegenüber einem Projektlenkungsausschuss, bestehend aus Mitgliedern des Managements der Fachbereiche, die Projekterfolge zu dokumentieren. Auch müssen die Anforderungen im Laufe des Projektes des Öfteren überprüft und ggf. angepasst werden.

Unabhängig von der IT-Lösung sollten gemeinsam mit allen beteiligten Fachabteilungen Guidelines für die Kundenkommunikation erarbeitet werden. Ein Beispiel hierfür ist die Art der Ansprache: „SERIÖS“ oder „LÄSSIG“, „DU“ oder „SIE“. Ein vermeintlich einfacher, aber sehr wichtiger Schritt in Richtung einer Kommunikation aus einem Guss.

Einen Überblick über Prozesse und die bestehende Infrastruktur verschaffen

In vielen Unternehmen ist, historisch gewachsen, eine Vielzahl von abteilungsindividuellen Lösungen vorzufinden, um den jeweils unterschiedlichen Kommunikationsanforderungen gerecht zu werden. Eine Kundenkommunikation aus einem Guss erfordert jedoch, Silos miteinander zu vernetzen und gegebenenfalls in eine neue Lösung zu integrieren, mit welcher die gesamte Kundenkommunikation abteilungsübergreifend gesteuert werden kann. Es kann auch durchaus sinnvoll sein, bestehende Systeme in diesem Zuge abzulösen. Hierzu sollte zunächst eine Bestandsaufnahme der tangierten Infrastruktur durchgeführt werden, beispielsweise:

• CRM- und ERP-Systeme (z.B. Siebel, SAP)
• Datenbanken
• Datawarehouse / BI-Lösungen
• Telefonanlage / CTI
• Dokumentenmanagement und Archivlösungen
• Office Lösungen
• Druck und Versandlösungen
• Software E-Mail-Marketing
• Software SMS-Versand
• Software Kampagnenmanagement
• Social Media Distribution
• Portale
• Eigenentwicklungen – Altsysteme
• Lösungen externer Dienstleister (z.B. zum E-Mail-Versand)

Demnächst: Im zweiten Teil des Beitrags geht es um Lösungen und das Fazit.

Eine genaue Definition von Enterprise Architecture (EA), zu Deutsch Unternehmensarchitektur, gibt es nicht. Das ist soweit nichts ungewöhnliches und zeigt, daß es ein größeres Themengebiet ist mit Raum für Interpretation.

Den Versuch alles was EA ausmacht in einem Satz auszudrücken, mündet dabei so:

• „Die Unternehmensarchitektur beschreibt aus einer ganzheitlichen Sicht, wie die IT mit ihren einzelnen Elementen und Prozessen mit dem Unternehmen verzahnt ist und zwar sowohl in aufbau- wie auch ablauforganisatorischer Sicht.“ – Quelle: Gabler Wirtschaftslexikon
• „Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.“ – Quelle: Gartner IT Glossary
• “By being inclusive with all other management frameworks, EA is a discipline that helps the Enterprise define , develop and exploit the boundaryless information flow […] capabilities in order to achieve the Enterprise’s Strategic Intent.” – Quelle: The Open Group

Wir nehmen uns etwas mehr Zeit und erzählen die Geschichte der Enterprise Architektur von Anfang an. Am Schluss gibt es eine Zusammenfassung in wenigen Worten. Wer sich nicht für Geschichte interessiert, kann also bis zum Ende des Beitrags blättern.

Alles fing 1987 mit einer Publikation von John Zachman im IBM Systems Journal an. In diesem formulierte er die Vision für Enterprise Architecture und adressierte dabei folgende Herausforderungen seiner Zeit:

• Die zunehmende Komplexität der Systeme und die dadurch steigende Kosten für Planung, Implementierung und Betrieb.
• Die schlechter werdende Vereinbarkeit von Unternehmenszielen mit der wachsenden System-Landschaft

Dabei legte er den Grundstein für seinen Ordnungsrahmen, dass als „Zachman Framework“ noch heute genutzt wird. Beeinflusst von seinen Ideen, nahm sich das US Verteidigungsministerium des Themas an und schuf 1994 mit TAFIM ein Rahmenwerk, welches 1996 an die Open Group weitergegeben wurde Seither arbeitet die Open Group mit Enterprise Architekten aus der Forschung und Industrie an TOGAF, welches zur Zeit in der Version 9.1 vorliegt.

Wenn Systeme komplizierter werden, benötigen sie mehr Planung!

Im Alltag und für andere Ingenieurs-Disziplinen leuchtet das sofort ein. Um eine Hütte im Schrebergarten zu bauen, braucht man keinen Architekten. Aber es gibt womöglich Vorschriften, wie und wo die Hütte aufgebaut werden darf. Sind die Gebäude größer werden Architekten benötigt, sogar gesetzlich vorgeschrieben.

Auch bei IT-Systemen gilt dieser Grundsatz. Aber ebenfalls das Gegenteil findet Anhänger und wird je nach Jahrzehnt als „Quick & Dirty“ oder „Agil“ bezeichnet. Agilität ist sehr wichtig, aber ab einer gewissen Komplexität kein Ersatz für eine gute Planung und umgekehrt. 

Moderne Ansätze der EA berücksichtigen dies und lassen in ihren iterativen Prozessen genug Platz für Agilität um Planungslücken und den unvorhersehbaren Wandel zu berücksichtigen.

Generell hat die Notwendigkeit zugenommen, schnell auf neue Anforderungen zu reagieren. Weshalb wir den Problemfeldern der EA von 1987 noch einen Punkt hinzufügen müssen:

• Schnelle Anpassung der Organisation und Systeme durch den Wandel des Kundenverhaltens, gesetzlicher Auflagen und des technologischen Fortschritts.

Die Bedeutung von Enterprise Architecture heute

„Er ist der Messias, ich weiß es genau, denn ich bin schon vielen gefolgt“. Dieses Zitat aus Monty Python’s Film „Das Leben des Brain“ bringt es ziemlich gut auf den Punkt. Oft wird vorschnell das Potential einer neuen Technologie oder neuer Methoden überzogen dargestellt.

Zum Teil geschieht die Übertreibung mit Absicht um gezielt Nachfrage zu generieren.

Gartner hat dafür schon länger den „Hype Cycle“ eingeführt um Orientierung zu geben. Im Verlauf einer Neuerung erklimmt diese zuerst die „Spitze der überzogenen Erwartungen“ und stürzt danach regelrecht in das „Tal der Desillusion“, bevor es schließlich das „Plateau der Produktivität“ erreicht.

Die Enterprise Architecture gilt heute als etabliert und befindet sich auf dem Weg der realen Einschätzung der Möglichkeiten. Viele Organisationen nutzen Frameworks und Tools um ihre Unternehmensarchitekturen zu verwalten sowie Praktiken der EA um die Evolution und den Wandel der Architekturen zu beherrschen und zu steuern.

Es soll nicht unerwähnt bleiben, dass durch die überzogenen Erwartungen am Zenit des Hypes auch viele kritische Stimmen laut wurden, die der EA und deren Praktiken kein gutes Zeugnis ausstellten. Diese Kritik ist richtig und wichtig um die Praktiken der Enterprise Architecture zu verbessern. Die Praktiken der EA zielen darauf die „Fitness“ (fit-for-purpose) einer Architektur sicherzustellen. Dies wird der Enterprise Architecture gelingen, da es noch über viele Jahre nötig sein wird die Problembereiche der Unternehmensarchitektur, wie Komplexität, Business Value und Evolution, zu adressieren und eine „best practice“ zu betreiben. Welches Framework und welches Tool diesen Wandel zum fit-for-purpose für sich selbst hinbekommt bleibt abzuwarten. TOGAF ist allerdings wegen seiner großen und aktiven Community der aussichtsreichste Kandidat.

Der Trend zur Cloud dürfte durchaus stimulierend wirken, schliesslich handelt es sich bei Cloud-Services um die Enterprise Architecture des Cloud-Providers. Der Cloud-Service ist die Erweiterung der organisations-spezischen Architektur eines Unternehmens wie Amazon und Google auf Kundenebene. Es ist somit eine erweiterte Enterprise im Sinne von TOGAF, und zwar der Enterprise von Amazon, Google und Co. Dabei verlieren Unternehmen die Autonomie über die Evolution der Unternehmensarchitektur. Andererseits bieten Cloud-Services die Möglichkeit an der Reife und Effizienz der Enterprise Architecture des Provides zu partizipieren.

Einige Probleme sind aber nicht Ausdruck unreifer Frameworks und Tools, sondern Resultat eines einseitigen Vorgehens der IT-Division im Unternehmen. EA wirkt am besten, wenn es ganzheitlich über die gesamte Organisation praktiziert wird, insbesondere im Verbund mit der Business-Seite. Ein weiteres Problem ist die Tendenz Unerfahrenheit durch ein starkes Festhalten an das Framework oder das Tool zu kompensieren. Hierbei kann es leicht zum Over-Engineering kommen. Charlie Parker, ein bekannter Saxophonist, brachte es für sich auf den Punkt: „Um ein guter Musiker zu sein, musst Du erst alles lernen um es dann wieder zu vergessen!“

In den vergangenen 12 Monaten zeigt das Interesse an Enterprise Architecture (Blau) und TOGAF (Rot) ein stabiles Niveau. Wobei sich mehr als doppelt so viele für die konkrete Praktik TOGAF interessieren als für Enterprise Architecture im Allgemeinen. Dies unterstreicht auch die hohe Zahl, von über 50.000, nach TOGAF zertifizierten Architekten.

Die Weltkarte links zeigt die Google Trends der letzten fünf Jahre für den Suchbegriff „Enterprise Architecture“. In Europe zeigen die Niederlande das größte Interesse an diesem Themen. Deutschland liegt im internationalen Vergleich auf dem neunten Platz. Dies ist nicht notwendigerweise ein Nachteil, wenn man in der Lage ist aus den vorhandenen Erfahrungen zu lernen.

 Zusammenfassung

Enterprise Architecture zielt darauf die Effizienz bei der Erstellung und Steuerung von komplexen System-Landschaften zu erhöhen. Der stete Wandel ist dabei ebenso wichtig wie die Ausrichtung auf den Business Value.

Das Interesse an Praktiken und populären Frameworks hat heute ein stabiles Plateau erreicht. Deutschland hat als EA-Entwicklungsland die Möglichkeit aus den Erfahrungen der Vergangenheit zu profitieren.

Praktiken der Enterprise Architecture sind auch für iterative und agile Entwicklungsprozesse geeignet, verlangen aber ein Mindestmaß an Planung und Steuerung der Architektur-Landschaft einer Organisation.

Cloud-Services sind die offenen Unternehmensarchitekturen der Cloud-Provider. Organisationen, welche diese Nutzen werden ein Teil dieser Unternehmensarchitektur. Gewinnen dabei an Effizienz und verlieren an Einfluss auf die Evolution der Unternehmensarchitektur.

Die Enterprise Architecture ist hier um zu bleiben, in welcher Form auch immer.