Latest Activity
-
Markus Güntert edited the text of Process 'Every Alternative Event separately'
11 months, 4 weeks ago -
Markus Güntert edited the text of Process 'Summarize all undesired cases to one flow'
11 months, 4 weeks ago -
Markus Güntert edited the text of Best Practice 'Modeling Practice: Reactive Processes'
11 months, 4 weeks ago -
Alexander Grosskopf added proposal Bad Practice Proposal 'Modeling Practice: Reactive Processes'
1 year, 2 months ago -
Alexander Grosskopf deleted Good Practice Proposal 'Modeling Practice: Reactive Processes'
1 year, 2 months ago
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?
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.
