Salomon Web Services
El software de transporte se consolidó en un puñado de plataformas que hacen bastante. Tableros de carga, despacho, liquidaciones, IFTA, mantenimiento, reportes de cumplimiento. Para una operación de carga general cubren casi todo el terreno.
La fricción aparece cuando la operación no es general.
Dónde deja de encajar la plataforma estándar
Carga especializada con requisitos propios. Refrigerada con obligaciones de monitoreo, materiales peligrosos con cadenas de documentación, sobredimensionado con control de permisos por jurisdicción. La plataforma tiene campos. No tiene el flujo de trabajo para lo que hace distinta a esa carga.
Operaciones dedicadas o por contrato. Correr rutas dedicadas para unos pocos clientes no es el mismo problema que la carga spot. La economía, el horizonte de planeación y la relación con el cliente son distintos, y las plataformas armadas alrededor de transacciones carga por carga lo modelan con torpeza.
Modelos mixtos. Flota propia con un brazo de brokerage, o transporte junto con almacenaje. Casi siempre significa dos sistemas que no se hablan y alguien cuadrando entre los dos.
Requisitos específicos de un cliente. Un embarcador grande quiere sus datos en su formato y en su horario. La plataforma exporta el formato de ella. Alguien tapa el hueco a mano, todas las semanas, para siempre.
Los números que a ti te importan. Ingreso por milla por ruta y por cliente, descontando los costos que tu operación de verdad tiene. Patrones de vacío. Retención de choferes contra asignación de rutas. Los reportes estándar cubren preguntas estándar, y las que definen tu rentabilidad casi nunca lo son.
Qué te está diciendo la capa de hojas de cálculo
Toda operación logística que corre una plataforma también corre hojas de cálculo. Rentabilidad por ruta. Margen por cliente. Planeación de asignaciones. Uso del equipo. Un reporte semanal que alguien arma para un cliente.
Ese conjunto es una especificación de lo que la plataforma no hace. También es un riesgo: sin documentar, mantenido por una persona, y guardando el análisis sobre el cual de verdad opera el negocio.
La pregunta no es si las hojas deberían existir. Es si la operación puede permitirse que sean la única versión de esa información.
Cómo se ve construir al lado
El patrón que funciona deja la plataforma para lo que resuelve y agrega lo que no.
Visibilidad operativa en un solo lugar. Cargas, choferes, equipo y compromisos con clientes en una sola vista, tomados de donde sea que vivan. Casi todas las operaciones responden “cómo va todo” revisando tres sistemas y preguntándole a dos personas.
Rentabilidad al nivel que tú decidas. Por ruta, por cliente, por chofer, por tipo de equipo, calculada de forma continua desde datos que ya existen en vez de armada cada mes.
Estatus para el cliente. Los embarcadores quieren saber dónde va su carga sin llamar. Un portal o un aviso automático se lleva la mayor parte de ese tráfico, y las llamadas que elimina son un costo real.
El flujo propio de tu carga. Control de permisos, excepciones de temperatura, documentación de detención, lo que tu nicho requiera y que la plataforma trata como un campo de notas.
Excepciones a la vista. Cargas atrasadas, equipo cerca de un servicio, un cliente cuyo volumen bajó, una ruta cuyo margen se erosionó. Cosas que necesitan atención, encontradas por el sistema y no por alguien revisando reportes.
La realidad de las integraciones
Este trabajo es en su mayoría integración, y en logística la integración es despareja.
Algunas plataformas tienen APIs sólidas. Otras las tienen limitadas. Otras funcionan con transferencias de archivos programadas en formatos anteriores a la web. Los proveedores de ELD, los tableros de carga y los sistemas de los clientes cada uno tiene lo suyo.
Esta es la parte que define costo y plazo, y hay que evaluarla antes de comprometer nada. Una construcción que asume acceso limpio a los datos y descubre lo contrario se pasa de presupuesto exactamente de la forma que le da mala fama al software a medida.
El consejo práctico: dimensiona la integración primero, como pieza propia de trabajo, antes de dimensionar el sistema que depende de ella.
Cómo juzgar si vale la pena
Cuenta las hojas de cálculo de las que la gente depende a diario. Pregunta cuántas horas por semana se van en armar información de varios sistemas. Pregunta qué cosas de la operación no se pueden responder hoy sin un proyecto.
Después pregunta cuánto cuesta una mala decisión tomada porque la información no estuvo a tiempo. En transporte la respuesta suele ser una ruta corrida sin margen durante meses, o un uso de equipo que nadie notó que se estaba cayendo.
Si esos números pesan contra lo que cuesta construir, el caso existe. Si la operación es lo bastante chica como para que una persona la sostenga cómodamente, quédate con las hojas y revísalo cuando eso deje de ser cierto.
Si tu operación corre sobre una plataforma más cinco hojas de cálculo, escríbenos. Construimos capas de visibilidad y flujo para transportistas y brokers alrededor de los sistemas que ya tienen.
Preguntas frecuentes
¿Hay que reemplazar el TMS?
Rara vez es la primera jugada. Los TMS manejan cargas, liquidaciones y reportes de cumplimiento que saldrían caros de reconstruir. Lo común es quedarse con el TMS y construir encima la capa de visibilidad y flujo que no da.
¿Y los datos del ELD y de cumplimiento?
Se quedan en los sistemas hechos para eso, y esos requisitos no vale la pena reimplementarlos. El valor de una capa propia suele estar en juntar esos datos con los de despacho, clientes y finanzas, que hoy viven separados.
¿Desde qué tamaño tiene sentido?
Depende menos del número de camiones que de cuánto de la operación corre en hojas de cálculo al lado del TMS. Una operación con tres o cuatro archivos de los que la gente depende a diario tiene caso, sin importar la flota.