[go: up one dir, main page]

0% found this document useful (0 votes)
82 views55 pages

VC To AVC

The document outlines a workshop focused on the transformation from SAP ECC to SAP S/4HANA, specifically addressing the migration of LO-VC to AVC models. It covers the data migration process, procedural models, and best practices for successful transformation, including the Greenfield, Brownfield, and Bluefield approaches. Key tools and methodologies for data migration, including the 'Migrate my Data' app, are also discussed to facilitate a smooth transition.

Uploaded by

Gazet
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
82 views55 pages

VC To AVC

The document outlines a workshop focused on the transformation from SAP ECC to SAP S/4HANA, specifically addressing the migration of LO-VC to AVC models. It covers the data migration process, procedural models, and best practices for successful transformation, including the Greenfield, Brownfield, and Bluefield approaches. Key tools and methodologies for data migration, including the 'Migrate my Data' app, are also discussed to facilitate a smooth transition.

Uploaded by

Gazet
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 55

Tranformation Workshop

advanced variant configuration


Thomas Gelzhäuser, SAP

Public
Agenda

The Road from SAP ECC to SAP S/4HANA

Data Migration Cockpit

Procedural Approach Models

Transformation Steps from LO-VC to AVC

Demo incl. Simulation & Trace

Prepare Your LO-VC Models Today in ECC

Public 2
The Road from SAP ECC to SAP S/4HANA
v SAP S/4HANA Cloud v SAP S/4HANA Cloud v SAP S/4HANA
public edition private edition

Public
Availability of classic LO-VC and AVC
SAP S/4HANA Cloud
private edition SAP S/4HANA Cloud
public edition

SAP S/4HANA

LO-VC AVC AVC


Variant
Configuration
Configuration Data (cBase) Configuration Data (cBase)
Master Data VC-Model Master Data VC-Model

• Transformation of LO-VC
models to AVC models
supported

* SAP HANA Enterprise Cloud, SAP S/4HANA


Public 4
Source Target

→ S/4HANA
LO-VC
→ S/4HANA Cloud, Private Edition

SAP ECC LO-VC Migration


→ S/4HANA
AVC → S/4HANA Cloud, Private Edition
→ S/4HANA Cloud, Public Edition

→ S/4HANA
LO-VC Transformation AVC
→ S/4HANA Cloud, Private Edition
S/4HANA
S/4HANA Cloud, Private Edition
→ S/4HANA
AVC Replication AVC → S/4HANA Cloud, Private Edition
→ S/4HANA Cloud, Public Edition

Public 5
Transform LO-VC data (ECC) to AVC data (S/4HANA) directly

SAP S/4HANA Cloud


v public edition
v

AVC
SAP ECC
SAP ECC
Data
Migration
Cockpit

LO-VC
SAP S/4HANA Cloud
private edition

SAP S/4HANA

AVC

Data
Migration
Cockpit

Public 6
Transfer LO-VC data from ECC to S/4HANA and transform to AVC data later

SAP S/4HANA Cloud


private edition
SAP ECC
SAP ECC SAP S/4HANA

LO-VC LO-VC AVC

Transformation
Tools

Public 7
Transfer AVC data between S/4HANA systems

SAP S/4HANA Cloud


private edition
SAP S/4HANA Cloud
v public edition
v SAP S/4HANA

AVC AVC
Product
Data Replication
(PDR)

Public 8
“Migrate my Data” App

Public
Video
Migrate Data Using Staging Tables

Video
Using CSV Files to Fill Staging Tables

Public 10
SAP S/4HANA “Migrate my Data” – the next-generation data migration software

§ Included in SAP S/4HANA and SAP S/4HANA Cloud license Migration approach
and shipment Data Transfer

§ Made for migrating data from SAP and non-SAP sources into Migrate data using Staging Tables
SAP S/4HANA and SAP S/4HANA Cloud
§ Guided procedure takes users through the migration process:
Easy and safe, no programming required Predefined SAP S/4HANA-specific migration content
facilitates and accelerates your data migration
§ Flexible for integration of custom business data including data
§ Preconfigured content and mapping
transformations
§ Automated mapping between template and target
structure
§ Migration programs generated automatically

Public 11
Back to Agenda
SAP S/4HANA “Migrate my Data”
What it is designed for (in/out of scope)

Designed for:
§ Initial load of data
§ Used in context of a new implementation of SAP S/4HANA

Not designed for


§ Keep data in sync across systems*
§ Realize a continuous exchange or flow of data*
§ Cleanse data
§ Migrating data directly from SAP S/4HANA or SAP S/4HANA Cloud to SAP S/4HANA is
currently not supported.

* For this purpose SAP products like SAP Master Data Governance, Central Finance, Product Data Replication or SAP LT
Replication Server or SAP Data intelligence are available (list does not claim to be complete).

Public 12
Data Migration Process with SAP S/4HANA “Migrate my Data”
Overview

SAP S/4HANA Cloud,


public edition

SAP S/4HANA Cloud,


private edition
Select Get data Map and transform data Simulate Migrate
migration objects SAP S/4HANA
Model and design to reflect custom
requirements*

SAP Business Suite Legacy


* Migration object modeler available for SAP S/4HANA and SAP S/4HANA Cloud, private edition.
For SAP S/4HANA Cloud, public edition limited functionality – check SAP Note 2999428.

Public 13
SAP S/4HANA “Migrate my Data”
Step: select migration objects

Preconfigured SAP S/4HANA-specific migration content

What is a migration object?


§ Represents a business entity in SAP S/4HANA, such as a customer, sales order, or invoice
§ Encapsulates the logic to create the specific business entities through the corresponding APIs offered by SAP S/4HANA
§ Delivered by SAP based on SAP Best Practices configuration and are ready for immediate use
§ Categorized in master data and transactional data (no historical data)
§ Contains rules how values from source to target are handled – called “mapping”

What is migration content?


§ Migration content is the sum of all migration objects

Public 14
SAP S/4HANA “Migrate my Data”
Step: map and transform

Automated mapping between source & target

What is a mapping?
§ Data transformation or data mediation between a data source and a destination. Here, you map the source values,
which were extracted from the source system to the values and formats of the SAP S/4HANA system.
Example Source Dependency Type Target Dependency Type
1 Constraint → 11 Constraint AVC
2 Precondition → 12 Precondition AVC
5 Selection Condition → 15 Selection Condition AVC
6 Constraint Net → 16 Constraint Net AVC
7 Procedure → 17 Procedure AVC

§ The migration cockpit automatically provides proposals for mapping values, if possible. 1:1 mappings and rules are
predefined by SAP.
§ The mappings have to be maintained only once, they are used for all objects within a project.
Example You maintain the country key for migration object BANK, then all other objects in your project will use the same mapping.

Note: Check the object-related documentation for details on mapping. It is not necessary that the extracted data has to be provided how
SAP S/4HANA would expect.

Public 15
SAP S/4HANA “Migrate my Data”
Step: simulate and migrate

Guidance and simulation for the migration process

§ Data is posted to the SAP S/4HANA system via standard APIs. Therefore, data is created like it would be created
when it is entered manually in the SAP system.
§ All logical and semantic checks are done in the API.
§ During the simulation process, no data is written to the target SAP S/4HANA, but you can view all the messages that
would occur during an actual data transfer (for example information about a cost center that does not exist).

§ Objects can be simulated/migrated one by one – keep dependencies in mind.


§ There is no migration at database table level.
§ It is possible to simulate/migrate only specific migration object instances (single instances or a set of instances).

Public 16
SAP S/4HANA “Migrate my Data” – Enhancing Data Migration Performance
Further recommendations

Recommendations

§ Do not start the migration of all objects in a migration project in parallel. There is a sequence for migrating objects, because of the
dependencies between objects.
§ Parallelization is meant for migration objects with high data migration volumes.
§ Try to prevent many people working in parallel on separate migration projects.
§ Try to avoid that users trigger multiple activities for several projects in same data migration context.
§ Consider that uploading multiple objects in parallel can flood the job queue.
§ In our experience, it delivers better results to migrate one object with full number of jobs, complete the data migration and then start
the migration of the next object.
§ Even if you assign a higher number of data transfer jobs to run in parallel, the effect in the performance depends on the overall load of
the system.
§ Consider that there might be additional activities running on in the system that also fills the process queue.
§ If you experience performance problems, consider executing the data migration in time periods when the system has a low workload.

KBA 2878945 and KBA 3065607 provide information on parallelization of XML file loads and improving the performance of the data
transfer

Public 17
Procedural Models

There are different approaches to get your configurable LO-VC product model switched to AVC.

LO-VC

LO-VC AVC
AVC

AVC-Greenfield AVC-Brownfield AVC-Bluefield


§ Start from drawing board § Transformation of existing VC models § Mash up of brown- and greenfield

§ Reengineering and simplification § No change of existing structures § Selective VC model transformation

§ Going new ways and correcting past § Deep analysis of product model and § Mix of old and new world
mistakes past modelling technics

Public 18
AVC - Greenfield

The Greenfield method denotes a clean slate, a fresh start with SAP Advanced Variant Configuration from the scratch.

This entails extensive reengineering as well as the prospect of substantial process simplification.

This is based on the most recent technological breakthroughs. The Greenfield method ensures that the new implementation
adheres to SAP standards and modeling best practices.

Brownfield Bluefield
§ Transformation of existing VC models § Mash up of brown- and greenfield
§ XXX § Selective VC model transformation
§ XXX § Mix of old and new world

Public 19
AVC-Greenfield

Pro Contra
• Starting from scratch • More effort for design and implementation
• Reengineering of processes and product model • No historical data (documents)
• Concept development considering best practices
in modeling
• No need to bother with legacy systems/product
models with impromptu solutions, and various
settings
• Using full functions and potential of AVC

Public 20
AVC-Brownfield

The brownfield approach involves converting an existing LO-VC model into an AVC model.

As a result, this is an upgrade.


Processes, data, and individual advances are all moved to the new AVC engine.

The brownfield strategy is best suited for businesses whose existing configuration models have little heterogeneity
and are near to the SAP standard. This is because the present process and model complexity, which is often
heterogeneously created, is retained. As a result, the status quo is maintained.

Public 21
AVC-Brownfield

Pro Contra
• Almost no changes in configuration logic of • AVC full potential could not be realized
existing product models
• Limited possibilities for optimization and
• SAP tools for smooth and easy transition innovations
• No changes or adaptions to existing processes
• Saves time and budget

Public 22
AVC-Bluefield

For huge organizations with incredibly sophisticated structures, this is the most effective alternative.

Bluefield is a hybrid strategy that preserves the value of the present solution while providing for additional flexibility in the
go-live phase definition, allowing to transform or new design selected product models.

This can be a massive undertaking, but it offers the opportunity to re-evaluate past modeling and structures that have been
in place for years, if not decades. It also allows businesses to redesign their processes in accordance with the new functions
and options in AVC.

In this method it is essential to do a cost-benefit-risk analysis before deciding. Instead of focusing just on short-term
payback, part of the study should reflect longer-term potential advantages.

Public 23
AVC-Bluefield

Pro Contra
• Selective decision which product models are • More effort in maintenance of models
transformed, and which remains in LO-VC
• No interaction between both worlds
• Smooth transition from LO-VC to AVC
• Increased testing effort after transition
• Chance to get rid of past mistakes
• Best compromise between Greenfield and
Brownfield

Public 24
Parallel operation

Sales Logistics (SCM)

High-Level-Configuration Low-Level-Configuration
LO-VC Products

Classic Mode

AVC Products

• BOM explosion
• Routing explosion

Public 25
Planning and preparation are the nuts and bolts for a successful
transformation

Scoping Planning Realization Testing Go Live Hypercare

It's better to reach the goal with 6 steps than to break your legs in a big
jump....

Public 26
Best Practice in transformation from LO-VC to AVC
– 6 Steps –

SCOPING
Definition of the scope of transformation.

The following questions should be


answered after scoping:
• Which data models are to be
transformed into the AVC?
• In which sequence should the data
models be transformed?
• Should all LO-VC data models be
transferred to the AVC?

Public 27
Best Practice in transformation from LO-VC to AVC
– 6 Steps –

PLANNING
Planning of the transformation project.

The following points should be worked


through and formulated:
• Sequence of processing
• Which milestones need to be
achieved.
• Who is needed for the project?
• Which tools and instruments are to be
used.
• Definition of the test phase and test
scenarios.
Public 28
Best Practice in transformation from LO-VC to AVC
– 6 Steps –

REALIZATION
In the implementation phase, the activities defined
in the project plan are carried out and task
packages are processed.
The following items can be considered as task
packages with subtasks:
• Analysis
• Conception
• Adaptation/modification/correction
• Transformation
• Functional testing
Regular reviews and dailies serve to evaluate,
coordinate and monitor the progress of the
project.

Public 29
Which Objects can be transferred from LO-VC to AVC?

LO-VC model AVC model

Configuration profile Configuration profile

Object dependencies Object dependencies

Variant table Variant table Variant table


classic mixed advanced

Classes

Characteristics

Materials

BOM`s

Routing

Public 30
Best Practice in transformation from LO-VC to AVC
– 6 Steps –

Realization phase
Definition of Analysis of Data Adjustment Release Transfer Material
transformation model(s) Transformation
LO-VC and AVC AVC Data model(s) variants
scope

Public 31
Instead of (p)functions – Use BADIs to implement custom logic

BADIs can be implemented in all S/4 Editions (including Public Cloud Edition)

Use BADI-Filters to select when they are triggered (e.g. per KMAT, per Plant, per Document Type)
Available BADIs:
- Enhancement Spot: VCH_HL_ES_CORE
- VCH_HL_MD_DOMAIN_MODIFY – change characteristics domains on loading master data (called for
each class in the model)
- VCH_HL_PRE_VALIDATE_ASSIGN – called before validation, change values that are used in validation
- VCH_HL_POST_VALIDATE_ASSIGN – called after validation, calculate additional values after validation
- VCH_HL_ON_SAVE – change characteristics before saving to CBASE

- Enhancement Spot: VCH_HL_CLOUD


- BD_VCH_HL_PRINTING – Select which characteristics are printing relevant

Public 3232
Best Practice im Transformationsprozess
– 6 Steps –

TESTING
In the test phase, integrative tests within the
process chain must be performed in addition
to the pure functional tests.
This means that the previously defined E-2-E
test scenarios must be successively tested,
and the results documented.
A great deal of attention should be paid to
customer-specific functions that deviate from
the AVC standard.
Best practice at this point is to always perform
a direct comparison between the configuration
results of the LO-VC and those of the AVC.

Public 33
Best Practice im Transformationsprozess
– 6 Steps –

GO LIVE
The multiple assignment of configuration
profiles makes it possible to set the new
AVC profile productively conveniently via
ECN or key date.
The advantage is that that the old LO-VC
configuration profile doesn’t need to be
deleted and by using an ECN the AVC
configuration profile can be locked.

Public 34
Best Practice im Transformationsprozess
– 6 Steps –

HYPERCARE
Within the maintenance phase, further
optimizations and possibly minor error
corrections are to be carried out.
Furthermore, after stabilization of the
data model in this phase, the functions
and special features initially excluded
from the transformation can be
considered again and analyzed and
conceptualized for the AVC.

Public 35
Useful transactions

Transaction code Description


VCH_L2A_WORKSPACES LO-VC - AVC Transition Workspaces
VCH_L2A_WORKBENCH LO-VC - AVC Transition Workbench
VCHMOVMVAR AVC: Switch Material Variants

Public 36
Procedural approach models

Which approach suits the best for me?


At the beginning of a transformation project, the question always arises, “which color suits us the best?”.
Unfortunately, this question can only be answered by a typical, partly unsatisfactory sentence...

IT DEPENDS...
AVC-Greenfield AVC-Brownfield AVC-Bluefield
High use of complex procedures Mainly SAP LO-VC standard High mix of minor complex and
structures very complex product models
Use of many individual functions Little to none (P)FUNCTION in Fast product lifecycle with range
(P)FUNCTION operations of models close to cycle end
Very deep configuration High overlap of global object No solutions to replace individual
structures with interactive dependencies functions by BADI and or syntax
configuration over multiple levels elements
Predominant use of constraints

© networker,
Public solutions GmbH | 2023 | CWG - AVC transformation Workshop 3737
Simulation & Trace

Public
Sequence of High Level Dependency Processing

Special Assignments

Restrict Solution

Regular Assignment

Restrict Solution

Public 39
BOM Explosion Strategy & Instance Activation

Breadth-first manner
• Level by Level
1
• Left-to-right activation inside a level

Instance Activation (selected components only)


• Constraint Matching
• Value Assignment by User, Procedure etc.
2 3 4
Any time for active instances
• Constraint Processing

Facet dependencies are processes after all instances 5 6 7 8


are activated and solution cannot be restricted anymore

9 10

Public *see „SAP S/4HANA for Advanced Variant Configuration 2108 CE / 2021 OP Improvement List“ page 10 & page 14f 40
Sequence of High Level Dependency Processing for Each Instance

2 3 4

5 6 7 8

Special Restrict Regular Restrict


Assignments Solution Assignment Solution

• Template Pattern Restriction • Initial Constraint • User Assignments • Constraint Processing


• Master Data Assignments Processing • External Assignments
• Assignments of Static Defaults
• Procedure Processing

• Unassign Defaults
leading to
inconsistency!

Public 41
Prepare Your LO-VC Models Today in ECC

Public
Some Notes…

3217211 - Restrictions for Advanced Variant Configuration SAP S/4HANA 2208 CE and 2022 OP

3366124 - Advanced Variant Configuration 2023 - Improvement list compared to LO-VC

Public 43
Prepare Your LO-VC Models Today in ECC

• How do I model so that it behaves as similarly as possible in the AVC.


• How do I model so that I have good performance in the AVC after the switch?
• How do I avoid the things that the AVC can't do yet?

Public 44
Constraint-based Modeling

Always use constraints when possible. Other dependency types should only be used if a
constraint can't be used.

Procedures only in exceptional cases, e.g.


• Use of Not Specified
• Setting of Default Value

Precondition on Characteristic Value only in exceptional cases, e.g.


• Use of Not Specified
• Restricting Multi-Valued Characteristics*

*Multi-valued Characteristics can be restricted via constraints in AVC, but not in LO-VC.
Public 45
Constraint Processing

Align the behavoir of constraints in LO-VC and AVC


• set all characteristics to restrictable (all cstics are restrictable in AVC)
• avoid use multi-valued characteristic (never restrictable in LO-VC)
• avoid if-condition in Restriction-Part (AVC infers right side of if)
• infer all values in Inferences-Part (AVC does not need/ignores the Inferences-Part)

OBJECTS: OBJECTS:
cuboid (300) rect_dim. cuboid (300) rect_dim.

RESTRICTION: Condition:
cuboid.volume = cuboid.height * cuboid.length * cubiod.width cuboid.height < 100.
if cuboid.height < 100.

RESTRICTION:
INFERENCES: cuboid.volume = cuboid.height * cuboid.length * cubiod.width.
cuboid.volume.

INFERENCES:
cuboid.volume, cuboid.height, cuboid.length, cubiod.width.

Public 46
Variant Table Content

Use variant table with discrete values; each cell must be valuated with at least one value.

No empty cells

No cells with intervals


• use of cells with intervals to check condition work equal in LO-VC and AVC
• use of cells with intervals to assign values in procedures work differently in LO-VC and AVC
• use of cells with intervals to restrict values in constraints work differently in LO-VC and AVC

Processing Mode for Variant Tables in S/4HANA


• Normalized tables can be used in Mixed Mode
• Tables with empty cells can only be used in Classic Mode
• Tables with intervals must be assigned either to Classic Mode or Advanced Mode – no Mixed Mode

Public 47
Procedures With Multiple Statements

Ensure, that all statements of a procedure are processed.

AVC does not terminate the procedures, if an assignment cannot be executed


• ensure, all cstics on right sub-statements have a value assignment
• split sub-procedure into single procedure if a missing assignment could terminate the procedure

LO-VC AVC
* always executed * always executed
$self.X = 1, $self.X = 1,

* only executed if $root.C is specified * only executed if $root.C is specified


$self.Y = $root.C,
=
if $root.C is
may not specified
$self.Y = $root.C,

* explicit statement to terminate further processing of procedure


exit if $root.C not specified,

* only executed if $root.C is specified * always executed, if procedure is not terminated explicitly
$self.Z = 2. $self.Z = 2.

Public 48
Multiple Configuration Profile

Merge multiple profiles (same process) assigned to one material

Configurable Item Configurable Item

✘ ✓
1 Plan/Prod. Order
AVC selects configuration profile always 1 Plan/Prod. Order
2 Plan/Prod. Order
automatically
• harmonize dependencies in the Configurable Item Configurable Item
multiple profiles of same process
✘ ✓
1 Order BOM
(e.g. Plan/Prod. Order) as far as 1 Order BOM
2 Order BOM
possible
• distinguish not harmonizable Configurable Item Configurable Item
dependencies by a helper
✘ ✓
1 Sales Order (Set)
1 Sales Order (Set)
characteristic 2 Sales Order (Set)

Configurable Item


1 Plan/Prod. Order
2 Order BOM

Public 49
High-level valuation in low-level

Avoid valuation of high-level characteristics in procedures assigned to a BOM item

Check procedures assigned to a BOM item


• change valuation of BOM reference characteristics only in procedures on BOM items
• assign procedure on BOM items to configuration profile if non-reference characteristic is changed by this
(may add an additional condition)

Public 50
Sales Order (Set) Modeling

Consider circling to model AVC Sales Order (SET) scenario - see Note 3190519
all items are
Sales Set assigned to the
Constraint for X same class
Constraint for Z
• do not use $root for shipping items
and lower sub-assemblies to refer to Cstic X
the Sales Set
• assign constraint to instance with
Sales Set to inherit values from Sales Shipping Item Shipping Item
Set to Shipping Item section Constraint for Y
• assign constraint to instance with Cstic X Cstic Y
Sales Set to set relationships Cstic Y Cstic Z
between different Shipping Item
sections
• assign constraint to instance inside a Sub-Assembly
Shipping Item section to set
Shipping Item Section

Shipping Item Section


relationships inside the same Cstic Y
Shipping Item section Cstic Z

Public 51
Performance - Variant Tables and Key Accesses

Improve performance for variant table processing


Use of variant tables can may
improved esp. for

• very large variant tables Use condtions in constraints, if table lookup


(may linked to database table) is only relevant when specific characteristics
have already been valuated
• characteristics with many
discrete values are used with
large variant table

Nevertheless – the use of variant tables for restrictions is often recommended


Public 52
Performance - Overwrites and Procedures

Improve performance of dependency processing

• Overwriting procedures should not be used at all if possible


• If overwrites can’t be avoided, try not to address the affected characteristics in constraints additionally.
• Default values should be set last

$self.X = 2
$self.X ?= 1.
if $self.A = 1
and ( $self.B <> 1 or not specified $self.B),
$self.X = 2
if $self.A = 1, $self.X = 3
if $self.B = 1,
$self.X = 3
if $self.B = 1.
$self.X ?= 1.

Public 53
Avoid the things that the AVC can't do yet*

This list names the most common cases only


• not supported modules or objects (e.g. SAP PS, SAP PP-PI)
• not supported configuration scenarios
• scenario combination of Sales Order (Set) & Order BOM
• configurable items without configuration profile
• recursive Bom explosion during configuration
(valuation of lower components enforces Bom explosion of upper components)
• function & pfunction which cannot be transferred to the AVC BAdIs
• multi-valued cstic bound to variant table
• not supported Syntax (e.g. $SUM_PARTS)

* most topics are categorized as Future Innovation, please check roadmap in time
Public 54
Thank you.
Contact information:

Yong-Gün Hesse
y.hesse@networker-solutions.de

Andreas Koelbl
andreas.koelbl@sap.com

© 2023 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.

You might also like