La estrategia requiere un enfoque híbrido que combine SAP Gestión del Ciclo de Vida de la Información (ILM) para la extracción de datos históricos, una capa de integración temporal MuleSoft para mantener la continuidad del flujo de pedidos durante el período del TSA, y una implementación por fases de Salesforce priorizando los procesos orientados al cliente antes de las capacidades de cierre financiero. Esta arquitectura aborda la restricción de cero tiempo de inactividad al mantener un puente temporal entre los módulos de manufactura de SAP de la empresa matriz y la nueva instancia de CRM Salesforce. La especificación de requisitos debe documentar los límites de propiedad de los datos, los protocolos de sincronización en tiempo real para las transacciones en curso, y los mecanismos de preservación de la pista de auditoría independiente para satisfacer los mandatos de SOX de Controles Generales de TI (ITGC).
Descripción del problema
Un conglomerado de manufactura global estaba desinvirtiendo su división de químicos especiales hacia una firma de capital privado. La división había operado dentro de la instancia SAP S/4HANA de la empresa matriz durante 15 años, compartiendo clientes, proveedores y cuentas de libro mayor con cinco otras divisiones. Las ventas interempresariales representaban el 40% de los ingresos de la división, con transacciones fluyendo a través de la función centralizada de tesorería de la empresa matriz. El Acuerdo de Servicios de Transición permitía solo 90 días para la separación operativa completa, sin embargo, la división tenía 2,500 pedidos de clientes activos en curso, y el comprador requería la capacidad inmediata de cumplimiento de SOX para apoyar su futura OPI en 18 meses. La empresa matriz se negó a proporcionar acceso continuo al sistema más allá del período del TSA, y la instancia de Salesforce del comprador necesitaba manejar tanto CRM como procesos de pedido a efectivo sin los módulos profundos de manufactura disponibles en SAP.
Solución 1: Cambio radical con migración completa de datos
Una de las opciones consideradas fue realizar un cambio de fin de semana donde todos los 15 años de datos históricos serían extraídos, depurados de transacciones interempresariales, y cargados en Salesforce con un modelo de datos personalizado que imitara las estructuras de SAP. Esto involucraría congelar todas las transacciones durante 72 horas mientras las herramientas LDS de SAP separaban los objetos de datos de la división.
Pros: Separación limpia, sin complejidades de integración en curso, independencia inmediata de los sistemas de la matriz.
Cons: Violó el mandato de cero tiempo de inactividad del TSA; Salesforce carece de soporte nativo para complejos BOM de manufactura y contabilidad de costos, requiriendo un enorme desarrollo personalizado que no podría completarse en 90 días; el riesgo de corrupción de datos durante la transformación de 15 años era inaceptablemente alto dados los requisitos de auditoría para la OPI.
Solución 2: TSA extendido con migración por fases
Otra opción fue negociar un TSA extendido de 12 meses donde la división continuaría utilizando SAP para el cierre financiero mientras migraba gradualmente a los clientes a Salesforce solo para nuevos pedidos.
Pros: Riesgo técnico reducido, tiempo permitido para construir personalizaciones adecuadas de Salesforce para procesos de manufactura, mantenía la accesibilidad a los datos históricos en SAP durante la transición.
Cons: Los financiadores de capital privado del comprador se negaron a aceptar los costos de responsabilidad de las tarifas de TSA extendidas ($500K mensuales); los auditores de SOX requerían que la división demostrara entornos de control independientes dentro de 90 días, lo que no podría lograrse mientras todavía se utilizara la instancia de SAP de la empresa matriz; las transacciones interempresariales históricas necesitaban ser reestatuidas como ventas externas, lo que no podía ser diferido.
Solución elegida y resultado
El equipo seleccionó una Arquitectura de Ejecución Dual utilizando MuleSoft como un bus de integración intermediario. Durante los primeros 60 días, nuevos pedidos de clientes fueron ingresados en Salesforce pero fluyeron a través de MuleSoft hacia el SAP de la empresa matriz para su cumplimiento, mientras la extracción de datos históricos se llevaba a cabo en paralelo utilizando SAP Gestión del Ciclo de Vida de la Información (ILM) con reglas personalizadas para bifurcar las transacciones interempresariales. En los días 61-90, el cumplimiento de pedidos se trasladó a una instancia temporal de Microsoft Dynamics 365 (ya certificada por SOX) para operaciones de manufactura, mientras Salesforce manejaba CRM y cotizaciones. Los datos históricos fueron archivados en AWS S3 con Snowflake proporcionando pistas de auditoría consultables para el requisito de 7 años, en lugar de intentar migrar toda la historia a objetos operativos de Salesforce.
Este enfoque satisfizo las restricciones del TSA manteniendo la continuidad de los pedidos, logró la preparación para SOX para el día 85 a través del marco de controles de Dynamics 365, y costó $2M menos que construir módulos de manufactura nativos en Salesforce. La firma de capital privado completó exitosamente su OPI 14 meses después del cierre.
¿Cómo manejaría la ambigüedad legal y técnica cuando el acuerdo de compra define el "Negocio" que se vende de manera diferente a la estructura técnica del cliente SAP, resultando en clientes compartidos que compran tanto de la división desinvertida como de las divisiones retenidas?
Muchos candidatos asumen que los datos de los clientes se pueden copiar simplemente. El enfoque correcto implica crear una estrategia de Registro Dorado donde los clientes compartidos se replican en el nuevo entorno con datos históricos enmascarados, mientras se implementa un hub de Gestión de Datos Maestros (MDM) utilizando Informatica o Talend para mantener la sincronización durante el período del TSA sin violar las cláusulas de privacidad de datos. El BA debe redactar requisitos para algoritmos de coincidencia de clientes que identifiquen entidades compartidas basadas en el ID fiscal y la coincidencia difusa de direcciones, y luego implementar reglas de enmascaramiento de datos asegurando que la entidad desinvertida vea solo su historial de transacciones mientras la empresa matriz retiene registros completos.
¿Qué requisitos específicos de control de SOX deben documentarse para el estado interino cuando la entidad desinvertida utiliza el sistema SAP de la empresa matriz pero es técnicamente una entidad legal separada?
Los candidatos a menudo se enfocan solo en el estado objetivo. Durante el TSA, el BA debe documentar los requisitos de Controles Generales de TI (ITGC) que especifican que la empresa matriz mantiene controles de acceso de SAP GRC (Gobernanza, Riesgo y Cumplimiento) mientras proporciona acceso de solo lectura a los registros del sistema de los auditores de la entidad desinvertida. Los requisitos deben exigir que todas las entradas de diario publicadas por la entidad desinvertida durante el TSA lleven códigos de empresa y IDs de publicación distintos para una segregación de deberes, y que el equipo Basis de SAP de la matriz proporcione extracciones automáticas diarias de todas las transacciones que afecten el balance de la entidad desinvertida a un repositorio independiente de SQL Server para la preservación de la pista de auditoría independiente.
¿Cómo modelaría los requisitos de la descomposición de transacciones interempresariales que anteriormente eran transferencias internas pero deben convertirse en ventas/compras externas después de la desinversión?
Esto requiere modelos de proceso BPMN que muestren la transformación de publicaciones de centro de beneficios internos de SAP en transacciones externas EDI. El BA debe especificar requisitos para nuevos datos maestros de precios (el precio de transferencia se convierte en precio externo), motores de cálculo de impuestos (el IVA ahora se aplica donde antes no lo hacía), y la creación de datos de cuentas por cobrar/pagar. Críticamente, los requisitos deben incluir un mecanismo de "Restatamiento Día 1" donde los últimos 12 meses de transacciones interempresariales sean reclasificadas retrospectivamente en el almacén de datos de Snowflake para mostrar a la entidad desinvertida como una parte externa, asegurando que los estados financieros comparativos para la OPI no muestren transacciones internas imposibles consigo misma.