Contenido7 secciones
Qué automatizar primero, y por qué no es el peor trabajo
El instinto pide empezar por el proceso que todos odian. El radio de daño es mejor criterio, y suele señalar a otro sitio distinto.
El instinto falla de forma predecible
Pregunta a un equipo qué proceso automatizar primero y nombrará el que odia.
Ese trabajo suele ser minucioso, de alto riesgo y poco frecuente. La preparación de contratos. La conciliación de fin de mes. Eso que tiene que salir bien, lleva una tarde y ocurre dos veces al mes.
Como primer candidato es casi el peor posible, y por razones que nada tienen que ver con si merece automatizarse algún día.
El criterio es el radio de daño
Lo que ordena la lista es la pregunta de qué pasa cuando el sistema se equivoca, porque en un primer proyecto se va a equivocar.
| Proceso | Si falla | Radio de daño |
|---|---|---|
| Enrutado de consultas | Una respuesta va a la persona equivocada | 1 conversación, recuperable en minutos |
| Comprobación de disponibilidad | Se rechaza una reserva que se podía aceptar | 1 reserva, recuperable el mismo día |
| Montaje de documentos | Sale un contrato con condiciones erróneas | Un cliente, y quizá un problema legal |
| Precio o compromiso | La empresa queda obligada a algo | Un cliente, y el compromiso se mantiene |
Los dos primeros son sitios para aprender. Los dos últimos son sitios para tener cuidado, y de ahí vienen casi siempre las quejas.
La frecuencia convierte la obra en evidencia
El segundo criterio es cada cuánto se ejecuta, y decide cuánto esperas para saber algo.
Un proceso que ocurre cuarenta veces por semana da una respuesta utilizable en quince días. La misma obra sobre un proceso que ocurre dos veces al mes calla durante un trimestre, y para entonces el equipo ha dejado de mirar y el proveedor está en otra cosa.
De ahí también la razón práctica para que el primer proyecto quepa en dos a cuatro semanas. Un primer proyecto largo es una apuesta hecha antes de que llegue la información, y te compromete con un proveedor y un diseño en el momento en que menos sabes.
Cuál suele ser
De los cuatro procesos que más desplegamos, la atención de consultas entrantes suele ir primero.
Se ejecuta constantemente. Un error es una respuesta mal dirigida. Toca pocos sistemas, así que la integración no se come el calendario. Y produce un número rápido: en una implantación inmobiliaria, el tiempo de respuesta pasó de 6 horas a 8 minutos, y el ciclo de operación de 14 días a 5.
Ese segundo número es el que financia el siguiente proyecto, y conviene ver de dónde salió. Las respuestas rápidas no ahorraron la tarde a nadie de forma medible. Acortaron el ciclo, y los ciclos cortos convierten mejor porque menos compradores se enfrían en la pausa.
Cuando el candidato obvio toca dinero
Divídelo en vez de saltártelo, porque la parte que toca dinero rara vez es donde se va el tiempo.
En un flujo de pedidos, la comprobación de disponibilidad, el montaje de documentos y la programación del despacho pueden automatizarse mientras el compromiso, el precio y las condiciones se quedan con una persona. Consigues la frecuencia y el ahorro sin poner a un sistema de tres semanas en posición de obligar a la empresa.
No es una concesión para principiantes. Es el diseño que el sistema terminado tiene igualmente, por las razones expuestas en nuestras reglas para mantener a una persona en el circuito, y el flujo de pedidos en alquiler es un ejemplo trabajado de exactamente ese reparto.
Para qué sirve realmente el primer proyecto
Es la ocasión más barata que tendrás de aprender tres cosas que ninguna propuesta cuenta.
Cómo reacciona tu equipo ante un sistema que decide, que rara vez es como nadie predijo. Cuántas excepciones produce el proceso de verdad cuando alguien las cuenta, que casi siempre es más que la estimación. Y si el proveedor te avisa de los problemas antes de que los encuentres, que es la que debería decidir si hay un segundo proyecto.
Esas respuestas cambian la forma de lo que viene después. Elegir un primer proyecto incapaz de darlas en un mes es la parte cara de equivocarse aquí, y por eso el orden importa más que la lista.
Antes de todo esto
Nada de lo anterior ayuda si el proceso ya suspende la prueba de preparación, y las cinco condiciones de cuándo todavía no automatizar merecen pasarse antes de elegir orden alguno.
Saca el volumen de tus sistemas. Nombra al dueño. Y coge primero el frecuente y recuperable, aunque no sea del que se queja nadie.
01¿Por qué no empezar por el proceso del que más se queja el equipo?+
Porque la queja sigue al desagrado, y el desagrado no sigue ni al valor ni a la seguridad. El trabajo que todos odian suele ser minucioso, de alto riesgo y poco frecuente, que es casi la peor combinación posible para una primera automatización. Poco frecuente significa esperar meses hasta tener ejecuciones suficientes para saber si funciona. Alto riesgo significa que el primer error lo ve un cliente y no un compañero. Minucioso significa lleno de excepciones, que es justo el material que hace larga la obra y decepcionante el resultado. Ese proceso tiene su sitio, y el sitio es el segundo o el tercero, después de que el equipo aprenda cómo se comporta el sistema y de que alguien vigile una cola de excepciones unas semanas. Empezar por ahí es la forma más común de que un primer proyecto ponga a toda la organización en contra de la idea.
02¿Qué hace bueno a un primer candidato, en concreto?+
Cuatro propiedades, y las dos primeras pesan mucho más. Tiene que ejecutarse a menudo, porque la frecuencia es lo que convierte una obra en evidencia: un proceso que ocurre cuarenta veces por semana te dice si funciona en quince días, mientras que uno que ocurre dos veces al mes tarda un trimestre en decir nada. Tiene que fallar de forma recuperable, es decir, que una persona pueda deshacer el error antes de que afecte a un cliente. Necesita un dueño con nombre que vaya a vigilarlo de verdad. Y debería tocar pocos sistemas, para que el trabajo de integración no domine el calendario. El enrutado de consultas entrantes cumple las cuatro en la mayoría de las empresas pequeñas, por eso suele ir primero, y además produce el tipo de número que hace fácil financiar el segundo proyecto.
03¿El primer proyecto va de automatizar o de aprender?+
De ambas cosas, y tratarlo solo como el primero es el error. El primer proyecto es la ocasión más barata que tendrás de averiguar tres cosas que ninguna propuesta puede contarte: cómo reacciona tu equipo ante un sistema que toma decisiones, cuántas excepciones produce tu proceso de verdad cuando alguien las cuenta, y si el proveedor te avisa de los problemas antes de que los encuentres tú. Esas respuestas cambian lo que debería ser el segundo proyecto, y a veces cambian si habrá un segundo proyecto. Es también por eso que mantenemos el primero lo bastante pequeño para terminarlo en dos a cuatro semanas. Un primer proyecto de seis meses es una apuesta hecha antes de que llegue ninguna información, y te ata a un proveedor y a un diseño justo cuando menos sabes.
04¿Y si el candidato obvio toca dinero?+
Entonces divídelo en vez de saltártelo, porque la parte que toca dinero rara vez es la parte donde se va el tiempo. En un flujo de pedidos, la comprobación de disponibilidad, el montaje de documentos y la programación del despacho pueden automatizarse mientras el compromiso, el precio y las condiciones se quedan con una persona. Eso te da la frecuencia y el ahorro sin poner a un sistema recién nacido en posición de obligar a la empresa a algo. Es la misma regla que aplicamos siempre y no solo al principio: todo lo que obliga va a un humano, las excepciones se derivan con contexto completo y cada decisión automática queda registrada. Empezar por la parte que no obliga no es una concesión; es el diseño que el sistema terminado va a tener igualmente.
