top of page
  • eLogic

SAP Variant Configuration (VC) Projects are not just about Modeling!

Working in the IT domain in the past years, I have come to realize that the technical realization of a project is one thing, but the planning and facilitation of it is another. In the Variant Configuration (VC) world, this is also true. Very often, a good part of the workload and challenge of VC projects find their source in things that are not related to modeling itself. With that in mind, here are several aspects of product modeling which can be easy to overlook, but are nonetheless crucial in having a smooth VC implementation.

The « Information » Problem

Some of the potential problems of a product modeling project are often caused internally, before the project even begins! The classic principle of entering data only once and at its source, as well as the “garbage in, garbage out” motto are absolutely relevant here. However and in reality, having 100% accurate, readily accessible data is not always achieved in the first place.

Duplicate or incorrectly-entered data sets linger in the database, causing confusion and potentially costly errors. The poor quality of data and the lack of consensus on it then creates a situation where the product models are open to interpretation.

When the time to switch to a variant configuration enabled environment comes, this same data is the one used as reference, which leads to problems. In some cases and after raising up ambiguities in the information which we were provided, it has occurred to me that customers could not agree internally on what the correct data for a model was, which is symptomatic of that problem. How can the VC model behave as expected, if the expectations of the model are not uniform in the first place? Also, not only does the data have to be accurate, it also has to be up-to-date, which can be a real challenge for bigger businesses.

Data Communication and Formatting

When there is a gap between a VC model and its real-life counterpart, it could be because of incorrect data on the product, as mentioned earlier. More often than not, however, it will be the results of gaps in the way the information was formatted and communicated. Obviously, this is much less likely if the information is communicated face-to-face in a workshop. However, given the nature of VC (basically a combination of choices which drive and restrict results), the information about models is often communicated by the customer via spreadsheets, or even just scans of whatever internal documents or tables they have available.

Budget-wise, the challenge here for companies is to find an effective way to translate internal documents into usable information for the consulting modelers. Rather than have the consultant spend time reformatting data, it can save time and costs in the long run to have internal employees prepare the data, as employees are more knowledgeable about their products than the consultants who are hired to help. It is also a good idea to establish some kind of convention on how the data should be formatted right at the beginning of the project.

Having Accessible Points of Contact

There are usually few projects where the entirety of the information on products is provided right at the beginning, and even fewer where the said information never changes throughout the different project gates. Therefore, there will most certainly be a need to have a person of contact to answer whatever questions consultants might have while modeling the products. When faced with an ambiguity in a product definition, modelers can either:

  • Make a best guess and risk having to revert many changes if it was not right, or

  • Wait for the right piece of information from a knowledgeable, available source.

In past projects I have worked on, work has had to be temporarily stopped until an ambiguity was resolved by a crucial piece of information. This can be a challenge for companies, since the people who know the most about a series of products are not necessarily the ones which are the most available. When manageable, companies should try to free some time for these resources, so that they can answer questions as soon as possible. It is also a good idea to establish quick communication channels like an instant-messaging application, as a quicker response to inquiries from the modelers means less bottlenecks in the overall completion of the modeling project.

Change Management and Attitudes

Finally, there is one last element that can totally change the way a project is both run and perceived by company employees and consultants alike: Change Management. Some might see the social aspect of such projects as the icing on the cake, but I see it as the lubricant of the whole “project machine”. It is surprising how taking people and their interests into consideration can change the day-to-day outcomes.

For companies, this translates into communication with employees before, during, and after the start of a project. Generally and to varying degrees, people don’t like when the way they work is changed – it means they have to learn new skills, and can impact their performance during the learning process. That is why process-altering projects like setting up a variant configuration enabled environment require strong change management. For example, while employees generally have an interest in knowing how implemented changes will benefit the business itself (because they are eventually indirectly impacted), telling employees how the changes will positively impact them directly will resonate even more with them, and make them more receptive to change.

Change management might be the responsibility of the company, but that does not mean that consultants cannot help with social aspects. Here is an example that personally occurred to me: While inquiring about a process at a customer site, I felt that one of the points of contact I was working with was perceiving me as a “consulting threat”. Instead of acting as if it was not happening, I took five minutes to stop talking about the process and instead ask him about the realities of his day-to-day work. He looked surprised that an external consultant would actually care about what he was doing instead of just demolishing the process he had been using for years. Let’s just say that his attitude completely changed after that, and he was much more receptive to my questions. Five minutes well spent if you ask me!

bottom of page