経営会議で「今月の売上」を確認したところ、営業部の資料と経理部の資料で数字が違う。さらに経営企画が作成したダッシュボードを見ると、また別の数字が表示されている。
このような状況では、「どの部署の数字が間違っているのか」と考えがちです。しかし、計算ミスやシステム障害ではなく、そもそも各部署が別のものを同じ「売上」という名前で呼んでいることがあります。
例えば営業部は受注額、生産・物流部門は出荷額、経理部は会計処理上の売上高、経営企画は経営管理用に加工した指標を見ているかもしれません。それぞれ業務上必要な数字であり、一つだけが正しく他が誤りとは限りません。
重要なのは、異なる意味の数字を無理に一つへ統合することではなく、異なる意味の数字を同じ名前で呼ばない状態をつくることです。
本記事では、営業・経理・経営企画などでKPIの数字が合わないときに、受注・出荷・請求等の業務イベントを整理し、KPI定義書やBusiness Glossary、データ辞書へ落とし込む方法を解説します。
同じ「売上」で数字が違うのは珍しくない
企業の活動には、受注、出荷、請求、入金など複数の業務イベントがあります。
営業部門であれば、受注した案件金額を中心に進捗を確認することがあります。生産・物流部門では、実際に出荷した金額の方が業務管理に使いやすい場合があります。経理部門では、会社の会計方針や会計処理に基づいた売上高を扱います。
つまり、「売上」という言葉が指している対象が違えば、同じ月でも数字が異なること自体は不自然ではありません。
問題になるのは、それらの違いが明文化されないまま、同じ「売上」というラベルでExcel、会議資料、BIダッシュボード等に表示されることです。
問題は数字の違いより「同じ名前」で呼んでいること
売上数字が異なると、「全社共通の売上を一つ決めよう」と考えることがあります。
もちろん、会計・経営管理等の目的に応じて正式な指標を定めることは重要です。しかし、受注額と出荷額のように、そもそも異なる業務イベントを測っている数字まで一つにする必要はありません。
例えば営業部門が将来の売上見込みを考えるために受注額を追うことと、物流部門が出荷実績を追うことは両立します。
この場合に必要なのは、「売上」という曖昧な名称ではなく、受注額、出荷額、請求額、会計売上高、管理売上高など、意味が分かる名称に分けることです。
受注額・出荷額・請求額を全部「売上」と呼ぶ架空例
説明用の架空企業で、4月の経営会議を考えます。
| 部門 | 資料上の名称 | 実際に集計しているもの | 主な利用目的 |
|---|---|---|---|
| 営業 | 売上 | 4月に受注確定した案件金額 | 営業活動・案件進捗の確認 |
| 生産・物流 | 売上 | 4月に出荷した商品金額 | 生産・出荷実績の確認 |
| 経理 | 売上 | 会計方針・会計処理に基づき4月に売上計上した金額 | 財務・会計管理 |
| 経営企画 | 売上 | 経営管理ルールに基づく管理指標 | 経営判断・計画管理 |
この表だけを見て、どの部門が間違っているとは判断できません。
見るべきなのは「どの業務イベントを基準にしているか」「何の判断へ使っているか」です。
整理後は、必要に応じて「受注額」「出荷額」「請求額」「会計売上高」「管理売上高」などへ名称を分けます。なお、会計売上高の具体的な認識ルールは各社の会計方針等に基づくため、本記事では独自の会計処理ルールを定めません。
KPI定義を揃える7つのステップ
1. 同じ名称で使われている数字を洗い出す
まず、経営会議や月次報告で頻繁に使われるKPIを一つ選びます。
例えば「売上」であれば、営業、経理、経営企画のExcel、BI、帳票等に同じ名称がないか確認します。
最初から全社の全KPIを整理する必要はありません。数字の照合作業が頻繁に発生している指標や、経営判断への影響が大きい指標から始める方法があります。
2. 各部署が何のために使っているか確認する
同じ「売上」でも、目的が異なれば必要な数字も変わります。
営業活動を評価するためなのか、生産実績を見るためなのか、財務数値として確認するのか、事業計画との差を見るのかを整理します。
KPIは数字だけでなく、どの意思決定のために見るのかまで明確にすると定義しやすくなります。
3. 起点となる業務イベントを分ける
次に、数字が発生する基準を確認します。
- 受注確定
- 出荷
- 請求
- 会計上の計上
- 入金
など、似たように見える数字でも起点となるイベントは異なります。
ここを分けるだけでも、「なぜ4月の数字が合わないのか」が説明できるケースがあります。
4. 対象範囲・計上条件を定義する
同じ業務イベントを見ていても、対象範囲が違えば数字は一致しません。
例えば次の条件を確認します。
- 対象会社・部署・事業
- 対象商品・サービス
- キャンセルの扱い
- 返品・値引きの扱い
- 税込・税抜
- 通貨・換算ルール
- 計上基準日
- 集計粒度
細部まで一度に定義する必要はありませんが、「数字が変わる条件」を優先して明文化します。
5. 指標へ正式名称を付ける
意味の異なる数字には、意味の違いが伝わる名称を付けます。
「売上①」「売上②」のような名称ではなく、「受注額」「出荷額」など、何を測っているか分かる名前にします。
ここで重要なのは、部署固有の数字を廃止することではありません。業務上必要なら別KPIとして残し、名称と用途を明確にします。
6. Ownerとデータソースを決める
KPI定義には、その定義について説明・変更判断を行うBusiness Ownerを設定しておくと管理しやすくなります。
加えて、CRM、販売管理、会計システム等のうち、どのデータを集計元とするかも明記します。
同じKPI名でも、部署ごとに別のExcelを参照している状態では、定義を合意しても再び差異が生じる可能性があります。
7. BI・Excel・帳票へ同じ定義を反映する
最後に、合意した定義を実際の集計ロジックへ反映します。
KPI定義書では「受注確定日を基準」と書いてあるのに、BIでは請求日で集計していれば、定義書を作っても数字は揃いません。
業務定義と実装ロジックが一致していることまで確認して初めて、定義整理が運用へつながります。
KPI定義書には何を書くか
KPI定義書は、指標名だけを一覧化した表ではありません。
「何を意味する数字なのか」「どう計算するのか」「どこから取得するのか」「誰が定義を管理するのか」を確認できる状態を目指します。
| 項目 | 記載内容の例 |
|---|---|
| KPI名 | 受注額 |
| 利用目的 | 営業活動・将来売上の状況確認 |
| 業務上の定義 | 定義した条件を満たす受注確定案件の金額 |
| 計上イベント | 受注確定 |
| 計上基準日 | 受注確定日 |
| 対象範囲 | 組織で合意した対象案件 |
| 除外条件 | キャンセル案件等、組織で定めた条件 |
| 単位 | 円 |
| 集計粒度 | 案件、顧客、月等 |
| Data Source | CRM等 |
| Business Owner | 営業管理等 |
| Status | Draft / Approved等 |
| 適用開始日 | 定義を適用する開始日 |
| 変更履歴 | 変更日、変更内容、承認者等 |
これは説明用の架空例です。すべての企業ですべての項目を必須にする必要はありません。
まずは、数字の差異に直結する「定義」「計上基準日」「対象範囲」「除外条件」「データソース」などから整理する方法があります。
KPI定義書・Business Glossary・Data Dictionaryの違い
KPI定義を整理すると、「データ辞書を作ればよいのか」「Business Glossaryとは何が違うのか」という疑問が出ます。
| 管理対象 | 主な役割 | 例 |
|---|---|---|
| KPI定義書 | 指標の意味、計算ルール、Owner等を管理 | 受注額、粗利率、案件数 |
| Business Glossary | 業務用語の意味を組織内で共有 | 顧客、案件、受注、解約 |
| Data Dictionary | データ項目の技術的な構造・仕様を管理 | カラム名、型、コード値、許容値 |
| Data Catalog | 組織内のデータ資産を発見・把握しやすくする | CRMデータ、会計データ、DWHテーブル |
実際の運用では、これらを別々のExcelで完全に分離しなければならないわけではありません。小規模な組織では一つの管理表から始めても構いません。
大切なのは、「売上」という業務用語の意味と、BIが参照する具体的なカラム・計算式を対応付けられる状態にすることです。
複数のKPI定義が必要でも問題ない
KPI定義を統一するというと、全社で一つの数字だけを使うことだと受け取られることがあります。
しかし、営業活動を管理する受注額と、財務報告等で使用する会計上の売上高では、目的が異なります。
目的の違う指標を無理に一つへ合わせると、かえって必要な情報が失われる可能性があります。
したがって、複数の数字が必要なら複数のKPIとして定義します。その代わり、「どの場面でどのKPIを使うか」を明確にします。
例えば経営会議では「会計売上高」と「受注額」を並べ、現在の実績と将来の案件状況を別々に確認する、といった使い分けが考えられます。
BI・DWHはKPI定義を決めた後に実装する
部署ごとに数字が異なると、BIツールやDWHを導入して「数字を一か所に集めれば解決する」と考えることがあります。
しかし、営業が受注を売上と呼び、経理が別の基準による売上高を売上と呼んでいる状態でデータだけを統合しても、「どの売上を表示するか」という問題は残ります。
BIやDWHには大きな価値がありますが、システムは業務定義そのものを自動的に決めてくれるわけではありません。
先にKPI名、業務上の意味、計算ルール、正式なデータソースを決め、その定義をBIへ実装することで、ダッシュボード上の数字を説明しやすくなります。
KPI定義を維持するための運用ルール
KPI定義書を一度作っても、業務は変化します。新しい商品や事業の追加、組織再編、システム変更、管理会計ルールの変更等によって、指標の定義を見直す必要が生じます。
そのため、少なくとも重要KPIについては次の情報を残しておくと管理しやすくなります。
- 現在の定義がDraftかApprovedか
- 誰がBusiness Ownerか
- いつからその定義を適用するか
- いつ、何を変更したか
- BI・Excel・帳票のどこで利用されているか
特に定義変更では、「最新の定義」だけを残すと、過去資料との数字の違いを説明できなくなる場合があります。必要に応じて適用期間や変更履歴を管理します。
KPI定義が揃っているか確認するチェックリスト
| 確認項目 | 確認内容 |
|---|---|
| 名称 | 同じKPI名を複数部署が異なる意味で使っていないか |
| 目的 | そのKPIを何の判断へ使うか明確か |
| イベント | 受注、出荷、請求等の何を基準にしているか |
| 計上日 | どの日付を集計基準とするか決まっているか |
| 範囲 | 対象会社、部署、商品等が明確か |
| 除外条件 | 返品、キャンセル、値引き等の扱いが決まっているか |
| 単位 | 税込・税抜、通貨等の条件が明確か |
| 粒度 | 案件、顧客、商品、月等の集計粒度が明確か |
| Data Source | 正式に参照するデータが決まっているか |
| Owner | 定義について説明・変更判断する担当が決まっているか |
| Status | 検討中と正式承認済みを区別できるか |
| 変更履歴 | 定義を変更した日時・内容を確認できるか |
| 実装 | BI、Excel、帳票の計算ロジックが定義書と一致しているか |
まず次の経営会議で頻繁に使う指標を一つ選び、営業、経理、経営企画等へ「この数字は、何を、いつの時点で、何を含めて集計していますか」と確認してみてください。
同じ「売上」という名前でも回答が異なるなら、システム統合より先に業務定義を整理する余地があります。
まとめ
営業、経理、経営企画で「売上」の数字が異なる場合、どこかの部署が計算を間違えているとは限りません。
受注、出荷、請求、会計上の計上など、異なる業務イベントを同じ「売上」という名称で扱っていることが原因の場合があります。
まず、各部署が何を判断するために数字を使っているのかを確認し、何の業務イベントを基準にしているかを整理します。意味の異なる数字は、受注額、出荷額、請求額、会計売上高等の別KPIとして定義します。
そのうえで、対象範囲、計上基準日、除外条件、集計粒度、データソース、Owner等をKPI定義書へ記録し、BI、Excel、DWH等の実装と一致させます。
SCI総合研究所株式会社のRASHINRAでは、売上、案件、原価、工数等のデータを集計する前に、経営・業務上どの判断へ使う指標なのかを確認し、KPIの定義、集計単位、対象範囲、データソース等を整理します。
「営業と経理で売上の数字が合わない」「BIを導入したが会議で数字の確認に時間がかかる」「KPI定義書をどこから作ればよいか分からない」といった段階から、データを意思決定へ使うための論点を整理できます。