Kommentare
Melden Sie sich an, um einen Kommentar zu verfassen.
Neueste Beiträge
-
Alexej Eisenberg hat Good Practice Vorschlag 'praktische Modellierung: Reactive Processes' in den Papierkorb verschoben
vor 2 Jahre, 1 Monat -
Alexej Eisenberg hat den Text von Prozess 'Sammeln alle Alternativ-Fälle zu einem Fluss' geändert
vor 2 Jahre, 1 Monat -
Alexej Eisenberg hat Revision 2 von Prozess 'Sammeln alle Alternativ-Fälle zu einem Fluss' erstellt
vor 2 Jahre, 1 Monat -
Alexej Eisenberg hat Revision 1 von Prozess 'Sammeln alle Alternativ-Fälle zu einem Fluss' erstellt
vor 2 Jahre, 1 Monat -
Alexej Eisenberg hat den Vorschlag Good Practice Vorschlag 'praktische Modellierung: Reactive Processes' hinzugefügt
vor 2 Jahre, 1 Monat
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?
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.
