Automatizar un proceso mal definido no lo arregla, lo rompe más rápido

Hay una promesa que se repite en muchos comités de eficiencia: "automaticemos esto y el proceso finalmente se va a ordenar". Es exactamente al revés. Un proceso que nadie ha estandarizado, con excepciones que solo el equipo de siempre sabe resolver a mano, no se arregla porque le pongas un robot encima. Se rompe más rápido, porque ahora el caos corre a la velocidad de una máquina y no a la velocidad de una persona que, al menos, dudaba antes de ejecutar.

La tentación es entendible. Automatizar parece una solución tecnológica a un problema de gestión, y las soluciones tecnológicas se compran, se instalan y se muestran en un dashboard de progreso. Pero el problema casi nunca es tecnológico. Es que el proceso nunca tuvo reglas explícitas, y esa ambigüedad, que un humano compensaba con criterio, un sistema automatizado no la compensa: la ejecuta sin preguntar.

El criterio que decide si un proceso está listo

Antes de preguntar qué herramienta usar, hay una pregunta más básica que casi nadie se hace con rigor: ¿este proceso es maduro? La madurez de un proceso no es una sensación, es algo verificable. Un proceso maduro tiene tareas especificadas, es predecible, estable y medible. Si nadie puede describir por escrito, sin ambigüedad, qué pasa en cada paso y por qué, ese proceso no está listo para un robot, está listo para una reunión de rediseño.

Hay un segundo criterio, igual de concreto, que se suele ignorar: la tasa de excepciones. Un proceso candidato a automatización debe mostrar poca o ninguna desviación respecto al flujo definido. Si en la práctica el proceso se resuelve "a veces así, a veces asá" dependiendo de quién lo atienda, del cliente, del mes o del sistema legado que esté caído esa semana, automatizarlo no es optimizar: es fijar el caos actual como comportamiento oficial, y hacerlo correr sin supervisión.

Esto no es una objeción filosófica a la automatización. Es un filtro de entrada. Antes de preguntar qué plataforma usar, hay que responder si el proceso ya tiene reglas documentadas y si esas reglas cubren razonablemente las excepciones reales, no las excepciones ideales que aparecen en el diagrama de flujo que nadie actualiza.

Por qué el ahorro inicial se come el presupuesto de reparación

El patrón se repite con una lógica predecible. Se arma un caso de negocio con una estimación de ahorro atractiva. Se automatiza la parte más visible del proceso, típicamente con herramientas de automatización robótica que replican lo que hacía una persona en una interfaz. Y ahí empieza el desgaste: la estimación de valor capturado en el primer año se va reduciendo, no porque la tecnología falle, sino porque el proceso subyacente tenía más variaciones, más pasos "fuera de guion" y más calidad irregular de datos de entrada de lo que el documento de requisitos reconocía.

Cuando eso ocurre, el costo no desaparece: se traslada. Alguien tiene que revisar lo que el robot ejecutó mal, reconstruir los casos que quedaron fuera del flujo estándar, y explicar a los equipos que absorben el cambio por qué las rutinas de trabajo que ya funcionaban ahora están interrumpidas. Ese trabajo de reparación, sumado a la fricción de personal que dedicó horas a entregar requisitos sin obtener claridad sobre cómo iban a funcionar las piezas juntas, suele superar el ahorro que motivó el proyecto en primer lugar.

La lección operativa es directa: automatizar sin resolver antes el diseño del proceso no es una apuesta arriesgada con buen potencial de retorno. Es una forma garantizada de pagar dos veces el mismo problema: una vez en el diseño que se evitó hacer, y otra en la limpieza posterior.

Rediseñar primero, automatizar después

La secuencia correcta no es negociable, aunque incomode a quien quiere resultados rápidos: primero se aplica una metodología de reingeniería de procesos que fuerce a tomar decisiones explícitas sobre entrada de datos, límites de cada tarea y manejo de excepciones. Recién después de eso tiene sentido evaluar qué parte del proceso conviene automatizar y con qué herramienta.

Esto significa, en la práctica, resistir la presión de automatizar "lo que ya está" solo porque está disponible y es visible. Significa preguntar, tarea por tarea, si existe una regla escrita que cubra el caso normal y una regla escrita que cubra las excepciones más frecuentes. Si la respuesta es "eso lo resuelve fulano según el caso", ese paso no está listo para un robot: está listo para que alguien se siente a definir el criterio que fulano usa en su cabeza y lo convierta en una regla que cualquiera pueda seguir, humano o máquina.

Tampoco hay que caer en el extremo contrario: usar la falta de estandarización perfecta como excusa permanente para no automatizar nunca. El objetivo no es exigir un proceso impecable en cada detalle, sino exigir que la parte que se va a automatizar tenga la madurez suficiente y una tasa de excepciones manejable. Automatizar el ochenta por ciento estable de un proceso y dejar el veinte por ciento ambiguo en manos humanas es una decisión razonable. Automatizar el cien por ciento asumiendo que la ambigüedad se resuelve sola no lo es.

La revisión que vale la pena hacer esta semana

Toma el proceso que tu organización está por automatizar, o el que ya automatizó y que sigue generando trabajo de corrección manual. Pide que alguien describa por escrito, sin usar la palabra "depende", cómo se resuelve el caso más común y cómo se resuelven las tres excepciones más frecuentes. Si esa descripción no existe, o existe solo en la memoria de una persona clave, no tienes un proceso listo para automatizar: tienes un proceso que primero necesita una decisión de diseño.

La pregunta que conviene instalar en el próximo comité no es "qué herramienta de automatización conviene". Es esta: ¿qué porcentaje de las excepciones de este proceso está documentado como regla, y qué porcentaje sigue viviendo únicamente en el criterio de alguien que un día se puede enfermar, cambiar de rol o irse de la empresa? Esa cifra, aunque sea aproximada, dice más sobre el riesgo real del proyecto que cualquier proyección de ahorro en la propuesta.