Einen Geschäftsprozess für eine Softwarelösung modellieren

Wenn die neue Software einen ungeklärten Ablauf nur schneller macht

Die KüstenKiste Veranstaltungsservice GmbH vermietet Kühlanhänger an Vereine und kleine Gastronomiebetriebe. Anfragen kommen per E-Mail und Telefon. Zwei Mitarbeitende übertragen sie in eine Tabelle, prüfen die Verfügbarkeit in einem Kalender und erstellen anschließend ein Angebot in einer Textvorlage.

Die Geschäftsleitung wünscht sich ein Kundenportal. Doch schon im ersten Gespräch bleiben wichtige Fragen offen: Wann gilt ein Anhänger als reserviert? Wer darf einen Preisnachlass freigeben? Was passiert, wenn ein Führerschein nicht zur Anhängerklasse passt? Und welche Daten braucht die Disposition wirklich?

Eine Oberfläche zu entwerfen wäre jetzt zu früh. Dein Auftrag lautet: Modelliere den fachlichen Ist-Prozess so weit, dass ein Entwicklungsteam die passende Softwarelösung entwerfen kann, ohne die offenen Entscheidungen selbst zu erfinden.

Die Grundidee lautet: Ein Prozessmodell beschreibt, wer welches fachliche Ergebnis unter welchen Regeln erzeugt. Eine Systemanforderung legt danach fest, welchen Teil davon die Software unterstützen soll.

Du solltest einfache Abläufe lesen können. Eine bestimmte Modellierungsnotation musst du noch nicht beherrschen. Alle Namen, Fälle und Daten dieser Lektion wurden für das Szenario neu erstellt.

Beginne mit Ziel und Ergebnis

Ein Geschäftsprozess verbindet einen fachlichen Auslöser mit einem fachlich wertvollen Ergebnis. Für KüstenKiste beginnt der betrachtete Prozess, wenn eine vollständige Mietanfrage eingeht. Er endet, wenn ein verbindliches Angebot versendet oder die Anfrage begründet abgelehnt wurde.

Damit ist noch keine Softwaregrenze festgelegt. Zuerst hältst du den fachlichen Rahmen fest:

Eine Prozessgrenze legt fest, welcher Ausschnitt des betrieblichen Ablaufs untersucht wird. Sie schützt das Modell davor, immer weiter in angrenzende Abläufe zu wachsen. Die Übergabe des Anhängers ist wichtig, gehört aber nicht zu diesem Analyseauftrag.

Trenne Prozessgrenze und Systemgrenze

Die Systemgrenze beantwortet eine andere Frage: Welche Aufgaben übernimmt die geplante Software und welche bleiben bei Menschen oder anderen Systemen?

Im ersten Gespräch vereinbart KüstenKiste folgende Arbeitsannahme:

• Das Portal nimmt die Anfrage entgegen und prüft Pflichtangaben.
• Das Dispositionssystem liefert verfügbare Anhänger.
• Der Kundenservice beurteilt Sonderfälle und löst den Versand aus.
• Die Teamleitung entscheidet über Rabatte von mehr als 10 Prozent.
• Ein Zahlungsdienst ist noch nicht Teil der Lösung.

Das ist ein Kontextdiagramm, kein Ablaufdiagramm. Es zeigt Beziehungen über die Systemgrenze, aber weder ihre zeitliche Reihenfolge noch technische Protokolle. Genau diese Beschränkung macht es für die erste Abgrenzung nützlich.

Nimm den Ist-Ablauf mit Regeln und Ausnahmen auf

Für die Ist-Aufnahme kombinierst du Interviews, Beobachtungen und vorhandene Dokumente. Eine einzelne Aussage reicht selten. Die Textvorlage kann zum Beispiel einen anderen Ablauf nahelegen als die tägliche Arbeit.

Aus den Gesprächen entsteht dieser vereinfachte Ablauf:

1. Der Kundenservice prüft, ob Zeitraum, Anhängerklasse und Kontaktdaten vorliegen.
2. Die Disposition prüft, ob ein passender Anhänger frei ist.
3. Bei Verfügbarkeit berechnet der Kundenservice den Listenpreis und mögliche Nachlässe.
4. Ein Rabatt bis einschließlich 10 Prozent darf direkt angeboten werden. Ein höherer Rabatt braucht die Freigabe der Teamleitung.
5. Liegt die Freigabe vor, versendet der Kundenservice das Angebot. Ohne Verfügbarkeit oder erforderliche Freigabe folgt eine begründete Ablehnung.

Die Beschreibung ist bewusst als einfaches Ablaufmodell formuliert. Wenn du BPMN, eine ereignisgesteuerte Prozesskette oder ein UML-Aktivitätsdiagramm verwendest, musst du deren Symbole und Regeln konsequent einhalten. Ein frei gezeichnetes Flussdiagramm darf nicht nachträglich als BPMN bezeichnet werden.

Geschäftsregeln machen Entscheidungen prüfbar

Eine Geschäftsregel beschreibt eine fachliche Bedingung unabhängig von einer technischen Umsetzung. Für KüstenKiste lauten drei Regeln:

GR-01: Ein Angebot setzt einen verfügbaren Anhänger der angefragten Klasse voraus.
GR-02: Ein Rabatt über 10 Prozent braucht die Freigabe der Teamleitung.
GR-03: Eine Ablehnung enthält einen dokumentierten Ablehnungsgrund.

Ausnahmen gehören direkt an die Stelle, an der sie den normalen Ablauf verändern. Ein fehlender Zeitraum führt zurück zur Klärung. Ein hoher Rabatt führt zur Teamleitung. Ein nicht verfügbarer Anhänger führt zur Ablehnung. Wenn das Modell nur den Idealfall zeigt, kann das Entwicklungsteam weder Zustände noch Fehlermeldungen verlässlich entwerfen.

Verfolge Informationsobjekte durch den Ablauf

Ein Informationsobjekt ist ein fachlich zusammengehöriger Bestand an Informationen. Es ist noch keine Datenbanktabelle. Im Szenario reichen vier Objekte für die Übergabe:

Prüfe zu jedem Objekt vier Punkte: Wer erzeugt es? Wer liest oder ändert es? Welche Regel bestimmt seinen Zustand? Welcher nachfolgende Schritt braucht es? So werden unklare Übergaben sichtbar, ohne bereits Tabellen, Schnittstellen oder Dateiformate festzulegen.

Ein typischer Modellierungsfehler wäre, “E-Mail” als fachliches Informationsobjekt zu behandeln. Die E-Mail ist zunächst ein Übertragungsweg. Ihr Inhalt kann eine Mietanfrage oder ein Angebot sein. Diese Trennung verhindert, dass eine heutige technische Form den künftigen Entwurf unnötig festlegt.

Leite Anwendungsfälle und Anforderungen ab

Ein Anwendungsfall beschreibt ein fachliches Ziel, das eine Rolle mit Unterstützung des Systems erreicht. Für die Anfrageverwaltung reichen zunächst diese Fälle:

• Kunde reicht eine Mietanfrage ein.
• Kundenservice prüft und ergänzt eine Anfrage.
• Kundenservice lässt die Verfügbarkeit prüfen.
• Teamleitung entscheidet über einen Sonderrabatt.
• Kundenservice erstellt und versendet ein Angebot oder eine Ablehnung.

Ein Anwendungsfall ist mehr als ein Button. “Speichern” beschreibt eine Bedienhandlung, aber noch kein fachliches Ziel. “Mietanfrage zur Prüfung einreichen” sagt dagegen, welches Ergebnis die Rolle erreichen will.

Aus Prozessschritten, Regeln und Ausnahmen leitest du zwei Arten von Anforderungen ab:

• Funktionale Anforderungen beschreiben, was das System tun oder ermöglichen soll.
• Nichtfunktionale Anforderungen beschreiben überprüfbare Qualitätsbedingungen, unter denen es das tun soll.

Nichtfunktionale Anforderungen dürfen nicht nur mit Adjektiven arbeiten. Statt “schnell” brauchst du einen Messfall. Statt “sicher” brauchst du beispielsweise Rollen, erlaubte Aktionen und einen nachvollziehbaren Umgang mit Freigaben. Der genaue Zielwert muss mit den Beteiligten vereinbart sein, nicht aus Gewohnheit erfunden werden.

Übergib ein prüfbares Analysepaket

Die Übergabe an den Lösungsentwurf besteht nicht aus einem einzelnen Diagramm. Sie verbindet mehrere Sichten, die sich gegenseitig prüfen lassen:

1. fachliches Ziel, Auslöser, Ergebnisse und Prozessgrenze,
2. Rollen und Verantwortungen,
3. Ist-Ablauf mit Regeln, Entscheidungen und Ausnahmen,
4. Systemkontext mit einbezogenen und ausgeschlossenen Systemen,
5. Informationsobjekte mit Zuständen und Verantwortungen,
6. priorisierte funktionale und nichtfunktionale Anforderungen,
7. offene Annahmen, Konflikte und Rückfragen,
8. Abnahmekriterien und eine Versionsangabe.

Die Teile müssen konsistent sein. Wenn GR-02 eine Freigabe verlangt, muss der Ablauf den Sonderfall enthalten. Das Informationsobjekt Rabattfreigabe braucht eine verantwortliche Rolle. Eine funktionale Anforderung muss den Versand ohne Freigabe verhindern. Fehlt eine dieser Verbindungen, bleibt Interpretationsspielraum.

Was du jetzt von angrenzenden Lektionen unterscheiden kannst

In dieser Lektion hast du einen Geschäftsprozess als fachliche Grundlage einer Softwarelösung strukturiert. Der Schwerpunkt lag auf Ziel, Grenzen, Beteiligten, Regeln, Informationsobjekten und der konsistenten Übergabe an den Entwurf.

Die Lektion “Einen Prozess und seinen Informationsfluss modellieren” vertieft dagegen die präzise Ablaufnotation mit Verzweigungen, Parallelität, Medienbrüchen und Übergaben. Die Lektion “Einen Soll-Prozess entwerfen und eine Lösung auswählen” setzt eine belegte Schwachstelle voraus, entwickelt Verbesserungsvarianten und bewertet sie. Hier hast du weder eine detaillierte Notationsübung noch eine Optimierungsentscheidung vorweggenommen.

Belegmatrix

Quellenbasis und Abgrenzung

Der KMK-Rahmenlehrplan trägt die berufliche Handlung des Analysierens und Gestaltens von Prozessen in Lernfeld 11c. Die Fachinformatikerausbildungsverordnung ordnet das Analysieren von Arbeits- und Geschäftsprozessen der Berufsbildposition D1 zu und nennt für den Prüfungsbereich “Durchführen einer Prozessanalyse” Analysewerkzeuge, Prozessdarstellung, Optimierung sowie Qualitäts- und Wirtschaftlichkeitskontrolle. Prüfungskatalog und interner Lernguide dienen hier nur zur Eingrenzung typischer Teilkompetenzen und Modellierungsformen.

Die Lektion übernimmt keine Aufgabenstellung und keine Lösung aus einer Prüfung. Das Unternehmen, der Ablauf, die Regeln und alle Daten wurden neu entwickelt. Eine konkrete Notation wird nur so weit eingesetzt, wie ihre Aussage erklärt werden kann. Detaillierte BPMN-Modellierung, Informationsfluss, Kennzahlen, Optimierungsvarianten, Wirtschaftlichkeitsvergleich und technischer Architekturentwurf gehören in eigene Lerneinheiten.