Las cuarenta y un mil fotos que nadie volvió a mandar

Una empresa de última milla entrega 300.000 paquetes por día en tres países. Al dejar cada paquete, el repartidor saca una foto: la etiqueta, la puerta, el paquete apoyado. Un modelo lee la etiqueta de esa foto y confirma que la dirección de la entrega coincide con la del envío. Es lo que evita que un paquete quede marcado como entregado en la casa equivocada.

El modelo es del proveedor, corre afuera y factura por llamada. Es, con diferencia, la pieza más cara del sistema: USD 200 por mes de base, más consumo.

El viernes 12, entre las 14 y las 18, el proveedor empezó a rechazar llamadas por límite de tasa: acepta 600 por minuto y el sistema le estaba mandando más. Cada rechazo se anotó como error en el registro del proceso y ahí terminó la historia. 41.000 fotos quedaron sin leer.

El lunes, cuando quisieron reprocesarlas, aparecieron las dos mitades del problema. La primera: no había ninguna lista de cuáles eran. El pedido de lectura existía solamente adentro del proceso que lo estaba atendiendo, y ese proceso ya se había reiniciado. La segunda: la foto tampoco estaba. El sistema guarda lo que el modelo leyó, no lo que el repartidor sacó. No había nada que volver a mandar.

Y hay una tercera cosa que se descubrió esa misma semana: nadie sabía cuántas llamadas al modelo hacía el sistema por día. La primera medición fue la factura.

El equipo tiene un techo de 7 unidades operativas y hoy usa 4. Cada pieza que agregues sale de ese número, y el modelo ya se lleva una.

Rearmá el sistema con tres cosas en la cabeza. Una: el pedido de lectura tiene que existir en algún lado que sobreviva a un reinicio, o un mal rato del proveedor se lleva el trabajo. Dos: la foto original tiene que quedar guardada, porque es lo único contra lo que se puede volver a intentar. Tres: el gasto del modelo se tiene que poder mirar antes del día 5 del mes siguiente.