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
Volker,
This is one of the ways which could get complex very easily. You will need to have a strong governance and change management for what you have proposed above.
I do not recommend to have multiple DBs to manage AS-IS and TO-BE. At the end of the day it comes to managing multiple DBs and users. What if you need to refer to AS-IS maps, you will then need to move between the DBs.
I like the idea of using an attribute to manage/ identify AS-IS, TO- BE maps and also the naming convention for the maps.
In ARIS you can create variants between AS-IS and TO-BE. This functionality provides clear picture between the models at different stages/ release and also you can run reports to compare the models. Off course, you will need work through the group structure in ARIS. You can have something like AS-IS in development and TO-BE in development.
Also versioning can be used. However, with versioning the models are permanently locked.
Regards,
Rupesh
Alternative-1 -- using an Attribute seems to be interesting.. Though how it could help in replacing the "AS-IS" with new "TO-BE" model for new process to be release - does need to be thought about... Especially if you are using RCM or AGE.
Otherwise Alternative-4 is good if whole-some TO-BE changes are expected (most likely over a period) and Alternative-3 is good if TO-BE changes are likely to be within one or few processes only. Given the overheads in these approaches, strong govenance & Change Mgmt (as highlighted by Rupesh) is critical.
FYI -- This thread seems to be similar to the other recent post "How to create and maintain different versions of the same diagram".
Thanks & Regards,
Shankar
Hi,
In the discussion above Release Cycle Management is mentioned quite often.
How this is used? What is the procedure of using it? I tried to check help in ARIS, but description just mentions versioning and variants.
We have an open question: how to align releases of business processes in ARIS with releases of IT application. I was wondering maybe RCM can help here.
Thanks,
Hanna
Hi Hanna,
can you quickly describe what challenges you see in the release area to allow me a better response?
Is it that you like to "move" a group of processes beside (Release 1) and continue with another process group and call it Release 2? Are you going to bring changes back or is Release 1 only for bugfixing and any next enhancement will be tracked in the Release 2 group only?
Anything else you are looking for?
Thanks a lot, Volker
Hi Volker,
Thanks for response and interest, below I describe the situation we have:
1). We have ARIS database that describes processes of company department with three levels of process (from high-level to detailed and more detailed). The lowest level of processes involves application (interaction between application and users).
2). Let's say new changes are introduced: processes are changed and more manual things in the department become automated. First these changes are assigned to a new release of software, then you have to design this changes, then implement. (At this point you have two versions of diagrams: one for current 'version' of processes and software and one for new (changed)). But not all diagrams has to be changed. So what I mean here is that all 'changed' or impapcted diagrams can be called 'release' and once software changes are implemented and released the new diagrams become kind of released (become as-is instead of to-be).
Probably versioning is enough for this purpose. So my question about release management
was a kind of investigation of possible improvements.
Thank you. Let me know if more info is needed.