Mapear procesos antes de automatizar: qué recoger y cuándo parar

Mapear procesos antes de automatizar suena a paso burocrático y es justo lo contrario: es lo que evita montar un automatismo perfecto sobre el tramo equivocado. Ocurre más de lo que parece. Se automatiza la entrada de pedidos, que era la parte visible, y resulta que el pedido llevaba cuatro días parado antes de llegar ahí, esperando una confirmación de precio. El tiempo total no baja. La tarea mecánica desaparece, sí, pero el cliente sigue esperando lo mismo. Lo que sigue trata de cómo levantar el mapa que hace falta para decidir bien, qué recoger de cada proceso y en qué momento se puede dejar de mapear y empezar a construir.

Lo que cuesta automatizar con el mapa a medias

Cuatro consecuencias concretas, todas caras y todas frecuentes.

La primera ya está contada: se acelera un tramo que no era el cuello de botella y el conjunto tarda igual. La segunda es peor porque no se ve: el atasco se desplaza. Si un paso empieza a producir el triple, el siguiente recibe el triple, y como lo hace una persona, ahora la cola está ahí.

La tercera aparece con el segundo o tercer automatismo: cada uno lleva dentro su propia versión de las reglas. Uno da por hecho que los portes se suman si el pedido no llega a cierto importe; otro, montado seis meses después por otra persona, aplica un criterio distinto. Nadie lo nota hasta que dos documentos del mismo cliente no cuadran.

La cuarta se nota el día que algo cambia: nadie sabe a qué afecta. Cambia un plazo o un límite de aprobación y hay que ir buscando dónde estaba escrito eso. Con el mapa delante se ve en qué procesos interviene esa regla y qué puestos hay que avisar.

El mapa para automatizar es más estrecho y más profundo

Conviene no confundir dos ejercicios distintos. El mapa general de la empresa sirve para ver el conjunto: qué procesos hay, de quién son, cuáles sostienen el negocio. Es ancho y poco profundo, y se hace una vez.

El mapa previo a una automatización es lo contrario: coge un proceso candidato y baja al detalle, pero solo de él y de sus vecinos inmediatos, el que le entrega el trabajo y el que lo recibe. No hace falta mapear la empresa entera para automatizar la recepción de albaranes. Hace falta mapear la recepción de albaranes, lo que pasa justo antes y lo que pasa justo después, porque ahí es donde están las sorpresas.

Esa acotación es la que hace el trabajo abordable. Dos o tres días bien empleados, no un proyecto de tres meses que se abandona a la mitad.

Qué recoger de cada proceso

Siempre los mismos diez datos, en el mismo orden, para que dos procesos mapeados por personas distintas se puedan comparar.

Dato	La pregunta que lo saca
Disparador	¿Qué tiene que pasar para que esto empiece?
Entrada	¿Qué llega, en qué formato y por dónde?
Fin	¿En qué momento decimos que esto ya está hecho?
Pasos y puestos	¿Qué se hace y qué puesto hace cada cosa?
Traspasos	¿Cuántas veces cambia de manos y cómo se avisa?
Esperas	¿Dónde se queda parado y a qué está esperando?
Decisiones	¿Qué hay que decidir, con qué criterio y quién decide?
Herramientas y datos	¿En qué programa se hace y de dónde sale cada dato?
Volumen	¿Cuántos casos al mes y cómo varía a lo largo del año?
Fallos	¿Qué sale mal, cada cuánto y cómo se arregla?

De los diez, los tres que más gente se salta son traspasos, esperas y decisiones. Y son precisamente los que determinan si una automatización va a servir de algo. Un proceso de ocho pasos que cambia de manos cuatro veces no tiene un problema de pasos: tiene un problema de coordinación, y eso se arregla con avisos y estados, no automatizando el tecleo.

Ejemplo: aprobar un pedido en una empresa de ejemplo

Pongamos una distribuidora ficticia de 40 personas. Sobre el papel, aprobar un pedido son tres pasos: comercial lo registra, administración revisa el crédito del cliente y almacén lo prepara. Mapeado de verdad aparecen dos esperas que nadie había contado: el pedido se queda parado hasta que administración hace la revisión de la mañana siguiente, y si el cliente tiene facturas vencidas vuelve a comercial para que llame, sin que haya un momento fijo para eso. Los tres pasos suman minutos de trabajo; las dos esperas suman días de calendario. Con ese mapa delante, la conversación sobre qué automatizar cambia de sitio.

Cómo sacar a la luz las excepciones que rompen una automatización

Un automatismo que solo conoce el camino bueno se cae en el caso que peor momento elige, y nadie cuenta las excepciones espontáneamente porque para quien las vive no son excepciones: son el trabajo. Hay que ir a buscarlas con preguntas que no admitan una respuesta general.

• «Cuéntame la última vez que esto se torció. ¿Qué hiciste?»
• «¿Con qué clientes o proveedores lo hacéis distinto, y por qué?»
• «¿Qué caso te obligó a llamar a alguien para preguntar?»
• «Si mañana te tocara enseñárselo a alguien, ¿qué le avisarías de que no está escrito?»
• «¿Cuándo dices "este lo hago yo a mano"?»

Además de preguntar, mira datos. Coge los diez casos que más tardaron del último trimestre y reconstruye qué les pasó: las excepciones dejan rastro en los casos lentos. Revisa la carpeta o el hilo de correo donde se resuelven los líos, si existe. Y fíjate en los «depende»: cada uno señala una regla que alguien tiene en la cabeza y nadie ha escrito. Si al hacer este ejercicio aparecen más «depende» que pasos, el proceso todavía necesita quedar escrito antes que nada.

Clasificar cada excepción antes de decidir nada

No todas se tratan igual, y meterlas todas en el mismo saco es lo que hace que un proyecto no termine nunca.

Tipo de excepción	Qué hacer con ella
Frecuente y con regla clara	Entra en la automatización como una rama más.
Frecuente sin regla escrita	Se decide la regla ahora, se escribe y entonces entra.
Rara y con consecuencias graves	Se detecta y se desvía a un puesto concreto, que resuelve a mano.
Rara y sin consecuencias	Se deja fuera a propósito y se apunta que se hace a mano.
Nunca vista antes	El automatismo para y avisa. Nunca sigue adivinando.

La última fila es la más importante y la que más se olvida. Un proceso automatizado tiene que tener una salida de emergencia con nombre y apellidos de puesto. Sin ella, el caso raro se resuelve solo y mal, y lo normal es que nadie se entere hasta bastante después.

Cuándo se puede dejar de mapear

El mapa no está terminado nunca, así que hace falta una condición de salida para no quedarse dando vueltas. Estas seis funcionan bien:

1. Dos personas distintas describen el proceso igual, sin contradecirse en ningún paso.
2. Cada decisión tiene escrito su criterio, con su número o su límite, y quién decide.
3. Las excepciones están clasificadas y se sabe qué pasa con cada tipo.
4. Se sabe de dónde sale cada dato que hace falta y quién tiene acceso a él.
5. Hay una medida de partida: casos al mes, tiempo desde que entra hasta que se cierra y fallos habituales.
6. Hay un puesto dueño del proceso que responderá también del automatismo.

Si las seis se cumplen, para de mapear y empieza. Si falla alguna, ya sabes dónde seguir: no es que el mapa esté incompleto en general, es que le falta esa pieza concreta. Con eso resuelto, la siguiente decisión es cuál de los candidatos merece ir primero, y ahí ayudan los criterios de elección y priorización.

El mapa después de automatizar

Hay una tentación comprensible: dar el mapa por amortizado cuando el automatismo ya funciona. Es el momento exacto en que empieza a hacer falta más.

Automatizar cambia el proceso, y si el mapa sigue describiendo el de antes, deja de servir para lo siguiente. Toca actualizarlo con lo que ha cambiado: qué pasos ya no ejecuta una persona, dónde queda el punto de validación, qué puesto responde de vigilarlo y a quién avisa cuando se para. Guardar la versión anterior con su fecha también ayuda, porque cuando algo falle querrás saber qué decía el proceso antes del cambio.

Y conviene volver a mirar el conjunto cada cierto tiempo. El atasco se ha movido: eso no es un fallo, es el resultado esperado. La pregunta útil es dónde está ahora. En automatización de procesos contamos cómo encaja este ciclo en una pyme, y si necesitas material de referencia para mapear, en ocho procesos de ejemplo tienes el formato aplicado a casos concretos.