De strategie vereist een hybride benadering die SAP Information Lifecycle Management (ILM) voor historische data-extractie combineert, een tijdelijke MuleSoft integratielaag om de continuïteit van de orderstroom tijdens de TSA-periode te behouden, en een gefaseerde Salesforce-implementatie waarbij klantgerichte processen voorrang krijgen boven financiële sluitingsmogelijkheden. Deze architectuur voldoet aan de nul-downtime vereiste door een tijdelijke brug tussen de productie modules van de moedermaatschappij in SAP en de nieuwe Salesforce CRM-instantie te behouden. De specificatie van de vereisten moet de grenzen van datagebruik vastleggen, protocollen voor real-time synchronisatie van in-flight transacties en mechanismen voor het behouden van onafhankelijke auditsporen documenteren om te voldoen aan SOX IT General Controls (ITGC) vereisten.
Probleembeschrijving
Een wereldwijd productieconcern was bezig met de verkoop van zijn divisie voor speciale chemicaliën aan een private equity-firma. De divisie had 15 jaar binnen de SAP S/4HANA omgeving van het moederbedrijf gewerkt en deelt klanten, leveranciers en grootboekrekeningen met vijf andere divisies. Intercompany-verkopen vertegenwoordigden 40% van de omzet van de divisie, met transacties die via de gecentraliseerde treasuryfunctie van het moederbedrijf stroomden. De Transition Services Agreement stond slechts 90 dagen toe voor een volledige operationele scheiding, terwijl de divisie 2.500 actieve klantorders in behandeling had, en de koper onmiddellijke SOX-compliance vereiste om hun geplande IPO binnen 18 maanden te ondersteunen. Het moederbedrijf weigerde om verdere systeemtoegang te bieden na de TSA-periode, en de Salesforce-instantie van de koper moest zowel CRM- als order-to-cash-processen afhandelen zonder de diepgaande productie modules die beschikbaar zijn in SAP.
Oplossing 1: Big Bang Cutover met Volledige Data Migratie
Een benadering die werd overwogen, was het uitvoeren van een enkele weekend cutoff waarbij alle 15 jaar historische data zou worden geëxtraheerd, ontdaan van intercompany-transacties, en geladen in Salesforce met een aangepast datamodel dat de structuren van SAP nabootste. Dit zou inhouden dat alle transacties gedurende 72 uur werden bevroren terwijl de SAP LDS-tools de data-objecten van de divisie afsneden.
Voordelen: Schone scheiding, geen lopende integratiecomplexiteit, onmiddellijke onafhankelijkheid van de systemen van de moedermaatschappij.
Nadelen: Veraagde de nul-downtime vereiste van de TSA; Salesforce ondersteunt geen complexe productie BOM's en kostprijsadministratie, wat enorme maatwerkontwikkelingen vereiste die niet binnen 90 dagen konden worden voltooid; het risico op gegevenscorruptie tijdens de transformatie van de 15-jarige geschiedenis was onaanvaardbaar hoog gezien de vereisten voor de IPO-audit.
Oplossing 2: Verlengde TSA met Gefaseerde Migratie
Een andere optie was onderhandelen over een verlengde TSA van 12 maanden, waarbij de divisie SAP voor financiële sluiting zou blijven gebruiken terwijl klanten geleidelijk naar Salesforce voor nieuwe bestellingen zouden worden gemigreerd.
Voordelen: Verminderde technische risico's, gaf tijd om juiste Salesforce-aanpassingen voor productieprocessen te bouwen, en behield de toegankelijkheid van historische data in SAP tijdens de transitie.
Nadelen: De private equity-investeerders van de koper weigerden de aansprakelijkheidskosten van de verlengde TSA-kosten ($500K per maand) te accepteren; SOX-auditors vereisten dat de divisie binnen 90 dagen onafhankelijke controleomgevingen demonstreerde, wat niet kon worden bereikt terwijl ze nog gebruik maakten van de SAP-instantie van de moedermaatschappij; historische intercompany-transacties moesten als externe verkopen worden herclassificeerd, wat niet kon worden uitgesteld.
Gekozen Oplossing en Resultaat
Het team selecteerde een Dual-Run Architectuur waarbij MuleSoft als een tussenliggende integratiebus fungeerde. Gedurende de eerste 60 dagen werden nieuwe klantorders in Salesforce ingevoerd maar stroomden via MuleSoft naar de SAP van de moedermaatschappij voor verwerking, terwijl de extractie van historische data parallel verliep met gebruik van SAP Information Lifecycle Management (ILM) met aangepaste regels om intercompany-transacties te splitsen. In de dagen 61-90 schakelde de orderverwerking over naar een tijdelijke Microsoft Dynamics 365 instantie (al SOX-gecertificeerd) voor productie-operaties, terwijl Salesforce CRM en offertes afhandelde. Historische data werd gearchiveerd in AWS S3 met Snowflake die doorzoekbare auditsporen voor de 7-jaar vereiste bood, in plaats van te proberen alle geschiedenis in operationele Salesforce-objecten te migreren.
Deze benadering voldeed aan de TSA-vereisten door de continuïteit van bestellingen te behouden, behaalde SOX-gereedheid op dag 85 door middel van het controlesysteem van Dynamics 365, en kostte $2 miljoen minder dan het bouwen van native Salesforce-productiemodules. De private equity-firma voltooide met succes hun IPO 14 maanden na de sluiting.
Hoe ga je om met de juridische en technische ambiguïteit wanneer de aankoopovereenkomst de "Bedrijf" die wordt verkocht anders definieert dan de technische clientstructuur van SAP, resulterend in gedeelde klanten die zowel bij de afgesplitste divisie als bij de behouden divisies kopen?
Veel kandidaten gaan ervan uit dat klantdata eenvoudigweg kan worden gekopieerd. De juiste benadering houdt in dat een Golden Record-strategie wordt gecreëerd waarbij gedeelde klanten in de nieuwe omgeving worden gerepliceerd met gemaskeerde historische data, terwijl een Master Data Management (MDM) hub wordt geïmplementeerd met behulp van Informatica of Talend om synchronisatie tijdens de TSA-periode te behouden zonder de privacyclausules te schenden. De BA moet vereisten opstellen voor klantmatch-algoritmen die gedeelde entiteiten identificeren op basis van belasting ID en adres-vage matching, en vervolgens gegevensmasker regels implementeren zodat de afgesplitste entiteit alleen hun transacties geschiedenis ziet terwijl het moederbedrijf volledige records behoudt.
Welke specifieke SOX-controlevereisten moeten worden gedocumenteerd voor de tussentijdse staat wanneer de afgesplitste entiteit gebruikmaakt van het SAP-systeem van het moederbedrijf, maar technisch gezien een afzonderlijke juridische entiteit is?
Kandidaten concentreren zich vaak alleen op de doelstaat. Tijdens de TSA moet de BA vereisten documenteren voor IT General Controls (ITGC) waarbij wordt gespecificeerd dat de moedermaatschappij SAP GRC (Governance, Risk, and Compliance) toegang controles onderhoudt terwijl zij de auditors van de afgesplitste entiteit lees-only toegang tot systeemlogs biedt. Vereisten moeten stellen dat alle journaalposten die door de afgesplitste entiteit tijdens de TSA zijn gepost, afzonderlijke bedrijfs codes en boekings ID's dragen voor segregatie van plichten, en dat het SAP Basis team van de moedermaatschappij dagelijkse extracts van alle transacties die de balans van de afgesplitste entiteit beïnvloeden, automatisch levert aan een zelfstandige SQL Server repository voor het behouden van onafhankelijke auditsporen.
Hoe modelleer je de vereisten voor de afbraak van intercompany-transacties die voorheen interne overdrachten waren maar na de afsplitsing externe verkopen/aankopen moeten worden?
Dit vereist BPMN procesmodellen die de transformatie van interne SAP winstcentrum postings in externe EDI transacties tonen. De BA moet vereisten specificeren voor nieuwe prijsgegevens (transferprijzen worden externe prijzen), belastingberekeningsmachines (BTW is nu van toepassing waar het voorheen niet het geval was), en het creëren van debiteur/crediteur gegevens. Cruciaal zijn de vereisten voor een "Dag 1" herclassificatie mechanisme waarbij de laatste 12 maanden van intercompany-transacties retrospectief worden geherclassificeerd in het Snowflake data warehouse om de afgesplitste entiteit als externe partij te tonen, zodat vergelijkende financiële overzichten voor de IPO geen onmogelijke interne transacties met zichzelf laten zien.