Profile picture for user Volker Eckardt

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

by Rupesh Shrestha
Posted on Mon, 02/15/2010 - 00:29

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

0
by Shankar Ganesh
Posted on Mon, 02/15/2010 - 10:13

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

0
by Hanna Mironchyk
Posted on Tue, 03/23/2010 - 12:33

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

0
by Volker Eckardt Author
Posted on Wed, 03/31/2010 - 19:55

In reply to by tcaro

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

0
by Hanna Mironchyk
Posted on Thu, 04/01/2010 - 10:15

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.

0

Featured achievement

Question Solver
Share your expertise and have your answer accepted as best reply.
Recent Unlocks
  • CP
  • BZ
  • Profile picture for user TEF_Bernd
  • ПЦ
  • CR
  • PacMan

Leaderboard

|
icon-arrow-down icon-arrow-cerulean-left icon-arrow-cerulean-right icon-arrow-down icon-arrow-left icon-arrow-right icon-arrow icon-back icon-close icon-comments icon-correct-answer icon-tick icon-download icon-facebook icon-flag icon-google-plus icon-hamburger icon-in icon-info icon-instagram icon-login-true icon-login icon-mail-notification icon-mail icon-mortarboard icon-newsletter icon-notification icon-pinterest icon-plus icon-rss icon-search icon-share icon-shield icon-snapchat icon-star icon-tutorials icon-twitter icon-universities icon-videos icon-views icon-whatsapp icon-xing icon-youtube icon-jobs icon-heart icon-heart2 aris-express bpm-glossary help-intro help-design Process_Mining_Icon help-publishing help-administration help-dashboarding help-archive help-risk icon-knowledge icon-question icon-events icon-message icon-more icon-pencil forum-icon icon-lock