Analizar los procesos antes de automatizar: relevamiento, valoración, selección

Aparece en casi todas las llamadas iniciales, normalmente de pasada y pensando en una tarea que a alguien le cuesta horas cada semana: teclear presupuestos, reenviar solicitudes, pasar datos de correos a una hoja de cálculo. El deseo es comprensible y, a menudo, está justificado. La dificultad está en otra parte: en la pregunta de qué es exactamente «eso».

Supongamos que una empresa con unos quince empleados quiere automatizar la tramitación de las solicitudes de clientes entrantes. Si se pregunta a la propietaria, funciona así: llega la solicitud, se registra, sale el presupuesto. Si se pregunta a la administrativa, se añaden tres pasos más: una consulta al almacén, un vistazo a la lista de precios de hace dos años y una nota manuscrita para el jefe. Ambas describen el mismo flujo y se refieren a cosas distintas.

Lo notable es que ninguna de las dos descripciones es falsa. La propietaria conoce el flujo desde el punto de vista del resultado; la administrativa, desde el del trabajo diario. Solo juntas dan una imagen, e incluso entonces suele faltar la perspectiva del almacén o de la contabilidad, que participan al margen sin que nadie piense en ellos.

Este escenario es un patrón, no un caso individual real. Muestra por qué el trabajo empieza antes de la automatización. Un flujo que nadie abarca por completo no puede plasmarse de forma fiable en reglas. Un análisis de procesos lo hace visible antes de invertir tiempo y dinero en una herramienta basada en una suposición incompleta.

El patrón de fallo más frecuente es la automatización del rodeo. Si hoy una factura se imprime, se visa y se vuelve a escanear porque en su día se exigía el principio de los cuatro ojos, ese camino puede reproducirse con un script. Sería más rápido, pero no más inteligente. La pregunta de fondo, si la aprobación sigue siendo necesaria así, queda sin responder.

El segundo patrón de fallo son las excepciones. Un flujo funciona en el caso normal y fracasa en los cinco casos especiales que aparecen constantemente en el día a día: un cliente sin número de cliente, un pedido con entrega parcial, un documento en el formato equivocado. Las personas lo resuelven de pasada porque tienen contexto. Una automatización sin excepciones documentadas, o bien se interrumpe, o bien produce en silencio resultados erróneos, lo que es peor.

En tercer lugar, a menudo falta alguien responsable. En la práctica, un proceso rara vez tiene un propietario; se reparte entre roles que se pasan trabajo unos a otros. Si entonces falla un paso automatizado, nadie sabe quién debe notarlo, corregirlo o decidir si puede seguir funcionando. De estos tres patrones se deduce qué debe recoger un análisis de procesos.

Quien ha visto una vez lo que es posible suele querer empezar enseguida, y además por el proceso que más molesta. Es humano y rara vez la mejor elección. Lo que más molesta no es automáticamente lo que mejor se puede automatizar, y las tareas pesadas suelen serlo precisamente porque contienen muchas excepciones.

Por eso valoramos los candidatos con unos pocos criterios sobrios. La frecuencia indica con qué regularidad se produce un flujo por semana o por mes. La duración indica cuánto tiempo de trabajo ocupa cada ejecución. La propensión a errores describe con qué frecuencia surgen retrabajo, consultas o correcciones. Como contrapeso se añade la regularidad: cuanto más criterio necesita un paso, menos se presta a una secuencia fija.

En la práctica esto significa que cada candidato recibe una ficha con breves datos sobre estos criterios, expresamente como estimación aproximada y con la fuente detrás, por ejemplo «recuento en el buzón, cuatro semanas» o «estimación de la administrativa». Así sigue siendo visible qué cifra está documentada y cuál es supuesta. Las fichas sin datos fiables no pasan a la selección, sino primero a una breve fase de medición.

Se pone interesante cuando se comparan los criterios entre sí. Un proceso que se da pocas veces pero cuesta media jornada cada vez puede compensar más que uno que se da a diario y dura dos minutos. A la inversa, un paso frecuente, corto y propenso a errores suele ser la mejor puerta de entrada, porque incluso pequeñas mejoras evitan muchos fallos. La ponderación depende de la empresa, y precisamente por eso merece la pena hablarla.

La alternativa más evidente al análisis de procesos es probar: conectar una herramienta, lanzar una primera ejecución, ir mejorando. Para tareas muy pequeñas y autónomas es defendible, por ejemplo cuando una sola persona realiza ella sola un único paso. En cuanto intervienen varios roles, sistemas o clientes, ir corrigiendo sale caro, porque cada corrección afecta a otros participantes y los errores se ven tarde.

La segunda alternativa es un modelo de procesos exhaustivo, como es habitual en grandes organizaciones, con notación, herramienta y una serie de talleres. Para una empresa de diez a cincuenta empleados, el esfuerzo rara vez guarda proporción con el resultado. Mantenemos el análisis deliberadamente ligero: una entrevista por rol, media hora de observación en el puesto de trabajo, un esquema del flujo de una página. Eso basta para tomar decisiones.

Nuestro orden es: entender, simplificar, decidir y después automatizar. Simplificar es el paso que a menudo se omite. A veces la necesidad desaparece en cuanto se elimina un registro doble o se suprime una aprobación. Eso no es un fracaso del proyecto, sino su resultado más favorable, porque un paso que ya no existe no necesita ni mantenimiento ni supervisión.

Una tercera alternativa es comprar una solución sectorial que traiga el flujo «de serie». Puede funcionar si su empresa se ajusta al estándar del sector. Si se desvía, o bien adapta el software a su flujo, o bien su flujo al software. Ambas opciones son legítimas, pero deberían ser una decisión consciente, y para ello hace falta tener una imagen del propio flujo.

El precio de este enfoque es tiempo al principio. El levantamiento retrasa el avance visible entre unos días y unas pocas semanas, según el número de procesos. A cambio, se evitan reformas posteriores. Si hay prisa, se puede empezar con un único proceso bien delimitado y limitar el levantamiento a él.

La entrevista no empieza con la pregunta por el proceso, sino con un caso concreto. «Cuénteme la última solicitud que tramitó» da más que «¿Cómo funciona normalmente?». La primera pregunta recupera el recuerdo de detalles reales; la segunda, la versión idealizada. Pedimos que nos enseñen archivos, buzones y notas en papel, en la medida de lo posible, y tras cada paso preguntamos: ¿qué ocurre antes, qué ocurre después y quién está esperando por ello?

La observación complementa la conversación allí donde las personas ya no perciben conscientemente su propio trabajo. Quien lleva años manteniendo la misma hoja de cálculo ya no menciona que recurre a la segunda lista. Observar también revela los tiempos de espera: un proceso que sobre el papel dura una hora tarda en realidad dos días porque una carpeta espera en un escritorio a que alguien vuelva. Esta diferencia entre tiempo de tramitación y tiempo de ciclo es fundamental para la evaluación.

De las conversaciones surge el mapa del proceso, al principio como una secuencia sencilla: desencadenante, pasos, resultado. Cada paso recibe cuatro datos: quién lo ejecuta, en qué medio, con qué frecuencia ocurre y qué excepciones hay. Marcamos en color las rupturas de medio, porque casi siempre son a la vez fuentes de error y buenos puntos de partida. Ahí se vuelve a teclear, se copia o se archiva, y ahí nace la mayor parte de las consultas posteriores.

Lo importante es la contrastación. Mostramos el mapa a las personas implicadas y preguntamos: ¿es así? Las correcciones son el verdadero aprendizaje, porque ponen al descubierto dónde divergen las percepciones. Solo cuando todos dicen «así funciona entre nosotros», el proceso actual se da por levantado.

A partir del proceso actual diseñamos el proceso objetivo en dos pasos. Primero se elimina y se unifica: ¿qué pasos no aportan valor al cliente ni a un control demostrablemente necesario? ¿Qué información se registra dos veces? Después se decide cuáles de los pasos restantes puede asumir una máquina y cuáles se quedan en manos de personas. Esta división en dos fases evita que la automatización sirva de sustituto de una decisión que en realidad debe tomar la empresa.

En la implantación técnica, el levantamiento y la elección de herramientas son cuestiones distintas. Los procesos basados en reglas con desencadenantes claros suelen resolverse con herramientas de conexión entre los sistemas existentes, sin software propio. Donde hay que interpretar textos, correos o documentos, un modelo de lenguaje puede asumir pasos concretos, por ejemplo clasificar solicitudes o extraer campos. En ese caso conviene una comprobación de plausibilidad antes o después, porque estos modelos a veces se equivocan y no lo indican.

A partir del levantamiento, cada paso automatizado recibe tres definiciones. Primera, una comprobación de entrada: ¿qué datos deben existir para que el paso pueda arrancar? Segunda, una salida para excepciones que traspase el caso a una persona designada en lugar de adivinar. Tercera, una traza, es decir, un registro que permita saber qué ocurrió, cuándo y con qué resultado. Sin estas tres cosas, en el día a día es difícil decidir si la automatización mejora algo.

Un ejemplo práctico: llega una solicitud por formulario. El proceso objetivo comprueba los datos obligatorios, crea el contacto, asigna la solicitud a una persona y envía un recordatorio pasado el plazo acordado. La oferta en sí la sigue redactando una persona, porque el precio y el alcance se negocian de forma individual. La automatización no se ha hecho aquí más pequeña, sino que se ha colocado en los lugares adecuados.

El primer caso especial es la excepción que no lo es. En el levantamiento aparece un caso especial que todos describen como raro. El recuento en el buzón muestra entonces que afecta a un tercio de los casos. Eso cambia la planificación de raíz: o bien el caso especial pertenece al proceso estándar, o bien el proceso estándar está menos estandarizado de lo pensado. Por eso contrastamos estas afirmaciones con una muestra de las últimas semanas, no solo con la memoria.

El segundo caso es el conocimiento que no está escrito en ninguna parte. Una empleada veterana sabe qué cliente quiere que se le confirme siempre por teléfono y qué proveedor suele desviarse en las cantidades. Estas reglas no están documentadas y en las entrevistas solo se encuentran preguntando de forma específica por las sorpresas: ¿qué falló la última vez y cómo se dieron cuenta? Este conocimiento basado en la experiencia se traduce en una regla o se deja constancia de él como motivo para una revisión humana.

Tercero, el escepticismo en el equipo. Quien levanta procesos hace preguntas sobre el trabajo de otras personas, y eso puede parecer un control o la preparación de un recorte de plantilla. Decimos el objetivo con claridad: se trata de delegar la rutina y crear tiempo para tareas que exigen criterio, no de evaluar a las personas. Lo que se dice en las entrevistas permanece anónimo en el mapa del proceso, y las personas implicadas ven el resultado antes de que se transmita.

Cuarto, hay procesos con un marco legal o contractual, por ejemplo obligaciones de conservación o de documentación. Conocemos estos requisitos solo en lo esencial y no los resolvemos de forma definitiva. Forman parte del levantamiento como condición de contorno, y en caso de duda debería decidir una asesoría fiscal o jurídica qué debe mantenerse en el proceso objetivo.

El beneficio de un levantamiento de procesos está, ante todo, en las decisiones, no en las automatizaciones. Después se sabe qué procesos merecen la pena, cuáles conviene cambiar primero y cuáles seguirán siendo manuales. Eso reduce el riesgo de invertir dinero en herramientas que resuelven el cuello de botella equivocado. Este beneficio es real, pero difícil de expresar en euros, y no afirmamos ninguna cifra.

Donde se automatiza a continuación, el efecto puede leerse en pocas magnitudes. El tiempo de ciclo muestra cuánto tarda un caso desde la entrada hasta el cierre. El número de consultas y correcciones muestra si los errores se vuelven menos frecuentes. El tiempo de tramitación manual por caso, medido durante unas semanas con un simple recuento a mano o con marcas de tiempo, muestra el alivio real. Es importante registrar estos valores antes, de lo contrario falta la comparación.

Al mismo tiempo hay límites. Cuánto tiempo se ahorra depende de la empresa y solo puede estimarse de forma aproximada de antemano. Además, una automatización puede generar trabajo nuevo: hay que tramitar excepciones, leer registros y mantener reglas. Una comparación honesta incluye este mantenimiento. Tras la puesta en marcha, cuente con una fase en la que se ajustan los procesos, y juzgue el resultado al cabo de unas semanas, no tras los primeros días.

Lo que no se mide, pero se nota, es la ganancia en claridad. Cuando las responsabilidades están definidas, las rupturas de medio reducidas y las excepciones conocidas, la empresa se gobierna mejor incluso sin tecnología. Algunos equipos cuentan en estos proyectos que el propio levantamiento ya fue el mayor avance. No se puede garantizar, pero es un efecto secundario plausible.

Primera: empiece con un proceso, no con todos. Un único proceso bien delimitado da un resultado en poco tiempo y muestra si el enfoque encaja con su empresa. Segunda: mida antes de intervenir. Sin un valor de partida, cualquier afirmación sobre el éxito sigue siendo una opinión. Basta incluso un recuento a mano de dos semanas para reconocer órdenes de magnitud.

Tercera: deje constancia de lo que se queda en manual de forma deliberada y justifíquelo. Aquí entran los pasos que requieren criterio o relación personal, como la conversación con un cliente insatisfecho o la decisión de precio en un encargo especial. También los pasos con un daño elevado en caso de error, como las autorizaciones de pago, deberían conservar una confirmación humana. Y los casos tan raros que el desarrollo y el mantenimiento nunca se amortizarían también quedan en manos de personas.

Cuarta: implante las automatizaciones por etapas. Un estado intermedio en el que el sistema hace una propuesta y una persona la confirma saca a la luz suposiciones erróneas antes de que tengan consecuencias. Solo cuando las propuestas aciertan durante un periodo largo merece la pena relajar la confirmación. Quinta: designe para cada proceso automatizado a una persona responsable que revise su estado con regularidad.

Estas reglas no tienen nada de espectacular, y justo ahí está su valor. Desplazan el centro de gravedad de la técnica a la decisión. Hoy la tecnología rara vez es el factor escaso; la claridad sobre el propio proceso, sí.

Quien quiera analizar y automatizar procesos debería hacer ambas cosas en este orden. El análisis aclara cómo trabaja realmente la empresa, dónde se pierde información y qué existe solo por costumbre. La automatización actúa donde demostrablemente alivia. Entre ambas está la decisión honesta sobre qué puede quedarse, qué se cambia y qué sigue siendo trabajo manual de forma deliberada.

El siguiente paso es pequeño y no necesita un proyecto. Elija un proceso que le cueste tiempo con regularidad y pida a dos personas implicadas que lo dibujen por separado, solo como palabras clave en una hoja. Las diferencias entre las dos hojas son el primer hallazgo. Si son grandes, merece la pena levantar el proceso con más detalle antes de elegir cualquier herramienta.

Para la conversación con proveedores de servicios vale la misma regla. Una oferta que promete un ahorro de tiempo fijo sin mirar su proceso se basa en suposiciones que nadie ha comprobado. Pregunte qué pasos asume la herramienta, qué ocurre ante una excepción y quién supervisa el funcionamiento. Quien sabe responder con concreción se ha ocupado de su proceso.

Con gusto acompañamos este levantamiento y, tras una llamada inicial, le diremos con franqueza si una automatización resulta rentable o si basta con una simplificación. También el segundo resultado es bueno. Le ahorra un proyecto que habría costado más de lo que aporta.