Role Based Processes

28 Dec 2015

by Ian Stendera

Documenting Role Based Processes in Ardoq.

 

Role Based Process

Over the last few months we have been working closely with our new clients to help them document their business processes. We offer a handful of models out of the box, but we have come to realize that it is necessary for us to also provide best practices for the most common scenarios.

This blog post will cover a specific case in which a user wants to document their processes and have unique owners to individual steps. The example we will use for this post is a commonly used BPM example outlining a customer ordering a pizza in a restaurant. Traditionally the manually drawn diagram would look something like this.

Role Based Process BPM

We will replicate this example in Ardoq in the video below. But since we are focusing on the data first, we will create interactive, automatically drawn diagrams. The swimlane view will be a similar perspective to the diagram above.

You can check out this video, or continue on to explore our two suggested methods.

Documentating Role Based

 

Your Options

We can recommend two methods to document ownership or roles to individual steps. Which is best depends on the what your goal is. The easiest and often the best option for simply identifying who is responsible for what, is to tag or add a field for process or step ownership. If you are more interested in seeing the process visually segregated by the roles, similar to the example above, then we would recommend that you use a model that includes the “Role” as the parent or owner of steps and states.

Fields / Tags

The field or tag option is a simple way to document ownership but has a few limitations, at least for the time being. You can add a field from the Pages view by clicking the add field button under your other existing fields.

add fields

Or click on the main menu and select “Manage Fields”

manage fields ardoq

Benefits and Limitations to Fields

One benefit to using the field method is that it can be done quickly to a large amount of pre-existing data. This is helpful if you are working with completed documentation.

Fields are also useful for filtering and searching. By using a field you can quickly filter away all owners that you are not concerned with.

Currently, fields are limiting when it comes to visualizing ownership. Our out of the box visualizations are not modifiable by non-numerical fields. However, all our visualizations are built as plug-ins and by utilizing the plug-in editor you can modify or create your own plug-in, which in theory, could include fields as modifiers.

 

The Model

To best replicate the pizza shop example, we recommend utilizing a model that takes into account process ownership. The model used in this example is extremely simplified but can be applied to a variety of scenarios such as internal ownership, external suppliers, partners, etc.

You can also build on this model to include things like decision points and highlight different role types if necessary. Again, we alway recommend that you Keep It Simple.

 

Role

Benefits and Limitations to Model Approach

The model is a great way to visually represent ownership. Using the swimlane provides a clear process divided by role. You can also use other visualizations like the sequence diagram to gain a different level of overview to your processes.

The main limitation of using a model approach is that you are taking a very specific view of your processes and framing them in a manner that may not speak to other domains. Also, if you already have pre-existing documentation, applying it to a new model may take some time. Other than that, I personally think the model approach is the best way to highlight ownership and better visualize your processes.