La mayoría de los procesos de aprobación no fallan porque el equipo carezca de una herramienta. Fallan porque nadie acordó quién es realmente responsable de la decisión, qué criterios activan un «sí» o qué sucede cuando el aprobador principal está en una conferencia en Ámsterdam y su bandeja de entrada está configurada en modo vacaciones.
He visto este patrón suficientes veces como para dejar de sorprenderme. Un equipo pone en marcha un nuevo flujo de aprobación en cualquier herramienta que tenga disponible, observa que funciona durante tres semanas y luego se encuentra con el primer caso excepcional. Nadie definió la ruta de escalamiento. La solicitud queda pendiente. El solicitante hace seguimiento. El aprobador se disculpa. El ticket se cierra como «resuelto», aunque el proceso subyacente siga roto.
La afirmación que defiende este artículo es la siguiente: la mayoría de las demoras en las aprobaciones provienen de un mal diseño del proceso, no de la falta de herramientas. Mapear y simplificar antes de automatizar es la secuencia que realmente produce una mejora medible. Aplicar automatización a una secuencia rota simplemente hace que la secuencia rota funcione más rápido.
Primero mapee, después automatice
- La mayoría de las demoras en las aprobaciones se deben a responsabilidades imprecisas y criterios ausentes, no a limitaciones de las herramientas.
- Automatizar un proceso de aprobación mal diseñado no lo corrige: acelera la disfunción.
- Defina roles, umbrales y rutas de escalamiento antes de abrir cualquier pantalla de configuración.
- El enrutamiento de aprobaciones en paralelo puede reducir el tiempo de ciclo sin disminuir la supervisión, pero la mayoría de los equipos nunca lo prueba.
Qué controla realmente un proceso de aprobación (y dónde suele fallar)
Un proceso de aprobación es un mecanismo estructurado de enrutamiento y responsabilidad. Responde cuatro preguntas concretas: quién puede iniciar una solicitud, quién está autorizado para decidir, bajo qué criterios se toma la decisión y qué sucede con el registro después. Si elimina el software y las cadenas de correo electrónico, eso es todo.
Un proceso de aprobación es un sistema estructurado que mueve una solicitud a través de etapas de revisión definidas antes de ejecutar una acción o comprometer un recurso. Existe para aplicar controles y equilibrios, evitando que una sola persona tome decisiones importantes de forma unilateral y manteniendo la transparencia y la responsabilidad sobre el resultado. Una aprobación de gastos firmada es un registro de quién revisó qué, bajo qué reglas y qué decidió.
Esa es la teoría. En la práctica, el flujo de aprobación —la secuencia técnica que ejecuta el proceso— se construye antes de que la lógica del proceso esté realmente definida. Alguien crea un formulario, añade un campo de aprobador, lo conecta al correo electrónico y lo da por terminado. Los criterios viven en la cabeza de alguien. La ruta de escalamiento no existe. El aprobador de respaldo es quienquiera que esté disponible.
Los dos fallos estructurales más comunes que veo son las definiciones de roles imprecisas («el gerente aprueba las cosas») y los criterios de decisión ausentes («use su criterio»). Ambos garantizan retrabajo. Ambos sobreviven a la automatización completamente intactos. Puede automatizar un proceso de aprobación impreciso, pero lo único que habrá hecho será enrutar la ambigüedad más rápido.
Ahí es donde suele comenzar el ticket.
Cómo mapear y analizar su flujo de aprobación actual antes de usar cualquier herramienta
Cuando los procesos de aprobación son lentos, el instinto es recurrir inmediatamente a una herramienta. Crear un formulario, configurar un flujo, conectarlo a Slack. Entiendo el impulso. Parece progreso. Normalmente no lo es.
Los equipos que omiten el mapeo —que pasan directamente a la pantalla de automatización— terminan automatizando el caos. La regla de enrutamiento que configuran refleja cómo se producen realmente las aprobaciones hoy, lo que incluye los cuellos de botella, las soluciones alternativas, las rutas de excepción olvidadas y la única persona cuya bandeja de entrada bloquea una de cada tres solicitudes. La herramienta ejecuta todo eso fielmente.
Qué documentar antes de rediseñar nada
Antes de rediseñar nada, necesita un mapa paso a paso de cómo se mueven realmente las aprobaciones hoy; no de cómo se supone que deben avanzar, sino de la secuencia real. Eso implica hablar con las personas que envían solicitudes y con las personas que las aprueban, porque esas dos versiones casi siempre son diferentes.
Documente cada etapa desde el envío inicial hasta la decisión final. Identifique quién interviene en la solicitud en cada etapa. Mida o estime el tiempo promedio por paso, aunque sea de forma aproximada. Un enfoque sistemático aquí no necesita ser complicado: basta con un diagrama de flujo en una pizarra con nombres y estimaciones de tiempo por etapa para empezar. Lo que está creando es un registro de dónde vive actualmente el proceso, para poder ver dónde falla antes de decidir cómo corregirlo.
En concreto, registre:
- Cada paso de la secuencia actual de revisión y aprobación, en orden
- Quién es responsable de cada paso (no el equipo, sino la persona)
- Tiempo promedio de espera en cada paso
- Puntos de fallo recurrentes: solicitudes que desaparecen, aprobaciones que se estancan, retrabajo que ocurre más de una vez al mes
- Cualquier solución alternativa que el equipo haya creado alrededor del proceso oficial
Los últimos dos elementos son los más valiosos. Las soluciones alternativas le indican exactamente dónde no funciona el proceso oficial.
Cómo detectar los cuellos de botella que sobrevivirán a la automatización
No todos los cuellos de botella son iguales. Algunos desaparecen al añadir lógica de enrutamiento y recordatorios automatizados. A otros no les importa que haya creado un flujo atractivo: persistirán porque el problema nunca fue técnico.
El cuello de botella peligroso es el causado por una responsabilidad poco clara o por criterios de decisión ausentes. Si tres personas creen que podrían necesitar aprobar una solicitud, pero nadie está seguro, automatizar el paso de enrutamiento no resuelve la ambigüedad. Simplemente entrega la ambigüedad más rápido, a tres bandejas de entrada simultáneamente y con una fecha límite adjunta.
Del mismo modo, complicar en exceso un flujo con demasiados aprobadores es un error estructural, no un error de configuración de la herramienta. Añadir más aprobadores secuenciales genera más demora sin mejorar la calidad de las decisiones. Si el quinto aprobador de una cadena está revisando una solicitud de gasto de 500 $, la pregunta no es cómo recordárselo más rápido, sino si debería estar en la cadena.
Cuando examine el mapa de su proceso, los cuellos de botella que sobrevivirán a la automatización son aquellos donde la demora se debe a una pregunta y no a un recordatorio. «¿Quién aprueba esto?» y «¿Esto necesita aprobación siquiera?» son preguntas. Son problemas de diseño. Corríjalos primero.
Cómo definir roles, criterios y umbrales para un proceso de aprobación ágil
El proceso de aprobación eficiente se diseña en torno a reglas, no a decisiones basadas en el juicio. Cada vez que un aprobador debe decidir si algo necesita aprobación, en lugar de decidir si aprobarlo, existe una brecha de diseño.
Para crear un proceso de aprobación que enrute de manera consistente, necesita cuatro elementos definidos de antemano: quién inicia las solicitudes, quién aprueba en cada nivel, qué criterios determinan qué ruta sigue una solicitud y quién cubre la función cuando el aprobador principal no está disponible. La mayoría de los equipos define los dos primeros y omite completamente los dos últimos.
Establecer criterios de aprobación que enruten solicitudes sin suposiciones humanas
Los criterios de aprobación son las reglas que determinan adónde va una solicitud. Sin ellos, el enrutamiento se convierte en una decisión basada en el juicio cada vez, lo que implica inconsistencia, decisiones subjetivas y retrabajo cuando distintos aprobadores aplican estándares diferentes al mismo tipo de solicitud.
Defina los criterios explícitamente antes de configurar nada. Algunos ejemplos prácticos:
- Umbral de presupuesto: las solicitudes inferiores a 1.000 $ se enrutan al líder del equipo; las de 1.000 $ a 10.000 $ se enrutan al responsable del departamento; las superiores a 10.000 $ requieren revisión financiera
- Categoría de riesgo: las compras estándar a proveedores siguen una ruta; la incorporación de nuevos proveedores activa una comprobación de cumplimiento
- Documentación requerida: las facturas por encima de un umbral deben incluir un número de orden de compra; las solicitudes de viaje deben incluir el propósito y destino del viaje
Los criterios predefinidos hacen que la solicitud se enrute automáticamente según una regla. Cuando los criterios son claros, la tarea del aprobador es evaluar la solicitud, no averiguar qué es la solicitud o si es la persona adecuada para gestionarla. Solo esa distinción elimina una cantidad sorprendente de idas y vueltas.
Designar aprobadores de respaldo y rutas de escalamiento antes de necesitarlos
Todo proceso de aprobación se diseña para el caso ideal: el aprobador principal está disponible, revisa la solicitud y la aprueba o rechaza dentro del plazo previsto. Esa ruta funciona bien hasta que el aprobador principal se va de vacaciones.
Diseñar únicamente para el caso ideal es un error estructural que aparece de forma consistente en los patrones de soporte. Una solicitud de aprobación sin un aprobador de respaldo definido no se escala: se estanca. Eso significa que alguien debe perseguir manualmente la situación, encontrar un aprobador alternativo y reiniciar el plazo. Es un ticket de soporte esperando a ocurrir.
Antes de configurar cualquier flujo, designe un aprobador de respaldo para cada rol de aprobación y defina cuándo se produce el escalamiento. Como punto de partida: marque cualquier solicitud de aprobación que no haya recibido una decisión en 48 horas laborables, envíe un recordatorio a las 24 horas y escale automáticamente al aprobador de respaldo o a un gerente a las 72 horas. Los umbrales específicos variarán, pero el principio es el mismo: las rutas de excepción necesitan rutas definidas, no improvisación humana.
Cómo diseñar el flujo futuro: secuencia, aprobaciones en paralelo y pasos estandarizados
Una vez que haya mapeado el proceso actual y definido roles y criterios, puede rediseñar la secuencia. El objetivo es tener menos pasos con responsables más claros, no más pasos con mayor visibilidad.
Un flujo de aprobación bien diseñado sigue una secuencia estandarizada de pasos: envío, revisión, colaboración o ajuste si es necesario, aprobación o rechazo, y luego registro y archivado. Cada tipo de aprobación debería encajar en esta estructura, incluso si los actores y criterios específicos son distintos. Estandarizar el patrón de pasos reduce la confusión tanto para los solicitantes como para los aprobadores. Las personas saben qué esperar y dónde se encuentra la solicitud en cualquier momento.
La pregunta de rediseño para cada paso es si es necesario. Si un paso de aprobación existe debido a un evento histórico o a la suposición de «siempre lo hemos hecho así», compruebe si eliminarlo modifica el perfil de riesgo. Muchas cadenas de aprobación incluyen redundancia —múltiples autorizaciones sobre una decisión que una persona informada podría tomar— que genera demora sin mejorar la calidad de las decisiones.
La secuencia frente al paralelismo es la otra decisión estructural. La mayoría de los equipos utiliza el enrutamiento secuencial de forma predeterminada. Cada aprobador ve la solicitud solo después de que el anterior haya actuado. Esto parece controlado. A menudo no lo está. El enrutamiento secuencial significa que el tiempo de ciclo es la suma de cada tiempo de respuesta individual. Si un aprobador tarda tres días, toda la cadena espera tres días. El enrutamiento en paralelo envía la solicitud a varios aprobadores simultáneamente. La aprobación se completa cuando se reciben todas las respuestas requeridas. Para decisiones en las que cada aprobador evalúa algo distinto —viabilidad técnica, presupuesto, cumplimiento— no hay razón para que esas revisiones no puedan realizarse al mismo tiempo.
💡 Conviene saber:
El enrutamiento de aprobaciones en paralelo puede reducir significativamente el tiempo de ciclo sin disminuir la supervisión, porque cada revisor está evaluando una dimensión distinta de la solicitud de todos modos. La mayoría de los equipos utiliza el enrutamiento secuencial de forma predeterminada porque parece más controlado. Lo que realmente hace es sumar los tiempos de respuesta de todos los aprobadores en una sola demora. Si tiene tres revisores independientes que tardan un día cada uno, el enrutamiento secuencial tarda tres días. El enrutamiento paralelo tarda uno.
Cómo configurar y automatizar un proceso de aprobación en una herramienta de flujos
Ahora está listo para configurar. El trabajo de diseño está terminado: tiene un mapa de procesos, roles definidos, criterios explícitos, rutas de escalamiento y una secuencia de pasos futura. En esta etapa, la automatización es trabajo de configuración, no trabajo de descubrimiento. Está codificando decisiones que ya se han tomado.
Reglas de enrutamiento, notificaciones y lógica de escalamiento que realmente evitan solicitudes estancadas
Los mecanismos específicos de automatización que evitan que las aprobaciones queden en las bandejas de entrada son el enrutamiento dinámico, los recordatorios activados por plazos y el escalamiento automático cuando vence un SLA. Cada uno resuelve una parte diferente del problema de estancamiento.
El enrutamiento dinámico significa que la solicitud se dirige al aprobador correcto según criterios, automáticamente. El importe del presupuesto se enruta al nivel de autoridad adecuado. El departamento se enruta al responsable correcto. El tipo de solicitud activa la ruta de revisión adecuada. Esto sustituye el reenvío manual y los mensajes de «creo que necesita hablar con tal persona», que ocupan una cantidad sorprendente de tiempo en procesos gestionados manualmente.
Sigo viendo equipos que automatizan el paso de envío de formularios, pero dejan los recordatorios y el escalamiento como tareas manuales. Esa es la parte que reproduce el problema de perseguir correos electrónicos dentro de una herramienta nueva. Configure la lógica de recordatorios antes de que se active la primera solicitud. Un punto de partida práctico: envíe un recordatorio después de 24 horas sin respuesta, escale al aprobador de respaldo después de 72 horas y marque para revisión de un gerente cualquier solicitud que no se haya resuelto en cinco días laborables.
Las notificaciones y las respuestas de aprobación por correo electrónico deben permitir actuar en el contexto cuando sea posible. Un aprobador que puede aprobar o rechazar desde un mensaje de Slack o una notificación por correo electrónico, sin iniciar sesión en un sistema independiente, responde más rápido. No es una preferencia de funcionalidad: es comportamiento humano.
Integraciones de sistemas que eliminan la introducción manual de datos de la cadena de aprobación
Las herramientas de aprobación conectadas a sistemas de origen producen menos errores y tiempos de ciclo más rápidos por una razón sencilla: los datos se obtienen automáticamente en lugar de ser introducidos por el solicitante. Cuando una solicitud de compra exige que el solicitante introduzca manualmente el nombre del proveedor, el número de orden de compra, el código presupuestario y el centro de costes, ha creado cuatro oportunidades de errores tipográficos y cuatro motivos para que un aprobador rechace o solicite correcciones.
Conectar su flujo de aprobación a su ERP, CRM, sistema de compras o sistema de gestión documental significa que la solicitud llega con el contexto relevante ya completado. El aprobador evalúa la decisión, no la introducción de datos. Orquestar estas conexiones —obtener contexto de un sistema, enrutar la aprobación y enviar el resultado a otro— es donde el diseño de procesos de aprobación en flujos deja de ser un problema de creación de formularios y se convierte en un problema de integración.
Para flujos de aprobación multisistema, Latenode gestiona este tipo de orquestación de una manera que vale la pena describir concretamente. Un flujo puede ingerir una factura por correo electrónico o almacenamiento en la nube, utilizar uno de más de 1.200 modelos de IA para extraer el nombre del proveedor, el importe y las líneas de detalle, aplicar lógica de enrutamiento codificada en un nodo de JavaScript, sincronizar el resultado con un ERP mediante una integración OAuth preconfigurada y enviar actualizaciones de estado a Slack, todo dentro de una única ejecución. El modelo de precios por ejecución significa que un flujo de seis pasos cuenta como una ejecución, no como seis tareas independientes, lo que cambia el cálculo de costes a volúmenes más altos.
Cómo probar, implementar y formar a los equipos sin perjudicar la adopción
Un flujo que funciona en una prueba controlada y falla en producción normalmente falló porque la prueba no utilizó datos realistas. Pruebe con tipos de solicitud reales, importes de umbral reales y casos excepcionales que sabe que existen: la solicitud que queda entre dos reglas de enrutamiento, el aprobador que está de baja por paternidad o maternidad, el envío que llega con documentación incompleta. No son situaciones improbables. Son las primeras situaciones de un lunes por la mañana.
Antes del lanzamiento completo, valide la lógica de enrutamiento con cada combinación de criterios definida. Confirme que los activadores de escalamiento se ejecutan en el momento correcto. Compruebe que funcionan las rutas de excepción, no solo el caso ideal. Un proceso nuevo que no se ha probado frente a sus propios modos de fallo no está listo.
La gestión del cambio es la parte que determina si el proceso funciona realmente a la capacidad diseñada o al 40 % de adopción porque la mitad del equipo no sabía que había cambiado. He visto procesos de aprobación bien diseñados fracasar no porque la automatización estuviera rota, sino porque las personas que debían utilizarla seguían enrutando solicitudes a la manera antigua. Implementar sin formación no solo genera tickets de soporte: crea procesos paralelos, lo que es peor que el problema original.
Forme por separado a los solicitantes y a los aprobadores, porque su experiencia del proceso es completamente distinta. Los solicitantes necesitan saber cómo enviar una solicitud, qué información se requiere y dónde consultar el estado. Los aprobadores necesitan saber cómo actuar sobre una solicitud, qué sucede si no responden dentro del plazo del SLA y a quién contactar si detectan un caso excepcional que el sistema no contempló. Una breve demostración con ejemplos reales es más efectiva que un PDF que nadie lee.
Mantenga un período de operación paralela si hay mucho en juego. Mantenga el proceso anterior funcionando junto con el nuevo durante una o dos semanas. Compare los resultados. La redundancia es temporal; la confianza que genera en aprobadores y solicitantes vale el coste.
Cómo supervisar y optimizar un proceso de aprobación después de su lanzamiento
Ningún proceso de aprobación es definitivo. Los requisitos empresariales cambian, las estructuras organizativas se modifican y los casos excepcionales que no anticipó en las pruebas surgirán después de las primeras cien solicitudes. La capa de supervisión le indica cuáles de esos cambios son importantes.
Realice un seguimiento del tiempo de ciclo de aprobación desde el envío hasta la decisión final. Controle cuántas solicitudes requieren revisión o información adicional antes de llegar a una decisión. Supervise la frecuencia de escalamiento y el cumplimiento del SLA. Mida la adopción: ¿las solicitudes están entrando realmente en el sistema o las personas siguen enrutando asuntos por correo electrónico? Cada métrica revela un tipo distinto de problema de proceso. Las tasas altas de retrabajo suelen indicar criterios ausentes o requisitos de documentación ambiguos. Las tasas altas de escalamiento pueden significar que los plazos del SLA son demasiado ajustados, que es difícil localizar a los aprobadores de respaldo o que el rol de aprobador principal cuenta con poco personal. Un proceso con buen tiempo de ciclo y baja adopción funciona correctamente para el 40 % de las solicitudes que entran en el sistema y falla de forma silenciosa para el resto.
Las métricas que muestran si el proceso funciona realmente
Seis métricas le proporcionan una imagen útil del estado del proceso. La reducción del tiempo de ciclo confirma que el enrutamiento y la automatización mueven las solicitudes más rápido que antes. Menos escalaciones sugieren que los criterios son lo suficientemente claros como para que las solicitudes no necesiten intervención de un gerente para avanzar. Tasas de retrabajo más bajas —menos rechazos debido a información incompleta— indican que el formulario de envío y los requisitos de documentación están funcionando. Mayores tasas de finalización a tiempo demuestran que la lógica del SLA funciona. Mejores registros de auditoría significan que el sistema captura el registro de decisión correcto para fines de cumplimiento. Y las tasas de adopción de usuarios —el porcentaje de solicitudes elegibles que entran en el flujo frente a las que se enrutan informalmente— le indican si el proceso es confiable o se evita.
Observe estos campos en el panel de su flujo: tiempo promedio desde el envío hasta la decisión, número de solicitudes fallidas o rechazadas, número de escalaciones por período, solicitudes sin decisión una vez superado el SLA y porcentaje de solicitudes completadas sin revisión. Debe buscar líneas de tendencia, no instantáneas puntuales.
📊 En la práctica:
Los datos de análisis de flujos de AltaFlow sugieren que una automatización de aprobaciones bien implementada suele reducir los tiempos de ciclo entre un 40 % y un 60 %, con objetivos de referencia de una reducción del 30 % al 50 % durante los primeros tres meses y al menos un 85 % de las aprobaciones rutinarias completadas sin revisión. Estas cifras son orientativas, no garantizadas, pero le ofrecen un punto de referencia realista para distinguir entre «está funcionando» y «instalamos una herramienta y lo dimos por terminado».
Cuándo realizar una revisión del proceso y qué cambiar
Programe una revisión del proceso a los 90 días del lanzamiento y, después, trimestralmente. Pero también realice una revisión no programada cuando detecte alguno de estos desencadenantes: un grupo de incumplimientos del SLA en un período corto, un aumento de escalaciones desde un paso específico, un nuevo requisito de política que cambie quién puede aprobar qué o un cambio en la estructura organizativa que afecte a las personas nombradas en el proceso. Los patrones de escalamiento repetidos desde la misma etapa de aprobación casi siempre indican un rol con poco personal o criterios que no coinciden con la forma en que la empresa toma realmente las decisiones. Cambie los criterios. No se limite a recordar a las personas que respondan más rápido.
Gestionar procesos de aprobación a lo largo del tiempo implica tratar el flujo como un documento vivo, no como un artefacto de lanzamiento. Las revisiones periódicas con las partes interesadas —las personas que envían solicitudes, las que las aprueban y las que gestionan los procesos empresariales relevantes— revelan problemas que las métricas detectan demasiado tarde.
Prácticas recomendadas para mantener un proceso de aprobación que no vuelva al correo electrónico
Las prácticas recomendadas a continuación se organizan según el modo de fallo específico que previene cada una, porque una práctica recomendada sin ese contexto es solo una sugerencia.
Utilice plantillas de envío estandarizadas para cada tipo de solicitud
Los procesos de aprobación vuelven a canales informales cuando enviar una solicitud mediante el proceso oficial es más difícil que enviar un mensaje. Las plantillas reducen la fricción en el envío y garantizan que los aprobadores reciban información completa, lo que reduce las solicitudes de retrabajo. Una solicitud que llega con todos los campos obligatorios completados puede evaluarse inmediatamente.
Implemente controles de acceso basados en roles y mantenga un registro de auditoría completo
Sin controles de acceso, el registro de aprobación puede modificarse posteriormente, lo que rompe el cumplimiento y genera disputas. Un registro de auditoría captura quién aprobó qué, cuándo y bajo qué criterios establecidos, y la capacidad de exigir responsabilidades depende de que ese registro sea preciso y resistente a manipulaciones. Esto importa especialmente en los flujos de compras, RR. HH. y finanzas.
Predefina rutas de excepción antes del lanzamiento, no después de la primera excepción
Todo proceso tiene casos excepcionales: solicitudes que quedan fuera de las reglas de enrutamiento estándar, aprobadores que no están disponibles y envíos que llegan con documentación incompleta. Diseñar la ruta de excepción después del primer caso excepcional implica que el primer caso queda estancado mientras la diseña. Documente qué sucede cuando no se alcanza un umbral, cuando el aprobador principal no responde y cuando una solicitud está incompleta.
Evite capas de aprobación innecesarias: cuestione cada paso secuencial
Cada paso de aprobación añade tiempo. Un proceso de aprobación efectivo tiene tantos pasos como realmente requieren el riesgo y el cumplimiento, y no más. Si una capa de aprobación existe porque «siempre lo hemos hecho así» o porque alguien la añadió una vez para una situación específica que ya no existe, elimínela. Las tareas que requieren aprobación deben estar claramente definidas; las que no la requieren no deben enrutarse por aprobación de forma predeterminada.
Configure notificaciones que lleguen a la persona correcta, no solo al rol correcto
Una notificación enviada a una bandeja de entrada de equipo es una notificación sobre la que quizá nadie actúe. Nombre a las personas en las reglas de enrutamiento. Envíe recordatorios a los aprobadores de respaldo automáticamente, no de forma manual. Una notificación de aprobación que crea un nuevo registro de aprobación en la herramienta de flujos que la persona prefiera —en lugar de desaparecer en un canal compartido— recibe una acción de forma más fiable.
Establezca puntos de control periódicos de gobernanza para evitar que los criterios queden obsoletos
Los criterios de aprobación que tenían sentido con la estructura presupuestaria u organigrama del año pasado pueden enrutar incorrectamente ahora. Un punto de control de gobernanza —trimestral o activado por cambios organizativos— es lo que evita que el proceso se aleje silenciosamente de la forma en que opera realmente la empresa. Fomente la responsabilidad compartida del proceso entre las partes interesadas que trabajan dentro de él, no solo la persona que lo configuró inicialmente.
