Konzept: Große Organisationen modellieren
Bei der Modellierung großer Organisationen werden Unternehmen in einzelne Komponenten aufgeteilt (z. B. Finanzen, Marketing, Fertigung usw.), um dem hohen Komplexitätsgrad Herr zu werden.
Beziehungen
Hauptbeschreibung

Kleine und große Organisationen

Die Unterschiede zwischen einer kleinen und einer großen Organisation liegen in dem breiteten Spektrum von Produkten, die häufig aus völlig verschiedenen Produktfamilien stammen. Im Allgemeinen gilt, dass je höher die Komplexität der Produkte ist, desto verteilter sind Organisation und Markt. Dies führt zu einer höheren Anzahl komplexerer Geschäftsanwendungsfälle, an denen eine höhere Anzahl von Mitarbeitern mit spezielleren aufgaben beteiligt sind.

Die hier vorgeschlagenen Techniken können unabhängig voneinander oder in Kombination angewendet werden.

Abstrakte und detaillierte Geschäftsanwendungsfälle

Das leitende Management eines Unternehmens sowie die Prozesseigner sind an den Geschäftsmodellen für ihr Unternehmen interessiert. Das Management muss mit den strategischen Zielsetzungen des Unternehmens arbeiten, und die Prozesseigner und -leiter benötigen ein detailliertes Bild von der Durchführung der Prozesse.

Wenn die Sichten auf die Organisation von Entscheidungsträgern und Prozesseignern zu stark voneinander abweichen, könnten sie die Anforderungen beider Seiten erfüllen, indem Sie zwei unterschiedliche, aber dennoch miteinander in Zusammenhang stehende Gruppen von Geschäftsanwendungsfällen entwickeln. Das Modell für die Entscheidungsträger könnte eine Gruppe von Geschäftsanwendungsfällen der hohen Ebene enthalten, die Absicht und Zweck der Organisation veranschaulichen. Das Modell für die Prozesseigner könnte eine Gruppe detaillierter Anwendungsfälle enthalten, die veranschaulichen, wie die Organisation intern funktionieren muss. Für jeden Geschäftsanwendungsfall der hohen Ebene könnten Sie einen oder mehrere detaillierte Anwendungsfälle definieren, die dieselben Aktivitäten in der Organisation darstellen. Beispielsweise könnten Sie mit dem primären Geschäftsakteur beginnen, die Ergebnisse und Services, an denen dieser interessiert ist, detailliert beschreiben oder sogar den Geschäftsakteur selbst spezialisieren und anschließend einen gesonderten Geschäftsanwendungsfall für jeden detaillierten Bereich entwickeln.

Wenn Sie Ihre Organisation auf der Basis von Geschäftsanwendungsfällen aufbauen möchten, können Sie diese Technik inkrementell anwenden. Zuerst erstellen Sie ein Anwendungsfallmodell der hohen Ebene des gesamten Geschäfts und stufen die Geschäftsanwendungsfälle in einer Übersicht nach Rangordnung ein. Anschließend identifizieren Sie einen oder mehrere detaillierte Geschäftsanwendungsfälle für die Geschäftsanwendungsfälle der hohen Ebene, die in der Rangordnung am höchsten stehen.  

Zwischen einem Geschäftsanwendungsfall der hohen Ebene und seinen detaillierten Geschäftsanwendungsfällen besteht eine Eins-zu-eins-Beziehung. Die Beziehungen zwischen Geschäftsanwendungsfällen der beiden Kategorien werden als <<Präzisierungsbeziehung>> (refinement), einem Stereotyp von Abhängigkeit dargestellt. Ein Geschäftsanwendungsfall der hohen Ebene und die Gruppe der zugehörigen detaillierten Geschäftsanwendungsfälle können in demselben Diagramm dargestellt werden.

Im folgenden Inhalt beschriebe Abbildung

Geschäftsanwendungsfälle der hohen Ebene und detaillierte Geschäftsanwendungsfälle. Die detaillierten Geschäftsanwendungsfälle werden durch die detaillierte Beschreibung der Ergebnisse, an denen Kunden und potenzielle Kunden interessiert sind, ermittelt.  

Übergeordnete und untergeordnete Modelle

Die Technik für die Modellierung von Geschäftsanwendungsfällen, die bisher vorgestellt wurde, lässt sich am einfachsten auf Unternehmen anwenden, die nur einen Geschäftsbereich haben und deren Geschäftsaktivitäten geographisch auf einen Standort konzentriert sind. Für größere Unternehmen mit mehreren Standorten kann es erforderlich sein, diese Technik zu skalieren.

Wenn Sie Unternehmen modellieren möchten, die sich aus unabhängigen, aber kooperierenden Teilen zusammensetzen, können Sie ein übergeordnetes Geschäftsanwendungsfallmodell, das das gesamte Geschäft beschreibt, und für jeden Geschäftsbereich ein untergeordnetes Geschäftsanwendungsfallmodell erstellen. Geschäftssysteme können verwendet werden, um die verschiedenen Zuständigkeitsbereiche, unterschiedliche physische Standorte oder interagierende Teile des Geschäfts zu definieren.

Für die Untersuchung von Realisierungen der übergeordneten Geschäftsanwendungsfälle können Sie Geschäftssysteme identifizieren und zeigen, die sie für den Workflow kollaborieren. Auf dieser Ebene entspricht ein Geschäftssystem einem Geschäftsbereich. Kollaborationen zwischen Geschäftssystemen können explizit definiert und mit Schnittstellen auf einer Geschäftsebene transparenter gestaltet werden. Diese "Schnittstellen" beschreiben die Zuständigkeiten des Geschäftssystems.

Übergeordnete und untergeordnete Modelle einer Organisation

Übergeordnete und untergeordnete Modelle einer Organisation

Im folgenden Inhalt beschrieben Abbildung

In diesem Beispiel sehen wir, dass der übergeordnete Geschäftsanwendungsfall "Anforderungsentwurf" in den untergeordneten Geschäftsanwendungsfällen "Projekt für Anforderungsentwurf, Projektplanung und -schätzung" und "Ressourcenkosten schätzen" auf Geschäftssystemebene präzisiert wird. Der übergeordnete Geschäftsanwendungsfall "Ressourcen bereitstellen" wird in den untergeordneten Geschäftsanwendungsfällen "Ressourcenbedarf bestimmen" und "Rohmaterial einkaufen" auf Geschäftssystemebene präzisiert.

Jedes Geschäftssystem kann dann als eigene Organisation behandelt werden, das die Schnittstellen erfüllt, die in dem übergeordneten Geschäftsanalysemodell definiert sind.

Die Ableitung der untergeordneten Geschäftsanwendungsfälle (die die erforderlichen Schnittstellen für jedes Geschäftssystem zur Realisierung der übergeordneten Geschäftsanwendungsfälle einrichten) kann analog zu dem auf der Seite Konzept: Anwendungsfall-Flowdown beschriebenen Verfahren durchgeführt werden.

Geschichtete Geschäftsmodelle

Im Software-Engineering wird eine Technik, die anwendet wird, um die Komplexität sehr großer Systeme zu meistern, Schichtung (oder Layering) genannt. Hinter dieser Technik steckt die Idee, die anwendungsspezifischen Teile von den eher allgemeinen Teilen des Systems zu trennen, so dass die Programmeinheiten und Programmservices wiederverwendet werden können. Bei der Strukturierung von Organisationen werden dieselben Prinzipien häufig ganz selbstverständlich angewendet. In der unteren Schicht finden Sie beispielsweise Ressourcen, die allgemeine Services bereitstellen. Irgendwo in der mittleren Schicht finden Sie häufig Ressourcen, die geschäftsspezifische Aktivitäten unterstützen, und in der oberen Schicht finden Sie geschäftsbereichsspezifische oder produktspezifische Spezialisten-, Forschungs- und Entwicklungs- und Vertriebsaktivitäten. Die Kerngeschäftsfälle verwenden Ressourcen von allen Schichten.

Schichtung ist deshalb keine Frage von Qualifikationen oder Dienstalter, sondern eine Frage von Einzigartigkeit und Bedeutung in Relation zu den Geschäftsideen des Unternehmens. Eine Aufgabe, die von einem Mitarbeiter aus der Schicht des allgemeinen Fachgebiets ausgeführt wird, kann genauso qualifiziert sein wie jede andere. Die Arbeit in den Kerngeschäftsanwendungsfällen und den unterstützenden Geschäftsanwendungsfällen, in denen geschäftsspezifische Informationssysteme, Produktlinien und andere Typen von Geschäftsinfrastrukturen entwickelt werden, setzen unter Umständen auch geschäftsspezifische Kenntnisse von derselben geschichteten Organisation voraus.

Die Seite Richtlinie: Geschäftssystem enthält ein Beispiel für Geschäftssysteme und ihre Schnittstellen. Obwohl dieses Beispiel die Schichten nicht explizit veranschaulicht, sind die Geschäftssysteme in diesem Beispiel implizit geschichtet.

Eine Erläuterung der Begriffe "Kern", "unterstützend" und "Managementgeschäftsanwendungsfall" finden Sie auf der Seite Technik: Geschäftsanwendungsfallmodell. Schauen Sie sich insbesondere den Abschnitt über die unterschiedlichen Kategorien von Geschäftsanwendungsfällen an.  

Geschäftsanwendungsfälle und Klassen in einem geschichteten Modell

Die Strukturierung der Organisation in Schichten ändert den Geschäftsanwendungsfall nicht, da weiterhin dieselben Ergebnisse produziert werden müssen. Sie hat jedoch Änderungen in den Geschäftsanwendungsfallrealisierungen zur Folge.

Im Gegensatz zu einem nicht geschichteten Geschäftsanalysemodell Analysis Model muss ein geschichtetes Geschäftsanalysemodell mit zwei empfohlenen Einschränkungen im Hinterkopf entwickelt werden:

  • Ein Mitarbeiter in einer bestimmten Schicht nimmt niemals Kontakt mit einem Mitarbeiter einer höheren Schicht auf und bearbeitet auch keine Geschäftsentitäten der höheren Schicht, es sei denn, dies wird explizit von jemandem in der höheren Schicht angefordert. Gleichermaßen sollten Geschäftsereignisse der höheren Schichten nicht an untergeordnete Schichten weitergegeben werden.
  • Ein Mitarbeiter hat seine Zuständigkeiten nur innerhalb seiner eigenen Schicht.

Wenn Sie diese Einschränkungen nicht berücksichtigen, degeneriert die geschichtete Struktur sehr schnell. Beachten Sie, dass diese Einschränkungen für den Fall gelten, wenn sich die meisten allgemeinen Teile des Geschäfts in den unteren Schichten und die spezifischsten (in Bezug auf ein bestimmtes Marktsegment) in den oberen Schichten befinden. In vielen Organisationsdiagrammen ist es im Allgemeinen genau andersherum - dort sind die allgemeinen Teile oben und die spezifischen Teile unten dargestellt.

Wenn Sie Mitarbeiter identifizieren und diesen Aktivitäten zuordnen, müssen Sie die Kenntnisse, die zum Ausführen einer Aktivität erforderlich ist, verstehen. Ein Mitarbeiter aus der Schicht, die Ressourcen für diese bestimmten Kenntnisse organisiert, muss eine Aktivität ausführen, die von der Sache her bestimmte Kenntnisse erfordert. Anstatt möglichst wenig Mitarbeiter einzusetzen, wie es beim Entwurf eine Geschäftsanwendungsfalls als Faustregel gilt, sollten Sie jetzt in jeder Schicht möglichst wenig Mitarbeiter mit möglichst weit gefasstem Zuständigkeitsbereich haben.

Workflows, Mitarbeiter, Geschäftsentitäten und Geschäftsereignisse in unteren Schichten sollten mit Allgemeingültigkeit im Hinterkopf entworfen werden, so dass die bereitgestellten Services sich für die Wiederverwendung in verschiedenen Bereichen eignen. Mitarbeiter und Geschäftsentitäten können entsprechend ihrer Geschäftsspezifik in Geschäftssystemen organisiert werden. Geschäftssysteme, die die allgemeinsten Kompetenzen und Ereignisse enthalten, sind in der unteren Schicht zu finden, und die unternehmensspezifischen Geschäftssysteme in der oberen Schicht.

Kerngeschäftsanwendungsfälle vs. Unterstützende Geschäftsanwendungsfälle

An Geschäftsanwendungsfallrealisierungen sind in unterschiedlichem Maße Mitarbeiter aus unterschiedlichen Schichten beteiligt. Geschäftsanwendungsfallrealisierungen mit einem hohem Maß an Beteiligung aus oberen Schichten (sehr spezifisch) bestimmen das Profil des Unternehmens, implementieren die Geschäftsidee und funktionieren als Profitcenter. Diese entsprechen den Kerngeschäftsanwendungsfällen und den unterstützenden Geschäftsanwendungsfällen, die den Kerngeschäftsanwendungsfällen die wesentliche, geschäftsbereichsspezifische Infrastruktur liefern.

Geschäftsanwendungsfallrealisierungen in unteren Schichten ohne Beteiligung von Mitarbeitern der oberen Schichten stellen allgemeine Services bereit, die erforderlich sind, um das Unternehmen in Gang zu halten. Sie können abstrakt sein und Workflows definieren, die im Rahmen anderer Geschäftsanwendungsfälle ausgeführt werden, z. B. Rechnungsstellungsaktivitäten, die einen Verkaufsgeschäftsanwendungsfall abschließen. Sie können auch konkret und eigenständig sein und Aktivitäten ausführen, die keine geschäftsbereichsspezifische Kompetenz erfordern, z. B. die Buchhaltung. Diese entsprechen normalerweise den unterstützenden Geschäftsanwendungsfällen.

Eine geschichtete Struktur spiegelt die Arten von Kenntnissen wider, die der Schlüssel zu den Geschäftsideen sind, unabhängig davon, ob sie in den Kerngeschäftsanwendungsfällen oder in den unterstützenden Geschäftsanwendungsfällen erforderlich sind, sowie die Kenntnisse, die weniger spezifisch sind. Dies kann ein tauglicher Ausgangspunkt für die systematische Analyse der verfügbaren Unternehmensressourcen sein.

Modelle der gesamten Organisation

Häufig sind Sie nur an detaillierten Informationen über einen oder einige Ihrer Geschäftsprozesse interessiert. Zur Bereitstellung eines Kontextes kann es jedoch ganz praktisch sein, die Geschäftsprozesse vollständig zu identifizieren und jeden kurz zu beschreiben. Dies ergibt ein Modell, das die Kerngeschäftsanwendungsfälle, die unterstützenden Geschäftsanwendungsfälle und die Managementgeschäftsanwendungsfälle enthält. Schauen Sie sich hierzu den Abschnitt zu den unterschiedlichen Kategorien von Geschäftsanwendungsfällen auf der Seite Technik: Geschäftsanwendungsfallmodell an.

Unterstützende Geschäftsanwendungsfälle, z. B. Kerngeschäftsanwendungsfälle, geschäftsspezifische Informationssysteme, Computernetze und Geschäftsräume, sind unter anderem für die Entwicklung und Pflege der Infrastruktur eines Unternehmens zuständig. Aus der Modellierungsperspektive gibt es keinen wirklichen Unterschied zwischen Kerngeschäftsanwendungsfällen und unterstützenden Geschäftsanwendungsfällen. Beide Arten von Geschäftsanwendungsfällen sollten dieselben Anforderungen bezüglich Benutzerfreundlichkeit und Effektivität haben. Für eine erfolgreiche Ausführung können beide Arten von Geschäftsanwendungsfällen dieselben Typen von Ressourcen erfordern.

Ein unterstützender Geschäftsanwendungsfall in einer Organisation, z. B. ein Geschäftsanwendungsfall für die Softwareentwicklung, kann in einer anderen Organisation ein Kerngeschäftsanwendungsfall sein. Der Hauptunterschied besteht darin, für wen die Geschäftsanwendungsfälle arbeiten. Auf Anforderung eines Geschäftseigners entwickeln die unterstützenden Geschäftsanwendungsfälle das Geschäft in Zusammenarbeit mit den betroffenen Geschäftsanwendungsfalleignern und -bedienern. In einem Modell des gesamten Geschäfts ist ein typischer Geschäftsakteur der Vorstand. Wenn die Modellierung auf die unterstützenden Geschäftsanwendungsfälle beschränkt ist, sind typische Geschäftsakteure der Eigner des Geschäftsanwendungsfalls und der Bediener des Geschäftsanwendungsfalls.

Managementgeschäftsanwendungsfälle hingegen sind für die Verwaltung des Geschäfts, d. h. für die Ausführung und die Entwicklung der anderen Geschäftsanwendungsfälle entsprechend den Anweisungen des Eigners, zuständig, um die Kerngeschäftsanwendungsfälle entsprechend den Anweisungen des Eigners einzuleiten und zu überwachen. Das Geschäftsanalysemodell beschreibt, wie Entscheidungsträger, Ressourceneigner, Geschäftsanwendungsfalleigner, Geschäftsanwendungsfallleiter und Geschäftsanwendungsfallbediener miteinander kooperieren müssen. Typische Geschäftsakteure sind der Eigner und der Vorstand.

Modell einer gesamten Organisation

Ein Modell einer gesamten Organisation

Am anderen Ende der Skala stehen viele untergeordnete Aufgaben, um die man sich kümmern muss, z. B. die Wartung des Computernetzes, das Entgegennehmen von Anrufen oder das Reinigen der Kaffeemaschine. Diese Aufgaben sind jedoch nicht Teil eines definierten Geschäftsanwendungsfalls. Wenn Sie Ihr Unternehmen beispielsweise nach dem Standard ISO 9000 zertifizieren möchten, müssen diese Aktivitäten in das Modell aufgenommen werden. Eine unkomplizierte Methode ist die Befolgung der folgenden Faustregel: Wenn es sich um einen Vollzeitjob handelt, ordnen Sie die Aktivität einem bestimmten Mitarbeiter zu. Andernfalls ordnen Sie die Aktivität einem vorhandenen Mitarbeiter mit den entsprechenden Kenntnissen zu, ohne zu versuchen, sie in einen Geschäftsanwendungsfall einzufügen.