一家巴西运输公司——拥有约 150 辆车的车队、每月超过 10,000 趟运输和 20,000 张 CT-e——其数据分散在互不相通的系统中运作：TMS 负责运费与装载清单，车队遥测负责定位追踪，ERP 负责财务。对运营的统一视图只能靠手工拼凑的电子表格维系，滞后长达 7 天。
应客户要求匿名处理。
挑战
- 将遥测数据与 TMS 交叉比对是一场手工噩梦：车牌在追踪器中的 ID 不断变化，各系统间的运输起止日期也很少能对上。
- 每公里成本、车队占用率和交付 SLA 都靠手工计算；管理层收到的电子表格报表滞后长达 7 天。
- 分析师宝贵的工时只被用来拼凑数据透视表——而非分析运营本身。
解决方案
Meta Dados 整合了各数据源，并以自托管 Metabase 作为统一的可视化层进行交付：
- 集成——通过自动化管道将 TMS、遥测与 ERP 连接至一个中央分析型数据库，车辆映射对照与运输对账在数据加载阶段即完成解决。
- 建模——统一运输、运费、车辆与司机的数据层，以“运输”为核心粒度。
- 治理——在开源 Metabase 中，每家分公司都是一个隔离连接（在数据仓库中拥有独立 schema），并通过按集合划分的分组与权限映射谁能访问什么：每个网点的管理者仅能看到本网点运营的数据，而管理层则可在高管仪表盘中掌握整个车队的汇总情况。
- 仪表盘——运营（进行中的运输、占用率、准点率）与财务（每公里成本、按线路与客户划分的利润率、运费对账）。
成果
决策所需时间大幅缩短：每公里行驶成本、车队占用率和交付准点率等指标，从滞后数天的电子表格中脱离出来，转为每日跟踪。交接十分彻底——如今运输公司的内部团队能在 Metabase 中独立创建自己的查询，Meta Dados 则提供持续的专业支持与平台演进。
技术栈
TMS · 车队遥测 · PostgreSQL · 自托管 Metabase · Python。
为什么选择 Metabase
自托管且开源——敏感的运营数据留在客户的基础设施内；通过隔离连接与分组权限来分隔各业务单元；其学习曲线让运输公司自己的团队在交接后也能创建查询。
我们在此集成的系统
常见问题
要获得 BI，是否必须更换 TMS 或遥测系统？
不需要。工作在于将运营现有的数据源——TMS、遥测与 ERP——整合到一个统一的分析层中。源系统保持原样不变。
为什么要将遥测数据与 TMS 交叉比对？
每个系统只掌握其中一部分。遥测知道车辆去过哪里；TMS 知道计划了什么、收了多少费用。交叉比对后，它们才能回答每条线路真正花了多少成本、运营在哪里损失了利润。