Post-merger integration.
Día 100 sin pánico. Los dos stacks parecen uno.
Una adquisición trae dos CRMs, dos ERPs, dos HRIS, dos portales y un montón de talento que tiene que operar como una sola compañía. La presión es real: la dirección y los inversores piden synergies visibles en trimestres, no en años. La estrategia técnica que funciona es no migrar todo el día uno, sino integrar. Con MuleSoft armás la capa que une ambos stacks, expone vista consolidada al negocio y da tiempo para una migración ordenada cuando corresponde.
¿Qué resuelve post-merger integration con MuleSoft?
Después de una adquisición, dirección pide reportes consolidados, sales rep necesita ver cliente cross-empresa y procurement quiere consolidar contratos. Migrar todo a un único stack en pocos meses no es realista. La estrategia que funciona es construir una capa de integración encima de los dos stacks, donde el negocio vea la compañía unificada mientras los sistemas locales siguen operando. MuleSoft acelera el day-100 y ordena la convergencia futura.
- Customer master cross-empresa con matching por documento fiscal, email y fuzzy name.
- Reporting financiero consolidado con eliminación inter-company aplicada.
- Vendor rationalization: detección de duplicados para consolidar contratos.
- Identidad federada para empleados cross-org.
Sistemas típicos involucrados
Las familias que conviven en una integración post-deal seria.
CRM duplicados
Salesforce + Microsoft Dynamics, dos instancias Salesforce, dos orgs con configuración divergente, custom legacy. Un cliente puede aparecer en uno, en el otro o en ambos con datos distintos.
ERP duplicados
SAP + Oracle, dos SAPs distintos, SAP + NetSuite. Cada empresa con su modelo de cuentas, calendarios fiscales, monedas funcionales y reglas de cierre.
HR y payroll por empresa
Workday, SuccessFactors, sistemas locales LATAM. Cada empresa con su estructura organizacional, jerarquías y políticas de talento.
Reporting consolidado
Hyperion, OneStream, sistemas custom de consolidación financiera, BI corporativo (Tableau, Power BI, Salesforce CRM Analytics). Donde el negocio espera ver una sola compañía.
Arquitectura objetivo
Cada empresa mantiene su stack. La integración pasa por arriba.
+-----------------------+ +-----------------------+
| Empresa A | | Empresa B |
| (CRM A, ERP A, etc.) | | (CRM B, ERP B, etc.) |
+-----------+-----------+ +-----------+-----------+
| |
| System APIs A | System APIs B
v v
+----------------------------------------------------+
| Integration Layer (MuleSoft) |
| - Cross-entity Customer Master |
| - Cross-entity Vendor Master |
| - Consolidated Reporting Feed |
| - Unified Identity Layer |
+--------------------+-------------------------------+
|
v
+----------------------------------------------------+
| Unified Experience APIs |
| (consolidated dashboards, BI feeds, |
| unified portals) |
+----------------------------------------------------+System APIs
Las System APIs de A y B se mantienen separadas: crm-a-customer-sapi, crm-b-customer-sapi, erp-a-finance-sapi, erp-b-finance-sapi. Cada empresa conserva su modelo y su gobernanza local.
Process APIs
unified-customer-pa devuelve la vista consolidada cross-empresa. consolidated-financial-pa agrega data financiera con eliminación inter-company. vendor-rationalization-pa detecta duplicados. employee-cross-org-pa federa identidad.
Experience APIs
unified-bi-eapi alimenta Tableau, Power BI y Salesforce CRM Analytics con feeds consolidados. consolidated-portal-eapi expone portales unificados a clientes, proveedores y partners post-deal.
Flujo paso a paso
Vista consolidada de cliente cross-org desde Salesforce, sin que el sales rep abandone su entorno.
- 1 Un sales rep de Empresa A está en Salesforce viendo un Account. Quiere saber si ese cliente también compra a Empresa B antes de armar la propuesta.
- 2 Un botón custom en Salesforce invoca GET /unified-customer/{accountId} contra unified-bi-eapi, sin que el sales rep abandone su entorno.
- 3 La Experience API delega en unified-customer-pa, que orquesta la consulta cross-org con criterios de matching configurables.
- 4 La Process API consulta crm-a-customer-sapi con accountId y recibe la data del customer en A: identidad fiscal, contactos, contratos vigentes, oportunidades activas.
- 5 Hace matching contra B siguiendo prioridad: primero documento fiscal (CUIT, RUT, CPF, RFC) normalizado, luego email, finalmente fuzzy name match con umbral configurable.
- 6 Si hay match en B, consulta crm-b-customer-sapi para los datos del customer en B y erp-b-customer-sapi para histórico de compras y estado de cuenta.
- 7 Compone respuesta cross-empresa: revenue combinado, productos comprados en cada lado, oportunidades cross-sell sugeridas, contactos clave en cada compañía, riesgos abiertos.
- 8 Si la disponibilidad de B está degradada, devuelve respuesta parcial con flag explícito y el sales rep ve qué información viene de cada lado.
- 9 El widget en Salesforce muestra la vista consolidada al sales rep. La conversación con el cliente arranca con contexto cross-empresa, no con dos ventanas distintas.
- 10 Cada acceso queda en audit log. Reconciliation jobs nocturnos detectan inconsistencias en master data y disparan alertas para el equipo de integración.
Patterns aplicados
Los patrones que sostienen una integración post-deal en producción.
Hub-and-spoke con cada empresa como spoke
Las System APIs de A y B se mantienen separadas. La integración ocurre arriba, sin pelear con la realidad operativa de cada compañía.
Master Data Reconciliation
Un hub canónico (efímero o persistente según política) reconcilia identidades cross-empresa. El matching no rompe los maestros locales.
Inter-company elimination
El consolidated-financial-pa aplica las reglas de eliminación inter-company en el reporting. Las transacciones entre A y B se cancelan en el consolidado.
Phased data migration
Consolidación progresiva por dominio. Primero customer view, luego vendor master, luego financial reporting, luego identidad. Sin big bang.
Identity Federation
Empleados que necesitan operar en ambas empresas acceden con identidad federada y permisos consolidados, sin duplicar usuarios y sin perder auditoría.
Exit plan explícito
Cada componente de la capa de integración tiene definido si es permanente o transitorio. Las decisiones arquitectónicas dependen de eso.
Cómo lo implementamos
Cinco fases coordinadas con dirección, CFO y los equipos de ambas empresas, contra el reloj del day-100.
Mapeo cross-empresa y prioridades day-100
Inventario de stacks de A y B, identificación de los dominios críticos para el day-100 (customer, vendor, financials, identity), expectativas de sinergia con dirección y CFO, decisión sobre convergencia futura. Plan priorizado.
Modelo cross-org y reglas de matching
Diseño del hub canónico cross-empresa, contratos de Process APIs unificadas, reglas de matching configurables por dominio, modelo de eliminación inter-company, política de identidad federada, plan de reconciliación y exit plan por componente.
Vistas unificadas y reporting consolidado
Implementación de unified-customer-pa, consolidated-financial-pa, vendor-rationalization-pa, employee-cross-org-pa. Integración con BI corporativo, tests con datos reales sintetizados, runbooks. Foco en cumplir el hito day-100.
Day-100 readiness
Hardening, security review, validación con dirección y CFO, dashboard cross-org listo para steering committee de integración, hypercare en las primeras semanas. Go-live coordinado con el plan de comunicación interno del deal.
Convergencia y sinergias
Cuando la decisión es converger a un único stack, la capa cumple su rol transitorio y se descomisiona dominio por dominio. Cuando coexistencia es la realidad operacional, la capa evoluciona con managed services y CoE.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Acceso técnico a los CRMs y ERPs de A y B, master data crítico (customer, vendor, employee), reglas de negocio para inter-company, política de privacidad y compliance del deal aprobada por legal.
Licencias y capacidades
Anypoint Platform, conectores de los stacks de A y B (SAP, Oracle, Salesforce, Dynamics, Workday según aplique), módulo de eventos cuando hay sync bidireccional, infraestructura para audit trail.
Integraciones típicas
BI corporativo (Tableau, Power BI, CRM Analytics), sistemas de consolidación financiera (Hyperion, OneStream), portales unificados, identity provider corporativo, herramientas del PMO de integración.
Pre-requisitos organizacionales
Sponsor a nivel CEO o COO, CFO involucrado para reporting consolidado, IT lead de cada empresa, PMO de integración, legal alineado con compliance del deal y plan de comunicación interno.
KPIs operativos
Las métricas que típicamente mejoran tras armar la capa cross-empresa.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| Cross-org match rate | Porcentaje de customers de A con identidad resuelta cross-org en B (alta o nula confianza). | Habilita cross-sell, vendor rationalization y consolidación de descuentos por volumen. Tiende a crecer con el tiempo al mejorar el matching. |
| Revenue synergy tracked | Revenue cross-sell concretado a partir de la vista cross-empresa. | Es la métrica que dirección y los inversores miran para validar el deal. Se reporta al steering committee de integración. |
| Data inconsistency alerts | Cantidad de inconsistencias detectadas en reconciliation jobs entre A y B. | Diagnostica calidad del matching y de los maestros. Tiene que tender a la baja conforme avanza la integración. |
| Time to synergy realization | Tiempo desde el day-100 hasta el primer dólar de sinergia operativa identificable. | KPI estratégico para dirección. Más rápido es mejor; cada mes adicional es presión sobre el deal. |
| Vendor consolidation rate | Porcentaje de proveedores duplicados consolidados en un único contrato. | Una de las palancas principales de sinergia operativa post-deal. |
| Cross-org user adoption | Cantidad de empleados que efectivamente usan las vistas cross-empresa en su día a día. | Sin adopción no hay sinergia. Indica si la capa unificada está generando valor real o quedó como proyecto de IT. |
Time-to-value: day-100 readiness con vistas consolidadas en producción tras 14 a 20 semanas, alineado con el calendario del deal y el steering committee de integración.
Cómo se mide: dashboard sobre Anypoint Monitoring por Process API, integrado con Splunk, Datadog o Grafana cuando ya existe ese stack del lado del cliente, más KPIs de negocio reportados al board y al PMO.
Preguntas frecuentes
Es la primera decisión que se define con dirección y el steering committee de integración. Si el plan estratégico es converger a un único stack en 12 a 18 meses, conviene integración liviana y herramientas específicas de migración. Si la coexistencia va a durar 24 meses o más, o si nunca se va a forzar la convergencia, la capa de integración estable con MuleSoft es el camino. La decisión define la arquitectura, no al revés.
En LATAM observamos rangos típicos de 12 a 36 meses post-deal antes de tomar decisiones definitivas de convergencia, con dominios que pueden mantenerse separados más tiempo (HR es habitual). Lo crítico no es el plazo sino que cada componente de la capa de integración tenga un exit plan: ¿cuándo se descomisiona, contra qué evento, con qué responsable? Sin eso, la capa transitoria se vuelve permanente por inercia.
Antes del closing y durante el periodo de integración hay límites legales sobre qué información puede compartirse entre A y B. La capa se diseña con esos límites como requisito: granularidad fina de permisos, audit trail completo, controles que reflejan compliance del deal. Datos sensibles (compensación, contratos confidenciales, pipeline pre-cierre) tienen acceso restringido por rol y por dominio.
Las sinergias se trackean en KPIs operativos que la capa habilita: revenue synergy tracked (cross-sell concretado), vendor consolidation rate (proveedores duplicados consolidados), cross-org user adoption (uso real de las vistas unificadas). Los reportes alimentan el steering committee de integración y el board. La métrica integrada de "time to synergy realization" es la que más mira la dirección.
Aplica con la lógica invertida. En un carve-out hay que separar dos compañías que hoy comparten stack: identificar qué entidades, contratos, customers y vendors quedan de cada lado, qué integraciones temporales son necesarias para que la unidad escindida opere durante el TSA (Transition Service Agreement) y qué se descomisiona al finalizar. MuleSoft es la capa natural para construir esa separación con trazabilidad.
Día 100 sin pánico. Los dos stacks parecen uno.
Hablemos del deal y diseñamos juntos la capa que sostiene la integración cross-empresa.