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 decidir qué función cumple cada paso. Una solicitud que llega por correo, se copia en otro sistema, obtiene una firma sin efecto y rebota por falta de datos no mejora porque circule más deprisa. El equipo debe acotar un caso recurrente, contrastar el procedimiento con expedientes terminados y asignar a cada paso o rama una sola disposición: eliminar, estandarizar, aclarar o conservar para revisión humana. Así se evita convertir incertidumbres, controles mal definidos y traspasos incompletos en reglas difíciles de corregir.

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

El mapa debe mostrar cómo un tipo de caso pasa de un desencadenante observable a un resultado aceptado por su destinatario. Empieza con un solo tipo de solicitud, un inicio, una condición de cierre y un usuario posterior; amplía el límite únicamente si una dependencia explica materialmente el resultado. Una documentación que no presuponga la solución puede hacer visibles actores, decisiones, tareas y puntos de inicio y final antes de elegir tecnología. El análisis del estado actual debe preceder al diseño futuro y apoyarse en evidencias del escenario acotado.

Para cada paso, anota su finalidad, el rol que lo ejecuta, la entrada y su origen, la regla o acción, la salida, el canal, la evidencia de terminación, el siguiente responsable y su condición de aceptación. Mantén separados el tiempo de trabajo y el tiempo total: el mapeo del flujo de valor distingue ambos conceptos y registra también información y trabajo completo y correcto. Contrasta el procedimiento con expedientes rutinarios, incompletos, rechazados, retrasados y rehechos; una instrucción describe lo previsto, mientras que un expediente muestra una ejecución concreta.

• Revisa formularios, plantillas, registros de soporte, hallazgos de auditoría y devoluciones del destinatario.
• Usa observaciones y recorridos de casos recientes con quienes envían, reciben, deciden y recuperan el trabajo.
• Si analizas eventos, conserva al menos identificador del caso, actividad y marca temporal, y valida por separado cobertura y calidad.
• No atribuyas la causa de una espera a una marca temporal: esta acredita secuencia y duración, no el motivo del retraso.

¿Qué desviaciones son variantes estándar y cuáles son excepciones reales?

Una desviación es una variante estándar cuando responde a una situación legítima, repetible y delimitada; es una excepción real cuando exige recuperación, autoridad o juicio fuera del recorrido estable. BPMN puede representar pasarelas, mensajes, temporizadores, errores y escalados, pero el dibujo no decide el tratamiento empresarial. Una variación recurrente puede pasar al recorrido estándar si tiene criterios de entrada, pasos, responsable, evidencias y resultado estables. La frecuencia por sí sola no basta: un caso habitual puede seguir siendo materialmente incierto o requerir una autoridad específica.

Sustituye la cola genérica por un registro que permita diagnosticar cada familia. Anota el desencadenante observable, ejemplos, frecuencia durante un periodo indicado cuando se conozca, consecuencia, respuesta segura, responsable de recuperación, límite delegado, evidencias necesarias y resultado registrado. El trabajo estandarizado ofrece una secuencia explícita y revisable, no una regla permanente. Por eso una rama normalizada debe cambiar cuando cambien sus entradas, condiciones o riesgos, y una excepción rara debe conservar atención si su consecuencia o recuperación son relevantes.

• Entrada incompleta o inválida: prevenir mediante requisitos claros o devolver al responsable indicando qué falta.
• Variación de negocio conocida: crear una rama estable cuando su contrato operativo esté definido.
• Excepción de política o autoridad: remitirla a quien pueda decidir dentro de un límite delegado.
• Fallo de capacidad, dependencia o plazo: definir propiedad de la cola, alternativa y siguiente acción.
• Fallo técnico: especificar reintento seguro, prevención de duplicados, conciliación, recuperación manual y condición de parada.

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

Una aprobación merece conservarse cuando produce una decisión distinta y respaldada que modifica el estado siguiente. Define si puede aprobar, rechazar, devolver, imponer condiciones o escalar; si la persona no puede cambiar nada, quizá se trate de una notificación, una consulta o un acuse. Relaciona la decisión con un riesgo, una política, un recurso o un objetivo de control. Los controles deben ajustarse a los objetivos, riesgos evaluados, entorno, complejidad y sensibilidad de los datos, no a una preferencia general por añadir o quitar firmas.

Registra la autoridad delegada, competencia o independencia exigida, evidencias disponibles, criterios, discreción permitida, identidad, momento, motivación y efecto posterior. La autorización corresponde a personas que actúan dentro de su autoridad; una segregación adecuada puede separar autorización, tramitación, registro y revisión. Compara dos puertas que examinan las mismas pruebas para la misma decisión, pero no elimines una porque tarde o parezca duplicada en el diagrama. Antes hay que confirmar sus obligaciones, dependencias y el riesgo que cubre otro control retenido.

• Comprueba que exista una decisión definida, no una presencia humana decorativa.
• Entrega al decisor evidencia pertinente y suficiente para aplicar el criterio correspondiente.
• Mantén separadas la opinión especialista, la autorización de gestión y la revisión independiente cuando el riesgo lo requiera.
• Permite que convivan controles manuales, parciales y automáticos; automatizar no demuestra eficacia.
• Si interviene IA, documenta funciones, límites, supervisión, contexto, tolerancia al riesgo y uso humano de sus resultados.

¿Cuándo puede darse por terminado un traspaso?

Un traspaso termina cuando un receptor identificado acepta un caso completo y puede iniciar la siguiente acción; enviar un correo o colocarlo en una cola no acredita ese resultado. BPMN distingue participantes y flujos de mensajes, pero la transferencia operativa necesita un contrato más concreto. Identifica el caso y su estado, remitente, receptor, información y anexos, evidencia de que el paso anterior terminó, criterios de aceptación, siguiente acción y ruta para trabajo incompleto, disputado, mal dirigido o no aceptado.

Añade una expectativa de servicio elegida localmente y registra la aceptación en un lugar duradero. Mide desde que el caso está listo hasta que alguien asume su propiedad, sin mezclar esa espera con el tiempo de trabajo. Observa devoluciones por datos incompletos, cambios de responsable, antigüedad del trabajo sin aceptar, incumplimientos de la expectativa local, reprocesos demostrablemente vinculados al traspaso y casos resueltos por canales laterales. Ninguna cifra aislada dicta la solución: sirve para seleccionar expedientes y averiguar qué contrato está fallando.

La traza debe permitir reconstruir quién transfirió, quién aceptó, con qué evidencias, en qué estado y qué debía ocurrir después. Esa documentación facilita examinar hechos significativos y la ejecución de un control, pero no demuestra que la decisión fuese correcta ni que el control resultase eficaz. Si el receptor devuelve el caso, el motivo y la nueva propiedad deben quedar visibles; si lo acepta, la responsabilidad posterior debe cambiar de forma inequívoca, sin depender de conversaciones privadas o del seguimiento personal del remitente.

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

Cada elemento debe recibir exactamente una de estas disposiciones: eliminar, estandarizar, aclarar o conservar para revisión humana. Es una síntesis editorial de mejora del flujo, trabajo estandarizado, gobierno explícito, control basado en riesgo y supervisión humana; ninguna fuente citada prescribe estas cuatro etiquetas como método único. La clasificación obliga a expresar una razón verificable. Evita la categoría imprecisa «automatizar o escalar», porque oculta si falta una regla, una autoridad, evidencia suficiente o una decisión que nunca debió existir.

En una solicitud interna de un nuevo servicio de terceros, por ejemplo, podría eliminarse una firma que solo confirma que la petición existe, siempre que no autorice recursos ni mitigue un riesgo distinto. Se estandarizarían la identificación del caso, los campos obligatorios, la detección de duplicados y el enrutamiento normal. Se aclararían la propiedad de solicitudes incompletas, excepciones y traspasos. Se conservarían las decisiones presupuestarias, especialistas, independientes o de excepción de política cuando los requisitos de la organización las exijan. El ejemplo es adaptable y no fija aprobaciones universales.

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

La estandarización crea una referencia explícita para la consistencia y la mejora, no la prueba de que todo deba pasar por el camino normal. Del mismo modo, conservar una persona no garantiza seguridad o corrección. Elige controles preventivos y detectivos según contexto, probabilidad, impacto y riesgo evaluado, sin asumir que lo automático siempre supera a lo manual. Si se propone retirar un control, documenta la finalidad analizada, el riesgo, la cobertura alternativa y la revisión interna autorizada que corresponda.

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

El flujo está listo únicamente si supera una decisión condicional de continuar, revisar o detener, basada en propietarios, evidencias, controles y recuperación observables. Un modelo concebido para documentar puede no ser ejecutable, de modo que el mapa visible no constituye por sí solo una especificación de implementación. Recorre el diseño propuesto con casos representativos: rutinarios, incompletos, rechazados, cercanos a un límite, caducados, anulados, rehechos y afectados por fallos técnicos. Compáralos con registros reales cuando existan y documenta las diferencias.

• Cada excepción tiene desencadenante, respuesta segura, responsable, evidencias y resultado registrado.
• Cada aprobación contiene una decisión distinta, finalidad, autoridad, criterios, resultados y efecto posterior.
• Cada traspaso identifica receptor, suficiencia, aceptación y ruta para trabajo incompleto o no aceptado.
• Los controles eliminados cuentan con motivación y revisión apropiadas; los retenidos preservan su finalidad.
• Permisos, revisión manual, reintentos, duplicados, conciliación, supervisión y propiedad del cambio se diseñan en proporción al riesgo.
• Un responsable revisará devoluciones, excepciones repetidas, anulaciones, colas, defectos y canales laterales tras el lanzamiento.

Continúa cuando los elementos retenidos tengan responsables, decisiones, evidencias, condiciones de aceptación, recuperación y seguimiento proporcionado. Revisa el diseño si las pruebas revelan rutas sin dueño o criterios que aún pueden delimitarse. Detén la implementación si siguen abiertas cuestiones materiales de política, delegación, independencia, aceptación de riesgo, suficiencia de evidencias o juicio profesional. Antes de modificar controles o interpretar obligaciones, consulta a las funciones cualificadas y autorizadas de control interno, asesoría jurídica, privacidad, seguridad, finanzas, compras, recursos humanos u otras áreas afectadas. Codificar una duda no la convierte en regla.