Anmelden oder Registrieren
"#comment-list, #writenew_annotation"

Kommentare

, um einen Kommentar zu verfassen.


"#latest_activity"

Neueste Beiträge

"#tag_list, #add_tags"

Tags

praktische Modellierung: Reactive Processes

In all service processes the customer interacts whenever he or she wants. They don't stick to our process models regardless how nice they look ...

Every activity a service provider performs can lead to a re-action as soon can be perceived by a customer. In addition we usually have indirect re-actions such as customers contacting the service provider due to another's customer's experience or press coverage regarding the respective process. So there does not need to be a triggering activity at all.

Example:
A provider sends out an offer for a sale via e-mail. The desired re-active process chunk is the customer buying the offered items via provided link in the online shop. This will usually be modeled as the standard process. But what about all the other possible reactive scenarios? E.g. "recipient complaining about spam", "recipient calling in and trying to place the order by phone", "recipient replying to the e-mail with questions", "other customer who has heard about the offer writing in", ...

In our experience we usually have about ten re-active scenarios which need to be covered - more than a comprehensive model can take without getting messy. One possible way to cover it would be annotations at the activities which are perceivable for the customers with referrals to the known re-active processes.

How would you deal with it?

Beschreibung bearbeiten

letzte Änderung Markus Güntert am 17.09.2009 19:05

$(this).parent().parent().find(".collapse_content")
(0 Kommentare)
$("#best_practice_chapter_82")
Good Practice Summarize all undesired cases to one flow
Summarize all undesired cases to one flow

As I understood it, there is a desired case, e.g. the customer buys the item, and there are many other actions that the customer can do. To model this in BPMN I propose to distinguish the happy flow (desired case) and the unhappy path (all other cases).

Because the next step is determined by the customer I propose to use an event-based gateway for that. For the desired case the I propose to use a Receiving Intermediate Message event. It captures the case that the customer buys the offered product. All other cases are captured by another message event that is examined and handled using a subsequent activity. Finally, we have to decide wheter the process is going back to the state where he could purchase the item or whether the process ends here.

Beschreibung bearbeiten
$(this).parent().parent().find(".collapse_content")
(0 Kommentare)
$("#best_practice_chapter_83")
zum Modellieren hier klicken
Channel undesired case but model alternatives explicitly

Beschreibung des neuen Vorschlags

Beschreibung bearbeiten
$(this).parent().parent().find(".collapse_content")
(0 Kommentare)
$("#best_practice_chapter_85")
Bad Practice Every Alternative Event separately
Every Alternative Event separately

If I understood you correctly, this is the modeling situation that you want to avoid.

Beschreibung bearbeiten

Papierkorb

Geben Sie Feedback

Close

Helfen Sie uns die BPMN-Community zu verbessern

Geben Sie uns Feedback zur aktuellen Seite. Ihre Kommentare sind nurfür das Entwickler-Team einsehbar.