Strategia wymaga podejścia hybrydowego, łączącego SAP Information Lifecycle Management (ILM) do wydobywania danych historycznych, tymczasową warstwę integracyjną MuleSoft w celu utrzymania ciągłości przepływu zamówień w okresie TSA oraz fazowaną implementację Salesforce, koncentrując się najpierw na procesach bezpośrednio związanych z klientami, a następnie na możliwości zamykania finansowego. Ta architektura odpowiada na wymóg zerowego przestoju, utrzymując tymczasowy most między modułami produkcyjnymi SAP firmy macierzystej a nową instancją CRM Salesforce. Specyfikacja wymagań musi dokumentować granice własności danych, protokoły synchronizacji w czasie rzeczywistym dla transakcji w toku oraz mechanizmy zachowania niezależnych ścieżek audytowych, aby spełnić wymogi SOX dotyczące ogólnych kontroli IT (ITGC).
Opis problemu
Globalny konglomerat produkcyjny wydzielał swoją jednostkę zajmującą się chemią specjalistyczną dla firmy private equity. Jednostka działała w obrębie instancji SAP S/4HANA firmy macierzystej przez 15 lat, dzieląc klientów, dostawców i konta główne z pięcioma innymi jednostkami. Transakcje międzyfirmowe stanowiły 40% przychodu dzielnicy, a transakcje przepływały przez centralną funkcję skarbcową firmy macierzystej. Umowa o świadczenie usług przejściowych pozwalała na jedynie 90 dni na pełne oddzielenie operacyjne, mimo że w dzielnicy było 2500 aktywnych zamówień klientów w toku, a nabywca wymagał natychmiastowej zdolności do zgodności z SOX, aby wspierać planowaną IPO w ciągu 18 miesięcy. Firma macierzysta odmówiła dalszego dostępu do systemu po okresie TSA, a instancja Salesforce nabywcy musiała obsługiwać zarówno CRM, jak i procesy zamówień do gotówki bez głębokich modułów produkcyjnych dostępnych w SAP.
Rozwiązanie 1: Big Bang Cutover z pełną migracją danych
Jednym z rozważanych podejść było przeprowadzenie jednorazowego przełączenia weekendowego, podczas którego wszystkie 15 lat danych historycznych zostałoby wydobyte, oczyszczone z transakcji międzyfirmowych i załadowane do Salesforce z niestandardowym modelem danych, naśladującym struktury SAP. To obejmowałoby wstrzymanie wszystkich transakcji na 72 godziny, podczas gdy narzędzia LDS SAP wydobywałyby dane jednostki.
Zalety: Czyste oddzielenie, brak złożoności dalszej integracji, natychmiastowa niezależność od systemów macierzystych.
Wady: Naruszało wymóg zerowego przestoju TSA; Salesforce nie obsługuje natywnie złożonych BOM produkcyjnych i rachunkowości kosztowej, co wymagałoby ogromnego rozwoju niestandardowego, którego nie można by zrealizować w 90 dni; ryzyko uszkodzenia danych podczas transformacji 15-letniej historii było nieakceptowalnie wysokie, biorąc pod uwagę wymagania audytu IPO.
Rozwiązanie 2: Przedłużony TSA z fazowaną migracją
Innšą opcją było negocjowanie 12-miesięcznego przedłużonego TSA, w ramach którego jednostka nadal korzystałaby z SAP do zamykania finansowego, jednocześnie stopniowo migrując klientów do Salesforce tylko dla nowych zamówień.
Zalety: Zredukowane ryzyko techniczne, czas na zbudowanie odpowiednich dostosowań Salesforce dla procesów produkcyjnych, utrzymywanie dostępu do danych historycznych w SAP podczas przejścia.
Wady: Prywatni inwestorzy klienta odmówili przyjęcia kosztów związanych z odpowiedzialnością przedłużonych opłat za TSA (500 000 USD miesięcznie); audytorzy SOX wymagali, aby jednostka wykazała niezależne środowiska kontrolne w ciągu 90 dni, co nie mogło być osiągnięte podczas korzystania z macierzystego systemu SAP; historyczne transakcje międzyfirmowe wymagały przekształcenia w zewnętrzne sprzedaże, co nie mogło być opóźnione.
Wybrane rozwiązanie i wyniki
Zespół wybrał architekturę Dual-Run, wykorzystując MuleSoft jako pośrednią warstwę integracyjną. Przez pierwsze 60 dni nowe zamówienia klientów były wprowadzane do Salesforce, ale przepływały przez MuleSoft do macierzystego SAP w celu realizacji, podczas gdy równolegle postępowało wydobywanie danych historycznych z użyciem SAP Information Lifecycle Management (ILM) z niestandardowymi zasadami do wydzielenia transakcji międzyfirmowych. W dniach 61-90 realizacja zamówień przeszła na tymczasową instancję Microsoft Dynamics 365 (już certyfikowaną zgodnie z SOX) do operacji produkcyjnych, podczas gdy Salesforce obsługiwał CRM i wycenę. Dane historyczne zostały zarchiwizowane w AWS S3, a Snowflake dostarczał zapytania audytowe zgodne z wymogiem 7 lat, zamiast próbować migrować całą historię do operacyjnych obiektów Salesforce.
To podejście spełniało wymogi TSA, zachowując ciągłość zamówień, osiągnęło gotowość do SOX do dnia 85 dzięki ramom kontrolnym Dynamics 365 i kosztowało 2 miliony dolarów mniej niż budowa natywnych modułów produkcyjnych Salesforce. Firma private equity pomyślnie zakończyła swoją IPO 14 miesięcy po zamknięciu.
Jak radzisz sobie z prawną i techniczną niejednoznacznością, gdy umowa kupna definiuje „Biznes”, który jest sprzedawany, inaczej niż struktura techniczna klienta SAP, co skutkuje współdzielonymi klientami, którzy kupują zarówno od wydzielonej jednostki, jak i od zachowanych jednostek?
Wielu kandydatów zakłada, że dane klientów można po prostu skopiować. Prawidłowe podejście polega na stworzeniu strategii Golden Record, w której współdzieleni klienci są replikowani w nowym środowisku z zamaskowanymi danymi historycznymi, wdrażając jednocześnie punkt centralny Master Data Management (MDM) z użyciem Informatica lub Talend, aby utrzymać synchronizację w czasie TSA, nie naruszając klauzul dotyczących prywatności danych. BA musi przygotować wymagania dotyczące algorytmów dopasowywania klientów, które identyfikują współdzielone podmioty na podstawie identyfikatora podatkowego i dopasowania adresu, a następnie wdrożyć zasady maskowania danych, zapewniając, że wydzielona jednostka widzi tylko swoją historię transakcji, podczas gdy firma macierzysta zachowuje pełne rekordy.
Jakie konkretne wymogi dotyczące kontroli SOX muszą być dokumentowane dla stanu przejściowego, gdy wydzielona jednostka korzysta z systemu SAP firmy macierzystej, ale jest technicznie oddzielnym podmiotem prawnym?
Kandydaci często koncentrują się tylko na stanie docelowym. W czasie TSA, BA musi dokumentować wymagania dotyczące IT General Controls (ITGC), określając, że firma macierzysta utrzymuje kontrole dostępu SAP GRC (Governance, Risk, and Compliance), zapewniając jednocześnie audytorom wydzielonej jednostki dostęp do systemów logujących tylko w trybie odczytu. Wymagania muszą nakładać obowiązek, aby wszystkie zapisy dziennika wprowadzane przez wydzieloną jednostkę podczas TSA miały wyraźnie oddzielne kody firmowe i identyfikatory publikacji do segregacji obowiązków, a zespół SAP firmy macierzystej musi dostarczać zautomatyzowane codzienne ekstrakty wszystkich transakcji wpływających na bilans wydzielonej jednostki do oddzielnego repozytorium SQL Server w celu zachowania niezależnych ścieżek audytowych.
Jak modelujesz wymagania dotyczące rozkładu transakcji międzyfirmowych, które były wcześniej wewnętrznymi transferami, ale muszą stać się zewnętrznymi sprzedażami/zakupami po wydzieleniu?
To wymaga modeli procesów BPMN, pokazujących transformację wewnętrznych zapisów zysków w SAP w zewnętrzne transakcje EDI. BA musi określić wymagania dotyczące nowych danych strętowych dotyczących cen (ceny transferowe stają się cenami zewnętrznymi), silników obliczania podatku (VAT teraz ma zastosowanie tam, gdzie wcześniej nie obowiązywał) oraz tworzenia danych dotyczących wierzytelności/należności. Krytycznie, wymagania muszą zawierać mechanizm „Dzień 1” do restatement, w którym ostatnie 12 miesięcy transakcji międzyfirmowych zostaje retrospektywnie przekształconych w hurtowni danych Snowflake, aby pokazać wydzieloną jednostkę jako podmiot zewnętrzny, zapewniając, że porównawcze sprawozdania finansowe dla IPO nie pokazują niemożliwych transakcji wewnętrznych z samym sobą.