スプレッドシートの問題
45名のスタッフを抱える流通会社が、12本のExcelファイルで業務を回していました。売上データ、在庫水準、配送状況、仕入先のリードタイム——それぞれが別々のファイルに存在し、別々の担当者が管理し、別々のタイミングで更新されていました。
毎週月曜日、業務管理者は週次報告書の集計に2時間を費やしていました。報告書が完成するころには、一部のデータがすでに古くなっていました。
これはよくある話です。Excelは優れたツールです。しかし、4人が同じデータをリアルタイムで参照して意思決定する場面では、間違ったツールになります。
カスタムダッシュボードが実際に置き換えるもの
構築の前に、ダッシュボードが支援すべき意思決定を洗い出しました：
- 最低在庫を下回っている製品ラインはどれか？
- どの配送が遅延していて、どのくらい遅れているか？
- 最も遅延を引き起こしている仕入先はどこか？
- 売上推移は目標に対してどうか？
これらは回答に何時間もかかる質問でした。目標は、数秒で答えられるようにすることでした。
移行プロセス
フェーズ1：データ監査（第1週）
12本のスプレッドシートを棚卸しました。実際に使われているものはどれか？他のファイルにデータを供給しているものはどれか？データの発生源は——手動入力、他システムからのエクスポート、あるいは両方？
結果：12本中4本は重複または使用頻度が極めて低いものでした。実際のデータソースは3つの主要システムだけでした。
フェーズ2：データモデル設計（第2週）
ダッシュボードを作る前に、定義の統一が必要です。「遅延配送」とは何か？出荷時点で遅れているのか、配送予定日を過ぎているのか、顧客から苦情があったときなのか？これらの問いを通じて、各チームが長年にわたって暗黙裡に持っていた前提が——互いに相違していたことも含めて——浮かび上がります。
フェーズ3：構築と接続（第3〜5週）
3つのソースシステムからデータを引き込み、フォーマットを標準化して中央データベースに格納するパイプラインを構築しました。ダッシュボードはこの中央データベースからリアルタイムで取得し、15分ごとに更新されます。
フェーズ4：展開（第6週）
2週間、ダッシュボードとスプレッドシートを並行稼働させました。差異が生じた場合は調査を実施。大半はソースシステム側のデータ品質問題でした——データが可視化されて初めて発見されたものです。
変わったこと
月曜の報告作業は2時間から10分に短縮されました。ダッシュボードはリアルタイムで動いているため、会議が始まる時点で最新データが揃っています。2日前のデータではありません。
さらに重要なのは、チームが問う質問が変わったことです。データが取りにくいとき、人は問いかけをやめます。すぐに取れるとき、より多く問い、より良い決断をします。
実際のコスト
プロジェクトは6週間で完了し、評価対象だった商用BIツールと比べて大幅に安価でした。既成のツールには継続的なライセンス費用に加えてカスタマイズのための外部コンサルタントが必要で、結局トータルコストはカスタム開発と同水準になっていました。
違いは明確です。カスタムダッシュボードは自社の特定システムに直接接続し、社内の用語をそのまま使い、新しいコンサルティング契約なしに修正できます。