Detectar una alarma en un producto, enviar material peligroso a un cliente no certificado o descubrir un contrato de proveedor caducado debería tener consecuencias en el ERP. ¿Cómo conectar lo que ocurre en la empresa con lo que el sistema permite hacer?
Imaginemos una distribuidora que recibe una reclamación por un posible defecto en uno de sus productos. Calidad abre una incidencia y envía un correo: «No vender hasta que terminemos la revisión».
Una hora después, Comercial prepara otro pedido con ese producto. No ha leído el mensaje. El almacén sigue trabajando. En Business Central, nada ha cambiado.
La empresa ha detectado el problema y alguien ha dado una instrucción. Pero la operación sigue adelante.
La pregunta es sencilla: si sabemos que algo no debería hacerse, ¿por qué el sistema todavía permite hacerlo?
El espacio entre avisar y controlar
En muchas empresas, las decisiones de control viajan por correo, reuniones o mensajes internos: no comprar a ese proveedor, no enviar ese documento, no utilizar ese producto.
El cumplimiento depende de que todas las personas implicadas reciban el aviso, lo entiendan y lo recuerden justo cuando van a actuar. También de que la persona que las sustituye durante las vacaciones conozca la situación.
Un aviso comunica un riesgo. Un control preventivo actúa sobre la operación antes de que ese riesgo se materialice.
Ese es el papel de las Entity Rules, o reglas de entidad, de AWH GRC: aplicar restricciones sobre registros de Business Central en momentos definidos de un proceso y liberarlos cuando se cumplen las condiciones previstas.
La entidad es el registro sobre el que se actúa: por ejemplo, un producto, un proveedor o un documento. La regla conecta su situación con las acciones que deben quedar restringidas.
Qué aporta AWH GRC al bloqueo
Business Central ya dispone de mecanismos de bloqueo. Por ejemplo, permite bloquear productos para determinadas operaciones. El valor de AWH GRC está en vincular las restricciones al proceso que las justifica: qué ha ocurrido, quién debe intervenir, qué comprobaciones faltan y cuándo corresponde liberar el registro.
Volvamos a la distribuidora. El circuito que interesa diseñar es concreto:
- Se registra la incidencia y se vincula al producto afectado.
- El proceso entra en una etapa que aplica la restricción prevista.
- Calidad investiga y reúne las evidencias.
- La persona responsable decide si procede autorizar de nuevo la operación.
Abrir una incidencia deja de ser solo dejar constancia: puede cambiar lo que se permite hacer.
Los siguientes escenarios ilustran controles que se pueden diseñar con este enfoque. Su alcance depende de las entidades, acciones y conexiones configuradas en cada implantación; una alarma externa o una caducidad deben alimentar el proceso para provocar la respuesta prevista.
Situaciones en las que una regla cambia el resultado:
1. Una alarma de calidad mientras el producto sigue a la venta
Una reclamación recurrente, un ensayo desfavorable o una alerta del fabricante pueden justificar que se detenga la venta de un producto mientras se investiga.
El objetivo del control es restringir las operaciones afectadas desde la apertura del proceso, sin esperar a que cada comercial consulte el correo. La liberación queda ligada a la decisión de Calidad y a las evidencias requeridas.
Importa definir bien el alcance: una incidencia sobre un lote concreto no debería paralizar todas las referencias. El control debe aplicarse al nivel que permita la solución implantada y que corresponda al riesgo real.
2. Un proveedor cuyo certificado acaba de caducar
Compras homologó a un proveedor hace meses. Hoy caduca un certificado que la empresa exige para seguir contratándolo, pero su ficha continúa disponible para nuevos pedidos.
Un proceso de revisión de vigencias puede llevar al proveedor a una situación restringida hasta recibir y validar la documentación renovada.
La condición de salida merece tanta atención como el bloqueo: recibir un archivo no equivale a comprobar que es válido. Debe revisarse que corresponde al proveedor, cubre la actividad requerida y tiene la vigencia adecuada.
3. Un documento pendiente de aprobación que ya parece definitivo
Un pedido con condiciones excepcionales está pendiente de autorización. Mientras tanto, alguien modifica su contenido, imprime una copia o lo envía por correo electrónico.
El circuito de aprobación pierde sentido si el documento puede utilizarse como definitivo antes de resolverlo, o si lo que se ejecuta ya no coincide con lo revisado.
Las reglas pueden plantearse para restringir edición, impresión y registro durante las etapas correspondientes. El diseño debe contemplar también las correcciones: si el documento se devuelve para modificarlo, debe pasar de nuevo por las validaciones que procedan.
Así, la aprobación se refiere a unas condiciones concretas, no simplemente a un número de documento.
4. Una factura en disputa que entra en la propuesta de pagos
El responsable de un servicio comunica que el trabajo está incompleto. La factura ya está contabilizada y Tesorería prepara los pagos sin conocer la reclamación.
Business Central permite marcar movimientos de proveedor como retenidos para excluirlos de la propuesta automática de pagos. Esa función tiene un alcance específico documentado por Microsoft.
El proceso de control puede coordinar esa retención con la resolución de la disputa: quién confirma el servicio, qué importe se acepta y qué evidencia permite continuar. Si se necesita impedir también otras vías de pago, deben quedar cubiertas por el diseño.
El objetivo es evitar que el calendario de Tesorería se adelante a la decisión sobre la factura.
5. Un producto que exige una autorización que el cliente o el proveedor no tiene
Algunos productos están sujetos a normativas que condicionan quién puede comprarlos o venderlos: sustancias peligrosas, materiales con requisitos específicos de transporte o componentes que exigen una homologación. El requisito no depende solo del producto, sino de la combinación entre producto, normativa y la otra parte de la operación.
Un comercial puede preparar un pedido para un cliente nuevo sin saber que ese artículo exige una acreditación que el cliente no ha aportado. En Compras ocurre lo mismo con un proveedor que no dispone del certificado necesario para suministrarlo.
El enfoque consiste en vincular cada normativa con los productos, proveedores y clientes afectados, y comprobar si existe el certificado u homologación requerido antes de permitir la operación. Mientras falte, la operación queda restringida; cuando se valida la documentación, el proceso la libera.
Así, el cumplimiento normativo deja de depender de que alguien recuerde el requisito justo en el momento de hacer o entregar el pedido.
Bloquear es solo la mitad del control
Un bloqueo sin responsable acaba convirtiéndose en una urgencia. Y las urgencias repetidas terminan generando atajos.
Por eso, cada restricción debería tener una respuesta clara a cuatro preguntas:
- ¿Qué la activa? Una incidencia, una caducidad, un rechazo o una revisión pendiente.
- ¿Qué impide? Las acciones concretas que exponen a la empresa al riesgo.
- ¿Quién la resuelve? La persona o departamento responsable de revisar el caso.
- ¿Qué permite retirarla? La evidencia y la decisión necesarias para continuar.
También hay que contemplar los motivos concurrentes. Un proveedor puede tener documentación pendiente y, al mismo tiempo, una incidencia de calidad abierta. Resolver la primera cuestión no debería eliminar la restricción que siga siendo necesaria por la segunda.
Si existe una excepción por urgencia, debe formar parte del procedimiento: autorización, motivo y alcance definidos. «Desbloquéalo y luego lo revisamos» deja la decisión fuera del control que se pretendía aplicar.
Tres preguntas para revisar tus operaciones
Piensa en la última vez que alguien dijo «esto no puede seguir adelante»:
- ¿La decisión cambió algo en Business Central o se quedó en un mensaje?
- Si alguien se encontró con el bloqueo, ¿podía saber por qué se había aplicado, quién se encargaba y cuándo y cómo se resolvería?
- ¿Estaba claro quién podía autorizar la continuación y con qué evidencia?
Las Entity Rules gestionadas por tareas conectan esas decisiones con las operaciones del ERP. Permiten que el proceso tenga consecuencias mientras está abierto y que la vuelta a la normalidad responda a una decisión controlada.
Porque detectar un problema sirve de poco si, un minuto después, la empresa puede seguir operando como si no hubiera ocurrido.
¿Qué operación debería detenerse en tu empresa cuando aparece una incidencia? Ese puede ser el punto de partida para una demostración de AWH GRC con un caso real de tu negocio.
