Qué pasó
Starbucks anunció un sistema de conteo de inventario basado en visión por computadora: en lugar de que alguien recorriera el almacén con una planilla, el sistema reconocía producto en imágenes y estimaba las existencias. La promesa era buena y del tipo que sí conviene automatizar, porque el conteo manual es repetitivo, consume tiempo del personal de tienda y se hace con la misma frecuencia todos los días.
Nueve meses después, la compañía lo desconectó. Lo reportó Restaurant Dive.
Nueve meses no es el tiempo que tardó la tecnología en fallar. Es el tiempo que tardó la organización en enterarse de que no servía como estaba desplegada.
Por qué pasó
El inventario tiene una propiedad que casi ningún otro proceso ofrece: existe un dato verdadero contra el cual comparar. El conteo manual está ahí, es tedioso pero es exacto, y permite responder la única pregunta que importa antes de escalar: ¿cuánto se separa lo que dice el sistema de lo que hay en la bodega?
Esa comparación era posible desde el primer día y no era cara. Un grupo acotado de tiendas contando en paralelo durante unas semanas produce la diferencia real, tienda por tienda, con las condiciones de una tienda de verdad: cajas apiladas fuera de lugar, luz distinta según la hora, empaques que cambian de diseño, producto que se mueve mientras se cuenta. Un almacén operando no se parece al escenario de una demostración, y ese es justamente el dato que un piloto entrega.
Lo que ocurrió fue lo contrario: se lanzó a toda una red algo que no se había probado contra el conteo real. Y cuando una automatización llega a la operación completa sin línea base, deja de ser un experimento con salida y se convierte en un cambio de proceso. Ahí el costo se multiplica: hay que capacitar a todo el personal, hay que sostener el conteo manual en paralelo porque nadie confía del todo, y cada tienda que ve un número raro pierde un poco más de confianza en el sistema. Ese desgaste es el que se paga durante nueve meses.
Dónde te puede pasar a ti
El patrón se repite cada vez que una herramienta se enciende para todos a la vez sin comparar contra el proceso que reemplaza:
- Un lector de facturas que en la demostración procesó veinte documentos limpios y en producción recibe fotos torcidas y con sombra.
- Un bot de atención que se abre a todos los clientes sin haber corrido antes en paralelo con el equipo humano sobre las mismas conversaciones.
- Un sistema de clasificación de pedidos que nadie comparó contra la clasificación que hacía el operador.
- Cualquier automatización cuyo criterio de éxito no se escribió antes de encenderla.
Cómo se evita
- Línea base primero. Se mide el proceso actual antes de tocarlo: cuánto tarda, cuánto se equivoca, cuánto cuesta. Sin ese número, cualquier resultado del sistema nuevo es una opinión.
- Piloto acotado corriendo en paralelo. El sistema hace su trabajo y la persona sigue haciendo el suyo. Se comparan las dos salidas todos los días y la diferencia se anota.
- Umbral de aceptación escrito antes de empezar, con fecha de decisión. Qué diferencia es tolerable y qué día se decide si escala o se apaga. Un piloto sin fecha se transforma solo en un despliegue.
- Apagado reversible. Volver al proceso anterior tiene que costar minutos, no un trimestre. Si el retorno es caro, la decisión de apagar se pospone aunque los números ya la pidan.
Cómo lo hacemos en Catalizadora
Ninguna automatización nuestra se enciende para toda la operación el primer día. Corre en paralelo con el proceso existente sobre un grupo acotado, con la línea base medida antes, un número de aceptación escrito y una fecha puesta para decidir. Si no llega a ese número, se apaga sin haber tocado el resto de la operación y sin haber pedido a nadie que cambie su forma de trabajar.