ライオンが社内組織主導で内製したデータ基盤、経営判断をリアルタイム化

各事業や各システムにデータが分かれて存在し、経営の目線でリアルタイムに使える状態になっていなかった。加えて、これまでの意思決定は経験に依る部分が大きく、データを手がかりに先手を打つ動きが取りにくい状況にありました。

困りごとの本質は、データが不足していたことではなく、集めた情報が「誰のためのものか」という設計思想の違いにあったのではないでしょうか。ソースには、従来のシステム刷新が現場の業務改革に主眼を置きがちだったと記されています。現場の効率化を目的に組まれた仕組みは、業務単位で最適化されるぶん、事業や部門をまたいで経営指標を横串で見る用途には向きません。つまり、個々のシステムがうまく動いていたからこそ、経営レベルの視界だけが空白のまま残った——そう読み解くと、この会社が現場改善ではなく経営の意思決定そのものを基盤づくりの主題に据えた理由が見えてきます。

企画・構築・運用の全工程を社内のクラウドCoE（専門知見を集約する中核組織）が主導する体制を選んだことが、この取り組みの土台になっていると考えられます。データ基盤は作って終わる性質のものではなく、事業の変化に合わせてデータの持ち方や指標の定義を絶えず組み替え続ける必要があります。外部に委ねると、その都度の仕様調整が発注と納品のサイクルに乗ってしまい、判断のスピードが基盤の更新速度に縛られてしまう。知見を社内に残す設計が、アジリティとコストの両面に効いている理由はここにあるでしょう。

統合の出発点にERPの販売・会計・生産データを据えた点も、優先順位の付け方として合理的です。周辺の細かなデータから積み上げるのではなく、経営が最も頻繁に参照する中核の数字から束ねていく順序をとれば、基盤が形になった時点で経営判断に直結する価値が生まれます。データ統合の取り組みが「集めたが使われない」状態に陥りやすいことを踏まえると、使い道が最初から確定している領域を先に押さえた選択は理にかなっています。

可視化と分析を特定の担当者に閉じ込めない設計も見逃せません。BigQueryのスケーラビリティを前提に、Lookerによる可視化とGemini in BigQueryを組み合わせることで、データを扱える人の裾野を広げる方向に舵が切られています。基盤の価値は問いを立てる人の数に比例して増えるため、分析の民主化を初期から織り込んだ構えが、基盤を単なる保管庫で終わらせない支えになっているはずです。

新しいデータ基盤の稼働により、経営層は最新データを網羅したダッシュボードを通じて経営状況を正確に把握できるようになり、変化の兆しを捉えた迅速な意思決定が可能になっています。今後は可視化にとどめず、AIや機械学習を用いた高精度な需要予測やサプライチェーン最適化など、未来の経営指標を予測する機能の追加が予定されており、クラウドCoE体制のさらなる拡充も方針として示されています。可視化から予測へという段階の踏み方が明示されている点は、基盤投資の道筋として参考になります。