Dynamics 365 ERP MCP: cómo conectar agentes con datos, formularios y acciones del ERP
Microsoft está convirtiendo Finance & Operations en una plataforma que puede exponer capacidades del ERP a agentes compatibles sin diseñar una API diferente para cada caso. La clave no es el protocolo en sí: es qué datos y acciones ponemos a disposición de la IA, con qué permisos y para qué proceso.
El servidor Dynamics 365 ERP MCP ya no debe entenderse como una curiosidad para desarrolladores. En 2026 pasa a formar parte de una arquitectura empresarial donde Copilot Cowork, Copilot Studio y otros clientes compatibles pueden descubrir herramientas del ERP, trabajar con registros, navegar formularios y utilizar lógica de negocio dentro del modelo de seguridad de Dynamics 365.
MCP no es “darle acceso al ERP a la IA”. Es convertir capacidades del ERP en herramientas gobernadas.
MCP significa Model Context Protocol, un estándar que permite que una experiencia de IA descubra y utilice herramientas y recursos publicados por un servidor compatible. En Dynamics 365 Finance & Operations, el interés empresarial aparece porque Microsoft ha llevado ese patrón al propio ERP. En lugar de construir una integración específica para cada agente, el servidor Dynamics 365 ERP MCP ofrece un marco dinámico para que plataformas de agentes autorizadas trabajen con datos y lógica de negocio del sistema.
La diferencia es importante. Durante años, integrar un asistente con un ERP significaba diseñar conectores, APIs, endpoints, autenticación, tratamiento de errores y lógica específica para cada escenario. Ese trabajo sigue siendo necesario en determinados casos, pero MCP introduce una capa estandarizada para describir herramientas disponibles y permitir que el cliente de IA las descubra. La consecuencia no es que “ya no haga falta integrar”. La consecuencia es que parte de la integración puede convertirse en una capacidad reutilizable y gobernable.
Microsoft documenta que el nuevo servidor dinámico puede permitir a agentes trabajar con datos y realizar prácticamente cualquier función disponible para un usuario a través de la interfaz, siempre dentro de los requisitos de producto, clientes permitidos y permisos de seguridad. Esa frase cambia el nivel de riesgo y de oportunidad. Si un agente puede actuar casi como un usuario, la pregunta decisiva deja de ser cómo crear un prompt y pasa a ser qué funciones queremos exponer, quién puede utilizarlas, qué controles necesitamos y qué procesos merecen realmente esa autonomía asistida.
Tres tipos de herramientas explican por qué el ERP MCP cambia el alcance de los agentes
La versión dinámica del servidor ERP MCP es especialmente relevante porque cambia el modelo anterior basado en un conjunto limitado de herramientas estáticas. Microsoft indica que la versión estática anterior, construida sobre el framework de conectores Dataverse y limitada a trece herramientas concretas, se retirará el 1 de octubre de 2026. Para organizaciones que ya estén experimentando con MCP en Finance & Operations, no es un detalle menor: conviene comprobar qué arquitectura utilizan y planificar la transición para evitar construir nuevos escenarios sobre una base que tiene fecha de retirada.
Herramientas de datos
Permiten realizar operaciones sobre entidades de datos de Finance & Operations. Sirven para consultar registros y, según herramienta y permisos, crear, actualizar o eliminar información. El agente no debería saltarse el modelo de seguridad: actúa con el contexto de identidad autorizado.
Herramientas de formulario
Permiten interactuar con la experiencia de aplicación: abrir páginas, localizar controles, establecer valores y ejecutar acciones disponibles en formularios. Son especialmente relevantes para procesos donde la lógica no vive únicamente en una entidad de datos.
Herramientas de acción
Exponen lógica de negocio invocable como herramienta. Aquí pueden encapsularse operaciones específicas y convertirlas en capacidades que el agente utiliza cuando el proceso lo requiere, en lugar de intentar reproducir toda la lógica fuera del ERP.
La evolución hacia un servidor dinámico también encaja con una necesidad más amplia: reducir la dependencia de herramientas rígidas y permitir que los agentes trabajen con un catálogo que refleja mejor las capacidades reales del entorno. Esto no elimina la disciplina de diseño. Al contrario: cuanto más dinámico y poderoso es el acceso, más importante es documentar qué puede hacer cada cliente, qué usuarios están autorizados y cómo se auditan las acciones.
El valor de MCP no está en conectar más sistemas. Está en evitar que cada agente necesite una integración distinta para hacer el mismo trabajo.
Si varios agentes necesitan consultar proveedores, revisar pedidos, abrir registros, leer documentos o ejecutar una acción del ERP, una arquitectura basada en herramientas reutilizables puede reducir duplicidad y facilitar gobierno. Pero solo funciona si el catálogo de herramientas tiene propósito, ownership y límites claros.
Qué cambia para la arquitectura empresarial: reutilización, menos duplicidad y una frontera más clara entre agente y ERP
Para un CIO o un responsable de aplicaciones, el principal atractivo de Dynamics 365 ERP MCP es la posibilidad de desacoplar parcialmente la lógica del agente de la lógica de integración. El agente puede cambiar, el cliente puede evolucionar y la experiencia de usuario puede ser distinta, mientras las herramientas autorizadas del ERP siguen expuestas de una forma coherente. Ese patrón abre la puerta a reutilizar capacidades entre Copilot Studio, Copilot Cowork u otros clientes compatibles.
También puede reducir una fuente clásica de deuda técnica: automatizaciones que duplican reglas del ERP fuera del ERP. Si una política de negocio ya está implementada correctamente dentro de Finance & Operations, tiene más sentido exponer una acción que utilice esa lógica que reconstruirla en otro servicio. Esto preserva una autoridad funcional más clara. El sistema de registro sigue siendo el sistema donde viven transacciones, validaciones y reglas; el agente utiliza herramientas, no inventa procesos paralelos.
Pero MCP no convierte automáticamente cualquier integración en buena arquitectura. Hay sistemas externos, procesos en tiempo real, cargas masivas, integraciones event-driven o requisitos de rendimiento para los que APIs, eventos, Azure Integration Services u otros patrones seguirán siendo más adecuados. El criterio no debe ser “usar MCP porque es nuevo”. Debe ser decidir si el problema es realmente un escenario de agente que necesita descubrir contexto y herramientas de negocio.
Seis escenarios donde MCP puede aportar valor sin sacar el proceso fuera de Dynamics 365
Los casos más interesantes no son “preguntar al ERP”. Son procesos donde una persona pierde tiempo reconstruyendo contexto y navegando entre registros antes de tomar una decisión. Ahí MCP puede acercar información, interfaz y acción dentro de una misma conversación, sin obligar a copiar el modelo de negocio a una aplicación paralela.
Finanzas: resolver excepciones de cierre
Un agente puede consultar saldos, movimientos o estados, localizar el registro relevante, combinarlo con documentación y preparar una acción o navegación concreta. La oportunidad está en acelerar el diagnóstico sin mover la lógica contable fuera de Finance.
Compras: pedidos y proveedores
Puede reunir contexto de pedidos, recepciones, facturas y proveedor; abrir registros relacionados; proponer siguientes pasos y utilizar una acción autorizada cuando el comprador aprueba la decisión.
Supply Chain: priorizar incidencias
Un agente puede consultar inventario, pedidos, disponibilidad o excepciones, razonar sobre impacto y dirigir al usuario a los registros afectados. La IA ayuda a priorizar; el ERP conserva la transacción.
Servicio interno: navegación asistida
Usuarios menos expertos pueden pedir una tarea en lenguaje natural y recibir enlaces profundos o navegación hacia el registro correcto, reduciendo el tiempo dedicado a encontrar pantallas y parámetros.
Documentos adjuntos
Microsoft ha ampliado el servidor ERP MCP para que los agentes puedan trabajar con adjuntos. Esto abre escenarios donde el contexto operativo depende tanto del registro como de documentos asociados, manteniendo una relación más directa con el objeto de negocio.
Lógica específica de empresa
Las action tools permiten exponer lógica de negocio propia como herramientas. Esto puede ser útil para procesos corporativos donde el agente necesita invocar una operación específica y controlada, no simplemente editar campos.
Conviene evitar un error frecuente: medir el éxito por el número de herramientas publicadas. Un servidor con cien herramientas difíciles de interpretar puede ser peor que uno con veinte capacidades bien descritas y alineadas con procesos. La calidad del catálogo influye en la capacidad del agente para elegir la herramienta correcta, y la documentación de Microsoft está evolucionando precisamente hacia rutas óptimas de ejecución para mejorar el rendimiento de los agentes.
Antes de hablar de agentes, revisa versión, clientes permitidos, entornos y modelo de identidad
Microsoft exige una serie de prerrequisitos para utilizar el servidor dinámico. La documentación actual señala versiones mínimas de Finance & Operations —10.0.47, 10.0.46 PQU-2 o 10.0.45 PQU-7—, además de tener habilitada la característica del servidor MCP, registrar la plataforma de agente en la lista de clientes permitidos y trabajar en un entorno compatible, como Tier 2 o Unified Developer Environment. Los Cloud Hosted Environments no están soportados para este servidor dinámico.
Más allá de la versión, el requisito más importante es de gobierno: Allowed MCP Clients. No debería poder conectarse cualquier cliente que conozca la URL. La organización debe decidir qué plataformas de agente están autorizadas a utilizar herramientas del ERP. Esa decisión necesita participación de aplicaciones, seguridad, arquitectura y, cuando el agente actúe sobre procesos sensibles, del propietario funcional.
La identidad también es central. El objetivo no es crear una “supercuenta de IA” con acceso transversal. El patrón correcto es que el usuario o identidad que ejecuta el escenario tenga permisos coherentes con lo que puede hacer en la aplicación. Si una persona no puede consultar un proveedor, modificar un pedido o lanzar una operación desde Finance & Operations, el agente no debería convertirse en una puerta trasera para hacerlo.
MCP amplía el poder del agente y también la superficie de gobierno
Exceso de permisos
El mayor riesgo no es que el modelo “alucine”, sino que una identidad tenga más capacidad de la necesaria y el agente pueda proponer o ejecutar acciones con un alcance demasiado amplio.
Herramientas ambiguas
Nombres, descripciones o parámetros poco claros pueden hacer más difícil que el orquestador elija correctamente. Diseñar herramientas también es diseñar una interfaz para la IA.
Automatizar lógica fuera del ERP
Si una regla crítica se duplica en prompts o flujos externos, aumenta el riesgo de divergencia. Conviene mantener la autoridad donde corresponde y exponer acciones controladas.
No distinguir lectura y escritura
Consultar contexto y modificar un registro tienen niveles de riesgo distintos. La arquitectura debe separar ambos y definir cuándo se necesita confirmación humana.
No registrar decisiones
En procesos financieros u operativos hay que saber qué herramienta se usó, con qué identidad, qué datos cambió y qué intervención humana existió.
Construir sobre la versión estática
Con retirada anunciada para el 1 de octubre de 2026, iniciar nuevos desarrollos sobre el servidor estático sin plan de transición crea una deuda evitable.
El principio práctico es sencillo: cuanto más capacidad de actuar tenga el agente, más formal debe ser el diseño de permisos, pruebas, supervisión y rollback. MCP facilita el acceso a herramientas; no sustituye el gobierno de la operación.
MCP no sustituye Power Automate, APIs o Azure: define una nueva capa para agentes
Una duda razonable es dónde encaja MCP frente a Power Automate, Dataverse, APIs y Azure Integration Services. No son sustitutos perfectos. MCP está orientado a que un modelo o agente descubra herramientas y recursos y los utilice en función de una intención. Power Automate es excelente para procesos deterministas, desencadenadores, conectores y secuencias previsibles. Las APIs siguen siendo fundamentales para integraciones de sistemas, rendimiento y contratos bien definidos. Azure aporta integración, eventos, seguridad, escalabilidad y servicios de datos o IA.
El patrón más potente suele ser híbrido. El agente interpreta intención y contexto; MCP le proporciona acceso estructurado al ERP; un flujo determinista ejecuta una secuencia que necesita consistencia; Azure conecta sistemas externos o procesa documentos; y Dynamics 365 conserva la transacción y la lógica de negocio. Intentar que una sola tecnología haga todo suele producir una arquitectura más frágil.
Este reparto también ayuda a controlar costes y soporte. Un proceso que siempre hace exactamente los mismos diez pasos no necesita razonamiento generativo en cada paso. Puede ser un flujo. Un proceso que necesita elegir entre varias herramientas en función de contexto puede beneficiarse de un agente. Un intercambio masivo de datos puede necesitar integración clásica. La madurez está en elegir bien la frontera.
La mejor arquitectura de agentes no es la que usa más IA. Es la que deja claro qué decide el agente, qué ejecuta un flujo y qué sigue gobernando el ERP.
Ese reparto evita duplicar reglas, limita la superficie de riesgo y permite evolucionar cada capa con más independencia. Dynamics 365 ERP MCP aporta una pieza nueva, pero necesita encajar en un modelo más amplio de Power Platform, Azure, identidad, datos y operación.
Una ruta de seis pasos para probar MCP sin convertirlo en otra isla tecnológica
Una organización que quiera experimentar con Dynamics 365 ERP MCP debería empezar con disciplina de producto, no con una demo abierta. El objetivo del piloto es demostrar que una capacidad del ERP puede utilizarse de forma segura y repetible dentro de un proceso real.
1. Selecciona un proceso, no una tecnología
Busca un proceso con fricción medible: tiempo de análisis, cambios de contexto, incidencias repetitivas o decisiones que requieren reunir datos del ERP y otros sistemas.
2. Define la autoridad de cada sistema
Qué dato es oficial, dónde vive la regla, qué sistema puede escribir y qué herramientas solo consultan. Evita crear una copia semántica del ERP en prompts o flujos.
3. Separa herramientas de lectura y acción
Clasifica qué puede consultar el agente, qué navegación puede ofrecer y qué operaciones pueden modificar datos. Añade aprobación humana donde el impacto lo justifique.
4. Revisa clientes e identidad
Autoriza únicamente plataformas necesarias, asigna permisos mínimos y comprueba que el acceso respeta funciones reales de negocio.
5. Prueba rutas y excepciones
No pruebes solo el caso feliz. Fuerza ambigüedades, datos incompletos, registros bloqueados, permisos insuficientes y herramientas parecidas.
6. Mide y escala patrones
Registra ahorro de tiempo, calidad, errores evitados, acciones rechazadas y soporte. Reutiliza herramientas y gobierno cuando el patrón demuestra valor.
El reto no es desplegar MCP. Es conectar ERP, agentes, Power Platform, Azure y seguridad dentro del mismo proceso
Ayesa Digital puede aportar valor en este tipo de escenarios porque el problema no pertenece a una única práctica. Requiere entender Finance & Operations, procesos financieros y de supply chain, extensibilidad, Power Platform, Azure, identidad, seguridad, datos y gobierno de agentes. Si cada capa se diseña por separado, las dependencias aparecen tarde y el piloto acaba necesitando más integración de la prevista.
El enfoque recomendable es identificar primero el proceso y su resultado de negocio; después revisar qué capacidades ya existen dentro de Dynamics 365, qué puede exponerse mediante MCP, qué pasos siguen siendo deterministas, qué sistemas externos intervienen y dónde hace falta supervisión humana. Así se evita utilizar el agente como una capa de pegamento que termina acumulando lógica que debería residir en la plataforma.
Esto también permite conectar la conversación con una hoja de ruta más amplia de ERP + IA. MCP no es el objetivo final. Es una pieza que puede ayudar a que agentes y copilotos trabajen sobre el sistema de registro con más contexto y menos integración específica, siempre que el entorno esté preparado para ello.
Preguntas frecuentes sobre Dynamics 365 ERP MCP
¿Qué es Dynamics 365 ERP MCP?
Es el servidor Model Context Protocol de Finance & Operations que expone herramientas para que clientes de agentes autorizados puedan trabajar con datos, formularios y lógica del ERP de forma estructurada.
¿MCP sustituye las APIs?
No. MCP resuelve un patrón distinto: proporcionar herramientas y recursos a agentes. APIs, eventos e integraciones clásicas siguen siendo necesarias para numerosos escenarios empresariales.
¿Qué ocurre con el servidor MCP estático?
Microsoft indica que la versión estática anterior se retirará el 1 de octubre de 2026. Los nuevos escenarios deberían evaluar el servidor dinámico y las organizaciones con implementaciones existentes necesitan revisar transición.
¿Puede un agente modificar datos?
Dependiendo de las herramientas expuestas y los permisos, puede realizar operaciones sobre datos o acciones. Por eso lectura, escritura, aprobación y auditoría deben diseñarse explícitamente.
¿Funciona con Copilot Studio?
Copilot Studio puede conectarse a servidores MCP y utilizar herramientas y recursos. Dynamics 365 ERP MCP también se utiliza como base de conexión en experiencias como Copilot Cowork para ERP.
¿Qué versión de Finance & Operations necesito?
Microsoft documenta versiones mínimas concretas para el servidor dinámico, entre ellas 10.0.47 y determinadas actualizaciones de 10.0.46 y 10.0.45. Conviene verificar siempre la documentación vigente antes de desplegar.
¿MCP evita el código personalizado?
Puede reducir la necesidad de conectores o APIs específicas en ciertos escenarios de agente, pero no elimina la necesidad de diseño, extensiones, acciones propias o integración cuando el caso lo requiere.
¿Cuál es el primer caso que elegiría?
Uno frecuente, medible, con información disponible, riesgo acotado y suficiente fricción manual. Por ejemplo, análisis de excepciones con navegación y acción controlada antes que un proceso financiero crítico totalmente autónomo.
Profundiza sin mezclar intenciones
La visión completa de cómo ERP, datos, Copilot, Power Platform, Azure y agentes forman una arquitectura empresarial.
Cómo Microsoft está llevando intención, análisis y ejecución a una misma experiencia sobre Finance & Operations.
Diseño de agentes propios con herramientas, procesos, permisos y acciones.
Apps, flujos, Dataverse y automatización alrededor del núcleo transaccional.
Finanzas empresariales conectadas con operaciones, automatización, datos e IA.
Designaciones, especializaciones y capacidad para conectar Business Applications, Cloud, datos, IA, seguridad y productividad.
¿Quieres saber si Dynamics 365 ERP MCP tiene sentido en vuestro escenario?
Podemos revisar versión, arquitectura, clientes de agente, permisos, herramientas candidatas y uno o dos procesos donde MCP pueda reducir integración específica sin sacar el control fuera del ERP.
Cuéntanos qué quieres conectar o automatizar
Podemos revisar el proceso, la arquitectura actual, los datos, permisos, integraciones y el nivel de autonomía que tiene sentido asumir.
Microsoft Learn · Use Model Context Protocol for finance and operations apps
Microsoft Learn · New and planned features for finance and operations cross-app capabilities
Microsoft Learn · Enable agents to work with attachments through Dynamics 365 ERP MCP server
Microsoft Learn · Extend your agent with Model Context Protocol
Qué debería revisar un arquitecto antes de exponer una acción del ERP a un agente
Una herramienta MCP no debería publicarse simplemente porque técnicamente puede publicarse. Cada herramienta se convierte en una capacidad que el orquestador puede descubrir y utilizar, por lo que su diseño necesita el mismo rigor que una API empresarial y, en algunos aspectos, más. El nombre debe expresar con claridad qué hace; la descripción debe ayudar al modelo a distinguirla de herramientas parecidas; los parámetros deben estar acotados; las respuestas deben ser comprensibles; y los errores deben devolver suficiente contexto para que el agente sepa si puede recuperarse o debe escalar a una persona.
En procesos financieros y operativos conviene clasificar herramientas por criticidad. Una herramienta que localiza un registro o devuelve el estado de una orden tiene un perfil distinto a una que confirma, contabiliza, libera, cancela o modifica una transacción. El catálogo debería reflejar esa diferencia y el modelo de aprobación también. No todas las herramientas necesitan la misma fricción, pero las acciones con impacto económico o contractual no deberían tratarse como si fueran una simple consulta.
La descripción funcional es tan importante como la implementación técnica. Un desarrollador puede crear una acción perfectamente segura y aun así exponerla de una forma que el modelo interprete mal. Por eso diseño de herramientas, naming y ejemplos de uso deberían revisarse con responsables funcionales. El agente necesita saber no solo qué puede llamar, sino en qué contexto esa herramienta es la correcta y qué precondiciones deben cumplirse.
Además, hay que decidir qué información devuelve cada herramienta. Respuestas excesivamente técnicas pueden dificultar el razonamiento; respuestas demasiado resumidas pueden ocultar datos necesarios para decidir. La salida ideal combina identificadores, estado, contexto relevante y mensajes de negocio que permitan construir el siguiente paso sin obligar al agente a adivinar qué ha ocurrido.
Cuatro niveles de autonomía para no pasar de consulta a ejecución de golpe
Consulta y explicación
El agente lee información, localiza registros, resume contexto y ayuda a navegar. No modifica datos. Es el nivel adecuado para validar seguridad, utilidad y calidad de herramientas con riesgo limitado.
Preparación de acción
El agente reúne contexto, propone una operación, calcula parámetros y deja la acción preparada para que el usuario la revise. Reduce trabajo sin ceder responsabilidad sobre la transacción.
Ejecución con aprobación
El agente utiliza una herramienta de escritura después de una confirmación humana explícita. Es útil cuando la operación es frecuente y el usuario necesita validar antes de comprometer el cambio.
Ejecución autónoma acotada
Solo para procesos muy bien definidos, reversibles o de bajo riesgo, con límites, monitorización, reglas de escalado y evidencia de que la automatización mejora el proceso de forma sostenida.
Observabilidad: la pieza que determina si un agente puede pasar de piloto a operación
Cuando una organización lleva un agente conectado al ERP a producción necesita responder preguntas que una demo no plantea: ¿qué herramientas utiliza con mayor frecuencia?, ¿qué llamadas fallan?, ¿en qué situaciones el agente elige una herramienta incorrecta?, ¿cuántas operaciones son rechazadas por los usuarios?, ¿qué permisos provocan más incidencias?, ¿qué cambio de versión alteró una respuesta o un formulario? Sin observabilidad, los problemas aparecen como “la IA a veces falla”, una categoría demasiado vaga para operar un proceso empresarial.
Conviene registrar el recorrido desde la intención hasta la acción: usuario o identidad, herramienta seleccionada, parámetros relevantes, resultado, errores, confirmación humana y transacción final. No todo debe conservarse indefinidamente ni con el mismo nivel de detalle; privacidad y cumplimiento importan. Pero debe existir suficiente trazabilidad para investigar un incidente y medir si el patrón aporta valor.
La observabilidad también ayuda a mejorar el catálogo. Si una herramienta nunca se utiliza quizá sobra o está mal descrita. Si dos herramientas compiten constantemente puede haber ambigüedad. Si una acción genera muchas correcciones posteriores, el problema puede estar en el proceso, los parámetros o el nivel de autonomía. Un buen programa de agentes utiliza la telemetría para evolucionar arquitectura y no únicamente para contabilizar uso.
Finalmente, hay que incorporar cambios de producto. Microsoft está mejorando rutas de ejecución, adjuntos, enlaces profundos y otras capacidades del servidor ERP MCP durante 2026. Cada nueva funcionalidad puede cambiar qué patrón es más eficiente. La operación debe incluir revisión periódica de release plans y documentación para adoptar mejoras sin romper herramientas existentes.
Dónde no utilizaría MCP como primera opción
No utilizaría un agente con MCP para una sincronización masiva nocturna de maestros, una integración de alta frecuencia con un sistema de almacén o una interfaz que exige tiempos de respuesta deterministas y contratos de datos estrictos. Esos escenarios siguen perteneciendo a patrones de integración diseñados para volumen, resiliencia y consistencia. El hecho de que un agente pueda llamar una herramienta no convierte esa llamada en el mejor canal para intercambiar miles de registros.
Tampoco utilizaría MCP para esconder una mala arquitectura de personalizaciones. Si el ERP tiene lógica dispersa, reglas duplicadas y procesos que solo entiende una persona, exponer más herramientas puede multiplicar el problema. Antes conviene ordenar extensiones, permisos, ownership y semántica. Un agente funciona mejor cuando el sistema que utiliza tiene fronteras claras.
Y evitaría empezar por acciones irreversibles o de alta criticidad. Contabilizaciones sensibles, pagos, modificaciones contractuales, cierres definitivos o cambios regulatorios necesitan controles proporcionales. La tecnología puede participar, pero el primer piloto debería demostrar gobierno en un proceso donde exista margen para corregir y aprender sin comprometer operación.
La mejor prueba de madurez no es cuántas acciones puede ejecutar un agente. Es cuántas acciones la organización ha decidido conscientemente que debe ejecutar, bajo qué identidad, con qué límites, con qué evidencia y con qué procedimiento de rollback.
¿Conectamos?
La tecnología bien aplicada suele facilitar las cosas. Si sospechas que también puede ser de ayuda para ti, concédenos la oportunidad de conocerte y demostrarte hasta qué punto es así.
Suscríbete a nuestra enews mensual, y no te pierdas los mejores contenidos sobre Microsoft Dymanics 365
Información respecto al tratamiento de los datos solicitados, de acuerdo con el RGPD 2016/679 y la LOPDGDD 3/2018: el responsable es Ibermática SA; la finalidad es la recogida y tratamiento de los datos personales que solicitamos para atender tu consulta, enviarte nuestras publicaciones, newsletters, promociones de productos y/o servicios, y recursos exclusivos; la legitimación se establece mediante el consentimiento expreso; no se cederán datos a terceros, salvo obligación legal; en cualquier momento puedes ejercer tus derechos de acceso, rectificación, supresión, portabilidad, limitación u oposición al tratamiento de tus datos, así como retirar el consentimiento prestado o formular reclamaciones ante la Autoridad de Control, enviando la solicitud por correo electrónico a: arco@ibermatica.com; puedes consultar la información adicional y detallada sobre Privacidad y Protección de Datos de Carácter Personal en la Política de Privacidad de Ibermática S.A.
¿Por qué Ayesa?
Somos uno de los principales implantadores de Microsoft, con casi 2000 clientes que han depositado su confianza en nosotros para la implantación de Dynamics 365, Business Central (NAV / Navision) y Dynamics 365 Finance & Operations (AX / Axapta). Además, destacamos en el despliegue de proyectos sobre AZURE y Microsoft 365. Nuestra experiencia en el campo de la inteligencia artificial y el uso de Copilot nos sitúa a la vanguardia de la innovación tecnológica.
Con una plantilla de más de 12.000 profesionales y una sólida presencia en 23 países, estamos comprometidos en ayudar a nuestros clientes a definir y aprovechar oportunidades en el nuevo contexto digital. Desde la tecnología hasta las personas, ofrecemos un enfoque integral que garantiza el éxito en cada proyecto.
- ÚLTIMAS ENTRADAS DEL BLOG -
-
Un único partner Microsoft o varios especialistas: cómo decidir sin fragmentar la arquitectura
-
Power Automate o agente de IA: qué usar en cada proceso y cuándo combinarlos
-
Copilot Cowork y Dynamics 365 ERP: cuando la IA pasa de consultar a ejecutar procesos
-
Gobernanza de agentes Microsoft 365 Copilot: guía 2026
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)