Auf Linie

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:

Produktorganisation

Diese Organisationsform wird auch Divisionäre Organisation genannt. Anstatt nach Funktionen ist sie auf der zweiten Hierarchieebene nach Objekten gegliedert. Die Gliederung (Objekte) können Produkte, Produktgruppen, Märkte, Regionen oder Kunden umfassen.

Es handelt sich hierbei um ein sogenanntes Einliniensystem, da in der Hierarchie nur eine einfache, über eine Linie verbundene, Führungsstruktur vorhanden ist. Jeder hat einen einzigen Vorgesetzten.

Die Unabhängigkeit der Teilbereiche sind bei der Produkt-Organisation größer als bei einer funktionalen Untergliederung, weshalb man von einer Entscheidungsdezentralisierung sprechen kann.

Das Einliniensystem stößt schnell an seine Grenzen, wenn die Organisation insgesamt zu groß wird. Dies kann zu langen und starren „Wegen durch die Instanzen“ führen.

Das Einliniensystem ist eine typische Form der Organisationsstruktur für neu gegründete Unternehmungen sowie für stabile, tendenziell bürokratische Organisationen und für solche, die großen Wert auf Disziplin und eindeutige Kommandostrukturen legen.

Matrixorganisation

Markant ist hierbei die Einführung einer zweiten, horizontalen Führungsebene, weshalb man von einem Mehrliniensystem spricht.

In der ersten Führungsebene, der Verrichtungsebene, geht es um die Erbringung von Leistungen für eine Vielzahl von Objekten. In der Grafik oben sind diese Objekte Projekte. Es können aber auch Produkte, Regionen, Märkte, Programme und Systeme sein. Die Objektebene bildet die zweite Führungshierarchie in der Matrixorganisation. Oft spricht man auch von fachlichen Vorgesetzten (z.B. Projektleiterin) und disziplinarischen Vorgesetzten (z.B. Abteilungsleiterin). Mitarbeiter einer Matrixorganisation sind deshalb in gewisser Weise „Diener zweier Herrn“.


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 MatrixorganisationDivisionale Organisation

TOGAF® Architecture Partitioning

Informationsbedarf der Enterprise Architektur – Teil 3

Informationsbedarf der Enterprise Architektur – Teil 3

Im dritten und letzten Teil der Reihe  geht es um den Einsatz von Werkzeugen im Umgang mit Enterprise Architecture sowie einige Dinge, die es dabei zu bedenken gilt.

Teil 1 gab Überblick und Motivation für das Thema. Teil 2 beinhaltet den konkreten Bedarf an Informationen und den Umgang damit.

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

Werkzeuge

Für die Verwaltung der Informationen im „Architecture Repository“ hat sich eine eigene Gattung von Software herausgebildet, „Enterprise Application Management Tools“ oder auch allgemeiner „Enterprise Architecture Tool“. Das Spektrum geht dabei von der reinen Verwaltung der „Architecture Landscape“ bis hin zu modular aufgebauten Frameworks von erheblicher Komplexität.


Unter den Anbietern zu finden sind  Troux mit dem gleichnamigen Produkt, „Rational System Architect“, welches IBM Ende 2015 an Unicom Systems verkauft hat, die Software AG mit „Aris“ und „Alfabet“, der derzeitige Marktführer Mega mit seinem gleichnamigen Produkt sowie Iteraplan mit „iteratec“, welche als Open Source Software in einer sogenannten „Community“ (kostenlos) und „Enterprise“ Edition angeboten wird.

Manche der Lösungen verarbeiten mehr als die oben beschriebenen Informationen des „Architecture Repository“. Die meisten der angebotenen Produkte haben einen Suite-Charakter und umfassen auch das Anforderungs-Management,  das modellieren von Geschäftsprozessen (Business Process Models), budgetäre Informationen sowie Komponenten zur Projektplanung und -steuerung.

Bei Auswahl von umfangreichen Lösungen sollte man eine angemessene Einarbeitungszeit sowie zusätzlichen Beratungsleitungen des Herstellers einplanen. Der Vorteil von modular aufgebauten Suiten ist das „mitwachsen“ der Lösung. Dies erlaubt die stufenweise Erweiterung um neuen, höheren Anforderungen an das Enterprise Architektur-Management gerecht zu werden.  Einige Produkte erlauben ebenfalls eine Partitionierung der Informationen und mehrfache Installation, um den föderalen Aufbau größerer, IT-zentrischer Organisationen zu unterstützen.

Das Lizenzmodell der Anbieter sollte vor einer Produktauswahl genauer Untersucht werden. Bei einige Anbietern, wie der Software AG, reicht die Produktpalette von kostenlosen Einsteigerversionen bis hin zu komplexen Installationen, welche Investitionen im Millionen Euro Bereich entsprechen. Die meisten Hersteller bieten flexible Modelle bei den Lizenzen an. So gibt es benutzerbezogen (named user) Lizenzen, sogenannte „floating licenses“, Lizenzen per Installation und globale, Multi-Installationen Lizenzen.

Es besteht auch die Möglichkeit sich ein Informationsmanagement-System für die Enterprise Architektur durch das Kombinieren verschiedener, eventuell schon vorhandener, Werkzeuge selbst aufzubauen.  Nicht unüblich, zum Beispiel, ist die Kombination aus Microsoft SharePoint, Visio und einem Wiki. SharePoint dient hierbei als Content-Management Plattform, Visio der Erstellung von Diagrammen und das Wiki als Benutzerschnittstelle.

Das Werkzeug sollte der Größe der System-Landschaft und dem Reifegrad der Architektur-Funktion angemessen sein. Die reichhaltigen Möglichkeiten von umfangreichen Suiten gehen ohne die eigene Anforderungen zu kennen, unter Umständen über den Bedarf hinaus.

Bei der Werkzeugauswahl entsteht leicht eine Henne-Ei-Situation: Nehme ich zuerst ein Werkzeug und lege meine Architektur-Funktion danach aus, oder lege ich zuerst meine Architektur-Funktion fest und suche mir das dazu passende Werkzeug aus?

Die Werkzeug-getrieben Enterprise Architektur ist empfehlenswert, wenn der Reifegrad der Architektur-Funktion nicht hoch ist, hat aber den Nachteil, dass über die vom Werkzeug geführten Fähigkeiten hinaus, eine eigene Vision nur schwer zu verwirklichen ist. Auch gibt es Hinweise, dass „Conway’s Law“ ebenfalls für die Verbindung von Enterprise Architecture Tool und den Entwürfen gilt. „Conway’s Law“ besagt: „Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“

Andererseits ist die Konzeption einer Enterprise Architektur-Disziplin unter Umständen ein ressourcen-intensives Unterfangen. Die Unterstützung der Führungsebene könnte bröckeln, wenn nicht auch schnell Ergebnisse geliefert werden. Allerdings ist eine eigenständige und gute Vision, mit der entsprechenden Konzeption und  Werkzeugunterstützung, durchaus ein Wettbewerbsvorteil für IT-intensive Organisationen.

Fazit

Die anfallende Informationsmenge und der Informationsbedarf in der Enterprise Architektur ist von der Unternehmensgröße, der Anzahl der Systeme und vom Reifegrad der Organization abhängig.

Eine zu schwaches Informations-Management kann zu einer Vernachläßigung der Architektur-Führung führen, mit der Folge erhöhter Gesamtkomplexität der Architektur-Landschaft durch großer Heterogenität der Lösung und funktionalen Redundanzen.

Ein zu starkes Informations-Management kann über das Ziel hinausschiessen und verursacht einen erheblichen administrativen Aufwand. Anpassungen der Architektur-Funktion ziehen unter Umständen Aufwände im Bereich des Informations-Management nach sich. Eine größere Homogenität der Architekturen und Reduktion der funktionalen Redundanzen sind allerdings möglich. Es muss dabei auch berücksichtigt werden, dass sich Standardisierung und Innovation diametral gegenüberstehen. Eine permanente Innovation verhindert eine wirkungsvolle Standardisierung und eine starke Standardisierung erlaubt keine Innovation. Diese Aspekte gehören ausbalanciert.

Das Angebot an Werkzeugen unterstützen verschiedene Ausprägungen. Die Marktführer haben allerdings den Fokus auf ein starkes, umfängliches Informations-Management, welches im Bedarfsfall durch Reduktion auf den entsprechenden Anwendungsfall angepasst wird.

Bei der Produktauswahl sollte ein Mindestmaß an Konzeption der Architektur-Funktion  in der Organization vorhanden sein. Die Konzeption muß aber keineswegs vollumfänglich sein bevor ein Werkzeug ausgewählt wird. Dabei sollte man allerdings berücksichtigen das der Umfang der Investition dem Umfang der Konzeption angemessen ist. Also schwache Konzeption, schwache Investition und starke Konzeption, starke Investition.

Die Verbindung zwischen dem Enterprise-Architektur-Tool und des Entwurfs der Enterprise Architektur (Conway’s Law) bedingt, dass das Werkzeug ebenfalls den gleichen Anforderungen an Flexibilität und Agilität entspricht. Es muss sich schnell den Veränderungen der Architektur-Funktion anpassen lassen.

Entwicklung im Bereich der Open Source Software versprechen neue, flexiblere Ansätze. So erlauben Graphdatenbanken nicht nur das effiziente Verwalten von Diagrammen, sondern erlaubt auch Informationen zu Verbinden, ohne vorherige relationale Abbildungsanweisungen zu formulieren. Gleichsam wie auf einer Landkarte kann man zwischen „Informations-Siedlungen“ über ihre Verbindungen traversieren, um z.b. alle „Nachbar-Siedlungen“ auszumachen. Die Entkopplung von Funktionsgruppen (Services) in der Verarbeitung der Informationen, sowie HTTP-basierte Protokolle erlauben einen modularen Aufbau mit guter Integration und guter Änderbarkeit.

Man kann auf die Evolution der Enterprise-Architcture-Tools in naher Zukunft gespannt sein. Werkzeug-Hersteller die ein Lizenzmodell auf Nutzerbasis oder komplexe Bedienoberflächen anbieten, verpassen womöglich den Zeitgeist und bekommen in Zukunft weniger „likes“. Die Open Source Communities und die sozialen Netzwerke zeigen das verteilte Zusammenarbeit und der Informationsaustausch Spaß machen kann.

Quellen

Blind Men and an elephant – https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

Open Group TOGAF 9 – https://www.opengroup.org/togaf/

Open Group ArchiMate – https://www.opengroup.org/archimate/

Frederic Vester, Neuland des Denkens – Vom technokratischen zum kybernetischen Zeitalter, dtv, München 1984 / 2002, ISBN 3-423-33001-5

Gartner, Magic Quadrant for Enterprise Architecture Tools 2015