Login or Sign up
"#comment-list, #writenew_annotation"

Annotations

Please to write annotations.


"#latest_activity"

Latest Activity

"#tag_list, #add_tags"

Tags

Modeling Practice: 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?

Edit Description

Last edited by Markus Güntert on Sept. 17, 2009, 7:05 p.m.

$(this).parent().parent().find(".collapse_content")
(1 Comment)
$("#best_practice_chapter_12")
Good 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.

Edit Description
$(this).parent().parent().find(".collapse_content")
(0 Comments)
$("#best_practice_chapter_20")
click here to start modeling
Channel undesired case but model alternatives explicitly
Edit Description
$(this).parent().parent().find(".collapse_content")
(0 Comments)
$("#best_practice_chapter_22")
Bad Every Alternative Event separately
Every Alternative Event separately

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

Edit Description

Trash

Provide Feedback

Close

Help us to improve usability!

Enter your feedback referring to the current page. Your comments are only visible to the development team.