Hay un momento característico en todo proyecto de automatización, y siempre llega en la misma fase. Se ha decidido automatizar un proceso, se sienta uno con las personas que lo ejecutan para describirlo paso a paso, y a la tercera pregunta aparece el silencio.
"¿Y en este caso qué se hace?" "Pues depende." "¿De qué?" "De si el interesado es..." "¿Y eso dónde consta?" "En ningún sitio, se sabe."
Ese silencio es, en mi experiencia, el hallazgo más valioso de todo el proyecto.
Lo que la automatización revela
Un proceso ejecutado por personas tolera la ambigüedad. Las personas resuelven los casos raros con criterio, aplican excepciones que nadie escribió, preguntan a un compañero, deciden por analogía con algo que pasó hace cinco años.
Todo eso funciona razonablemente bien y es invisible. No aparece en ningún diagrama porque nadie lo ha formulado nunca: forma parte del "saber hacer" acumulado.
Automatizar obliga a explicitarlo. Una máquina no puede resolver por analogía ni preguntar al de al lado: necesita una regla. Y al intentar escribir esa regla se descubren tres cosas incómodas.
Que hay decisiones que se toman con criterios que nadie ha acordado. Que dos personas del mismo servicio resuelven el mismo caso de forma distinta, y ninguna lo sabía. Y que algunos pasos existen por razones que ya no se recuerdan.
El error de automatizar tal cual
La tentación entonces es replicar lo que hay, con las excepciones que se hayan podido documentar, para no abrir un melón organizativo.
Es un error caro por dos motivos.
El primero: se codifica el desorden. Las inconsistencias que antes eran flexibilidad se convierten en reglas contradictorias dentro de un sistema, y arreglarlas después cuesta un desarrollo en vez de una conversación.
El segundo: se pierde la oportunidad. Ese momento, con las personas que ejecutan el proceso sentadas en la misma sala hablando de cómo lo hacen, es dificilísimo de conseguir. No volverá a producirse hasta el siguiente proyecto. Desaprovecharlo para limitarse a copiar es tirar lo único verdaderamente escaso.
Lo que hago cuando aparece el silencio
Parar y documentar el hallazgo. Antes de resolverlo, dejarlo escrito: aquí hay una decisión sin criterio establecido. Esa lista, al final del análisis, suele ser el documento más útil de todo el proyecto.
Separar lo que hay que decidir de lo que hay que programar. Muchas de esas ambigüedades no son cuestiones técnicas: son decisiones de gestión que llevaban años sin tomarse porque el sistema manual permitía no tomarlas. Necesitan a alguien con autoridad, no a un analista.
Preguntar por el origen. "¿Por qué se hace este paso?" tiene tres respuestas posibles: porque lo exige una norma —comprobable—, porque evita un problema concreto —comprobable—, o porque siempre se ha hecho así. La tercera respuesta aparece más veces de lo que uno esperaría, y es una invitación a eliminar el paso.
Dejar la excepción fuera. Si el 95% de los casos sigue un camino claro y el 5% requiere criterio, automatizar el 95% y dejar el resto a una persona es mucho mejor que intentar cubrir el 100% con reglas. Además, hace explícito que ese 5% requiere criterio humano, lo cual protege a quien lo ejerce.
El fondo del asunto
Llevo tiempo pensando que el mayor valor de estos proyectos no está en el ahorro de tiempo, que suele ser menor de lo prometido.
Está en que obligan a una organización a mirar de frente cómo funciona realmente. No cómo dice el manual, ni cómo cree la dirección: cómo se resuelve un martes por la mañana un caso que no encaja.
Esa conversación casi nunca se tiene por sí sola. Hace falta una excusa, y la automatización es una excusa excelente.
Aunque a veces, después de tenerla, la conclusión sensata sea no automatizar nada todavía.