Volver al blog
Business Intelligence Flotas Telemetría

De los partes de trabajo al coste por servicio: datos para gestionar una flota

Octubre 2026 Equipo Meular 9 min de lectura

Una flota deja dos relatos de la misma jornada. Uno es el parte de trabajo: lo que el conductor o el operario escribe al final del día, con sus servicios, sus incidencias y su letra. El otro es el que deja el vehículo sin que nadie lo escriba: posiciones, paradas, kilómetros, régimen de motor, tiempos de conducción. Los dos describen lo mismo y casi nunca coinciden, porque uno cuenta lo que se hizo y el otro registra lo que ocurrió. Montar BI para flotas industriales consiste, en buena medida, en construir el modelo donde esos dos relatos se encuentran y en decidir, caso a caso, qué se hace cuando discrepan. Este artículo describe ese modelo tal como lo hemos construido en una empresa del sector industrial y en distribución alimentaria: qué entidades lo componen, qué publica el vehículo, qué hay que estimar, cómo se empareja una parada con un cliente y qué inconsistencias aparecen siempre.

El parte de trabajo y la telemetría cuentan la misma jornada de dos maneras

El parte de trabajo es un documento de intención. Recoge lo que se planificó y lo que la persona recuerda al cerrar la jornada, agrupado como le resulta cómodo: a veces una línea por cliente, a veces una por tipo de trabajo, a veces una sola por todo el día. Es información valiosa porque contiene lo que ningún sensor sabe —qué se hizo, con qué material, por qué se tardó más— y es, al mismo tiempo, la fuente menos estructurada de todo el sistema.

La telemetría es lo contrario: completamente estructurada y completamente muda sobre el propósito. Sabe que el vehículo estuvo parado veinte minutos en un punto, y no sabe si eso fue una entrega, una avería o un café. Por eso ninguna de las dos fuentes sirve sola. El parte sin telemetría no se puede verificar; la telemetría sin parte no se puede interpretar.

La decisión de gestión que esto habilita es anterior a cualquier indicador: con las dos fuentes unidas, operaciones deja de discutir si un servicio se hizo y puede empezar a discutir cuánto costó. Son conversaciones distintas y solo la segunda lleva a alguna parte.

El servicio como unidad del modelo

El modelo se construye alrededor de una entidad central, el servicio: un trabajo realizado para un cliente en un punto y en un momento. Todo lo demás cuelga de ahí. El servicio se relaciona con el vehículo y el recurso humano que lo ejecutaron, con el punto de servicio donde ocurrió, con el periodo al que pertenece y con los documentos que lo respaldan.

Alrededor de esa entidad se colocan cuatro bloques:

  • Partes de trabajo. Lo declarado: servicios, tiempos, incidencias y material empleado, normalizado a una línea por servicio aunque llegue agrupado de otra manera.
  • Telemetría. Lo registrado por el vehículo: trayectos, paradas, kilómetros, tiempos de motor en marcha y en ralentí.
  • Mantenimiento. Intervenciones preventivas y correctivas por vehículo, con su coste y su tiempo de inmovilización, que es casi siempre más caro que la reparación.
  • Costes. Combustible, neumáticos, seguro, amortización y personal, imputados por vehículo y periodo para poder repartirse después entre los servicios que ese vehículo ejecutó.

Definir el servicio como unidad mínima es lo que permite que la pregunta «cuánto cuesta atender a este cliente» tenga una respuesta y no un debate. Sin esa unidad, los costes solo se pueden mirar por vehículo o por mes, que es justo el nivel en el que no se puede decidir nada concreto.

Qué publica el vehículo: bus CAN y tacógrafo

La telemetría se captura con Movildata, y dos de sus fuentes merecen comentario aparte porque son las que convierten un sistema de localización en un sistema de gestión.

El bus CAN es la red interna del vehículo, por la que circulan los datos que las centralitas intercambian entre sí. Leerlo permite obtener magnitudes del propio vehículo y no deducidas del GPS: kilómetros del cuentakilómetros real, régimen de motor, tiempos en marcha y en ralentí. La diferencia con calcularlo desde posiciones no es menor: un trayecto estimado por GPS puede quedarse corto en zonas con mala cobertura, y el ralentí sencillamente no se ve desde fuera, porque un vehículo parado con el motor encendido y uno parado con el motor apagado ocupan la misma posición.

El tacógrafo aporta la dimensión legal del tiempo: conducción, pausas y descansos por conductor. Integrarlo no es solo una cuestión de cumplimiento; es lo que permite distinguir una parada que forma parte del trabajo de una que forma parte del descanso obligatorio, y por tanto no computarla como tiempo improductivo. Sin esa distinción, cualquier indicador de aprovechamiento de jornada castiga al conductor por cumplir la ley.

Consumo estimado cuando el vehículo no publica litros

No todos los vehículos publican consumo. Cuando no lo hacen, la alternativa no es renunciar al dato, sino estimarlo y decir claramente que es una estimación. El cálculo se apoya en dos magnitudes que sí están disponibles: los kilómetros recorridos que publica el bus CAN y las horas de ralentí, que consumen combustible sin producir desplazamiento.

El resultado es un consumo estimado por kilómetro y por vehículo, comparable entre vehículos y entre periodos. Esa comparabilidad es lo útil: permite ordenar la flota, detectar un vehículo que se desvía de sus propios valores habituales y señalar rutas con mucho tiempo de motor parado. Lo que no permite es liquidar un repostaje ni sustituir una medición directa, y así se presenta en el cuadro de mando, etiquetado como estimación. Publicar una estimación sin decir que lo es desacredita el sistema entero la primera vez que alguien la contrasta con un ticket.

Las tres fuentes que convergen en el servicio como unidad de análisis Tres orígenes, la telemetría del vehículo con bus CAN y tacógrafo, los partes de trabajo y el ERP con sus albaranes y costes, convergen en una capa de conciliación donde se emparejan paradas con puntos de servicio y se resuelven las inconsistencias. De ahí sale el servicio como unidad, y sobre él se calculan el coste por servicio, los cuadros de mando y las alertas. Tres fuentes, una unidad de análisis Telemetría Bus CAN · tacógrafo · GPS Partes de trabajo Lo declarado ERP Albaranes y costes Conciliación Paradas y puntos Clientes y albaranes Reglas de descarte Servicio Unidad del modelo Coste por servicio Power BI Alertas Las cargas analíticas se ejecutan de forma incremental cada hora, no en tiempo real.
Esquema conceptual del modelo. No representa el número de vehículos, puntos ni rutas de ninguna flota concreta.

Emparejar paradas con clientes

Aquí está la parte difícil. El vehículo produce paradas; el negocio necesita visitas a clientes. Convertir unas en otras parece un problema de distancia y no lo es.

El modelo separa dos conceptos que en el maestro del ERP suelen estar mezclados: el cliente, que es quien contrata y a quien se factura, y el punto de servicio, que es el lugar físico donde se trabaja. Un cliente puede tener varios puntos. Un punto puede corresponder a varios clientes, como ocurre en un polígono, en una galería de alimentación o en un centro comercial donde varias empresas comparten muelle. Con esa separación, una parada se empareja primero con un punto, que es una cuestión geográfica, y el cliente se resuelve después cruzando con la documentación del periodo, que es una cuestión de negocio.

El emparejamiento con el punto exige dos condiciones simultáneas: estar dentro de un radio alrededor de la ubicación conocida y permanecer allí un tiempo mínimo. El radio no puede ser único para toda la flota —un muelle industrial no es una calle estrecha— y suele ajustarse por tipo de punto. Para operaciones, el resultado es poder responder con un dato a la pregunta de cuántas veces se ha visitado realmente a un cliente en un mes, que es la base de cualquier revisión de ruta o de tarifa.

El cruce con los albaranes del ERP

La tercera fuente es el ERP. Los albaranes aportan lo que ni la telemetría ni el parte contienen: qué se entregó o se recogió, en qué cantidad y con qué valor. Cruzar los tres conjuntos —parada emparejada, parte de trabajo y albarán— produce una tabla de servicios conciliados y, lo que es más útil, tres listas de excepciones: visitas sin albarán, albaranes sin visita y servicios declarados sin rastro en ninguna de las otras dos fuentes.

Esas listas no son un reproche a nadie. Casi siempre son circuitos que se interrumpen: un albarán registrado al día siguiente, una entrega documentada contra la matriz en vez de contra la delegación, un servicio ejecutado por un vehículo que ese día no llevaba el equipo habitual. Lo importante es que existan y que alguien las revise con una periodicidad fija. Este tipo de integración con el sistema de gestión es la que describimos en la integración de ERP con cuadros de mando, y cuando el albarán entra en papel o en PDF, la lectura la hacen las aplicaciones de IA documental en lugar de una persona.

Las inconsistencias que aparecen siempre

Hay un conjunto de problemas que se repite en todas las flotas y que conviene resolver de forma explícita, porque si no se tratan contaminan todos los indicadores de arriba:

  • Paradas de segundos que parecen visitas. Un semáforo o un ceda el paso junto a la puerta de un cliente genera una parada dentro del radio. Se descartan por permanencia mínima y por recurrencia: un punto por el que el vehículo pasa de largo casi todos los días no es un destino.
  • Clientes con varias direcciones. Resuelto con la separación entre cliente y punto de servicio, y con un maestro de puntos que se mantiene como dato propio y no se deduce de la dirección de facturación.
  • Visitas sin albarán. Pueden ser entregas no documentadas, servicios no facturados, paradas operativas legítimas o albaranes imputados a otro cliente. El sistema las clasifica por separado y no decide cuál es: eso lo hace operaciones.
  • Direcciones mal geocodificadas. Una dirección que el geocodificador coloca en el centro del municipio convierte todas las paradas de la zona en visitas a ese cliente. Los puntos se validan contra las paradas reales observadas y se corrigen una sola vez.
  • Solapes entre vehículos. Dos vehículos en el mismo punto a la misma hora suelen indicar un servicio duplicado en el parte o un apoyo no declarado; en ambos casos conviene verlo.

Tratar estas cinco cosas es lo que separa un mapa bonito de un sistema de control. La decisión que habilitan es concreta: permite revisar una ruta o una tarifa con un listado de hechos verificados en la mano, en lugar de con la impresión de que ese cliente «da mucho trabajo».

Cuadros de mando, alertas y coste por servicio

Con el modelo conciliado, los cuadros de mando en Power BI se construyen sobre un almacén analítico separado de los sistemas operativos, y las cargas son incrementales y horarias. No es tiempo real, y conviene decirlo así: la telemetría llega de forma continua desde el vehículo, pero su consolidación con partes, albaranes y costes se ejecuta cada hora. Esta capa es la que explicamos en almacén analítico y cuadros de mando.

Encima se colocan dos cosas distintas. Los cuadros responden preguntas estables: coste por servicio, por cliente y por punto; aprovechamiento de jornada descontando los descansos del tacógrafo; consumo estimado por vehículo frente a su propio histórico; coste de mantenimiento e inmovilización por unidad. Las alertas hacen lo contrario: no esperan a que alguien pregunte, sino que avisan cuando algo se sale de su patrón —un vehículo cuyo consumo estimado se desvía, un punto que lleva demasiado tiempo sin visita, un servicio declarado sin respaldo documental—.

Esa es la frontera de nuestro trabajo: dejar el coste por servicio calculado sobre hechos conciliados y las desviaciones señaladas a tiempo. Lo que viene después —qué rutas se rediseñan, qué tarifas se revisan, qué vehículo deja de compensar— es una conversación de gestión, y nuestros compañeros de CAIC la cuentan desde ese lado en su artículo sobre control de costes y rentabilidad por servicio.

¿Sabes lo que te cuesta cada servicio que hace tu flota?

Revisamos qué registra hoy tu telemetría, qué dicen tus partes y qué haría falta para unir ambos con el ERP.

Hablemos

FAQ

Preguntas frecuentes

Artículos relacionados

Hablemos

¿Quieres unir tu telemetría con tus partes y tu ERP?

Cuéntanos tu proyecto y te proponemos la solución más adecuada sin compromiso.