Security Governance en Dynamics 365 F&O: de los permisos al control real
Roles, segregación de funciones, accesos temporales, auditoría y licencias ya no deberían revisarse como problemas separados.
Microsoft ha ampliado la gobernanza de seguridad de usuario en las aplicaciones de finanzas y operaciones para alinear la arquitectura de acceso con los procesos de negocio. La oportunidad es importante: pasar de conceder roles porque “este usuario necesita entrar aquí” a diseñar quién debe hacer qué, durante cuánto tiempo, con qué conflictos y con qué impacto de licencia.
El problema habitual
En muchos entornos F&O la seguridad crece usuario a usuario. Y ahí empieza el problema.
Una organización implanta Dynamics 365 Finance & Operations con un conjunto razonable de roles. Después llegan nuevas sociedades, cambios de puesto, sustituciones, proyectos, cierres, nuevas funcionalidades y usuarios que “solo necesitan poder hacer una cosa más”. La solución rápida suele ser añadir otro rol. Y luego otro. Al cabo de unos años, el acceso de una persona puede ser la suma de decisiones tomadas en momentos distintos, por administradores distintos y con necesidades que ya ni siquiera existen.
El riesgo no está únicamente en que alguien vea una pantalla que no debería. Puede aparecer una combinación de tareas que rompe una regla de segregación, un privilegio más amplio de lo necesario, un acceso temporal que termina siendo permanente o una asignación que eleva el requisito de licencia de un usuario sin aportar valor operativo.
Security Governance cambia la conversación porque permite abordar estos problemas desde la lógica del proceso. Microsoft plantea una jerarquía en la que las responsabilidades de negocio se traducen en tareas, roles, deberes, privilegios y puntos de entrada. La pregunta deja de ser “¿qué menú necesita?” y pasa a ser “¿qué trabajo realiza esta posición y qué acceso mínimo necesita para hacerlo?”.
Roles acumulados
Usuarios con permisos heredados de puestos anteriores, proyectos finalizados o responsabilidades que ya no desempeñan.
Excepciones permanentes
Accesos concedidos para una incidencia, un cierre o una ausencia que no se retiran cuando termina la necesidad.
Conflictos invisibles
Dos roles individualmente razonables pueden dar a una misma persona una combinación incompatible de tareas.
Licencias sobredimensionadas
Un permiso o punto de entrada que no se usa puede terminar afectando al requisito de licencia asociado al usuario.
La base de F&O
Rol, deber, privilegio, permiso: cuatro niveles que conviene no mezclar
El modelo de seguridad de Finance & Operations es jerárquico. Microsoft recomienda conceder acceso a través de roles alineados con las responsabilidades del negocio y utilizar deberes para representar partes de un proceso. Los privilegios representan tareas concretas y los permisos son el nivel que finalmente da acceso a objetos securizables. Entender esta jerarquía evita diseñar seguridad a base de excepciones.
Agrupa el acceso que necesita una posición o función: contable, responsable de compras, tesorería, controller, responsable de almacén.
Representa un conjunto coherente de tareas dentro de un proceso de negocio, por ejemplo mantener transacciones bancarias.
Permite ejecutar acciones específicas, como cancelar pagos, mantener proveedores o procesar determinadas operaciones.
Es el acceso granular a los elementos securizables que hacen posible la tarea: menús, tablas y otros componentes.
Regla práctica: no empieces por el objeto técnico. Empieza por el proceso y la responsabilidad. Cuanto más cerca del negocio se diseña la seguridad, más fácil resulta explicar por qué existe cada acceso y detectar cuándo sobra.
El salto de 2026
Security Governance permite diseñar la seguridad desde los procesos, no solo revisar roles existentes
La documentación actual de Microsoft describe User Security Governance como una capacidad para crear una arquitectura de seguridad estrechamente alineada con los procesos empresariales. Entre sus funciones aparecen el diseño de roles basados en procesos y posiciones, la creación de tareas desde objetos existentes, la gestión de roles temporales, el acceso privilegiado con límite de tiempo, la monitorización de segregación de funciones, el control de versiones y la pista de auditoría.
Esto es relevante porque las organizaciones suelen tener dos problemas distintos. Uno es el diseño inicial: qué rol debería existir. El otro es el gobierno continuo: qué ocurre meses después cuando cambian puestos, procesos, personas, licencias y necesidades. Security Governance intenta cubrir ambos.
Jerarquía de procesos
Permite organizar procesos y asociar tareas, roles, puntos de entrada y privilegios a las responsabilidades del negocio.
Roles temporales
Facilita que determinados accesos tengan una duración limitada en lugar de convertirse en una excepción permanente.
Usuarios privilegiados
Microsoft contempla cuentas dedicadas que pueden recibir privilegios elevados durante un tiempo acotado.
Versionado y auditoría
Los cambios en seguridad pueden compararse, restaurarse y quedar registrados para aportar trazabilidad.
Control SoD continuo
Las reglas de segregación pueden utilizarse para detectar roles o deberes que generan incompatibilidades.
Indicadores de licencia
Los informes relacionan rol, deber, privilegio y punto de entrada con los requisitos de licencia del usuario.
Caso práctico 1
Proveedor, recepción y pago: el ejemplo clásico sigue siendo el mejor para entender SoD
Microsoft utiliza ejemplos muy claros para explicar la separación de funciones. Una persona que mantiene información de proveedores no debería, por defecto, concentrar también la capacidad de confirmar recepciones y procesar pagos. No porque cualquier empleado sea sospechoso, sino porque el control interno se diseña precisamente para que un error o una acción indebida no pueda completar todo el ciclo sin intervención de otra responsabilidad.
La segregación de funciones en F&O permite definir qué deberes resultan incompatibles y comprobar si un rol o una asignación de roles rompe esa regla. Security Governance amplía este enfoque con una vista más orientada a procesos y con capacidad para monitorizar solapamientos. Esto facilita detectar no solo el conflicto “de manual”, sino también combinaciones que aparecen después de meses de cambios.
Crear o modificar proveedor
Especialmente sensible cuando se modifican datos bancarios o información de pago.
Registrar recepción
Acredita que el bien o servicio ha sido recibido y habilita pasos posteriores del proceso.
Registrar factura
Incorpora la obligación de pago y debe responder a la política de compras y validación.
Proponer o ejecutar pago
Es el punto donde una mala combinación de accesos puede convertir una debilidad de control en una pérdida real.
El objetivo no es que cuatro personas tengan que tocar cada factura. El objetivo es identificar qué combinaciones son críticas, qué controles compensatorios existen y dónde tiene sentido exigir separación real. Una política SoD demasiado genérica termina siendo ignorada; una política ligada a procesos concretos se puede defender y auditar.
Caso práctico 2
El cierre de mes no justifica regalar permisos permanentes
Durante un cierre financiero aparecen situaciones excepcionales: una persona cubre a otra, un responsable necesita revisar una tarea adicional, el equipo de soporte debe investigar una incidencia o un usuario necesita acceso ampliado durante unos días. En muchos entornos, estas necesidades se resuelven añadiendo un rol y confiando en que alguien lo retire más adelante.
La gestión de roles temporales cambia esa mecánica. Si el acceso tiene una razón temporal, el diseño debería reflejarlo. El beneficio no es únicamente de seguridad. También reduce la acumulación de permisos históricos y facilita explicar ante auditoría por qué una persona tuvo una capacidad concreta durante un periodo determinado.
Sustitución
Acceso ampliado mientras una persona responsable está ausente, con fecha de inicio y fin coherente con la necesidad.
Cierre
Funciones adicionales para completar tareas extraordinarias de fin de periodo sin mantenerlas durante el resto del mes.
Soporte
Acceso privilegiado limitado para resolver una incidencia concreta en lugar de conceder privilegios elevados de forma indefinida.
Caso práctico 3
Cuando seguridad y licenciamiento se cruzan, revisar roles puede tener retorno económico
La seguridad de F&O y el licenciamiento no son dos mundos completamente independientes. Microsoft define requisitos de licencia a nivel de puntos de entrada y la nueva gobernanza de seguridad utiliza esos mismos puntos de entrada para explicar qué acceso necesita cada usuario según sus roles asignados. El resumen de uso de licencias permite bajar desde el usuario a roles, deberes, privilegios y objetos securizables.
Esto no significa que una revisión de seguridad garantice ahorro. Puede ocurrir que el usuario realmente necesite todas las funciones que tiene asignadas. Pero sí permite detectar un problema muy habitual: una persona recibe un rol amplio para resolver una tarea concreta y ese rol arrastra puntos de entrada que elevan el requisito de licencia. Si el trabajo real puede cubrirse con una definición más precisa, seguridad y coste mejoran al mismo tiempo.
La documentación de Microsoft también indica que User Governance ofrece información sobre uso de puntos de entrada por rol mapeado al usuario. Esa señal es valiosa para distinguir entre “tiene acceso” y “lo utiliza realmente”, siempre con cuidado: que algo no se use durante unas semanas no significa automáticamente que deba retirarse. Hay tareas trimestrales, anuales o de contingencia que justifican acceso aunque su frecuencia sea baja.
| Señal | Qué puede estar ocurriendo | Qué revisar |
|---|---|---|
| Rol muy amplio | Se concedió por comodidad para resolver pocas tareas. | Deberes y privilegios realmente necesarios. |
| Punto de entrada no usado | El rol contiene capacidades que quizá no forman parte del puesto. | Frecuencia real, procesos periódicos y riesgo de retirar acceso. |
| Varios roles superpuestos | La persona ha acumulado funciones similares con el tiempo. | Simplificación del modelo y redundancias. |
| Licencia superior a la esperada | Un permiso concreto puede estar condicionando el requisito. | Ruta usuario → rol → privilegio → punto de entrada. |
Diseñar bien desde el principio
Cómo construir un modelo de seguridad que siga teniendo sentido dentro de tres años
El objetivo no es producir el menor número posible de roles ni crear un rol distinto para cada persona. Ambos extremos generan problemas. Un modelo sostenible debe representar responsabilidades suficientemente estables, permitir excepciones controladas y ser comprensible para IT, Finanzas, auditoría y responsables de proceso.
Partir de puestos y procesos
Qué hace contabilidad, tesorería, compras, almacén o controlling. No empezar por la lista de menús de F&O.
Identificar incompatibilidades
Definir qué tareas no deben concentrarse en una sola persona y por qué el negocio considera crítico ese conflicto.
Usar estándar como punto de partida
Microsoft recomienda utilizar los roles estándar como referencia y copiar/modificar cuando se necesitan requisitos avanzados, en lugar de empezar siempre desde cero.
Separar permanente de temporal
Un acceso para cubrir una ausencia no debería incorporarse al perfil permanente de la posición.
Revisar licencia durante el diseño
Si dos diseños cubren el mismo trabajo, conviene conocer también su impacto de licenciamiento antes de aprobar el modelo.
Establecer una revisión periódica
Cambian las personas, cambian los procesos y cambia el producto. La seguridad no puede quedar congelada el día del go-live.
Errores que vemos repetirse
Siete formas de convertir la seguridad de F&O en una deuda silenciosa
Asignar roles por similitud de usuario
“Dale lo mismo que a Marta” es rápido, pero copia también permisos históricos, excepciones y necesidades que quizá no tienen nada que ver con el nuevo puesto.
Modificar estándar sin una política clara
Después de actualizaciones resulta más difícil distinguir qué pertenece al producto y qué se modificó internamente. Microsoft sugiere trabajar con copias cuando existen necesidades avanzadas.
Tratar SoD como un informe anual
Una foto anual sirve de poco si durante los doce meses siguientes se incorporan roles y usuarios sin validar nuevas combinaciones.
No retirar accesos temporales
Una excepción de dos días termina formando parte del perfil normal y vuelve difícil explicar por qué existe seis meses después.
Optimizar licencias sin hablar con negocio
Quitar un rol porque no se utilizó recientemente puede bloquear una tarea trimestral o una responsabilidad de contingencia. Los datos de uso necesitan contexto funcional.
Resolver todo con desarrollos
No todos los problemas de seguridad requieren personalización. Antes conviene revisar roles, puntos de entrada, políticas de datos y capacidades estándar de gobierno.
Confundir seguridad con administración técnica
IT puede operar la herramienta, pero el negocio debe decidir qué responsabilidades son compatibles, qué excepciones acepta y qué control considera suficiente.
Auditoría que sirve para operar mejor
Una buena pista de auditoría no debería existir solo para enseñársela al auditor
La capacidad de registrar cambios en la gobernanza de seguridad tiene valor regulatorio, pero también operativo. Permite reconstruir por qué se modificó un rol, cuándo se introdujo un privilegio o qué versión estaba activa antes de un cambio. Cuando aparece una incidencia, esa trazabilidad acorta la investigación y evita depender de memoria, correos y capturas antiguas.
El versionado añade otra capa: comparar versiones y restaurar una anterior reduce el riesgo de que un cambio de seguridad se convierta en una operación irreversible. En entornos con muchos usuarios y responsabilidades sensibles, esto convierte el modelo de acceso en algo gestionable, no en un conjunto de configuraciones dispersas.
Qué cambió
Roles, tareas, privilegios y configuración de gobierno deben poder analizarse sin depender de conocimiento informal.
Quién lo aprobó
Las decisiones de acceso críticas necesitan responsables claros, especialmente cuando afectan a controles financieros.
Cómo volver atrás
Poder comparar y restaurar versiones reduce el riesgo de cambios que afectan a muchos usuarios o procesos.
Security Governance + Power Platform
Automatizar alrededor de Finance no puede saltarse el modelo de control del ERP
Muchas organizaciones extienden Dynamics 365 Finance con Power Apps, Power Automate, Power BI o agentes para agilizar aprobaciones, capturar información, generar alertas y reducir tareas manuales. La idea es correcta siempre que la automatización respete las mismas responsabilidades que se han definido en el core financiero.
Un flujo que permite aprobar un pago desde fuera del ERP sin conservar límites, identidad, evidencias y segregación no mejora el control: lo desplaza. Lo mismo ocurre con apps que replican información sensible sin una política clara o con automatizaciones que operan mediante cuentas técnicas excesivamente privilegiadas.
Por eso la arquitectura debe mirar seguridad de extremo a extremo. F&O define procesos y control financiero; Power Platform puede acelerar lo que ocurre alrededor; Microsoft Entra aporta identidad; y la gobernanza debe asegurar que la experiencia más cómoda no cree una ruta alternativa menos controlada.
Aprobaciones
Responsables, importes, límites, evidencias y excepciones deben conservarse aunque la experiencia se automatice.
Apps internas
Capturar datos de forma ágil no significa abrir acceso directo a información financiera que el usuario no necesita.
Agentes y automatismos
La cuenta o identidad que ejecuta acciones debe formar parte del diseño de seguridad, no ser un atajo para “que funcione”.
Plan de revisión
Cómo revisar seguridad y licencias de F&O sin convertirlo en un proyecto infinito
No hace falta rediseñar todos los roles de una gran organización de una vez. Es más eficaz empezar por procesos sensibles y poblaciones donde el riesgo o el coste potencial justifican el esfuerzo. Compras, pagos, tesorería, alta de proveedores, administración, cierres y usuarios con muchos roles suelen ser buenos candidatos.
Elegir procesos críticos
Pagos, proveedores, tesorería, compras, cierres, inventario, maestros sensibles o cualquier proceso señalado por auditoría.
Mapear responsabilidades
Identificar qué posiciones realizan cada tarea y dónde existen sustituciones, acumulaciones o responsabilidades poco claras.
Cruzar con roles reales
Comparar la organización teórica con lo que existe en F&O: roles asignados, solapamientos, excepciones y accesos temporales.
Validar SoD
Revisar conflictos existentes y decidir qué se corrige, qué se compensa con otro control y qué excepción se acepta formalmente.
Analizar licenciamiento
Identificar qué permisos condicionan licencias y si la asignación responde realmente a la función que realiza el usuario.
Crear gobierno recurrente
Definir cómo se solicitan accesos, quién aprueba, cuándo expiran, qué se revisa tras cambios de puesto y qué informes se revisan periódicamente.
Prioridad recomendada: si el entorno tiene cientos o miles de usuarios, no empieces por los casos sencillos. Empieza por usuarios con muchos roles, procesos financieros sensibles y grupos donde el coste de licencia sea material. Ahí es donde una revisión bien hecha puede devolver antes valor y reducir riesgo.
El momento más delicado
Cuando una persona cambia de puesto, su seguridad debería cambiar con ella
Una de las fuentes más frecuentes de exceso de permisos no está en la implantación inicial, sino en la movilidad interna. Un usuario empieza en administración, pasa a compras, asume temporalmente tareas de tesorería y dos años después entra en controlling. Si cada cambio se resuelve añadiendo acceso sin revisar el anterior, el resultado puede ser un perfil que ya no representa ningún puesto real de la organización.
El problema aumenta en grupos con rotación interna, centros de servicios compartidos, múltiples sociedades o equipos que cubren vacaciones y cierres. La organización conoce el puesto actual de la persona, pero F&O conserva la historia de todas las funciones que fue necesitando. Esa diferencia entre estructura organizativa y estructura de permisos es precisamente la que una gobernanza basada en posiciones y procesos intenta reducir.
La revisión correcta no consiste únicamente en preguntar qué roles nuevos necesita. Hay que decidir qué accesos dejan de corresponder, qué excepciones deben caducar y si la nueva combinación crea conflictos SoD. También conviene comprobar si el cambio altera el requisito de licencia. Así, una modificación organizativa deja de ser una suma de permisos y pasa a convertirse en una actualización completa del perfil de acceso.
Alta
Asignar el acceso según una posición definida y evitar copiar el perfil completo de otro usuario solo porque desempeña un trabajo parecido.
Cambio de puesto
Retirar lo que deja de aplicar, incorporar la nueva responsabilidad y validar la combinación resultante antes de darla por correcta.
Ausencia temporal
Usar acceso con caducidad cuando una persona cubre durante días o semanas responsabilidades que no forman parte de su puesto normal.
Baja
La revocación debe formar parte del proceso de salida y coordinarse con identidad, acceso al entorno y cualquier cuenta privilegiada asociada.
Gobierno continuo
Qué indicadores revisaría cada trimestre en un entorno F&O maduro
Gobernar seguridad no significa revisar manualmente cada permiso cada tres meses. Significa tener un pequeño conjunto de señales que indique dónde mirar. Si el modelo está razonablemente bien diseñado, la revisión puede orientarse a excepciones y cambios: usuarios con acumulación anormal de roles, conflictos SoD nuevos, accesos temporales que deberían haber vencido, roles modificados, puntos de entrada que condicionan licencias y cuentas privilegiadas.
La frecuencia también debe responder al riesgo. Un grupo con operaciones internacionales, tesorería centralizada y cientos de usuarios probablemente necesitará más disciplina que una organización pequeña con pocas funciones sensibles. Pero incluso en el entorno más estable conviene evitar que la única revisión llegue cuando auditoría pregunta por un acceso que nadie recuerda haber concedido.
| Indicador | Qué puede revelar | Acción útil |
|---|---|---|
| Usuarios con muchos roles | Acumulación histórica, duplicidad o responsabilidades mal modeladas. | Revisar puesto, redundancias y necesidad real. |
| Nuevos conflictos SoD | Cambios recientes han creado una combinación incompatible. | Corregir, compensar o aprobar excepción documentada. |
| Roles temporales vencidos | Acceso extraordinario que ya no tiene una razón operativa. | Retirar y revisar el proceso que lo originó. |
| Cambios de versión de seguridad | El modelo se ha modificado desde la última revisión. | Comparar versiones y validar impacto. |
| Licencias inesperadas | Uno o varios puntos de entrada elevan el requisito del usuario. | Trazar la causa y validar necesidad funcional. |
| Accesos privilegiados | Funciones elevadas que merecen mayor trazabilidad y menor permanencia. | Revisar propietario, duración, uso y necesidad. |
La mejor señal de madurez no es tener cero excepciones. Es saber cuáles existen, por qué existen, quién las aprobó, cuándo se revisan y qué control evita que se conviertan en acceso permanente sin justificación.
Preguntas frecuentes
Dudas habituales sobre Security Governance en Dynamics 365 F&O
¿Security Governance sustituye al modelo de seguridad basado en roles?
No. Se apoya en el mismo modelo de roles, deberes, privilegios, permisos y puntos de entrada. Lo que añade es una forma más estructurada de diseñar, gobernar, auditar y analizar esa seguridad.
¿Puede detectar conflictos de segregación de funciones?
Sí. Microsoft documenta la monitorización de reglas SoD y vistas específicas para identificar roles que infringen reglas de segregación. Después el administrador debe analizar y resolver el conflicto.
¿Crear una regla SoD corrige automáticamente los conflictos existentes?
No. Microsoft advierte que una regla nueva puede entrar en conflicto con roles o asignaciones ya existentes. Hay que validar el cumplimiento y resolver los conflictos después de crear o modificar reglas.
¿Puede ayudar a optimizar licencias?
Sí, como herramienta de análisis. El resumen de uso relaciona usuarios, roles y permisos con requisitos de licencia. La decisión de retirar o rediseñar acceso debe validarse funcionalmente antes de cambiarlo.
¿Security Governance permite saber qué funciones usa un usuario?
Microsoft indica que User Governance ofrece información sobre uso de puntos de entrada por rol mapeado al usuario. Es útil para revisar acceso, pero debe interpretarse teniendo en cuenta tareas poco frecuentes.
¿Es mejor crear todos los roles desde cero?
No necesariamente. Microsoft recomienda aprovechar los roles estándar como base y copiarlos o modificarlos cuando existen requisitos específicos. Crear todo desde cero aumenta mantenimiento y complejidad si no hay una razón clara.
¿Quién debe ser propietario del modelo de seguridad?
IT puede administrar la configuración, pero las responsabilidades y conflictos deben acordarse con negocio, Finanzas, control interno y, cuando corresponda, auditoría. La seguridad del ERP es un modelo operativo, no solo técnico.
¿Tiene sentido revisar seguridad si F&O ya lleva años implantado?
Precisamente ahí suele existir más valor. El tiempo acumula cambios de puesto, nuevos roles, excepciones, adquisiciones y procesos. Una revisión permite comparar el modelo actual con la organización que existe hoy.
Para seguir profundizando
Seguridad, ERP y automatización: piezas que conviene leer juntas
Segregación de funciones en F&O
Cómo identificar incompatibilidades entre tareas críticas y reducir riesgo en procesos financieros y operativos.
Dynamics 365 Finance & Operations
La visión completa del ERP enterprise para finanzas, operaciones, supply chain, gobierno y crecimiento.
Dynamics 365 Finance
Control financiero, tesorería, cumplimiento, cierres, analítica y automatización sobre una base gobernada.
Power Platform + Finance
Aprobaciones, apps, reporting y automatización alrededor del ERP sin perder control financiero.
También conviene poner límites
Security Governance no sustituye al gobierno completo de identidad, datos y procesos
La gobernanza de seguridad de F&O resuelve una parte muy importante del problema: quién puede hacer qué dentro de las aplicaciones de finanzas y operaciones y cómo se diseñan, revisan y auditan esos accesos. Pero no debería presentarse como una capa mágica que cubre toda la seguridad empresarial.
La identidad sigue dependiendo de Microsoft Entra y de las políticas corporativas de acceso. La protección de datos puede requerir políticas de seguridad extensible, controles adicionales y decisiones sobre qué información puede ver cada organización o función. Los desarrollos, integraciones, cuentas de servicio, Power Platform y sistemas externos también forman parte de la superficie de control.
Y hay una limitación práctica especialmente importante: una herramienta puede detectar una combinación de permisos, pero no puede decidir por la empresa si esa combinación es aceptable. Esa decisión exige conocimiento del proceso, del riesgo y de los controles compensatorios. Seguridad técnica y control interno tienen que hablar el mismo idioma.
Identidad
Quién es el usuario, cómo se autentica y qué políticas corporativas condicionan su acceso.
Autorización
Qué puede hacer dentro de F&O mediante roles, deberes, privilegios, permisos y políticas de datos.
Control de proceso
Qué combinaciones acepta el negocio, qué tareas separa y qué excepciones requieren controles compensatorios.
Referencias Microsoft
Documentación oficial sobre seguridad y gobernanza de F&O
Microsoft Learn · Configurar una jerarquía de procesos, roles y privilegios
Microsoft Learn · Role-based security en Finance & Operations
Microsoft Learn · Configuración de segregación de controles
Microsoft Learn · Resumen de uso de licencias de Security Governance
Microsoft Learn · Preguntas frecuentes sobre Security Governance
Revisión de seguridad Dynamics 365 F&O
¿Tus usuarios tienen los permisos que necesitan o los que han ido acumulando?
Podemos revisar roles, segregación de funciones, accesos temporales, puntos de entrada y su impacto de licenciamiento para identificar riesgo, complejidad y oportunidades de optimización sin bloquear la operación.
¿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 -
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)