SAP導入プロジェクトで、組織構造の設計に割かれる時間は驚くほど短い。会社コードは登記されている法人をそのまま並べ、原価センタは現在の組織図を写し、利益センタは事業部の一覧を貼る。キックオフから二、三週間で片づき、以後の議論はFit-to-Standardの判定とアドオンの査定に移っていく。だが稼働後に効いてくる順序は、これと逆だ。アドオンは作り直せる。設定も直せる。会社コードと管理領域だけは、事実上変更できない。 組織構造の設計とは、いまの組織図を写す作業ではなく、数年先の資本政策を先に器の形にしておく作業である。
「直せない」の中身を、先に正確に把握する
組織構造の議論は、しばしば「後で変えられないので慎重に」という漠然とした注意で始まり、どこまでが本当に変えられないのかが共有されないまま進む。実際の境目ははっきりしている。
会社コードは、伝票が転記された時点で削除できなくなる。統廃合や番号の付け替えは、SAPが提供するDMLT（Data Management and Landscape Transformation、旧称SLO）のようなデータ変換の専用サービスで技術的には可能だが、これは設定を直す作業ではない。過去の全伝票・全残高・全マスタを書き換える別プロジェクトで、見積りは移行プロジェクトに近い規模になる。
管理領域も同じ性質を持つ。とくに管理領域の通貨タイプ（会社コード通貨・管理領域通貨・グループ通貨のどれを基準に持つか）は、転記が始まってからの変更ができない。ここで「変更できない」と「追加できない」を分けておきたい。S/4HANAには、稼働済みの会社コードや元帳に通貨を追加するツールが用意されている（対象外の通貨があること、過去データの換算が別作業になることといった制約は残り、適用可否はリリースに依存する）。だが最初に選んだ通貨タイプそのものを付け替えることはできない。連結や海外展開が視野にあるなら、追加できるかをリリースごとに確かめる前に、基準にする通貨を最初に決めるほうが早い。
これに対して、原価センタの階層、利益センタのグループ、配賦のサイクル、承認ワークフロー、帳票、アドオンは、稼働後でも作り替えられる。組織変更のたびに動くのはこちら側だ。つまり「変わりやすいもの」と「直せないもの」は、ほとんど重なっていない。設計会議で長時間の議論になりやすいのは変わりやすいほうで、短時間で決まってしまうのが直せないほうである。
会社コードは「組織」ではなく「法人」
よくある設計の失敗が、事業部を会社コードで切ることだ。動機はたいてい「事業別のバランスシートが欲しい」に集約される。だが会社コードは外部報告の器であり、一つ増えるごとに勘定残高、決算、税務申告、監査、そして法人間の内部取引消去の単位が増える。国内で分社する予定がないなら、事業別の損益も資産負債も利益センタで作れる（事業別バランスシートの作り方：ROICを語るなら、事業に資本を負わせる）。
逆の失敗も、同じ数だけ起きる。数年内に分社や事業譲渡が視野に入っているのに、その事業を独立した利益センタで切っていないケースだ。分社の局面で必要になるのは、その事業の損益と主要な資産負債を過去にさかのぼって切り出せることである。利益センタが付いていない過去の伝票は、後から按分で作るしかない。按分で作った数字は、買い手のデューデリジェンスで必ず突かれる。
判断の基準は現在の組織図ではなく、「この単位を法人として切り出す可能性が数年内にあるか」の一点に置く。あるなら、利益センタで先に切っておく。会社コードを足すのは、分社の日程が現実に乗ってからでいい。器は後から足せるが、過去の数字は後から切り出せない。
管理領域を法人ごとに分けると、グループの採算は作れなくなる
管理領域は、原価センタ・利益センタ・内部指図・配賦が動く枠だ。複数の会社コードを一つの管理領域に割り当てれば、法人をまたぐ共通費の配賦や、グループ横断のプロジェクト原価の集計がシステムの中で完結する（クロス会社コード原価会計）。分けてしまうと、これらはすべて管理領域の外——実務的にはExcel——での手作業になる。
一つに寄せるには前提がある。同一の管理領域に割り当てる会社コードは、同じ営業勘定科目表を使い、会計年度バリアントの記帳期間数が揃っていなければならない。しかも数が揃えば足りるわけではなく、期間の区切り——会計年度の開始日と終了日——が対応している必要がある。12月決算も3月決算も記帳期間は12だが、区切りが半年ずれているため同じ管理領域には入らない。ここが数年先の資本政策と直結する。海外子会社を買う計画があるなら、その国の決算月と勘定科目表を、いまの管理領域が受け入れられるか。買ってから気づくと、その会社だけ別の管理領域になり、グループの採算管理が二本立てになる。以後、法人をまたぐ配賦は永久にシステムの外に残る。
利益センタの切り方が、開示の単位を決める
利益センタは管理会計の都合で切るもの、と扱われがちだが、実際には外部開示に直結する。セグメント情報等の開示に関する会計基準（企業会計基準第17号）はマネジメント・アプローチを採っており、開示するセグメントは、経営者が業績評価と資源配分に使っている社内の区分から出発する。もっとも、利益センタは原価責任の単位まで細かく切るのが普通で、報告セグメントとそのまま一致するわけではない。効くのは逆方向だ。セグメントを導出できる属性を持たない単位は、後から報告セグメントに昇格させられない。利益センタの切り方は、開示の粒度を決めているのではなく、開示できる粒度の上限を決めている。
S/4HANAでは仕訳が単一のテーブル（ユニバーサルジャーナル、ACDOCA）に集約され、一行の中に会社コード・利益センタ・セグメント・原価センタが並ぶ。セグメントは利益センタから導出するのが標準の作りで、旧来の事業領域（Business Area）を新規設計で使う理由はほぼない。
だから設計で問うべきは「部門をいくつ作るか」ではない。この単位で損益の責任者が名前で挙がるか、この単位が開示のセグメントに耐えるか、の二つだ。決定権のない単位に損益を立てた瞬間、配賦の押し付け合いが始まり、資料は読まれなくなる（SAPの利益センタ会計で「部門別の儲け」を責任の単位で見る）。
「いまの組織」を写した設計は、いまの組織が変わった日に負債になる
組織構造の設計レビューで確かめる問いは三つでいい。この単位を法人として切り出す日が来るか。その時に過去の数字を切り出せるか。買う予定の会社の決算月と勘定科目表が、この管理領域に入るか。三つとも答えが出ていない状態で会社コードを増やす判断は、将来の選択肢を減らす方向にしか働かない。稼働後に現場が困る大半——帳票が使いにくい、承認が回りくどい、配賦が納得されない——は、時間をかければ直せる。直せないのは、最初の三週間で決めた側だ。設計の時間は、そちらへ寄せる（SAP移行を機にする勘定科目体系（COA）の再設計｜全社で数字を揃える）。
