Cómo rediseñar excepciones, aprobaciones y traspasos antes de automatizar

Antes de automatizar, hay que reconstruir el flujo que realmente siguen los casos y resolver la incertidumbre que hoy se mueve entre correos, formularios, sistemas y colas. Una solicitud puede ser digitada dos veces, recibir una firma que no cambia ninguna decisión, esperar entre áreas y regresar al solicitante porque faltaba evidencia. Hacer más rápida esa secuencia no corrige el problema: solo acelera sus devoluciones. El rediseño debe delimitar un caso recurrente, contrastar el procedimiento con expedientes terminados y asignar a cada paso o rama una disposición explícita: eliminar, estandarizar, aclarar o conservar para revisión humana. Antes de configurar reglas, robots o inteligencia artificial, también deben quedar definidos el responsable de cada desvío, la evidencia que permite avanzar, las condiciones de aceptación y las decisiones que requieren autoridad, criterio especializado o independencia.

¿Qué debe mostrar el mapa del estado actual antes de automatizar?

El mapa debe mostrar cómo un tipo de caso pasa desde un disparador observable hasta un resultado aceptado por un usuario posterior, sin anticipar todavía una plataforma. Delimita un solo tipo de solicitud, un inicio, un final aceptable y las áreas comprendidas. Para cada paso, registra su propósito, el rol que lo ejecuta, la entrada y su fuente, la regla o acción, la salida, el canal utilizado, la evidencia de término, el siguiente responsable y la condición que este debe aceptar. Esa vista independiente de la solución permite discutir el trabajo antes de convertirlo en configuración.

• Propósito del paso, disparador y rol responsable.
• Entrada, fuente, regla aplicada y salida esperada.
• Sistema o canal, tiempo de atención y tiempo de espera.
• Evidencia de término, siguiente responsable y condición de aceptación.

El procedimiento es una fuente, no una fotografía completa de la operación. Contrástalo con casos rutinarios, incompletos, rechazados y retrabajados; formularios; registros de soporte; hallazgos de control; recorridos con quienes envían y reciben; y datos de eventos cuando existan. Mantén separado el tiempo de atención del tiempo total en cola. Un registro con identificador de caso, actividad y marca de tiempo puede reconstruir una secuencia, pero no demuestra que la cobertura sea completa ni explica por sí mismo la causa de una demora. Valida calidad, periodos ausentes y trabajo realizado por canales paralelos.

¿Qué desvíos son variantes normales y cuáles son excepciones reales?

Una variante normal tiene criterios de entrada, pasos, responsable, evidencia y resultado suficientemente estables; una excepción real necesita una decisión o recuperación fuera de esa ruta definida. La frecuencia no basta para distinguirlas. Un caso recurrente puede seguir siendo una excepción de autoridad, mientras una variación legítima puede pasar a una rama estándar. BPMN permite dibujar compuertas, temporizadores, errores y escalaciones, pero la notación no decide el tratamiento comercial u operativo. Para evitar una cola genérica, clasifica primero el desvío según el problema observable.

• Entrada incompleta o inválida: falta información, evidencia, formato o un requisito previo.
• Variación conocida del negocio: el caso legítimo sigue otra ruta estable y delimitada.
• Excepción de política o autoridad: la acción excede una regla, delegación o tolerancia.
• Falla de capacidad, dependencia o plazo: el trabajo no puede avanzar dentro de la expectativa local.
• Falla técnica: una integración rechaza, duplica, interrumpe o deja el caso en estado incierto.

El registro debe describir el disparador observable, casos representativos, frecuencia durante un periodo indicado cuando se conozca, consecuencia, respuesta segura, responsable de recuperación, límite delegado, evidencia requerida y resultado documentado. Añade la posible fuente de recurrencia: entrada, regla, capacidad, política, ruta normal o sistema. Un volumen alto puede revelar datos inestables, una ruta normal demasiado estrecha o trabajo genuinamente variable; uno bajo puede ocultar correos y arreglos no registrados. Ambos son señales para revisar expedientes, no veredictos. La rama estandarizada debe permanecer revisable cuando cambien las condiciones.

¿Cuándo vale la pena conservar una aprobación?

Una aprobación merece conservarse cuando produce una decisión distinta, respaldada por un propósito de control y ejercida dentro de una autoridad definida. Nombra primero la decisión y sus posibles resultados: aprobar, rechazar, devolver, imponer una condición o escalar. Si la persona no puede cambiar el siguiente estado, quizá el paso sea una notificación, consulta, constancia o producción de evidencia. Después identifica el riesgo, la política o el compromiso de recursos que se controla, la atribución del aprobador y cualquier competencia, independencia o separación de funciones requerida por la organización.

• Decisión exacta y propósito operativo o de control.
• Rol aprobador, autoridad delegada y límites.
• Competencia o independencia que el caso requiere.
• Evidencia disponible y criterios aplicables al decidir.
• Resultados posibles, sustento registrado y efecto posterior.
• Coincidencia con otros controles que revisan el mismo riesgo.

Compara las puertas que observan la misma evidencia para la misma decisión y riesgo, pero no retires un control solo porque demora o parece repetido en el diagrama. Documenta qué aporta cada revisión y valida la modificación con las funciones internas autorizadas. Los controles manuales, parcialmente automatizados y automatizados pueden coexistir; ninguno es efectivo por el solo hecho de incluir o excluir a una persona. En flujos con inteligencia artificial, la revisión humana necesita una tarea real, información suficiente, límites del sistema, responsabilidad y resultados utilizables. La presencia humana sin autoridad, criterio ni registro solo agrega una pausa.

¿Cuándo se considera completo un traspaso entre áreas?

Un traspaso queda completo cuando un receptor identificado acepta que el caso contiene la información y evidencia necesarias para iniciar la siguiente acción. Enviar un correo, reenviar una carpeta o colocar trabajo en una cola no demuestra transferencia de responsabilidad. Para cada traspaso retenido, define la identidad y el estado del caso, el rol remitente, el responsable receptor, los documentos requeridos, la prueba de que el paso anterior terminó, los criterios de aceptación y la acción esperada. La obligación debe pasar a una persona o rol reconocible, no a un buzón sin dueño.

• Identidad y estado vigente del caso.
• Remitente, receptor y evidencia de término previo.
• Información, anexos y criterios de aceptación.
• Siguiente acción y expectativa de servicio elegida localmente.
• Ruta para trabajo incompleto, disputado, vencido o mal dirigido.
• Momento y ubicación durable de la aceptación.

Mide desde que el caso queda listo para transferirse hasta que el receptor acepta la responsabilidad, por separado del tiempo que alguien trabaja activamente. Observa devoluciones por información faltante, cambios de dueño, antigüedad del trabajo no aceptado, incumplimientos de la expectativa local, retrabajo respaldado por evidencia y terminaciones fuera del sistema. Esas medidas ayudan a ubicar la fricción, pero no explican solas su causa. El registro del traspaso permite reconstruir quién recibió qué y cuándo; no prueba que la decisión anterior fuera correcta ni que el control asociado haya funcionado como se esperaba.

¿Cómo se debe rediseñar cada elemento del flujo?

Cada elemento debe recibir exactamente una disposición: eliminar, estandarizar, aclarar o conservar para revisión humana. Estas categorías son una síntesis editorial de mejora del flujo, trabajo estandarizado, gobierno explícito, controles basados en riesgo y supervisión humana; no constituyen un método prescrito por una sola autoridad. La decisión se toma con los casos y documentos reunidos, no según la apariencia del diagrama. Así se evita reducir el rediseño a una elección imprecisa entre automatizar todo o enviar cualquier dificultad a una persona de mayor jerarquía.

• Eliminar: no produce una decisión distinta, valor operativo, información necesaria ni mitigación de un riesgo que no esté cubierta en otro punto.
• Estandarizar: las entradas pueden validarse, las reglas y resultados permitidos son estables, la ambigüedad es baja y existe un responsable constante.
• Aclarar: el elemento es necesario, pero su dueño, autoridad, criterio, evidencia, término, escalamiento o recuperación sigue siendo ambiguo.
• Conservar para revisión humana: requiere autoridad delegada, criterio contextual, conocimiento calificado, independencia o resolución de un caso todavía no delimitado.

En una solicitud interna para contratar un nuevo servicio empresarial, podría eliminarse una firma que solo confirma la existencia del pedido, siempre que no autorice recursos ni controle un riesgo. La organización puede estandarizar la recepción, la identidad del caso, los datos obligatorios, la verificación de duplicados y la ruta normal. Debe aclarar quién devuelve solicitudes incompletas, quién resuelve cada variante y qué constituye una entrega aceptada al equipo ejecutor. Puede conservar la aprobación presupuestal autorizada, una revisión especializada o independiente activada por el riesgo y la decisión sobre una excepción de política. Los requisitos exactos dependen de las obligaciones y delegaciones de cada organización.

No automatices un diagrama heredado: rediseña las decisiones, evidencias, excepciones y responsabilidades que sostienen el flujo.

¿Qué demuestra que el flujo está listo para implementarse?

El flujo está listo solo cuando puede emitirse una decisión condicionada de avanzar, revisar o detenerse con base en propietarios, evidencia, controles y recuperación definidos. Un mapa visible no es todavía una especificación ejecutable. Recorre el diseño propuesto con casos rutinarios, incompletos, rechazados, limítrofes, vencidos, anulados, retrabajados y afectados por fallas técnicas, comparándolos con registros cuando estén disponibles. La prueba no busca que todos terminen por la ruta feliz; busca confirmar que cada salida tiene un estado seguro, un responsable autorizado, evidencia suficiente y una forma durable de registrar el resultado.

• Cada excepción tiene disparador observable, respuesta segura, responsable, evidencia y resultado registrado.
• Cada aprobación produce una decisión distinta dentro de una autoridad definida.
• Cada traspaso tiene receptor, criterios de aceptación y ruta para trabajo incompleto.
• Todo control retirado conserva una justificación y la revisión interna apropiada.
• Permisos, revisiones manuales, reintentos, prevención de duplicados y conciliación están especificados según el riesgo.
• Las métricas y su responsable permiten investigar devoluciones, anulaciones, colas, defectos y canales paralelos.
• Los límites, responsabilidades y tolerancia al riesgo están documentados cuando se usa inteligencia artificial.

Después del lanzamiento, las excepciones repetidas, devoluciones, anulaciones y colas crecientes deben activar investigación, no una solución automática predeterminada. Asigna responsables de monitoreo y cambio para que la evidencia pueda modificar la ruta estándar. Antes de alterar un control o interpretar una obligación, consulta a las funciones legales, regulatorias, financieras, de seguridad, privacidad, compras, recursos humanos, control interno u otras que estén calificadas y autorizadas dentro de la organización. Si persisten dudas materiales sobre política, delegación, independencia, aceptación de riesgo, evidencia o juicio profesional, detén la implementación y resuélvelas. Codificar esa ambigüedad convertiría una pregunta de gobierno pendiente en comportamiento repetible del sistema.