Imagina que es el día 28 del mes. Una analista tiene abiertas once hojas de Excel, dos portales bancarios y un chat con tres áreas que todavía no le han enviado su información. Son las 8:40 de la noche. Nadie le pidió quedarse; el cierre simplemente no se hace solo. Cada cifra que copia tiene que revisarla dos veces, porque la última vez que no lo hizo, el error apareció en una reunión de gerencia.
Si miras ese proceso desde afuera, parece un candidato perfecto para automatizar. Si lo miras desde adentro, es otra cosa: es la persona más cuidadosa del equipo, usada como si fuera una fotocopiadora con criterio.
El trabajo que no aparece en el cargo
Casi ningún cargo describe lo que realmente consume el tiempo de quien lo ocupa. La descripción dice "responsable de la conciliación" o "responsable de la liquidación". La realidad es una mezcla de cinco tipos de trabajo muy distintos:
• Transcribir: mover un dato de un lugar a otro.• Cruzar: comparar dos fuentes y encontrar diferencias.• Verificar: revisar que lo anterior se hizo bien.• Perseguir: pedir, recordar y esperar información de otras personas.• Decidir: resolver lo que no encaja en ninguna regla.
Los primeros cuatro son trabajo de reglas. Se pueden describir, se pueden repetir y se pueden ejecutar sin cansancio. El quinto es trabajo de criterio, y es el único por el que la empresa contrató a esa persona. El problema es que, en un proceso manual, los cuatro primeros ocupan tanto espacio que el quinto se hace al final, con prisa, cuando ya no queda energía.
Una automatización bien diseñada separa estas cinco capas antes de escribir una sola línea de código. Esa separación es el diagnóstico real, y es lo que determina si el proyecto mejora la vida de alguien o solo cambia el lugar donde se acumula el estrés.
Lo que pasa cuando no se rediseña el rol
Hay un patrón que se repite cuando una automatización se entrega sin pensar en la persona: el proceso corre, las horas se liberan y nadie sabe qué hacer con ellas. Pueden ocurrir tres cosas, y ninguna es buena.
La primera es que las horas liberadas se absorben con más volumen. La persona hace lo mismo que antes, pero con más carga, porque "ahora que es más rápido". La segunda es que la persona queda sin un rol claro, y el temor que ya existía de que la automatización venía a reemplazarla empieza a parecer razonable. La tercera es la más silenciosa: la persona sigue verificando a mano lo que el sistema hace, porque nadie le explicó en qué puede confiar y en qué no. Termina con el trabajo anterior más el trabajo de vigilar al sistema.
En los tres casos el fallo no es técnico. El sistema funciona. Lo que falló es la decisión sobre qué hace ahora el ser humano dentro del proceso, y esa decisión tiene que tomarse antes de construir, no después de entregar.
Diseñar el nuevo lugar de la persona
El rol que queda después de automatizar rara vez es "supervisar". Supervisar sin herramientas es mirar un proceso opaco y esperar que nada falle. El rol útil es el de dueño de las excepciones, y para que exista hay que construirlo como parte del proyecto:
1. Una cola de excepciones explícita. Todo lo que el sistema no puede resolver con sus reglas llega a un lugar visible, con el contexto necesario para decidir sin tener que reconstruir lo ocurrido. La persona deja de buscar el problema y empieza a resolverlo.
2. Reglas que la persona pueda leer. Si la lógica de la automatización vive en un código que solo entiende quien la construyó, el equipo no puede confiar en ella ni corregirla. La confianza se construye con transparencia, no con promesas.
3. Un periodo de convivencia con criterio de salida. Correr el proceso nuevo en paralelo con el anterior sirve para ganar confianza, pero solo si se define cuándo termina y con qué evidencia. Sin ese criterio, la doble carga se vuelve permanente.
4. Responsabilidades nuevas, nombradas desde el inicio.Análisis de variaciones, mejora de las reglas, relación con las áreas que proveen la información. Son tareas que casi siempre existían en teoría y nunca tuvieron tiempo.
Calidad de vida laboral: lo que sí se puede medir
Hablar de bienestar en un proyecto de automatización suena blando hasta que se traduce en variables observables. Hay varias que cualquier empresa puede revisar antes y después:
• Cuántas horas se trabajan fuera de jornada en los días de cierre.• Cuántas personas son el único punto de falla de un proceso que no pueden dejar sin atender.• Cuántas correcciones se hacen después de entregar un resultado.• Cuántas veces al mes alguien tiene que interrumpir lo que estaba haciendo para responder una urgencia del proceso.
Ninguna de estas aparece en un retorno de inversión tradicional, y todas tienen costo real: errores, rotación, conocimiento que se va con la persona que se cansó. Un proyecto que reduce el tiempo de ejecución pero deja intactas estas cuatro variables ahorró horas, pero no resolvió el problema.
Una pregunta que conviene hacer en el discovery
Antes de definir qué se automatiza, hay una conversación que casi nunca ocurre y que cambia el diseño completo: sentarse con quien hoy ejecuta el proceso y preguntarle qué parte de su trabajo le gustaría dejar de hacer, y qué parte no entregaría nunca. Las dos respuestas dibujan el límite de la automatización con más precisión que cualquier diagrama de flujo.
En esas conversaciones suele aparecer algo que ningún levantamiento técnico detecta: la persona ya sabe cuál es el trabajo que la agota y cuál el que le da sentido. Lo que necesita es que alguien diseñe el sistema alrededor de esa diferencia.
Así que. Una automatización exitosa no se reconoce por lo que el sistema hace a las 8:40 de la noche del día 28. Se reconoce por lo que la analista hace a esa hora: nada, porque se fue a las seis, y al día siguiente llegó a revisar las tres excepciones que de verdad necesitaban su criterio.
En EmasT empezamos cada proyecto por esa conversación. Si estás evaluando automatizar un proceso y quieres definir primero qué le quedaría a tu equipo, esa es una buena forma de empezar.