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

Antes de automatizar, hay que reconstruir cómo avanza de verdad un caso, no cómo supone el procedimiento que debería avanzar. Un pedido que llega por correo, se vuelve a cargar, recoge una firma sin efecto y rebota por falta de evidencia contiene incertidumbre operativa; un bot solamente la trasladaría más rápido. El trabajo previo consiste en delimitar el recorrido, verificarlo con casos, distinguir variantes de excepciones, probar cada aprobación y establecer cuándo un traspaso fue aceptado. Después, cada elemento recibe una sola disposición: eliminar, estandarizar, aclarar o conservar para revisión humana.

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

El mapa debe mostrar cómo un tipo de caso acotado pasa de un disparador observable a un resultado que alguien aguas abajo acepta. Elegí primero un pedido recurrente, un punto inicial, una condición final y el usuario del resultado. Documentá el proceso sin anticipar una plataforma: así quedan visibles los actores, decisiones, tareas y límites antes de que las opciones técnicas condicionen la conversación. Ampliá el borde únicamente si una dependencia observada explica materialmente lo que ocurre.

• Para cada paso: propósito, rol, entrada y origen, regla o acción, salida, canal, evidencia de cierre, próximo responsable y condición de aceptación.
• Por separado: tiempo de trabajo efectivo y tiempo de espera o cola, sin atribuir una causa que los registros no demuestren.
• Como contraste: procedimientos, formularios, casos completos, devoluciones, entrevistas de recorrido, hallazgos de auditoría y datos de eventos disponibles.

La evidencia escrita y la secuencia registrada se complementan, pero no son equivalentes. Un procedimiento describe la intención; un caso terminado revela pasos, retornos y canales que pudieron quedar fuera. Si hay datos de eventos, vinculá por lo menos identidad de caso, actividad y marca temporal, y validá cobertura y calidad antes de concluir. Las marcas permiten reconstruir orden y tiempo transcurrido, pero no explican por sí mismas si la demora provino de trabajo, espera, dependencia o una decisión pendiente.

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

Una desviación es una variante estándar cuando representa trabajo legítimo y repetible con criterios de entrada, recorrido, responsable, evidencia y resultado estables; de lo contrario, debe permanecer como excepción hasta entenderla. La frecuencia ayuda a investigar, pero no decide la clasificación. Un volumen alto puede esconder entradas inestables, reglas confusas o un recorrido normal demasiado estrecho. Un volumen bajo también puede engañar si las personas resuelven casos por mensajes privados o los registran con otra categoría.

• Entrada incompleta o inválida: faltan datos, evidencia, formato o un requisito previo.
• Variación de negocio conocida: existe una ruta alternativa legítima y estable.
• Excepción de política o autoridad: la solicitud excede una regla, delegación o tolerancia.
• Falla de capacidad, dependencia o plazo: el caso no puede avanzar dentro de la expectativa local.
• Falla técnica: una integración rechaza, duplica, interrumpe o deja el estado incierto.

El registro de excepciones debe capturar un disparador observable, casos representativos, frecuencia dentro de un período declarado cuando se conozca, consecuencia, respuesta segura, responsable de recuperación, límite delegado, evidencia requerida y resultado durable. BPMN puede volver visibles ramas, temporizadores, errores y escalaciones, pero la notación no decide el tratamiento comercial. Si una variación pasa al recorrido estándar, documentala como una base revisable: el cambio de condiciones puede exigir reclasificarla o devolverla a revisión.

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

Una aprobación merece conservarse cuando produce una decisión distinta, dentro de una autoridad definida, y modifica lo que puede ocurrir después. Nombrá sus resultados posibles: aprobar, rechazar, devolver, imponer una condición o escalar. Si la persona no puede cambiar el próximo estado, quizá el paso sea una notificación, una consulta, una constancia o la producción de evidencia. Esa distinción evita llamar control a una firma que solamente confirma que el caso existe.

• Decisión exacta y propósito de riesgo, política, recurso o control.
• Rol aprobador, delegación, competencia e independencia necesarias.
• Evidencia disponible, criterios aplicables y margen de discreción permitido.
• Identidad, momento, fundamento o condición y efecto sobre el estado siguiente.
• Superposición con otro control que examine la misma evidencia, decisión y riesgo.

No elimines un control porque demora ni lo conserves porque siempre estuvo. Compará propósito, autoridad y evidencia, y obtené la revisión interna apropiada antes de modificarlo. Los controles manuales, parcialmente automatizados y automatizados pueden coexistir; el modo de ejecución no garantiza eficacia. Si el flujo usa inteligencia artificial, documentá además el contexto, los límites del sistema, la tolerancia al riesgo, quién supervisa y cómo se usarán sus resultados. La revisión humana solo agrega valor si tiene decisión, competencia, información y consecuencias reales.

¿Cuándo está realmente completo un traspaso?

Un traspaso está completo cuando un receptor identificado acepta un caso suficientemente documentado y puede iniciar la acción siguiente. Enviar un correo, mover una tarjeta o colocar trabajo en una cola demuestra emisión, no transferencia de responsabilidad. Para cada traspaso retenido, definí identidad y estado del caso, rol emisor, dueño receptor, información y adjuntos obligatorios, evidencia de que el paso previo terminó, criterios de aceptación y acción esperada. Agregá una expectativa de servicio elegida localmente, no un plazo universal.

• Ruta para trabajo incompleto, discutido, vencido o dirigido al equipo equivocado.
• Registro durable de quién aceptó, cuándo lo hizo y en qué estado quedó el caso.
• Tiempo desde listo para transferir hasta aceptación, separado del tiempo de trabajo.
• Devoluciones por información insuficiente, cambios de dueño, antigüedad sin aceptar y saltos entre colas.
• Reprocesos atribuibles a evidencia faltante y casos cerrados fuera del recorrido, solo cuando los registros permiten sostenerlo.

Este contrato de traspaso es una síntesis práctica de flujo, información, responsabilidad y documentación; ninguna notación lo completa automáticamente. El registro permite examinar hechos importantes y reconstruir responsabilidades, aunque no demuestra que una decisión haya sido correcta ni que un control funcionara bien. Su valor operativo es más modesto y concreto: evita que el receptor tenga que reconstruir el caso, hace visible el trabajo sin dueño y entrega una base común para investigar devoluciones, esperas y desvíos laterales.

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

Cada paso o rama se rediseña asignándole exactamente una de cuatro disposiciones: eliminar, estandarizar, aclarar o conservar para revisión humana. Las categorías son una síntesis editorial de mejora del flujo completo, trabajo estandarizado, gobernanza explícita, controles basados en riesgo y supervisión humana; ninguna fuente las prescribe juntas. Obligar a elegir una evita el cómodo “automatizar o escalar” y revela qué falta resolver. La justificación debe apoyarse en propósito, evidencia, autoridad, variabilidad y consecuencia, no en preferencia tecnológica.

En un pedido interno de contratación de un servicio empresarial, por ejemplo, podría eliminarse la firma de un gerente que no decide recursos ni riesgos; estandarizarse el ingreso, la identidad del caso y el enrutamiento normal; aclararse quién resuelve información incompleta y quién acepta el traspaso; y conservarse la autorización presupuestal o la revisión especialista que exija el riesgo evaluado. Es un ejemplo adaptable, no un diseño universal: las aprobaciones, delegaciones y evidencias dependen de la política y las obligaciones de cada organización.

No automatices un diagrama heredado: rediseñá las decisiones, evidencias, excepciones y responsabilidades que vuelven real al flujo.

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

El flujo está listo únicamente cuando casos representativos pueden atravesar el diseño con dueños, evidencia, decisiones, aceptación y recuperación definidas. Un mapa descriptivo no alcanza: un modelo orientado a documentación puede no contener el detalle formal requerido para ejecutar. Recorré casos normales, incompletos, rechazados, limítrofes, vencidos, anulados, reprocesados y fallidos contra registros disponibles. Para cada excepción exigí disparador, respuesta segura, responsable y resultado; para cada aprobación, decisión y autoridad; para cada traspaso, receptor, suficiencia y ruta de devolución.

• Documentar por qué se retira un control y obtener la revisión interna autorizada que corresponda.
• Especificar permisos, disparadores de revisión manual, reintentos seguros, prevención de duplicados, conciliación y recuperación.
• Asignar indicadores y un responsable de revisarlos después del lanzamiento.
• Investigar devoluciones, excepciones repetidas, anulaciones, colas crecientes, defectos y canales laterales sin asumir una única causa.
• Decidir entre avanzar, revisar el diseño o detener la implementación según la evidencia pendiente.

La decisión debe ser condicional. Antes de cambiar un control o interpretar una obligación, consultá a los roles calificados y autorizados de control interno, legales, regulatorios, financieros, seguridad, privacidad, compras, recursos humanos o seguridad laboral que correspondan. Si la automatización incorpora inteligencia artificial, el contexto, los límites, la supervisión y la tolerancia al riesgo también deben formar parte del avance. Cuando persistan dudas materiales sobre política, delegación, independencia, aceptación de riesgo, evidencia o juicio profesional, detené la implementación y resolvelas en lugar de codificar la ambigüedad.