Software para logística y última milla en México: qué construir primero

Cuando una operación de distribución decide invertir en software, la lista de deseos casi siempre empieza por el ruteo inteligente: un algoritmo que arme las rutas del día y ahorre kilómetros. Es una aspiración razonable y, al mismo tiempo, el módulo que menos conviene construir primero.

El ruteo optimiza sobre datos. Si hoy no sabes con certeza qué se entregó, a qué hora, a quién y por qué falló lo que no se entregó, no hay nada confiable que optimizar. El orden de construcción importa más que la lista de módulos.

¿Por qué el orden de construcción importa más que el módulo?

Cada capa de un sistema logístico consume los datos que produce la anterior. Las notificaciones al cliente dependen de un estatus de entrega confiable. La integración con el ERP depende de que la entrega quede registrada con un formato consistente. El ruteo depende de conocer tiempos reales de servicio por zona y por tipo de cliente.

Cuando se construye en desorden, cada módulo nuevo hereda la mala calidad de los datos del anterior. El resultado típico es un tablero bonito que nadie en operación cree, y un equipo que vuelve a la hoja de cálculo para saber qué pasó realmente en el día.

Por eso proponemos una secuencia: visibilidad, app del repartidor, integración, comunicación con el cliente y, al final, optimización. Cada etapa debería justificar su costo antes de pasar a la siguiente, y cada una deja datos más limpios para la que sigue.

¿Qué construir primero? Visibilidad de cada entrega

El primer módulo no es tecnológicamente sofisticado, pero es el que más cambia la operación: saber en todo momento el estatus de cada entrega y tener evidencia verificable de lo que ocurrió en el punto de destino.

• Estatus por entrega, no por ruta: asignada, en camino, entregada, fallida o reprogramada, con la hora de cada cambio.
• Evidencia de entrega: foto del paquete en destino, firma o nombre de quien recibe y la ubicación del dispositivo al momento de cerrar la entrega.
• Motivos de entrega fallida en un catálogo cerrado: cliente ausente, domicilio incorrecto, rechazo, acceso restringido. Un campo de texto libre no se puede analizar después.
• Registro del cobro contra entrega: monto cobrado, forma de pago y diferencias contra lo esperado, ligado a la entrega y no a una libreta.

Con esto resuelto, las disputas con clientes dejan de ser palabra contra palabra, las entregas fallidas se pueden clasificar por causa y la conciliación del efectivo deja de depender de la memoria del repartidor. Varias de estas tareas de conciliación se pueden automatizar después; lo explicamos en automatización de procesos.

¿Por qué la app del repartidor tiene que funcionar sin señal?

La cobertura celular en México es irregular. Hay zonas rurales, tramos de carretera, sótanos de centros comerciales, andenes de carga y edificios donde el teléfono simplemente no conecta. Una app que exige conexión para cerrar una entrega obliga al repartidor a volver a capturar después, o a no capturar.

El diseño correcto es offline primero: la app guarda cada entrega, foto y firma en el dispositivo y sincroniza en cuanto recupera señal, sin que el repartidor tenga que hacer nada. Es una decisión de arquitectura que se toma al inicio; agregarla después es mucho más caro que construirla desde el principio.

• Cola de sincronización que sobreviva a que la app se cierre o el teléfono se reinicie.
• Fotos comprimidas en el dispositivo para no saturar datos móviles ni tardar horas en subir.
• Cierre de entrega en pocos toques, con botones grandes, pensado para usarse con una mano y con prisa.
• Hoja de ruta descargada al inicio del turno, con direcciones, referencias y montos a cobrar.
• Indicador visible de qué está pendiente de sincronizar, para que el supervisor sepa si un hueco es falta de señal o falta de captura.

Si la flotilla es propia y los equipos son de la empresa, una app híbrida suele ser suficiente. Si depende de cámara, escáner de códigos o GPS en segundo plano de forma intensiva, conviene evaluar con cuidado la tecnología. Lo detallamos en desarrollo de aplicaciones móviles nativas e híbridas.

¿Cuándo integrar con el ERP o el WMS?

En cuanto la captura en campo sea confiable. El síntoma que indica que llegó el momento es la recaptura: alguien exporta los pedidos del ERP a Excel para armar las rutas y, al final del día, alguien más captura en el ERP lo que se entregó. Cada recaptura es una oportunidad de error y un retraso en la facturación.

La integración correcta es por API, en dos direcciones: los pedidos listos para salir fluyen del ERP o del WMS a la plataforma de entregas, y los estatus, cobros y evidencias regresan al ERP sin intervención humana. Escribimos sobre cuándo usar API y cuándo otras capas en API, RPA o IoT: cuándo cada uno, y sobre cómo diseñarlas en desarrollo de APIs.

Si el ERP es antiguo y no expone una API, no es motivo para detener el proyecto. Se puede construir una capa intermedia que lea y escriba en su base de datos de forma controlada, mientras se planea una modernización.

Notificaciones al cliente final: ¿cuándo sí valen la pena?

Avisar al cliente que su pedido va en camino reduce entregas fallidas por ausencia, que suelen ser de las más costosas porque obligan a una segunda visita. Pero solo funciona si el estatus en el que se basa el aviso es confiable. Una notificación que promete una ventana de entrega que no se cumple genera más llamadas al centro de atención que no avisar.

Por eso este módulo va después de la visibilidad y de la app. Los canales habituales son WhatsApp, SMS y correo; en México, WhatsApp suele tener mejor respuesta, pero requiere usar la plataforma oficial para empresas y plantillas aprobadas. Lo más útil es permitir que el cliente confirme, reprograme o deje instrucciones de acceso antes de que llegue el repartidor.

¿Y el ruteo? Casi siempre se compra

La optimización de rutas es un problema matemático complejo que resuelven bien productos especializados, con años de desarrollo y mapas actualizados detrás. Construir un motor de ruteo propio rara vez se justifica. Lo que sí conviene construir es la integración: que las rutas optimizadas lleguen a la app del repartidor y que los tiempos reales de servicio regresen al motor para mejorar las siguientes.

La excepción son operaciones con restricciones muy particulares que ningún producto de mercado modela bien: ventanas de recepción negociadas cliente por cliente, vehículos con permisos de circulación distintos o combinaciones de entrega y recolección con reglas propias.

¿Cómo decidir entre comprar y construir?

La pregunta no es ideológica. Hay plataformas de última milla muy buenas y, para una operación estándar, empezar con una de ellas es lo sensato. Construir se justifica cuando se cumple alguna de estas condiciones:

• La forma en que entregas es parte de tu ventaja competitiva y un producto de mercado te obligaría a operar como todos los demás.
• El producto disponible exige cambiar procesos que funcionan bien solo para ajustarse a la herramienta.
• Necesitas cruzar datos de entrega con información propia, como crédito del cliente, precios especiales o inventario en ruta, que la plataforma no puede recibir.
• El costo de licencias por usuario o por entrega crece con tu volumen de forma que, a mediano plazo, deja de tener sentido frente a un sistema propio.

Una ruta intermedia que funciona bien es comprar el ruteo y la mensajería, y construir la app del repartidor, la visibilidad y la integración. Así el conocimiento de la operación queda en un sistema tuyo y las piezas genéricas se reemplazan si aparece una mejor opción.

Sea cual sea la decisión, define desde el principio quién es dueño de los datos de entrega y quién puede modificarlos. Si las evidencias y los cobros viven solo en la plataforma de un tercero, cambiar de proveedor se vuelve un problema. Lo tratamos en gobernanza de datos para empresas medianas.

Errores frecuentes al digitalizar la última milla

• Diseñar la app desde la oficina, sin acompañar a un repartidor durante un turno completo.
• Pedir demasiados datos por entrega: cada campo extra es un campo que se llena mal o no se llena.
• Tratar el cobro contra entrega como un tema contable separado, en lugar de parte del cierre de cada entrega.
• Medir solo entregas completadas y no la causa de las fallidas, que es donde está el ahorro.
• Lanzar a toda la flotilla al mismo tiempo, en lugar de empezar con una ruta o una zona y ajustar.

En logística, el primer software que se paga solo no es el que optimiza. Es el que dice la verdad sobre lo que pasó en cada entrega.