Public Cloud: Das ist bei der Migration von VC nach AVC wichtig

Dennoch birgt die Migration von SAP LO-VC zu SAP AVC einige Herausforderungen. Eine davon besteht darin, während der Migration mit sechs neuen Transaktionscodes im Workspace und der Workbench zu arbeiten.

• VCH_L2A_WORKSPACES: (Transition Workspace):  Mithilfe dieses Codes können neue Arbeitsbereiche erstellt und sämtliche Änderungen im Arbeitsbereich vor dem Wechsel zur Advanced Variant Configuration gesichert werden. D.h. hier können Modelle hinzugefügt und die Migration der Modelle gestartet werden. 
• VCH_L2A_WORKBENCH: (AVC Transition Workbench): Wird genutzt, um alle erforderlichen Konfigurationen für die neue AVC-Umgebung vorzunehmen. Hier kann auch geprüft werden, ob sich das bestehende VC-Modell auf die AVC-Funktionalität migrieren lässt.
• PMEVC: Testet das migrierte Modell. Dadurch sind in der Modellierungsumgebung alle Abhängigkeiten zu den Objekten des neu erstellten Konfigurationsprofils sichtbar.
• VCHMOVMVAR: Wandelt Materialvarianten des LO-VC-Modells in das SAP-AVC-Modell um.
• VCHMOVCOMP: Vergleicht die Ergebnisseund bestätigt den Übergang zu AVC (Obsolet, durch Transition Workbench ersetzt).
• VCHMOVCOPY: Überführt das LO-VC-Modell in das Advanced Variant Configuration Modell (Obsolet, durch Transition Workbench ersetzt).

Ein Erfolgreicher Umstieg von SAP LO-VC auf SAP AVC setzt ein effektives Change-Management, eine umfassende Planung sowie die die Beachtung funktionaler und technischer Aspekte voraus.

1. Projektmanagement

Ein zentraler Punkt bei der Migration ist das Projektmanagement. Hier werden die Rahmenbedingungen für den Umstieg definiert. Drei Felder sind dabei von entscheidender Bedeutung.

• Projektplanung: Sie ist entscheidend, um Ressourcen effizient zu nutzen, zeitliche Vorgaben einzuhalten, Risiken zu managen, klare Ziele zu setzen, die Kommunikation zu fördern, das Budget zu kontrollieren und die Qualitätsstandards zu gewährleisten. So ist hinsichtlich der Migration von Lo-VC zu AVC über die verschiedenen Projektphasen eine vorausschauende Planung von essenzieller Bedeutung. Nach einer erfolgreichen Transformation sind abschließend Funktionstests zu konzipieren und durchzuführen, um die reibungslose Integration sicherzustellen.
• Definition Migrationsumfang: Nur ein ganzheitlicher Ansatz gewährleistet eine kohärente und effiziente Migration. Dabei werden Materialien, die untereinander verbunden sind oder ähnliche Merkmale aufweisen, zusammen betrachtet und migriert. Vier Kriterien sind dafür ausschlaggebend: Die Materialien stehen einer mehrstufigen Abhängigkeit zueinander, sie haben viele gemeinsame Constraints oder Prozeduren, sie besitzen einen ähnlichen Aufbau repräsentieren einen gemeinsamen Produktbereich.
• Change Management: Um die Einführung der neuen AVC-Lösung erfolgreich zu gestalten, ist es entscheidend, Schulungsmaßnahmen für Benutzer und Administratoren zu planen. Grund: Die ist AVC ausschließlich über FIORI zu bedienen. Daher ist die Entwicklung eines Change-Management-Plans von elementarer Bedeutung, um die Akzeptanz der neuen AVC-Lösung.

2. Technische Voraussetzungen überprüfen

Damit der Wechsel auf die AVC problemlos gemeistert werden kann, müssen zwei technische Voraussetzungen im Vorfeld überprüft werden.

• Kompatibilität: Vor dem Umstieg sollte die bestehende Systemarchitektur geprüft und bewertet werden, ob sie mit AVC kompatibel ist. Dazu gehört auch die Überprüfung der Datenmodelle und -strukturen in LO-VC sowie ein Check der allgemeinen Datenqualität.
• Kundenspezifische Konfigurationen: Zudem muss bewertet werden, ob individuelle Anpassungen oder Erweiterungen, die im LO-VC durchgeführt wurden, in AVC übernommen werden können. Außerdem sollte analysiert werden, ob spezifische Geschäftsregeln oder kundenspezifische Konfigurationen neu implementiert oder umgestaltet werden müssen.

3. Funktionale Anpassungen

Sind die technischen Voraussetzungen gegeben bzw. bewertet, müssen die unternehmensspezifischen geklärt werden – möglicherweise wurde die LO-VC speziell für das Unternehmen angepasst. Folgende vier Bereiche sind dabei von speziellem Interesse.

• Variantentabelle: Bei der Einführung von AVC gibt es das neue Datenobjekt „Verarbeitungsmodus“. Im Konfigurationsprofil, Beziehungswissen, Constraint-Netzen und Constraints kann jetzt anstelle der klassischen Variante nun Advanced Variant Configuration gewählt werden. Für die Migration ist es wichtig, dass alle Variantentabellen von „Classic“ auf „gemischt“ geändert werden. Wenn in der Low-Level-Konfiguration Beziehungswissen für die Maximalstückliste und den Maximalarbeitsplan erforderlich ist, ist es notwendig, den Verarbeitungsmodus "Classic" weiterhin zu verwenden, denn die Selektionsbedingung zur Auswahl von Stücklistenpositionen oder Arbeitsplanvorgängen basiert nach wie vor auf dem LO-VC-Verarbeitungsmodus. Im Produktvariantenkonfigurator wird der neue Verarbeitungsmodus "Advanced" für die High-Level-Konfiguration genutzt.
• Struktur: In der AVC werden Intervallzuordnungen als Merkmalswerte nicht unterstützt, möglicherweise erfordert dies eine Anpassung der Struktur der maximalen Teileliste und des maximalen Arbeitsplans.
• Abhängigkeiten von Drittanbieter-Integrationen: Falls in das aktuelle LO-VC-System Anwendungen von Drittanbietern integriert sind, ist es erforderlich, diese Integrationen zu prüfen. Möglicherweise müssen neue Strategien entwickelt werden, um die reibungslose Integration von Drittanbieteranwendungen in die AVC-Umgebung sicherzustellen.

• Funktionsbausteine: Der Übergang zur AVC wird für Anwender, die zuvor ihre Variantenkonfiguration mithilfe von ABAP-Funktionsbausteinen aufgrund interner Strukturen individuell angepasst haben, mit einem erhöhten Arbeitsaufwand verbunden sein. Der Grund dafür ist, dass in der AVC solche Variantenfunktionen ausschließlich über Business Add-Ins (BAdIs) gelöst werden können, was im Vergleich zu ABAP-Funktionsbausteinen als komplexer und aufwendiger betrachtet werden kann. Daher ist eine Anpassung des ABAP-Codings erforderlich, um es an die neue Struktur anzupassen. Es können generell folgende BAdIs implementiert werden:
  • VCH_HL_MD_DOMAIN_MODIFY: Ermöglicht sämtliche Merkmalswertdomänen jedes konfigurierbaren Materials eines Konfigurationsmodells zu modifizieren, sobald dieses Material erstmalig in die aktive Konfiguration geladen wird.
  • VCH_HL_PRE_VALIDATE_ASSIGN: Eröffnet Anpassungen an sämtlichen Merkmalsbewertungen in jeder aktiven Instanz des Konfigurationsstatus vornehmen, einschließlich aller nicht validierten Änderungen, die seit dem letzten Validierungs-Roundtrip durchgeführt wurden.
  • VCH_HL_POST_VALIDATE_ASSIGN: Damit sind Anpassungen an allen Merkmalsbewertungen in jeder aktiven Instanz des Konfigurationsstatus unmittelbar nach der Modellvalidierung möglich.
  • VCH_HL_ON_SAVE: Diese BAdI ermöglicht Anpassungen an sämtlichen Merkmalsbewertungen in jeder aktiven Instanz des Konfigurationsstatus direkt vor dem Speichern der Konfiguration vorzunehmen.