Use of Variant Models

Hi Ang,

The real benefit of variant handling lies in the fact that it enables the "model comparison" functionality. A "classic" example of its application could be if you had many locations all doing a "Customer Return" process but all doing it differently. You could create a "gold-standard" model from which you could then create a variant copy. This variant copy would then be modified by one of the other locations. After, because the system maintains a "master-variant" realtionship under the covers, you could comapre the two models (even down to the attribute level) and possibly modify the "gold standard" when befnefits are realized, thus creating a "new" gold-standard." If it were me, I would then delete that first variant and create a new variant from the "new" gold-standard which would then be given to the next location for them to modify to match thier process. Then that process gets compared to the "new" gold-standard etc. In this fashion, when all the comparisons and modifications are completed, you end up basically with a "best practice" process which can be used by all the different locations.

The only risk that I can see is that a variant copy actually creates definition copies of objects. For this reason, you may want to keep the variant models segregated in your group structure as there is a risk that an inexperienced modeler could reuse the wrong object.

Hope that was some help anyway....

Best Regards,

Bob

Hi Angie,

Creating variant copies like Bob said, gives you improved analysis/comparison ability.

The risk Bob pointed out is actually not a risk, as you can decide whether or not to create defintion or occurrence copies of objects.

The modellers would need some training around how to this properly so that they are aware of how to create variants with occurrence copies of the objects. So, it might be more work initially to use variants, but there will be time saving and easier analysis benefits later on.

Using this variant model with occurrence copy method, you will be able to reuse the objects from 'create sales order' process and add new objects which represent the steps unique to the europe process.

To create a variant with occurence copies of the objects:

1.  Right-click on the model in the nav tree. select 'new' > 'variant' from the context menu.
2. This will bring up a dialog box,
3. At step 1. choose to create a new model variant.
4. At step 2. ensure the 'reuse objects' checkbox is selected ALSO, select 'select objects...'.
5. This will bring up a list of the objects in the model, by default they are set to create new definition copies, so select all the objects and select the 'occurrence copy' button, this will change the objects' status to 'occurrence copy' (from new). Now the variant model will be created with occurrence copies of the objects.

Thanks Ben for your build on this thread! I guess the point around training the users on variant modeling ahead of time is really a key point here. The two key things to look after are:

1) Definition copies for your variants where modelers need to be sure (in the case of reusing objects) that the correct object is selected for reuse and,

 2) Occurrence copies for your variants where modelers need to be aware of changing the object on the "variant" model that would also change the object on the "master" model as well which would have an impact if you comapre the models down to the attribute level of detail. 

I agree.  We have had similar experiences with variant modeling.  Our biggest challenge has been maintenance.  Every time a variant changes, the models related to the variant may also need to change.  This had definitely been the downside for us.  Also, since variant functionality if advanced.  It has taken some time for our team to learn this new functionality.  I would not suggest variants for the beginning user.

Angie Walsh

Hi Sébastien,

I guess the main thing that variant handling offers is the fact that the system keeps track of the variant relationships between models. In other words, the system always knows which model is the 'Master" and which models are "Variants" of that "Master." I've made some screen shots to try to illustrate (as I'm not an expert on this but just want to offer what I think I know at this point...)

For the sake of discussion, I've created a situation such that "some organization" has 7 different locations and they are all doing the Customer Return Process differently. The goal is then to use "variant handling" to determine the "best practice" for all the locations to use (in other words, one common process).

They first model one process to be deemd the "Master" against which the 'Variants" from all the other locations will be compared. Once the 6 "Variants" are created, it is then possible to know all the "Variants" that have been created from the "Master" by looking to the "Model Properties" of the "Master" as below:

Further, you can look to the properties of any of the "Variant" models to learn its association to the "Master" model(s) as below:

This "tracking" of the variant relationships becomes increasingly valuable when you reach a situation where you begin creating "variants of variants" for example.

I believe this to be the benefit of creating variants.

Best Regards,

Bob

Hello Bob,

Thanks for your answer. If I understood correctly you can use variant copy for models (to keep the link) but the kind of copy for objects in the model must not necessarily be also variant copies then. You can use occurence  and definition copies as well depending the aim of the model.

A last question : would you think that it's a good way for handling the changes from AS IS to TO BE ? And why ?

Best regards, Sébastien.

Hi Sébastien,

Yes, your understanding is correct in that you get the choice of making either occurrence copies or definition copies of the objects during the creation of the variant model.

Regarding your follow-on question, two advantages for using the variant concept for 'As-Is/To-Be' modeling would be:

1. If you have the situation where you might be analyzing multiple 'To-Be' models I would elect to go this way

2. The variant relationship we spoke of earlier is actually consistent on a global basis. In other words, if you create the variant copy in one database, you could then merge that variant into another database (perhaps for a different country). The variant could then be modified and, finally, merged back into the original database (this is commonly referred to as a 'back merge'). The original variant relationship will not have been 'broken' or 'disconnected' in this scenario. So, the 'Master' will still know who the 'Variants' are and vice versa, in spite of the 'journey' taken by the Variant model in this case.

My humble opinion for you Sir,

Bob

OK great ! Thanks for the answer Bob :)

Even if point 2 doesn't apply for me so far it's really good to know about this possibility !

Have a nice day and week.

Regards, Seb.