Imagen de la noticia Dos empresas, dos ERP: ¿integrar o unificar tras una ad...

FUSIONES Y ADQUISICIONES · DECISIÓN ERP · CIO Y CFO

Dos empresas, dos ERP: ¿integrar o unificar tras una adquisición?

La empresa se ha unido. Sus sistemas no tienen por qué hacerlo el primer día.

Dos compañías pueden compartir accionistas sin compartir sistemas. Descubre cuándo mantener dos ERP conectados, cuándo converger por fases y cuándo implantar una plataforma común sin comprometer el negocio.

DESPUÉS DE FIRMAR LA OPERACIÓN

La adquisición termina en el contrato. La integración empieza al día siguiente.

Dos compañías pueden sumar clientes, talento, plantas y facturación y seguir funcionando como dos organizaciones tecnológicas. Eso no siempre es malo. El problema aparece cuando el nuevo grupo necesita decidir con datos comunes y descubre que cada filial mide, contabiliza y explica la realidad de una manera distinta.

Una empresa trabaja con Microsoft Dynamics 365 Business Central; la adquirida utiliza SAP, Sage, un ERP vertical o una solución desarrollada a medida. Cada sistema tiene usuarios, reglas, históricos, integraciones y procesos que siguen siendo necesarios. Desde dirección surge una pregunta aparentemente simple: «¿Por qué no lo ponemos todo en un único ERP?». Desde Operaciones llega otra: «¿Quién se hace responsable si paramos la fábrica o retrasamos la facturación?». Y el CFO necesita una respuesta todavía más inmediata: «¿Cuándo vamos a poder cerrar y comparar resultados del grupo?».

La tentación es transformar la compra en un proyecto de sustitución tecnológica. Sin embargo, antes de decidir la plataforma conviene separar las necesidades financieras, operativas y de integración. Compartir un estado de resultados consolidado no exige necesariamente operar en una sola aplicación. Y mantener dos ERP tampoco obliga a convivir indefinidamente con duplicidades y conciliaciones manuales.

FINANZAS

Necesidad del CFO

Comparar sociedades, cerrar con confianza, eliminar operaciones intragrupo y explicar rentabilidad, deuda y tesorería sin reconstruir cada mes los datos.

TECNOLOGÍA

Necesidad del CIO

Garantizar continuidad, ciberseguridad, trazabilidad, integración, gobierno de datos y una arquitectura que no penalice futuras compras.

OPERACIÓN

Necesidad de Operaciones

Proteger fabricación, distribución, proyectos, pedidos, calidad y servicio mientras se alinean procesos realmente comunes.

NEGOCIO

Necesidad de Dirección

Capturar sinergias medibles, reducir costes duplicados cuando compense y evitar que la integración tecnológica retrase el crecimiento.

LA DISTINCIÓN QUE CAMBIA LA DECISIÓN

Consolidar resultados, integrar datos y unificar ERP son tres trabajos distintos

Confundirlos suele disparar presupuestos. A menudo, el grupo necesita primero una visión financiera fiable; después, determinados procesos compartidos; y solo entonces puede valorar si mantener dos plataformas genera un coste o riesgo difícil de justificar.

01 · VISIÓN FINANCIERA

Consolidación contable

Obtener estados consolidados, tratamiento de distintas divisas, ajustes de consolidación y eliminaciones intragrupo.

Resultado esperado: el CFO puede cerrar y explicar el negocio completo. No implica sustituir el ERP desde el que opera cada sociedad.

02 · INTEROPERABILIDAD

Integración de sistemas y datos

Intercambiar información necesaria: clientes, proveedores, pedidos, catálogos, saldos, inventario, maestros o indicadores.

Resultado esperado: el grupo coordina decisiones y procesos sin transcribir datos entre plataformas. La integración necesita responsables, reglas y monitorización.

03 · CONVERGENCIA

Unificación del núcleo ERP

Migrar una o varias entidades a una plataforma común, armonizar procesos y abandonar aplicaciones anteriores de forma controlada.

Resultado esperado: menos diversidad tecnológica y mayor estandarización donde aporta valor. Puede ser la mejor decisión, pero no siempre la primera ni la más barata.

La diferencia es relevante en Microsoft. Business Central permite consolidar información financiera de varias compañías y contempla escenarios con diferentes planes contables, monedas, ejercicios y ciertas fuentes externas. Dynamics 365 Finance documenta consolidaciones multientidad, ajustes, traducción de divisas y opciones de reporting. Las posibilidades concretas dependen de configuración, calidad del dato y alcance funcional; no equivalen a una consolidación completa y automática de todas las operaciones.

UNA PREGUNTA, TRES SALIDAS

Tres caminos posibles. Ninguno debería elegirse por intuición.

No existe una respuesta universal para «dos empresas, dos ERP». La mejor opción cambia según el grado de integración del negocio, la madurez de las aplicaciones, la presión de los cierres, el riesgo de interrupción y los beneficios que puedan medirse. Estas son las tres decisiones que conviene evaluar con los mismos criterios.

CAMINO A · CONVIVENCIA CONTROLADA

Mantener ambos ERP e integrarlos

Cada sociedad conserva su sistema transaccional. Se crea una capa de gobierno y se conectan solo los datos o flujos que el grupo necesita compartir.

Encaja cuando: las operaciones siguen siendo bastante autónomas, el ERP adquirido funciona, hay exigencias locales o la adquisición necesita un periodo de estabilidad. No encaja si: mantener dos sistemas bloquea procesos comunes, genera un sobrecoste creciente o hace imposible un control básico.

CAMINO B · TRANSFORMACIÓN PROGRESIVA

Consolidar procesos y sociedades por fases

Se define un modelo corporativo objetivo, pero la transición se ejecuta por países, sociedades, plantas o procesos, con integraciones transitorias y fechas de salida concretas.

Encaja cuando: se persiguen sinergias claras, pero no puede asumirse una migración simultánea. Riesgo: que la fase transitoria se convierta en permanente y acumule licencias, dobles desarrollos y una organización dividida.

CAMINO C · PLATAFORMA COMÚN

Unificar en un único ecosistema ERP

Se estandarizan datos y procesos y se migra la operación a una solución elegida según la complejidad de negocio. Puede ser una plataforma con varias compañías, no una sola entidad jurídica.

Encaja cuando: el modelo de operación compartido es real, las aplicaciones actuales limitan el crecimiento o el coste de convivencia supera de forma sostenible el de la transformación. Riesgo: convertir diferencias legítimas en excepciones costosas.

INSTRUMENTO PARA EL COMITÉ DE INVERSIÓN

Matriz de decisión: qué alternativa gana peso según el problema

La tabla no sustituye una evaluación técnica. Ayuda a descartar decisiones automáticas. «Favorece» significa que esa opción merece estudiarse antes: no es una recomendación incondicional.

Situación del grupo Opción que merece evaluarse Prueba que debe exigirse
Las filiales operan de forma autónoma Mantener e integrar Consolidar sólo resultados y datos compartidos; proteger procesos locales
El grupo exige cierre financiero homogéneo pronto Integrar primero Diseñar plan contable corporativo, conciliaciones, divisas y eliminaciones
Un ERP está obsoleto y sin soporte viable Convergencia por fases Priorizar la plataforma con mayor riesgo operativo y normativo
La operación comparte fabricación o inventario Fases o ERP común Probar órdenes, trazabilidad, reservas, costes y logística cruzada
Se prevén más adquisiciones en 24 meses Modelo repetible Crear arquitectura y datos maestros reutilizables para nuevas filiales
La sociedad adquirida debe seguir autónoma Mantener e integrar Cumplir acuerdos societarios, controles y separación de datos
Existen múltiples desarrollos críticos Evaluación previa Analizar qué es estándar, qué se reemplaza y qué hay que conservar
El coste anual de convivencia crece cada año Comparar tres TCO Incluir integraciones, proveedores, soporte, seguridad y cambios futuros
Hay países con fiscalidad y localizaciones distintas Diseño multinacional Validar requisitos legales antes de fijar plataforma y calendario
La calidad del dato es muy desigual Saneamiento primero Acordar responsables y reglas de maestros antes de migrar
La adquisición busca sinergias comerciales Integrar procesos concretos Priorizar cliente común, oportunidades, precios y facturación cuando aplique
El ERP actual responde bien y no genera fricción No sustituir por reflejo Exigir un caso de negocio para justificar cualquier reemplazo

La lectura correcta no es contar cuántas casillas favorecen una opción. Hay criterios que pueden invalidar todo un programa: por ejemplo, la continuidad de una planta productiva, un requisito fiscal no cubierto o una separación societaria obligatoria. El peso de cada criterio debe acordarse con Finanzas, Tecnología y Operaciones.

ANTES DE ELEGIR PRODUCTO

Doce preguntas de due diligence tecnológica que nadie debería dejar para después

El mejor momento para construir el mapa ERP es antes de comprometer presupuesto y calendario. Si la adquisición ya se ha cerrado, el inventario debería ser una de las primeras actividades del plan de integración. No basta con saber el nombre del software: hay que comprender qué hace cada sistema y qué sucede si deja de funcionar.

EVIDENCIA QUE PEDIR

01 · Sociedades

¿Qué entidades legales existen, qué fiscalidad aplican y quién consolida sus cuentas? La estructura legal condiciona el diseño y la trazabilidad.

EVIDENCIA QUE PEDIR

02 · Procesos críticos

¿Qué operaciones se detienen si el ERP no está disponible durante ocho horas? Identificar el daño operativo antes de planificar migraciones.

EVIDENCIA QUE PEDIR

03 · Desarrollos

¿Cuáles son extensiones propias, soluciones de terceros y procesos manuales? Separar singularidad de deuda tecnológica.

EVIDENCIA QUE PEDIR

04 · Integraciones

¿Qué se conecta con CRM, bancos, WMS, MES, nómina, e-commerce y BI? Un sistema aparentemente pequeño puede sostener decenas de dependencias.

EVIDENCIA QUE PEDIR

05 · Datos maestros

¿Quién define cliente, proveedor, artículo, centro de coste y producto? Evitar unificar códigos que representan realidades distintas.

EVIDENCIA QUE PEDIR

06 · Históricos

¿Qué movimientos deben migrarse y qué información puede archivarse de forma consultable? No convertir una migración en una copia indiscriminada.

EVIDENCIA QUE PEDIR

07 · Cierres

¿Cuánto tardan el cierre local y el consolidado? ¿Qué ajustes son manuales? Distinguir problema contable de problema ERP.

EVIDENCIA QUE PEDIR

08 · Seguridad

¿Quién administra accesos, identidades, cuentas de servicio y privilegios? Minimizar privilegios heredados y accesos desconocidos.

EVIDENCIA QUE PEDIR

09 · Contratos

¿Cuándo vencen licencias, hosting, soporte y acuerdos de mantenimiento? Detectar costes hundidos y ventanas de negociación.

EVIDENCIA QUE PEDIR

10 · Organización

¿Quién decide cambios de proceso y quién valida resultados en cada filial? Evitar un proyecto que IT ejecuta pero nadie adopta.

EVIDENCIA QUE PEDIR

11 · Crecimiento

¿Se prevén nuevas compras, países, centros o cambios societarios? Diseñar una arquitectura repetible, no solo resolver la compra actual.

EVIDENCIA QUE PEDIR

12 · Salida

¿Cómo se desconectará el ERP anterior y cuánto costará mantener su histórico? Incluir la retirada definitiva desde el inicio del caso de negocio.

La documentación resultante debería permitir un diagnóstico por riesgo, capacidad, coste y dependencia. Si el equipo no puede localizar propietarios de datos, integraciones o permisos críticos, acelerar una unificación puede ser más peligroso que posponerla. La primera victoria del proyecto es recuperar visibilidad, no comprar otra licencia.

EL COSTE QUE NO APARECE EN LA PROPUESTA

El mayor riesgo no siempre es pagar dos licencias. Es tener dos versiones de la realidad.

La dirección suele ver dos contratos ERP y pensar en ahorrar uno. El coste más importante puede estar en las conciliaciones, los errores de catálogo, las ventas intragrupo duplicadas, la falta de trazabilidad y las horas que consumen los equipos para producir informes comparables.

Antes de sustituir tecnología, identificamos qué decisiones del grupo necesitan datos comunes y en qué momento. Una integración bien gobernada puede generar valor inmediato. Una unificación precipitada puede trasladar el problema a una plataforma nueva.

Solicitar evaluación ERP

FINANZAS MULTISOCIEDAD

Puedes consolidar las cuentas del grupo sin que todas las filiales operen en el mismo ERP

La necesidad de consolidación suele llegar antes que la necesidad de convergencia operativa. El grupo quiere conocer resultados por sociedad, ajustar diferencias de divisa, eliminar transacciones entre vinculadas y comparar márgenes. Eso exige disciplina contable y un modelo de datos financiero, pero no supone que todos los usuarios deban registrar compras, producción o ventas en un único sistema al día siguiente de la adquisición.

CONSOLIDACIÓN FINANCIERA

Dynamics 365 Business Central

Permite trabajar con varias compañías y disponer de una empresa consolidada. Microsoft documenta escenarios con planes contables, monedas y ejercicios diferentes, así como intercambio de datos de consolidación desde otras fuentes. La configuración de cuentas, unidades de negocio y criterios de conversión es determinante.

GOBIERNO CORPORATIVO

Dynamics 365 Finance

Ofrece capacidades de consolidación financiera entre entidades jurídicas, traducción de moneda y reporting corporativo. Microsoft documenta distintas aproximaciones de consolidación según el modelo de control, el origen de datos y las necesidades de auditoría.

Hay que añadir una precisión que muchas comparativas omiten: consolidación financiera e intercompany no son sinónimos. La primera responde a cómo se presentan los resultados del grupo. El segundo aborda operaciones entre sociedades —ventas, compras, cargos y conciliaciones— y debe definirse según procesos y control. Una automatización de facturas entre vinculadas no sustituye los ajustes de consolidación; un informe consolidado tampoco resuelve por sí solo los procesos intragrupo.

En Business Central, las eliminaciones contables del consolidado pueden requerir asientos manuales conforme al proceso documentado por Microsoft. Por tanto, prometer una consolidación universal «automática» sin análisis es poco riguroso. En Finance también hay que definir método, reportes, propietarios y conciliaciones.

Fuentes técnicas de referencia: consolidación en Business Central, configuración de la compañía consolidada y consolidación y divisas en Dynamics 365 Finance.

La prueba que pediría el CFO

Antes de decidir si se cambia un ERP, produciría un cierre piloto con balances de dos sociedades, reglas de conversión, ajustes intragrupo, trazabilidad hasta origen, responsables de revisión y un informe que pueda explicar dirección. Si eso es viable manteniendo los ERP actuales, se ha desbloqueado una necesidad fundamental sin asumir todavía una migración completa.

INTEGRACIÓN Y GOBIERNO DEL DATO

Dos ERP conectados no deben convertirse en un laberinto de interfaces

Mantener sistemas distintos puede ser una decisión sólida, pero únicamente si la convivencia está diseñada. No basta con intercambiar un fichero cada noche y esperar que los informes cuadren: hay que decidir qué dato manda, cómo se identifica cada registro, qué ocurre ante un error y quién se hace responsable de repararlo.

GOBIERNO

Un propietario por cada dato

Definir qué aplicación es fuente maestra para clientes, proveedores, artículos, centros de coste, contratos y entidades. Sin esa decisión, sincronizar información solo multiplica contradicciones.

CONTINUIDAD

Integraciones observables

Registrar ejecuciones, rechazos, reintentos, duplicados y tiempos de entrega. Los procesos críticos necesitan alertas, evidencia y procedimientos de recuperación, no solo una conexión técnica.

CONTROL

Seguridad entre entornos

Revisar identidades, permisos mínimos, aplicaciones registradas, cuentas técnicas, segregación de funciones, auditoría y protección de datos personales. La adquisición no legitima el acceso indiscriminado a todas las bases.

DECISIÓN

Modelo analítico consistente

Definir dimensiones, divisas, calendarios y métricas comparables. Unificarlas en una capa analítica facilita ver el grupo, pero no corrige procesos mal registrados en los ERP de origen.

Si una filial utiliza Business Central, Microsoft dispone de API REST para integrar Business Central con servicios externos. Las APIs son una capacidad técnica, no una arquitectura de integración por sí mismas: siguen haciendo falta reglas de negocio, control de errores, permisos y pruebas de extremo a extremo. En ecosistemas heterogéneos se pueden estudiar Azure Integration Services, Power Platform y soluciones de datos según volumen, latencia, criticidad y coste de operación.

En informes de gestión, herramientas como Microsoft Fabric y Power BI pueden contribuir a comparar información de sociedades. Pero la capa de análisis no debe utilizarse para ocultar divergencias de inventario, contabilidad o facturación. Una cifra bonita no equivale a una cifra conciliada.

SECUENCIA CORRECTA

Inventariar fuentes → Acordar maestros → Establecer contratos de intercambio → Validar conciliaciones → Supervisar incidencias → Retirar duplicidades.

PLAN DE INTEGRACIÓN POSTADQUISICIÓN

Día 1, primeros 100 días y horizonte de 24 meses: cada decisión tiene su momento

Un proyecto de integración ERP no debería comenzar con un calendario de migración impuesto. Debería comenzar con una secuencia de decisiones basada en el riesgo. Un plan útil diferencia lo que debe existir desde el primer día, lo que debe quedar probado en el primer trimestre y lo que necesita un caso de negocio antes de arrancar.

DÍA 1 · CONTINUIDAD

Proteger lo que ya funciona

Asegurar accesos, responsables de incidentes, licencias y contratos críticos, copias de seguridad, integraciones existentes y continuidad de facturación, compras, producción y nómina. No realizar cambios simultáneos en procesos sensibles por el mero hecho de haber firmado la compra.

PRIMEROS 30 DÍAS · VISIBILIDAD

Conocer sistemas y obligaciones

Mapear entidades, aplicaciones, dependencias, usuarios, integraciones, cierre financiero, principales datos maestros, riesgos y contratos. Diferenciar lo que es común de lo que debe seguir siendo local por regulación o por operación.

DÍAS 30–100 · PRUEBAS

Validar una arquitectura mínima viable

Probar un consolidado financiero, una integración comercial o un flujo intragrupo prioritario con datos reales. Establecer las reglas de conciliación, monitorización y soporte. Construir un inventario económico de las tres rutas.

MESES 4–12 · DECISIÓN

Seleccionar el modelo objetivo

Contrastar beneficios, costes, capacidades internas, integraciones, deuda técnica y calendario. Definir por qué sistema o sociedad comenzar y qué condiciones deben cumplirse para avanzar a la siguiente fase.

MESES 12–24 · EJECUCIÓN

Migrar o estabilizar lo que de verdad compense

Ejecutar oleadas, pruebas de aceptación, transición operativa y retirada de sistemas con controles. Si se decide mantener dos ERP, gestionar la arquitectura como un servicio estable, medible y revisable.

Los plazos son una secuencia orientativa, no una promesa de duración. Una empresa con tres sedes puede avanzar antes que un grupo con múltiples países; una fábrica con procesos 24/7 puede exigir ventanas específicas. Lo profesional es fijar hitos verificables, criterios de salida y responsables, no anunciar una fecha sin conocer dependencias.

EL BUSINESS CASE QUE FALTA EN MUCHAS ADQUISICIONES

¿Cuál es el coste real de mantener dos ERP frente a unificarlos?

Comparar exclusivamente las licencias es una forma rápida de elegir mal. La coexistencia tiene gastos de integración, operaciones y soporte. Una implantación común añade migración de datos, rediseño de procesos, gestión del cambio, pruebas, riesgos de parada y retirada de sistemas. Y una convergencia por fases puede mantener ambos costes durante cierto tiempo.

Para ilustrar la diferencia, construimos un ejemplo ficticio en miles de euros. Supongamos dos compañías con sistemas operativos, necesidades de información del grupo y distintos niveles de transformación. Los importes no son precios de Microsoft, no son una oferta de Ayesa Digital y no pueden utilizarse para estimar un proyecto real sin diagnóstico.

Alternativa hipotética Inversión inicial Coste recurrente / año Coste total 3 años Coste total 5 años
Mantener e integrar 120.000 € 85.000 € 375.000 € 545.000 €
Convergencia por fases 260.000 € 55.000 € 425.000 € 535.000 €
ERP común 510.000 € 42.000 € 636.000 € 720.000 €

Fórmula aplicada: inversión inicial + coste recurrente anual × número de años. El cálculo no incluye financiación, variación de tarifas, descuento financiero ni monetización de beneficios. Al tratarse de supuestos inventados, ninguna alternativa «gana» por naturaleza. El objetivo de la tabla es demostrar que el horizonte temporal y los beneficios que se incorporan cambian el resultado.

COSTES DE CONVIVENCIA

Lo que el CFO debe cuantificar

Horas de cierre, coste de conciliación, retrasos de reporting, licencias y contratos, soporte externo, mantenimiento de interfaces, duplicidades, riesgos regulatorios y esfuerzo de auditoría.

COSTES DE TRANSFORMACIÓN

Lo que Operaciones debe valorar

Riesgo de parada, pérdida de conocimiento local, cambios de almacén o fabricación, aprendizaje, productividad, trazabilidad y oportunidades reales de sinergia comercial o industrial.

El caso económico correcto añade los beneficios verificables, el plazo de captura y los riesgos. Una unificación puede ser más costosa en los tres primeros años y seguir siendo razonable si habilita operaciones compartidas de alto valor; también puede no justificarse nunca si ambas compañías deben continuar autónomas. Una decisión sólida documenta qué variables inclinan la balanza y qué ocurriría si el grupo compra otra empresa dentro de un año.

LOS ERRORES QUE SE REPITEN

Ocho riesgos que aparecen cuando la integración se gestiona solo como un proyecto de software

01 · Migrar sin entender

Tratar el ERP adquirido como un problema que debe desaparecer. Se pierden procesos eficientes, localizaciones y conocimiento histórico; los usuarios vuelven a hojas de cálculo porque la solución nueva no reproduce lo esencial.

02 · Consolidar datos sin conciliarlos

Unificar tablas en un repositorio y asumir que las cifras del grupo ya son comparables. Diferencias de calendario, moneda, reconocimiento de ingresos y maestros hacen que las métricas discrepen.

03 · Eliminar una licencia antes de tiempo

Cancelar una aplicación porque existe otra «equivalente», sin identificar integraciones, contratos, retención de información, obligaciones fiscales y procesos activos. El ahorro contractual puede transformarse en interrupción.

04 · Subestimar el trabajo intragrupo

Suponer que la facturación entre sociedades, transferencias, cargos y eliminaciones quedan resueltas por disponer de un informe consolidado. Existen flujos operativos y contables que requieren controles distintos.

05 · Diseñar para la foto de hoy

Crear una integración específica para dos empresas sin pensar en más filiales, países o nuevas adquisiciones. Cada compra posterior añade conexiones difíciles de mantener y reglas inconsistentes.

06 · Descuidar permisos y auditoría

Fusionar accesos y extraer datos sin definir propietario, roles, privilegios, retención o trazabilidad. El crecimiento corporativo no elimina responsabilidades de seguridad y cumplimiento.

07 · Imponer la matriz sobre la operación

Forzar procesos corporativos a una filial industrial o de servicios que tiene necesidades críticas distintas. La estandarización no debe destruir ventajas operativas que justificaron la adquisición.

08 · No fijar una salida del sistema anterior

Mantener indefinidamente interfaces provisionales, licencias de lectura, usuarios duplicados y soporte de aplicaciones históricas. Un proyecto «por fases» sin criterios de retirada termina siendo un coste recurrente permanente.

CUATRO EJEMPLOS PARA ENTENDER LA DECISIÓN

La misma adquisición puede exigir soluciones totalmente diferentes

Los casos siguientes son ejemplos ilustrativos y no corresponden a clientes identificados de Ayesa Digital. Sirven para mostrar las preguntas que cambian el camino recomendado, no para convertir una situación hipotética en una regla.

01 · Grupo industrial compra una planta

La sociedad adquirida tiene un ERP propio que integra planificación y trazabilidad de producción. La matriz necesita resultados consolidados y compras comunes, pero cambiar MES y ERP a la vez generaría un riesgo alto.

Primero estudiar consolidación financiera, maestros de proveedores y compras compartidas. Mantener temporalmente el ERP de planta y decidir la convergencia solo tras demostrar que la operación puede reproducirse sin pérdida.

Primera decisión útil: Acordar quién gobierna datos, cierre, compras e integraciones; documentar criterios para revisar la decisión dentro de seis meses.

02 · Servicios profesionales en expansión

La empresa comprada usa una aplicación de gestión de proyectos y otro sistema contable. Ambas tienen servicios y clientes parcialmente comunes. La dirección quiere unificar facturación y márgenes por cliente.

Puede tener sentido estandarizar cuentas, clientes y proyectos antes de elegir un ERP común. Una convergencia por fases permite probar la integración comercial y financiera con menor exposición.

Primera decisión útil: Acordar quién gobierna datos, cierre, compras e integraciones; documentar criterios para revisar la decisión dentro de seis meses.

03 · Grupo de construcción y promoción

Una promotora adquiere una constructora. Los procesos societarios se solapan, pero control de obra, certificaciones, presupuestos, costes y rentabilidad por promoción tienen necesidades distintas.

Antes de homogeneizar el ERP, revisar la cobertura sectorial y las obligaciones de cada negocio. Valorar Business Central con soluciones verticales como IB Building 365 o IB Real Estate 365 donde el encaje sea demostrable.

Primera decisión útil: Acordar quién gobierna datos, cierre, compras e integraciones; documentar criterios para revisar la decisión dentro de seis meses.

04 · Holding internacional con compras recurrentes

Un grupo integra varias filiales en distintos países, algunas con ERP Microsoft y otras con sistemas locales. El cierre requiere conversión de divisas, auditoría y controles, pero no todas las sociedades deben operar igual.

Diseñar primero un modelo financiero y de datos reutilizable; evaluar Dynamics 365 Finance cuando la complejidad de control corporativo lo requiera. No asumir que el número de filiales obliga por sí solo a una plataforma.

Primera decisión útil: Acordar quién gobierna datos, cierre, compras e integraciones; documentar criterios para revisar la decisión dentro de seis meses.

QUÉ PAPEL TIENE MICROSOFT EN LA ARQUITECTURA OBJETIVO

Business Central, Dynamics 365 Finance y Power Platform: elegir por el problema, no por una jerarquía de productos

Si el grupo decide evolucionar hacia tecnologías Microsoft, hay diferentes caminos. La elección no debe derivarse automáticamente de la facturación o del número de sociedades; debe partir de la complejidad financiera, las operaciones, los países, los datos, las integraciones y la capacidad real de adoptar un modelo común.

ERP EMPRESARIAL

Dynamics 365 Business Central

Puede encajar en filiales o grupos con procesos manejables, necesidades financieras y operativas cubiertas por su alcance y un buen ajuste al estándar o a verticales especializados.

Evalúa multiempresa, intercompany, consolidación financiera, límites funcionales, localizaciones, extensiones y coste de mantenimiento. Explorar Business Central.

GOBIERNO FINANCIERO CORPORATIVO

Dynamics 365 Finance

Tiene sentido estudiarlo cuando el grupo exige controles financieros complejos, operación multinacional, reporting corporativo y gobierno más profundo. Debe evaluarse junto al ecosistema operativo si fabricación y supply chain son críticas.

Revisar entidades legales, consolidación, intercompany, dimensiones, cierres, regulación y despliegue progresivo. Explorar Dynamics 365 Finance.

DATOS E INTEGRACIÓN

Power Platform, Azure y Fabric

Pueden conectar aplicaciones, automatizar flujos y proporcionar una capa analítica común mientras los ERP siguen siendo diferentes. No sustituyen la necesidad de responsables de proceso ni la calidad de datos.

Diseñar arquitectura de integración y datos en función de criticidad, volumen, controles y coste de operación. Explorar Power Platform.

Para comparar específicamente las capacidades y el alcance funcional entre Business Central y Finance, ya existe una guía dedicada a Business Central frente a Dynamics 365 Finance. Este artículo aborda una decisión diferente: qué hacer con los sistemas de dos organizaciones después de una operación corporativa. Primero el modelo de integración; después, cuando corresponda, la plataforma.

AYESA DIGITAL · ESPECIALIZACIÓN MICROSOFT

No se trata de colocar el mismo ERP en dos compañías. Se trata de construir un grupo que pueda operar mejor.

Ayesa Digital acompaña decisiones de transformación sobre Dynamics 365 Business Central, Dynamics 365 Finance, Power Platform, Azure y datos empresariales. El valor no consiste en imponer una herramienta: consiste en diagnosticar procesos, riesgos y costes, contrastar escenarios y ejecutar una evolución sostenible.

Para conocer las designaciones y especializaciones Microsoft que respaldan nuestras capacidades, consulta la página corporativa de acreditaciones.

Conocer nuestras capacidades Microsoft

CÓMO CONVERTIR EL DIAGNÓSTICO EN UNA DECISIÓN

Qué debería recibir el comité de integración antes de aprobar una migración

Un informe técnico que no llega a decisiones es insuficiente. El comité debe disponer de evidencias comprensibles para Finanzas, Dirección y Tecnología, con un responsable asignado para cada hipótesis. Estas seis entregas permiten comparar alternativas sin convertir el debate en preferencias de proveedor.

01 · Mapa de aplicaciones y dependencias

Sistemas por sociedad y proceso, versiones, contratos, integración, seguridad, responsables y riesgos de continuidad.

02 · Diagnóstico de datos y cierre

Maestros, diferencias contables, necesidad de reporting corporativo, operaciones intercompany y reconciliaciones pendientes.

03 · Opciones de arquitectura

Convivencia integrada, transición progresiva y ERP objetivo, con cobertura de procesos, condicionantes y exclusiones explícitas.

04 · Caso económico comparable

Horizonte temporal, inversión, gasto recurrente, coste de doble operación, recursos internos, riesgo y beneficios verificables.

05 · Plan de continuidad y despliegue

Pruebas, recuperación, ventanas de cambio, validación por usuarios, retirada de aplicaciones y control posterior al arranque.

06 · Gobierno y responsables

Quién aprueba cambios, qué decide el CFO, quién asume el servicio, cómo se gestionan conflictos y qué indicadores desencadenan revisión.

Una pregunta final antes de firmar el proyecto

Si dentro de doce meses adquirimos una tercera compañía, ¿la arquitectura propuesta facilitará integrarla o tendremos que empezar de cero? Si no hay respuesta, el diseño probablemente está demasiado centrado en la operación de hoy.

RESPUESTAS PARA EL CIO Y EL CFO

Preguntas frecuentes sobre la integración de ERP tras una adquisición

¿Es obligatorio implantar un ERP único después de comprar otra empresa?

No. La decisión depende de la integración operativa, las obligaciones societarias, el coste de convivencia, la tecnología existente y los beneficios. Un grupo puede trabajar con varios ERP y aun así disponer de información financiera consolidada y procesos compartidos bien diseñados.

¿Se pueden consolidar cuentas si cada filial usa un ERP distinto?

Sí, existen escenarios para consolidar información de distintas fuentes, pero deben definirse importaciones, plan de cuentas, dimensiones, monedas, ajustes, eliminaciones, trazabilidad y responsabilidades de control. No equivale a conectar dos sistemas y obtener automáticamente estados auditables.

¿Qué diferencia hay entre consolidación financiera y consolidación de ERP?

La consolidación financiera agrupa datos contables para informar del conjunto del grupo. La consolidación de ERP supone converger sistemas y, normalmente, procesos operativos. La primera puede conseguirse sin la segunda; la segunda no elimina la necesidad de reglas contables de consolidación.

¿Cuándo merece la pena conservar el ERP de la compañía adquirida?

Cuando cubre procesos críticos con fiabilidad, existe autonomía operativa, la sustitución añade un riesgo desproporcionado o los beneficios de unificar aún no están probados. Es necesario, eso sí, establecer integración y gobierno suficientes para la nueva organización.

¿Cuál es el primer proyecto tras una fusión: migración, integración o reporting?

Depende de los riesgos inmediatos. Frecuentemente lo prioritario es proteger continuidad y seguridad, levantar el inventario y obtener un reporting financiero razonablemente fiable. No debería seleccionarse una migración masiva antes de conocer procesos, integraciones y dependencias.

¿Business Central puede trabajar con varias sociedades y consolidar información?

Sí. Microsoft documenta gestión multiempresa, intercompany y capacidades de consolidación financiera, incluso con distintos planes de cuentas, ejercicios y monedas. La adecuación a un grupo concreto exige valorar complejidad, localizaciones, volumetría y requerimientos de gobierno.

¿Cuándo hay que valorar Dynamics 365 Finance?

Cuando la complejidad financiera, el gobierno del grupo, las operaciones internacionales y el reporting corporativo justifican estudiar una plataforma de mayor profundidad. No existe un número universal de sociedades que haga obligatoria la elección.

¿Cómo se justifica económicamente una plataforma ERP común?

Comparando escenarios de varios años con inversión, licencias, soporte, integraciones, gestión del cambio, riesgos, retirada de sistemas y beneficios demostrables. El coste de mantener dos plataformas no puede compararse solo con el coste de las licencias del ERP único.

¿Puede Power BI o Fabric resolver el problema de integración de los ERP?

Puede facilitar análisis y modelos de datos comunes, pero no sustituye por sí mismo los procesos transaccionales, el control de operaciones ni la calidad de los datos de origen. Debe distinguirse la capa analítica de las integraciones operativas y del cierre financiero.

¿Qué debe incluir una evaluación externa antes de decidir?

Mapa de procesos, aplicaciones y riesgos; revisión financiera e intercompany; arquitectura alternativa; modelo de datos; TCO comparable; plan de continuidad; pruebas de viabilidad; y criterios que permitan al comité decidir con evidencias.

LA DECISIÓN NO DEBERÍA EMPEZAR EN EL CATÁLOGO

¿Dos ERP después de una adquisición? Evaluemos primero qué necesita controlar el grupo.

Si tu organización acaba de adquirir una empresa, está integrando filiales o lleva años trabajando con ERP diferentes, el siguiente paso no tiene por qué ser una migración. Puede ser un diagnóstico que permita identificar riesgos, desbloquear reporting y determinar si merece la pena integrar, evolucionar por fases o unificar.

En Ayesa Digital podemos analizar el mapa actual, las necesidades de Finanzas y Operaciones, los costes de convivencia y la arquitectura objetivo dentro del ecosistema Microsoft. La recomendación debe sostenerse por impacto y viabilidad, no por una preferencia de producto.

HABLEMOS DE TU ESCENARIO

Explica tu situación y estudiamos el mejor punto de partida

Indícanos cuántas sociedades y ERP intervienen, el principal problema de cierre o integración y si existe una fecha de decisión. Con esa información podremos orientar la conversación hacia los riesgos y beneficios que realmente importan.

    Responsable del tratamiento: AYESA IMPLEMENTACIONES TECNOLÓGICAS S.A.U.
    Finalidades: i) Gestionar y responder a las consultas recibidas a través del formulario de contacto del sitio web. ii) Enviar comunicaciones comerciales de Ayesa Digital, en caso de que así lo consienta expresamente.
    Base jurídica: Consentimiento del interesado.
    Destinatarios: No se prevén cesiones de datos a terceros.
    Derechos: Puede ejercer sus derechos de acceso, rectificación, supresión, oposición, limitación y portabilidad, según se detalla en la información adicional. Información adicional: Puede consultar la información adicional y detallada sobre protección de datos en nuestro Registro de Actividades de Tratamiento

    He leído y acepto la Política de Privacidad.

    Documentación de referencia: Microsoft Learn · Consolidación en Business Central · Microsoft Learn · Consolidación en Dynamics 365 Finance · Microsoft Learn · APIs e integración en Business Central. Ejemplos de negocio y costes: simulaciones didácticas, no casos reales ni presupuestos vinculantes.