Strateji, SAP Bilgi Yaşam Döngüsü Yönetimi (ILM) ile tarihsel veri çıkışını, TSA dönemi boyunca sipariş akışının sürekliliğini sağlamak için geçici bir MuleSoft entegrasyon katmanını ve finansal kapanış yeteneklerinden önce müşteri odaklı süreçleri önceliklendiren aşamalı bir Salesforce uygulamasını birleştiren bir hibrit yaklaşım gerektirmektedir. Bu mimari, ana şirketin SAP üretim modülleri ile yeni Salesforce CRM örneği arasında geçici bir köprü kurarak sıfır duraksama kısıtlamasını ele alır. Gereksinim spesifikasyonu, veri sahipliği sınırlarını, uçta işlem gören işlemler için gerçek zamanlı senkronizasyon protokollerini ve SOX BT Genel Kontrolleri (ITGC) gereksinimlerini karşılamak için bağımsız denetim yolu koruma mekanizmalarını belgelemelidir.
Problemin Tanımı
Küresel bir üretim konglomeratı, özel kimyasallar bölümünü bir özel sermaye şirketine devrediyordu. Bölüm, ana şirketin SAP S/4HANA örneğinde 15 yıl boyunca faaliyet göstermiş, diğer beş bölümle müşterileri, satıcıları ve genel muhasebe hesaplarını paylaşmıştır. İç şirket satışları, bölümün gelirinin %40'ını temsil ediyordu ve işlemler ana şirketin merkezi hazine işlevi üzerinden geçiyordu. Geçiş Hizmetleri Anlaşması, tam operasyonel ayrılma için yalnızca 90 gün izin veriyordu, ancak bölümün 2,500 aktif müşteri siparişi mevcut olup, alıcı 18 ay içinde planladıkları IPO'yu desteklemek için hemen SOX uyumluluk yeteneği talep ediyordu. Ana şirket, TSA süresinden sonra devam eden sistem erişimi sağlamayı reddetti ve alıcının Salesforce örneği hem CRM hem de siparişten nakde süreçlerini yönetmek zorundaydı ancak SAP'te mevcut olan derin üretim modülleri yoktu.
Çözüm 1: Tam Veri Göçü ile Büyük Patlama Kesintisi
Düşünülen bir yaklaşım, tüm 15 yıllık tarihsel verilerin çıkarılacağı, iç şirket işlemlerinden temizleneceği ve Salesforce'a özel bir veri modeli ile yükleneceği tek bir hafta sonu kesinti gerçekleştirmekti. Bu, SAP LDS araçlarının bölümün veri nesnelerini ayrıştırdığı süre boyunca tüm işlemlerin 72 saat dondurulmasını gerektirecekti.
Artıları: Temiz ayrım, sürekli entegrasyon karmaşıklığı yok, ana sistemlerden hemen bağımsızlık.
Eksileri: TSA'nın sıfır duraksama kuralını ihlal ediyordu; Salesforce, karmaşık üretim BOM'ları ve maliyet muhasebe desteği sağlamıyordu, bu da 90 günde tamamlanamayacak büyük özelleştirme gerektiriyordu; 15 yıllık tarihsel dönüşüm sırasında veri bozulma riski, IPO denetim gereklilikleri göz önüne alındığında kabul edilemez derecede yüksekti.
Çözüm 2: Aşamalı Göç ile Uzatılmış TSA
Diğer bir seçenek, bölümün finansal kapanışı için SAP kullanmaya devam ederken müşterilerin yalnızca yeni siparişler için Salesforce'a kademeli olarak geçirileceği 12 aylık uzatılmış bir TSA müzakere etmekti.
Artıları: Teknik risk azaldı, üretim süreçleri için düzgün Salesforce özelleştirmeleri oluşturmak için zaman sağladı, geçiş sırasında tarihsel veri erişilebilirliğini SAP'de korudu.
Eksileri: Alıcının özel sermaye destekçileri, uzatılmış TSA ücretlerini ($500K aylık) kabul etmedi; SOX denetçileri, bölümün 90 gün içinde bağımsız kontrol ortamlarını göstermesini gerektiriyordu ki bu, ana şirketin SAP örneğini kullanarak başarılacak bir şey değildi; tarihsel iç şirket işlemleri, ertelenemeyen dış satış olarak yeniden sınıflandırılmalıydı.
Seçilen Çözüm ve Sonuç
Ekip, MuleSoft aracılığıyla bir ara entegrasyon otobüsü kullanan bir Çift Çalışma Mimarisi belirledi. İlk 60 gün boyunca, yeni müşteri siparişleri Salesforce'a kaydedildi ancak MuleSoft aracılığıyla ana şirketin SAP sistemine akış sağlandı, tarihsel veri çıkışı ise sistematik kurallar kullanılarak iç şirket işlemlerinin ayrıştırılması için eş zamanlı olarak devam etti. 61-90. günlerde, sipariş yerine getirme geçici bir Microsoft Dynamics 365 örneğine (zaten SOX sertifikalı) kaydırıldı, üretim operasyonları için, Salesforce ise CRM ve teklif alma işlemlerini yönetti. Tarihsel veriler, son 7 yıl gereksinimi için sorgulanabilir denetim yolları sağlayan Snowflake ile birlikte AWS S3’te arşivlendi; tüm tarihsel verilerin operasyonel Salesforce nesnelerine aktarılması yerine.
Bu yaklaşım, sipariş sürekliliğini koruyarak TSA kısıtlamalarını sağladı, Dynamics 365 kontrol çerçevesi ile 85. günde SOX hazırlığını elde etti ve yerel Salesforce üretim modüllerini inşa etmekten $2M daha düşük maliyetle sonuçlandı. Özel sermaye firması, kapanışın 14 ay sonrasında IPO'larını başarıyla tamamladı.
Satın alma anlaşmasının "satılan iş" tanımının SAP teknik müşteri yapısından farklı tanımlandığında, paylaşılan müşterilerin hem devredilen bölümden hem de tutulan bölümlerden alım yaptığı durumlarda hukuki ve teknik belirsizlikleri nasıl ele alıyorsunuz?
Birçok aday, müşteri verilerinin basitçe kopyalanabileceğini varsayıyor. Doğru yaklaşım, paylaşılan müşterilerin yeni ortamda tarihsel verileri maskelenmiş şekilde çoğaltılmasını içeren bir Altın Kayıt stratejisi oluşturmaktır; geçiş dönemi boyunca veri gizliliği hükümlerine aykırı olmadan senkronizasyonu sağlamak için Informatica veya Talend kullanarak bir Ana Veri Yönetimi (MDM) merkezi uygulanmalıdır. BA, üyelik teşkil edenların vergi kimliği ve adres bulanık eşleştirmeye dayalı olarak tanımlarını belirlemek için müşteri eşleşme algoritmaları için gereksinim belgelendirmelidir; ardından devredilen varlığın yalnızca kendi işlem geçmişini görebilmesi için veri maskeleme kurallarını uygulamalıdır.
Devredilen varlık ana şirketin SAP sistemini kullanırken, teknik olarak ayrı bir yasal varlık olduğunda hangi özel SOX kontrol gereklilikleri belgelenmelidir?
Adaylar genellikle yalnızca hedef duruma odaklanırlar. TSA sırasında, BA'nın, ana şirketin SAP GRC (Yönetim, Risk ve Uyum) erişim kontrollerini sürdürdüğünü belgeleri gerekmektedir; devredilen varlığa ait denetçilerinin sistem günlüklerine yalnızca okuma erişimi olması gerekmektedir. Gereksinimler, TSA süresince devredilen varlık tarafından kaydedilen tüm muhasebe kayıtlarının ayrım görevlerini sağlamak için belirgin şirket kodları ve göndermeler içermesi gerekecek ve ana şirketin SAP Taban ekibinin devredilen varlığın bilançosunu etkileyen tüm işlemlerin otomatik günlük çıkarımını bağımsız denetim yolu korunması için ayrı bir SQL Server deposuna sağlamasını zorunlu kılmalıdır.
İç şirket işlemlerinin daha önce dahili transferler iken, devritiş sonrası dış satış/alışlar haline nasıl dönüştürüleceğini gereksinim modellemesi yapıyorsunuz?
Bu, iç SAP kâr merkezi tahsislerini dış EDI işlemlerine dönüştüren BPMN süreç modelleri oluşturmayı gerektirir. BA'nın, yeni fiyat listesi verileri için gereksinimler belirtmesi (transfer fiyatlandırması dış fiyatlandırma haline gelir), vergi hesaplama motorları (KDV artık geçerli olduğu yerlerde uygulanır) ve alacak/borç hesap verileri oluşturulmasını gerektirir. Kritik olarak, gereksinimler, devredilen varlığın dış taraf olarak gösterilmesini sağlamak için son 12 aylık iç şirket işlemlerinin geçmişe yönelik yeniden sınıflandırılacağı bir "Gün 1" yeniden ifade etme mekanizmasını içermelidir, bu da IPO için karşılaştırmalı mali tabloların kendisiyle gerçekleşen mümkün olmayan iç işlemler göstermemesini sağlayacaktır.