Best Practice for As-Is and To-Be Process Handling within ARIS

We are modelling a high number of models of different types like VAC, BPMN, Risk Diagram, Function Allocation, BPMN allocation, EPC etc. In total we will end up with 500 or more process model instances.

At a certain milestone we will move from the As-Is to the To-Be modelling, perhaps not for all models at the same time but for some out of the 500, so after some time we will have ax. 750 model instances.

My question now belongs to best practice how to structure As-Is and To-Be's best in relation of grouping within ARIS.

I mainly see the following alternatives:

Alternative 1: As-Is and To-Be as different versions

Track the To-Be with the same model name in the same group, but with an attribute "Model Stage" with the values "As-Is", "To-Be". (As-is has then a lower version as the current to-be)

Advantage:

• only one model required
• Version compare / difference report available

Disadvantage:

• You can not perfom any changes to the As-Is version anymore, because is has been continued by the To-Be already.
• It might be difficult to set all linked flows to the latest As-Is version (for review or reporting purposes) as the models do not have always the same version

Alternative 2: As-Is and To-Be as different Models

Keep As-Is and To-Be close by another and change the model name accordingly (pre or postfix with To-Be).

Advantage:

• Clear separation, unwanted links to other models can be removed easily without disturbing the As-Is
• As-Is and To-Be can be opened in parallel
• Can be combined with versioning
• Suggested is the ARIS Variant usage for To-Be, pointing to As-Is, this would also allow you to run model comparison reports.

Disadvantage:

• Please make sure that you do not change a commonly used object by both processes; you need to work with definition copies to keep As-Is stable.

Alternative 3: Two Subfolders within the main Process Folder

Create two subfolders within the main process folder and name the first "As-Is", and the second "To-Be". Place the appropriate model into the right folder then.

Advantage:

• Same model name can be used. Linked models from As-Is will always have an As-Is path, same for To-Be.
• Possibility to grant individual access to both groups (r/rw)
• Can be combined with versioning
• Suggested is the ARIS Variant usage for To-Be, pointing to As-Is, this would also allow you to run model comparison reports.

Disadvantage:

• Please make sure that you do not change a commonly used object by both processes; you need to work with definition copies to keep As-Is stable. 

Alternative 4: Two trees within one database

Start with two trees within one database, where the first one will have a main group "As-Is" and the second "To-Be", create the appropriate group structure below and place the models accordingly.

Advantage:

• Very clear separation.
• Can be combined with versioning
• Possibility to grant individual access to both groups (r/rw)
• Suggested is the ARIS Variant usage for To-Be, pointing to As-Is, this would also allow you to run model comparison reports.

Disadvantage:

• Please make sure that you do not change a commonly used object by both processes; you need to work with definition copies to keep As-Is stable.

Alternative 5: Create one database for "As-Is" and the next for "To-Be".

Advantage:

• Separate backups possible
• Clear definition for access rights
• Can be combined with versioning.

Disadvantage:

• Can not compare models across databases
• Managing multiple DBs and users required

Related Topics: Variants

Variants are initially offered to handle process variants like for cars (mini, van, and lorry) or services (phone, mobile, and internet). The idea is to keep a reference to the other and be able to highlight always the difference (if one employee moves to another department you can quickly show the difference to him). Also process improvements (reducing the variants step by step) are an often used example. The use of variants for As-Is, To-Be handling is perhaps unexpected, but offers exactly the mentioned advantages. Keep in mind that you can create variances when you copy a model or later on, when you discover that similar models can be treated as variance. A variance goes always from the master to a variance, and this can also be hierarchically. Finally a variance can be set/removed on model or/and object level.

In terms of custom reporting such a variant link can be listed within a section called "Related Processes".

I see variants as a good approach to link and track the relation between As-Is and To-Be.

Advantage:

• report to compare model and object variances available

Disadvantage:

• none 

Note: see also link to another discussion below.

There might exist more alternatives, for now these are the once we are discussing. As we already see advantages and disadvantages for all of these, can you please share with me your thoughts how you would manage this requirement in respect to the high number of linked processes as mentioned above?

Current Suggestion

Whereas all mentioned alternatives are valid, a mix between the alternatives might be the best. We usually suggest to keep, coming from the root of the groups tree, as much as possible stable, means not divided into As-Is/To-Be. But from a certain point within the tree we need to distinguish between these stages and then we start with a dedicated group for the As-Is part and another one for To-Be.

It is very important to make sure that everything what is linked directly to the As-Is part stays stable!

Let's provide an example:

If you share data structures between As-Is/To-Be, and you are going to change these for To-Be, you may need to create another one, just to keep As-Is stable.

You might think about other situations, where e.g. a To-Be function name needs to be changed, but the underlying BPMN allocation diagram has to be then no more linked to the As-Is!

A good group structure and clear governance would help here much.

Any input is welcome!

Thanks a lot, Volker