El problema no es tener varias empresas. Es mantener varias versiones de la verdad.
Cuando una referencia de cliente, proveedor o artículo cambia, una organización necesita saber dónde se modifica, qué sociedades deben recibirla y cómo comprobar que sigue siendo válida.
Imagina un grupo que ha crecido mediante adquisiciones. La sociedad matriz mantiene acuerdos de compra y un catálogo de productos común, mientras cada filial opera con sus almacenes, idiomas, monedas, responsables financieros y condiciones comerciales. Algunas unidades comparten un entorno de Business Central; otras trabajan en entornos distintos por razones geográficas, organizativas o de administración. Cada equipo cree que conoce los datos correctos. Sin embargo, los códigos se duplican, una descripción cambia solo en una filial y dos proveedores aparentemente diferentes son la misma entidad jurídica.
En ese escenario, el verdadero coste no es volver a escribir una ficha. Son los pedidos que no encuentran el artículo adecuado, los informes que mezclan categorías incompatibles, las compras que no aprovechan acuerdos de grupo, las facturas que llegan con datos incompletos y el tiempo dedicado a reconciliar información. La consolidación financiera puede seguir funcionando, pero las decisiones de gestión pierden fiabilidad porque cada sociedad utiliza definiciones diferentes.
La evolución de la gestión de datos maestros entre entornos de Business Central es interesante precisamente por eso. Microsoft mostró esa dirección en Directions EMEA 2026. Aun así, conviene separar la novedad anunciada del producto que una empresa puede configurar hoy: la documentación vigente del mecanismo estándar sigue exigiendo que las sociedades estén en el mismo entorno. Microsoft Learn documenta expresamente ese requisito.
Compartir datos no significa unificar todas las decisiones
La empresa debe acordar qué información es común, qué información pertenece a cada filial y quién responde cuando ambas necesidades entran en conflicto. El diseño de responsabilidades tiene más impacto que la elección del conector.
Empresa y entorno: una diferencia que cambia completamente el proyecto
Antes de hablar de sincronización hay que entender qué se está conectando.
Una sociedad dentro del ERP
Representa una entidad operativa o legal dentro de Business Central. Puede disponer de su propia contabilidad, clientes, proveedores, artículos, documentos y reglas. Varias empresas pueden coexistir en un mismo entorno.
Una unidad de administración y operación
Es el espacio donde viven una o varias empresas y donde se administran aplicaciones, actualizaciones y configuraciones. Un grupo puede separar países, unidades o ciclos operativos en entornos diferentes.
Sincronización estándar documentada
Business Central permite organizar un origen y varias filiales para compartir determinadas tablas y campos. La función estándar está documentada como una sincronización unidireccional entre empresas del mismo entorno.
Una necesidad más exigente
No basta con seleccionar la empresa origen. Deben resolverse autorización entre entornos, compatibilidad de esquemas, identidad de registros, reglas de sobrescritura, observabilidad y responsabilidad sobre el dato.
Microsoft explica esta diferencia en su documentación sobre empresas y entornos de Business Central. Un grupo con seis sociedades no necesita necesariamente seis entornos: puede administrar varias empresas dentro de uno. La decisión depende de ubicación, extensiones, gobernanza, restricciones operativas, ciclo de actualizaciones y necesidades de separación.
La distinción importa porque determina qué funciones puede utilizar la compañía sin desarrollo adicional. Una solución que funciona bien entre sociedades del mismo entorno no debe darse por aplicable automáticamente a filiales situadas en entornos separados. Tampoco debe confundirse un entorno de pruebas con otro de producción: duplicar datos entre ambos sin criterios de seguridad puede originar exposiciones innecesarias y pruebas poco fiables.
Qué mostró Microsoft en París y qué podemos afirmar con seguridad
Una novedad útil y necesaria en grupos empresariales
Hoy: compartir entre empresas del mismo entorno
La documentación oficial describe una empresa origen y filiales que recuperan datos maestros mediante un proceso unidireccional. Los cambios se procesan a través de trabajos programados y se supervisan desde el ERP.
Evolución anunciada: conectar entornos
En Directions EMEA 2026 se presentó la evolución de Master Data Management across environments: compartir información maestra entre sociedades ubicadas en entornos distintos de Business Central.
Antes de implantar: validar alcance y disponibilidad
No hemos encontrado una guía pública definitiva del nuevo mecanismo que permita garantizar fecha, configuración, tablas admitidas, límites o disponibilidad general. Estos puntos deben confirmarse en la hoja de ruta y en el entorno de cada cliente.
El anuncio es relevante, pero no sustituye una validación técnica. Una diapositiva de producto puede explicar hacia dónde evoluciona la plataforma sin detallar todos los requisitos. En particular, no sabemos por la documentación pública consultada si estarán admitidos todos los tipos de tablas, las extensiones de terceros, la sincronización entre regiones con distintas restricciones de residencia de datos o escenarios que mezclen organizaciones y tenants distintos. Sería un error presentarlos como resueltos.
El punto verificable hoy es la capacidad estándar de sincronización de datos maestros entre empresas del mismo entorno y el funcionamiento de la supervisión de esas sincronizaciones. Existen además mecanismos de integración entre aplicaciones y entornos mediante APIs o Dataverse, pero eso constituye una arquitectura que debe diseñarse, no una equivalencia automática con la nueva función anunciada.
La hoja de ruta no es un compromiso de disponibilidad
Se puede analizar el caso de negocio y preparar los datos desde ahora. La contratación de una implantación que dependa específicamente de la novedad entre entornos debe supeditarse a validar disponibilidad, requisitos técnicos y soporte real en el cliente.
Así debería viajar un dato maestro: del propietario a cada filial
El objetivo no es trasladar todos los registros, sino mantener una fuente autorizada y permitir excepciones locales bien definidas.
El esquema introduce una distinción fundamental: hay atributos que deberían mantenerse idénticos y otros que pertenecen a cada sociedad. El código internacional de un fabricante, una categoría de producto o una denominación aprobada pueden tener una definición común; la tarifa comercial, el almacén, el grupo contable o el plazo negociado pueden seguir siendo locales. Sin esta separación, la sincronización puede sustituir la duplicidad por un problema más grave: sobrescribir información correcta de las filiales.
Otro punto crítico es el identificador. Si el mismo proveedor aparece con números distintos en cada entorno, no basta con copiar su nombre. Hay que decidir cómo vincular las identidades, qué ocurre con los documentos históricos, cuándo procede fusionar y cuándo deben permanecer dos registros por razones legales o contractuales. La solución debe preservar la trazabilidad de todos esos cambios.
Qué conviene compartir y qué necesita seguir siendo local
Una política de datos maestros bien diseñada evita que la armonización comprometa la autonomía necesaria para operar.
Identidad común; relación comercial local
Pueden compartirse datos identificativos y algunas clasificaciones. Condiciones de pago, límites de crédito, responsables comerciales, impuestos y consentimientos requieren reglas por sociedad o jurisdicción.
Un tercero; diferentes condiciones de compra
Razón social, identificadores y determinadas categorías pueden centralizarse. Cuentas bancarias, métodos de pago, retenciones, condiciones, aprobaciones y contratos necesitan un control específico.
Catálogo global sin perder la operación local
Unidades, descripciones homologadas, familias y atributos pueden beneficiarse de un origen común. Costes, existencias, reposición, almacenes, disponibilidad y precios pueden pertenecer a cada unidad.
Mayor exigencia de privacidad
Cuando se comparten datos personales, debe justificarse la finalidad, la minimización y quién puede verlos. No todo dato disponible en un ERP debería distribuirse a otros entornos.
Coherencia para informar y comparar
Centros de coste, familias, sectores y otras clasificaciones son útiles si representan el mismo concepto. Una categoría global mal definida puede empeorar la calidad de los informes del grupo.
Dependencia de esquema y versión
Los desarrollos de terceros pueden añadir campos y tablas relevantes. La compatibilidad entre entornos, las reglas de correspondencia y el impacto de actualizaciones deben probarse antes de activar cualquier sincronización.
La respuesta correcta no es siempre compartir más. Algunas organizaciones descubren durante el análisis que necesitaban un catálogo corporativo de cien atributos, pero estaban duplicando cientos de campos operativos sin valor fuera de la filial. Reducir el alcance mejora seguridad, simplifica pruebas y evita discusiones interminables sobre detalles que no afectan a los resultados del grupo.
Conviene documentar cada conjunto de información con una ficha sencilla: propietario, propósito, regla de alta, identificador, campos compartidos, excepciones, frecuencia de actualización, acceso, criterio de validación y procedimiento de reversión. Esas fichas permiten que un cambio de responsable o una adquisición futura no obliguen a reconstruir las decisiones tomadas durante el proyecto.
¿Quién puede cambiar un dato y quién responde cuando se equivoca?
El mayor riesgo de la sincronización no es técnico: es distribuir un error de forma consistente a todas las sociedades.
La empresa suele descubrir que no existe un único propietario del dato. Compras decide proveedores homologados, ventas mantiene la relación comercial, finanzas establece condiciones contables y tecnología administra los sistemas. Cuando esas responsabilidades no están definidas, la incorporación de una herramienta de sincronización introduce un conflicto que ya existía, solo que ahora se propaga con mayor rapidez.
Nombrar un propietario funcional
Cada familia de información debe tener una persona o unidad que apruebe altas y cambios relevantes. Tecnología administra la plataforma, pero no decide qué proveedor es válido.
Definir reglas de calidad
Establecer campos obligatorios, validación de identificadores, formatos, duplicados, estado activo, criterios de clasificación y motivos aceptables para una excepción.
Asignar permisos por función
Separar la solicitud de cambios, la aprobación, la ejecución y la supervisión. Las cuentas técnicas y los equipos de soporte deben disponer solo del alcance necesario.
Preparar gestión de conflictos
Decidir qué ocurre cuando una filial modifica un campo común, cuándo se bloquea la actualización, quién arbitra y cómo se restaura el valor adecuado.
Registrar y medir
Mantener evidencias del origen, cambios, fallos, retrasos, reconciliaciones y decisiones de excepción. La calidad de datos necesita indicadores, no solo un responsable nominal.
Revisar el modelo periódicamente
Una adquisición, una nueva normativa o un cambio de extensión pueden alterar las reglas. El modelo de sincronización debe evolucionar con el negocio.
Las funciones estándar documentadas por Microsoft para el mismo entorno permiten elegir tablas y campos, realizar el emparejamiento inicial y gestionar ciertos cambios locales. No obstante, la sincronización es unidireccional y la guía explica que habilitar un campo y permitir simultáneamente su modificación autónoma en la filial puede provocar conflicto. El tratamiento de cambios locales y errores se describe en Microsoft Learn.
Para los entornos diferentes, conviene prever un proceso formal de aprobación del diseño: responsables de datos, responsables de cada ERP, seguridad, protección de datos, finanzas y operaciones. La fase de definición no tiene por qué durar meses, pero sí debe conseguir que los participantes entiendan qué se centraliza, qué queda fuera y a quién acudir cuando un dato no coincide.
Compartir maestros, integrar aplicaciones y conciliar operaciones son tres problemas distintos
Elegir bien el problema evita que dos proyectos diferentes compitan por el mismo presupuesto.
La referencia con la que se opera
Resolver que las sociedades reconozcan el mismo artículo, tercero o clasificación autorizada. Aquí importan identidad, calidad, versiones, campos y responsables.
Los documentos entre sociedades
Registrar compras, ventas, facturas, envíos y conciliaciones entre entidades del grupo. El objetivo es que la transacción sea correcta y que el cierre no dependa de tareas manuales.
La circulación entre aplicaciones
Coordinar información de clientes, oportunidades, pedidos y estados entre Business Central, Dynamics 365 Sales u otras aplicaciones. Requiere una arquitectura y reglas propias.
La lectura transversal del grupo
Combinar registros operativos y financieros para informes comparables. Power BI o Fabric pueden utilizar datos de distintos orígenes sin actuar como mecanismo de mantenimiento de maestros.
Esta separación es importante también para la búsqueda de información. Si una empresa necesita registrar automáticamente facturas entre sociedades, debe analizar operaciones intercompany con Business Central. Si está implantando el ERP y necesita trasladar históricos o saldos, corresponde revisar la migración de datos a Business Central. El trabajo que nos ocupa es diferente: cómo mantener información de referencia coherente a lo largo del tiempo, entre varios entornos operativos.
En empresas que combinan Business Central con otras plataformas, el modelo puede incluir Dataverse, APIs y Power Platform. Pero conectar datos no significa necesariamente que todos puedan editarlos en ambos sentidos. Las reglas deben evitar bucles, escrituras concurrentes, duplicados y una falsa sensación de que la última modificación siempre es la correcta.
Cómo resolver hoy la necesidad mientras evoluciona la función anunciada
La elección depende de cuántos entornos participan, qué datos deben compartirse y cuánto control necesita la organización.
Hay escenarios que se pueden resolver con herramientas estándar y otros que requieren integración. La documentación actual de Business Central indica que la gestión estándar de maestros entre compañías opera dentro de un único entorno. Cuando las sociedades están separadas, conviene estudiar mecanismos de integración soportados, sin presentar una extensión de terceros o un proyecto API como si fuera una funcionalidad nativa idéntica a la anunciada.
Sincronización entre sociedades del mismo entorno
Adecuada cuando el diseño organizativo permite reunir sociedades en un mismo entorno. Dispone de origen, filiales, selección de tablas y campos, emparejamiento y supervisión, con límites conocidos y documentados.
Integración controlada entre entornos
Puede resolver lecturas y escrituras autorizadas según las APIs disponibles. Permite diseñar correspondencias y validaciones propias, pero exige operación, seguridad, mantenimiento y gestión de errores.
Integración de información entre plataformas
Útil cuando ya existe un modelo de aplicaciones y datos conectado con Dataverse. Microsoft documenta escenarios de sincronización de múltiples empresas o entornos hacia Dataverse, que requieren estudiar mapeos y reglas.
Evaluación de la evolución anunciada
La propuesta de sincronización entre entornos presentada en París puede simplificar algunos escenarios. El alcance real solo debe incorporarse al plan de implantación después de verificar documentación, disponibilidad y compatibilidad.
Existe además una cuarta necesidad que a menudo se mezcla con las anteriores: consultar información consolidada. Si el objetivo es comparar ventas por sociedad, no es indispensable replicar los datos maestros mediante el mecanismo transaccional. Pueden obtenerse datos para una plataforma analítica siguiendo las rutas de integración de ERP, CRM, Power BI y Fabric. Eso resuelve la lectura, no el mantenimiento común de registros dentro de cada ERP.
Una arquitectura con APIs debe estudiar volúmenes, límites de las interfaces, claves, operaciones reintentables, confirmaciones de escritura, registros de auditoría y reconciliación periódica. Los cambios de una entidad no siempre deben propagarse inmediatamente: si el alta requiere aprobación o validación fiscal, es preferible una cola controlada a una actualización automática que extienda datos incompletos.
Las soluciones de terceros pueden acelerar escenarios concretos, pero hay que comprobar sus condiciones de soporte, licencias, restricciones entre tenants, mantenimiento tras actualizaciones de Business Central y posibilidad de recuperar el control de la información. La comparación debe basarse en requisitos verificables y coste total, no solo en una demostración atractiva.
Qué se comparte, qué se gobierna y qué se deja en cada filial
Una matriz visual para convertir debates abstractos en decisiones sobre campos y responsabilidades.
La matriz permite realizar un primer inventario sin entrar todavía en herramientas. Cada director funcional clasifica atributos y justifica excepciones. El CIO comprueba la viabilidad técnica de distribuirlos. El CFO revisa qué criterios afectan a contabilidad, pagos, auditoría y cierre. Compras, operaciones y ventas valoran las consecuencias en transacciones reales. Las discrepancias se resuelven antes de configurar un flujo que después será costoso modificar.
La clasificación no debe ser rígida. Una descripción global puede exigir traducciones locales; una referencia de proveedor puede estar compartida y, a la vez, necesitar un código fiscal distinto; un artículo puede tener unidad corporativa pero conversiones específicas por almacén. De ahí que sea útil registrar decisiones por campo y no declarar que toda la ficha es global o local.
Cinco situaciones donde los datos maestros entre entornos sí pueden importar
El interés aumenta cuando la empresa necesita autonomía operativa sin renunciar a una identidad común.
Catálogo de artículos entre plantas
Una compañía industrial administra referencias comunes de materia prima, producto y proveedor, pero cada planta conserva listas de materiales, almacenes, rutas de producción, aprovisionamiento y costes. La coherencia del catálogo reduce errores de clasificación y facilita compras coordinadas.
Productos y proveedores en filiales comerciales
Un distribuidor internacional puede querer mantener el mismo código y familia de producto, con tarifas y condiciones fiscales propias por país. El beneficio potencial es ganar velocidad en el alta de referencias sin uniformizar decisiones comerciales que deben seguir siendo locales.
Proveedores homologados en sociedades de proyecto
Un grupo constructor o promotor puede operar mediante sociedades independientes. Compartir determinados terceros y categorías facilita el control corporativo, pero cada proyecto mantiene contratos, certificaciones, impuestos, retenciones y estructuras de costes específicas.
Integración progresiva de nuevas compañías
Una adquisición puede mantener su entorno durante un periodo de transición. El reto es comenzar a armonizar identidades y categorías sin forzar un reemplazo inmediato de todo el ERP ni destruir el histórico de operaciones.
Clasificaciones homogéneas para comparar
Una organización de servicios con entidades jurídicas separadas puede beneficiarse de categorías y maestros de referencia compartidos, mientras conserva diferencias de contratos, clientes y condiciones de facturación locales.
Autonomía de cada país, visión de grupo
La centralización de ciertos registros puede mejorar la incorporación de nuevas filiales. Pero residencia de datos, tratamiento fiscal, permisos y necesidades de configuración deben revisarse país por país.
En todos los casos conviene empezar por una familia de datos con impacto demostrado. No tendría sentido un gran proyecto corporativo para armonizar cincuenta mil registros que casi nunca cambian si el problema que más perjudica al negocio son los cien artículos que generan errores en pedidos intersociedad. Elegir un piloto con operaciones reales permite medir el beneficio sin convertir el alcance en una iniciativa interminable.
Ayesa aborda este tipo de decisiones desde una visión conectada de Business Central como ERP empresarial, integración de aplicaciones y gobierno de datos. El diseño debe comenzar por qué procesos y sociedades necesitan coherencia, no por qué producto de integración resulta más atractivo.
Mover información entre entornos amplía el perímetro de responsabilidad
La autorización técnica para leer o escribir un registro no equivale a una autorización de negocio para compartirlo.
En proyectos multiempresa, los entornos pueden existir precisamente para mantener separación. Conectar esa información exige revisar el motivo original de la separación: país, unidad jurídica, región, privacidad, aplicaciones instaladas, responsabilidades y equipos de soporte. Si el dato se incorpora a otro entorno, puede cambiar quién lo ve, quién lo modifica y dónde se conserva una copia.
La evaluación debe cubrir identidades de aplicación, permisos mínimos, autorización por entidad, cifrado en tránsito, registros de acceso, retención, gestión de secretos, cuentas de servicio y procesos de revocación. Si se utilizan APIs, los permisos tienen que limitarse a las operaciones estrictamente necesarias. Si existen desarrollos o extensiones, la revisión también debe considerar los campos que incorporan y las posibles dependencias de seguridad.
Los datos personales requieren un análisis adicional: finalidad del tratamiento, legitimación, minimización, derechos de acceso o rectificación y posibles transferencias internacionales. El hecho de que una entidad sea parte del mismo grupo empresarial no autoriza automáticamente a compartir cualquier dato. En proyectos con varias regiones, la protección de datos debe participar en las decisiones sobre campos y destinatarios.
No hay que olvidar el entorno de pruebas. Una reproducción de maestros reales puede incluir información financiera o personal que no se necesita para verificar un proceso. Las opciones de anonimización, generación de datos sintéticos y limitación de acceso deben diseñarse antes de copiar información. Lo mismo ocurre con los logs: registrar que una ficha falló puede ser necesario; reproducir en un registro técnico todos sus datos sensibles, no.
Qué ocurre cuando un dato no llega, llega dos veces o llega mal
Una sincronización fiable necesita procedimientos de fallo, no solo una configuración inicial.
Identificadores que no coinciden
El mismo proveedor figura con códigos distintos en dos sociedades. Se requiere una regla de correspondencia, tratamiento de duplicados y validación de documentos vinculados, no una copia ciega.
Cambios simultáneos
La matriz y la filial modifican un campo compartido. El sistema debe identificar quién tiene prioridad, cuándo bloquear una sobrescritura y cómo resolver la excepción.
Extensiones diferentes
Una sociedad utiliza un campo personalizado que otra no tiene. El diseño debe comprobar compatibilidad de versiones y definir si ese atributo queda fuera del intercambio.
Sincronización interrumpida
Una credencial caduca, una API responde con error o una tarea se retrasa. Debe existir alarma, cola de reintentos, registro de incidencias y reconciliación posterior.
Datos no válidos
Una dirección incompleta o una categoría incorrecta pasa todas las comprobaciones técnicas y contamina los registros receptores. Hace falta validar reglas de negocio antes de distribuir.
Sobrescritura no deseada
Un valor corporativo reemplaza una condición contractual local. Deben existir campos protegidos, pruebas de regresión y un procedimiento de recuperación.
Microsoft documenta expresamente en la gestión estándar dentro del mismo entorno problemas de cambios concurrentes, mecanismos para inspeccionar sincronizaciones, actualización de esquemas y opciones de sobrescritura. Son lecciones aplicables al diseño de cualquier arquitectura de datos compartidos, aunque no permiten asumir que la futura capacidad entre entornos tendrá exactamente la misma interfaz o tratamiento técnico.
La operación diaria debe responder tres preguntas sencillas: ¿qué se ha actualizado desde la última ejecución?, ¿qué registros han fallado y por qué?, ¿qué persona puede decidir la corrección? Si nadie puede responderlas sin consultar al desarrollador, el proyecto no está terminado. La gestión de datos maestros es un servicio continuo para el negocio, no un proceso que se da por cerrado al activar una sincronización.
Indicadores que deberían interesar al CFO, CIO y dirección de operaciones
El beneficio tiene que observarse en los procesos del grupo y en la calidad de sus decisiones.
Tasa de duplicados
Medir registros duplicados por familia de datos, tanto antes como después del piloto. Un dato «sincronizado» puede seguir siendo un duplicado si el emparejamiento inicial no se ha resuelto bien.
Tiempo de alta y actualización
Registrar cuánto tarda una referencia aprobada en estar disponible de forma correcta en las sociedades que deben utilizarla, incluida la validación funcional.
Incidencias en transacciones
Contar pedidos, facturas y movimientos afectados por datos incompletos, incorrectos o inconsistentes entre sociedades. Esta medida conecta el proyecto con el coste real.
Cambios fallidos y su antigüedad
Revisar el volumen de sincronizaciones con error, la causa, el tiempo de resolución y los fallos repetidos. La fiabilidad importa tanto como la rapidez.
Trabajo manual evitado
Medir cuántas fichas se dejan de mantener por duplicado y cuánto tiempo invierten los equipos en excepciones, correcciones o conciliaciones.
Satisfacción y adopción
Comprobar si compras, finanzas y operaciones confían en las referencias compartidas y si utilizan el proceso aprobado en lugar de mantener hojas paralelas.
El retorno económico debe calcularse con supuestos explícitos. Un modelo sencillo puede sumar el tiempo administrativo evitado, el coste de incidencias reducido y los beneficios de calidad de información, y restar licencias, implantación, soporte y gobierno. Pero no conviene convertir cada minuto ahorrado en ahorro de plantilla: puede representar capacidad liberada para atender más volumen, mejorar servicio o reducir retrasos. El análisis financiero debe diferenciar ahorro contable y mejora de productividad.
Un piloto razonable se compromete a medir tres indicadores principales: duplicados, incidencias operativas y tiempo de incorporación de registros. Después pueden añadirse métricas más ambiciosas. Si la compañía intenta medir veinte resultados desde el principio sin disponer de fuentes fiables, el proyecto acaba discutiendo cómo calcular los indicadores en lugar de mejorar la calidad de los datos.
Cómo validar una arquitectura sin poner en riesgo todas las sociedades
Una prueba de alcance reducido debe demostrar calidad, seguridad, control y utilidad para el negocio.
Elegir un dominio prioritario
Seleccionar artículos o proveedores donde exista un problema conocido, varios destinatarios y un responsable funcional claro.
Inventariar dos entornos
Revisar sociedades, versiones, extensiones, tablas, campos, datos sensibles, número de registros y cambios necesarios.
Acordar reglas y excepciones
Determinar el origen autorizado, campos compartidos, validaciones, políticas locales, conflictos y responsables.
Seleccionar tecnología verificada
Utilizar las capacidades estándar cuando el diseño lo permita o una integración soportada para entornos separados. No depender de funcionalidades anunciadas sin documentación de disponibilidad.
Probar fallos reales
Verificar duplicados, altas, modificaciones, borrados permitidos, errores de credenciales, datos incompletos y restauración de cambios no deseados.
Medir, decidir y ampliar
Comparar los resultados con la situación inicial y definir si el modelo merece extenderse a otras sociedades o familias de información.
El piloto debe incluir a usuarios que crean y corrigen fichas reales. Su participación ayuda a detectar restricciones que no aparecen en una arquitectura: un proveedor debe validarse por cumplimiento antes de usarse; un artículo no puede activarse hasta recibir una certificación; una filial necesita mantener una descripción local para que sus documentos comerciales sean correctos. Estas reglas suelen explicar por qué los proyectos aparentemente sencillos generan tantos cambios en producción.
También es útil establecer un umbral de salida: ningún registro crítico sin propietario, cero sobrescrituras de campos protegidos durante la prueba, errores con diagnóstico y una forma de reconciliar los datos después de una interrupción. Los valores exactos de aceptación deben acordarse con el cliente; la idea no es imponer porcentajes universales, sino convertir riesgos conocidos en criterios verificables.
CEO, CFO, CIO y operaciones no necesitan cuatro proyectos distintos
Necesitan una misma decisión explicada desde el resultado que afecta a cada área.
¿Podemos incorporar filiales sin multiplicar el desorden?
La pregunta es si el modelo ayudará a integrar adquisiciones, coordinar unidades y mantener una visión coherente de proveedores, clientes y catálogo. No se trata de imponer el mismo proceso a todas las empresas.
¿Qué errores y costes operativos vamos a reducir?
La inversión debe explicar cómo disminuirá la duplicidad, mejorará el control sobre terceros y reducirá incidencias que afectan pagos, compras, ventas y reporting. Los costes de implantación y mantenimiento también cuentan.
¿Qué simplifica hoy y qué compromete mañana?
Deben verificarse soporte de las APIs, derechos de acceso, entornos, versiones, dependencias de extensiones, continuidad, integraciones y coste de evolución ante futuras capacidades nativas.
¿Cómo evitamos que un dato incorrecto pare una operación?
Interesan referencias disponibles a tiempo, menor retrabajo, menos excepciones y la posibilidad de mantener particularidades de cada planta, obra, almacén o equipo.
La conversación de dirección debería acabar con un resultado concreto: una prioridad funcional, un mapa de datos compartidos, un diseño posible para los entornos actuales y una decisión sobre la prueba inicial. No hace falta decidir toda la plataforma en la primera reunión. Sí es necesario saber qué problema se quiere resolver, cómo se demostrará la mejora y cuál será la responsabilidad del negocio una vez que el sistema funcione.
Sin datos maestros fiables, los informes y los agentes también se equivocan
La coherencia del dato no es un proyecto aislado. Es la base de un ERP que pueda trabajar conectado con otros sistemas.
Los informes de Power BI y los modelos sobre Microsoft Fabric pueden reunir datos de varias sociedades, pero no corrigen automáticamente la identidad de un proveedor ni determinan qué artículo corresponde a otro. Si una empresa utiliza tres códigos diferentes para la misma referencia, una herramienta analítica puede acabar mostrando tres resultados separados. La solución comienza con definiciones compartidas y reglas de correspondencia.
Lo mismo sucede con la inteligencia artificial. Un agente que recomienda compras o responde preguntas sobre márgenes necesita confiar en la identidad de clientes, productos y proveedores. Si consulta información duplicada, puede sumar operaciones incompatibles o presentar como equivalentes registros que no lo son. Un dato maestro bien gobernado aumenta las posibilidades de que una aplicación inteligente utilice el contexto adecuado, aunque no elimina la necesidad de comprobar resultados, permisos y fuentes.
La arquitectura de Ayesa365 conecta Business Central, Power Platform aplicada al ERP, datos y analítica con Fabric y el hub Azure + IA empresarial. Cada componente resuelve una necesidad diferente: el ERP ejecuta transacciones, la integración distribuye información autorizada, la analítica ayuda a comprender el negocio y los agentes pueden asistir o actuar dentro de los permisos definidos. El modelo de datos debe unirlos sin convertirse en otro silo.
Conviene no confundir compartir datos maestros con replicar datos para análisis. Un informe que lee información desde distintas sociedades puede necesitar normalizar claves y clasificaciones, pero eso no significa que deba escribir registros en los ERP de origen. En cambio, si varias filiales deben utilizar una nueva referencia corporativa en sus pedidos, hablamos de mantener registros operativos coherentes. La decisión sobre lectura o escritura cambia la tecnología, la seguridad y el nivel de riesgo.
El objetivo es conectar empresas y procesos sin perder trazabilidad
La experiencia en ERP, integración y plataformas de datos debe servir para tomar decisiones mejores, no para añadir complejidad.
Ayesa Digital combina capacidades en Microsoft Dynamics 365 Business Central, Azure, Power Platform, Power BI y soluciones para sectores empresariales. Para una organización con varios entornos de ERP, esa combinación permite trabajar simultáneamente en el diseño funcional de maestros, la arquitectura de intercambio, la seguridad y la explotación posterior del dato. La prioridad es conocer cómo opera la compañía antes de proponer una tecnología específica.
Un análisis inicial puede identificar que la empresa tiene dos entornos que deberían permanecer separados; que gran parte de sus incidencias procede de unas pocas familias de datos; o que los mayores problemas se resolverían primero mediante reglas de alta y limpieza, incluso antes de activar nuevos flujos. Estos porcentajes deben calcularse en cada proyecto y no extrapolarse: lo importante es que el diagnóstico pueda encontrar soluciones más sencillas cuando corresponda.
En algunos casos será suficiente la función estándar entre sociedades del mismo entorno. En otros convendrá una integración por APIs o Dataverse. Y en escenarios donde la nueva capacidad anunciada por Microsoft demuestre cumplir requisitos y disponibilidad, podrá evaluarse como una alternativa adicional. El criterio debe ser sostenibilidad, trazabilidad y resultados empresariales, no dependencia de una promesa de producto.
Un mapa para profundizar sin confundir problemas diferentes
El siguiente paso depende de si el reto es compartir maestros, registrar operaciones, migrar información o analizar datos.
Dynamics 365 Business Central
Cuándo encaja el ERP de Microsoft y qué debe revisar dirección antes de implantarlo.
Operaciones intercompany
Cómo gestionar transacciones, documentos y conciliaciones entre sociedades, un problema diferente del dato maestro.
Migración de datos a Business Central
Qué información llevar al ERP durante un cambio o implantación, con limpieza, históricos y saldos.
Business Central + Power Platform
Cómo integrar aplicaciones y automatizar procesos alrededor del ERP sin perder el gobierno.
ERP, CRM, Power BI y Fabric
Arquitecturas para leer y analizar datos de distintos sistemas sin confundir analítica con sincronización transaccional.
Azure e IA empresarial
Cómo preparar datos, seguridad y aplicaciones para soluciones inteligentes que utilizan información corporativa.
Directions EMEA 2026
El contexto del anuncio de Microsoft y las otras capacidades presentadas en París.
Business Central para empresas medianas
Una evaluación global de encaje funcional, complejidad, integraciones, datos y crecimiento.
Las dudas que conviene resolver antes de conectar varios entornos
Respuestas breves sobre alcance, disponibilidad, decisiones funcionales y riesgo.
¿Puede Business Central sincronizar hoy datos maestros entre empresas del mismo entorno?
Sí. Microsoft documenta una función de sincronización con empresa origen, filiales, selección de tablas y campos, emparejamiento de registros y ejecución mediante trabajos programados. El alcance y los permisos deben configurarse.
¿La función estándar actual admite empresas en distintos entornos?
La documentación estándar consultada exige expresamente que todas las empresas estén en el mismo entorno. Microsoft ha mostrado una evolución para escenarios entre entornos, pero antes de planificar su uso deben confirmarse disponibilidad y condiciones.
¿Compartir datos maestros equivale a integrar operaciones intercompany?
No. Los maestros son referencias como clientes, proveedores y artículos. Intercompany gestiona documentos y transacciones entre sociedades, con procesos contables y conciliaciones específicos.
¿La sincronización puede ser bidireccional?
En la función estándar actual Microsoft documenta un modelo unidireccional desde origen hacia filiales y desaconseja configurar dos direcciones por riesgo de conflictos o sobrescrituras. Una integración personalizada requiere reglas propias.
¿Hay que compartir todos los campos de clientes o proveedores?
No debería ser el punto de partida. Conviene clasificar los atributos por responsabilidad corporativa, necesidad local, sensibilidad y efecto sobre procesos y normativa.
¿Qué sucede si dos sociedades ya tienen duplicados?
Antes de sincronizar debe definirse un emparejamiento de identidades, revisar los registros afectados y decidir qué diferencias se conservan. Copiar sin reconciliar puede propagar errores.
¿Una empresa puede mantener distintos precios para el mismo artículo?
Sí, conceptualmente los atributos compartidos y los locales pueden separarse en el diseño. Qué campos pueden controlarse de esa manera depende de la configuración y del mecanismo de integración utilizado.
¿Podemos utilizar Dataverse para conectar varios entornos?
Microsoft documenta integración con Dataverse y escenarios que incluyen varias empresas o entornos. La viabilidad concreta depende de tablas, mapeos, reglas, permisos, licencias y arquitectura.
¿Qué precauciones hay con datos personales?
Es necesario revisar finalidad, base jurídica, minimización, accesos, retención, localización y posibles transferencias. La pertenencia al mismo grupo no elimina las obligaciones de protección de datos.
¿Cómo se justifica la inversión?
Midiendo duplicados, incidencias, tiempo de incorporación de registros, trabajo manual evitado y coste de mantenimiento, frente a los costes de implantación, plataforma, soporte y gobierno.
¿Hay que esperar a que la novedad de Microsoft esté disponible?
No necesariamente. Se pueden definir propietarios, limpiar datos y evaluar alternativas soportadas. Solo deberían posponerse compromisos que dependan específicamente de la nueva capacidad sin validar.
¿Qué información necesita Ayesa para evaluar el caso?
Número de empresas y entornos, países, familias de datos, volúmenes, incidencias, extensiones, integraciones, responsables, criterios de seguridad y objetivo de negocio.
Documentación y contexto para verificar el alcance de cada escenario
La evolución de Microsoft debe interpretarse a partir de la documentación publicada y del estado concreto de cada función.
Microsoft Learn · Configurar sincronización de datos maestros
Requisito de mismo entorno, origen y filiales, tablas y campos.
Microsoft Learn · Administrar sincronización de datos maestros
Supervisión, tratamiento de cambios locales, conflictos y trabajos.
Microsoft Learn · Sincronización con Dataverse
Escenarios de integración entre empresas y entornos mediante Dataverse.
Microsoft Learn · Empresas y entornos en Business Central
Definiciones de company y environment y sus implicaciones.
Directions EMEA 2026 · Crónica Ayesa Digital
Contexto del anuncio sobre Master Data Management across environments.
¿Tus sociedades comparten datos o están multiplicando errores?
Ayesa puede ayudarte a identificar qué maestros conviene unificar, cómo gobernarlos y qué alternativas técnicas encajan con tus entornos actuales de Business Central, sin depender de promesas de disponibilidad.
Qué podemos evaluar juntos
Sociedades y entornos, datos compartidos, duplicidades, responsables, integraciones, cumplimiento, aplicaciones instaladas y opciones de evolución.
El objetivo es obtener un primer mapa de decisiones y un posible piloto, no iniciar una implantación sin un alcance bien definido.
Cuéntanos qué necesitas conectar
Indica cuántas sociedades o entornos utilizáis y qué registros generan más incidencias. Nos ayudará a orientar la primera conversación.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)