Zeit ist – analog dem Sprichwort – nicht nur Geld, sondern kann auch in Geschäftsprozessen einen sehr wichtigen Faktor darstellen. Wichtig also, dies auch bei der Prozessmodellierung entsprechend darzustellen.
In BPMN 2.0 ist das eigentlich durch den Zeittrigger sehr gut machbar. In einer EPK dagegen gibt es solche Elemente für Zeitkomponenten leider nicht. Wie kann man dort solche Anforderungen sinnvoll lösen?
Möglichkeiten der Umsetzung
1. Als Freitexte und Kommentare
Die wahrscheinlich einfachste Lösung ist es, Informationen über die Zeit als Freitext oder Kommentar in das Prozessmodell zu integrieren.
Dies hat allerdings 2 große Nachteile:
- Freitexte sind nicht datenbankbasiert
- Man muss immer darauf achten, dass die Information an der richtigen Stelle steht – und auch dort bleibt. Beim Verschieben von Objekten darf man Freitexte nicht vergessen!
2. Als Information in den Attributen
Datenbankbasierte Tools wie z.B. ARIS bieten die Möglichkeit, zusätzliche Informationen in Objekt- oder Modellattributen zu erfassen. Dort kann man sich (notfalls über den Tooladministrator) Attributfelder für die Zeitkomponente einrichten und die jeweiligen Daten bei der Modellierung dort erfassen. Über entsprechende Skripte oder Reporte kann man diese Felder auch auswerten lassen. Viele Tools unterstützen auch die Funktion, ausgefüllte Attributfelder automatisch im Modell anzuzeigen. Dies ist auch sehr sinnvoll, da sonst die Zeitkomponente nicht auf einen Blick zu erkennen ist. Als Nachteil kann man hier den erhöhten Aufwand zur Pflege der Attribute nennen.
3. Über Ereignisse und / oder Tätigkeiten
Natürlich lassen sich zeitliche Informationen auch über Ereignisse und Tätigkeiten darstellen, z.B.
über (zeit- oder ereignisbasierte) auslösende Ereignisse darstellen:
- 24.12., erster Montag im Monat (absoluter Zeitpunkt)
- „3 Wochen nach Anmeldeschluss“ (relativer Zeitpunkt)
Tätigkeiten, die einen Zeitraum oder Dauer mitliefern:
- „Maschine 10min warm laufen lassen“
- „3 Tage auf Rückmeldungen warten“ (hier müssen dann entsprechende Ereignisse das weitere Vorgehen bestimmen)
Ein Nachteil dieser Möglichkeit kann sein, dass ein „erzwungener“ Einbau der zeitlichen Komponente sehr gekünstelt wirken kann un man Gefahr läuft, das Modell unnötig zu verkomplizieren.
Fazit
Ehrlich gesagt, habe ich für mich persönlich noch keinen zufriedenstellenden Weg gefunden, solche Informationen in EPK oder WKD darzustellen. Eine Ideallösung gibt es wohl auch nicht. Oft kombinier ich je nach Anforderung verschiedene Möglichkeiten. Wichtig ist dabei vor allem: ist die zeitliche Komponenten prozessflussrelevant oder ist sie nur informativ? Im Zweifelsfall gilt bei mir: lieber eine Information zu viel als zu wenig.
Für Zeiten gibt es ja eine Attributgruppe in ARIS, wie auch zum Beispiel der in der BIC Platform. Zeiten für Funktionen, wie die Dauer einer Tätigkeit, werden also im passenden Attribut angegeben. Hier kann man die Dauer auch unterteilen in Rüstzeiten und reine Dauer des Arbeitsschrittes oder Maximalzeiten, Minimalzeiten sowie Durchschnittszeiten. Zeitspannen, die zwischen 2 Funktionen liegen kann man plakativ im Ereignis beschreiben oder auch wieder über ein Attribut, welches dann eingeblendet werden kann. Diese Form der Dokumentation eignet sich auch um wiederkehrende Perioden zu beschreiben.
Noch eleganter finde ich ja, wenn man Kantenattribute nutzt um die Zeit zwischen 2 Funktionen zu beschreiben. Auch diese kann man dann entlang der Kante einblenden. Alle diese Varianten haben den Vorteil, dass diese auswertbar sind. Freitexte sollte man nach Möglichkeit komplett weglassen.
Kommt auch auf die „Natur“ des Prozesses an. Folgendes Beispiel ist bestimmt selten (um nicht zu schrieben „nie“) in vollem Umfang innerhalb einer unternehmensweiten Prozessdokumentation realisierbar, wäre hier aber fehlend und gibt vielleicht die passende Idee zur letztendlichen Lösung:
Aus der Vergangenheit heraus in einer Produktion mit Sub-Produkten in mehreren Ebenen zum End-Produkt realisiert. Zu den einzelnen Schritten jeweils die zeitliche Komponente dahinter „geklemmt“.
Zeitangabe: Es stellte sich heraus, dass die Art der Erfassung der zeitlichen Komponenten am realistischsten von den Arbeitern/ Betroffenen vor Ort eingeschätzt wurde.
Teils reine Produktionszeit (bspw. Drehautomat 43sec reine „Drehzeit“) , teils kompletter Zeitrahmen von Anfang Schritt „A“ bis mit Schritt „A“ wieder angefangen wird (bspw. Drehautomat Rohling holen, einspannen, … , Drehteil wegsortiert, habe neuen Rohling in der Hand).
REFA brachte (wie üblich) eher Unruhe rein und wurde nach aufkommen der Idee direkt verworfen. Unterm Strich keine 100% Lösung, aber für die Belange der Natur des Projektes (Lasten-/Pflichtenheft bei zeitlich begrenztem Rahmen) sehr sehr gut.
Für Rückfragen stehe ich gerne zur Verfügung.
Ja, hört sich vernünftig an. War ja nur ein plakatives Beispiel. In der Praxis würde ich es wohl genauso machen.
Sehr interessante Fragen. Wir modellieren bei uns Prozesse im Office-Bereich und haben Zeitraum und Dauer bislang außer acht gelassen. Absolute Zeitpunkte haben wir öfter, die integrieren wir dann auch als eigenes Ereignis in die EPK. Spontan würde ich Zeiträume oder Angaben zur Dauer auch versuchen als Ereignis aufzunehmen. Die Nachteile der Freitext-Info sind ja schon genannt. Wobei ich beim Beispiel „Einladung verschicken“ – „drei Wochen warten“ – „Teilnehmerliste erstellen“ vermutlich zwei EPK´s erstellen würde. „Einladung erstellen und versenden“ mit Schnittstelle zur EPK „Teilnehmerliste erstellen“. In der zweiten EPK würde ich den relativen Zeitpunkt „3 Wochen nach der Einladung“ oder „1 Tag nach Anmeldeschluß“ als zusätzliches Eingangsereignis modellieren.