---

Comments

In case of process models, it is a good practice to only model the process flow and all belonging objects like data input/output, executing org units, risks associated with a certain step, etc. in diagrams assigned to the process flow model. In that way you have a lean diagram with all additional information just away a single click.

---

Thanks Sebastian,

We model processes with just basic objects (applications, functions, events and connectors). However the process itself is quiet huge. It has a lot of exceptions and usually involves 4 - 5 participants. Just modelling this process with all the exception makes the model look huge. Its so huge that we usually have to print it on a A0 sheet for people to be able to see the entire model. This is not really convenient for most end users.To give you an indication of the size, on a Level 4 model we average at 25 - 30 functions per model. We model in traditional EPC fashion (events alternating with functions). This also causes the model size to increase. I've been considering omitting "trivial" events from the models to make it smaller.

Based on recent feedback that we received most of these exceptions dont occur that often. So if we were to use the Pareto principle, the most like path (maybe 10 - 15 functions long) occurs 80% of the time and the the exceptions occur 20% of the time. Hence I was keen to know if there's a way we can hide the other exceptions and only show the process that happen 80% of the time.

This would make the models very versatile and acceptable to different groups of people. i.e. the ones who want to view just the simple process and the ones who are interested in all the exceptions.

Cheers

Ganesh

---

Hi Ganesh,

it could be a little bit risky to remove the exceptions from your model. People usually know how to run a process if everything works fine, but they need support if an exception occurs.

As you already said, I highly recommend to through out all trivial events. It's a waste of time to read all of them without gaining anything.

You might also want to evaluate if it is possible to further divide your models to reduce complexity, but that's probably a lot of work also influencing the level above.

It always rings the business rules bell if I hear that there are many complex rules modelled in a process. The suggestion would be to move complex decision into decision trees out of the model. But that's a bit of academic suggestion as it usually involves incorporating a completely new formalism.

---

Thanks Sebastian,

We are not planning to remove the exception from the processes. Our requirement is to create "views" in ARIS BP that hides some exceptions while using the proposed "Simple" view. All exceptions will be thoroughly modelled in the process. We just want the user to have the flexibility to switch between views to suit their purpose.

Trivial events removal is something we're keen on and I'm currently revising the conventions to get this implemented.

Dividing the models to reduce complexity would have the best option for us, however as you've mentioned its a large piece of work and we're not in a position to do that. We will need to revise our L3s to sub divide them into logical chunks to make the L4s smaller and manageable. However this is not realistic for us at this time.

So does this mean, there's no way to implement the concept of views in ARIS BP?

---

What does this "views" option under Find do?

---

Here's another clue I found in our ARIS BP instance. I'd really like to know how to use these features to fit my requirement.

Does anyone have any ideas?

---