One of the things I do is work part-time within a business that has SAP Variant Configuration implemented. In fact, I was originally the consultant who had to build a proof of concept to show it would work in this industry. The industry is making windows and doors- sounds simple.
The requirement for the proof of concept was to be able to manage, among other things, the size, type and thickness of glass in each position of a window.
This one "simple" requirement drives the whole VC design and sets our naming conventions, BOM structure, Routing design, Class and Dependency approach.
The Consultant View
When you first implement VC where it has never been used before it is an interesting journey both for the consultant and the people in the business who will become "VC Modellers". As a consultant, you are trying to take them on a good practice journey so the models will be structured, adaptable and maintainable. As a consultant, you do not have the product knowledge they have, so you need to also train them on how to approach the VC Modelling task so they can apply it to the complexities.
Yesterday, Steve - one of the VC Modellers sat down for a chat. We went live with VC in mid-2016 so he now has good experience with the day to day upkeep of models. Often we do have modelling discussions about this and that, and ideas to improve things.
The VC Modeller View
What Steve likes about our models is that the fundamentals of our model structures are very simple. A sign of this is that he can explain the basics of the models to new people and they get the concepts. Through the good structure and naming conventions, they can see where to go in the model. Although you think a window or door is a simple product, the complexity in some areas is enormous.
The interesting thing Steve commented on was about a change of mindset. Bear in mind, this was the third ERP system that Steve had been through over the years with the previous systems being fixed BOMs (about 20,000) and so his role was more about the data and need to maintain lots of it.
Using VC, the mindset is different. Instead of thinking in legacy data thought patterns, he instead had to switch to a VC Modeller mindset. This is different, as instead of thinking in "20,000 BOM's" it is thinking in relationships and how they are represented. Because, really, that is what VC is all about. Relationships and how they are represented - in a class structure, in a BOM structure, in a routing design, in a variant table, and in constraint nets. So our 20,000 BOM's became around 40 models.
So when he looks at adding new models or enhancing existing models his other favourite concept is Plug and Play. As our models often share common sub-models, represented as assemblies or phantom assemblies, we wanted to be able to plug them into any model without any, or at least very little code changes. The idea is that they "just work". We got close to that when we first implemented but not quite as good as we wanted it. At the time we did not have the time to get this concept perfectly. But now, Steve knowing what is knows now has been working with the VC team to achieve a better result.
Since 2016 we have implemented two more plants, had significant changes in the way the business procures glass and components, added new products and all the usual business as usual things that happen, and the VC models we have, have been adapted and have been adaptable.
Are You Happy?
So getting back to "Are you happy?" For me, it is seeing the care we took in getting our building blocks in place for our VC models from the early days of the project to being used now for 3 1/2 years and seeing the design hold together has been pleasing. More pleasing is seeing the members of the VC team, who previously had no SAP or VC experience, now being very good modellers who like what the VC can offer and know how to follow our design approach.