Стратегия требует гибридного подхода, сочетая SAP Information Lifecycle Management (ILM) для извлечения исторических данных, временный интеграционный слой MuleSoft для поддержания непрерывности потока заказов в течение периода TSA и поэтапную реализацию Salesforce, приоритизируя процессы, ориентированные на клиентов, перед финансовыми возможностями закрытия. Эта архитектура отвечает требованиям о нулевом времени простоя, сохраняя временный мост между производственными модулями материнского SAP и новой CRM-системой Salesforce. Спецификация требований должна задокументировать границы владения данными, протоколы синхронизации в реальном времени для текущих транзакций и механизмы сохранения независимого аудиторского следа, чтобы удовлетворить требования IT General Controls (ITGC) по SOX.
Описание проблемы
Глобальный производственный конгломерат выделял свое подразделение специальной химии частной инвестиционной компании. Подразделение функционировало в материнской среде SAP S/4HANA в течение 15 лет, разделяя клиентов, поставщиков и счета общего учета с пятью другими подразделениями. Внутренние продажи составили 40% выручки подразделения, при этом транзакции проходили через централизованную казначейскую функцию материнской компании. Соглашение о предоставлении переходных услуг позволяло только 90 дней для полного операционного разделения, но в подразделении было 2500 активных заказов клиентов в процессе выполнения, и покупатель требовал немедленной возможности соблюдения SOX для поддержки их запланированного IPO в течение 18 месяцев. Материнская компания отказалась предоставить доступ к системе после окончания периода TSA, и инстанс Salesforce покупателя должен был обрабатывать как CRM, так и процессы от заказа до оплаты без углубленных производственных модулей, доступных в SAP.
Решение 1: Полное переключение с размещением всех данных
Одним из рассматриваемых подходов было выполнение единственного переключения за выходные, при котором все 15 лет исторических данных были бы извлечены, очищены от внутренних транзакций и загружены в Salesforce с индивидуальной моделью данных, имитирующей структуры SAP. Это потребовало бы остановить все транзакции на 72 часа, пока инструменты SAP LDS вырезали объекты данных подразделения.
Преимущества: Чистое разделение, отсутствие текущей интеграционной сложности, немедленная независимость от систем материнской компании.
Недостатки: Нарушало требование TSA о нулевом времени простоя; Salesforce не поддерживает сложные производственные сборки и бухгалтерский учет затрат, требуя масштабной индивидуальной разработки, которую невозможно было бы завершить за 90 дней; риск повреждения данных при трансформации 15-летней истории был неприемлемо высок с учетом требований аудита для IPO.
Решение 2: Расширенное соглашение TSA с поэтапной миграцией
Другим вариантом было бы согласовать 12-месячное расширенное соглашение TSA, при котором подразделение продолжало бы использовать SAP для финансового закрытия, постепенно переводя клиентов на Salesforce для новых заказов только.
Преимущества: Сниженный технический риск, позволило время для создания адекватных индивидуальных настроек Salesforce для производственных процессов, сохраняя доступность исторических данных в SAP в течение переходного периода.
Недостатки: Частные акционеры покупателя отказались принять ответственность за затраты на расширенные сборы TSA (500 тыс. долларов в месяц); аудиторы SOX потребовали от подразделения продемонстрировать независимые контрольные системы в течение 90 дней, что не могло быть достигнуто при продолжении использования материнского SAP; исторические внутренние транзакции требовали переосмысления как внешние продажи, что не могло быть отложено.
Выбранное решение и результат
Команда выбрала Dual-Run Architecture, использующую MuleSoft в качестве промежуточной интеграционной шины. В течение первых 60 дней новые заказы клиентов вводились в Salesforce, но проходили через MuleSoft в материнский SAP для выполнения, в то время как параллельно происходило извлечение исторических данных с использованием SAP Information Lifecycle Management (ILM) с индивидуальными правилами для отделения внутренних транзакций. На 61-90 дни выполнение заказов было перенесено на временный интерфейс Microsoft Dynamics 365 (уже сертифицированный по SOX) для производственных операций, в то время как Salesforce обрабатывал CRM и котировки. Исторические данные были архивированы в AWS S3 с Snowflake, предоставляющим запрашиваемые аудиторские следы для 7-летнего требования, вместо попытки миграции всей истории в операционные объекты Salesforce.
Этот подход удовлетворил ограничения TSA, поддерживая непрерывность заказов, достигнулся уровень готовности по SOX к 85-му дню через контрольные механизмы Dynamics 365, и стоил на 2 млн долларов меньше, чем создание родных производственных модулей Salesforce. Частная инвестиционная компания успешно завершила IPO через 14 месяцев после закрытия.
Как вы справляетесь с юридической и технической неопределенностью, когда договор купли-продажи определяет "Бизнес", который продается, иначе чем техническая структура клиента SAP, что приводит к совместным клиентам, которые покупают как у выделенного подразделения, так и у сохраняемых подразделений?
Многие кандидаты предполагают, что данные клиентов можно просто скопировать. Правильный подход включает создание стратегии Golden Record, в которой совместные клиенты дублируются в новой среде с замаскированными историческими данными, одновременно внедряя центр управления мастер-данными (MDM) с использованием Informatica или Talend для поддержания синхронизации в течение переходного периода TSA, не нарушая условия конфиденциальности данных. BA должен разработать требования для алгоритмов сопоставления клиентов, которые определяют общие субъекты на основе налогового идентификатора и смягченного сопоставления адресов, а затем реализовать правила маскировки данных, чтобы выделяемая сущность видела только свою историю транзакций, в то время как материнская компания сохраняет полные записи.
Какие конкретные требования по контролю SOX должны быть документированы для промежуточного состояния, когда выделенное подразделение использует систему SAP материнской компании, но технически является отдельным юридическим лицом?
Кандидаты часто сосредотачиваются только на целевом состоянии. Во время TSA BA должен документировать требования IT General Controls (ITGC), указывая, что материнская компания поддерживает доступ к SAP GRC (Управление, Риск и Соответствие), одновременно предоставляя аудиторам выделенной сущности доступ только для чтения к системным журналам. Требования должны предписывать, чтобы все журналы проводок, размещенные выделенным подразделением в течение TSA, имели отдельные коды компаний и идентификаторы проводок для разделения обязанностей, а команда SAP Basis материнской компании предоставляла автоматизированные ежедневные выписки всех транзакций, влияющих на баланс выделенной сущности, в отдельный репозиторий SQL Server для сохранения независимого аудиторского следа.
Как вы моделируете требования для декомпозиции внутренних транзакций, которые ранее были внутренними переводами, но должны стать внешними продажами/покупками после выделения?
Это требует BPMN моделей процессов, показывающих трансформацию внутренних проводок SAP по центрам прибыли в внешние EDI транзакции. BA должен указать требования по новым данным мастер-цен (трансфертные цены становятся внешними ценами), механизмы расчета налогов (НДС теперь применяется, где ранее не был), и созданию данных по дебиторской/кредиторской задолженности. Критически важно, чтобы требования включали механизм "Day 1" переосмысления, где последние 12 месяцев внутренних транзакций задним числом переоцениваются в хранилище данных Snowflake как внешняя сторона, обеспечивая сопоставимые финансовые отчеты для IPO, чтобы не показывать невозможные внутренние транзакции с самим собой.