7.1 Grunddatenbearbeitung für Personalplanung und Management

Das erste Beispiel in der folgenden Abbildung ist eine Ereignisgesteuerte Prozesskette aus SAP R/3. Es handelt sich um den Geschäftsprozess Grunddatenbearbeitung für Personalplanung und Management. Unter Grunddatenverwaltung wird die Datendefinition, die Datenpflege und die Auswertung von Stammdaten verstanden (vgl. für die Definition und für vertiefte Erläuterungen [Lexikon WI, S. 179ff]). Hier geht es um den Bereich der Personalplanung.

Spezifika von SAP-EPKs

Wie bei allen Ereignisgesteuerten Prozessketten von SAP R/3 werden bei der Grafik Informationsobjekte und Organisationseinheiten nicht angegeben, können allerdings mithilfe der Software (Business Navigator, Komponente des R/3) leicht aufgerufen werden.

Da es in diesem Buch nur um die „Methode EPK“ geht und nicht um Inhalte wurden nur Ereignisgesteuerte Prozessketten aus thematischen Randgebieten gewählt. Außerdem wurden aus Platzgründen bis auf eine Ausnahme sehr kurze gewählt. Daraus sollte nicht auf die Gesamtheit der SAP-EPKs geschlossen werden. Diese sind inhaltlich umfassend und – den wirklichen Geschäftsprozessen entsprechend – meist sehr lang.

Alle SAP-EPKs mussten grafisch bearbeitet werden, um sie in einem solchen Buch darstellen zu können. Zum einen wurden die im Original vorhandenen Farben beseitigt, zum anderen wurden sie durch Verkürzung der Linien grafisch verdichtet. Als Letztes wurden noch die im Original dünnen gestrichelten Kanten (Linien) verdickt und die Strichelung entfernt.

SAP-EPKs: Grafische Bearbeitung

Textliche Beschreibung der EPK

Gestartet wird der Geschäftsprozess durch das Ereignis Mitarbeiterdaten sind zu bearbeiten. Als Erstes wird die Person bestimmt, dann der Bearbeitungsgrund. Dieser kann entweder eine Veränderung der persönlichen Mitarbeiterdaten, der Ausbildungsdaten, der Qualifikation eines Mitarbeiters oder von betriebsinternen Daten sein. Haben sich persönliche Mitarbeiterdaten geändert, wird anschließend die Funktion Grunddaten Person bearbeiten gestartet. Haben sich entweder die Ausbildungsdaten oder die Qualifikation des Mitarbeiters geändert, werden anschließend die Planungsdaten bearbeitet, bei einer Änderung der betriebsinternen Daten startet die entsprechende Funktion. In allen Fällen endet der Geschäftsprozess mit dem Schlussereignis Mitarbeiterdaten sind bearbeitet.

Aufteilung und Zusammenführung des Kontrollflusses erfolgt durch XODER, da es sich ja um echte Alternativen handelt.

7.2 Lieferantenstammbearbeitung

Das nächste Beispiel zeigt eine Ereignisgesteuerte Prozesskette aus SAP R/3 zum Geschäftsprozess Lieferantenstammbearbeitung. Es geht um die Bearbeitung der Stammdaten zu Lieferanten. Dieser Geschäftsprozess kann auf zweierlei Art gestartet werden. Entweder durch das Ereignis Lieferant soll angelegt werden oder durch einen anderen Geschäftsprozess Mängelrüge. Dort ist gegebenenfalls das Ereignis Q-Meldung erfordert eine Änderung im Lieferantenstammsatz eingetreten. Der aufrufende Geschäftsprozess entstammt dem Modul QM (Qualitätsmanagement).

Als Erstes wird dann dem Kreditor eine Kontengruppe zugeordnet. Danach werden zwei Funktionen angestoßen: Erstens wird eine Lieferantennummer festgelegt, zweitens die Einkaufsorganisation. Bei der Festlegung der Lieferantennummer gibt es zwei durch Ereignisse angedeutete Möglichkeiten (interne oder externe Vergabe).

Danach wird der Kontrollfluss wieder zusammengeführt (mithilfe eines UND, weil mit einem UND aufgespaltet wurde) und die Funktion Kreditorendaten erfassen angestoßen. Diese Funktion und der gesamte Geschäftsprozess endet mit dem Schlussereignis Lieferant ist angelegt.

7.3 Kontaktbearbeitung

Das folgende Beispiel ist etwas umfangreicher. Mit ihm soll die Rolle der Prozesswegweiser deutlicher gemacht werden. Es beschreibt den Geschäftsprozess Kontaktbearbeitung. Im Geschäftsprozess Mailing-Aktion-Bearbeitung wird nach dem Ereignis Kontakt ist zu vereinbaren dieser Prozess Kontaktbearbeitung angestoßen.

Weil der Geschäftsprozess so umfangreich ist, hier zuerst eine Gesamtübersicht, die den Aufbau angeben soll. In den nachfolgenden Abbildungen wird dieser Geschäftsprozess dann Stück für Stück (von oben nach unten, von links nach rechts) detailliert vorgestellt.

Übersicht gewinnen

Wie zu sehen ist hat der Geschäftsprozess zu Beginn einen Prozesswegweiser, durch den er u.U. gestartet wird. Alternativ kann er auch durch ein Ereignis gestartet werden. Am Ende finden sich dann acht Prozesswegweiser, die den jeweiligen Kontrollfluss in andere Ereignisgesteuerte Prozessketten weiterführen.

Start durch Prozesswegweiser

Doch nun zur Detailsicht. Sie ist in den nächsten 5 Abbildungen angegeben. Wie Teil 1 zeigt, wird der Geschäftsprozess tatsächlich entweder durch einen anderen gestartet oder durch ein Ereignis.

Auf eine solche Weise können verschiedene Startmöglichkeiten eines Geschäftsprozesses modelliert werden. Oftmals sieht man Ereignisgesteuerte Prozessketten, bei denen zahlreiche solche Startalternativen vorhanden sind, ähnlich wie in dieser Ereignisgesteuerten Prozesskette am Ende.

Der Start durch den Prozesswegweiser entspricht dem Standardaufbau von Ereignisgesteuerten Prozessketten: Der Prozesswegweiser zeigt, wo­her der Aufruf kommt, das auf den Prozesswegweiser folgende Ereignis entspricht dem Ereignis, nach dem im aufrufenden Geschäftsprozess der Prozesswegweiser steht (vgl. Kapitel 6).

Etwas unübersichtlicher erscheint auf den ersten Blick der Start durch die Ereignisse. Hier kann die folgende Abbildung helfen, die dasselbe Fragment in der klassischen Notation darstellt.

Reisebedarf?

Hier wird deutlich, dass das Startereignis Kontakt ist vorzubereiten ist. Von diesem geht der Kontrollfluss weiter zum linken XODER-Operator und zum rechten UND-Operator. Der linke Zweig führt dann auf jeden Fall zum Start der Funktion Kontaktart bestimmen. Dagegen wird der Prozess Erfassung der geplanten Reise nur gestartet, wenn zusätzlich Reisebedarf aufgetreten ist.

Steuerung mit UND

Diese Stelle kann nur verstanden werden, wenn man von einer durch die Anordnung der Operatoren gegebenen Reihen- und Rangfolge der Ereignisse ausgeht. Dieselbe Stelle hätte auch durch eine Funktion Prüfen ob Reisebedarf mit entsprechenden Ergebnisereignissen modelliert werden können.

Hier kann die Kenntnis des UND-Operators etwas vertieft werden. Ein UND-Operator (wie hier nach dem Ereignis Kontakt ist vorzubereiten ist bereits erfüllt, wenn der Kontrollfluss weitergeführt ist (hier zu den zwei Operatoren). Es müssen nicht die nachfolgenden Funktionen angestoßen werden (was ja hier zumindest auf einer Seite auch nicht sein muss). Auf diese Weise kann ein unterschiedlicher Ablauf modelliert werden, je nachdem, ob ein weiteres Ereignis eintritt oder nicht. Tritt hier das Ereignis Kontakt ist vorzubereiten nicht ein, bleibt – sozusagen – der vom UND-Operator kommende Zweig des Kontrollflusses vor dem weiteren UND-Operator stehen.

UND vertieft

Unabhängig vom konkreten Beginn des Geschäftsprozesses wird im Anschluss die Funktion Kontaktart bestimmen angestoßen. Diese hat drei mögliche Ergebnisereignisse. Nur eines kann eintreten, der Kontakt ist also entweder persönlich, telefonisch oder schriftlich herzustellen. Nach diesen drei Ereignissen wird der Kontrollfluss wieder zusammengeführt, da es einheitlich weitergeht: Es werden gleichzeitig zwei Funktionen angestoßen, Geschäftspartner bestimmen und Ansprechpartner bestimmen.

Bevor es mit dem nächsten Teil weitergeht, hier noch ein Hinweis auf die grafische Gestaltung. Im unteren Drittel der Ereignisgesteuerten Prozesskette folgen zwei Operatoren aufeinander, XODER sowie UND. Dies ist genau die Konstellation, die in der Basisnotation durch einen Kreis mit zwei Operatoren erfasst würde, der eine oben, der andere unten.

Abbildung 7.3-4 (Teil 2) oben zeigt die Fortsetzung. Nachdem die Geschäfts- und Ansprechpartner bestimmt sind, werden eine Kontaktbeschreibung und ein Kontakttext erfasst.

Nachdem dies geschehen ist, steht der Geschäftsprozess, verursacht durch das UND, bis das Ereignis Kontakt ist nachzubereiten eintritt. Zwischen diesen beiden Ereignissen liegt die Durchführung des eigentlichen Kontakts. Diese etwas unglückliche Konstruktion ist durchaus üblich und zeigt die vielen Möglichkeiten, die bei der Beschreibung von Geschäftsprozessen mit Ereignisgesteuerten Prozessketten zur Verfügung stehen. Auch hier hätte – wie oben – eine entsprechende Funktion eingefügt werden können.

Tätigkeit zwischen zwei Ereignissen

Hier geht es jedenfalls erst dann weiter, wenn beide Ereignisse eingetreten sind. Dann wird die Funktion Kontaktergebnis erfassen angestoßen. Der nachfolgende ODER-Operator signalisiert, dass es entweder einige durch entsprechende Ereignisse feststellbare Ergebnisse gibt oder dass Spesen angefallen sind oder dass beides eintritt.

Vgl. Abbildung
7.3-1 für eine
strukturelle
Gesamtübersicht

Betrachten wir zuerst die durch ein XODER als alternativ gekennzeichneten Ergebnisse:

• Kontakt ist erfolglos
• Folgekontakt ist vereinbart
• Anfrage ist aus Kontakt anzulegen
• Angebot ist aus Kontakt anzulegen
• Auftrag ist aus Kontakt anzulegen
• Servicevertrag ist aus Kontakt anzulegen
• Gut-/Lastschrift ist aus Kontakt anzulegen
• Retourenauftrag ist aus Kontakt anzulegen

Man sieht, hier ist an vieles gedacht worden. Teil 3 in der Abbildung zeigt die beiden Fälle Angebot ist aus Kontakt anzulegen und Auftrag ist aus Kontakt anzulegen. Hier wird dann jeweils ein entsprechender Prozess angestoßen.

Obige Abbildung mit Teil 4 zeigt den linken Teil des unteren Abschlussbalkens. Die ersten beiden Ereignisse (Scheitern bzw. Folgekontakt) stoßen keine anderen Geschäftsprozesse an. Die dritte Möglichkeit (Anfrage ist aus Kontakt anzulegen) stößt den Geschäftsprozess Kundenanfragebearbeitung an.

Abbildung 7.3-7 mit Teil 5 zeigt, dass im Falle der letzten drei Ereignisse aus obiger Liste jeweils ein Prozess angestoßen wird. Geht es um einen Servicevertrag, wird der Geschäftsprozess Servicevertragsabschluß u. -bearbeitung gestartet geht es um eine Gut-/Lastschrift, die Gut-/Last­schrift­anforderungsbearbeitung und, falls es sich um einen Retourenauftrag handelte, die Retourenbearbeitung.

Das letzte Fragment in Abbildung 7.3-8 (Teil 6) zeigt den Ablauf für den Fall, dass Spesen angefallen sind. Dieser Zweig rührt von dem ODER-Operator nach der Funktion Kontaktergebnis erfassen her. Das entsprechende Ereignis stößt dann die beiden Geschäftsprozesse Erfassung der Reisekosten und Ergänzung der Reisefakten an.

Dieser ODER-Operator erscheint hier nicht ganz schlüssig, denn so, wie die Ereignisgesteuerte Prozesskette jetzt verfasst ist, wäre es auch möglich, dass nur Spesen anfallen und kein Ergebnis festgehalten wird, nicht mal das Ergebnis Kontakt ist erfolglos.