Mapear el proceso real y fijar el alcance

Diseñar un workflow sin conocer cómo se ejecuta realmente el proceso suele producir una automatización impecable sobre una versión imaginaria del trabajo. El primer objetivo no es dibujar el flujo futuro, sino reconstruir una unidad de trabajo concreta desde que empieza hasta que termina y distinguir qué parte merece entrar en el perímetro de automatización.

Esta lección presupone que la oportunidad ya ha sido seleccionada y priorizada en C00 o mediante un proceso equivalente. Aquí no se vuelve a decidir si el problema merece automatización: el mapeo sirve para convertir una oportunidad aprobada en una especificación de ejecución, localizar variantes y fijar un perímetro implementable.

Esta lección parte de una premisa sencilla: el proceso descrito en una reunión, un procedimiento interno o una pantalla de software no siempre coincide con el proceso ejecutado. Puede haber esperas, correos paralelos, hojas de cálculo, reenvíos, decisiones verbales, excepciones conocidas por una sola persona o pasos que solo existen para corregir errores de otro sistema. Antes de automatizar hay que hacer visibles esas diferencias.

Empieza por una unidad de caso

Un mapa útil necesita una unidad de seguimiento. En una solicitud de presupuesto, la unidad puede ser cada petición recibida. En un alta de proveedor, cada expediente de alta. En una revisión documental, cada documento o lote que entra en el proceso.

La unidad debe permitir responder cuatro preguntas: cuándo empieza el caso, cuándo termina, qué identificador permite seguirlo y qué resultado observable confirma su cierre. Si estas respuestas no están claras, el workflow futuro tampoco podrá saber con precisión qué está procesando.

Evita utilizar unidades demasiado amplias como “ventas”, “administración” o “gestión de clientes”. Son dominios de trabajo, no casos ejecutables. La automatización necesita objetos concretos: una solicitud, una factura, un expediente, un correo, una incidencia o una orden.

Reconstruye la ejecución con evidencia

Entrevistar a las personas que conocen el proceso es necesario, pero no suficiente. Cuando sea posible, contrasta el relato con evidencia: registros del CRM, correos, timestamps, estados de una aplicación, documentos generados, tickets, hojas de cálculo o logs de actividad.

Las técnicas de process mining trabajan precisamente con registros de eventos para observar variantes, tiempos y recorridos reales. No necesitas implantar una plataforma de minería para aplicar el principio: cuando existe evidencia operacional, úsala para comprobar el mapa.

Para cada caso seleccionado, registra al menos:

• evento de inicio;
• actividades realizadas;
• persona o sistema responsable;
• sistemas consultados;
• datos de entrada y salida;
• decisiones tomadas;
• esperas;
• correcciones o retrabajo;
• resultado final.

No intentes todavía “limpiar” el flujo. Primero documenta lo que ocurre.

Separa camino habitual, variantes y excepciones

Un workflow diseñado únicamente a partir del camino feliz falla en cuanto encuentra el primer caso que no encaja. Por eso conviene clasificar los recorridos observados.

El camino habitual es la secuencia que cubre la mayoría de casos sin incidencias. Una variante es una ruta legítima que forma parte del proceso, por ejemplo una solicitud internacional que necesita datos adicionales. Una excepción es un caso que no puede seguir las reglas ordinarias y necesita tratamiento específico, revisión o escalado.

La distinción importa porque no todas las desviaciones deben automatizarse. Si una variante aparece de forma recurrente, puede merecer una ruta explícita. Si una excepción es rara, compleja y de alto impacto, quizá deba conservar intervención humana.

Localiza decisiones, esperas y cambios de sistema

Marca de forma especial tres tipos de punto porque suelen concentrar el diseño posterior.

Primero, las decisiones: qué criterio hace que el caso siga una ruta u otra y quién lo aplica. Segundo, las esperas: qué condición bloquea el avance y cuánto puede durar. Tercero, los cambios de sistema o canal: cuándo un dato pasa del correo al CRM, de un formulario al ERP o de un documento a una hoja de cálculo.

Estos puntos suelen revelar ambigüedades. Por ejemplo, “si el cliente es importante, lo revisa dirección” no es una regla implementable hasta definir qué significa “importante”, dónde se obtiene ese dato y quién decide cuando falta.

Fija el perímetro de automatización

Mapear el proceso completo no obliga a automatizarlo completo. El perímetro debe definirse como un tramo con inicio, final y responsabilidades claras.

Una buena delimitación responde:

• qué evento entra en el workflow automatizado;
• qué datos debe recibir;
• qué actividades quedan dentro;
• qué actividades permanecen fuera;
• qué decisiones serán automáticas, asistidas o humanas;
• en qué estado entrega el caso al siguiente actor;
• qué sistema conserva la autoridad sobre cada dato.

El perímetro más pequeño que produce valor suele ser mejor punto de partida que una automatización de extremo a extremo demasiado ambiciosa.

Ejemplo: solicitud de presupuesto

Supongamos un proceso B2B que comienza cuando llega una solicitud por correo. El equipo comercial lee el mensaje, identifica cliente y producto, consulta precios en el ERP, comprueba condiciones en el CRM, pide aclaraciones si falta información, prepara un documento y solicita aprobación cuando el descuento supera un umbral.

Al observar casos reales aparecen tres variantes: solicitudes completas, solicitudes incompletas y solicitudes de clientes con condiciones especiales. También aparece una excepción: productos sin precio vigente.

El primer perímetro razonable podría no incluir la aprobación final ni el envío. Podría terminar en “borrador de presupuesto preparado y validado para revisión humana”. Ese límite reduce el riesgo y permite diseñar estados, datos y reglas con precisión antes de delegar acciones irreversibles.

Ejercicio: crea el mapa operativo

Elige un proceso real ya priorizado. Reconstruye al menos cinco casos recientes y crea una tabla con estas columnas:

Después dibuja el perímetro de automatización y escribe explícitamente qué queda fuera. Si no puedes justificar el inicio, el final y el resultado de ese perímetro, todavía no estás preparado para diseñar el workflow objetivo.

Resultado de la lección

Debes terminar con un mapa del proceso real, no con un diagrama idealizado: unidad de caso, recorrido habitual, variantes, excepciones, decisiones, esperas, sistemas y límite de automatización. Ese mapa será la entrada de la siguiente lección, donde se diseñará el comportamiento objetivo mediante estados y transiciones.