1. Score Keeper:データの源泉の担い手
Score Keeperはその名の通り、会計処理を行う・仕訳計上するというアクションを通じて、データそのものを生成する役割を担っています。したがって、いかに正確に、スピーディーに、かつ効率よくデータを生成するかという点が重要です。
一方で、生成したデータも経営判断に活用できなければその意味が半減します。Score Keeperをデータの源泉の担い手として捉えた際の処理プロセスの自動化・効率化にとどまらず、データ利用者にとって利用価値の高いデータをどのような形で生成・蓄積すべきか、これまで以上に真剣に取り組む必要があります。
例えば、ERPシステムの導入プロジェクトにおけるこれまでのファイナンス部門の関与は、現状プロセスとERP標準プロセスのFit/Gap分析など、プロセス面に照準を合わせたタスクに終始していたケースが多いと思います。その結果、新システムが無事稼働し、日々の経理オペレーションや決算プロセスが進むようになりましたが、一方でERPに蓄積されたデータを経営判断にスムーズに活用できないという現象が生じています。
管理指標をどのような管理軸で評価・分析したいかという「管理要件」は、そのために保持すべきデータの粒度・属性・鮮度といった「データ要件」に直結します。したがって今日的なERP導入プロジェクトにおいては、経理処理プロセスの効率化にとどまらず、利用価値の高いデータを使いやすい形で生成するために、どのような業務処理プロセスであるべきかという観点の方がはるかに重要です。経理処理プロセスの標準化はその効率化のためではなく、データ標準化の実現手段であるというくらいの割り切りが必要になると考えます。
また、データの源泉はERPだけではありません。経営判断に活用するためのデータの価値・重要性・有用性を適切に判断し、企業内で発生するさまざまな活動の中で、どの活動を、どのような形で、アナログ情報からデジタルデータに変換すべきか、Score Keeperをデータの源泉の担い手として捉えた際、ただやみくもにデータを生成・集積するだけでなく上記の観点を包括的に検討し、そのための手段として業務プロセスを再構築する視点が求められます。
2. Custodian:データそのものの番人
Custodianは企業価値を守る番人として、不正リスクの検知や予防的統制、あるいは財務リスクの適時把握とヘッジのために、データを活用します。
さらにデータに着目した際、Custodianはデータそのものの番人、すなわちデータガバナンスの推進者としての役割も見逃すことができません。
経営管理要件を満たすためには、トランザクションデータの標準化・構造化要件のために、ファイナンス部門にとどまらない社内各部門のオペレーションルールの統一・徹底や業務プロセス標準化を推進する必要があります。また、取引先マスタ、勘定科目マスタといった、マスターデータをグループ内で統合・標準化するために、メンテナンス処理、申請プロセスを含めたガバナンスの徹底も必要です。こうしたグループ内の会社・部門横断的な役割の担い手として、ファイナンス部門のCustodianが進化する必要があります。
3. データ蓄積の手段の進化
前述のようにERPシステムは、標準化されたデータを構造的に蓄積するための手段として非常に有用です。
このERPシステムにも課題があります。一つ目は、巨額となりがちなシステム投資を正当化できるかという点です。Finance DXで見込まれる定量効果、定性効果を包括的に把握した上で、客観的にROIを見極め、その是非を判断する必要があります。
二つ目は、過度な業務標準化を許容できるかという点です。
ERPが広がり始めた1990年代半ば、あたかも取引伝票と仕訳伝票が複写式になっているかのようなフロントモジュールからの自動仕訳生成は、非常に魅力的なものでした。それ以前は販売管理システムから売上伝票を出力し、それを元にシステム外で仕訳伝票を起票して、会計システムに再投入するような手作業が横行しており、それが非効率や間違いの温床になっていました。当時のERPシステムの登場は、この問題を一気に解決したと言えます。
しかし、こうした便利さとは裏腹に、ERPシステム内の取引伝票処理と会計仕訳伝票処理が密結合であることに起因する不都合もあります。ERPで定義された取引伝票パターン×仕訳伝票パターンで対応できるよう、経理処理プロセスにとどまらず、フロント側の業務プロセスまでも定型パターンに収まるように標準化する必要が生じました。すなわち、経理をはじめとした後続プロセスの効率化やデータの標準化のために、営業などのフロント部門に対しても業務標準化を強いる結果になりました。
これはフロント部門の現場ユーザの不平不満の原因となるだけではなく、新規事業や新たな収益モデルが既存の取引パターンで対応できない場合、システムが迅速な新規事業・新収益モデル展開の足かせになる、という最悪のケースを招く懸念がありました。
こうした懸念を払しょくする一つの方法として、事業特性にマッチした各フロントシステム、仕訳生成システム、会計帳簿システムの三つにシステム構成を分け、その間を標準インターフェースでつなぐコンセプトが考えられます。この方法により、フロントシステム側の柔軟性・拡張性と、会計仕訳・データ側の標準化・統合化を両立することが可能です(<図2>参照)。