SAP generally offers two versions of variant configuration for S/4HANA: the classic variant (LO-VC) and the modern Advanced Variant Configuration (AVC). Both are fully available in on-premise systems. However, anyone considering moving to the cloud must be aware that only the new AVC is available in the public cloud. However, this is not a problem, as both versions access the same configuration database and the same master data. Nevertheless, you should be aware that some of the functions differ and the operation is different.
Nevertheless, LO-VC users who have already considered switching to the new version can look forward to it, as SAP provides suitable tools for transferring the old configuration profiles to the new AVC. This means that nothing stands in the way of a smooth transition from classic to modern variant configuration.
The new variant configuration enables efficient and high-performance modeling when simulating large models with many features and deep parts list structures.
These transaction codes help with switching
Nevertheless, the migration from SAP LO-VC to SAP AVC poses a number of challenges. One of these is working with six new transaction codes in the workspace and workbench during the migration.
- VCH_L2A_WORKSPACES: (Transition Workspace): This code can be used to create new workspaces and save all changes in the workspace before switching to the Advanced Variant Configuration. This means that models can be added here and the migration of models can be started.
- VCH_L2A_WORKBENCH: (AVC Transition Workbench): Is used to make all the necessary configurations for the new AVC environment. It can also be checked here whether the existing VC model can be migrated to the AVC functionality.
- PMEVC: Tests the migrated model. As a result, all dependencies to the objects of the newly created configuration profile are visible in the modeling environment.
- VCHMOVMVAR: Converts material variants of the LO-VC model into the SAP AVC model.
- VCHMOVCOMP: Compares the results and confirms the transition to AVC (Obsolete, replaced by Transition Workbench).
- VCHMOVCOPY: Transfers the LO-VC model to the Advanced Variant Configuration model (obsolete, replaced by Transition Workbench).
The changeover: three important construction sites
A successful migration from SAP LO-VC to SAP AVC requires effective change management, comprehensive planning and attention to functional and technical aspects.
1. Project management
Project management is a key aspect of the migration. This is where the framework conditions for the changeover are defined. Three areas are of crucial importance here.
- Project planning: It is crucial in order to use resources efficiently, meet deadlines, manage risks, set clear objectives, promote communication, control the budget and ensure quality standards. Forward planning is therefore essential when migrating from Lo-VC to AVC across the various project phases. Finally, after a successful transformation, functional tests must be designed and carried out to ensure smooth integration.
- Definition of migration scope: Only a holistic approach guarantees coherent and efficient migration. Materials that are linked to each other or have similar characteristics are considered and migrated together. Four criteria are decisive for this: the materials have a multi-level dependency on each other, they have many common constraints or procedures, they have a similar structure and they represent a common product area.
- Change Management: To make the introduction of the new AVC solution a success, it is crucial to plan training measures for users and administrators. The reason: AVC can only be operated via FIORI. The development of a change management plan is therefore of fundamental importance to ensure acceptance of the new AVC solution.
2. Check technical requirements
Two technical requirements must be checked in advance so that the switch to AVC can be mastered without any problems.
- Compatibility: Before switching, the existing system architecture should be checked and evaluated to see whether it is compatible with AVC. This also includes a review of the data models and structures in LO-VC as well as a check of the general data quality.
- Customized configurations: It must also be assessed whether individual adjustments or enhancements made in LO-VC can be transferred to AVC. It should also be analyzed whether specific business rules or customer-specific configurations need to be re-implemented or redesigned.
3. Functional adaptations
Once the technical requirements have been met or assessed, the company-specific requirements must be clarified - the LO-VC may have been adapted specifically for the company. The following four areas are of particular interest.
- Variant table: With the introduction of AVC, there is the new data object "Processing mode". In the configuration profile, object dependencies, constraint nets and constraints, Advanced Variant Configuration can now be selected instead of the classic variant. For the migration, it is important that all variant tables are changed from "Classic" to "Mixed". If dependencies are required in the low-level configuration for the maximum BOM and the maximum routing, it is necessary to continue using the "Classic" processing mode, as the selection condition for selecting BOM items or routing operations is still based on the LO-VC processing mode. In the product variant configurator, the new "Advanced" processing mode is used for high-level configuration.
- Structure: In the AVC, interval assignments are not supported as characteristic values; this may require an adjustment to the structure of the maximum parts list and the maximum routing.
- Dependencies on third-party integrations: If third-party applications are integrated into the current LO-VC system, it is necessary to check these integrations. New strategies may need to be developed to ensure the smooth integration of third-party applications into the AVC environment.
- Function blocks:
The transition to AVC will involve more work for users who previously customized their variant configuration using ABAP function modules based on internal structures. The reason for this is that in AVC such variant functions can only be solved via Business Add-Ins (BAdIs), which can be considered more complex and time-consuming compared to ABAP function modules. It is therefore necessary to adapt the ABAP coding in order to adapt it to the new structure. The following BAdIs can generally be implemented:
- VCH_HL_MD_DOMAIN_MODIFY: Enables all characteristic value domains of each configurable material of a configuration model to be modified as soon as this material is loaded into the active configuration for the first time.
- VCH_HL_PRE_VALIDATE_ASSIGN: Opens Make adjustments to all feature scores in any active instance of the configuration status, including any unvalidated changes made since the last validation roundtrip.
- VCH_HL_POST_VALIDATE_ASSIGN: This means that adjustments can be made to all feature evaluations in every active instance of the configuration status immediately after model validation.
- VCH_HL_ON_SAVE: This BAdI enables adjustments to be made to all feature evaluations in every active instance of the configuration status directly before the configuration is saved.
