이 전략은 역사적 데이터 추출을 위한 SAP 정보 생애 주기 관리(ILM), TSA 기간 동안 주문 흐름의 연속성을 유지하기 위한 임시 MuleSoft 통합 레이어, 재무 마감 기능보다 고객 대면 프로세스 우선 순위를 두는 단계적 Salesforce 구현을 결합한 하이브리드 접근 방식을 필요로 합니다. 이 아키텍처는 모회사 SAP 제조 모듈과 새로운 Salesforce CRM 인스턴스 간의 임시 브리지를 유지함으로써 제로 다운타임 제한을 해결합니다. 요구 사항 사양에는 데이터 소유 경계, 진행 중인 거래에 대한 실시간 동기화 프로토콜 및 SOX IT 일반 통제(ITGC) 요구 사항을 충족하기 위한 독립된 감사 추적 보존 메커니즘을 문서화해야 합니다.
문제 설명
글로벌 제조 대기업이 사모펀드에 특수 화학 부서를 매각하고 있었습니다. 이 부서는 15년 동안 모회사 SAP S/4HANA 인스턴스 내에서 운영되었으며, 다섯 개의 다른 부서와 고객, 공급업체 및 일반 원장 계좌를 공유하고 있었습니다. 내부 판매는 부서 수익의 40%를 차지했으며 거래는 모회사의 중앙 재무 기능을 통해 흐르고 있었습니다. 전환 서비스 계약은 완전한 운영 분리를 위해 90일만 허용했지만 부서에는 2,500개의 활성 고객 주문이 진행 중이었고, 매수자는 계획된 IPO를 지원하기 위해 즉각적인 SOX 준수 능력을 요구했습니다. 모회사는 TSA 기간 이후 지속적인 시스템 접근을 제공하기를 거부했고, 매수자의 Salesforce 인스턴스는 모회사 SAP에서 제공되는 깊은 제조 모듈 없이 CRM 및 주문-현금 프로세스를 처리해야 했습니다.
솔루션 1: 데이터 마이그레이션을 통한 빅뱅 컷오버
고려된 접근 방식 중 하나는 모든 15년의 역사적 데이터를 추출하고, 내부 거래를 정리하고, Salesforce에 로드하여 SAP 구조를 모방하는 커스텀 데이터 모델을 사용하는 단일 주말 컷오버를 수행하는 것이었습니다. 여기에는 SAP LDS 도구가 부서의 데이터 객체를 분리하는 동안 모든 거래를 72시간 동결하는 것이 포함됩니다.
장점: 명확한 분리, 지속적인 통합 복잡성 없음, 부모 시스템으로부터의 즉각적인 독립.
단점: TSA의 제로 다운타임 의무를 위반; Salesforce는 복잡한 제조 BOM 및 비용 회계에 대한 네이티브 지원이 부족하여 90일 이내에 완료할 수 없는 대규모 커스텀 개발이 필요했으며, 15년 역사 변환 중 데이터 손상의 위험이 IPO 감사 요구 사항을 감안할 때 용납할 수 없었습니다.
솔루션 2: 단계적 마이그레이션을 통한 연장된 TSA
또 다른 옵션은 부서가 재무 마감을 위해 SAP를 계속 사용하면서 신규 주문의 고객을 Salesforce로 점진적으로 마이그레이션하는 12개월 연장된 TSA를 협상하는 것이었습니다.
장점: 기술 위험 감소, 제조 프로세스를 위한 적절한 Salesforce 커스터마이징 구축 시간 허용, 전환 기간 동안 SAP에서 역사적 데이터 접근 가능성 유지.
단점: 매수자의 사모펀드 후원자들은 월 $500K의 연장된 TSA 비용의 책임을 수용하기를 거부했으며; SOX 감사자는 부서가 90일 이내에 독립적인 통제 환경을 보여주어야 한다고 요구했으며, 이는 여전히 모회사 SAP 인스턴스를 사용할 경우 달성할 수 없었습니다; 역사적 내부 거래는 외부 매출로 재표기되어야 했으며, 이는 연기할 수 없었습니다.
선택된 솔루션 및 결과
팀은 MuleSoft를 중개 통합 버스로 사용하는 Dual-Run Architecture를 선택했습니다. 처음 60일 동안 신규 고객 주문은 Salesforce에 입력되었지만, 이 주문은 MuleSoft를 통해 모회사 SAP로 흐르는 형태로 처리되었고, 역사적 데이터 추출은 사용자 정의 규칙을 적용한 SAP 정보 생애 주기 관리(ILM)를 사용하여 진행되었습니다. 61일에서 90일 사이에는 주문 이행이 임시 Microsoft Dynamics 365 인스턴스로 전환되었고 (이미 SOX 인증됨), Salesforce는 CRM 및 견적 처리를 담당했습니다. 역사적 데이터는 AWS S3에 아카이브되었으며, Snowflake는 7년 요구 사항을 위한 쿼리 가능한 감사 추적을 제공했습니다. 모든 역사 데이터를 운영 Salesforce 객체로 마이그레이션하려고 시도하는 대신 찾아냈습니다.
이 접근 방식은 주문 연속성을 유지하여 TSA 제약 조건을 충족하였고, Dynamics 365 통제 프레임워크를 통해 85일 만에 SOX 준비를 완료하였으며, 기본 Salesforce 제조 모듈 구축 비용보다 $2M 적게 들어갔습니다. 사모펀드는 폐쇄 14개월 후 IPO를 성공적으로 완료했습니다.
구매 계약이 판매되는 "비즈니스"를 SAP 기술 클라이언트 구조와 다르게 정의할 때 법적 및 기술적 모호성을 어떻게 처리합니까?
많은 지원자들은 고객 데이터를 단순히 복사할 수 있다고 가정합니다. 올바른 접근 방식은 공유 고객을 새로운 환경에 복제하고 역사적 데이터를 마스킹하는 Golden Record 전략을 수립하며, TSA 기간 동안 데이터 개인정보 보호 조항을 위반하지 않고 동기화를 유지하기 위해 Informatica 또는 Talend를 사용한 Master Data Management (MDM) 허브를 구현하는 것입니다. BA는 세금 ID와 주소의 퍼지 매칭을 기반으로 공유 엔티티를 식별하기 위한 고객 매칭 알고리즘에 대한 요구 사항을 초안 작성해야 하며, 분할된 실체가 자신의 거래 이력만 볼 수 있도록 보장하는 데이터 마스킹 규칙을 구현해야 합니다.
분할된 실체가 모회사의 SAP 시스템을 사용하지만 기술적으로는 별도의 법인인 경우 임시 상태에 대해 어떤 특정 SOX 통제 요구 사항을 문서화해야 합니까?
지원자들은 종종 목표 상태에만 집중합니다. TSA 기간 동안 BA는 부모가 SAP GRC(Governance, Risk, and Compliance) 접근 제어를 유지하면서 분할된 실체의 감사자에게 시스템 로그에 대한 읽기 전용 액세스를 제공해야 하는 IT 일반 통제(ITGC) 요구 사항을 문서화해야 합니다. 요구 사항은 TSA 기간 동안 분할된 실체가 게시한 모든 분개가 의무 분리를 위해 독특한 회사 코드 및 게시 ID를 포함해야 하며, 부모의 SAP 기본 팀이 분할된 실체의 대차대조표에 영향을 미치는 모든 거래의 자동 일일 추출을 독립적인 감사 추적 보존을 위해 독립적인 SQL Server 리포지토리에 제공해야 한다고 요구해야 합니다.
내부 이관에서 외부 판매/구매로 전환해야 하는 분할된 거래의 분해 요구 사항을 어떻게 모델링합니까?
이것은 내부 SAP 이익 센터 게시물이 외부 EDI 거래로 변환되는 BPMN 프로세스 모델을 요구합니다. BA는 새로운 가격 마스터 데이터(이관 가격이 외부 가격이 됨), 세금 계산 엔진(VAT가 이제 적용됨), 대출 채권/채무 관리 데이터 생성을 위한 요구 사항을 명시해야 합니다. 중요하게도, 요구 사항에는 마지막 12개월의 내부 거래를 재분류하여 분할된 실체를 외부 당사자로 표시하는 "Day 1" 재표기 메커니즘이 포함되어야 하며, 이는 IPO의 비교 재무제표에서 불가능한 내부 거래를 보여주지 않도록 해야 합니다.