Skip to Content

This blog differs slightly from my previous two conference blogs. This is not so much about my learnings & insights from excellent customer presentations, but rather my own learning journey in the preparation for a preconference deep dive workshop on variant configuration.

Individualisation everywhere

Variant configuration used to be a topic mainly for discrete manufacturing industries, like when configuring a car or a PC. Today, variant configuration is everywhere. We configure pizzas, cerial, sneakers and T-shirts, but also steel-coils, corrugated packaging or furniture.

Sales configuration and beyond

SAP has a long history with many thousands of customers using variant configuration both in the ERP backend and in customer facing solutions. I would like to emphasize, that we are not simply talking about a sales configurator, but an integrated product model that touches many aspects from pricing, costing, production, quality and inventory management – and all the customer facing touch points.

The focus of my workshop was to look at new solution capabilities with the new SAP Advanced Variant Configuration (AVC) in SAP S/4HANA, and the equally new SAP Product Configuration in SAP Cloud Platform (and its role related to configuration in commerce, sales and CPQ).

Like in the old days, product definition decisions define your options in selling, how flexible you can act in supply chain planning, and also the granularity in reporting and execution.
When planning a move to SAP S/4HANA, I recommend to seriously consider the AVC (and its roadmap) to be future-proof and compatible with future plans for customer facing capabilities.

How the transformation towards an intelligent enterprise impacts variant configuration

The below slide is the core of SAP’s intelligent enterprise vision, and it’s well worthwhile to understand how this relates to the future of variant configuration. First of all, there’s the intelligent suite purpose built for a modern in-memory platform with a consistent integration and user interface across the suite components. For variant configuration, let’s focus on the digital core, SAP S/4HANA. The new AVC (and the classic LO-VC) reside here. They are complemented with new intelligent technologies like advanced analytics and machine learning. The SAP Cloud Platform plays an essential role integrating variant configuration into SAP’s customer experience solutions. The new SAP Product Configuration and Pricing services run as part of the SAP Cloud Platform, and power variant configuration e.g. in commerce or CPQ. The new SAP Product Configuration Intelligence, also on the SAP Cloud Platform, is intended to deliver additional machine-learning powered capabilities like a budgetary quote or guided configuration.

SAP C/4HANA and SAP S/4HANA play here hand-in-hand with one seamlessly integrated configuration model. The product model is defined in the SAP S/4HANA backend, and utilized in SAP C/4HANA’s sales and commerce solutions.

But let’s now take a closer look at the individual components, and let’s start with SAP S/4HANA.

SAP S/4HANA Advanced Variant Configuration

What’s new in SAP S/4HANA

First things first, and then let’s look closer at each of these:

  • SAP has built from scratch a new high level configuration optimized for SAP HANA and SAP Fiori (which is called the AVC).
  • Everything around low level configuration (BOM and routing explosion) has been also optimized for SAP HANA.
  • There are new embedded analytics based on core data service (CDS)-views.
  • The classic LO-VC variant configurator is still available in SAP S/4HANA, for compatiblity and ease-of-migration purposes .

If you do simply a technical migration to SAP S/4HANA you will immediately be able to benefit from the embedded analytics that will work with both LO-VC and AVC. Find more information in the cookbook of SAP note 2438550.

The optimizations in low level configuration may bring significant performance improvement in the MRP-run – but only if your VC-model can be translated so it can run in the HANA layer. Especially variant functions may be an issue here. Please consider SAP note 2639994
in migration preparation. If the MRP-dispatches realizes a product cannot be planned in the new MRP-live, it will execute the classic MRP-logic in the ABAP-layer. To check whether a product benfits from the optimization, you can run report PPH_CHECK_MRP_ON_HANA.

I already mentioned that the LO-VC and the AVC “co-exist” in SAP S/4HANA.

Material definition, classes, characteristics, BOM and routing related low level object dependencies are common for both. Whether to use the classic LO-VC or the new AVC can be decided model by model. Typically, you would do this on the level of the configuration profile and the object dependency.

Why would one consider to use the classic LO-VC at all?

First, for migration purposes e.g. migrating existing models first to LO-VC and then check model by model whether they are compatible with AVC. Secondly, for new models, if the AVC does not yet cover all required features (that may be available in LO-VC). Check the AVC roadmap for details.

Ideally, new models would be created in AVC, benefitting from the new constraint solver, higher calculation accuracy, and powerful new syntax capabilities.
But, at the time of the workshop, variant functions were not supported in AVC, yet. Thus, if you’re model required those, you would still need to use the classic LO-VC for now.

The new AVC comes with a number of exciting new features, both on the front-end for the user, like the new simulation environment. This is a huge step forward and helps modelers to simulate and test model changes, and to get explanations on the calculations within the model itself.

Under the hood of the AVC, not visible to the user is a brandnew configuration engine and constraint solver. I will not dive into every new feature on a technical level. From a mill products perspective, I am very happy to see the increased accuracy in numerical characteristics and in calculations. At the CWG, and also as part of our demo, we showed below simple example with a few formulas within a constraint. What you should remember:

The new AVC is significantly faster with constraints. Constraints can solve equations efficiently in multiple directions with much higher accuracy than LO-VC.

 

Migrating from LO-VC to AVC

As said before, SAP S/4HANA supports both LO-VC and AVC. You have the option to run the one or the other, or also run in a “mixed” mode where you decide model by model which engine to use. The new master data attribute “processing mode” controls which engine is used. You can set this at the level of the configuration profile, a constraint net, or an object dependency.

The advanced syntac check in the Product Modeling Environment for Variant Configuration (PMEVC) includes now an option to check if a product model is AVC-compatible.
There are also a number of conversion tools available. Find more information here.

To use BRFplus, or rather not?

We had a good discussion during the workshop whether or not to utilize BRFplus, to complement variant configuration, and its benefits and disadvantages. I will not dive into this here, but would sum up a few conclusions of the group:

  • BRFplus is a powerful standard tool that has advantages over hand-written variant function ABAP code, separating code from rules logic.
  • BRFplus can be deployed in applications where variant configuration is not available
  • BRFplus, like variant functions, is currently not supported in AVC
  • BRFplus cannot be exported via knowledge base to C/4HANA and SAP Product Configuration on the SAP Cloud Platform
  • As a default, wherever possible stay in one tool and work with constraints and “normal” object dependencies, and not with BRFplus. We agreed that there are problems that currently can’t be addressed in VC/AVC alone.

SAP C/4HANA and Variant Configuration

Let’s shortly recap what’s we mean with SAP C/4HANA. This includes:

  • the SAP Commerce Cloud. This is what B2B byuers and B2C consumers use.
  • SAP Sales Cloud. This includes SAP Configure Price Quote (CPQ)

Both solutions are using the same common microservices for CPS (Configuration and Pricing Services) and PCI (Product Configuration Intelligence) running on the SAP Cloud Platform

.

Thus, master data for variant configuration is created in S/4HANA, and sent as a “package”, a so called knowledge base, to the SAP Cloud Platform Configuration and Pricing Services (CPS). As soon as someone configures a product e.g. in Commerce, the CPS is called to validate and calculate the results.

What you should take away:

We run an fully integrated process between C4C, CPQ, Commerce Cloud, ERP or SAP S/4HANA for configurable products.

The SAP Cloud Platform takes an essential role here, and decouples the front-office C/4HANA to the back-office S/4HANA. We do not need to call back into S/4HANA.

Alternative approaches and considerations

The above process integration architecture is the SAP standard approach that is cloud-centric (and thus does not want to ask the backend after each user interaction in the webshop) and follows an asynchronous order integration.

This approach has challenges when you need tight synchronous integration, or your configuration model needs to execute complex ABAP or BRFplus logic in the backend to give correct responses in the webshop. In our workshop, we had intense discussions whether you should simply expose the fully complexity of the backend configuration model to the webshop. We could agree that we need to have a simpler in the webshop, but need to ensure that we only sell feasible “combinations”, and guide the user towards those.

At the conference, there was also an interestingly different approach presented by both Mondi and Aicomp, where their Cloud for Sales solution is tightly coupled to the backend configurator. The performance during the demo was impressive.
I can well imagine this tightly coupled scenario to work in a CPQ process. I doubt the scalability of this set-up for an “open” B2C-like E-Commerce scenario.

Product variants in Commerce Cloud

Material variants are a commonly used modeling approach in mill products, but we use them a little smarter than the others. Everyone (should) know configurable materials, and many know fully configured variants. The first are basically emty templates, the latter are fully specified in all their options. In mill products, we often use configurable variants, like a template from which you can deviate.

Configurable variants are now also supported in Commerce (but only for single level variants and plant-independent variants).

Product Configuration Intelligence

When I mentioned the intelligent enterprise vision above, I indicated that we want to use machine learning and artificial intelligence to be smarter about what we do in variant configuration. Entering the stage: SAP Product Configuration Intelligence.

There are a number of interesting use cases here, and the roadmap will depend a lot on customer influencing. I would be most interested in the last of the three, driving product selection based on functional needs. Make sure to join the CEI (customer engagement initiative) to push this into the right direction.

 

Conclusion

Variant configuration has been around a long time. I am very excited to see the momentum and the investment behind the SAP S/4HANA and SAP C/4HANA based new solutions.
I realized that 3,5 hours are not enough to cover everything, even less a single blog.
Make sure that you are part of our customer influencer groups, and best also join SAP Configuration Workgroup to be on top of things.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply