ブラジルの運送会社——約150台の車両、月間10,000件超の運行、20,000件のCT-e発行——は、互いに連携しないシステムにデータが散在した状態で運営されていました。運賃と積荷明細のためのTMS、車両追跡のためのテレメトリ、財務のためのERPです。運行の統合ビューは手作業で組み立てたスプレッドシートに存在し、最大7日の遅延がありました。
顧客の要望により匿名化しています。
課題
- テレメトリとTMSの突合は手作業の悪夢でした。ナンバープレートは追跡装置上でIDが絶えず変わり、運行の開始日と終了日はシステム間でほとんど一致しませんでした。
- キロ当たりコスト、車両稼働率、配送SLAは手作業で計算され、経営陣は最大7日遅延したスプレッドシートのレポートを受け取っていました。
- アナリストの貴重な時間が、運行の分析ではなくピボットテーブルの作成だけに費やされていました。
ソリューション
Meta Dadosは各データソースを統合し、単一の可視化レイヤーとしてセルフホスト型Metabaseを提供しました。
- 統合——TMS、テレメトリ、ERPを中央の分析用データベースに接続する自動化パイプラインを構築し、車両のマッピングと運行の照合をロード時に解決しました。
- モデリング——運行、運賃、車両、ドライバーを統一するレイヤーを構築し、「運行」を中心的な粒度としました。
- ガバナンス——オープンソース版Metabaseでは、各支店が独立した接続（データウェアハウス内の専用スキーマ）となり、コレクションごとのグループと権限で誰が何にアクセスするかをマッピングします。各拠点の管理者は自らの運行データのみを厳密に閲覧し、経営陣は全車両の統合状況を経営ダッシュボードで把握します。
- ダッシュボード——運行（進行中の運行、稼働率、定時性）と財務（キロ当たりコスト、ルート・顧客別マージン、運賃照合）。
成果
意思決定までの時間が劇的に短縮されました。走行キロ当たりコスト、車両稼働率、配送定時性の指標は、数日遅延したスプレッドシートから脱却し、日次で追跡されるようになりました。ハンドオーバーは完全に行われ、現在では運送会社の社内チームがMetabaseで独自の問いを自律的に作成し、Meta Dadosは継続的な専門サポートとプラットフォームの発展を担っています。
スタック
TMS · 車両テレメトリ · PostgreSQL · セルフホスト型Metabase · Python。
なぜMetabaseか
セルフホスト型かつオープンソース——機微な運行データは顧客のインフラ内にとどまります。独立した接続とグループごとの権限で事業拠点を分離し、ハンドオーバー後には運送会社自身のチームが独自の問いを作成できる習得しやすさを備えています。
よくある質問
BIを導入するにはTMSやテレメトリを入れ替える必要がありますか？
いいえ。作業は、運行がすでに保有するデータソース——TMS、テレメトリ、ERP——を単一の分析レイヤーに統合することです。元のシステムはそのまま維持されます。
なぜテレメトリとTMSを突合するのですか？
各システムは一部分しか把握していません。テレメトリは車両がどこにいたかを把握し、TMSは何が計画され請求されたかを把握します。両者を突合することで、各ルートが実際にいくらかかったのか、そして運行のどこでマージンを失っているのかに答えられます。