In the UMG database there are occurrences of ERM attribute objects connected to Event objects. (See below)
Is is acceptable ARIS modelling convention (i.e. best practice) to attach data objects to an event?
If so, is it acceptable ARIS modelling convention to attach a data/cluster object to an event?
If so, what does it mean? i.e. Does an attached cluster object imply or show "state"? Is it acceptable practice to "show state" with a data cluster object? Or does it simply mean that when the event occurs that the data is read/evaluated or written to a persistent store.
My group is having a lively debate about whether events can have state (i.e. stateful events) and whether a cluster object could be used to represent the specific data that makes up the "state" of the event when it occurs.
Any advice or opinions happily received.
Hi
No, events (in an event driven process chain diagram) are just that, something has happened. They are not an Activity where such things as data objects are more usually connected.
If you are modelling using EPC then the function object (Activity) is where you connect data clusters and roles etc. however it is more common to locate the objects used in an activity in a FAD diagram that is assigned to that activity... this keeps your EPC less cluttered and more readable.
ARIS is a very comprehensive configurable tool and you have the opportunity to apply or enforce standards amongst the users. Personally I would say that the example you give is not 'best practise'.
If you can provide more details about the sort of modelling you are undertaking then I can probably be more helpful.
Regards
Mike
David,
That`s a topic that indeed can provoke lively debates. According to me, Events are a bit of a loose concept in EPC. Events can be pre-conditions, post-conditions, condition expressions, states and ... events :) As modelling should alsways have purpose (not done for the sake of modelling), that would determine if and when to narrow the semantics of EPC events.
The model you've presented is very useful in process simulation. It represents the case where, if we apply BPMN terminology, events are used for condition expression of data-based gateways. The result produced by the previous activity is evaluated by the gateway aka EPC rule, based on condition expressions represnted by EPC events.
When events are linked to Cluster/Data model with hasState connection type, then they show the change of an entity (business object) based on what was done with it in the preceding activity (function). In some cases this is very useful because you represent in one integrated diagram what you would show in two or more using for example UML. UML and BPMN are much more formal of course but the beauty (and sometimes the drawback) of EPC is in being less so and still very strong for communication, analysis and simulation.
Fri, 02/17/2012 - 22:53
Dear David,
Actually many of those D attribute object types are connected to Events in the UMG demo database just to indicate a measuring point.
When you look up the occurences of those D attributes you will find them in KPI allocation diagrams. Typically, they are representing a time span (from order to delivery) or a specific status (no. of orders).
An example of the above is the EPC Order-to-cash direct sales (system). There are D attribute object types occuring in the KPI allocation diagram Increase sales process efficiency to deliver measuring points for KPI instances.
Cheers
Rune
I would not say that Events "have" states but rather that Events represent the State of an object, entity or data cluster. As mentioned above Events can have other uses but certainly repersenting the state of a data object is one of the intended uses. You may also be interested in the Event Diagram which allows you to collect all of the possible states (Events) of a single data object. The meaining is defined by the type of connections you use.
