KF
I am teaching the EPC model method and of course I tell my students, that in the EPC trivial events can be omitted. But until now I always insisted in telling that events should in any case be used before a connector. Checking out the delivered patterns in ARIS Express, I found that in all patterns, events are rarely used. Even in the pattern for the parallel process, there is no event before joining the two parallel paths. Here this can be argumented, but what is your position on this topic?
Should we as well omit the events when we have an exclusive OR connector? What about merging two exclusive paths via an exclusive OR? If we omit the events, we need somthing like in BPMN in order to be able to make clear to our audience which path is taken. But then, we can as well use BPMN instead of EPC :-)
I would be pleased to get your opinion.
Great topic, Klaus!
Well, start and end events are needed for sure for many reasons. For those intermediate that follow or precede rules, I have mixed feelings. From one side, from pure business point of view, they do not add much value and could be removed. The information about the special state/condition triggering and ending activities (I hope the term 'function' will be changed in ARIS pro soon) is very important but it should be an attribute of the connector. A good practice is probability attribute for simulation. The actual "change of state" represented by an event could be expresses in a value of some connector attribute.
From the other side, the good thing about EPC is that it's really a good "common language". So the IT capabilities are of equal importance. Although that it lacks the rigour of BPMN for describing the control flow, EPCs have many qualities as technical notation as well. Just compared with UML for example, one EPC can contain more or less the same information as activity, state chart and use case diagram together but in a single model and readable by the business and with much less number of objects. Events play an important role here in showing all states one business object might take and in what sequence. The other is representing pre- and post-conditions.
Yet another "pro" is their role when using assignmnets to link processes horizontally or different levels of details. May be there are better ways to solve this but I really find the "event" approach quite useful. Well, now it's a little bit inconvenient that a straight flow modeld at one point without events which are really not necessary, should be changed, and events added before and after an activity that should be detailed in a new EPC at a later stage.
Regarding usage of BPMN instead of EPC, have you read this discussion?
Ivo
Events rule!
At 2 different companies we have discussed eliminating 'trivial' events. To a certain level I am completely opposed, at a very detailed level I think it could be permitted. I would allow events to be skipped if detailing data entry, fill in field 1, press enter, fill in field 2, press enter, etc. When trying to define at a higher level when events could be skipped I make the list of times when they have to be used:
- start and end
- common or shared events
- before / after any rule/decision
- any point where you could conceivably want a milestone
- I also argue that a convention should have a standard and consistency is key. So level 4=events, level 5 no events.
My opinion, your mileage may vary.
donald
Hi Donald
thank you for your suggestion. The missing consistency is exaclty the point I have in this topic. As you suggest, it is wise to have the rules formulated in a modeling standard for the organisation or every person doing the modeling job will treat this differently leading to models that are difficult to understand.
Regarding your level 5 suggestion without events, what if you have a branching at this level? Then I think events should be added for clarity.
Best regards,
Klaus
Hi all,
this discussion is very interesting for us and we will use the input to improve the consistency of the usage of events in EPCs. I will talk with the persons in charge for ARIS Express development to check the quality of the delivered patterns. The EPC remains the central notation for IDS Scheer for business process modeling and we will strengthen our efforts to make it better than other (competing) process modeling notations like BPMN. BPMN will play an important role in ARIS too, but more regarding the description of technical processes, for more details see the other discussions in the community to this topic.
Regards
Uwe
From my point of view, the ca. 25 BPMN events (including logical operators) are too complicated. Perhaps they are useful in a context of BPEL orchestration, but they add complexity to modeling operations (hopefully we can filter). In EPCs, we appreciate the simplicity of the event and process interface symbols, used when required, depending upon the model's objectives.
I share Donald's view on the cases for using events, although I would not compromise on not having starting and ending events in the level 5. Events are what bind low-level processes together. We often do cross functional navigation by clicking events.
Rgds,
