When creating a model variants there is a nice option to select how to reuse objects - as new occurrences or new definitions. When modeling a new variant (a TO-BE for example) there are several approaches:
1. All objects in the control flow are new definitions and all library objects that are not expected to change - occurrences (my preference so far)
2. Occurrences for all objects that will have no change
3. Definitions for all objects
In some cases the choice is obvious but in others, for example when simulation for both AS-IS and TO-BE is to be done, and all variants may have new versions, it's not anymore.
Please share your experience and recommendations.
Thanx.
Ivo
First of all I would do Simulation(s) in a seperate database, since you might want to create multiple "futures" and need definition copies of the objects to play around with the different attributes (e.g. # of people in an org unit for utilization). The successful simulation result should then go back into your work DB.
I like to use variants for End-2-end scenarios which show the scope of an individual implementation project. For this you should use occurences of the objects IMHO, but save the E2E in a separate archive DB after it was approved to be the baseline of the implementation (or version it). You can then compare the saved E2E (and the assigned EPCs below) and see what was changed during the system configuration - for whatever reasons: constraints, missing parts in the E2E, ...
Excellent timing, Ivo - Just couple of days back, one of our teams was discussing on the "good" guidelines around Model Variants (for EPCs) and these are some of the aspects that came out:
- General recommendation will be to create model variant thru the wizard rather than trying to copy & paste objects as variant (since in the wizard you can clearly select which all objects should be variant / occurrences / definition copies, in one shot for the entire model).
- All library objects should be occurrences in the variant process model as well -- unless a different library object(s) will replace the existing one(s).
- Events will always be definition copies (should not be variant objects).
- Only Function objects within EPCs can be variant objects -- as required. Incase the functions are same in both master & variant process, keep it as occurrences and if they differ those function object will be made variant.
- Although internally the master & variant relationship is maintained, debate is still on as to whether the master & variant function objects should be prefixed with "M_" & "V_" respectively -- so that the viewer can identify them while viewing the model, without having to look into the properties (Would welcome comments on this guideline).
Open issues, where no concensus evolved:
- Where could the info on the need for process variants be captured for each such function or at the process model level? Does ARIS Method provide any attribute to capture this specific info or is it supposed to be in Description or User attributes?
- What type(s) of group structure is recommended to maintain these variant models & objects?
- What best practices / recommendation does IDS provide on this?
Would welcome more sharing of experiences & suggestions on this.
Thank you for this comment, Ganesh. I agree with most of your points. Just I'm not sure about:
- the function objects being variants as this would require additional effort and I doubt it would pay off
- I fully understand the benefit of having unchanged functions as occurrences but as I wrote above, what about simulation? The idea of Roland is OK but that means merge which I don't like and additional effort for coordination with analysts to know at each moment in which DB is the latest version. That's the reason I still prefer to have identical functions in TO-BE variants as definition of their counterparts in AS-IS and occurrence in other model variants of the same TO-BE set. This way simulation could be run on both AS-IS and TO-BE models with the freedom to change attribute values of TO-BEs easily as opposed to - making a definition when at certain point (like trying some what-if scenario) you want to change something on a function initially planned to remain the same. So the attribute criterion for identical objects in Model comparison report supports well this approach. However, the problem with library objects remains that's why it's difficult for me point out a clear winner approach.
Re: open issues #2 I used to do AS-IS and TO-BE group at the same level of hierarchy and then started to put TO-BEs inside AS-IS group to save up one click any time an AS-IS model should be accessed.
