本社の稼働が落ち着くと、次のフェーズとしてグループ展開の計画が始まる。対象は何社か、順番はどうするか、一社あたり何か月か。工程表を引き、体制図を書き、投資対効果を試算する。ここまでは滞りなく進む。詰まるのは一社目の要件定義に入った瞬間で、現地から「この処理はうちの取引では回らない」という声が上がり、テンプレートに例外を一つ認める。その一件が通った時点で、二社目以降の要件定義はすべて交渉になる。テンプレート展開が崩れるのは、入れるか入れないかで議論しているからだ。決めるべきは範囲ではなく層である。 どの要件を絶対に動かさず、どの要件を会社ごとの設定で吸収し、どの要件を各社に委ねるか。この三層の境界を一社目の要件定義より前に確定させないと、展開は毎回ゼロから交渉するプロジェクトの連続になる。
「入れるかどうか」で議論している限り、線は引けない
グループ展開の稟議書に並ぶのは、たいてい会社の一覧だ。売上規模、従業員数、現行システム、稼働希望時期。この表を眺めて対象会社を選び、フェーズ1とフェーズ2に振り分ける。合理的に見えるが、この切り方では現場の議論が始まった瞬間に破綻する。
破綻する理由は単純で、会社という単位が業務の同質性を保証しないからだ。同じ製造業でも、受注生産と量産では原価の作り方が違う。同じ売上規模でも、国内一拠点と海外五拠点では締めの工程数が違う。会社規模で振り分けたフェーズ1に、業務の型が三種類混ざっていれば、テンプレートは一社目で三方向に引っ張られる。
切るべき軸は取引の型である。受注から請求までの流れ、在庫を持つか持たないか、原価をどう積むか、債権の回収サイクル。この型が同じ会社は同じテンプレートで回るし、型が違う会社は規模が近くても回らない。展開計画の最初の成果物は会社一覧ではなく、取引の型で会社を束ねたグルーピング表になる。
そして、この段階で「同じERPを入れない」という選択肢を明示的に持っておく。従業員十数名で取引の型も本社と違う会社に、本社と同じ基幹システムを入れて維持する合理性は薄い。それでも展開対象に入るのは、統一という言葉が判断の代わりに使われているからだ。ERPと会計システムの守備範囲が違うことは、この判断の出発点になる（ERPとは何か｜会計システムとの違いと、経理・財務が知るべき選び方）。
テンプレートは配る前に三層へ割る
三層に割るとは、要件ごとに「誰が変更を決められるか」を決めることである。層の名前は何でもよいが、変更権限が三段階になっている必要がある。
| 層 | 入るもの | 変更を決められる人 | 変更の手続 |
|---|---|---|---|
| Core | 勘定科目体系、会社コード・管理領域の設計思想、利益センタの切り方、締めスケジュールと承認の型 | 本社の管理部門とグループCFO | 変更申請は原則却下。認める場合はテンプレート本体を改版し全社へ再展開 |
| Configurable | 税コード、支払条件、通貨とレートタイプ、承認金額の閾値、帳票の言語と様式 | 展開先の会社と本社PMOの合議 | 設定値の変更として処理。テンプレート本体は改版しない |
| Local | 現地の法令が求める処理、現地の税務申告に必要な項目 | 展開先の会社 | 法令の根拠を添えて申請。期限とオーナーと戻し方をセットで登録 |
Core層に何を入れるかで、グループ展開の意味が決まる。勘定科目体系がここに入っていなければ、展開が終わっても連結の消去仕訳は各社ごとの手作業のままで、投資回収の説明が立たない（SAP移行を機にする勘定科目体系（COA）の再設計｜全社で数字を揃える）。会社コードと管理領域は、そもそも稼働後に事実上変更できない領域であり、テンプレート側で思想を固定しておかないと、展開先ごとに違う粒度で作られて後から揃えられなくなる（SAPの組織構造設計（会社コード・管理領域・利益センタ）｜アドオンで直せない唯一の領域）。
Configurable層の設計が、展開の速度を決める。ここが薄いテンプレートは、現地の事情が全部Local層かCore層への変更申請に流れ込む。逆に厚すぎると設定パターンが爆発し、二社目以降の要件定義で「どの設定値にするか」の会議が延々と続く。目安として、Configurable層に置く項目には必ず既定値を持たせておく。既定値のない設定項目は、展開のたびにゼロから議論される。
現地要件は「法令・商慣行・慣れ」に分解する
展開先から上がってくる要件は、ほぼ例外なく「うちは特殊なので」という前置きで始まる。この前置きを額面で受けると、テンプレートは一社目で溶ける。分解の一問は決まっている。この形でないと現地の法令に反するか。
三つ目の扱いを間違えないことが、テンプレートを守る唯一の方法になる。現地の担当者は嘘をついているのではなく、いまのやり方でずっと締めてきたという事実を要件だと受け取っているだけだ。だから「不要ですね」と切るのではなく、標準のやり方でその締めが回ることを、展開のリハーサルで実際に見せる。見せずに切ると、稼働後に手元のExcelで復活し、二重管理が始まる（SAP稼働後にユーザーが使わなくなる理由｜定着を決めるのは操作研修ではない）。
二つ目の商慣行が最も判断に手間がかかる。相手がいるため一方的に変えられず、かといって法令ほど固くない。ここは件数で切る。その商慣行で動いている取引が年に何件あるかを出させ、件数が少なければ運用で受け、多ければConfigurable層で吸収できるかを検証する。件数を出せない要件は、その時点で保留にして戻す。
展開順は規模順ではなく、テンプレートが壊れる順に組む
展開順の定石として語られるのは、小さく素直な会社から始めて成功体験を作る、というものだ。実装側の経験から言えば、この順序はテンプレートの検証を先送りするだけになる。素直な会社は素直に入るので、テンプレートの弱点が見つからない。弱点が見つかるのは、最も型の違う会社に当てたときだ。そしてその時期が遅いほど、直す範囲は大きくなる。
二社目を検証工程として工程表に明記する。この一手が抜けると、フェーズ1の三社が全部素直に入り、テンプレートは検証されないままフェーズ2へ渡る。フェーズ2で初めて型の違う会社に当たり、そこでテンプレート本体の改版が必要になると、既に稼働している三社への再展開が発生する。この再展開は、当初の投資対効果の試算には入っていない。
移行アプローチそのものも会社ごとに変わりうる。本社は既存システムのコンバージョンで、子会社は新規構築、といった組み合わせは珍しくない。アプローチが違えば工程も成果物も変わるため、テンプレートの再利用範囲は会社ごとに変わる。工程表を引く前に、会社ごとのアプローチを確定させておく。
例外は認めてよい。期限とオーナーと戻し方が付いていれば
テンプレート展開の現場で最も破壊的なのは、例外を認めないという方針そのものではなく、方針を掲げたまま一件だけ黙認することである。黙認された一件は前例になり、次の会社は「あの会社は認められた」と言う。この時点で層の境界は消え、以降の要件定義は交渉になる。
だから例外は制度として認める。認める代わりに、閉じる条件を三つ付ける。
- ① 期限（稼働後1年など。期限のない例外は恒久化し、次のバージョンアップで負債になる）
- ② オーナー（展開先の会社側に置く。本社PMOに置くと、プロジェクト解散と同時に持ち主が消える）
- ③ 戻し方（期限到来時に標準へ戻す手順。戻し方を書けない例外は、そもそも認めない）
三つ目が効く。戻し方を書かせると、多くの例外はその場で取り下げられる。戻せない例外は、実質的にテンプレート本体の改版要求であり、だとすればその会社だけの話ではなく全社の話になる。全社の話として持ち上がった時点で、Core層の変更申請として正規の手続に乗る。例外の申請書に戻し方の欄を一つ足すだけで、この選別が自動的に働く。
追加開発を伴う例外は、さらに一段の関門を置く。展開先ごとに作った追加開発は、テンプレートのバージョンアップのたびに全社分の検証対象になる。三社に別々の追加開発があれば、検証工数は三倍になる。固有性・標準代替可能性・保守コストの三軸で切る判断は、展開フェーズでこそ厳しく当てる（SAPアドオン（追加開発）をどこまで作るか｜Fit-to-Standardの判断基準）。
同じERPを入れない会社にも、会計の器だけは揃えさせる
展開対象から外した会社を、放置してよいわけではない。むしろ、外すと決めた会社にこそ、何を揃えさせるかを明示する必要がある。揃えるべきは業務のやり方ではなく、数字の器である。
具体的には三つで足りる。勘定科目のコードと定義を本社の体系に合わせること。利益センタあるいはそれに相当する管理単位の切り方を合わせること。締めのスケジュールと、連結パッケージに載せる項目の定義を合わせること。この三つが揃っていれば、使っているシステムが会計ソフトであっても、グループとしての数字は作れる。逆に、同じERPを入れても、この三つが揃っていなければ連結は手作業のままになる。
システムを揃えることと数字が揃うことは別だという理解が、展開範囲の線引きを現実的にする。連結パッケージの回収設計と、子会社側の経理体制をどう置くかは、この線引きとセットで決める（連結パッケージの設計と回収：子会社からのデータ収集を遅らせない運用）。買収した会社であれば、システムを入れる前に締めの型そのものを移す工程が先に来る。器を揃えるより前に、締めが同じ手順で回る状態を作らなければ、連結パッケージの提出期日そのものが守られない。
作り切る順番は、束ねる・割る・壊す・並走させるである
グループ展開は、対象会社を決める作業から始めない。取引の型で会社を束ね、テンプレートを三層に割り、二社目で意図的に壊しにいき、境界が固まってから並走させる。この順で組めば、四社目以降の工数は会社数に比例せず落ちていく。
順番を守るために工程表へ書き込むべきは二行だけである。一社目の要件定義完了時点で「Core・Configurable・Localの境界が確定していること」を終了判定に入れること。二社目を「テンプレート検証」というフェーズ名で明記し、テンプレート本体の改版工数をあらかじめ確保しておくこと。この二行が入っていれば、例外の一件が前例になる事故は起きない。そして展開対象から外す会社には、勘定科目・管理単位・締めの定義という三つの器だけを揃えさせる。同じシステムを入れることと、グループの数字が揃うことは、別の話である。
