「SAPの入れ替えが始まるらしい。情シスとベンダーがやってくれる」――経理がこの姿勢で移行を迎えると、稼働後にしっぺ返しが来る。月次の締めが以前より遅くなった、欲しい単位で損益が出ない、監査対応の手作業が増えた。稼働してから「そんなはずでは」と気づいても、作り込みはもう固まっている。移行の失敗の多くは、技術の失敗でなく、経理財務が要件を出すべき局面で沈黙していたことに起因する。 かといって、経理が設定作業まで抱え込むのも違う。丸投げと過干渉のあいだに、経理が主体となって決めるべき意思決定の範囲がある。本稿は、その範囲を工程ごとに示す。
なぜIT主導だと経理の要件が抜けるのか
移行プロジェクトの体制図を見ると、たいていIT部門とベンダーが中心にいる。彼らは「動くシステムを期限内に作る」ことに責任を持つ。そして動くことと、経理が使いやすいことは別物だ。IT側から見れば、標準機能で伝票が起票でき残高が合えば、システムは「動いている」。だがその標準が、自社の締めの段取りや、見たい損益の切り口に合っているかは、経理でないと判断できない。
だから経理が黙っていると、要件は技術的に楽な場所に落ちる。締めのフローはSAP標準のまま、損益の粒度はデフォルトの科目単位、統制は「あとで規程で縛る」。個々は間違いではないが、積み重なると「動くが使えない」システムができあがる。ERPが会計システムと決定的に違うのは、業務プロセスそのものを規定する点にある（ERPとは何か、会計システムとの違いと経理・財務の立場から見た選び方の基準）。プロセスを決める場に経理がいなければ、経理の業務が他人の設計で固定されてしまう。
経理が担うべきは「作業」でなく「意思決定」
ここで関与の質を取り違えないことが肝心だ。経理が移行に関わるとは、設定画面を触ることでも、テストデータを黙々と流すことでもない。押さえるべきは、後戻りできない意思決定のほうだ。具体的には三つに集約される。
- 科目と粒度――どの単位で損益・残高を見たいか。これはCOA再設計の話に直結する（SAP移行を機にする勘定科目体系（COA）の再設計）。
- 統制――発注と支払、仕訳と承認をどこで分けるか。監査で問われる職務分掌を、規程でなく権限設計で担保する。
- 締め――いつ・どの順で締めるか。標準フローに合わせるのでなく、自社の締めをどう作り込むか。
この三つは、ベンダーが代わりに決められない。決めるのに会社の意思が要るからだ。逆に、この三つさえ経理が決めれば、細かな設定はIT・ベンダーに任せてよい。丸投げすべきでないのは意思決定で、抱え込むべきでないのは作業――この切り分けが関与の軸になる。
いつ何を決めるか――工程ごとの決めどき
意思決定には、それぞれ決めどきがある。早すぎても情報が足りず、遅すぎると手戻りになる。工程の流れに沿って、経理が何を出すべきかを並べる。
とりわけ効くのが要件定義とテスト（UAT）だ。要件定義で出さなかった要望は、設計に載らない。設計に載らなければ、テストで検証する対象にすらならない。そしてテストは、IT部門が用意した理想データでなく、月末が集中する実データで、実際の締めを最初から最後まで通してみる必要がある。ここで初めて「この帳票が出ない」「この単位で集計できない」が露見する。稼働後に気づけば作り直しだが、テストで気づけば設計変更で済む。移行後にデータを見るだけの器で終わらせないためにも、テストは経理の主戦場だ（SAP移行後もExcelと標準帳票に頼り、データを活かせない原因と最初の一手）。
ある会社では、要件定義の段階で経理が「事業別・地域別の損益を締めから3営業日で見たい」と一行だけ要件に書き込んだ。それだけで、補助軸の設計、締めフローの並行化、帳票の作り込みが、後工程で当然に検討対象になった。逆にこの一行がなければ、標準の科目別損益しか出ず、稼働後にExcel集計へ逆戻りしていた。要件は、後工程が拾える形で早く出すほど安く実現する。同じ要望でも、稼働後に言えば作り直し、要件定義で言えば設計に織り込むだけで済む。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
過干渉もまた失敗
最後に逆側の注意を。経理が心配のあまり設定の細部まで口を出し、あらゆる例外処理を作り込ませると、移行はアドオンの塊になり、保守費が膨らみ、次の移行がまた重くなる。標準に寄せるべきところは寄せ、譲れない要件だけを筋を通して守る。この見極めこそが経理の腕の見せどころだ。要件のオーナーであることと、何でも作り込ませることは違う。守るべき数本を決め、それ以外は手放す胆力が要る。
