La pregunta aparece siempre en la segunda reunión, casi con las mismas palabras: «vale, ¿y por dónde empezamos?». Para entonces el equipo ya ha hecho la lista mental de todo lo que le gustaría quitarse de encima, y esa lista suele tener entre quince y treinta cosas. El problema no es que falten candidatos. El problema es que el orden en el que se acometen determina si el proyecto genera confianza dentro de la empresa o si muere en el tercer mes.
Conviene decirlo pronto, porque ahorra discusiones: el primer proceso que se automatiza no debería ser el más importante. Debería ser el que demuestra antes que esto funciona.
Por qué empezar por lo que más molesta suele salir mal
El instinto de cualquier dirección es atacar el dolor más agudo. Si la facturación mensual se lleva tres días de trabajo manual, la facturación mensual parece el sitio evidente por donde entrar. En la práctica, el proceso que más duele casi siempre es también el más enredado: tiene más excepciones, toca más departamentos, y suele depender de decisiones que nadie ha escrito nunca en ningún sitio.
Automatizar eso lo primero significa pasar seis o siete semanas sin entregar nada visible, resolviendo casos raros y peleando con áreas que todavía no confían en el proyecto. Cuando por fin se entrega, media empresa ha perdido interés y la otra media ha desarrollado la sospecha de que la automatización es cara y lenta. Es una manera excelente de que el segundo proyecto no llegue nunca.
Cómo decidimos cuál va primero
En una empresa con procesos administrativos recurrentes, el orden se puede razonar con bastante frialdad. Estos son los criterios que aplicamos, y no valen por separado sino combinados:
- Frecuencia por encima de duración. Una tarea de cuatro minutos que ocurre ochenta veces por semana devuelve mucho más que una de dos horas que ocurre una vez al mes. La intuición de la gente falla justo aquí, porque recordamos las tareas largas y olvidamos las repetitivas.
- Que el resultado sea comprobable. Si al terminar no se puede enseñar un número que antes era otro, el proyecto no se puede defender ante quien lo paga.
- Que dependa de pocas personas. Cada área implicada añade una ronda de validación y un riesgo de bloqueo. El primer proyecto ideal vive dentro de un solo equipo.
- Que las herramientas implicadas tengan API decente.Esto no se ve desde dirección, pero cambia el coste por tres. Conectar dos sistemas documentados es cuestión de días. Sacar datos de un programa cerrado que solo exporta PDF puede costar más que todo lo demás junto.
Cuando un proceso cumple los cuatro, se automatiza. Cuando cumple dos, se pospone. No hay mucho más misterio.
¿Y si el proceso está mal planteado?
Es la pregunta que menos se hace y la que más dinero ahorra. Una parte considerable de los procesos administrativos de cualquier empresa no existen porque alguien los diseñara, sino porque alguien los improvisó un martes hace seis años y nadie los ha vuelto a mirar desde entonces.
Automatizar un proceso que nadie ha revisado no lo mejora. Lo congela y lo hace más difícil de cambiar.
Antes de conectar nada preguntamos por qué existe cada paso. En bastantes casos la respuesta es que se hacía así para un cliente que ya no está, o para cumplir un requisito que cambió. Esos pasos no se automatizan: se eliminan, que sale gratis y es más rápido. Solo cuando el proceso depurado sigue teniendo sentido tiene sentido construir sobre él.
El tamaño del primer proyecto
Nuestro primer encargo en una empresa nueva rara vez pasa de cinco semanas. No es una cuestión de precio sino de aprendizaje: durante ese primer proceso descubrimos cómo trabaja realmente el equipo, qué sistemas mienten en su documentación, quién decide de verdad y con qué velocidad responde la organización. Toda esa información hace que el segundo proyecto se estime mucho mejor que el primero.
Hay otra razón, menos técnica. Una entrega corta que funciona cambia la conversación interna. Deja de discutirse si automatizar sirve y empieza a discutirse qué automatizar después, que es una discusión mucho más productiva y en la que la empresa ya participa aportando ideas propias.
Lo que dejamos para más adelante
Hay tipos de proceso que sistemáticamente van al final de la cola, aunque el ahorro teórico sea grande. Todo lo que implique decisiones con criterio humano poco codificado, por ejemplo, o cualquier cosa que toque nóminas y contratación, donde un fallo tiene consecuencias que no se arreglan reprocesando un fichero. También esperamos con los procesos que dependen de un software que la empresa ya está pensando en cambiar, porque construir encima de algo que va a desaparecer es tirar el presupuesto.
Y queda un caso que conviene nombrar: cuando no hay nadie dentro de la empresa que vaya a hacerse cargo del sistema entregado. Ahí no posponemos, directamente no lo hacemos. La automatización traslada la dependencia, no la elimina, y una dependencia sin dueño es un problema futuro con fecha desconocida.
Cómo se hace este ejercicio en la práctica
No hace falta una auditoría larga. Con dos conversaciones de cuarenta minutos con las personas que ejecutan la operativa, y no con quienes la describen desde arriba, sale una lista ordenada bastante fiable. Las preguntas útiles son concretas: qué hiciste ayer que ya habías hecho el día anterior, qué información copias de un sitio a otro, qué informe preparas a mano y para quién.
De ahí sale el primer proyecto. Y del primer proyecto sale, casi siempre, una lista mejor que la que había al principio.
Si quieres ver cómo abordamos esto como encargo, está detallado en automatización de procesos, y los rangos por tipo de proyecto están publicados en cuánto cuesta digitalizar una empresa.