Una excepción recurrente es un segundo proceso que nadie ha diseñado

Una excepción que aparece todas las semanas ya no es una excepción. Muchas operaciones mantienen un proceso “oficial” y, alrededor de él, una colección de favores, atajos y aprobaciones especiales que se resuelven por chat. Cada caso parece pequeño: un cliente que necesita otra fecha, una factura que usa un formato distinto, una publicación que requiere una revisión adicional. El problema aparece cuando esas desviaciones se repiten. En ese momento existe un segundo proceso, solo que nadie lo ha dibujado, nadie ha definido quién lo opera y nadie mide cuánto tiempo consume.

La recurrencia convierte el parche en una ruta real de trabajo. Si una excepción tiene un disparador reconocible y una respuesta que el equipo repite, ya contiene los elementos mínimos de un proceso: entrada, decisión, responsable, acción y salida. Mantenerlo fuera del diseño formal crea fricción porque cada persona debe reconstruir la lógica desde memoria. La pregunta útil no es “¿por qué otra vez hicieron una excepción?”, sino “¿qué condición provoca esta ruta y con qué frecuencia ocurre?”. Contar eventos durante varias semanas suele revelar qué casos merecen una política explícita y cuáles son verdaderamente raros.

El costo escondido está en la coordinación, no solo en la tarea adicional. Una excepción suele implicar preguntar quién puede autorizarla, buscar antecedentes, verificar si ya ocurrió algo parecido y explicar al siguiente responsable por qué se cambió la regla. Ese tiempo de contexto raramente aparece en el costo del servicio. Además, dos personas pueden resolver el mismo caso de forma distinta porque la lógica nunca fue acordada. El resultado es una operación donde la experiencia depende de quién estaba conectado ese día, una señal clara de que el sistema está transfiriendo decisiones repetitivas a memoria humana.

Antes de formalizar, conviene separar tres tipos de excepción. La primera es temporal: existe por una transición y debería desaparecer en una fecha definida. La segunda es legítima y recurrente: corresponde a un segmento, canal o condición que necesita una ruta propia. La tercera es un síntoma de que la regla principal está mal diseñada y obliga a demasiados casos a salir del camino. Clasificar evita automatizar un parche equivocado. Si el problema está en la regla base, crear una segunda ruta puede añadir complejidad sin resolver la causa que genera las desviaciones.

Una ruta secundaria necesita límites tan claros como la principal. Si se decide conservarla, hay que definir qué condición permite entrar, quién aprueba, qué datos son obligatorios, qué cambia respecto al proceso normal y cómo se cierra. También necesita una forma de rastreo para saber cuántos casos pasan por allí. Sin ese contador, la excepción puede crecer silenciosamente hasta convertirse en la manera dominante de trabajar. Una buena señal de control es poder responder, sin buscar conversaciones antiguas, qué porcentaje de casos usó la ruta especial y por qué.

La automatización debe llegar después de estabilizar la decisión. Automatizar una excepción mal entendida convierte una improvisación humana en improvisación rápida y repetible. Primero se documentan disparadores y resultados; luego se revisan casos donde las personas discrepan; finalmente se codifica lo que ya tiene suficiente consistencia. Algunas rutas deben quedarse con aprobación humana porque implican riesgo, dinero o compromisos contractuales. La meta no es eliminar toda flexibilidad, sino hacer visible cuándo se usa, quién tiene autoridad y qué evidencia justifica apartarse del procedimiento normal.

La regla editorial es simple: toda excepción recurrente debe ganarse un nombre o desaparecer. Ponerle nombre obliga a reconocer que existe y abre una conversación sobre diseño. El equipo puede decidir integrarla al proceso principal, convertirla en una variante formal o eliminar la condición que la provoca. Lo peligroso es mantenerla indefinidamente como “caso especial”, porque esa etiqueta evita medirla. Cuando las rutas reales coinciden con las rutas documentadas, el negocio depende menos de héroes que recuerdan trucos y más de un sistema que puede explicarse, mejorarse y delegarse.