Hay algo profundamente irónico en la forma en que muchas organizaciones se acercan a la automatización. Se presenta como una promesa de eficiencia, como una solución casi inevitable para escalar operaciones sin aumentar costos. En reuniones estratégicas se habla de flujos automáticos, de decisiones asistidas por inteligencia artificial, de procesos que ya no dependerán de la intervención humana. La automatización es “la pomada canaria”. Y todo suena lógico. Todo parece alineado con una narrativa muy atractiva: si logramos automatizar lo suficiente, podremos hacer más con menos. Menos personas (aunque la idea no es despedir sino reasignar), menos errores, menos tiempo perdido en tareas repetitivas. El problema es que esa historia suele omitirse una parte incómoda. Automatizar algo no lo vuelve necesariamente mejor. Automatizar simplemente significa que el sistema ejecutará un proceso de forma automática, exactamente como fue diseñado. Y si el proceso fue diseñado mal, el sistema lo ejecutará mal… solo que ahora lo hará con más velocidad, más consistencia y muchas más veces al día.
Con los años uno aprende a reconocer este patrón con facilidad. Aparece en empresas de todos los tamaños y en prácticamente todas las industrias. El proyecto se aprueba con entusiasmo, se implementa una plataforma poderosa, el equipo celebra que finalmente el proceso está “automatizado” –“¡Ahora sí vamos a resolver nuestros dolores de cabeza!… y semanas o meses después empiezan a aparecer las señales extrañas. El sistema genera más excepciones de las esperadas. Los equipos comienzan a crear caminos paralelos para resolver situaciones que el flujo no contempla. Las personas empiezan a decir cosas como “el sistema no nos deja hacerlo” o “esto antes lo resolvíamos más rápido”. Nadie dirá abiertamente que el proceso se volvió peor, pero la sensación empieza a instalarse lentamente. Y lo curioso es que el problema rara vez está en la tecnología. Lo que suele fallar es algo mucho más básico: se automatizó un proceso que ya era defectuoso desde el principio.
Una de las escenas más frecuentes en proyectos de automatización es también una de las más silenciosas. El equipo identifica un proceso que consume mucho tiempo. Tal vez requiere varias aprobaciones, involucra diferentes áreas o depende de correos electrónicos interminables para avanzar. El diagnóstico parece obvio: el problema es la falta de automatización. Entonces se propone implementar un sistema que gestione el flujo, notifique a los responsables, registre las decisiones y asegure que cada paso ocurra en el orden correcto -lo típico. A primera vista, la lógica parece impecable. Lo que casi nunca ocurre en ese momento es algo mucho más simple y al mismo tiempo mucho más incómodo, que es detenerse a analizar si el proceso en sí tiene sentido.
¿Alguien se preguntó por qué el proceso tiene tantos pasos? ¿Por qué existen ciertas validaciones? ¿Qué riesgos se intentaban evitar cuando se diseñó ese flujo? ¿Siguen existiendo esos riesgos hoy? En muchas organizaciones estas preguntas no aparecen porque el proceso ya forma parte del paisaje operativo. “Llevamos 30 años haciéndolo así” ó “Así se ha hecho toda la vida”. Nadie recuerda exactamente cuándo se definió, pero todos saben que así se hace. Y cuando algo ha funcionado durante años, aunque sea de forma imperfecta, a nadie se le ocurre cuestionarlo. De modo que la automatización avanza con un objetivo bastante claro que es replicar digitalmente lo que ya ocurre. El resultado es predecible. El sistema ejecuta el proceso exactamente como fue definido. Los mismos pasos, las mismas aprobaciones, las mismas dependencias entre áreas, la misma burocracia. Solo que ahora todo ocurre dentro de una plataforma.
A veces la automatización se presenta como un gran salto hacia la eficiencia, pero cuando uno observa con calma lo que realmente se implementó, descubre algo mucho más modesto: simplemente se digitalizó la burocracia existente. Un proceso que antes dependía de correos electrónicos ahora ocurre dentro de un sistema. Las aprobaciones que antes se registraban informalmente ahora aparecen como estados dentro de un flujo. Hay notificaciones automáticas, trazabilidad y dashboards que muestran en qué etapa se encuentra cada solicitud. Desde fuera, todo parece más ordenado. El problema es que el proceso que se automatizó puede seguir siendo innecesariamente complejo.
Imaginemos un flujo que requiere cinco aprobaciones para avanzar. Nadie recuerda con claridad por qué son cinco. Probablemente en algún momento existieron razones válidas: controles financieros más estrictos, mayor riesgo operativo o simplemente una organización más pequeña e inexperta que necesitaba revisar todo manualmente mientras el personal aprendía a hacerlo. Con el tiempo el proceso sobrevivió y se convirtió en la forma “normal” de hacer las cosas. Cuando llega la automatización, la discusión rara vez gira en torno a reducir esas aprobaciones. El objetivo es construir un flujo que permita gestionarlas de forma digital. Cada responsable recibe su notificación, revisa la solicitud, aprueba o rechaza y el sistema registra la decisión. El proceso ahora se ve elegante en pantalla, pero sigue teniendo cinco aprobaciones. Y lo más curioso es que ahora será mucho más difícil cambiarlo, porque lo que antes era una práctica organizacional flexible ahora es una lógica programada o “quemada” dentro de un sistema.
Cuando un proceso manual tiene defectos, las personas suelen encontrar formas de adaptarse. Le buscan la comba al palo como se dice popularmente. La experiencia y el criterio funcionan como mecanismos de compensación. Si una aprobación es innecesaria, alguien llama directamente al responsable para acelerar el proceso. Si una regla no contempla un caso particular, las personas conversan y deciden cómo proceder. La informalidad, en cierta medida, permite que la organización sobreviva a sus propios procesos imperfectos. Pero cuando ese mismo proceso se automatiza, esa flexibilidad desaparece. Y nos damos cuenta que nos metimos en una camisa de fuerza y de paso muy costosa.
Los sistemas no improvisan. Los sistemas ejecutan reglas. Y cuando las reglas fueron definidas sin cuestionar su lógica, el sistema las aplicará con absoluta disciplina. Es en ese momento cuando empiezan a aparecer situaciones curiosas. El sistema bloquea una solicitud porque falta una validación que nadie considera realmente necesaria. El flujo no permite avanzar porque una condición específica no se cumple exactamente como fue programada. Las personas saben que el caso debería resolverse de otra manera, pero el sistema no contempla esa posibilidad. Entonces empiezan a aparecer soluciones improvisadas alrededor del sistema. Registros duplicados, correos paralelos, excepciones que se gestionan manualmente fuera de la plataforma. En lugar de simplificar el proceso, la automatización termina generando nuevas capas de complejidad.
En las conversaciones sobre transformación digital aparece con frecuencia una confusión conceptual bastante persistente. ¡Y yo la odio! Muchas organizaciones hablan de automatización como si fuera sinónimo de optimización. Sin embargo, ambas cosas responden a preguntas completamente distintas. Automatizar significa ejecutar un conjunto de pasos de manera automática. Por el contrario, optimizar significa cuestionar si esos pasos deberían existir en primer lugar. El problema es que cuestionar procesos puede ser incómodo. Implica revisar decisiones que alguien tomó en el pasado, revisar supuestos que tal vez ya no aplican y reconocer que algunas prácticas se mantuvieron simplemente por costumbre. Eso impacta el ego y un ego herido no colabora.
Por esa razón, muchas iniciativas de automatización comienzan directamente con el diseño del flujo digital. Se define quién aprueba qué, en qué orden ocurren las validaciones y qué condiciones activan cada etapa del proceso. Lo que casi nunca aparece en esa conversación es una pregunta mucho más radical: ¿este proceso podría ser más simple? Tal vez algunas decisiones podrían eliminarse. Tal vez ciertas aprobaciones no agregan valor. Tal vez el proceso existe solo porque alguna vez existió una razón que hoy ya no aplica. Mea culpa que al inicio de mi carrera como consultor yo tampoco las hacía. Cuando esas preguntas no se hacen, la automatización se convierte en una forma sofisticada de preservar la complejidad existente.
Un proceso defectuoso ejecutado manualmente tiene un impacto relativamente limitado. Puede generar fricción, consumir tiempo o provocar retrasos, pero las personas suelen encontrar formas de adaptarse y sacar la tarea. El problema se vuelve mucho más serio cuando ese mismo proceso se automatiza. La automatización introduce velocidad y escala. El flujo que antes se ejecutaba unas pocas veces al día ahora puede ejecutarse decenas o cientos de veces. Las decisiones que antes dependían de conversaciones ahora se convierten en reglas programadas que afectan a toda la organización. En ese contexto, un pequeño error de diseño deja de ser un molesto inconveniente operativo y se convierte en un problema estructural.
Además, corregir ese problema después suele ser mucho más difícil. Lo que antes era un hábito organizacional ahora está incrustado en la arquitectura del sistema. Cambiarlo implica revisar lógica, modificar integraciones y realizar pruebas para asegurarse de que otros procesos no se vean afectados. De pronto, algo que podría haberse resuelto con una conversación entre equipos se convierte en un proyecto técnico.
Existe una expectativa silenciosa que aparece en muchos proyectos de automatización. Se espera que la tecnología introduzca orden en procesos que la organización nunca logró estructurar del todo. Responsabilidades difusas, reglas ambiguas o decisiones que dependen de interpretaciones individuales. En ese contexto, el sistema parece ofrecer una solución atractiva. Si todo queda definido dentro de un flujo automatizado, el proceso debería volverse más claro. Sin embargo, los sistemas no inventan orden. Los sistemas ejecutan reglas. Y si las reglas no están claras, el sistema simplemente reflejará esa misma ambigüedad en forma de excepciones, bloqueos o flujos que nadie termina de entender.
Con el tiempo empiezan a aparecer comentarios familiares dentro de la organización. Las personas dicen que el sistema es demasiado rígido, que no contempla ciertos casos o que obliga a seguir pasos innecesarios. Simplemente que no se adapta a la organización. Pero el sistema solo está ejecutando lo que se le pidió que ejecutara. En muchos casos lo más irónico es que la tecnología termina exponiendo, con mayor claridad, los problemas de diseño que ya existían en el proceso original.
Cuando se analiza un proyecto de automatización, la conversación suele concentrarse en los costos visibles: licencias de software, tiempo de implementación, integraciones con otros sistemas. Sin embargo, existe otro tipo de costo que rara vez aparece en los análisis iniciales. Es el costo de institucionalizar procesos que tal vez nunca debieron existir. Cada proceso innecesario que se automatiza se convierte en algo que la organización tendrá que mantener, actualizar y soportar durante años. Con el tiempo se agregan nuevas reglas, nuevas validaciones y nuevas dependencias con otros sistemas. Ya te imaginas todo el mantenimiento que tendrá que estar dando TI por cada excepción que salió después del go-live.
La paradoja es que el objetivo original era reducir complejidad operativa. Pero cuando se automatiza sin cuestionar el proceso, la complejidad simplemente cambia de lugar. Deja de estar en la interacción entre personas y pasa a vivir dentro del sistema.
Curiosamente, cuando uno observa organizaciones que han logrado automatizar procesos con verdadero impacto, el punto de partida suele ser muy distinto. Antes de hablar de tecnología, hablan de procesos, eso dice mi amigo Joe. Antes de construir flujos digitales, revisan decisiones. Antes de programar reglas, eliminan pasos innecesarios. Ese ejercicio suele producir descubrimientos interesantes. Procesos que parecían complejos pueden simplificarse significativamente cuando se revisan sus supuestos. Algunas aprobaciones dejan de tener sentido. Algunas validaciones pueden consolidarse. Algunas decisiones pueden automatizarse porque en realidad siguen reglas bastante claras.
En ese punto, la automatización deja de ser un intento de domesticar la complejidad. Se convierte en una forma de sostener la simplicidad que ya se logró en el rediseño del proceso. ¡Me encanta esa frase!
Después de ver muchos proyectos de automatización, uno termina llegando a una conclusión bastante sencilla. La tecnología no corrige procesos malos. Los procesos malos automatizados siguen siendo malos, solo que ahora se ejecutan más rápido, con más consistencia y con mayor alcance dentro de la organización. Y cuando eso ocurre, la empresa termina con algo que nadie esperaba al inicio del proyecto. Tiene más tecnología, más sistemas y más automatización… peeeero no necesariamente tiene mejores procesos.
Tal vez por eso la pregunta más importante en cualquier iniciativa de automatización no debería ser qué tecnología implementar o qué plataforma utilizar. La pregunta realmente incómoda aparece antes de todo eso. Aparece cuando alguien se detiene a observar el proceso con calma y se atreve a formular una duda que rara vez se plantea al inicio de los proyectos.
¿De verdad necesitamos que esto ocurra de esta manera? ¿Vos qué pensás?