社長から「製品別の物流費を出荷重量あたりで見たい」という依頼が来る。経理はSAPから勘定別の残高を落とし、物流部からトンベースの出荷実績をもらい、Excelで突き合わせる。三日かかる。 翌月、今度は「同じものを地域別で」と来る。また三日かかる。 半年これを続けたところで、情報システム部門がBI基盤の見積りを持ってくる。初期費用四千万円、年間利用料八百万円。会議の論点は、金額に見合うかどうかになる。 そして金額の話をしている限り、この投資がそもそも要るのかという問いには、誰も答えられない。
分かれ目はデータ量ではない
BI基盤の必要性を説明するとき、最も多く使われる根拠がデータ量である。仕訳明細が年間で何千万行あるから、Excelでは扱えない。 この説明は、聞こえは良いが判断の役に立たない。インメモリのデータベース上に載っている明細テーブルは、行数が増えても集計に耐えるように作られている。 行数で困っているなら、それは器の問題ではなく、集計をどこでやっているかの問題である。
実際に判断を分けるのは、分析対象が会計データの中で閉じているかどうかである。
売上を製品別・得意先別・月別で見る。原価差異を工程別に分解する。部門別の損益を配賦後で追う。これらは、伝票に付いている属性の組み合わせでしかない。 勘定コード、利益センタ、原価センタ、製品コード、得意先コード、プロジェクト。すべて仕訳の中にある。ERPの中で完結する。
一方で、出荷重量あたりの物流費、稼働時間あたりの製造間接費、受注残の消化速度、Webの問い合わせから受注までの転換率、従業員一人あたりの粗利。これらは、会計データの分母か分子のどちらかが会計の外にある。 重量は物流システム、稼働時間は生産管理システム、受注残は販売管理システム、問い合わせはマーケティングツール、人員は人事システムにある。そして分母が外にある指標は、ERPの中の会計データだけでは出せない。
判断の質問はこうなる。経営から来る依頼のうち、分母か分子が会計の外にあるものは何割か。 三割を超えていれば器が要る。一割なら、要るのは器ではなく、ERPの中の分析機能を誰も使っていないという事実の是正である（SAP移行後もExcelと標準帳票に頼り、データを活かせない原因と最初の一手）。
「Excelに落としている」は、二つの別の病気の症状である
現場から上がってくる訴えは、どちらの場合も同じ言葉になる。毎月Excelに落として手で加工している。 同じ症状だが、原因が違う。
第一の病気は、ERPの標準の分析機能を誰も使っていないという状態である。帳票が要件定義の段階で「既存システムと同じ様式」に固定され、稼働後に標準のレポートを触った人がいない。 この場合、BI基盤を入れても症状は消えない。外の器に同じデータを複製して、同じようにExcelに落とすだけになる。
第二の病気は、突き合わせる相手が会計の外にあるという状態である。これは器がなければ解決しない。 ただし、ここでも先に確認すべきことがある。外にあるデータの側が、突き合わせに耐える粒度と鮮度で存在しているか。
物流部が持っている出荷重量が、月次で集計された一枚のExcelとしてしか存在しないなら、それをBI基盤に取り込んでも製品別には割れない。基盤を入れる前に、外側のシステムが出荷明細を製品コード付きで持っているかを確認する。 ここで詰まる会社は多く、そして詰まった結果として、高価な器の中で、月次の集計値どうしを掛け算するという、Excelと変わらない作業が始まる（SAPから出したExcelが正本になっていないか、加工した集計表をどこまで許すか）。
症状で判断せず、落としている中身を一か月分、実際に数える。 会計データだけの依頼が何件で、外と結ぶ依頼が何件か。この二つの数を並べた紙が、四千万円の見積書より判断に効く。
データ基盤を挟むと決めたら、定義の管理主体が問題になる
器を入れると決めたら、次に決めるのは製品ではない。同じ名前の指標が、二つの場所で別の値を持つという事態をどう防ぐかである。
ERPの中の売上高と、BI基盤の中の売上高。取り込みのタイミング、対象会社、内部取引の消去、返品や値引きの反映。この四つのどれか一つがずれれば、値は違う。 そして違ったとき、経営会議の場では「どちらが正しいのか」という議論になる。議論の結末はたいてい、経理が持っているほうを正とし、BIの数字は参考値と呼ばれるようになる。参考値と呼ばれるようになると、その基盤は使われなくなっていく。
これを防ぐうえで効くのは、指標の定義を管理する人を、システムを管理する人と分けて任命することである。 定義を持つのは経理か経営企画で、システムを持つのは情報システム部門。定義の変更は定義側の承認がなければ実装されない、という順序を作る。
そして定義は、名前ではなく算式で書く。売上高（連結、内部取引消去後、値引き控除後、計上基準は出荷）というところまで書き、どのテーブルのどの項目を、どの条件で集計するかまで含める（グループでKPIの定義がずれる問題、同じ名前の指標をそろえる定義書と改訂手続き）。
もう一つ、器を入れる前に決めておくべきものがある。分析軸である。 後から足せる軸と足せない軸があり、足せないほうが多い。伝票に付いていない属性は、BI基盤に取り込んでも生えてこない（管理会計の分析軸（ディメンション）設計、後から分解できない粒度を先に決める）。
帳簿はERPに残る。BIは正本にならない
技術と定義の話の後に、もう一つ効いてくる論点がある。外に出したデータは、帳簿ではない。
電子帳簿保存法における優良な電子帳簿の要件は、訂正または削除を行った場合にその事実と内容を確認できること、通常の業務処理期間を経過した後に入力した場合にその事実を確認できること、電磁的記録の記録事項と関連する他の帳簿の記録事項との間で相互にその関連性を確認できること、そして取引年月日・取引金額・取引先により検索できることを含んでいる。 これらを満たし、あらかじめ所轄税務署長に届出書を提出している場合、その電子帳簿に記録された事項に関して申告漏れがあったときの過少申告加算税が5パーセント軽減される。
この要件を満たすのは、ERPの側である。 BI基盤に複製されたデータは、訂正削除の履歴も、他の帳簿との相互関連性も、原本としては担保されない。したがって、BI基盤に入れたからERPの帳票を止めてよい、という判断はできない（電子帳簿保存法のスキャナ保存・電子取引を月次決算の工程に組み込む手順）。
同時に、統制の対象は増える。財務報告に係る内部統制の評価では、業務プロセスの統制がITに依存している場合、そのITに係る全般統制も評価の対象になる。 器を一つ増やすということは、アクセス管理、変更管理、運用管理の対象を一つ増やすということである。外に出した数字が経営会議の資料になり、それが開示の数字に影響するなら、その経路も評価の範囲に入る（SAPの権限設計と職務分掌（SoD）、内部統制を仕組みで担保する実務と判断基準）。
費用対効果の議論に、この二つを列として足す。 帳簿としての義務はERPに残り続けること。統制の対象が一つ増えること。初期四千万円と年間八百万円の隣に、この二行が並んで初めて、投資の判断ができる。
BI基盤の要否を判断するために決める三つのこと
第一に、必要性の根拠をデータ量から「分母か分子が会計の外にあるか」に置き換える。 SAP S/4HANAでは財務会計と管理会計の伝票が統合され、総勘定元帳、管理会計、資産会計、材料元帳の明細がACDOCAという単一の明細テーブルに集約されて、CDSビューやODataサービスを介した分析がERPの中で動く。製品別売上、得意先別粗利、部門別損益、原価差異の工程別分解は、いずれも伝票に付いた属性の組み合わせであり、外に出す技術的な理由はない。 一方、出荷重量あたりの物流費、稼働時間あたりの間接費、受注残の消化速度、一人あたり粗利は、分母か分子が生産管理・物流・人事・販売管理の側にあるため、ERPの中では原理的に出せない。経営から来る依頼を一か月分数え、後者が何割かを出す。この紙が見積書より判断に効く。
第二に、Excelに落としているという症状を、二つの原因に切り分ける。 標準の分析機能が使われていないだけなら、器を入れても同じ作業が外側で再現される。突き合わせる相手が会計の外にある場合でも、その外側のデータが突き合わせに耐える粒度と鮮度で存在しているかを先に確認する。 物流の出荷実績が月次の集計値としてしか存在しないなら、基盤に取り込んでも製品別には割れず、高価な器の中で集計値どうしを掛け算する運用が始まる。着手の順番は、外側のシステムの明細化が先で、器は後である。
第三に、挟むと決めたら、製品より先に定義の管理主体を決める。 ERPの値とBIの値がずれる原因は、取り込みのタイミング、対象会社、内部取引の消去、返品・値引きの反映の四つに集中する。ずれた瞬間にBIの数字は参考値と呼ばれ、参考値と呼ばれた基盤は使われなくなる。定義を持つのは経理か経営企画、システムを持つのは情報システム部門と分け、定義側の承認なしに実装されない順序を作る。定義は名前ではなく算式で書く。 そして費用対効果の表に二行足す。電子帳簿保存法の優良な電子帳簿の要件、すなわち訂正・削除の事実と内容の確認、通常の業務処理期間経過後の入力の確認、他の帳簿との相互関連性、取引年月日・取引金額・取引先による検索を満たし、あらかじめ届出書を提出することで過少申告加算税が5パーセント軽減されるという枠組みは、ERPの側で満たすものであり、複製先のBI基盤は原本にならない。そして器が一つ増えれば、IT全般統制の評価対象も一つ増える。
売上高680億円の食品メーカー。S/4HANAへの移行から三年が経ち、経営企画部からBI基盤の導入提案が上がった。見積りは初期3,800万円、年間利用料720万円。 提案書に書かれていた根拠は二つで、仕訳明細が年間2,400万行に達していることと、経営からの分析依頼に平均で4営業日かかっていることだった。CFOが差し戻した理由は、この二つがどちらも「外に器が要る」ことの証明になっていないという点だった。 差し戻しの際に指示したのは、直近12か月に経営から来た分析依頼を全件洗い出し、必要なデータがどこにあるかで仕分けることである。依頼の総数は87件。仕分けの結果、会計データだけで完結するものが61件、会計の外のデータと突き合わせる必要があるものが26件だった。 61件の内訳を見ると、製品カテゴリ別の粗利率、得意先別の値引き率、工場別の原価差異といった、伝票の属性を組み替えれば出るものが並んでいた。このうち49件は、S/4HANAの標準の分析アプリケーションで出せるものだったが、経理部でその画面を開いたことがある人間は一人もいなかった。 稼働時の教育が、伝票入力の操作研修に限られていたことによる。残る26件の内訳は、物流費を出荷重量で割るものが11件、製造間接費を設備稼働時間で割るものが8件、人員一人あたりの指標が7件。 ここで新たに分かったことがある。物流部が持っていた出荷実績は、月次で運送会社別に集計されたExcelで、製品コードが付いていなかった。 つまり、BI基盤を入れても11件のうち製品別に割れるものはゼロだった。着手はこの順序になった。第一に、標準の分析アプリケーションの利用研修を経理部と経営企画部に対して実施。所要は延べ3日で、外部費用は発生していない。 これで87件のうち49件が、依頼から半日以内で出せるようになった。第二に、物流部の出荷データに製品コードを持たせる改修を、運送会社への発注データの側から行った。 費用は420万円、期間は5か月。第三に、BI基盤の導入そのものは、この二つが終わった時点で再度判断することとし、この期は見送っている。 一年後に再検討した際、外と結ぶ依頼の件数は26件から41件に増えていた。理由は、標準機能で会計の中の分析が速く出るようになった結果、経営からの依頼の質が上がったことにある。 この時点で導入を決め、契約したのは当初提案とは別の構成で、初期費用は1,900万円に下がっている。下がった理由は、要件が「何でも見られる基盤」から「41件の指標を出す基盤」に絞られたためだった。 経営企画部長の言葉が記録に残っている。最初の提案は、うちが何を見たいのかを一件も書かずに、何でも見られる箱の値段だけを書いていた。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
会計データをERPの外に出すかどうかは、データ量では決まらない。会計の中で閉じた分析ならS/4HANAの中で足り、外に器が要るのは、分母か分子が会計の外にある指標が依頼の主流になっている場合である。
見積書を比べる前に、次の順で確かめたい。
- 直近の分析依頼を全件洗い出し、会計だけで完結するものと外のデータと結ぶものの件数を数える
- 会計だけで完結する依頼が、標準の分析機能で出せないかを試す
- 外と結ぶ依頼について、相手側のデータが製品コードなどの明細で存在するかを確認する
- 導入するなら、製品より先に指標の定義を管理する担当を決め、帳簿の義務とIT全般統制の対象増を費用対効果の表に加える
関連記事
- SAP移行後もExcelと標準帳票に頼り、データを活かせない原因と最初の一手
- SAPから出したExcelが正本になっていないか、加工した集計表をどこまで許すか
- SAP Analytics Cloud（SAC）で計画と実績を一つのモデルにつなぐ進め方
- 管理会計の分析軸（ディメンション）設計、後から分解できない粒度を先に決める
- グループでKPIの定義がずれる問題、同じ名前の指標をそろえる定義書と改訂手続き
- SAPの帳票・レポート要件を絞る手順、標準で出す・作る・廃止するの3分類
- 経営ダッシュボードの作り方、載せない指標から決める3原則と10の数字
- 電子帳簿保存法のスキャナ保存・電子取引を月次決算の工程に組み込む手順
- SAPの権限設計と職務分掌（SoD）、内部統制を仕組みで担保する実務と判断基準
