However, feedback from ARIS customers with unique needs for rigorous process model governance indicated that more is needed than the lightweight workflows—like, for example, a workflow for publishing models in isolated repositories to ensure consistency for reporting and analysis.

Although the gap left by the lightweight workflows can be filled by a fully-fledged ARIS Process Governance engine, budgets are often a barrier. On the other hand, manual administration (e.g. the handling of models across several repositories without the support of automation) requires a fair bit of maintenance.

Solution Overview

To address these challenges, a customised approach is proposed; and this article introduces a semi-automated solution through the programming and reporting capabilities in ARIS.

The solution includes a few elements as described in Figure 1. There are four different roles that are responsible for advancing a semi-automated workflow through the invocation of designated Release Cycle Management (RCM) reports. These roles are designed for a typical scenario, and can be changed and updated according to a customer’s specific requirements.

Two repositories are used: one for housing, developing, reviewing and approving process models; and another for the released process models. The latter, the production repository, is available for operational users to consume models once released and transferred from the development repository. It is also available to process approvers to review feedback for revision should changes emerge in the process context.

A set of reports carry out actual RCM tasks, and inform the relevant roles with support from an internal email system. A set of records is logged in raw format every time a model status is changed for potential later reporting. This logged information includes: date/time, the RCM task performed, and process model information, etc.

Transitions of model status

The model status, which is identified by a model attribute, is essential to determine the status of process models in the release cycle. It is also the basis for the RCM tasks to carry out appropriate activities, inform relevant roles, and determine the next status.

Figure 2 – Transitions of model status

Model status is set to “In Progress” as soon as a new model is created. Once the model is ready for review by an appropriate reviewer, the modeller runs the RCM task “RCM – Request Model Review”. The task changes the model status to “To be reviewed”, and sends an email to the reviewer.

The model is then reviewed and, if the model needs more attention, the reviewer rejects it by running the RCM task “RCM – Reject Model”. The model status is then changed back to “In Progress” and an email is sent to the modeller with relevant comments.

Alternatively, if the model review was successful, the reviewer runs the RCM task “RCM – Request Model Approval”. The model status then changes to “Reviewed”.

Figure 3 – Implicit merge of released models

The process owner is now triggered by an email sent by the RCM task to perform the last review. The model can be rejected by the owner, or released to the production repository. The process owner, therefore, can run both RCM tasks: RCM – Reject Model or RCM – Release Model. In the latter case, the RCM task changes the model status to “Released”, locks the model in the development repository, and implicitly merges the model to the production repository. The production repository will have the same structure as the development repository and houses only released models.

The status “To be revised” is set when process owner has received feedback from operational users, or other parties, about certain defects in the process. As operational users are viewers in ARIS Connect, it is possible to inform the process owner by commenting on the model within ARIS Connect. The process owner then evaluates the feedback, and is able to run the RCM task RCM – Request Model Revision if the process needs to be revised.

From this point, further work is carried out to formalise a solution to address the reported feedback. Once the concerning model has been updated with the agreed changes, the process owner runs the RCM task RCM – Request Model Update. The model is then unlocked, and the model status changes to “In Progress”. Relevant parties receive emails about the changes, which starts a new RCM cycle.

Solution Summary

This RCM solution offers a practical and flexible approach at a reasonable cost—reasonable, that is, compared to the investment that comes with the introduction of APG.

As the automation is implemented by ARIS reports, it is possible to call these reports from both THICK and THIN clients (even by ARIS Connect viewer users), which means that all types of client are able to participate in the RCM activities if required.

This flexibility of programming also allows custom semantic checks to be incorporated in case in-built semantic checks fail to meet requirements. This pragmatic approach for semantic checks allows them to be connected to certain RCM stages. As it is a customised solution, it can be adapted to future changes.

The solution supports the participation of operational users to feedback from the context in which the processes run. Normal RCM solutions are encapsulated in a BPM Office.

Although ARIS Connect is used in this sample scenario, the solution can be adapted to support a combination of ARIS Design Server and ARIS Publisher with similar results.