第5回 前始末の重要性――業務システムと財務会計がコラボする
具体論に入る前に、やや抽象論になるが次のフレームワークを提案したい。
■モノが動けば「人も金も」動いている
販売管理や生産管理システムでは「材料から部品、中間品、製品」へ遷移し、得意先へ納品されている。その中で、「移動」は必ずついて回る。移動実績が仕入れや出荷、棚卸しにダイレクトにつながっている。つまり、「移動の度に金が絡んでいる」と理解しなければならない。
皆、意外と要求定義段階で財務連携を意識していないのではないかと思う。要求定義段階での主目的は業務の革新を注目するばかりで、財務のことは二の次になっているのではないか。あるいは、プロジェクトチームの主要メンバーに財務担当者がいないか、ほぼ要件定義作業完了時にレビューされる程度でないかと感じている。後述するが、多くの企業は財務について軽視しているのではないかと思う。
では、IFRSが導入されたらどうか。「IFRS」という錦の旗を振り、財務担当者が前面に出て来る絶好の機会である。業務担当者も財務担当者も経営企画担当者も喜ぶ「マネジメント基盤」を構築する絶好のチャンスではないかと考えたい。
以前連載していたコラム『製造業の業務改革とITの役割』で、次のように書いた。
スループット会計の話題に入る前に、モノが動くときには常に「財務との関係はあるのかないのか」を確認する必要があります。ここでは、仕訳を意識してください。財務部門の方とモノが動くパターンを整理し、仕訳ルールを確認しなければなりません。
■財務仕訳を知らねば、全体を鳥瞰できない
財務連携における仕組みの流れを説明します。まず実績データの抽出と集計を繰り返します。次に自動仕訳データを作成し、財務システムへ連携します。事務処理を合理化する狙いがありますが、同時に仕訳の正確性も担保されます。
仕訳パターンとして「出荷」「検収実績」は分かりやすいのですが、そのほかのパターンが洩れてしまうことが多くなります。例えば、仕入品に不良が あった場合、値引き対応なのか返品にしたのか、場合によってそれぞれ仕訳が異なります。社内の在庫移動でも、部門別・倉庫別在庫管理をしている場合は同様です。
従って、それぞれのモノの動きをパターン化します。
システムとして考慮すべきことは、実績データ内に、自動仕訳区分などデータ属性を定義する区分を設定することです。また、本支店の部門、倉庫コードなど、在庫管理上のkeyを定義し、受払表に移動元と移動先をきちんと表現できるようにします。
仕訳が正確でない場合、財務の数字が使いものになりません。また、システムの全体整合性と精度の担保は、仕訳を理解することから始まります。
会社が間違った仕訳処理をした場合、内部統制ができていないとも言われるリスクもあります。また、利益を正しく報告していなければ、課徴金対象と もなりかねません。「生産管理担当だから財務仕訳を知らなくてもよい」とは言えません。ものの流れが変わった時、仕訳に影響するか否か、生産管理担当者は 気を配る必要があります。生産管理にかかわる現場担当者やIT関係者は、仕訳について論議しない風潮が多いように見えます。「ものが動けば金も動く」とはよく言ったものです。
■「前始末」と「横串のクロスファンクシヨン活動」
ところで、皆どれだけ前工程のことを知って、当該工程の仕組みを検討しているのか？
逆の言い方をすれば、後工程である財務管理のことを思って、当該工程の仕組みを検討しているのか？
お互いの業務における仕組み上のコアとは何か、前工程から送る情報の精度（品質）が何たるかを両方の部門が理解し共有していることが、本来の全体最適につながる。これは、言い方を変えれば、後工程で苦労する「後始末」にならないための前工程の「前始末」である。早い話、他部門のことを知らなくてもよいというスタンスが問題であり、案外、製造業のITを推進するベンダのほとんどは、財務管理について、財務パッケージベンダにお任せではないだろうか。
IFRSの推進は、財務の本質を理解する機会にもなる。 これはユーザー側にとっても同様であり、IFRSは業務部門と財務部門が協働してプロジェクト運営を図る中で、プロジェクトメンバー全員が自社のプロセス全体を考える絶好の機会となるだろう。そして、他のプロジェクト運営の参考となる、よりよい事例となる事を目標と掲げるべきだ。
次のフレームワーク（地頭力）にて構想立案すべきと考えるのも、一理あるのではないだろうか。
- 結論（ゴール）から考える「仮説思考力」
- 財務（仕訳を意識して）まで全体を鳥瞰して考える「フレームワーク思考」
- 抽象化しモデリングする。「抽象化志向力」
さらに、事業セグメントを検討する中で、「プロダクト（商品群）」を当然意識する。 そのプロセスは部門間をまたがっている。なので、プロセス（部門）中心の視点ではなく、「プロダクト中心の視点」の思考であるべきと考える。プロジェクトチームは各プロダクト視点のチームとなり、クロスファンクションチーム（※1）として位置付けられる（下図）。
※1：クロスファンクションとは、社内横断的なチームが全社的な視点に立ち、顧客にとって最適な価値を考えて、トップに改革を提案すること。このチームの牽引役であるパイロットの最も重要な役割は、異なる部門、異なる価値観を持つ従業員の気付きと対話を促進することである。CFTにより提案され、経営会議で決定された課題を実行に移し、定量的な成果をあげるための手法の1つとしてV-upプログラムがあり、日産自動車のものが有名である。
ここまで、業務システムと財務との関わり、そしてチーム運営について述べた。
では、具体的なイメージを持って、表題にある業務と財務会計がコラボするには、どのような思考回路にすればよいのだろうかと考えてみる。
プロダクト＝事業セグメントと製品群の分類は、クロスファンクションチームにとって容易と思う。さらに、地域・部門のブレイクダウンも問題はないと思う。
難しい課題もある。財務担当しかなじみのない「科目」という言葉が、コミュニケーションを円滑にできないハードルになるのではないかと感じている（部門長は、部門損益科目については常々見ておられるかもしれないが）。
■業務フローと摘要一覧を作る
では、「材料が入荷し検収した」「部品を外注加工するため、無償支給した」「加工部品が入荷し検収した」「製品が完成した」「製品を出荷した」「出荷した製品が得意先にて検収された」などなど、平易な言葉として、定義したらどうだろうか？
表現力はともかくとして、モノの動きと行為が正しく伝わればよい。これを会計仕訳では「摘要欄」（適用ではない）に該当する。仕訳発生の理由などを分かりやすく説明する役割を持つ。
業務側のメンバーは、モノの移動とカネの移動、人の動きのなどを業務フローとして描き、そのプロセス単位に摘要を定義すればよい。そして、財務担当者はその摘要に対して、仕訳に変換定義すればよい。
以上の作業を繰り返し、重複や漏れをなくせば、業務標準化にも役立つ。また、この作業は通常行われている現状分析プロセスと大差なく、あらためて分析ツールなどを検討する必要はない。
以上の作業ができれば、ペーパーベースであるが、モノが動けば「人も金も」動いている実態が見える化されたことになる。
次回は、実装に大きく関わる「BOM部品表」と「自動仕訳」について、影響度と方法論へのアプローチについて考えてみたい。