zurueck


Tips zur Entwicklung eines Geschäftsdomänenmodelles

In den vorausgegangenen Abschnitten habe ich dargestellt, was ein Geschäftsbereichsmodell enthalten sollte und wie die im Modell enthaltenen Information strukturiert sein sollte. Nachdem also klar ist, wie ein Modell dokumentiert werden sollte, muss ich noch erläutern, wie ein Modell erstellt werden sollte. Erstellen bedeutet:

Vorbereitung einer Modellentwicklung

Die Entwicklung eines Geschäftsbereichsmodelles ist eine umfängliche Aufgabe, die nicht unbedeutende Ressourcen und beträchtliche Zeit beansprucht. Es stellt daher für ein Unternehmen eine wichtige Entscheidung dar, solch ein Projekt zu starten. Dabei ist es unbedeutend, ob das Projekt dazu dienen soll, ein vom Unternehmen verfolgtes Geschäftsfeld zu dokumentieren und letztlich zu optimieren, oder um die Basis für die Entwicklung eines "Standard Anwendungssystemes" zu legen, das an Kunden verkauft werden soll, die in der modellierten Geschäftsdomäne operieren.

Da ein Modellierungsprojekt immer teuer ist, ist es für beide Scenarien (Unternehmensrestrukturierung oder Standardanwendungsspezifikation) sehr wichtig, dass die Unternehmensleitung ein ins Auge gefasstes Unterfangen auch unterstützt. Nur wenn es ausreichende Managementunterstützung gibt, wird es möglich sein, a) die Belegschaft davon zu überzeugen, dass es sinnvoll ist, mit den Analytikern in fruchtbarer Weise zusammenzuarbeiten, oder b) die erforderlichen, meist sehr teuren Berater zu verpflichten, die das notwendige Fachwissen beitragen sollen.

Der erste Schritt zu einem Modellierungsprojekt muss also immer sein, die richtigen Sponsoren zu finden, die auch mächtig genug sind, den Grund für das Projekt vorzubereiten, auch wenn das Projekt bestimmten Mitarbeitern zusätzliche Arbeit aufbürdet, oder Zusatzkosten für ein bestehendes Entwicklungsprojekt erzeugt.

Wenn ein Projekt erfolgreich an das Management verkauft worden ist, ist der nächste wichtige Schritt, es auch erfolgreich an das Unternehmenspersonal zu verkaufen. Dies kann in zweifacher Art passieren müssen, entsprechend der zwei Szenarien.

Szenarium 1: Unternehmensmodellierung - das Modell ist dafür vorgesehen, das Geschäftsverhalten des Unternehmens selbst zu verbessern.

Sehr wichtig ist es bei Unternehmensmodellierungen, dass die Analysten die richtigen Informationen erhalten und zwar direkt von der Front, an der das Geschäft durchgeführt wird, und nicht aus zweiter Hand, wie etwa aus Handbüchern, Formularen, aufgezeichneten Geschäftsprozeduren oder eingesetzten Anwendungssystemen. Die Fachleute vor Ort müssen einen Analysten dadurch unterstützen, dass sie ihm ihren Job erläutern und Fragen in einem offenen und stressfreien Umfeld umfassend beantworten. Dies wird nur passieren, wenn die Fachleute davon überzeugt sind, dass sie signifikant zum Modell beitragen, und dass das Modell letztlich hilft, ihren täglichen Job einfacher zu gestalten und ihre Position im Geschäftsumfeld des Unternehmens zu verbessern.

Das Beste, was passieren kann, ist, dass die Mitarbeiter das Modell als ihr Modell ansehen, das bedeutet, dass das Modell von ihnen als die kompetente Beschreibung ihrer momentanen Aufgabe sowie der von ihnen gewünschten Weiterentwicklung betrachtet wird.

Szenarium 2: Standardanwendungsentwicklung - das Modell ist dafür vorgesehen, als Basis für die Entwicklung einer domänenspezifischen Standardanwendung zu dienen.

Ein kritischer Erfolgsfaktor für "Standardanwendungssysteme" ist, dass das System fast alle bestehenden Geschäftstransaktionen einer Geschäftsdomäne in einer Art und Weise unterstützt, die für die meisten Unternehmen akzeptabel und passend ist.

Dieses Ziel kann nur erreicht werden, wenn wirkliche Fachleute unterschiedlicher Unternehmen befragt werden können, wie ein bestimmtes Geschäft betrieben werden sollte. Es muss darum Geld vorhanden sein, um die notwendigen Fachleute als Berater anzuheuern, die das erforderliche Fachwissen beizutragen haben. Es ist völlig irrig zu glauben, dass IS Anwendungsarchitekten das fachliche Pflichtenheft für das Anwendungssystem ausreichend gut erstellen können. Fachliche Anforderungen, die auf so eine Art und Weise gesammelt werden, werden sehr wahrscheinlich von wirklichen Fachleuten aus der Geschäftsdomäne nicht akzeptiert, und das bedeutet, dass die daraus resultierende Standardanwendung nicht erfolgreich sein wird.

Darum ist es sehr wichtig, dass die IS Anwendungsarchitekten um Unterstützung nachsuchen, wenn problembereichsbezogene fachliche Anforderungen definiert werden müssen. Sie sollten ihre Aufgabe in einem optimalen "technischen Design" sehen, das bedeutet, sie müssen sich um die effizienteste Nutzung der IS bezogenen Dinge kümmern, wie z.B. Modularisierung, Auswahl des geeignetsten Betriebssystemes, Implementierungssprache, Datenbank usw..

Das wiederum kann nur geschehen, wenn die IS Anwendungsarchitekten überzeugt davon sind, dass es bei der Entwicklung von Standardanwendungssystemen zwei gleichgewichtige Aspekte zu beachten gibt, nämlich die IS Gesichtspunkte und die problemdomänenespezifischen fachlichen Gesichtspunkte. Sie müssen sich als die Schlüsselexperten für alle IS bezogenen Aspekte sehen, und sie müssen akzeptieren, dass sie durch gleichgute fachliche Experten ergänzt werden müssen, um das geplante Anwendungssystem letztlich erfolgreich zu machen.

Auswahl des Personals für ein Modellierungsprojekt

Wenn entschieden ist, dass ein Modellierungsprojekt aufgesetzt werden soll, dann muss das Projekt auch mit Personal besetzt werden.
Der Projektleiter, der für die Projektverwaltung verantwortlich ist, sollte zwei Gruppen von Entwicklern mit unterschiedlichem Wissen und Erfahrung und mit unterschiedlicher Verantwortung bilden:

  1. die Gruppe der IT/IS Spezialisten, die für die IS bezogene Strukturierung und Dokumentation des Modelles verantwortlich ist.


  2. die Gruppe der fachlichen Spezialisten der Geschäftsdomäne, die für die Definition und Strukturierung der fachlichen Anforderungen an das Modell aus Geschäftsbereichssicht verantwortlich ist.

Das Modellierungsprojekt sollte mit einem Team von zwei bis drei Schlüsselexperten jeder Kategorie gestartet werden. Diese Personalausstattung sollte dann immer wieder an die Erfordernisse angepasst werden, die sich aus der Größe und Komplexität der zu modellierenden Problemdomäne und der momentan erreichten Modelldetaillierung ableitet. (Siehe auch "Gesichtspunkte der Teambildung" weiter unten.)

Planung der Modellierungsaufgaben

Es gibt zwei unterschiedliche Arten, ein Modell zu entwickeln, den "Top down" Ansatz und den "Bottom up" Ansatz.

Der "Top down" Ansatz favorisiert ein intellektuelles Verfahren, das von einer sehr hohen Abstraktionsebene (einer "Score Card" d.h. einem Wunschziel) startet. Es sind also nur eine Reihe wichtiger Ziele festgelegt, die erreicht werden müssen. Geleitet von dieser Zielsetzung wird eine schrittweise Zerlegung und Strukturierung der Problemdomäne vorgenommen und zwar solange, bis der erwünschte Detaillierungsgrad des Modelles erreicht ist. Der Vorteil dieses Verfahrens ist, dass die Analytiker und Architekten von Anfang an eine ideale Geschäftsstrukturierung im Modell anstreben können. Nachteilig ist, dass die Art und Weise, wie ein Geschäft momentan betrieben wird, möglicherweise völlig ignoriert wird. Das kann bedeuten, dass Organisationen, die das Modell als Basis ihres geschäftlichen Verhaltens übernehmen, mit großer Wahrscheinlichkeit ziemliche Änderungen akzeptieren müssen.

Der "Bottom up" Ansatz favorisiert eine mehr praktische Methode, die mit einer gewissenhaft durchgeführten Bestandaufnahme der zu restrukturierenden Problemdomäne startet. Dann wird das gesammelte Material analysiert und entsprechend der festgelegten Modellierungsprinzipien neu strukturiert. Der Vorteil dieses Vorgehens ist, dass Bestehendes intensiver wiederverwendet wird und dass darum Änderungsanforderungen an die, die neuen Empfehlungen übernehmende Organisationen viel moderater ausfallen werden. Nachteilig ist, dass die neu entwickelte Struktur wegen der eingegangenen und allgemein akzeptierten Kompromisse nicht so optimal sein wird, wie das möglich gewesen wäre.

Der am meisten Erfolg versprechende Ansatz ist, beide Verfahren zu kombinieren.
Ein "Top down" Ansatz für die Definition der Modellierungsprinzipien und der grundlegenden Modellstrukturen garantiert ein fast optimal strukturiertes Modell und ein "Bottom up" Ansatz für die Definition der endgültigen Geschäftsobjekte und Geschäftsprozeduren garantiert Vollständigkeit sowie einen reibungslosen Übergang, wenn modellbasierte Systeme implementiert werden.

Angenommen, dieser kombinierte Ansatz wird verwendet, dann sind die in den folgenden Abschnitten beschriebenen Arbeitsschritte für ein Modellierungsprojekt zu planen.

Festlegung der Modellgrenzen.

Die saubere Definition und Abgrenzung des Inhaltes eines Modelles muss die erste Aufgaben sein, die für ein Modellierungsprojekt durchzuführen ist. Es ist überaus wichtig, dass den Analytikern ganz von Anfang an klar ist, was das Modell enthalten soll und was ausgeschlossen werden muß. Sind die Grenzen einer Problemdomäne und damit auch ihres Modelles nicht präzise festgelegt, dann besteht die Gefahr, dass das Modellierungsprojekt zu einem ewigen Projekt wird, denn alle Analysten haben eine natürliche Tendenz, die "ganze Welt" zu modellieren, und das dauert sicherlich seine Zeit.

Die Grenzen der Problemdomäne (respektive des Modells) muss durch eine kleine Gruppe von Topspezialisten der betreffenden Domäne, die auch mit den angrenzenden Domänen hinreichend vertraut sind von relativ hoher Warte aus festgelegt werden. Dabei ist es sehr von Vorteil, wenn diese Experten ein Vision haben, in welche Richtung hin sich eine Problemdomäne entwickeln sollte.

Festlegung der geschäftsbezogenen Struktur des Modelles.

Nachdem die Grenzen der Problemdomäne festgelegt sind, muß die Grundstruktur des Domänenmodelles festgezurrt werden. Das bedeutet, das Modell wird - sofern sinnvoll - in kleinere, logisch begründete Unterdomänen aufgegliedert. Auch diese Aufgabe sollte von der kleinen Gruppe von Topspezialisten der betreffenden Domäne ausgeführt werden, denn das ist eines ihrer Hauptinstrumente zur Festlegung, wie ein Geschäft in der Zukunft optimal durchgeführt werden sollte. Als geeignete Darstellungsform für solch eine stark abstrahierte Inhaltsstruktur sollte ein hierarchischer Zerlegungsbaum verwendet werden.

Für ein Unternehmensmodell sollte die Grundstruktur zum Beispiel die angestrebte Struktur der Unternehmensorganisation und ihrer Hierachien enthalten, das sind die benötigten Unternehmensbereiche und ihre Verantwortlichkeiten (zum Beispiel "Produktion", "Marketing und Vertrieb", "Verwaltung und Controlling", "Finanzwesen", "Personal", usw.). Geographische und andere wichtige Aspekte - sofern relevant - können ebenfalls berücksichtigt werden.
Für eine Industriemodell sollten die Geschäftszweige definiert werden, die für die Industrie von Bedeutung sind. Für die Automobilindustrie könnte das die Produktion und der nationale sowie der internationale, weltweite Vertrieb mit seinen Groß- und Einzelhandelsaspekten sein. Für andere Industriezweige können andere Bereiche von Interesse sein.

Natürlich muss in dieser Phase alles aus stark erhöhter Sicht beschrieben werden, die den Analytikern die wünschenswerte Freiheit und Flexibilität zur Beschreibung detaillierterer Modellschichten gewährt.

Untersuchung bestehenden Geschäftsverhaltens.

Kein Geschäftsverhalten kann aus dem Nichts heraus beschrieben werden. Es gibt immer Prozeduren (dokumentiert oder auch nicht dokumentiert), die Fachleuten Anhaltspunkte geben, wie eine bestimmte geschäftliche Transaktion durchgeführt werden sollte. Und dieses momentan angewandte Verhalten stellt ein ungeheures Reservoir an Erfahrung dar. Es wäre grob fahrlässig all dieses existente Wissen zu ignorieren.

Das Problem besteht darin, wie all dies Wissen zusammengetragen und den Geschäftsanalysten verfügbar gemacht werden kann, die beauftragt worden sind, ein Segment des angestrebten Modelles zu definieren.

Ich muß auf die zwei oben beschriebenen Szenarien zurückkommen.

Wenn ein Unternehmensmodell entwickelt werden soll, dann können die Fachleute im Unternehmen, die bestimmte Aufgaben tatsächlich auch durchführen, direkt gefragt werden, was sie genau machen und wie sie die anfallenden Arbeiten durchführen. Ein gegliedertes Formular zur Aufzeichnung geführter Interviews kann entwickelt werden, um damit spätere Analysen und Restrukturierungen der aufgezeichneten Informationen zu unterstützen. Die Zusammenstellung einer Sammlung von geschäftsspezifischen Fachausdrücken, die normalerweise eine bestimmte Tätigkeit in generischer Form beschreiben, kann hilfreich sein, wenn erwartet wird, dass bestimmte Tätigkeiten in ähnlicher, aber nicht identischer Form an verschiedenen Stellen im Unternehemen ausgeführt werden. Zum Beispiel kann eine "Preisfestlegung" für ihre Produkte von unterschiedlichen Abteilungen eines Unternehmens in unterschiedlicher Art und Weise vorgenommen werden. Wenn ein für einen Vorgang festgelegter Begriff im Interviewreport aufgeführt wird, dann wird es später leichter, ähnliche Arbeiten zu identifizieren und sie im endgültigen Modell als eine Aufgabe zusammenzuführen.

Geschäftsdaten können relativ leicht aus existierenden und im Unternehmen verwendeten Formularen oder Datenbanken abgeleitet werden. Während der Durchführung von Interviews sollte dann aber darauf geachtet werden, dass die Fachleute nach ihren Empfehlungen für Ergänzugnen und Optimierungen der existenten Informationseinheiten gefragt werden.

Etwas schwieriger ist die Erforschung von aktuellem Geschäftsverhalten, wenn Industriemodelle oder Geschäftsbereichsmodelle entwickelt werden sollen, die als Grundlage für die Entwicklung von Standardsoftware vorgesehen sind. Solche Modelle werden normalerweise von Unternehmen erstellt, die nicht direkt und auf keinen Fall tief mit der ausgewählten Geschäftsdomäne vertraut sind. Diese Unternehmen haben in aller Regel tiefgehende Analyse-, Strukturierungs- und Entwicklungserfahrungen, aber das Fachwissen über den zu modellierenden Geschäftsbereich ist meist dürftig.

Für ein derartiges Projekt ist es unumgänglich, dass gute Fachkräfte aus der zu modellierenden Geschäftsdomäne verpflichtet werden. Diese Fachkräfte sollten idealerweise auch noch aus verschiedenen Firmen kommen, und zwar aus Unternehmen, die anerkannterweise erfolgreich im entsprechenden Fachgebiet operieren. Die Fachkräfte sollten auch von Zeit zu Zeit ausgetauscht werden, um die für eine gute Modellierung erforderlichen unterschiedlichen Standpunkte während der einzelnen Modellierungsphasen zu bekommen.
Bewährt hat sich, ein Projekt mit Fachkräften zu beginnen, die aus dem mittleren Management eines Unternehmens kommen. Diese Leute haben in der Regel eine Vision, wie ein bestimmtes Geschäft, für das sie verantwortlich zeichnen, durchgeführt oder verbessert werden sollte. Sie sind aber ausreichend weit von der tatsächlichen Durchführung der aktuellen Transaktionen weg, so dass sie nicht betriebsblind dem aktuellen Verhalten verhaftet bleiben.
Später sollte dann auf Fachkräfte zurückgegriffen werden, die enger an der tatsächlichen Durchführung von Transaktionen sind, z.B. Abteilungsleiter oder Gruppenführer die tatsächlich die Tricks zur effektiven Transaktionsausführung, aber auch die Fallsticke kennen, die bei einer Transaktionsausführung ab und zu auftreten und den Fachleuten manchmal das Leben schwer machen.

Zur Sammlung der notwendigen Informationen können natürlich ebenfalls die Hilfsmittel eingesetzt werden, die für die Entwicklung von Unternehmensmodellen Verwendung finden. Bestehende Versionen von Standardanwendungssystemen sind zusätzlich eine gute Quelle, die analysiert werden kann, zumindest um zu garantieren, dass eine gewisse Kontinuität hergestellt wird und dass der Umstieg erleichtert wird.

Restrukturierung der gesammelten Information

Die letzte und allerwichtigste Aufgabe in einem Modellierungsprojekt ist die Restrukturierung der gesammelten Information entsprechend der bereits zu Projektbeginn festgelegten Basisstruktur des Modelles.

Während dieser Phase müssen primär alle Redundanzen aus dem Modell entfernt werden. Dabei wird man erstaunt sein, wieviele Redundanzen es gibt.
Die Geschäftsklassen müssen optimal definiert werden, und zwar aus informationstechnischen Gesichtpunkten wie auch aus Gesichtspunkten des wünschenswerten Basisverhaltens. Informationseinheiten müssen in logische Gruppen zusammengefasst werden, und es muss sichergestellt werden, dass ein bestimmtes Informationselement nur ein einziges Mal vorkommt. Dasselbe gilt auch für die Methoden, die das Basisverhalten der Geschäftsklasse definieren.
Geschäftsprozeduren müssen in ihre elementaren Komponenten zerlegt werden, doppelte Elemente müssen eliminiert werden, und die verbleibenden Elemente müssen jeweils einem einzigen Eigentümer (einer Organisationseinheit) zugeordnet werden. Entsprechend der Verantwortlichkeit einer Organisationseinheit müssen die Geschäftsprozeduren dieser Organisationseinheit zusammengestellt werden. Dazu sind die definierten elementaren Komponenten zu verwenden. Ausgegangen werden muß bei der Komposition der Geschäftsprozeduren von den gefundenen externen Ereignissen, die in der Geschäftdomäne als wichtig registriert werden. Und das Alles wieder auf der Basis der zu Projektbeginn festegelegten Regeln.

Während des gesamten Modellierungsprozesses ist eine Sache von essentieller Wichtigkeit:

Es ist immer daran zu denken, dass man ein Modell baut, und in einem Modell gibt es so gut wie keine Zwänge. Ein Modell stellt einen hohen Grad an Geschäftsabstraktion dar. Darum hat es frei von technischen, aber auch organisatorischen Aspekten zu sein. Man sollte niemals etwas strukturieren (oder noch viel schlimmer, etwas weglassen) aus der Sicht momentan existierender Implementierungsschwierigkeiten, die aus technischen Einschränkungen oder organisatorischen Zwängen herrühren, denn solche Aspekte haben in einem Modell nichts zu suchen. Geschäftsbereichsmodelle müssen unter den Gesichtspunkten maximaler Nutzungsdauer entwickelt werden, und wer weiss schon, was morgen technisch möglich sein wird. Wenn man glaubt, dass man aus Geschäftssicht die optimale Struktur gefunden hat, dann sollte man sie auch so ins Modell aufnehmen.

Sofern notwendig, können Rückzieher und Kompromisse immer noch während der Festlegung des technischen Anwendungsenwurfes und der Implementierung vorgenommen werden. Ausgehend vom Abstrahierungsgrad des Modelles liegt es in der Verantwortung der technischen Architekten, die existierenden technischen Mittel so optimal wie möglich einzusetzen.

Gesichtspunkte der Teambildung

Während eines Modellierungsprojektes müssen nacheinader unterschiedliche Teams gebildet werden, aber ein Prinzip hat immer oberste Priorität, wenn Teams zusmmengestellt werden.

Es ist immer der Spezialist für den Geschäftsbereich, der bezüglich des Modellinhaltes das Sagen hat. Die IS Spezialisten sind "nur" verantwortlich für die Auswahl der geeigneten Dokumentationsform und der strikten Einhaltung der gewählten Dokumentationsprinzipien und damit für die innere Konsistenz des entstehenden Geschäftsbereichmodelles.

Welche Art von Teams braucht man, und welche Teamzusammensetzung verspricht am ehesten die Entstehung eines guten Modelles? Die folgende Tabelle versucht gewisse Hilfestellungen zu geben:


Modellierungsphasen und Teamzusammensetzungen

Phase
Teammitglieder
Definition der Modellgrenzen 1 Teamleiter - eine Person mit verwaltungstechnischen Erfahrungen und Moderierungsfähigkeiten die als "Förderer" (facilitator) arbeiten kann.
2 oder 3 Fachexperten - Personen mit detaillierter Kenntnis der Problemdomäne und ihrer Nachbargebiete. Mittleres Management mit einer konkreten Geschäftsvision.
Definition der Modell-Grundstruktur 1 Teamleiter - eine Person mit verwaltungstechnischen Erfahrungen und Moderierungsfähigkeiten die als "Förderer" (facilitator) arbeiten kann.
2 bis 3 IT Spezialisten - Personen mit guten Kenntnissen über Modellierungsprinzipien (guter Überblick) und der Fähigkeit abstrakt zu denken.
1 to 2 Fachexperten - Personen mit guten Gesamtkenntnissen der Geschäftsdomäne.
Informationssammlung 1 Gesamtteamleiter mit verwaltungstechnischen Erfahrungen zur Koordination der Aktivitäten.
Einige Subteamleiter für die verschiedenen Sub-Domänen.
Für jede Sub-Domäne ein Kleinteam aus einem Fachexperten mit guten Kenntnissen der Subdomäne und einem IS Spezialisten mit der Fähigkeit, abstrakt zu denken, Gespräche zu moderieren und korrekt zu protokollieren.
Restrukturierung der Information / endgültige Modellierung 1 Gesamtteamleiter mit verwaltungstechnischen Erfahrungen zur Koordination der Aktivitäten.
Einige Subteamleiter für die verschiedenen Sub-Domänen.
Für jede Sub-Domäne ein Kleinteam aus einem oder zwei Fachexperten mit guten Kenntnissen der Subdomäne und einem IS Spezialisten mit der Fähigkeit, abstrakt zu denken und Modellierungserfahrung.

Ein Konsolidierungsteam mit einem Moderator (vorzugsweise einem der Schlüsselexperten für die Geschäftsdomäne), einem IS Spezialisten als "Modell-Eigentümer", der dafür zuständig ist, Zwischenergebnisse in das Gesamtmodell (master model) zu integrieren und der garantiert, dass das Gesamtmodell konsistent und redundanzfrei bleibt und einige Fachexperten (vorzugsweise die Schlüsselexperten aller momentan arbeitender Subteams).

zum Seitenanfang
zum Inhaltsverzeichnis

previous