この戦略は、SAP情報ライフサイクル管理（ILM）を使用して歴史データを抽出し、TSA期間中の注文フローの継続を維持するために一時的なMuleSoft統合レイヤーを搭載し、財務締結機能よりも顧客対応プロセスを優先する段階的なSalesforce実装を組み合わせたハイブリッドアプローチを必要とします。このアーキテクチャは、親会社のSAP製造モジュールと新しいSalesforce CRMインスタンスとの間に一時的なブリッジを維持することで、ゼロダウンタイムの制約に対処します。要件仕様は、データ所有権の境界、進行中の取引に対するリアルタイム同期プロトコル、独立した監査証跡保持メカニズムを文書化し、SOX IT一般統制（ITGC）要件を満たさなければなりません。
問題の説明
あるグローバル製造コングロマリットが、その特殊化学部門をプライベートエクイティファームに売却していました。この部門は親会社のSAP S/4HANAインスタンス内で15年間活動しており、他の5つの部門と顧客、ベンダー、総勘定元帳アカウントを共有していました。社内取引は部門の売上の40%を占め、その取引は親会社の中央財務機能を通じて流れました。移行サービス契約は完全な運営独立を90日間で求めていましたが、部門には2,500件の進行中の顧客注文があり、買い手は彼らの計画するIPOを18ヶ月以内に支持するために即時のSOX遵守能力を要求しました。親会社はTSA期間を超えて継続的なシステムアクセスを提供することを拒否し、買い手のSalesforceインスタンスは、SAPの豊富な製造モジュールなしでCRMおよび受注から現金化プロセスの両方を処理する必要がありました。
解決策1: ビッグバン切り替えと完全なデータ移行
考慮された1つのアプローチは、15年間のすべての歴史データを抽出して、社内取引を除去し、SAPの構造を模倣したカスタムデータモデルでSalesforceにロードするための単一の週末切り替えの実行でした。これにより、SAP LDSツールが部門のデータオブジェクトを切り出す72時間のトランザクション凍結が必要になります。
利点: クリーンな分離、進行中の統合の複雑さがない、親システムからの即時独立。
欠点: TSAのゼロダウンタイムの mandato違反; Salesforce は複雑な製造BOMとコスト会計のネイティブサポートがなく、大規模なカスタム開発が必要で、90日以内に完了できなかった; 15年間の歴史の変換中のデータ破損のリスクはIPO監査要件を考慮すると受け入れがたいほど高かった。
解決策2: 拡張TSAと段階的移行
別のオプションは、部門が財務closingの際にSAPを引き続き使用し、新しい注文にはしだいに顧客をSalesforceに移行する12ヶ月間のTSAの延長を交渉することでした。
利点: 技術リスクの軽減、私たちは製造プロセスのための適切なSalesforceカスタマイズを構築する時間を持ち、移行中にSAPにおける歴史データのアクセス可能性を維持しました。
欠点: 買い手のプライベートエクイティの支援者は、TSAの延長料金（毎月$500K）の負債コストを受け入れませんでした; SOX監査人は、部門が90日以内に独立した制御環境を示す必要があると要求したが、親のSAPインスタンスを依然として使用している状態では達成できませんでした; 過去の社内取引は外部の販売として再表現が必要で、先延ばしにすることができませんでした。
選ばれた解決策と結果
チームは、MuleSoftを中間統合バスとして使用したデュアルランアーキテクチャを選択しました。最初の60日間、新しい顧客注文はSalesforceに入力されましたが、MuleSoftを介して親のSAPにフルフィルメントのために流れ、歴史データの抽出は、社内取引を二分するためのカスタムルールを使用して並行して進められました。61-90日目には、受注の履行が一時的なMicrosoft Dynamics 365インスタンス（既にSOX認証）にシフトされ、製造操作が行われ、一方SalesforceはCRMと見積もりを処理しました。歴史データはAWS S3にアーカイブされ、Snowflakeが7年間の要件に対するクエリ可能な監査証跡を提供しました。すべての歴史を運用Salesforceオブジェクトに移行するのではなく。
このアプローチは、注文の継続性を維持することでTSAの制約を満たし、Dynamics 365の制御フレームワークを通じて85日目でSOX準備を達成し、ネイティブSalesforce製造モジュールを構築するよりも$2M安く済みました。プライベートエクイティファームは、クローズ後14ヶ月で成功裏にIPOを完了しました。
購入契約が販売される"ビジネス"をSAPテクニカルクライアント構造とは異なる定義で示した場合、法的および技術的な曖昧さをどのように扱いますか？それによって、売却された部門と保持部門の両方から購入する共有顧客が生じます。
多くの候補者が顧客データは単にコピーできると仮定します。正しいアプローチは、共有顧客が歴史データをマスクされた新しい環境に複製されるゴールデンレコード戦略を作成し、TSA期間の間、データプライバシー条項に違反しないようにマスターデータ管理（MDM）ハブをInformaticaやTalendを使用して構築し、同期を維持します。BAは、税IDおよびアドレスのファジーマッチングに基づいて共有エンティティを識別する顧客マッチングアルゴリズムの要件をドラフトする必要があり、次に、売却されたエンティティがトランザクション履歴のみを表示し、親が完全な記録を保持することを保証するデータマスキングルールを実装します。
分離されたエンティティが親のSAPシステムを使用している間の暫定状態に関して、どのように具体的なSOX制御要件を文書化しますか？それは技術的には別個の法人です。
候補者は、ターゲット状態のみに焦点を当てがちです。TSA期間中、BAは親がSAP GRC（ガバナンス、リスク、コンプライアンス）アクセスコントロールを維持し、売却されたエンティティの監査人にシステムログへの読み取り専用アクセスを提供することを指定するIT一般統制（ITGC）要件を文書化する必要があります。要件は、TSAの期間中に売却されたエンティティによって記録されたすべてのジャーナルエントリがセグリゲーションオブデューティのために異なる会社コードおよび投稿IDを持ち、親のSAP基盤チームが独立した監査証跡の保存のために売却されたエンティティのバランスシートに影響を与えるすべてのトランザクションの自動毎日の抽出をスタンドアロンのSQL Serverリポジトリに提供することを義務づける必要があります。
以前は内部移転だった社内取引の分解をどのように要件モデリングしますか？それは、分離後は外部の販売/購入にならなければなりません。
これは、内部のSAP利益センターポスティングが外部のEDIトランザクションに変わるBPMNプロセスモデルを必要とします。BAは、新しい価格マスターデータの要件を指定する必要があります（移転価格が外部価格に変わる）、税計算エンジン（VATが適用される場所の変更）、およびアカウント受取/支払のスタンディングデータの作成。重要なのは、要件に**"Day 1"再表明**メカニズムが含まれることです。直近12ヶ月の社内取引は、Snowflakeデータウェアハウスにおいて、分離されたエンティティを外部当事者として示すためにさかのぼって再分類され、IPOの比較財務諸表が自己との内部取引を示さないように保証されます。