Events are they an endangered species

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

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,