Die Prozesse eines Geschäfts
werden in Form mehrerer Geschäftsanwendungsfälle definiert, von denen jeder einen bestimmten Workflow im Geschäft
darstellt. Ein Geschäftsanwendungsfall definiert, was bei der Ausführung im Geschäft passieren soll. Er beschreibt den
Ablauf von Aktionen, die ein Ergebnis produzieren, das für einen bestimmten Geschäftsakteur von Nutzen ist. Ein
Geschäftsprozess erzeugt einen Wert für das Geschäft oder mindert die Kosten für das Geschäft.
Ein Passagier kann individuell oder in einer Gruppe reisen. Wenn er in einer Gruppe reist, wird der Passagier von einem
Reiseleiter begleitet.
Ein Geschäftsanwendungsfall beschreibt "eine Abfolge von Aktionen, die in einem Geschäft ausgeführt werden und ein
Ergebnis von erkennbarem Wert für einen einzelnen Akteur des Geschäfts erzeugen". Deshalb definiert ein
Geschäftsanwendungsfall aus der Perspektive eines einzelnen Akteurs den vollständigen Workflow, der die gewünschten
Ergebnisse produziert. Ein "Geschäftsprozess" ist zwar sehr ähnlich, aber ein "Geschäftsanwendungsfall" hat eine
präzisere Definition.
Die Definition des Geschäftsanwendungsfallkonzepts enthält eine Reihe von Schlüsselwörtern, die für das Verständnis
eines Geschäftsanwendungsfalls von Bedeutung sind:
-
Geschäftsanwendungsfallinstanz: Die obige Definition beschreibt eigentlich einen bestimmten Geschäfts-Workflow, d.
h. eine Instanz. In Wirklichkeit gibt es eine Vielzahl möglicher Workflows, von denen viele sehr ähnlich sind.
Zur besseren Verständlichkeit des Anwendungsfallmodells werden ähnliche Workflows in einem Geschäftsanwendungsfall
gruppiert. Im Objektmodell werden diese Gruppierungen "Klassen" genannt. Die Identifizierung und Beschreibung eines
Geschäftsanwendungsfalls bedeuten, dass der klassenähnliche Geschäftsanwendungsfall und nicht die einzelnen
Anwendungsfallinstanzen identifiziert und beschrieben werden. Ein Geschäftsanwendungsfall definiert somit
Entscheidungspunkte und alternative Abläufe. Welcher Pfad gewählt wird, richtet sich nach dem Zustand des
Geschäfts, den Geschäftsereignissen und der Eingabe des Geschäftsakteurs.
-
Einzelner Akteur: Der Akteur ist wahrscheinlich der eigentliche Schlüssel für die Identifizierung der richtigen
Geschäftsanwendungsfälle. Wenn Sie mit einzelnen Akteuren (eigentlich Instanzen von Akteuren) beginnen, verhindern
Sie, dass die Geschäftsanwendungsfälle zu groß oder zu komplex werden.
Wenn Sie die geeigneten Akteure bestimmen, versuchen Sie zunächst, mindestens zwei oder drei unterschiedliche
Personen zu benennen, die die Rolle des fraglichen Akteurs übernehmen könnten. Werten Sie dann kritisch die
Unterstützung aus, die jeder einzelne Akteur benötigt. Angenommen, Sie identifizieren einen Akteur "Kunde". Wenn
sich dann eingehender mit der Unterstützung beschäftigen, die jeder einzelne Kunde benötigt, finden Sie
möglicherweise drei ziemlich unterschiedliche Kunden: den normalen "Benutzer" des Produkts, den "Käufer" und den
"Gutachter", der in der Lage ist, das Produkt mit den Konkurrenzprodukten zu vergleichen. Jeder dieser Akteure kann
einen eigenen Geschäftsanwendungsfall erfordern, weil sie unterschiedliche Rollen im Geschäft darstellen.
-
Ergebnis mit erkennbarem Wert: Dieser Ausdruck ist sehr wichtig, um den richtigen Umfang eines
Geschäftsanwendungsfalls zu bestimmen. Ein Geschäftsanwendungsfall sollte weder zu klein noch zu groß sein. Die
Vorgabe, dass der Geschäftsanwendungsfall ein Ergebnis mit erkennbarem Wert erzeugen muss (wahrnehmbar und
messbar), hilft Ihnen, einen vollständigen Ablauf zu finden und zu kleine Geschäftsanwendungsfälle zu vermeiden.
Ein tauglicher Geschäftsanwendungsfall hilft einem Akteur, eine Aufgabe auszuführen, die einen feststellbaren Wert
hat. Ein erfolgreich ausgeführter Geschäftsanwendungsfall kann in Zahlen ausgedrückt werden. Ein zu kleiner
Geschäftsanwendungsfall hat einen sehr begrenzten Umfang und damit auch wenig Potenzial für Umstrukturierung.
-
In einem Geschäft bedeuten die Wörter "Aktionen, die in einem Geschäft ausgeführt werden", dass das Geschäft dem
Akteur den Geschäftsanwendungsfall bereitstellt und dass der Geschäftsanwendungsfall nur das abdeckt, was wirklich
innerhalb des Geschäfts getan wird. Unterstützende Arbeit, die an anderer Stelle ausgeführt wird, ist nicht
enthalten.
-
Aktion - Die Aktionen werden auf Anforderung eines Akteurs des Geschäfts oder zu einem bestimmten Zeitpunkt
aufgerufen. Zu Aktionen gehören interne Aufgaben und Entscheidungen sowie alle Anforderungen an den aufgerufenen
Akteur oder andere Akteure.
Geschäftsanwendungsfälle spezifizieren die Interaktionen zwischen dem betreffenden Geschäft und seinen (externen)
Geschäftsakteuren und die Auswirkungen, die sie auf das Geschäft haben. Die Ausführung eines
Geschäftsanwendungsfalls kann kann den Zustand des Geschäfts ändern (und damit die Art und Weise, in der das Geschäft
auf künftige Ereignisse und Interaktionen reagiert). Diese Zustandsänderungen müssen im Geschäftsanwendungsfall
spezifiziert werden.
Es das Geschäft direkt oder explizit für seine Umgebung bereitstellt, sind Services (das Geschäft aus dieser
Perspektive ist einfach das Geschäftssystem der Ausgangsebene und sollte deshalb seine Ressourcen beinhalten und klar
definierte Services für seine Umgebung bereitstellen - siehe Richtlinie:
Geschäftssystem). Die Interaktion zwischen dem Geschäftsakteur und dem Geschäft, die im Geschäftsanwendungsfall
beschrieben ist, findet über den Aufruf einer oder mehrerer dieser Services statt. Wenn ein neues Geschäft entwickelt
wird (z. B. Geschäftsprozessmodellierung) oder wenn das Geschäft geändert wird, sind
Geschäftsanwendungsfälle eine Möglichkeit, die Services zu identifizieren, die das Geschäft unterstützen muss.
Die zusammengestellten Geschäftsanwendungsfälle sind alles Wege zur möglichen Verwendung des Geschäfts. Weitere
Informationen hierzu finden Sie auf der Seite Richtlinie: Geschäftsanwendungsfallmodell.
In einem anwendungsfallgesteuerten Geschäftsmodellierungsprojekt entwickeln Sie zwei Sichten des Geschäfts.
Der Geschäftsanwendungsfall selbst stellt eine externe Sicht des Geschäfts dar, die definiert, was ausgeführt
werden muss, damit das Geschäft dem Akteur die gewünschten Ergebnisse liefern kann. Sie definiert auch, welche
Interaktionen (den Ablauf Geschäftsakteur-Geschäftseingabe-Antwort) das Geschäft mit den Akteuren haben muss, wenn der
Geschäftsanwendungsfall ausgeführt wird. Eine solche Sicht muss entwickelt werden, wenn Sie Entscheidungen und
Vereinbarungen darüber treffen, was in jedem einzelnen Geschäftsanwendungsfall ausgeführt wird. Eine Zusammenstellung
von Geschäftsanwendungsfällen gibt einen Überblick über das Geschäft und ist ein hilfreiches Mittel, um die Mitarbeiter
über die verschiedenen Teile des Geschäfts und die erwarteten Ergebnisse zu informieren. Eine
Geschäftsanwendungsfallbeschreibung tut dies, ohne auf die eigentliche interne Struktur des Geschäfts zu verweisen. Der
Geschäftsanwendungsfall sollte außerdem alle Zustandsänderungen im Geschäft beschreiben, die eintreten, wenn der
Geschäftsanwendungsfall ausgeführt wird, sowie alle wichtigen Geschäftsereignisse, die ausgelöst oder empfangen werden.
Der Geschäftsanwendungsfall schreibt nicht vor, wie der Geschäftszustand hergestellt und intern verwaltet wird oder wie
Geschäftsereignisse intern kommuniziert werden. Er spezifiziert jedoch, was die Zustandsänderungen und
was die wichtigen Geschäftsereignisse sind, um eine vollständige Sicht des erforderlichen
Geschäftsverhaltens zu präsentieren.
Eine Geschäftsanwendungsfallrealisierung ist eine interne Sicht des Geschäftsanwendungsfalls, die definiert, wie
die Arbeit organisiert und ausgeführt werden muss, um dieselben gewünschten Ergebnisse zu erzielen. Eine Realisierung
umfasst die Mitarbeiter (Rollen) und Geschäftsentitäten, die an der Ausführung eines Geschäftsanwendungsfalls beteiligt
sind, und die Beziehungen zwischen diesen, die erforderlich sind, um den Job auszuüben. Solche Sichten müssen
entwickelt werden, um Entscheidungen und Vereinbarungen darüber zu treffen, wie die Arbeit in jedem einzelnen
Geschäftsanwendungsfall organisiert werden muss, um die gewünschten Ergebnisse zu erzielen. Der Geschäftsdesigner
stellt sicher, dass konsistente Zuordnungen zwischen der Spezifikation (dem Was) im
Geschäftsanwendungsfall und der Realisierung (dem Wie) in der Geschäftsanwendungsfallrealisierung für
die Geschäftzustandsänderungen und Geschäftsereignisse verwendet werden, um das gewünschte Verhalten in allen
Geschäftsanwendungsfällen zu erzielen.
Beide Sichten der Geschäftsanwendungsfälle sind primär für die Personen innerhalb des Geschäfts bestimmt, die externe
Sicht für Personen, die außerhalb des Geschäftsanwendungsfalls arbeiten, die interne Sicht für Personen, die innerhalb
des Geschäftsanwendungsfalls arbeiten.
Während des Geschäftsbetriebs werden Sie feststellen, dass Sie eine nahezu unbegrenzte Anzahl unterschiedlicher
Workflows identifizieren können. Eine Anwendungsfallinstanz ist einfach ein spezifischer Workflow oder ein Szenario.
Sie entspricht der Arbeit, die eine Reihe kollaborierender Geschäftsmitarbeiter in ihren im Objektmodell definierten
Rollen ausführen, und nicht einem bestimmten Geschäftsmitarbeiter oder einer Rolle, die der Mitarbeiter einnimmt.
Normalerweise arbeiten Sie mit einem Geschäftsanwendungsfall, um das Anwendungsfallmodell verständlich zu machen und um
zu verhindern, sich in Details zu verlieren. Der Geschäftsanwendungsfall stellt den Zusammenschluss von
Geschäftsanwendungsfallinstanzen mit ähnlichen, aber normalerweise nicht identischen Workflows dar.
Ein Mitarbeiter, der kompetent ist, in einer bestimmten Rolle aufzutreten, tut dies gewöhnlich in Instanzen
unterschiedlicher Geschäftsanwendungsfälle.
Beispiel:
Am Check-in-Schalter am Flughafen erwarten die beiden Geschäftsanwendungsfälle "Einzel-Check-in" und "Gruppen-Check-in"
dieselben Kompetenzen vom Mitarbeiter am Schalter und Zugriff auf dieselben Informationen über einen bestimmten Abflug.
Somit können und müssen beiden Anwendungsfälle mit demselben Mitarbeiter (Rolle) "Check-in-Agent" und derselben Entität
"Abflug" entworfen werden.
Manchmal ist es schwierig zu entscheiden, ob ein Service einen oder mehrere Geschäftsanwendungsfälle umfasst. Wenden
Sie die Definition eines Geschäftsanwendungsfalls auf den Check-in-Prozess am Flughafen an. Ein Passagier händigt sein
Ticket und sein Gepäck dem Check-in-Agenten aus, der einen Platz für den Passagier sucht, die Bordkarte druckt und mit
der Gepäckabfertigung beginnt. Wenn der Passagier normales Gepäck hat, druckt der Check-in-Agent einen Gepäckaufkleber
und einen Abholschein und beendet den Geschäftsanwendungsfall, indem er den Aufkleber auf dem Gepäck aufbringt, dem
Passagier den Abholschein zusammen mit der Bordkarte aushändigt. Wenn das Gepäck eine Sondergröße oder speziellen
Inhalt hat, so dass es nicht auf normalem Wege transportiert werden kann, muss der Passagier es zu einem speziellen
Gepäckschalter bringen. Wenn das Gepäck schwer ist, muss der Passagier zum Ticketbüro im Flughafen gehen und dafür
bezahlen, da Check-in-Agenten normalerweise kein Geld annehmen.
Benötigen Sie jetzt einen Geschäftsanwendungsfall am Check-in-Schalter, einen weiteren am Schalter für Sondergepäck und
einen dritten im Ticketbüro? Oder benötigen Sie nur einen einzigen Geschäftsanwendungsfall? Sicherlich beinhaltet diese
Transaktion drei unterschiedliche Typen von Aktionen. Die Frage ist jedoch, ob irgendeine dieser Aktionen einen Wert
für den Passagier darstellt, der Sondergepäck hat, wenn er die anderen nicht ausführt? Nein, Wert hat nur die
vollständige Prozedur, von dem Moment an, zu dem der Passagier an den Check-in-Schalter tritt, bis zu dem Zeitpunkt, zu
dem er die Sondergebühr bezahlt hat. Nur das macht für den Passagier Sinn. Somit ist die vollständige Prozedur mit
allen drei Schaltern ein vollständiger Geschäftsanwendungsfall.
Zusätzlich zu diesen Kriterien ist es praktisch, Beschreibungen eng miteinander verbundener Services zusammenzuhalten,
so dass Sie sie zur selben Zeit prüfen, zusammen ändern, zusammen testen, Handbücher für sie schreiben und sie generell
als Einheit verwalten können.
Beachten Sie auch, dass zwei voneinander unabhängige Geschäftsanwendungsfälle ähnliche Anfänge haben können.
Beispiel:
In einer Versicherungsgesellschaft beginnen die beiden Geschäftsanwendungsfälle "Schadenfall bearbeiten" und
"Anforderung bearbeiten", wenn irgendjemand (ein Akteur) Kontakt mit einem Sachbearbeiter für Schadenfälle aufnimmt.
Der Sachbearbeiter für Schadenfälle und der Akteur tauschen Informationen aus, um sicherzustellen, ob der Akteur einen
Schaden meldet oder Informationen anfordert. Erst dann und nur dann ist es möglich zu entscheiden, welcher
Geschäftsanwendungsfall ausgeführt wird. Obwohl die beiden Geschäftsanwendungsfälle einen ähnlichen Anfang haben, sind
sie nicht miteinander verbunden.
Der Name des Geschäftsanwendungsfalls muss Aufschluss darüber geben, was passiert, wenn eine Instanz des
Geschäftsanwendungsfalls ausgeführt wird. Das Format des Namens sollte deshalb aktiv sein und, wenn möglich, mit der
Infinitivform eines Verbs (Einchecken) oder einer Kombination aus Substantiv und Verb beschrieben werden.
Die Namen können die Aufgaben im Geschäftsanwendungsfall von einem externen oder internen Blickpunkt aus beschreiben,
z. B. einen Auftrag erteilen oder einen Auftrag erhalten. Obwohl ein Geschäftsanwendungsfall beschreibt, was im
Geschäft passiert, geschieht es häufig ganz instinktiv, dass der Geschäftsanwendungsfall aus der Sicht des primären
Akteurs benannt wird. Nachdem Sie eine Entscheidung bezüglich des bevorzugten Stils in Ihrem Fall getroffen haben,
sollten Sie dieser Regel für alle Geschäftsanwendungsfälle im Geschäftsmodell folgen.
Das Ziel eines Geschäftsanwendungsfalls sollte aus mindestens zwei Perspektiven formuliert werden:
-
Für die Geschäftsakteure, mit denen der Geschäftsprozess interagiert, geben Sie den Wert an, den diese
Geschäftsakteure vom Geschäft erwarten (externe Ziele).
-
Aus der Perspektive der Organisation, die die Geschäftsprozesse ausführt, definieren Sie, welche Zielsetzungen Sie
mit dem Einsatz dieses Geschäftsprozesses verfolgen und was Sie hoffen zu erreichen, indem Sie diesen Prozess
ausführen (interne Ziele).
Im Folgenden sind einige allgemeine Metrikkategorien beschrieben:
-
Zeit - Ein ungefährer Wert für die erwartete Dauer des Worfklows bzw. eines Teils des Workflows.
-
Kosten - Die ungefähren Kosten für die Ausführung des Workflows oder eines Teils des Workflows.
-
Qualität - z. B. "nicht mehr als 2 % der Produkte dürfen mangelhaft sein, wenn sie die Fertigungslinie verlassen".
Eine Hauptanforderung ist zu verstehen, welche Szenarios (Geschäftsanwendungsfallinstanzen) wichtig zu messen sind. Die
zu verwendenden Kriterien sind Häufigkeit des Szenarios oder Geschäftsrelevanz des Szenarios. Wenn Sie feststellen
können, dass ein bestimmter Teil des Workflows von Bedeutung ist, können Sie sich Aufwand ersparen, indem Sie nur die
Kosten oder die Zeit für diesen untergeordneten Ablauf messen.
Die meisten Workflows setzen sich aus mehreren untergeordneten Abläufen zusammen, die zusammen den gesamten Workflow
ergeben. Manchmal haben mehrere Geschäftsanwendungsfälle im Geschäft einen gemeinsamen untergeordneten Ablauf, oder
derselbe untergeordnete Ablauf erscheint in unterschiedlichen Teilen eines Geschäftsanwendungsfalls. Wenn dieses
gemeinsame Verhalten sehr umfangreich ist, sollte es von denselben Mitarbeitern ausgeführt werden.
Wenn ein untergeordneter Ablauf umfangreich ist, mehreren Geschäftsanwendungsfällen gemein ist und außerdem einen
unabhängigen und natürlich begrenzten Teil darstellt, kann das Modell transparenter werden, wenn dieses Verhalten in
einen separaten Geschäftsanwendungsfall ausgelagert wird. Dieser neue Geschäftsanwendungsfall wird dann entweder in den
ursprünglichen Geschäftsanwendungsfall eingebunden (siehe Richtlinie: Einschlussbeziehung im Geschäftsanwendungsfallmodell), oder er ist eine
Erweiterung des ursprünglichen Geschäftsanwendungsfalls (siehe Richtlinie: Erweiterungsbeziehung im Geschäftsanwendungsfallmodell) oder ein
übergeordneter Anwendungsfall des ursprünglichen Geschäftsanwendungsfalls (siehe Richtlinie: Anwendungsfallgeneralisierung im Geschäftsanwendungsfallmodell).
Beispiel:
Am Check-in-Schalter des Flughafens verwenden die beiden Geschäftsanwendungsfälle "Einzel-Check-in" und
"Gruppen-Check-in" dieselbe Prozedur für die Abfertigung des Gepäcks eines einzelnen Passagiers. Da der untergeordnete
Ablauf von der Ticketbearbeitung unabhängig, aber logisch mit dieser verbunden ist, wird er gesondert im
Geschäftsanwendungsfall "Gepäckabfertigung" modelliert.
Der Workflow eines Geschäftsanwendungsfalls kann mit Aktivitätsdiagrammen visualisiert werden. Informationen hierzu
finden Sie auf der Seite Richtlinie: Aktivitätsdiagramm im Geschäftsanwendungsfallmodell.
Weitere Informationen zum Strukturieren und Beschreiben des Workflows eines Geschäftsanwendungsfalls finden Sie auf der
Seite Richtlinie: Anwendungsfall im Abschnitt über Ereignisabläufe.
Im Folgenden wird der Workflow des Geschäftsanwendungsfalls "Angebotsprozess" in einer Organisation beschrieben, die
individuell für Kunden konfigurierte Lösungen verkauft. Auf der Seite Technik: Aktivitätsdiagramme im Geschäftsanwendungsfallmodell finden Sie im
Abschnitt "Verwendungsbeispiele" ein Beispiel für ein Aktivitätsdiagramm, das die Struktur dieses Workflows
visualisiert:
1. Basisworkflow
1.1. Erstkontakt
Dieser Prozess beginnt mit einem Erstkontakt zwischen dem Kunden und dem Unternehmen. Der Erstkontakt kann wie folgt
aussehen:
-
Der Kunde wendet sich mit einer Anfrage oder eine Reihe von Anforderungen an das Unternehmen.
-
Das Unternehmen entscheidet, dass es Produkte hat, die dem Kunden von Nutzen sind und einen Umsatz für das
Unternehmen bedeuten.
Das Unternehmen interagiert mit dem Kunden, um Folgende Punkte zu klären:
-
Kontaktperson beim Kunden
-
Kontaktperson beim Unternehmen
-
Handelt es sich um einen neuen Kunden?
-
Wettbewerberinformationen zur Angebotssituation im Umfeld dieser Vereinbarung
1.2. Erste Arbeiten bei Verkaufschance
Dieser Abschnitt erfüllt zwei wesentliche Aufgaben:
-
Erfassung der Kundenanforderungen
-
Entscheidung bezüglich weiterer Aktionen zu dieser Verkaufschance.
Die Schritte "Vorläufige Kundenanforderungen erfassen", "Absatzplan erstellen" (optional) und "Analyse der
Verkaufschance durchführen" können iterativ und bis zu einem gewissen Grad parallel ausgeführt werden.
1.2.1 Vorläufige Kundenanforderungen erfassen
Produktanforderungen und Geschäftsanforderungen des Kunden können wie folgt zusammengetragen werden:
-
Sie können den Kunden fragen.
-
Sie können sich das Kundenfeedback ansehen.
-
Sie können eine vorläufige Standortübersicht erstellen (optional).
-
Sie können sich die verfügbaren Kundeninformationen ansehen.
Ein vollständiger Satz von Anforderungen enthält Folgendes:
-
Ausgewählte Technologie (es können auch mehrere sein, wenn der Kunde die Untersuchung alternativer Technologien
fordert)
-
Produktpräferenzen
-
Funktionale Anforderungen (Marktanalyse)
-
Gebäudestruktur und Angaben zur Betriebsumgebung
-
Demographie
-
Mobilität/Kapazität
-
Vorhersage zum Netzwachstum
-
Installierte Basisinformationen
-
Zeitachsen
-
Serviceanforderungen
-
Preisanforderungen
1.2.2 Absatzplan erstellen (optional)
Das Unternehmen bestimmt zusammen mit dem Kunden, wie es eine Lösung anbieten soll, die den Anforderungen des Kunden
entspricht. Dies wird als Absatzplan bezeichnet. Ein Absatzplan enthält die Netzwerk- und Weichenmerkmale für die
potenzielle Lösung. Die strategische Positionierung des Unternehmens und seines Netzwerks wird zur Vorbereitung auf
künftige Anforderungen ebenfalls beschrieben.
Dieser Absatzplan wird dann zusammen mit dem Kunden auf Genauigkeit und Vollständigkeit geprüft. Anschließend wird er
während des gesamten Angebotsprozesses als Anleitung verwendet, wenn entschieden werden muss, welche Produkte,
Marktpakete und Einzelposten angeboten werden und welche Annahmen bei der Zusammenstellung des Angebots getroffen
werden müssen.
1.2.3 Analyse der Verkaufschance durchführen
Das Unternehmen ermittelt den Endpreis und die Kosten für die potenzielle Lösung. Dies geschieht, um den potenziellen
Wert der Verkaufschance zu begreifen, und nicht, um einem Kunden einen genauen Betrag zu nennen.
Das Unternehmen sieht sich dann die Kundenanforderungen an, um Folgendes zu bestimmen:
-
Risiken der Verkaufschance (Produktverfügbarkeit, Konkurrenz, Kundenrisiko)
-
Kosten, verglichen mit dem Ertrag
-
Typ der Verkaufschance (einfach, komplex usw.)
-
Wahrscheinlichkeit von Absätzen
-
Erwartete Absatzzahlen
-
Geschätzter Zeitplan
Basierend auf dieser Auswertung trifft das Unternehmen eine Entscheidung darüber, ob die Verkaufschance weiter verfolgt
wird.
1.3. Projektplan für Angebot erstellen
Das Unternehmen erstellt einen Plan für das Erstellen und Einreichen des Angebots. Der Plan enthält die Zuordnungen zu
den Einzelpersonen, die die Teile des Angebots fertig stellen.
1.4. Projektplan für Bereitstellung erstellen
Das Unternehmen entwickelt einen vorläufigen Projektplan für die Bereitstellung der Lösung auf der Basis folgender
Punkte:
-
Zeitachsen in den Kundenanforderungen
-
Ressourcenverfügbarkeit
-
Fertigungskapazität
-
Verfügbarkeit neuer Produkte
-
Verfügbarkeit von Fremdanbieterprodukten
Dieser Projektplan wird für die künftige Fertigungsplanung verwendet.
Außerdem wird dieser Projektplan während des Angebotsprozesses aktualisiert und modifiziert.
1.5. Preisgestaltung vorbereiten
Dieser Ablauf wird detailliert im eingeschlossenen Geschäftsanwendungsfall "Angebotsprozess" beschrieben.
Das Ergebnis des Angebotsprozesses ist eine konstruierte Lösung mit einem Preis, die verschiedene
Verbindlichkeitsgrade haben kann.
1.6. Zusätzliche Informationen zusammentragen
Das Unternehmen trägt Informationen zusammen, um auf Anfragen (die sich gewöhnlich auf die künftige Entwicklung von
Produkten beziehen) reagieren zu können, die Teil der Geschäftsanforderungen des Kunden sein können. Dazu können auch
Informationen gehören, von denen das Unternehmen glaubt, dass sie wichtig für den Kunden sind. Die Anfragetypen sind im
Allgemeinen wie folgt:
-
derzeitige Kapazität
-
künftige Kapazität
-
Konformität mit Standards
-
Konformität mit künftigen Standards
-
derzeit angebotene Services
-
künftig angebotene Services
1.7. Angebot analysieren und fertig stellen
Das Unternehmen stellt ein Angebot zusammen, das die folgenden Elemente enthält:
-
Preis(e)
-
Vertriebsliteratur (handelsüblich)
-
Produktinformationen (handelsüblich)
-
Finanzierungsbedingungen
-
Planungsinformationen
-
Für die Angebotsebene zusammengefasste Finanzanalyse
-
Vertragsstrafen und Verbindlichkeiten von Kunde und Unternehmen
-
Gültige Umweltschutzbedingungen
-
Annahmen, die beim Erstellen der Lösungen im Angebot getroffen wurden
1.8. Angebot präsentieren
Das Unternehmen präsentiert dem Kunden die zuvor beschriebenen Informationen.
1.9. Kundenentscheidung
Der Kunde gibt Rückmeldungen zum Angebot. Das Unternehmen erhält die Zusage des Kunden zu den im Angebot genannten
Preisen. Eine solche Zusage kann je nach Art der Lösung und Kunden in verschiedenen Formen erfolgen,
z. B.:
-
unterzeichnete Bestellung
-
mündliche Zusage des Kunden, dass er eine Bestellung schickt
-
unterzeichneter Vertrag
-
mündliche Zusage
-
(Es kommt zu einer negativen Entscheidung, wenn der Kunde keine Entscheidung trifft und die Gültigkeit des Angebots
verfällt.)
2. Alternative Workflows
2.1. Geschäftschance abgelehnt
Wenn sich unter 1.2. herausstellt, dass die Geschäftschance abgelehnt wird, können die folgenden Aktionen ausgeführt
werden:
-
vollständige Ablehnung
-
Versuch eines Joint Venture mit einem anderen Lieferanten
-
Umleitung an einen anderen Bereich
-
Übergabe der Anforderung an einen anderen Distributor/Lieferanten
-
Versuch, die Kundenanforderung zu ändern
2.2. Kundenanforderungen können nicht erfüllt werden
Wenn das Unternehmen in "Analyse der Verkaufschance durchführen" oder "Preisgestaltung vorbereiten" nicht in der Lage
ist, eine Lösung für die Kundenanforderungen vorzuschlagen, können die folgenden Aktionen ausgeführt werden:
-
Geräte eines anderen Herstellers vorschlagen
-
Kundenanforderungen erneut auswerten
-
Kontakt mit dem Unternehmen aufnehmen, um Informationen zu künftigen Produkten zu erhalten
-
Versuch, die Kundenanforderung zu ändern
-
Entscheidung treffen, neue Produkte zu entwickeln
-
Joint Venture oder Lieferanten suchen
-
Alternative Formen der Finanzierung suchen
-
Andere Rabattpolitik anwenden
2.3. Kritische Informationen nicht bekannt
Wenn das Unternehmen zu irgendeinem Zeitpunkt des Angebotsprozesses feststellt, dass einige kritische Informationen
nicht bekannt oder nicht verfügbar sind, geht es wie folgt vor:
-
Es beschafft sich die Informationen oder
-
es trifft Annahmen und setzt den Prozess fort.
Wenn Annahmen getroffen werden, werden diese protokolliert und dem Kunden in einem Anhang zum Angebot ausgehändigt.
2.4. Neues/unvollständiges allgemeines Kundenprofil
Wenn das Unternehmen feststellt, dass das allgemeine Kundenprofil aus irgendeinem Grund nicht genau ist, können die
folgenden Aktionen ausgeführt werden:
-
Wenn der Kunde neu ist, eine Vereinbarung treffen.
-
Kundenpräferenzen berücksichtigen/bestimmen.
-
Installierte Basis bestimmen.
-
Aktualisierung der Datensätze anfordern.
Die Möglichkeiten eines Geschäftsanwendungsfalls sollten das Verbesserungspotenzial widerspiegeln, das Sie für den
Geschäftsanwendungsfall. Dies gilt für die Position im Prozess sowie den Umfang. Nehmen Sie Bezug auf die Metriken, die
Sie für den Geschäftsanwendungsfall definiert haben.
Ein Erweiterungspunkt ist eine Möglichkeit, einen Geschäftsanwendungsfall zu erweitern. Er hat einen Namen und
eine Liste von Referenzen auf eine oder mehrere Positionen im Workflow des Geschäftsanwendungsfalls.
Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Erweiterungsbeziehung im Geschäftsanwendungsfallmodell.
-
Name und Kurzbeschreibung des Geschäftsanwendungsfalls sind klar und einfach zu verstehen, selbst für Personen
außerhalb des Geschäftsmodellierungsteams.
-
Jeder Geschäftsanwendungsfall ist aus externe (Akteur-) Perspektive heraus vollständig. Der Geschäftsanwendungsfall
"Schadenfall bearbeiten" in einer Versicherungsgesellschaft beginnt beispielsweise damit, dass ein Kunde einen
Schadenfall meldet. Der Geschäftsanwendungsfall "Schadenfall bearbeiten" ist erst dann vollständig, wenn er eine
Benachrichtigung über die Entscheidung der Versicherungsgesellschaft an den Kunden und (bei positiven Ausgang) und
Zahlungsüberweisung enthält.
-
An jedem Geschäftsanwendungsfall ist gewöhnlich mindestens ein Akteur beteiligt. Geschäftsanwendungsfälle werden
von Akteuren eingeleitet, interagieren zum Ausführen der Aufgaben mit Akteuren und stellen Ergebnisse bereit.
-
Es ist zwar möglich, aber ungewöhnlich, dass ein unterstützender Anwendungsfall nicht mit einem Akteur
interagiert*. Dies ist der Fall, wenn ein Geschäftsanwendungsfall von einem internen Ereignis eingeleitet wird und
für die Ausführung seiner Aufgaben nicht mit einem Akteur interagieren muss.
*Dies scheint im Widerspruch zur UML-Definition von Anwendungsfällen zu stehen. Auf der Seite Richtlinie: Geschäftsanwendungsfallmodell im Abschnitt zu internen
Geschäftsanwendungsfällen wird dieser Fall jedoch erläutert.
-
Sie muss klar und einfach zu verstehen sein, selbst für Personen außerhalb des Geschäftsmodellierungsteams.
-
Sie beschreibt den Workflow und nicht nur den Zweck des Geschäftsanwendungsfalls.
-
Sie beschreibt nur die Aufgaben innerhalb des Geschäfts.
-
Sie beschreibt alle möglichen Aufgaben im Geschäftsanwendungsfall, z. B. was passiert, wenn eine Bedingung erfüllt
ist, und was passiert, wenn nicht.
-
Sie erwähnt keine Akteure, die nicht mit dem fraglichen Workflow kommunizieren. Wenn andere Akteure erwähnt werden,
lässt sich die Beschreibung schwieriger verstehen und verwalten.
-
Sie beschreibt nur die Aufgaben, die zu dem Workflow gehören, und nicht, was in anderen Geschäftsanwendungsfällen
geschieht, die parallel ausgeführt werden.
-
Sie erwähnt keine anderen Geschäftsanwendungsfälle, zu denen keine Beziehung besteht. Wenn der
Geschäftsanwendungsfall das Vorhandensein bestimmter Ergebnisse im Geschäft voraussetzt, müssen diese als
Vorbedingung beschrieben werden. Die Vorbedingung sollte nicht auf die Geschäftsanwendungsfälle verweisen, in denen
die Ergebnisse erstellt werden.
-
Sie gibt an, ob die Reihenfolge der für den Geschäftsanwendungsfall beschriebenen Aufgaben, vorgegeben ist oder
nicht.
-
Sie ist so strukturiert, dass sie einfach zu lesen und zu verstehen ist.
-
Die Beschreibung beschreibt Beginn und Ende des Workflows eindeutig.
-
Jede Erweiterungsbeziehung ist klar beschrieben, so dass offensichtlich ist, wie und wann sie in den
Geschäftsanwendungsfall eingeschlossen wird.
-
Er ist nennenswert. Denken Sie daran, dass ein konkreter Geschäftsanwendungsfall zusammen mit seinen abstrakten
Geschäftsanwendungsfällen einfach zu lesen sein muss. Deshalb sollte ein abstrakter Geschäftsanwendungsfall nicht
zu klein sein. Wenn ein abstrakter Geschäftsanwendungsfall nicht nennenswert ist, sollte er weggelassen werden, und
seine Aufgaben sollten in den betreffenden konkreten Geschäftsanwendungsfällen beschrieben werden.
-
Er enthält logisch miteinander verbundene Aufgaben.
-
Er existiert aus einem bestimmten Grund. Ein abstrakter Geschäftsanwendungsfall sollte einen von drei Aufgabentypen
enthalten: Aufgaben, die mehrere Geschäftsanwendungsfälle aufweisen, Aufgaben, die optional sind, oder Aufgaben,
die so wichtig sind, dass Sie sie im Modell hervorheben möchten.
|