El ERP no crea el conflicto. Lo hace visible.
En muchas empresas medianas, una persona acumula facultades porque “siempre se ha hecho así”. Puede dar de alta proveedores, registrar facturas, corregir dimensiones, lanzar propuestas de pago o contabilizar ajustes. No tiene por qué existir fraude para que haya un problema. Basta un error, una sustitución improvisada, una credencial comprometida o una cuenta bancaria modificada sin revisión.
La segregación de funciones, conocida también como SoD por sus siglas en inglés, busca que las fases incompatibles de un proceso no queden bajo el control exclusivo de una sola persona. Su propósito no consiste en multiplicar burocracia: consiste en impedir que alguien pueda iniciar, ocultar y completar una operación relevante sin intervención, revisión o evidencia independiente.
Microsoft Dynamics 365 Business Central proporciona capacidades para estructurar accesos, configurar conjuntos de permisos, utilizar grupos de seguridad, consultar permisos efectivos, establecer flujos de aprobación y registrar cambios. Sin embargo, ninguna plataforma conoce por sí sola qué conflictos son críticos para tu organización. Esa decisión pertenece al modelo de control de la empresa.
Autorizar
Quién decide que la operación puede producirse y dentro de qué límite.
Ejecutar
Quién crea, modifica o procesa la transacción en Business Central.
Custodiar
Quién controla el activo, el acceso, la cuenta o el dato maestro implicado.
Revisar
Quién comprueba la operación y puede reconstruir lo sucedido después.
Ocho señales de que los permisos ya no reflejan el negocio
Si varias de estas situaciones resultan familiares, el problema no se resuelve creando otro perfil llamado “administración”. Hace falta revisar el proceso, identificar incompatibilidades y reconstruir el acceso desde la función real.
Un usuario controla proveedor, factura y pago
Es la combinación clásica. La actividad puede ser legítima y frecuente, pero permite completar todo el ciclo sin una segunda mirada.
Los accesos proceden de la antigua NAV
Migrar datos no obliga a migrar privilegios. Copiar permisos históricos traslada excepciones y atajos a una plataforma nueva.
Todo el equipo tiene permisos demasiado amplios
Cuando nadie sabe qué objeto necesita cada tarea, se concede más acceso “para no bloquear”. El atajo se vuelve permanente.
Las bajas y cambios de puesto llegan tarde
Un cambio organizativo sin revisión de accesos crea acumulación de privilegios: el usuario conserva lo anterior y suma lo nuevo.
La aprobación existe, pero puede esquivarse
Un flujo no compensa un permiso excesivo si el usuario puede contabilizar por otra ruta, modificar el maestro o intervenir como sustituto.
Se utilizan cuentas compartidas
La trazabilidad pierde valor cuando varias personas operan con una misma identidad o comparten credenciales en una urgencia.
Solo se revisan permisos durante la auditoría
Una fotografía anual no detecta bien altas temporales, sustituciones, proyectos ni privilegios acumulados durante meses.
El conocimiento depende de una sola persona
Si solo alguien entiende por qué se concedió cada acceso, la empresa no tiene un modelo de control: tiene memoria oral.
La matriz no empieza en las pantallas: empieza en el proceso
Dos permisos aislados pueden ser correctos y convertirse en un conflicto cuando se combinan. Por eso una revisión útil no se limita a contar usuarios ni a exportar conjuntos de permisos. Debe conectar cada capacidad con una fase del proceso y valorar qué puede conseguir una misma identidad de principio a fin.
| Proceso | Combinación sensible | Riesgo | Control razonable |
|---|---|---|---|
| Proveedores | Crear proveedor + modificar banco + preparar pago | Pago desviado o maestro manipulado | Separación, aprobación y revisión de cambios |
| Compras | Solicitar + aprobar + recepcionar + facturar | Compra sin validación independiente | Límites por importe y funciones separadas |
| Ventas | Crear cliente + cambiar límite + emitir abono | Exposición de crédito o reversión indebida | Aprobación por excepción y seguimiento |
| Tesorería | Proponer pago + exportar fichero + conciliar | Salida de fondos sin contraste | Doble revisión y control bancario externo |
| Contabilidad | Crear diario + contabilizar + revertir | Ajustes no autorizados o difíciles de detectar | Series, límites, evidencia y revisión posterior |
| Administración | Gestionar usuarios + asignar privilegios + operar | Autoconcesión o uso de privilegios elevados | Administración separada y acceso excepcional controlado |
En estructuras pequeñas puede no existir capacidad organizativa para separar cada tarea. En esos casos deben documentarse controles compensatorios: aprobación independiente, límites de importe, revisión periódica, alertas, evidencia bancaria, análisis de excepciones o supervisión reforzada. Fingir una separación que la organización no puede cumplir es peor que reconocer el riesgo y controlarlo.
Cuatro procesos donde una pequeña excepción puede convertirse en un gran agujero
La segregación se entiende mejor cuando se abandona la jerga y se sigue una operación completa. Estos escenarios no presuponen mala fe: muestran cómo una combinación de acceso, presión operativa y falta de revisión puede producir pérdidas, errores o una evidencia imposible de defender.
La cuenta bancaria cambia justo antes de pagar
Una persona recibe por correo una petición de cambio de banco, modifica la ficha del proveedor, registra la factura y prepara la propuesta de pago. Todo puede parecer normal. Sin una validación independiente del cambio, el proceso es vulnerable a fraude del proveedor, suplantación de correo o simple error de transcripción.
Control útil: separar o aprobar la modificación de datos bancarios, conservar evidencia del contraste realizado y revisar cambios producidos cerca de una orden de pago. El control debe alcanzar también a importaciones e integraciones que actualicen el maestro.
Quien solicita también confirma que todo llegó
El comprador crea el pedido, lo ajusta, registra la recepción y facilita la factura. Si además puede aprobarla, no existe una comprobación independiente de cantidad, precio o servicio recibido. El riesgo crece en compras urgentes, subcontratación y servicios difíciles de verificar físicamente.
Control útil: definir límites de aprobación, separar la recepción cuando sea viable y exigir evidencia adicional en servicios o excepciones. Los casos fuera de pedido deberían quedar identificados, no absorbidos silenciosamente por el circuito habitual.
El ajuste se contabiliza y se revierte sin otra mirada
Durante el cierre se acumulan prisas, reclasificaciones y periodificaciones. Si una persona crea, contabiliza y revierte diarios relevantes, puede corregir errores con agilidad, pero también alterar el resultado sin revisión suficiente. La urgencia del cierre suele convertir privilegios temporales en permanentes.
Control útil: establecer límites, series identificables, revisión de diarios sensibles y acceso excepcional con caducidad. No todas las anotaciones exigen doble aprobación; sí necesitan mayor control las que afectan materialmente a resultado, caja, impuestos o cuentas puente.
La operación comercial se impone al control de riesgo
Una persona crea el cliente, eleva el límite de crédito, modifica condiciones y desbloquea el pedido para cumplir un objetivo urgente. Puede ser una decisión comercial justificada, pero si no queda aprobada y documentada, la empresa asume exposición sin saber quién la autorizó.
Control útil: separar la decisión comercial de la autorización de riesgo, utilizar aprobaciones por importe o excepción y registrar la razón. Un buen circuito no impide vender: permite que alguien con responsabilidad suficiente acepte conscientemente el riesgo.
Cómo decidir si separar, aprobar, limitar o revisar
No existe un único control válido para todas las operaciones. La respuesta depende del impacto potencial, la frecuencia, el volumen, la capacidad organizativa y la posibilidad de detectar el problema después. Una matriz eficaz no colecciona cruces rojos: propone un tratamiento coherente para cada riesgo.
Separar funciones
Es la opción preferente cuando una combinación permite crear y completar una operación de alto impacto, especialmente si afecta a caja, cuentas bancarias, datos maestros sensibles o estados financieros. La separación debe ser real: dos nombres distintos no sirven si comparten credenciales, se sustituyen sin control o ambos poseen el acceso completo.
También conviene separar la administración técnica de la actividad operativa. Quien puede concederse privilegios no debería utilizar esa capacidad como parte de su trabajo cotidiano.
Introducir aprobación
Funciona bien cuando la operación puede prepararse por una persona, pero necesita una decisión independiente antes de continuar. Es especialmente útil para importes, descuentos, crédito, compras, pagos o excepciones. El aprobador debe disponer de información suficiente y de responsabilidad real para rechazar.
Una aprobación automática, rutinaria o realizada sin contexto solo añade un clic. El valor nace de qué se revisa, quién lo revisa y qué sucede cuando detecta una anomalía.
Limitar el alcance
A veces no hace falta impedir una tarea, sino restringirla por compañía, centro, proyecto, diario, importe o tipo de operación. Limitar reduce la superficie de riesgo y permite que el usuario trabaje dentro de un perímetro comprensible.
El alcance debe revisarse al cambiar de puesto. La acumulación de responsabilidades históricas es una de las causas más comunes de privilegios excesivos.
Detectar y revisar
Cuando no es viable separar, se necesita una revisión posterior suficientemente rápida y concreta. Puede centrarse en cambios bancarios, diarios manuales, operaciones fuera de horario, usuarios privilegiados, documentos sin pedido o transacciones que superan determinados umbrales.
La revisión debe generar una acción. Un informe que nadie abre no es un control compensatorio; es decoración administrativa.
Cuanto más fácil sea completar la operación, mayor sea el impacto y más difícil resulte detectarla después, más fuerte debe ser el control preventivo. Cuando el impacto es limitado y la detección es rápida, un control posterior puede ser proporcionado. La decisión debe quedar documentada y contar con un responsable de negocio, no recaer exclusivamente en TI.
No basta con decir que hay control: hay que poder demostrarlo
Una auditoría seria no debería terminar con una captura de los permisos asignados. Necesita comprender qué funciones existen, qué riesgos cubren, quién autorizó las excepciones y qué ocurrió realmente durante el periodo revisado. La evidencia debe conectar diseño y operación.
También conviene distinguir entre evidencia preventiva y detectiva. Los permisos y aprobaciones intentan impedir ciertas acciones; el registro de cambios, la revisión de movimientos y la telemetría permiten detectar lo que sucedió. Ambos planos son necesarios porque ningún diseño preventivo cubre todas las situaciones.
Cuando la organización trabaja con varias sociedades, países o extensiones, la evidencia debe indicar también el alcance. Que un usuario tenga una función correcta en una compañía no significa que deba conservarla en todas. Lo mismo sucede con administradores y consultores: el acceso de soporte debe estar justificado, limitado y revisado.
Paquete mínimo de evidencia
Qué puede hacerse en noventa días sin paralizar la empresa
No siempre es razonable rediseñar todo de una vez. Un programa escalonado permite reducir primero la exposición más seria, aprender de la operación y extender el modelo con datos reales.
Localizar exposición crítica
Inventariar usuarios y accesos, identificar privilegios elevados, revisar proveedores y pagos, seleccionar procesos prioritarios y localizar cuentas compartidas o excepciones sin propietario.
El resultado debe ser una lista de riesgos ordenada, no un documento interminable que trate todos los permisos como iguales.
Rediseñar y probar funciones
Definir funciones objetivo, ajustar conjuntos de permisos, configurar aprobaciones prioritarias, documentar compensaciones y probar con usuarios reales en escenarios normales y de cierre.
La prueba debe comprobar que el control funciona y que el equipo puede realizar su trabajo sin solicitar privilegios generales.
Desplegar revisión recurrente
Retirar accesos heredados, cerrar excepciones temporales, activar la evidencia necesaria, asignar responsables y establecer una cadencia de revisión por riesgo. En esta fase se incorporan integraciones, Power Platform y cuentas técnicas para evitar que el perímetro se limite a usuarios humanos.
El resultado deseado no es “cero conflictos” a cualquier precio. Es un conjunto reducido de conflictos conocidos, justificados y controlados, junto con funciones limpias que puedan mantenerse cuando cambie la organización.
Pasar de NAV a Business Central sin revisar permisos moderniza la plataforma, no el control
La migración a Business Central SaaS ofrece una oportunidad poco frecuente: dejar de heredar perfiles construidos durante años a base de urgencias. Copiar el modelo anterior puede parecer más rápido, pero también conserva usuarios sobredimensionados, funciones incompatibles y excepciones cuya razón ya nadie recuerda.
El buen enfoque parte del puesto actual, del proceso futuro y del mínimo acceso necesario. Después se prueban escenarios reales, se documentan excepciones y se prepara un mecanismo de revisión. El objetivo no es impedir trabajar el primer día; es evitar que la presión del arranque convierta el acceso total en la configuración definitiva.
Seis piezas que deben trabajar juntas
La plataforma aporta herramientas potentes, pero ninguna sustituye a las demás. Un conjunto de permisos sin proceso de aprobación deja huecos; un flujo de aprobación sin trazabilidad puede no demostrar suficiente control; un registro de cambios sin responsables solo acumula datos.
Conjuntos de permisos
Agrupan capacidades sobre objetos y datos. Deben componerse por funciones entendibles y evitar perfiles gigantes que mezclen administración, operación y contabilización.
Grupos de seguridad
Facilitan asignar acceso de manera coherente a colectivos y conectarlo con la gestión de identidades. Reducen altas manuales dispersas, pero exigen una gobernanza clara del grupo.
Permisos efectivos
Permiten comprobar qué acceso termina teniendo realmente una persona tras combinar asignaciones. Es la vista que importa para evaluar riesgo, no solo el nombre del perfil concedido.
Flujos de aprobación
Incorporan intervención independiente ante documentos, importes o excepciones. Deben diseñarse con suplencias, escalados, límites y rutas que no puedan eludirse por otra vía.
Registro de cambios
Ayuda a seguir modificaciones relevantes, especialmente en maestros sensibles. Debe activarse con criterio: registrar todo sin priorización genera volumen, no necesariamente control.
Telemetría y revisión
Permiten pasar de una configuración estática a una supervisión viva: detectar usos anómalos, errores de autorización, cambios y patrones que requieren investigación.
Estas capacidades deben configurarse según versión, licencia, extensiones, procesos y requisitos de cada organización. El diseño final requiere validación funcional y técnica; no debe deducirse únicamente de una lista genérica.
Del organigrama a un control que funciona
El error más frecuente es abrir Business Central, mirar qué permisos existen y empezar a repartirlos. El orden correcto es el inverso. Primero se define qué debe poder hacer cada función, qué combinaciones son incompatibles y qué excepciones necesita la realidad. Después se traduce el modelo a la plataforma.
La segregación tampoco se resuelve una vez para siempre. La organización cambia, aparecen extensiones, se automatizan tareas y se incorporan agentes o flujos de Power Platform. Cada nueva capacidad puede alterar el poder efectivo de una identidad. El modelo debe poder evolucionar sin rehacerse desde cero.
Quién solicita, crea, modifica, aprueba, contabiliza, paga, concilia y revisa.
Qué combinación permite completar una operación o esconder un error.
Acceso mínimo suficiente, entendible por negocio y mantenible por TI.
Casos normales, excepciones, sustituciones y cierres bajo presión real.
Documentar duración, responsable, riesgo y control compensatorio.
Altas, bajas, cambios de función, accesos temporales y nuevos desarrollos.
Cinco atajos que fabrican una falsa sensación de seguridad
Confundir perfiles de interfaz con seguridad
Que una opción no aparezca en el menú no garantiza que la operación esté bloqueada. La seguridad debe evaluarse por permisos efectivos, no por apariencia.
Usar SUPER como remedio operativo
Conceder privilegios amplios para resolver incidencias evita el síntoma y multiplica el riesgo. La excepción debe ser temporal, trazable y revocable.
Creer que una aprobación lo arregla todo
El flujo controla una ruta. La revisión debe comprobar si existe otra forma de contabilizar, modificar datos o completar la operación.
Diseñar permisos usuario por usuario
Las asignaciones artesanales son difíciles de explicar, mantener y auditar. Conviene trabajar desde funciones y excepciones controladas.
Documentar una matriz y olvidarla
Una matriz sin proceso de alta, revisión y retirada termina describiendo una organización que ya no existe. El control solo es real cuando acompaña el ciclo de vida del acceso.
Una pyme no necesita el mismo modelo que un grupo internacional
El principio es común, pero el diseño debe ser proporcional a la estructura, el volumen, la regulación y el riesgo. Sobrediseñar bloquea la operación; infradiseñar deja la puerta abierta y obliga a depender de confianza personal.
Empresa mediana con equipo compacto
Puede necesitar que una persona realice varias fases. El control puede apoyarse en límites, aprobaciones del responsable financiero, revisión bancaria, informes de excepción y análisis mensual de cambios sensibles.
La clave: reconocer incompatibilidades inevitables y diseñar controles compensatorios que alguien ejecute de verdad.
Grupo con varias sociedades o países
Necesita mayor separación, funciones comunes, alcance por compañía, gobierno central, tratamiento de administradores, evidencia recurrente y coordinación con identidades, extensiones e integraciones.
La clave: mantener un estándar común sin ignorar diferencias legales, operativas o locales.
APIs, cuentas de servicio, extensiones, Power Automate y agentes pueden ejecutar operaciones sin utilizar la interfaz habitual. Deben entrar en el mismo mapa de identidades, privilegios y evidencias.
Si una automatización puede actuar, también puede concentrar riesgo
La segregación clásica se diseñó pensando en personas. El entorno moderno incorpora procesos automáticos, integraciones bancarias, importaciones, aplicaciones de Power Platform y agentes capaces de consultar o desencadenar acciones. La pregunta deja de ser únicamente “¿qué puede hacer este empleado?” y pasa a ser “¿qué puede conseguir esta identidad, directamente o a través de otros componentes?”.
Una automatización no actúa con mala intención, pero puede ampliar un error a escala, reutilizar una cuenta con privilegios excesivos o ejecutar una acción sin el contexto que tendría una persona. Por eso debe definirse con qué identidad opera, qué alcance tiene, dónde necesita aprobación humana, cómo se registran las acciones y quién puede modificar el flujo.
Esta visión conecta Business Central con Power Platform conectada al ERP y con el modelo de ERP e inteligencia artificial. Automatizar con control exige gobernar el conjunto, no solo el formulario que ve el usuario.
Lo que conviene aclarar antes de tocar un permiso
¿Qué es la segregación de funciones en Business Central?
Es el diseño de accesos y controles para evitar que una sola identidad concentre fases incompatibles de un proceso, como crear un proveedor, modificar sus datos bancarios, registrar la factura y completar el pago sin revisión independiente.
¿Business Central incluye una matriz SoD automática?
Business Central aporta capacidades de permisos, grupos, aprobaciones y registro, pero la definición de conflictos depende de los procesos y riesgos de cada empresa. Puede requerir metodología, informes o soluciones complementarias.
¿Un flujo de aprobación elimina el conflicto?
No necesariamente. Reduce riesgo en una ruta concreta, pero debe comprobarse si el usuario puede completar la operación mediante otros permisos, modificar datos maestros o intervenir también como aprobador o sustituto.
¿Qué ocurre si la empresa no tiene personal suficiente?
Se documenta el conflicto y se aplican controles compensatorios: límites, doble aprobación, revisión de movimientos, control bancario, alertas o supervisión periódica. Lo importante es que el riesgo no quede ignorado.
¿Hay que revisar permisos al migrar desde NAV?
Sí. Es uno de los mejores momentos para hacerlo. Trasladar sin análisis los privilegios históricos puede conservar accesos excesivos, excepciones antiguas y funciones que ya no corresponden con la organización actual.
¿Cada cuánto deben revisarse los accesos?
Además de una revisión periódica basada en riesgo, deben revisarse ante altas, bajas, cambios de puesto, sustituciones, nuevas sociedades, extensiones, integraciones, automatizaciones y modificaciones relevantes del proceso.
¿Registrar todos los cambios garantiza trazabilidad?
No. La evidencia debe ser relevante, accesible y revisada. Registrar indiscriminadamente puede producir ruido. Conviene priorizar datos sensibles, definir responsables y establecer criterios de investigación.
¿También afecta a Power Platform y agentes?
Sí. Cualquier identidad o componente que pueda leer, modificar o desencadenar operaciones debe incluirse en el modelo, con alcance limitado, trazabilidad y aprobación humana cuando el riesgo lo requiera.
El control gana valor cuando acompaña toda la arquitectura
Una implantación sólida no trata la seguridad como un anexo al final del proyecto. La conecta con el ERP, las aprobaciones, las automatizaciones, los datos y la evolución futura.
Business Central y migración
Revisar funciones, extensiones y permisos antes de trasladar el modelo histórico.
Aprobaciones y automatización
Convertir reglas de negocio en circuitos consistentes, medibles y sostenibles.
Construcción y control operativo
Aplicar el modelo a compras, certificaciones, subcontratas, obra y finanzas.
Gobierno de la plataforma Microsoft
Alinear identidad, permisos, automatización, datos, seguridad y evolución.
El permiso correcto no se adivina: se diseña con negocio, control y tecnología
Ayesa aborda Business Central dentro de una arquitectura Microsoft más amplia, conectando procesos, identidad, datos, automatización, seguridad y evolución operativa. El objetivo no es entregar una matriz impecable sobre el papel, sino un modelo que permita trabajar, escalar y demostrar control.
Conocer designaciones, especializaciones y certificaciones →
- ¿Qué puede hacer realmente cada identidad?
- ¿Qué combinaciones permiten completar un proceso?
- ¿Qué excepción está justificada y hasta cuándo?
- ¿Qué evidencia demuestra que el control funciona?
Lista de comprobación para una revisión que sirva después del proyecto
Si la respuesta a varios puntos es “no lo sabemos”, no significa necesariamente que Business Central esté mal configurado. Significa que la organización todavía no dispone de una visión común entre finanzas, operaciones, auditoría y tecnología. Esa conversación es precisamente el punto de partida: identificar dónde está la exposición, decidir qué merece control preventivo y construir un modelo que el equipo pueda mantener cuando el proyecto haya terminado.
¿Los permisos de Business Central reflejan cómo debería funcionar tu empresa?
Podemos ayudarte a identificar combinaciones sensibles, revisar permisos heredados, diseñar funciones, configurar aprobaciones y preparar un modelo mantenible para Business Central, tanto en una implantación existente como dentro de una migración desde NAV.
La revisión puede comenzar por un proceso prioritario —proveedores y pagos, compras, tesorería, ventas o cierre financiero— y extenderse después al resto de la organización. Así es posible reducir primero los riesgos más relevantes sin convertir el análisis en un proyecto interminable ni bloquear el trabajo diario. El resultado debe dejar responsabilidades claras, excepciones controladas y una base preparada para futuras automatizaciones, integraciones y capacidades de inteligencia artificial. También debe facilitar que dirección, finanzas, operaciones y tecnología compartan una misma lectura del riesgo y puedan tomar decisiones sin depender de interpretaciones aisladas.
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)