「BIツールを入れたんですが、結局 Excel に戻ってしまって」——導入から 1 年経った企業でよく聞くセリフです。ダッシュボードは作った、KPI も並べた、それでも意思決定の現場では Excel が開かれている。正直に言うと、私のところでも過去に同じ状況を作ってしまった案件があります。
この現象をツールの機能不足で説明するのは簡単なんですが、実際はもっと構造的な理由があるんですよね。BIツールという道具そのものが、この 30 年で何を解決しようとしてきたのか。そして今、経営企画や管理会計の現場で本当に売上に効く使い方はどこにあるのか。歴史をたどりながら、現場での勘所まで踏み込んで整理していきます。
忙しい人向けに、先に答えだけ書きます
BIツールを入れただけでは、意思決定は変わりません。1990 年代の DWH 中心の世代から、セルフサービス BI、そして現在の AI 連携世代まで、道具は確かに進化してきました。ただし、どの世代のツールも「経営が何を問いたいのか」が定義されていなければ、ただのダッシュボード製造機で終わるという構造は変わっていません。
管理会計の勘所は業界ごとに違いますし、経営企画に求められるスキルも、レポート作成から「問いを設計する力」へと確実に移っています。売上に効かせるには、KPI ツリーの設計と、現場フィードバックのループを、ツールの中に埋め込むこと。ここまで来て初めて、BIツールは経営の道具になります。
逆に言えば、この設計をせずに高価なツールを買うのは、望遠鏡を買って何を見るか決めていない状態に近いんです。
BIツールの価値は機能ではなく、その周辺で組まれた運用設計に宿る。
BIツールの 30 年——3 つの世代で整理する
BIツールの変遷は、大きく 3 つの世代に分けると見通しがよくなります。
世代 | 時期 | 代表製品・技術 | 解決した課題 | 積み残した課題 |
|---|---|---|---|---|
第 1 世代 | 1990 年代〜 | DWH + Cognos、BusinessObjects 等 | 基幹系データを統合した定型帳票 | 情シスに依頼しないと分析できない |
第 2 世代 | 2010 年前後〜 | Tableau、Power BI、Looker | 現場が自分で分析できる(セルフサービス化) | 乱立するダッシュボード、指標の統制不能 |
第 3 世代 | 2020 年代〜 | 生成 AI 連携、自然言語クエリ、埋め込み分析 | 自然言語で問える、業務システムへ組み込める | 「何を問うべきか」は人間が決める必要がある |
第 1 世代は、そもそもデータを一箇所に集めるだけで一大事業でした。データウェアハウスを構築して、月次の帳票を情シスが作る。現場が「ちょっとこの切り口で見たい」と言っても、要件定義から数週間待ちが当たり前だった時代です。
第 2 世代で Tableau や Power BI が普及し、この構造は劇的に変わりました。現場が自分の手でデータを触れるようになったんです。ただ、そのぶんダッシュボードが乱立し、部署ごとに違う定義の「売上」が並ぶという新しい問題が生まれました。ガバナンスの話ですね。
そして第 3 世代の今。自然言語で「先月の粗利、部門別に見せて」と問えば返ってくる世界に片足を突っ込んでいます。ただ、白状すると、この世代のツールを触ってみて痛感するのは——結局のところ 「何を問うか」を決めるのは人間の仕事のまま だという点なんですよね。ツールが賢くなればなるほど、問いの質がそのまま出力の質になる。
管理会計の勘所は、業界ごとに違う
BIツール導入プロジェクトで最初に躓きがちなのが、業界ごとの管理会計ロジックを甘く見るケースです。
製造業なら、原価計算と稼働率が中心になります。標準原価と実際原価の差異分析、設備別・工程別の稼働率、仕掛品の滞留時間。ここが見えないと、粗利が動いた本当の理由に到達できません。
小売は、商品別・店舗別・時間帯別の粗利貢献です。同じ商品カテゴリでも、店舗によって粗利率が 10 ポイント違うこともあります。単品管理と品揃え MD の粒度で数字を切れないと、意味のある会話になりません。
SaaS の管理会計は、また別の世界です。MRR、ARPU、解約率、コホート分析、LTV/CAC 比率。会計上の売上ではなく、契約ベースの積み上げで経営を見る必要があります。
サービス業(コンサル・広告・SI 系)は稼働率と単価、そして案件粗利率。人が原価の大半を占めるので、時間の使い方が P/L に直結する構造です。
同じ BIツールを使っていても、業界の管理会計ロジックを理解していないと、数字は意味を持ちません。ここを外部ベンダーに丸投げすると、綺麗だけど誰も見ないダッシュボードが出来上がります。現場あるあるですが、これは本当によく見る失敗です。
経営企画に求められるスキルは、静かに変わってきた
BIツールが「作る」を代替した結果、経営企画部の仕事は変質しました。うーん、これは経営企画の方本人が一番感じているところかもしれません。
10 年前の経営企画の主業務のかなりの部分は、レポート作成でした。各部門から数字を集めて、Excel で加工して、経営会議用の資料に整える。この作業に週の半分を溶かしていた、という話は珍しくありません。
今、この作業のかなりの部分がBIツールで自動化できます。じゃあ経営企画の人が楽になったかというと、そうでもないんですよね。要求される役割が変わっただけです。
現在の経営企画に求められる 3 つのコアスキルは、次のように整理できます。
- データモデリングの基礎理解:SQL を書けとまでは言わないまでも、テーブル同士の関係と粒度の話ができること
- 事業側との対話力:現場が本当に困っている問いを引き出し、それをデータで検証可能な形に翻訳する
- 仮説検証の設計力:ダッシュボードを見て「で、何が言えるのか」を最初から設計として持っている
要は、レポート作成係から問いを設計する側へ、というシフトです。ツールが安くなり自然言語で問える時代になったからこそ、「何を問うべきか」という一段上の判断が、人間にしかできない仕事として残っている。この構造は、コンサルが実装に降りる時代の、提案書の作法 で書いた話と地続きだと考えています。
売上に効かせる BI の使い方——3 段階の運用設計
ダッシュボードを眺めるだけでは、売上は 1 円も動きません。売上に効かせるには、次の 3 段階を運用の中に埋め込む必要があります。
第 1 段階:KPI ツリーの分解。売上を、顧客数 × 客単価 × 購買頻度、あるいは案件数 × 平均案件単価 × 受注率、といった構造に分解します。この分解が雑だと、その後のダッシュボードも雑になります。ここは 営業目標は"気合"で決まらない — KPIツリーで売上を逆算する で詳しく書いた通りです。
第 2 段階:現場アクションへの接続。KPI ツリーの末端まで分解した指標が、現場の誰の・どの行動に紐づくかを明示します。「受注率」が下がったとき、それは提案書の質なのか、リード品質なのか、価格提示のタイミングなのか。行動レベルまで落とせて初めて、ダッシュボードは意思決定の道具になります。
第 3 段階:フィードバックループの設計。BI 画面を見て「何を、いつまでに、誰が」変えるのかを会議体のフォーマットに埋め込む。ここまでやって、BI はやっと売上に効き始めます。
単なる可視化と「売上に効く可視化」の違いは、この第 3 段階があるかどうかです。
ある中堅商社での粗利率 3 ポイント改善
ある中堅商社の事例です。年商 200 億円規模で、部門別の粗利は月次で見えていましたが、営業担当者ごとの案件パイプラインは Excel と個人の頭の中に散在していました。
BIツールを導入し、SFA のデータと会計データを連携させたところ、粗利率が高い案件と低い案件で商談期間に 2 倍以上の差があることが可視化されました。ここまでは、多くの導入事例で語られる範囲だと思います。実際に売上に効いたのは、その先です。
営業会議のフォーマットを、案件件数の報告から 「粗利率別のパイプライン構成」の議論 に切り替えました。BI 画面を投影しながら、粗利率が低い案件をなぜ受注しているのかを毎週議論する運用に変えたんです。半年で平均粗利率が 3 ポイント改善しました。年商 200 億円に対して 3 ポイントですから、営業利益への影響は無視できない規模です。
ツールが優れていたから効いたのではありません。ツールを議論のトリガーとして運用に組み込んだから効いた事例です。逆に言うと、同じツールを入れて運用を変えなかった競合他社では、同じ効果は出なかったはずです。
BIツールの効果は、機能ではなく運用設計に宿ります。この一文だけ持ち帰ってもらえたら、この記事の目的はほぼ達成です。
BI 運用の設計から一緒に考えたいご相談
BIツールの導入検討や、既に入れたけれど活用しきれていない状態から、運用設計・KPI ツリーの再構築・経営会議のフォーマット変更までを含めて、私たちはご相談を承っています。「もう Tableau は入っているけど、経営会議で使われていない」「Power BI を入れたけど部門ごとに数字の定義がバラバラ」——このあたりの状態こそ、外部の視点が役に立つ局面だと考えています。
ツールの選定だけで終わらせず、経営の問いをどう設計するか、現場の行動にどう接続するかまで、腰を据えて議論する場をご用意します。関連する論点や事例は下記の記事もあわせてご覧ください。
関連記事:
