Marco de gestión de procesos empresariales: qué es y dónde falla

Esta es la versión de esta conversación que sigo teniendo. Alguien del área de operaciones de una empresa mediana decide que necesita "BPM". Compra una herramienta. Realiza un taller de mapeo de procesos de dos semanas. Documenta todo, los diagramas de flujo se ven muy bien en Confluence y declara el éxito. Seis meses después, los mismos cuellos de botella han vuelto. Las mismas cadenas de aprobación son lentas. Los mismos dos departamentos se siguen pasando datos erróneos entre sí en hojas de cálculo.

No fracasaron en la gestión de procesos empresariales. En realidad, nunca la iniciaron. Hicieron documentación de procesos, que es algo completamente distinto.

De eso trata este artículo. De lo que realmente gobierna un marco de gestión de procesos empresariales, cómo funciona el ciclo de vida en la práctica y en qué punto la mayoría de los equipos se desvían silenciosamente antes de que el trabajo llegue a ser útil.

Lo que los equipos aprenden tarde

• BPM es una disciplina de gestión cíclica, no un ejercicio de mapeo que se completa una sola vez.
• El ciclo de vida tiene seis etapas; la mayoría de los equipos financian dos y se preguntan por qué las otras cuatro no ocurren.
• Tratar BPM como automatización o software es la idea equivocada más costosa de esta categoría.
• El tamaño de la organización no determina la relevancia de BPM. La complejidad de los procesos sí.

Qué es realmente la gestión de procesos empresariales

La definición funcional más citada proviene de Gartner, según la formulación de IBM: la gestión de procesos empresariales es una disciplina que emplea métodos para descubrir, modelar, analizar, medir, mejorar, optimizar y automatizar procesos empresariales en apoyo de los objetivos de la empresa. Lea esa lista otra vez y cuente los verbos. Son siete. No es casualidad.

BPM no es una categoría de software. No es una metodología que usted termina. El enfoque de BPMInstitute.org resulta útil aquí: una gestión de procesos empresariales eficaz conecta la ejecución operativa con la intención estratégica, lo que significa que se trata fundamentalmente de gobernanza y responsabilidad, no solo de diagramas de flujo. Los procesos que documente deben tener propietarios, medirse e iterarse. De lo contrario, tiene artefactos, no un marco.

Esta distinción confunde a todos los equipos que he visto abordar esto de forma equivocada. Tratan BPM como un entregable. Un conjunto de mapas, una licencia de herramienta, un hito de proyecto. Lo que realmente es: una disciplina de gestión continua que sigue planteando la misma pregunta en un ciclo: ¿nuestros procesos empresariales están funcionando como exigen nuestros objetivos de negocio y, si no es así, qué estamos cambiando?

La metodología de gestión aquí es realmente cíclica. Usted diseña, ejecuta, supervisa, optimiza y luego vuelve al diseño porque el negocio cambió. No existe un "terminado". Solo existe la "iteración actual". Las organizaciones que lo entienden desarrollan capacidad con el tiempo. Las que no, siguen repitiendo el mismo taller de dos semanas cada pocos años y preguntándose por qué nada perdura.

Los 3 tipos de BPM que reconocen la mayoría de los marcos

Antes de poder elegir cómo gestionar sus procesos, conviene saber con qué tipo de trabajo de procesos está tratando realmente. La mayor parte de la literatura sobre BPM —IBM, SAP Signavio y Ardoq cubren este tema— converge en tres tipos. No son mutuamente excluyentes dentro de una organización. La mayoría de las empresas ejecuta los tres simultáneamente y los trata como una sola categoría, que es donde comienza la confusión.

BPM centrado en la integración

Este tipo se basa en conectar sistemas y automatizar transferencias entre plataformas con una intervención humana mínima. Piense en la sincronización de CRM a ERP, activadores de confirmación de pedidos y enrutamiento de datos entre herramientas según reglas empresariales. La automatización de procesos aquí es principalmente técnica: algo sucede en un sistema y el marco lo enruta al siguiente sin que alguien tenga que copiar información manualmente en el medio.

El BPM centrado en la integración es el tipo que más a menudo se confunde con el "software BPM" en su conjunto. Cuando alguien dice "implementamos BPM", hay una probabilidad razonable de que quiera decir que implementó una capa de integración. Es un trabajo real de alineación entre negocio y tecnología, pero es una parte del marco, no el marco en sí.

BPM centrado en las personas

Este tipo está diseñado para flujos donde el juicio humano, las decisiones y las aprobaciones son esenciales. Revisiones de contratos, validaciones de cumplimiento, rutas de escalamiento, evaluaciones de rendimiento: cualquier situación en la que una persona deba tomar una decisión antes de que el proceso avance. La automatización aquí gestiona el enrutamiento y las notificaciones; la persona sigue siendo responsable de la decisión.

Aquí es donde más importan la gobernanza y la claridad de roles dentro del marco. Los propietarios de procesos deben definirse claramente, las reglas empresariales sobre quién aprueba qué deben ser explícitas y el registro de auditoría debe capturar no solo que se tomó una decisión, sino quién la tomó y cuándo. Sigo viendo equipos tratar esto como un problema de flujo cuando en realidad es un problema de responsabilidad.

BPM centrado en documentos

Se construye alrededor del ciclo de vida de documentos que requieren revisión, aprobación, control de versiones y seguimiento de cumplimiento. Finanzas, seguros, salud y gobierno son los entornos evidentes para esto: donde el documento en sí constituye el trabajo del proceso, no solo un subproducto. Los requisitos empresariales aquí suelen ser regulatorios: necesita demostrar qué versión estaba activa, quién la aprobó y cuándo, a veces para auditorías que se realizan años después. Este tipo se superpone ampliamente con el BPM centrado en las personas, pero sitúa el documento en el centro en lugar de la tarea.

El ciclo de vida de BPM: qué controla realmente cada etapa del marco

Aquí hay dos modelos que vale la pena conciliar. BOC Group organiza el ciclo de vida como: gestión estratégica de procesos, diseño y documentación, análisis y optimización, implementación y gestión del cambio, ejecución y operación, y control y retroalimentación. HighGear lo plantea como: diseño, modelado, ejecución, supervisión y optimización. Describen el mismo ciclo desde perspectivas ligeramente diferentes. Ninguno se equivoca. El punto importante que ninguno enfatiza lo suficiente es que es iterativo, no secuencial. Terminar la "ejecución" no significa que deje de diseñar. Las organizaciones que tratan esto como un proyecto lineal en lugar de un proceso BPM continuo son las que terminan de nuevo en el punto de partida cada pocos años.

Diseño y documentación de procesos

Aquí es donde ocurre el descubrimiento de procesos: identificar qué procesos existen, quién es responsable de ellos, qué se supone que deben producir y dónde se descomponen realmente. Todavía no está modelando nada. Está creando un mapa defendible de la realidad actual: desordenada, no oficial y, a menudo, distinta de lo que sugiere el organigrama.

La mayoría de los equipos financia insuficientemente esta fase porque quiere llegar a la parte interesante. La parte interesante, según su visión, suele ser la automatización de procesos: software, herramientas, flujos. Pero no puede automatizar lo que no ha documentado con precisión. Y no puede documentarlo correctamente si omite el trabajo de descubrimiento y se basa en lo que los responsables creen que sucede en el nivel operativo. Esas dos cosas casi nunca son iguales.

Algunas señales de que su fase de diseño y documentación está incompleta: sus mapas de procesos se crearon en un taller sin la participación de las personas que realmente ejecutan el proceso, su documentación cubre solo el camino ideal o nadie ha asignado un propietario identificado a cada proceso documentado. Cualquiera de esas brechas le causará problemas más adelante.

Modelado de procesos y arquitectura de procesos

El modelado de procesos traduce los procesos documentados a representaciones visuales o estructuradas formales. BPMN (Business Process Model and Notation) es el enfoque más estandarizado, aunque la adopción varía: sigo escuchando a equipos que probaron BPMN, consideraron pronunciada la curva de aprendizaje y volvieron a diagramas de carriles o diagramas de flujo informales. Es una tensión real. La formalidad de BPMN es valiosa para procesos complejos entre sistemas. Para flujos más simples y centrados en las personas, las notaciones más ligeras suelen ganar en usabilidad.

La arquitectura de procesos es la disciplina de nivel superior: cómo se relacionan los flujos de procesos individuales entre sí en toda la organización, cómo se conectan con los objetivos estratégicos y cómo los cambios en un proceso se propagan a aquellos que dependen de él. La representación visual del proceso a nivel arquitectónico es lo que separa a los equipos con un marco BPM coherente de los equipos con una carpeta llena de diagramas de flujo que nadie consulta. Aquí vive la arquitectura empresarial en su conjunto: el mapa de cómo se conectan las capacidades, los procesos, los sistemas y las unidades organizativas.

Sin esta capa arquitectónica, está mejorando procesos en silos. Optimiza el proceso de un departamento, genera fricción tres transferencias más adelante y luego se pregunta por qué el resultado integral no mejoró. Esto es común. Lo he visto en ambas direcciones: empresas que optimizan su proceso de ventas sin modificar los criterios de calificación de marketing, y empresas que automatizan sus aprobaciones financieras sin comprobar cómo el cambio afecta a los procesos de RR. HH. que las alimentan.

Ejecución, supervisión y métricas de procesos

La ejecución de procesos es donde el flujo diseñado se ejecuta en producción. Esto parece obvio, pero la ejecución es donde se hace visible por primera vez la brecha entre el comportamiento documentado y el real. El mapa de procesos indica tres pasos. La realidad tiene cinco debido a una solución alternativa que existe desde 2019, que nadie documentó oficialmente pero de la que todos dependen de manera no oficial.

La supervisión de procesos es lo que mantiene la ejecución bajo control. Debe realizar un seguimiento de métricas de procesos que le indiquen si el proceso funciona según lo diseñado: tiempo de ciclo (cuánto tarda cada instancia desde el activador hasta la finalización), tasa de errores, tasa de reprocesos, frecuencia de excepciones y demora en las transferencias. El ciclo de control y retroalimentación del modelo de BOC Group pertenece aquí: los datos en tiempo real regresan a la capa de gobernanza y revelan desviaciones antes de que se conviertan en fallos normalizados.

La salud del proceso es lo que realmente está observando. Un proceso puede ejecutarse sin fallar y aun así tener una salud deficiente: si tarda tres veces más que el tiempo de ciclo diseñado, si una de cada cinco instancias activa una excepción manual o si los equipos posteriores corrigen sistemáticamente sus resultados. Esas son señales de salud. No aparecen en un panel de aprobado/reprobado. Aparecen en las métricas, si las está siguiendo.

Los equipos que omiten la supervisión casi siempre descubren que la necesitaban por las malas.

La optimización de procesos como ciclo continuo, no como proyecto

La optimización de procesos es donde los datos supervisados de la ejecución se convierten en cambios. Una variación en el tiempo de ciclo genera un análisis. El análisis revela un cuello de botella. El cuello de botella se rediseña. El rediseño vuelve a alimentar las fases de documentación y modelado. Este es el mecanismo de mejora continua que convierte BPM en una disciplina en lugar de una implementación.

El patrón que sigo viendo en los equipos que se estancan: tratan la primera optimización como la última. La metodología de mejora de procesos se aplica una vez, los indicadores mejoran y la iniciativa se declara completa. Luego el negocio cambia, el proceso se desvía y, dieciocho meses después, alguien vuelve a realizar el mismo taller y actúa sorprendido por los resultados. Los proyectos de mejora de procesos tienen fechas de finalización. Un marco BPM no. La fase de optimización es una puerta recurrente en un proceso continuo, no un hito de proyecto. Para optimizar procesos empresariales de manera sostenible, necesita que el ciclo esté funcionando, lo que exige que alguien sea responsable de él de forma permanente, no solo durante la iniciativa.

🤔 Piense en esto:
La mayoría de los equipos invierte considerablemente en diseño y documentación de procesos, las fases que generan resultados visibles como diagramas de flujo y entregables de talleres. La supervisión y la optimización, donde realmente reside la mejora sostenida, reciben una fracción de esa inversión. La fase de diseño produce artefactos. Solo la fase de supervisión le indica si esos artefactos reflejan algo que realmente funciona.

Marco BPM frente a gestión de flujos: dónde está realmente el límite

Esta es una de las confusiones más frecuentes que veo, y es importante porque confundirlas lleva a comprar soluciones para el problema equivocado.

Un marco BPM es una disciplina organizativa. Establece estructuras de gobernanza, define la propiedad de los procesos, fija estándares de medición y gestiona todo el ciclo de vida, desde el descubrimiento hasta la optimización. Es el sistema que decide qué procesos existen, quién es responsable de ellos, cómo se mide el rendimiento y cuándo se modifican. Un marco es un enfoque estructurado para toda la capa de gobernanza operativa.

La gestión de flujos es una capa táctica de ejecución. Gestiona el enrutamiento de procesos individuales: esta tarea va a esta persona, este documento necesita esta aprobación, este activador inicia esta secuencia. Las herramientas de gestión de flujos son lo que implementa para ejecutar una instancia de proceso específica. Operan dentro del marco, no lo sustituyen.

La consecuencia en el mundo real de confundirlos: los equipos compran una herramienta de gestión de flujos y asumen que el software crea el marco BPM a su alrededor. No es así. La herramienta gestiona el enrutamiento de tareas para instancias de procesos individuales. El marco define qué procesos existen, quién es responsable de ellos en toda la organización, cómo se mide el rendimiento y qué reglas de gobernanza se aplican. Necesita ambos, pero no son sustitutos entre sí.

Una analogía que funciona bien: gestión de proyectos frente a software de gestión de proyectos. La disciplina y la herramienta son cosas diferentes. La herramienta respalda la disciplina. La disciplina no surge de la herramienta.

Qué aspecto tiene un marco BPM adecuado en distintos niveles de madurez organizativa

Una de las ideas equivocadas persistentes en este ámbito es que BPM solo es relevante para grandes empresas con equipos dedicados a la excelencia de procesos. Es incorrecto. La formalidad y el alcance del marco cambian con la escala organizativa. La disciplina subyacente —gestionar, medir y mejorar sus procesos— se aplica en todas partes. Así es como se ve realmente un enfoque BPM adecuado en cada nivel de madurez y dónde suelen desviarse los equipos de cada nivel.

• Equipos en fase inicial con procesos informales

La señal organizativa: los procesos existen como conocimiento tribal, acuerdos ad hoc y "pregúntele a Jordan cómo se hace". El alcance BPM adecuado en este nivel es deliberadamente pequeño: documente de tres a cinco procesos críticos, asigne un propietario identificado a cada uno y establezca una métrica por proceso para comprobar si funciona. El error común consiste en no hacer nada —ninguna disciplina de procesos— o en saltar directamente a un despliegue completo de gobernanza de procesos con herramientas y talleres, lo que supone más estructura de la que la organización puede asimilar. Una práctica de procesos eficaz en esta etapa significa empezar de forma ligera y añadir gobernanza a medida que el equipo crece.

• Operaciones de empresas medianas que estandarizan entre departamentos

La señal organizativa: los distintos departamentos han desarrollado sus propios hábitos de procesos, y las transferencias entre ellos son una fuente recurrente de errores, demoras y trabajo duplicado. Aquí es donde las iniciativas de procesos deben centrarse en la alineación interfuncional, la propiedad formal de los procesos y estándares de medición coherentes. El alcance BPM adecuado aquí incluye una visión de arquitectura de procesos: cómo se conectan los procesos entre departamentos, no solo dentro de ellos. El error común es ejecutar proyectos de mejora de procesos departamento por departamento sin conectarlos. Mejora el proceso de ventas de manera aislada y luego descubre que la transferencia a finanzas sigue siendo manual, y la mejora se detiene en el límite del equipo.

• Empresas maduras que ejecutan una gobernanza de procesos completa

La señal organizativa: patrocinio ejecutivo de la gestión de procesos, una función dedicada de BPM o excelencia de procesos, control formal de cambios para actualizaciones de procesos e integración entre los datos de rendimiento de procesos y la planificación estratégica. La gobernanza de procesos a este nivel implica rutas de escalamiento definidas, controles de cumplimiento y revisiones periódicas de procesos vinculadas a objetivos empresariales. Un estudio de 2026 publicado en el International Journal for Quality in Health Care descubrió que, entre los factores más asociados con una mayor madurez BPM en hospitales públicos, la gestión de riesgos y el control de cumplimiento, junto con la participación de la alta dirección, ocuparon los primeros puestos. Ese patrón se mantiene fuera de la atención sanitaria: la gobernanza y la alineación ejecutiva no son elementos decorativos de un marco BPM maduro. Son lo que hace funcional a la disciplina a escala. El error común en este nivel es diseñar en exceso estructuras de gobernanza que ralentizan los mismos procesos que se supone que deben gestionar.

Los equipos del nivel intermedio —que estandarizan entre departamentos— suelen ser los que más se benefician de un enfoque de gobernanza de procesos compatible con la automatización. Hace unos años, un equipo de operaciones con el que trabajé gestionaba las aprobaciones de cambios de procesos en una hoja de cálculo con 14 columnas y un director financiero muy paciente. El problema no era que el marco fuera incorrecto. El problema era que la capa de ejecución para gestionar cambios de procesos no tenía registro de auditoría ni enrutamiento aplicable. Una vez que trasladaron las solicitudes de cambio de procesos a un flujo estructurado, donde cada actualización se enrutaba, versionaba y registraba, la capa de gobernanza finalmente funcionó como se había diseñado. En Latenode, algo así puede configurarse con una combinación de lógica de enrutamiento, comparación de versiones en un nodo JavaScript y OAuth automático para enviar las aprobaciones a cualquier sistema que el equipo ya utilice para las validaciones. Los precios por ejecución también ayudaron: un flujo de aprobación de seis pasos contaba como una ejecución, no seis, lo que mantuvo los costes previsibles a medida que crecía el volumen.

Dónde se descomponen los marcos BPM en la práctica

He visto suficientes iniciativas BPM estancarse como para tener una taxonomía aproximada de cómo fracasan. Casi nunca se trata de un único fracaso dramático. Suele ser una acumulación lenta de medias decisiones: se compró la herramienta, pero no se construyó la gobernanza; se dibujó el mapa, pero no se inició la medición; se lanzó el proyecto, pero no se asignó la responsabilidad. Luego la iniciativa sobrevive a su patrocinador, la energía se disipa y la organización vuelve a los procesos informales seis meses después.

Confundir el software BPM con un sistema BPM

Esto aparece en soporte más de lo que me gustaría admitir. Un equipo compra una plataforma BPM —buenas herramientas BPM, funcionalidad real— y trata la compra como la implementación de un sistema BPM. El software se convierte en el marco en su modelo mental. No lo es.

Las plataformas BPM y el software BPM le proporcionan infraestructura de ejecución. No le proporcionan propiedad de procesos, cultura de gobernanza, supervisión de procesos manuales ni voluntad organizativa para ejecutar las fases de supervisión y optimización. Esos son problemas de personas. El sistema BPM —el sistema realmente funcional— es una combinación de herramientas, roles, reglas y hábitos. No puede comprar los roles, las reglas y los hábitos. Debe desarrollarlos por separado.

El síntoma de este modo de fracaso: la plataforma BPM está en funcionamiento, los paneles parecen activos y los mismos problemas operativos que existían antes de comprar la herramienta siguen ocurriendo. A veces con más intensidad, porque ahora hay datos que los confirman y nadie ha asignado la responsabilidad de actuar sobre ellos. La mejora de procesos empresariales requiere un marco de gobernanza detrás de las herramientas. Las herramientas simplemente facilitan la ejecución de la gobernanza.

Ahí es donde suele comenzar el ticket.

Tratar el mapeo de procesos como el objetivo final

El mapeo de procesos es realmente útil. Revela cómo funcionan los procesos en realidad frente a cómo las personas creen que funcionan, que casi siempre es diferente. El problema surge cuando el mapa se convierte en el entregable, cuando completar el ejercicio de mapeo cuenta como completar el trabajo BPM.

Un mapa de procesos sin medición asociada es arqueología, no operaciones. Ha documentado el proceso actual, lo cual es valioso. Pero si esa documentación no se conecta con métricas que le indiquen si el proceso cumple su propósito, y si no hay gobernanza para decidir cuándo y cómo cambiarlo, el mapa simplemente queda desactualizado. El proceso actual evoluciona mediante soluciones alternativas informales, gestión de casos límite y rotación de personal. En un año, incluso un mapa bien elaborado es una imagen de un proceso que ya no existe.

El enfoque de mejora de procesos debe tratar el mapeo como la primera fase de un ciclo continuo, no como un proyecto independiente. Los problemas de procesos no se resuelven mediante documentación, sino cerrando el ciclo entre el mapa, la medición y la capa de gobernanza que decide qué cambia.

💡 Conviene saberlo:
Los fallos BPM más costosos no ocurren en la fase de diseño. Ocurren en la brecha entre los procesos documentados y lo que las personas realmente hacen. Esa brecha solo se cierra mediante supervisión y ciclos de retroalimentación: las dos fases que reciben la menor inversión organizativa. Un mapa de procesos detallado sin supervisión en tiempo real es una instantánea de cómo era su proceso en el momento del taller.

Cómo se aplican los marcos BPM en distintos sectores y departamentos

Los marcos BPM a veces se describen como aplicables "en todos los sectores", lo cual es cierto pero inútil sin detalles. Se aplican ampliamente porque toda organización tiene procesos empresariales, y todos se benefician de tener responsables, medirse y mejorarse. El alcance, la formalidad y las restricciones difieren significativamente según el contexto.

Sectores regulados: cumplimiento, riesgos y documentación de procesos

En finanzas, seguros, salud y gobierno, los marcos BPM incorporan una capa adicional de restricción: el cumplimiento normativo. La documentación de procesos no es solo una buena práctica en estos entornos. Es un requisito de auditoría. Debe demostrar no solo que existe un proceso, sino que la versión autorizada actual está documentada, que los cambios siguieron una aprobación formal y que las desviaciones del procedimiento estándar se detectaron y registraron.

El estudio sanitario de 2026 descubrió que, en hospitales con menor madurez BPM, el déficit se manifestaba con mayor claridad en las capacidades de control de cumplimiento y gestión de riesgos, precisamente los ejes que revisan los organismos de licencias y acreditación. La mejora de procesos empresariales en entornos regulados no es una optimización opcional. Es el mecanismo mediante el cual demuestra que opera dentro de límites definidos. El modelado de procesos en este contexto debe ser suficientemente preciso para servir tanto a la mejora operativa como a fines de auditoría externa, lo que genera una disciplina que tiende a producir marcos más rigurosos en general.

Equipos de operaciones y TI: alinear la automatización con la gobernanza de procesos

Para los equipos de operaciones y TI que impulsan la transformación digital, los marcos BPM proporcionan la capa de gobernanza que evita que la automatización se convierta en caos. Sin gobernanza de procesos detrás, la automatización a escala implica más velocidad en procesos que pueden estar mal diseñados, medirse de forma inconsistente o no tener responsable. Obtiene errores más rápidos, no resultados más rápidos.

La minería de procesos —el análisis de registros de eventos de sistemas para reconstruir cómo se ejecutan realmente los procesos— se utiliza cada vez más para revelar la brecha entre los flujos diseñados y los reales. Funciona como una herramienta de descubrimiento para organizaciones con entornos ricos en datos. El caso de uso de clasificación de cuellos de botella es práctico y accesible: cuando un equipo de procesos cuenta con una entrada estructurada para capturar puntos de demora, fricción en las transferencias y aprobaciones innecesarias, puede crear una lista priorizada de mejoras que alimenta directamente la fase de optimización. El flujo S-03 de Latenode refleja este patrón: un flujo de entrada conectado a clasificación por IA y puntuación de gravedad envía problemas estructurados de procesos al sistema de tareas del equipo adecuado, sustituyendo los mensajes dispersos por una señal rastreable. Configurarlo correctamente suele llevar menos de 30 minutos una vez definido el canal de entrada. La implementación de mejoras de procesos sigue requiriendo juicio humano. El marco enruta la información. Las personas toman la decisión.

Departamentos funcionales: flujos de RR. HH., finanzas y cadena de suministro

Los equipos de RR. HH., finanzas, legal y cadena de suministro tienen necesidades recurrentes de flujos que se sitúan claramente en el ámbito del BPM centrado en las personas y en los documentos: aprobaciones de incorporación, revisiones de gastos, enrutamiento de contratos, validaciones de órdenes de compra. No son desafíos de gobernanza de procesos a escala empresarial. Son problemas de gestión de recursos a nivel departamental que se benefician enormemente de la propiedad estructurada y de una medición básica.

Esto contradice la idea equivocada de que BPM es una disciplina empresarial o de TI. Un equipo financiero de cinco personas con un proceso claro para aprobaciones de gastos —pasos definidos, propietario identificado y tiempo de ciclo monitorizado— está haciendo BPM. Mejorar procesos empresariales a esta escala consiste principalmente en sustituir flujos informales por flujos definidos y añadir la supervisión justa para detectar cuándo algo se desvía.