BS
As a modeler I am aware of the value and usage of event objects in an EPC and have established them as mandatory in our process step level models.
However for the casual audience, events are often a distraction/annoyance.
I expect this is a common complaint and would be interested in how other groups deal with this.
Specifically I want to create a view to mask events that exist in a model:
I have tried filters and the “hide” options but these result in unconnected objects as the relationship lines connected to the events also disappear, therefore you loose visibility to the sequencing of functions.
In older versions of business publisher ( I think 7.02) a view option was available to display only “significant” events ( i.e. events that followed an OR or XOR connector). This is what I’m looking for.
However in the Version I currently have ( 7.2.2) that option is no longer available. Instead there are two options:
Hide Events
Show events for which a probability is specified.
I have tried these two options in various combinations after maintaining the probability attribute, but have not had any luck in achieving the same result as the display of significant events mentioned above.
I would like to avoid creating additional models or variants as they represent additional maintenance effort.
Please share your experiences on this topic.
Hello Bob,
In epc methodology, it is usually adviced to defined input and output events on each activity. This is usefull for the process designer to :
- define if there is an added value to the activity ;
- define business rules ;
- document outputs and inputs.
By the way, when you document processes, the event / activity concept is not so easy to understand for casual audience who are not new to process design.
The question is : why are you designing processes ? who is the audience ?
In my opinion, a process modeler who design process for a documentation goal should design a process not for himself, but for others. Indeed, the model is an abstract representation of your company. The resulted processes must be as simple as possible, syntetic in the design, detailed in the attribute description.
I think you must feel comfortable not to design trivial events (exemple Act : Create Business Requirements -> evt : Business Requirements created.) because they are useless for comprehension, and they are no taken into account by BPA, BPM, business simulator...
The only events you should keep are the following :
-Start process event
-End process event
-Gateway events
Other point : did you consider the BP default display options "process view" and "activity view" whose let you display only functions ?
Regards
I feel your pain, I face the same problems. The ARIS / EPC method is very complex for untrained casual users ; the events make it appear even more complex and in many cases do not add any information that is useful to the business.
The best way we have found to deal with this is to "use the events only where they are really needed" ; meaning leave out the trivial events as Vincent suggested.
It would be great if the simplified views in Publisher actually worked without making a big mess, but I understand why that is so difficult technically.
I agree with Bob, it would be nice to have the ability to only display significant events back. I have used that capability in the past.
As a work around you could create a filter that uses a very small object to depict the events and leave the name off of them. You could use this filter when reviewing models with users and it would at least reduce the noise on the diagram.
Rick
I use events (even non- branching ones) to describe "expected results" within Test Designer. With no good solution for masking them, I might need to reconsider this practice.
Rick,
I have tried in the same technique that you suggested (minimizing the size of the event object). While it works, you end up with the two connectors (appearing as one very long awkward connection) and the model looks artificially elongated.
Anyway, I just wanted to be sure I wasn’t overlooking some feature that may have address this.
Thanks for all your comments.
Bob
