Escalar automatización sin uniformar el proceso: gobierne las excepciones

Una empresa escala automatizaciones cuando todas las excepciones llegan con un código, evidencia y dueño comunes, aunque cada proceso conserve un camino feliz distinto. La tesis se puede probar: si dos equipos llaman “error” a eventos incompatibles y aplican el mismo reintento, la escala ya está produciendo duplicados, colas silenciosas o acciones incorrectas.

El camino feliz no es el contrato común

Una orden de compra, un embarque y una alta de proveedor no comparten las mismas reglas, datos ni consecuencias. Forzarlos a una plantilla idéntica elimina contexto útil y crea condiciones especiales ocultas. Sin embargo, todos deben responder de forma comparable cuando faltan datos, vence una dependencia, se viola una política o una decisión resulta ambigua.

La estandarización valiosa comienza donde el flujo deja de avanzar normalmente. Ahí operaciones necesita saber qué ocurrió, si es seguro reintentar, qué objeto fue afectado, quién puede resolverlo y cuándo escalar. Esa envoltura común permite medir y mejorar sin convertir procesos distintos en copias.

Una taxonomía de seis familias

La especificación BPMN 2.0 de OMG ofrece una notación común y distingue eventos como error, escalamiento, temporizador y compensación. No dicta esta taxonomía empresarial, pero demuestra por qué “falló” es insuficiente: diferentes eventos requieren diferentes continuaciones.

Use seis familias mutuamente excluyentes en el nivel superior:

1. DATA_INVALID. Falta un campo, el formato es inválido, la fuente está vencida o dos fuentes se contradicen.
2. POLICY_BLOCK. Una regla, límite, permiso o aprobación impide continuar. Reintentar sin cambio de política es incorrecto.
3. DEPENDENCY_TRANSIENT. Red, servicio o recurso temporalmente no disponible; puede admitir reintento acotado.
4. BUSINESS_NOT_FOUND. El objeto o relación esperada no existe: orden, contrato, cuenta o contraparte.
5. AMBIGUOUS_DECISION. Hay evidencia válida pero insuficiente para escoger una acción dentro del nivel de confianza acordado.
6. INTEGRITY_OR_SECURITY. Posible duplicado dañino, manipulación, acceso indebido o inconsistencia que exige contención.

Los códigos de dominio viven debajo: por ejemplo, DATA_INVALID.VENDOR_TAX_ID o BUSINESS_NOT_FOUND.PURCHASE_ORDER. El prefijo permite comparar portafolios; el sufijo conserva significado local.

El sobre de excepción mínimo

Una excepción debe ser un objeto operativo, no una cadena libre en un log.

Campo	Propósito
exception_id	Evita dobles cierres y permite referencias estables
occurred_at y detected_at	Separa origen de latencia de detección
business_object_type/id	Identifica factura, orden, envío o solicitud
automation_id/version	Ubica el flujo y artefacto exactos
reason_code/subcode	Activa política y análisis comparables
retryable y attempt	Impide reintentos infinitos o inseguros
evidence_refs	Enlaza entradas, salidas y eventos permitidos
owner_queue y due_at	Define responsabilidad y reloj
resolution_code	Registra cómo terminó sin borrar el incidente

Evite copiar datos personales o documentos completos al sobre. Use referencias con permisos y retención definidos.

Matriz de ruta: el código debe cambiar el comportamiento

Familia	Respuesta predeterminada	Quién resuelve	Cierre aceptable
DATA_INVALID	detener objeto, pedir o reconciliar dato	custodio del dato	corregido, fuente cambiada o descartado
POLICY_BLOCK	no reintentar	dueño de política/aprobador	autorizado, regla actualizada o rechazado
DEPENDENCY_TRANSIENT	reintento con límite y espera	equipo técnico si agota	recuperado o degradado
BUSINESS_NOT_FOUND	buscar relación o crear caso	operación del proceso	vinculado, creado o cancelado
AMBIGUOUS_DECISION	entregar evidencia a revisor	experto del dominio	decisión humana y razón
INTEGRITY_OR_SECURITY	pausar y contener	seguridad/control	liberado, bloqueado o investigado

La documentación de manejo de errores de AWS Step Functions separa errores reintentables, terminales, timeouts y rutas Catch. La lección portable es que Retry no es sinónimo de tratamiento: debe aplicarse a códigos explícitos, con máximo y salida alternativa.

El ciclo operativo: detectar, contener, resolver, aprender

La taxonomía solo crea valor si alimenta un ciclo. Primero detecte y preserve el objeto afectado. Después contenga la consecuencia: pause esa instancia, no todo el portafolio salvo riesgo común. Enrute con evidencia suficiente. Finalmente cierre con un código de resolución y revise recurrencia.

NIST publicó en 2025 la SP 800-61 Rev. 3, que integra preparación, detección, respuesta, recuperación y mejora del manejo de incidentes en la gestión de riesgo. Una excepción de negocio no es necesariamente un incidente de ciberseguridad, pero el ciclo disciplinado es aplicable: prepararse antes del evento, reducir impacto y aprender después.

Revise semanalmente familias y mensualmente subcódigos. Una subida en DEPENDENCY_TRANSIENT puede requerir ingeniería; DATA_INVALID recurrente, control en la fuente; AMBIGUOUS_DECISION, mejores reglas o datos. No premie a un equipo por cerrar rápido si solo reclasifica o descarta.

Cómo instrumentarlo en Quantum

En Quantum Automation Center, cada excepción puede vincularse con el objeto de negocio, la ejecución y su línea de tiempo. El estado muestra si continúa abierta; artefactos y logs aportan evidencia; la cola y los permisos asignan quién puede resolver; y las analíticas permiten observar familias, edad y recurrencia. La ontología de Quantum ayuda a mantener identidad del objeto entre agentes y automatizaciones.

No convierta el catálogo en otra base de mensajes libres. Haga obligatorios familia, subcódigo, objeto, dueño y resolución para que diferentes motores reporten al mismo contrato.

El contrapunto: las excepciones reales son demasiado particulares

Lo son en el detalle. Un rechazo aduanero y una cuenta bancaria inexistente no deberían compartir un runbook. El error consiste en concluir que tampoco pueden compartir familia, reloj, evidencia o estado. Sin ese nivel común, la dirección no puede distinguir mala calidad de datos de fallos técnicos, y operaciones no sabe dónde invertir.

Permita subcódigos locales y campos de contexto versionados. Cree una categoría nueva solo cuando la respuesta predeterminada, el dueño y el criterio de cierre sean realmente distintos. Si únicamente cambia el mensaje para el usuario, probablemente sigue siendo el mismo tipo.

Cuándo no usar una taxonomía corporativa

No se justifica una taxonomía compleja para un flujo único, de bajo volumen y un solo responsable. Un registro pequeño con tipos mutuamente excluyentes, dueño y ruta clara puede ser suficiente. Tampoco introduzca categorías si el equipo aún no puede identificar el objeto afectado: primero cree una identidad estable.

Evite esta solución para encubrir un proceso roto. Si la mayoría de casos entra como excepción, el supuesto camino feliz es incorrecto. Rediseñe la regla o la fuente antes de optimizar la cola.

Primer ejercicio: reclasifique la última semana

Tome una semana de fallos y, sin leer el nombre del flujo, clasifique cada caso en una de las seis familias. Marque dónde faltan objeto, evidencia, dueño o resolución. Los casos que dos personas clasifican distinto revelan definiciones ambiguas; los que no caben revelan un hueco real. A partir de esa muestra, publique el diccionario, asigne rutas y haga que el código determine una acción, no solo un color de tablero.

Sources

• OMG Business Process Model and Notation (BPMN) 2.0 — omg.org
• AWS Step Functions — Handling errors in workflows — aws.amazon.com
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations — nist.gov