Mapear un flujo de trabajo: qué ver antes de automatizar nada

Puntos clave

• Por qué el proceso que está documentado y el que ocurre rara vez coinciden, y qué se decide mal cuando se confunden.
• Dónde se detiene el trabajo de verdad, que casi nunca es donde la dirección supone.
• A quién preguntar para levantar el mapa, y las preguntas que sirven frente a las que producen la respuesta correcta y falsa.
• Cómo reconocer los pasos que solo existen por inercia, de un problema que ya nadie recuerda.

Análisis elaborado por los consultores de Xmarts, mejor partner de Asana en Latinoamérica.

Mapear un flujo de trabajo antes de automatizarlo revela algo que ningún organigrama muestra: dónde se detiene el trabajo de verdad, cuánto de ese tiempo es espera y no ejecución, y qué pasos existen solo porque alguien los agregó para compensar un problema que ya se resolvió.

Mapear un flujo de trabajo se hace preguntando a quien ejecuta, no a quien lo diseñó. Y se dibuja sobre lo que ocurre, no sobre lo que debería ocurrir. Esa distancia entre el proceso documentado y el real es donde suele estar el retorno.

El proceso que está escrito y el que ocurre

Casi toda empresa mediana y grande tiene sus procesos críticos documentados en algún lado. Un diagrama en una presentación, un manual de calidad, una plantilla de proyecto que alguien armó y el resto copia.

Ese documento describe el recorrido ideal: la solicitud entra, se revisa, se aprueba, se ejecuta, se entrega. Limpio y lineal. Sirve para explicarle a alguien nuevo cómo funciona la casa.

El problema aparece cuando se usa para decidir. Bain encontró que cuatro de cada diez empresas que midieron el ahorro de sus proyectos de automatización quedaron por debajo del diez por ciento, muy lejos de la meta que ellas mismas se habían fijado. No es que las herramientas no funcionaran. Es que se aplicaron sobre un mapa que no correspondía al territorio.

Dónde se detiene el trabajo, que casi nunca es donde parece

Preguntado desde la dirección, el cuello de botella siempre está en la etapa más visible: la que tiene más gente, la que genera más quejas, la que aparece en el reporte.

Observado desde el trabajo, suele estar en otro lugar. En el correo que espera respuesta de alguien que está en otra zona horaria. En el archivo que hay que pedirle a una persona porque vive en su equipo. En la aprobación que se resuelve en dos minutos pero solo ocurre los jueves, cuando hay comité.

La diferencia práctica es la proporción entre ejecución y espera. Un entregable que tarda nueve días en salir puede tener cuatro horas de trabajo real y el resto de calendario. Automatizar esas cuatro horas es tentador porque son medibles y visibles. No cambia nada, porque el proceso sigue tardando nueve días. Es el mismo mecanismo por el que la dispersión de herramientas cuesta más de lo que se ve: el costo no está donde se mira.

Ese es el punto donde conviene detenerse antes de evaluar cualquier herramienta, y la razón por la que mapear un flujo de trabajo empieza por medir esperas y no tareas. Si la espera representa la mayor parte del tiempo total, el problema no se resuelve acelerando la ejecución.

Cómo mapear un flujo de trabajo sin que te cuenten el manual

El mapa lo tiene quien ejecuta el proceso todos los días, no quien lo diseñó ni quien lo supervisa. Esa es la primera regla y la más incómoda, porque implica bajar dos niveles en la conversación.

La segunda es que la pregunta directa no funciona. "¿Cómo es el proceso?" produce el proceso documentado, porque es la respuesta correcta y la que se espera. Nadie va a describir los atajos que usa a diario cuando le preguntan formalmente por el procedimiento.

Lo que sí funciona es preguntar por el caso concreto. Cuál fue la última solicitud que atendiste. Qué pasó primero. Qué esperaste. A quién tuviste que buscar. Qué hiciste mientras tanto. En qué momento supiste que ya estaba aprobado.

De ahí sale el recorrido real, con sus retornos, sus consultas informales y sus dos o tres pasos que no están en ningún manual. Es el mismo ejercicio que decide si una implantación se adopta o se abandona, porque el sistema termina reflejando el proceso que se le describió. Conviene repetirlo con tres o cuatro casos distintos, porque un solo caso puede ser la excepción y el tercero ya muestra el patrón.

Los pasos que existen solo por inercia

En todo proceso con algunos años hay pasos que nadie sabe explicar. Una validación adicional, un correo de copia a un área que ya no participa, un archivo que se llena y nadie lee.

Casi siempre tienen el mismo origen: alguna vez hubo un problema y se agregó un control para evitarlo. El problema se resolvió en otro lado, a veces años después, y el control se quedó porque quitarlo nunca fue tarea de nadie.

Se identifican con una pregunta sencilla: si esto dejara de hacerse mañana, ¿quién lo notaría y qué pasaría? Cuando la respuesta es que nadie y nada, la respuesta está clara.

Vale la pena detenerse ahí porque es el hallazgo más rentable de un mapeo y el único que no requiere comprar nada. Tres formas en que suele aparecer. La primera es la copia de correo a un área que dejó de participar en el proceso hace tiempo y que ahora recibe entre veinte y cincuenta mensajes al mes que nadie abre. La segunda es la doble captura: un dato que se registra en un sistema y se vuelve a escribir en una hoja porque alguna vez los dos no se comunicaban, y hoy sí lo hacen. La tercera, la más cara, es la validación redundante, donde dos personas revisan lo mismo porque nunca se acordó cuál de las dos tenía la responsabilidad, y en la práctica ambas asumen que la otra mira con más cuidado.

Quitar cualquiera de las tres no mejora el proceso de forma espectacular. Lo que hace es dejar de gastar en algo que ya no compra nada, y suele ser lo primero que se puede mover sin pedirle presupuesto a nadie.

En los diagnósticos que realiza Xmarts con empresas de servicios y manufactura de la región, este suele ser el tramo que más sorprende a la dirección, porque revela trabajo que se paga todos los meses sin que aparezca en ninguna discusión de presupuesto.

Un recorrido, contado como se ve

Vale la pena ver cómo queda esto aplicado, porque mapear un flujo de trabajo se entiende mejor con un caso que con un método. Tomemos una solicitud de contenido para una campaña, que es un flujo que casi toda empresa mediana tiene y que cruza al menos tres áreas.

En el manual son cinco pasos: el área solicitante pide, marketing acepta, alguien redacta, alguien revisa, se publica.

Siguiendo una solicitud real, el recorrido se ve distinto. La petición entra por mensaje directo a la persona de marketing con la que el solicitante tiene más confianza, no por el formulario que existe para eso. Esa persona pide por correo tres datos que el formulario habría capturado. Pasan dos días hasta que llegan. Se asigna a quien redacta, que trabaja seis horas repartidas en tres días porque tiene otras dos campañas abiertas. La revisión de marca tarda una tarde, pero la pieza espera cuatro días en la bandeja de quien revisa, que no sabía que estaba ahí. Vuelve con un cambio menor. Se publica.

Total: catorce días de calendario, alrededor de ocho horas de trabajo.

Un proveedor que vea solo el manual propondrá acelerar la redacción, que es el paso que parece el trabajo. El mapa real muestra otra cosa: seis de los catorce días son espera por datos que nunca se pidieron al inicio, y cuatro son una bandeja donde nadie avisó. Ninguno de los dos se arregla escribiendo más rápido.

Cómo se ve un flujo de trabajo listo para decidir sobre él

Mapear un flujo de trabajo sirve cuando el resultado permite responder tres cosas sin volver a preguntar: dónde entra el trabajo, dónde se detiene y quién puede desatascarlo.

Con eso en la mano, la conversación con cualquier proveedor cambia de naturaleza. Se deja de pedir una demostración general y se pasa a pedir que muestre qué hace exactamente en el punto donde el proceso se traba. Esa pregunta es mucho más difícil de responder con una presentación, y por eso separa rápido a quien entiende el problema de quien vende una funcionalidad.

También cambia la decisión interna. Con el mapa levantado suele quedar claro que una parte del retorno no requiere comprar nada: está en los pasos por inercia y en las aprobaciones que se pueden delegar. Lo que queda después de eso es el alcance real de la inversión, y ya se puede dimensionar.

Ese mapa es, además, la condición para que cualquier agente de inteligencia artificial aporte, porque un agente lee la estructura que encuentra y no la que debería existir. Los Compañeros de IA de Asana, por ejemplo, trabajan con el contexto del proyecto al que se les asigna: si ese contexto refleja un proceso que nadie mapeó, heredan el desorden.

Tres preguntas para llevar a tu comité de dirección:

1. Del proceso que más nos preocupa, ¿cuánto del tiempo total es ejecución y cuánto es espera? Si nadie lo sabe, no estamos en condiciones de decidir qué automatizar.
2. ¿Cuándo fue la última vez que alguien de dirección siguió una solicitud completa, de principio a fin, como la vive quien la atiende?
3. ¿Qué pasos de ese proceso existen por una razón que hoy alguien pueda explicar?

Levantar ese mapa toma menos de lo que parece y cambia la conversación con cualquier proveedor, porque llegas con el problema ubicado en vez de con una necesidad general. Un consultor de Xmarts lo hace con tu equipo y sobre tus procesos. Agenda un diagnóstico.

Preguntas frecuentes