Durch die Modellierung von Geschäftsanwendungsfällen und Akteuren soll in erste Linie beschrieben werden, wie das
Geschäft von externen Stellen und insbesondere von seinen Kunden und Partnern verwendet wird. Es können Aufgaben, die
sich direkt auf den Kunden oder Partner beziehen, sowie unterstützende oder verwaltungsorientierte Aufgaben dargestellt
werden, die nur indirekt mit der externen Partei zu tun haben.
Das Modell beschreibt das Geschäft mit Hilfe von Geschäftsanwendungsfällen, die dem entsprechen, was gemeinhin als
"Prozesse" bezeichnet wird.
Akteure und Anwendungsfälle am Check-in-Schalter.
Wenn Sie sich die Aufgaben in einem Geschäft ansehen, können Sie mindestens drei Kategorien von Arbeit ausmachen, die
den drei Kategorien von Geschäftsanwendungsfällen entsprechen:
-
Kern - Hierbei handelt sich um extern orientierte Geschäftsanwendungsfälle, die die Wertschöpfungskette
darstellen, z. B. Produkt kaufen.
-
Management - Hierbei handelt es sich um die internen Geschäftsanwendungsfälle, die die Wertschöpfungskette
koordinieren, z. B. strategische Planung.
-
Unterstützung - Hierbei handelt es sich um interne Geschäftsanwendungsfälle, die die Wertschöpfungskette
unterstützen, z. B. Rohmaterial produzieren.
Wir gehen später auf die Bedeutung und Darstellung der internen Geschäftsanwendungsfälle näher
ein.
Gewöhnlich beschreibt ein Geschäftsanwendungsfall vom Typ Management die Beziehungen zwischen dem Vorstandsvorsitzenden
und den Personen, die in den Geschäftsanwendungsfällen arbeiten. Er beschreibt auch, wie Geschäftsanwendungsfälle
entwickelt und instanziert (gestartet) werden.
In dieser Abbildung in einem Restaurant sind die Kerngeschäftsanwendungsfälle "Marketing" und "Abendessen servieren",
und der unterstützende Geschäftsanwendungsfall ist "Lebensmittel einkaufen".
Beachten Sie, dass ein von Ihnen als Kerngeschäftsanwendungsfall eingestufter Geschäftsanwendungsfall in einem anderen
Geschäft durchaus ein unterstützender Geschäftsanwendungsfall sein kann. Die Softwareentwicklung ist in einem
Softwareentwicklungsunternehmen beispielsweise ein Kerngeschäftsanwendungsfall, würde aber in einer Bank oder in einer
Versicherungsgesellschaft als unterstützender Geschäftsanwendungsfall klassifiziert werden. Viele detaillierte
Geschäftsanwendungsfälle, die bei der Modellierung eines Softwareentwicklungsgeschäfts modelliert werden, gehören für
eine Bank, die ihre eigene Software entwickelt, nicht zu den vorrangigen Geschäftsanwendungsfällen, nicht einmal zu den
unterstützenden Geschäftsanwendungsfällen. Sie können als untergeordnete Anwendungsfälle erscheinen (siehe Konzept: Große Organisationen modellieren). Auf Bankebene würde man nur
unterstützende Anwendungsfälle erwarten, die die Strategie und Ziele der Bank widerspiegeln. Einer
davon könnte heißen 'Geschäftseinheit für Softwareentwicklung betreiben".
Instanzen mehrerer unterschiedlicher Geschäftsanwendungsfälle sowie mehrere Instanzen eines einzelnen
Geschäftsanwendungsfalls werden normalerweise parallel ausgeführt. Es kann eine nahezu unbegrenzte Anzahl von Pfaden
geben, denen eine Anwendungsfallinstanz folgen kann. Diese unterschiedlichen Pfade stellen die Optionen dar, die der
Anwendungsfallinstanz in der Workflowbeschreibung offen stehen. Eine Anwendungsfallinstanz kann ja nach Ereignissen
oder Fakten einen von mehreren möglichen Pfaden verfolgen und dabei von folgenden Faktoren gesteuert werden:
-
Eingabe eines Akteurs
-
einer Geschäftsregel
Bei der Modellierung von Geschäftsanwendungsfällen können Sie davon ausgehen, dass Anwendungsfallinstanzen ohne
Konflikte parallel ausgeführt werden können. In diesem Stadium der Geschäftsentwicklung sollten Sie sich darauf
konzentrieren, was das Geschäft tun soll. Lösen Sie potenzielle Ressourcenkonflikte später, wenn Sie die
Geschäftsanwendungsfallrealisierungen modellieren und dabei versuchen zu verstehen, wie Dinge im Geschäft
funktionieren sollten. Sie können diese Probleme auch während der Implementierung der neuen Organisation lösen, z. B.
durch Erhöhung der Anzahl von Mitarbeitern, die die kritische Aufgabe ausführen können.
Jeder Kerngeschäftsanwendungsfall muss eine gerichtete Kommunikationsbeziehung zu oder von einem Geschäftsakteur haben.
Diese Regel setzt das Ziel um, dass Geschäfte um die Services herum aufgebaut werden, die die Benutzer fordern. Wenn
Ihr Geschäftsanwendungsfallmodell Kerngeschäftsanwendungsfälle hat, die niemand anfordert, sollte dies eine Warnung für
Sie sein, dass mit dem Modell etwas nicht stimmt.
Geschäftsanwendungsfälle können in regelmäßigen Abständen ausgelöst oder über einen längeren Zeitraum hinweg ausgeführt
werden. Ein Beispiel für den letzteren Fall ist eine Überwachungsfunktion. Selbst die Geschäftsanwendungsfälle haben
Geschäftsakteure, die sie einleiten und unterschiedliche Services von ihnen erwarten. Andernfalls wären sie nicht Teil
des Geschäfts. Andere Geschäftsanwendungsfälle produzieren Ergebnisse für einen Geschäftsakteur, obwohl sie nicht
explizit vom Geschäftsakteur eingeleitet werden. Die Entwicklung eines weit verbreiteten Produkts beispielsweise wird
selten von einem identifizierbaren Kunden eingeleitet. Der Bedarf nach einem neuen Produkt ergibt sich vielmehr aus
Marktstudien und den kumulierten Anforderungen vieler Benutzer.
Management- und unterstützende Geschäftsanwendungsfälle (die wir zuvor als interne Geschäftsanwendungsfälle beschrieben
haben) müssen nicht unbedingt mit einem Geschäftsakteur verbunden sein, obwohl auch sie gewöhnlich eine Art von
externem Kontakt haben. Ein Geschäftsanwendungsfall vom Typ Management kann beispielsweise die Geschäftseigentümer oder
den Vorstand als Geschäftsakteur haben.
Ein Geschäftsanwendungsfall ohne einen Akteur scheint in Anbetracht der Tatsache, dass ein 'Anwendungsfall' die
Interaktion von jemandem bzw. etwas mit dem Geschäft repräsentieren und einen Wert darstellen sollte, etwas sonderbar,
aber Sie können diese Klasse von Geschäftsanwendungsfall als (theoretische) Erweiterung von
Geschäftsanwendungsfällen betrachten, die Geschäftsakteure haben. Wir erläutern die Verwendung expliziter Erweiterungen
auf der Seite Richtlinie: Erweiterungsbeziehung im Geschäftsanwendungsfallmodell, aber hier ist der
(erweiterte) Basisgeschäftsanwendungsfall möglicherweise nur konzeptionell und muss deshalb nicht modelliert werden.
Die Management- und unterstützenden Geschäftsanwendungsfälle sind in diesem Fall Erweiterungen des konzeptionellen
Basisanwendungsfalls, die durch durch Bedingungen ausgelöst werden (und in Geschäftsereignissen resultieren), die sich aus der Führung des
Geschäfts ergeben. Diese Denkweise verhindert, dass künstliche Geschäftsakteure eingeführt werden, zwingt Sie aber
dazu, darüber nachzudenken, welchen Mehrwert die Management- und unterstützenden Geschäftsanwendungsfälle bringen.
Abstrakte Geschäftsanwendungsfälle benötigen keinen Geschäftsakteur, weil sie nicht eigenständig instanziert
(gestartet) werden.
Geschäftsprozesse sind das Mittel, mit dem das Geschäft Dinge tut. Da eine direkte Übersetzung der Geschäftsstrategie
in Aktionen sehr schwierig ist, wird etwas anderes benötigt. Dieses Etwas sind die Geschäftsziele, die sicherstellen,
dass Geschäftsprozesse die Geschäftsstrategie umsetzen, indem Aktionen auf allen Ebenen der Organisation in die
Richtung des ultimativen Geschäftsziels - der Geschäftsidee - gelenkt werden.
Aus diesem Grund sollte jeder Geschäftsanwendungsfall mindestens ein Geschäftsziel unterstützen. Die Übersetzung der
Strategie in Ziele auf verschiedenen Ebenen ergibt konkrete, messbare Zielsetzungen, die von Geschäftsprozessen direkt
unterstützt werden können. Durch die Definition von unterstützenden Beziehungen zwischen Zielen und Prozessen wird
gewährleistet, dass die Geschäftsprozesse auf die Geschäftsstrategie ausgerichtet sind. Dies hilft auch, die richtige
Stufe von Geschäftsanwendungsfällen zu finden, die sich häufig nur schwer bestimmen lässt. Ein Geschäftsanwendungsfall
(z. B. Gewinn erwirtschaften) allein, der die strategischen Ziele des Unternehmens direkt unterstützt, wäre zu komplex
und ließe sich nur schlecht als Abfolge von Aufgaben modellieren. Für jede einzelne Aufgabe in der Organisation (z. B.
Telefonanruf weiterleiten oder Konferenzraum buchen) einen gesonderten Geschäftsanwendungsfall zu modellieren, würde zu
zu vielen Geschäftsanwendungsfällen führen und das Verständnis beeinträchtigen. Die Definition der Geschäftsziele, die
von einem Geschäftsanwendungsfall unterstützt werden, weist darauf hin, ob der Geschäftsanwendungsfall "zu hoch" oder
"zu niedrig" ist.
Wenn ein Geschäftsanwendungsfall ein oder mehrere Geschäftsziele direkt unterstützt, wird es einfacher, den Wert des
Geschäftsanwendungsfalls zu quantifizieren. Der Beitrag, den das Ergebnis des Geschäftsanwendungsfalls in Bezug auf das
Ziel darstellt, kann gemessen werden. Die Ausführung des Geschäftsanwendungsfalls kann zur Unterstützung eines
objektiven Vergleichs von Nutzen und Kosten überwacht werden.
Das Vorhandensein dieser Beziehungen hilft, Prioritäten für die Geschäftsanwendungsfälle zu vergeben.
Geschäftsanwendungsfälle, die viele oder wichtige und risikoreiche Geschäftsziele unterstützen, sind wahrscheinlich als
architektonisch relevant einzustufen. Viele Ziele können auch auf eine unnötige Komplexität hinweisen. Wenn ein
Geschäftsanwendungsfall viele unterschiedliche Ziele unterstützt, ist das Auftreten von Konflikten geradezu
vorhersehbar. In diesen Fällen ist es möglicherweise nicht klar, welche Ziele die höhere Priorität haben sollten, und
dies führt zu ineffizienten Aktionen.
Die Kategorie des Geschäftsanwendungsfalls (Kern, unterstützend oder Management) bestimmt nicht direkt die Arten der
unterstützten Geschäftsziele. Die Kategorie dient zwar als Richtlinie, aber die Geschäftsstrategie bestimmt
letztendlich, welche Geschäftszeile ein bestimmter Geschäftsanwendungsfall unterstützt. Ein Geschäftsanwendungsfall
"Produkt vertreiben und verkaufen" kann beispielsweise das Geschäftsziel "Wettbewerbsfähige Preise" für ein Geschäft
mit einer aggressiven Wachstumsstrategie unterstützen. Jahre später möchte dasselbe Geschäft unter Umständen seine
Investitionen in diese Produkte und Märkte erhöhen, indem es auf Kundenzufriedenheit und Kundenbindung abzielt. Der
Geschäftsanwendungsfall "Produkt vertreiben und verkaufen" muss dann unter Umständen das (sehr unterschiedliche)
Geschäftsziel "Höhere Qualität" unterstützen. Weitere Informationen zur Modellierung von Geschäftszielen finden Sie auf
der Seite Richtlinie: Geschäftsziel.
Stellen Sie sich beispielsweise das große Möbelgeschäft vor, das als Beispiel auf der Seite Richtlinie: Geschäftsziel verwendet wird. Ein Geschäftsanwendungsfallmodell für eine
solche Möbelkette könnte wie folgt aussehen:
Der Kunde kann Produkte auswählen, sie in dem an die Verkaufsräume angrenzenden Warenlager abholen und dann bezahlen.
Mangelhafte Produkte können zurückgegeben werden. "Kundenanforderungen identifizieren" ist der Geschäftsanwendungsfall,
der häufig auch als "Marktanalyse" bezeichnet wird. Sobald ein geeignetes Produkt gefunden ist, wird es auf den Markt
gebracht, und der Anbieter wird zum Lieferanten. Der Produktvertrieb muss überwacht werden, obwohl darüber diskutiert
werden kann, ob dies ein separater Geschäftsanwendungsfall (wie in der Abbildung oben) oder Teil der Marktforschung
ist. Wenn wir die beschriebenen Geschäftsanwendungsfälle den auf der Seite Richtlinie:
Geschäftsziel beschriebenen Geschäftszielen zuordnen sollte, könnte sich Folgendes ergeben:
Der Geschäftsanwendungsfall "Geeignetes Produkt finden" unterstützt Geschäftsziele, die ein wenig miteinander in
Konflikt stehen. Es muss klar gemacht werden, wie Kompromisse zwischen Preis und Qualität getroffen werden, um
sicherzustellen, dass beide Geschäftsziele erfüllt werden. Wenn die Produktqualität anhand der Anzahl (oder eines
Prozentsatzes) zurückgegebener mangelhafter Produkte gemessen wird, muss die Mängelursache bestimmt werden, um sie zum
Lieferanten zurückverfolgen zu können. Es könnte beispielsweise sein, dass viele ausgelieferte Produkte vom Kunden
zurückgegeben werden, weil sie durch das Auslieferungsteam beschädigt wurden. Wenn jedoch nur die Anzahl der
Lieferungen gemessen wird, bleibt die Qualität der Lieferungen verborgen.
Der Geschäftsanwendungsfall "Produkt bezahlen" kann "Zahlungsmethode", aber nicht "Niedrige Preise" unterstützen, weil
die Preise im (separaten) Geschäftsanwendungsfall "Geeignetes Produkt finden" bestimmt wird.
In einigen Unternehmen unterstützen einige Geschäftsanwendungsfälle keine Geschäftsziele. Dies kann ein Grund sein, z.
B. "Umsatz überwachen" mit "Kundenanforderungen identifizieren" zusammenzuführen, weil "Umsatz überwachen" direkt keine
Geschäftsziele unterstützt. Eine solche Zusammenführung sollte jedoch nicht zu hastig vorgenommen werden, weil die
fehlende Unterstützung von Geschäftszielen auch ein Hinweis darauf sein kann, dass die Geschäftsziele konkreter
formuliert werden müssen. Im schlimmsten Fall dient "Umsatz überwachen" als Eingabe für "Kundenanforderungen
identifizieren".
Der Geschäftsanwendungsfall "Produkt liefern" unterstützt das Geschäftsziel "Lieferzeit". Kunden sollten nicht zu lange
auf die Lieferung der von ihnen gekauften Produkte warten müssen. Die Überlegung, wie dieses Ziel erreicht werden
könnte, kann radikale neue Ideen hervorbringen. Eine Untergrundbahn könnte das Warenlager mit Häusern in der Stadt
verbinden, und die Produkte könnten mit 100 Km/h durch die Tunnel verschickt werden, so dass sie bereits vor dem Kunden
zu Hause ankommen! Obwohl dies unrealistisch ist, entstehen bei dieser Art von Gedankenaustausch häufig viele Ideen für
die Verbesserung des Geschäfts.
Im Folgenden wird anhand eines Beispiels beschrieben, wie beim Nachdenken über Geschäftsziele die Bedeutung von
scheinbar trivialen Geschäftsanwendungsfällen aufgedeckt wird. Angenommen, der Eindruck entsteht, dass viele Kunden zu
Essenszeiten einkaufen gehen. Da eines der Geschäftsziele die Verbesserung der Qualität von Einrichtungen und ein
anderes das Werben von Kunden ist, könnten wir uns dazu entschließen, ein Restaurant einzurichten, in dem Kunden vor
oder nach dem Einkauf einen Snack einnehmen können. Der Geschäftsanwendungsfall "Mahlzeit einnehmen", der dieses Ziel
unterstützt, wird im Folgenden gezeigt. Es kann sich herausstellen, dass das Restaurant eine der Hauptattraktionen des
Geschäfts wird!
In dem obigen Diagramm sehen wir auch, wie sich die Anpassung der Grenzen des Geschäfts auswirkt. Es wurde ein neuer
Geschäftsakteur "Versender" eingeführt, ein Partner, der für die Entnahme der Produkte aus dem Warenlager und die
Auslieferung an die Kunden verantwortlich ist. Mit diesem Ansatz könnten wir unter Umständen die Lieferzeit verringern
und damit eines unserer Geschäftsziele erreichen.
Es gibt drei Hauptgründe für die Strukturierung des Geschäftsanwendungsfallmodells:
-
Geschäftsanwendungsfälle verständlicher machen
-
Teile von Workflows wiederverwenden, die von mehreren Geschäftsanwendungsfällen genutzt werden
-
Verwaltung des Geschäftsanwendungsfallmodells vereinfachen
Für die Strukturierung der Geschäftsanwendungsfälle stehen drei Arten von Beziehungen zur Verfügung. Sie verwenden
diese Beziehungen, um die Teile von Geschäftsanwendungsfällen herauszufiltern, die in anderen Geschäftsanwendungsfällen
wiederverwendet werden können oder die Spezialisierungen oder Optionen des Geschäftsanwendungsfalls sind. Der
Geschäftsanwendungsfall, der die Änderung darstellt, ist ein so genannter Additionsanwendungsfall. Der
Geschäftsanwendungsfall, der geändert wird, ist der Basisanwendungsfall.
-
Wenn ein Teil eines Basisanwendungsfalls eine Funktion darstellt, deren Ergebnis allein für den
Geschäftsanwendungsfall von Bedeutung ist und nicht die Methode für die Ergebnisherleitung, können Sie diesen Teil
in einen Additionsanwendungsfall extrahieren. Die Addition wird über die Einschlussbeziehung explizit in den
Basisanwendungsfall eingeschlossen. Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Einschlussbeziehung im Geschäftsanwendungsfallmodell.
-
Wenn ein Teil eines Basisanwendungsfalls optional ist oder nicht erforderlich ist, um den primären Zweck des
Anwendungsfalls verstehen zu können, können Sie diesen Teil in einen Additionsanwendungsfall auslagern, um die
Struktur des Basisanwendungsfalls zu vereinfachen. Die Addition wird implizit über die Erweiterungsbeziehung in den
Basisanwendungsfall eingeschlossen. Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Erweiterungsbeziehung im Geschäftsanwendungsfallmodell.
-
Wenn es Geschäftsanwendungsfälle gibt, die Gemeinsamkeiten in Verhalten und Struktur sowie Ähnlichkeiten im Zweck
aufweisen, können diese gemeinsamen Teile in einen Basisanwendungsfall (übergeordnet) ausgelagert werden, der von
Additionsanwendungsfällen (untergeordnet) geerbt wird. Die untergeordneten Anwendungsfälle können in der Struktur,
die sie vom übergeordneten Anwendungsfall erben, neues Verhalten einfügen und vorhandenes Verhalten ändern. Weitere
Informationen hierzu finden Sie auf der Seite Richtlinie: Anwendungsfallgeneralisierung im Geschäftsanwendungsfallmodell.
Die vorherige Abbildung zeigt Akteure und Geschäftsanwendungsfälle und den Check-in-Schalter. Außerdem werden der
Einschlussanwendungsfall "Gepäckabfertigung" und Erweiterungsanwendungsfall "Check-In bis Reiseziel" gezeigt.
Mit Akteurgeneralisierung können Sie zeigen, dass Akteure spezialisierte Versionen eines anderen sein können. Weitere
Informationen hierzu finden Sie auf der Seite Richtlinie: Akteurgeneralisierung im Geschäftsanwendungsfallmodell.
Lesen Sie auch die Beschreibung zur Strukturierung von Systemanwendungsfällen auf der Seite Richtlinie: Anwendungsfallmodell.
Wenn Geschäftsmodelle nur entwickelt werden, um ein Software-Engineering-Projekt in Gang zu bringen, müssen Sie den
Aufwand für die Geschäftsmodellierung besonders sorgfältig begrenzen. In diesem Fall lohnt es sich selten, die gesamte
Organisation abzudecken, selbst wenn Sie nur einen Teil der Geschäftsteile modellieren. Um das Ziel nicht aus den Augen
zu verlieren und Ergebnisse mit dem erwarteten Wert zu produzieren, sollten Sie einen Teil des gesamten Unternehmens
als "Geschäftssystem" betrachten. Der ausgewählte Teil sollte der Teil sein, der das zu erstellende System direkt
verwendet. Die Teile der Organisation, die Sie als extern für das Modell einstufen, können als Geschäftsakteure
dargestellt werden.
Beispiel:
Das Unternehmen hat entschieden, eine neue Anwendung für die Vertriebs- und Auftragsbearbeitung zu erstellen. Um die
Anforderungen der Organisation zu untersuchen und die Art und Weise auszurichten, in der das Geschäft in der
Organisation ausgeführt wird, muss zuerst eine Reihe von Geschäftsmodellen erstellt werden. Die Abteilungen des
Unternehmens, die die neue Auftragsanwendung nicht aktiv verwenden, werden als extern für das Modell eingestuft und
durch Geschäftsakteure dargestellt.
Die vorherige Abbildung zeigt Geschäftsakteure und Geschäftsanwendungsfälle in einem Geschäftsanwendungsfallmodell
einer Auftragsbearbeitungsorganisation. Diese Organisation verkauft komplexe Lösungen, angepasst für jeden Kunden.
Die Geschäftsanwendungsfälle werden im Folgenden kurz beschrieben:
Auftragsprozess - Dieser Prozess beschreibt, wie das Unternehmen die entsprechenden Aktionen ausführt, um einem
Kunden eine Lösung bereitzustellen, die den definierten Kundenanforderungen entspricht. Der Prozess beginnt, wenn die
Geschäftsentscheidung getroffen wird, mit einer abgenommenen Lösung fortzufahren. Häufig erhält das Unternehmen hierbei
eine Bestellung vom Kunden. Der Prozess endet, wenn der Kunde mit der Installation und Inbetriebnahme der Lösung
zufrieden ist und die Zahlung geleistet hat. Die Zielsetzung ist, die Kundenanforderungen auf gewinnbringende Weise zu
erfüllen.
Angebotsprozess - In diesem Prozess werden Angebote als Reaktion auf Kundenanforderungen generiert. Der Prozess
wird durch eine Anfrage vom Kunden ausgelöst und endet, wenn der Kunde die Preise im Angebot akzeptiert (oder ablehnt).
Die Zielsetzung ist, eine Preisvereinbarung zu erzielen, die für den Kunden und das Unternehmen akzeptabel ist.
Preisgestaltungsprozess - Der Preisgestaltungsprozess ist ein abstrakter Geschäftsanwendungsfall, der in den
Angebotsprozess und den Auftragsprozess eingeschlossen ist. Der Prozess beginnt, wenn Kundenanforderungen vorliegen,
für die ein Preis erzeugt werden muss. Die Zielsetzung des Preisgestaltungsprozesses ist, eine Lösung zu erstellen, die
den Kundenanforderungen entspricht, und einen Preis dafür zu nennen.
Eine Übersichtsbeschreibung des Geschäftsanwendungsfallmodells muss
-
den Zweck der Organisation zusammenfassen,
-
die Abgrenzungen des Modells aufzeigen, d. h. Dinge, die nicht eingeschlossen sind und warum,
-
die primären Geschäftsanwendungsfälle spezifizieren.
Beispiel:
Dieses Geschäftsanwendungsfallmodell deckt den Teil unseres Unternehmens ab, der Aufträge von unseren Kunden verwaltet,
da nur dieser Teil für das Software-Engineering-Projekt von Interesse ist, das die Ergebnisse der Geschäftsmodellierung
als Eingabe verwendet. Aus diesem Grund schließen wir die Teile des Unternehmens nicht ein, die sich mit der
Rechnungsstellung, der Fertigung, dem Produktmanagement und der Produktentwicklung beschäftigen. Sie werden als extern
eingestuft und deshalb als Geschäftsakteure dargestellt.
In dieser Organisation umfasst ein Verkauf nicht nur die Einigung über eine Lösung, sondern auch die tatsächliche
Erstellung der Lösung. Um einen Preis für eine Lösung zu definieren, müssen Sie die Lösung bis zu einer gewissen
Detaillierungsebene entwickeln und erstellen. Dies geschieht im Angebotsprozess. Sobald eine Einigung mit dem Kunden
erzielt wurde, wird die Lösung in allen Details entwickelt und beim Kunden installiert. Dies wird im Auftragsprozess
beschrieben. Angebotsprozess und Auftragsprozess schließen den abstrakten Geschäftsanwendungsfall
Preisgestaltungsprozess ein.
-
Geschäftsanwendungsfälle sind an der Geschäftsstrategie ausgerichtet, die durch konkrete Geschäftsziele beschrieben
ist.
-
Anwendungsfälle entsprechen dem Geschäft, das sie beschreiben.
-
Es wurden alle Anwendungsfälle gefunden. Alle Anwendungsfälle zusammen führen die Aufgaben innerhalb des Geschäfts
aus.
-
Jede Aufgabe innerhalb des Geschäfts müssen in mindestens einem Anwendungsfall eingeschlossen sein.
-
Die Anzahl und die Größe der Geschäftsanwendungsfälle ist ausgewogen.
-
Weniger Anwendungsfälle machen das Modell verständlicher.
-
Viele Anwendungsfälle können die Verständlichkeit des Modells beeinträchtigen.
-
Große Anwendungsfälle können komplex und schwer zu verstehen sein.
-
Kleine Anwendungsfälle sind häufig einfach zu verstehen. Stellen Sie jedoch sicher, dass der Anwendungsfall
einen vollständigen Workflow beschreibt, der etwas von Wert für einen Kunden produziert.
-
Jeder Anwendungsfall muss eindeutig sein. Wenn der Workflow identisch mit einem anderen Anwendungsfall ist oder
Ähnlichkeiten aufweist, ist es schwierig, sie später zu synchronisieren. Überlegen Sie, ob sie die beiden Workflows
zu einem Anwendungsfall zusammenführen können.
-
Die Übersichtsbeschreibung des Geschäftsanwendungsfallmodells sollte ein aussagefähiges und umfassendes Bild der
Organisation liefern.
|