会議のたびに、営業と経理で「今月の売上」が違う。数字を集め直しているうちに、決めるはずだった話が終わってしまう。そんなとき、保存先を一つにまとめても、集計の意味が違えば食い違いは残ります。
データ一元化は、同じ場所に集めるだけでなく、判断に必要な数字を同じ条件で取り出せるようにすることから始めましょう。 この記事では、数字が合わない理由の調べ方と、運用を直すか、システムの調査へ進むかの選び方を紹介します。必要な改善を、ツール名より先に決められるようになります。
まずは：直近で判断が止まった会議資料と、その数字の元になった明細を用意する。「何を決めるための数字だったか」を資料の余白に一行書く。
1週間以内の実行案：資料作成者と元データの管理者に、集計対象・期間・更新時点を確認する。一つの指標について、計算をたどれる状態にするのが目標です。明細を見られない場合は、閲覧できる担当者に食い違う一件の照合を頼むところから始めます。
数字が違うときは、先に「何を数えたか」を比べましょう
二つの数字が違っても、どちらかが間違いとは限りません。 同じ「売上」という名前で、営業は受注した金額、経理は検収を基準に集計した金額を見ていることがあります。
たとえば、次のような場合です。金額と条件は説明用の記入例です。
会議に出てきた数字 | 明細をたどって分かったこと |
|---|---|
営業資料の4月「売上」1,200万円 | 4月受注の案件を集計。そのうちA案件300万円は5月検収予定 |
経理資料の4月「売上」900万円 | この例では4月検収の案件を集計。残り900万円の案件は両資料で共通 |
この例の差額300万円は、A案件を数える月の違いです。数字を無理にそろえるより、「4月受注金額」と「4月検収金額」に名前を分けるほうが、違いを説明できます。実際に採用する会計上の基準は、経理の定義を確認しましょう。
次に、「この会議では何を決めたいのか」を会議責任者に聞きます。受注の勢いを知りたいなら受注金額が候補になります。一方、来月の入金余力を決めるには、この二つの数字だけでは足りません。入金予定や支払予定も必要です。
指標は、名前を統一する前に、答えたい問いと対応させましょう。 英国政府のデータ品質フレームワークも、利用者と用途に応じて品質を評価する考え方を示しています。
データ一元化の前に、定義・入力・更新・接続を切り分ける
直す場所は、食い違いが生まれた場所で変わります。資料を作った人に合計値だけを聞くのではなく、同じ案件を一件選び、入力から集計までたどりましょう。
起きていること | 最初に確かめる相手と問い | 先に試す改善 |
|---|---|---|
同じ案件なのに集計対象が違う | 資料作成者へ「どの日付・状態を含めていますか」 | 指標名と対象条件を分け、同じ条件で再集計する |
元の記録に抜けや重複がある | 入力担当へ「いつ、どこへ記録し、訂正していますか」 | 正しい入力先と訂正手順を決め、同じ内容の再入力を減らす |
元データは新しいが資料は古い | 更新担当へ「取得はいつ完了しましたか。失敗を誰が見ますか」 | 更新時刻・対象期間・失敗時の連絡先を表示する |
元データは正しく、取得や表示で止まる | システム管理者へ「どの処理で、どんなエラーや遅延が出ますか」 | ログ・処理時間・件数を調べ、接続や基盤の改善を検討する |
一件の照合で全体の品質が分かるわけではありません。ただし、集計条件の違いが見つかったなら、いきなり全システムを移すより、その違いを説明できるようにするのが先です。別の案件でも同じ理由かを確かめ、説明できない差は残しておきましょう。
「正本」は一つの巨大ファイルではなく、迷わず戻れる元データ
正本とは、その情報の訂正・更新を担う元データです。 すべての情報を一つの表へ移す必要はありません。顧客情報は顧客管理システム、請求情報は請求システムに残したまま、案件IDなどで対応を追える形も選択肢になります。
先ほどの例なら、まず会議資料に次の定義を添えます。
用途：4月の受注状況を商材別に振り返る。
対象：受注日が4月1〜30日の確定案件。取消案件は除く。金額は税抜。
元データ：営業管理の案件一覧。案件IDで明細へ戻る。
更新：営業管理担当が会議前日の17時時点で取得。資料に取得日時を記載。
訂正：案件担当が元データを直し、営業管理担当が再集計する。資料だけを手直ししない。
注意：検収金額・入金額を示す指標ではない。
これは、その会社の会議用に決めた例です。更新を毎日行う必要があるかは、判断の締切から考えましょう。月次の振り返りと、当日の在庫引当では、必要な新しさが違います。
見られる人も、用途に応じて決めます。集計結果を使う人全員に、顧客の個人情報や契約明細まで開く必要はありません。元データへのアクセス権を変える場合は、管理者に確認しましょう。
既存ツールで直せるか、データ基盤を調べるか
定義や更新手順の問題と、システムの処理能力の問題を分けて考えましょう。
前者なら、既存の表に定義・取得日時・元データへの参照を加えて、次の会議で使えるか試せます。新しい二重入力を増やさず、訂正を追えることが条件です。
一方、次のような状態なら、接続方式やデータ基盤の技術調査が必要になることがあります。
- 必要な件数・頻度では取得が終わらず、判断の締切に間に合わない。
- 接続先の変更で処理が止まり、失敗の検知や復旧を担う人も決まっていない。
- 複数システムのIDが対応せず、同じ顧客や案件を誤って結び付ける。
- 必要な閲覧制御や変更履歴を、今の構成で確保できない。
星野リゾートの公開事例では、既存のBIへの接続だけでは安定性や性能に課題があり、データ基盤から見直した経緯が紹介されています。画面の見づらさに見えても、直す対象が画面とは限らない例です。
会社の規模だけで「表計算で十分」「基盤構築が必要」とは決められません。相談する際は、利用人数より先に、止まる処理・データ量・更新頻度・必要な権限・運用担当を伝えましょう。データと業務の流れ自体が見えていない場合は、PROTOCOREのData & Workflow Discoveryの案内も確認できます。基盤構築の可否や個別の接続対応は、対象システムを含めて確認してください。
ダッシュボードは、次の会議で一つ判断してから広げましょう
最初の到達点は、グラフを増やすことではありません。一つの指標について、数字の意味と残る不確かさを説明したうえで、決める・保留するを選べることです。
次の会議では、修正した指標と明細を使い、次の三つを確かめましょう。
- 同じ条件で集計した数字を、資料作成者以外もたどれるか。
- 更新遅れや未入力がある場合、判断に与える影響を説明できるか。
- その数字で、予定していた判断ができたか。できないなら、別の情報が足りないのか。
数字が一致しても、判断に必要な情報が足りなければ追加確認へ戻ります。判断できたら、その定義と更新手順を残して、次の指標へ広げましょう。一元化の範囲は、会議で必要になった情報から決められます。