300万件の乗車データはどのように意思決定につながったのか？
ある鉄道事業者には、データがありました。それも十分すぎるほどに。本当の課題は、そのデータが意思決定の瞬間にどれだけ早く届くかでした。
1日約300万人が利用する大規模な鉄道システムの運営では、乗車データ、現場点検、パフォーマンス指標、業務記録がそれぞれ別のシステムで管理されていました。
業務アプリケーション、データベース、分析基盤、レポーティングツール、現場のモバイルアプリケーションは、それぞれの役割を果たしていました。しかし、業務上の重要な問いへの答えは一か所にはありませんでした。
- どの路線でパフォーマンスが低下しているか？
- どの駅で問題が発生しているか？
- 現場からのデータは日々の業務にどのような影響を与えているか？
- どの指標に対応が必要か？
データは存在していました。しかし、複数のシステムに分散したデータを集めて意味づけるには時間がかかっていました。そのため課題は、新しいデータソースを作ることではなく、既存のデータを意思決定に使える状態にすることでした。
システムを変更せずに共通のデータ層を構築
解決策は、既存システムを撤去して再構築することではありませんでした。業務アプリケーション、SAP基盤と数十のモジュール、複数のデータベース、レポーティングツール、現場アプリケーションは、引き続き稼働しました。
Butterflyはこれらのシステムの上に位置し、異なるソースから届くデータを共通の構造に集約しました。こうして、複数のシステムにあったデータが一つの意思決定層に集まりました。
このアプローチの根底にあったのは、既存の技術投資を入れ替えるのではなく、既存システムが生み出す価値を互いに結び付けるという考え方です。その結果、組織は複数のシステムにあるデータに、一つの業務ビューからアクセスできるようになりました。
27ページのレポートが毎朝準備済みに
業務チームにとって、日次レポートは単なる文書ではありません。一日の始め方を決める基本的な情報源です。このプロジェクトでは、27ページの日次業務レポートが毎晩自動で作成されるようになりました。
チームは朝の時間を、複数のシステムからのデータ収集、ファイルの統合、レポート作成に費やすのではなく、得られた結果そのものに集中できるようになっています。つまりプロセスは次のとおりです。
- データ収集 → レポート作成 → 確認
- データ → 準備済みのレポート → 評価 → アクション
30分から3秒へ
データが一つの構造に集約されたことで、レポーティングだけでなく、クエリの速度も変わりました。以前は約30分かかっていたクエリが、現在は約3秒で完了します。
この差は、技術的なパフォーマンス指標以上の意味を持ちます。ある問いへの答えを得るのに30分かかるなら、その問いは業務の流れの中で後回しにされがちです。数秒で答えが得られるなら、同じ問いは日々の意思決定の自然な一部になります。データへのアクセス時間が短くなるほど、意思決定までの距離も短くなります。
現場からの10万行のデータが、同日中にパフォーマンス指標に
鉄道の業務では、現場データが絶えず生成されています。駅の点検により、1日約10万行のデータがシステムに入力されます。しかし、生データがシステムに記録されているだけでは十分ではありません。本当の価値は、そのデータが業務上意味のある指標に変わったときに生まれます。
現場データは、同日中に次の指標に反映されるようになりました。
- 路線パフォーマンス
- 駅のパフォーマンス
- スタッフのパフォーマンス
こうして、現場で起きた事象と経営画面に表示される結果との間の時間が短縮されます。現場 → データ → 分析 → 意思決定の流れが加速します。
6,000件のレコードを5秒で同期
異なるシステムを連携させる際の最大の課題の一つは、データを適切なタイミングと適切な形式で同期できるかどうかです。この構成では、6,000件のレコードを約5秒で同期できます。これにより、複数のソースで生じた情報を、業務に必要な共通ビューの中で更新できます。
ここでのアプローチが重要です。目的は、すべてのシステムを一つのシステムにすることではありません。目的は、異なるシステムが同じ業務について連携できるようにすることです。
ITからのレポートを待つのではなく、ユーザー自身が画面を作成
データへのアクセスが民主化されたもう一つの領域が、レポーティングです。業務チームは必要なダッシュボードをコードを書かずに作成できます。さらに、データに自然言語で質問して、必要な情報を得ることもできます。
そのため、新しい問いが生じるたびにレポートを依頼したり、技術チームの支援を待ったりする必要はありません。ITの役割は、レポートを作ることから、組織がデータをより効果的に活用できる基盤を提供することへと移りつつあります。業務チームは、必要な情報を直接活用できるようになっています。
本当の変革はデータ量ではなく、意思決定のスピードにある
この事例で、数百万件の乗車データを処理したことはもちろん重要です。しかし、本質はデータの量ではありません。大企業にはデータはすでにあるからです。
- SAPにある。
- データベースにある。
- 現場アプリケーションにある。
- レポーティングシステムにある。
本当の問いはこうです。これらのデータは、意思決定が必要な瞬間にどこまで近づいているのか。
業務レポートが朝の時点で準備されていれば、チームはデータ収集ではなく意思決定から一日を始められます。30分かかっていたクエリが3秒で終われば、先送りされていた問いを改めて投げかけられます。10万行の現場データが同日中にパフォーマンス指標になれば、現場と経営の距離は縮まります。そして異なるシステムが互いに連携できれば、組織が長年にわたって築いてきた技術投資を守りながら、新たな意思決定の層を構築できます。
デジタルトランスフォーメーションは、必ずしもシステムを入れ替えることではないからです。本当の変革は、すでに保有しているシステムが生み出すデータを、より速く、より利用しやすく、より意味のあるものにすることである場合もあります。
成果
1日300万人が利用する業務では、データが絶えず流れています。価値を生むのはデータが流れることではなく、それが適切なタイミングで適切な意思決定につながることです。
Butterflyは、既存の業務システムを変更することなく、異なるデータソースを共通の構造に集約し、組織が業務データからより早く成果を得られるようにします。
より多くのデータではなく、より速い意思決定を。