ERPの選定会議では、どこかで必ず同じ問いが出る。「うちの規模でSAPは大げさではないか」。議論は売上高と従業員数の話になり、同業他社の事例を並べ、最後は見積金額の差で決まる。実装側から見ると、この決め方はほぼ確実に外す。ERPの選定を分けるのは会社の規模ではなく、その会社が抱えている複雑さが何本あるかだ。 売上五百億でも法人が一つ・通貨が一つ・取引の型が一つなら、SAPの機能の大半は使われない。売上八十億でも国内外に法人が五つあり、連結を自前で締め、受注生産と量産と保守契約が同じ会社の中で走っているなら、中堅向けの製品では設計の途中で壁に当たる。

POINT
複雑さは六つの変数で数えられる。法人（会社コード）の数、原価や在庫を分けて見たい拠点の数、記帳と評価に使う通貨の数、連結を自社で締めるかどうか、社内に同居している取引の型の数、そして稼働後に自社で設定を触れる人数。この六つを現在と三年後の二時点で書き出すと、判断はほぼ決まる。重要なのは合計本数ではなく、そのうち後から足せない変数がいくつあるかである。法人・通貨・組織の階層は、稼働後に足そうとすると過去データの持ち方から作り直しになる。一方、取引の型や帳票は後からでも追加できるので、型が多いことだけを理由にSAPを選ぶと、使われない機能の保守料を払い続けることになる。前者が二つ以上動くならSAPを選ぶ理由が立ち、前者が一つも動かず後者だけが多い会社では、SAPは過剰になりやすい。そして選定の工程は、製品の機能比較からでなく、自社の型を棚卸しする作業から始める。ここを飛ばした選定は、必ず稼働の一年後に「思っていたのと違う」という形で返ってくる。

SAPが過剰になるかは、売上高でなく複雑さの本数で決まる

規模を基準にするやり方が広く使われているのは、単に数えやすいからだ。売上高も従業員数も拠点数も、決算書と人事の資料からすぐ出る。しかしERPの導入工数を決めているのは、その数字ではない。

導入プロジェクトで工数が膨らむのは、設計の分岐が増えるところだ。会社コードが二つになれば、勘定科目の運用ルールを二社で揃えるかどうかを決めなければならず、決算日程も二本になり、内部取引の消去という論点が生まれる。通貨が二つになれば、記帳通貨と評価通貨の関係、レートの取得元、換算差額の扱いをすべて設計する。逆に、売上が大きくても伝票の型が一種類なら、件数が増えるだけで分岐は増えない。件数はサーバーとバッチ設計の問題であって、設計工数の問題ではない。

だから「同じ売上規模の会社が入れているから」は判断材料にならない。実装側が最初に受け取りたいのは業界と売上の話でなく、その会社が何種類の型を同時に回しているかという一覧である（ERPとは何か｜会計システムとの違いと、経理・財務が知るべき選び方）。

その一覧が、複雑さの六変数である。次の六つを、現在と三年後の二時点で埋める。三年後は、稼働してから最初の大きな見直しが来るまでの期間だと考えてよい。

変数何を数えるか後から足せるかSAPが有利に傾く目安
法人会計単位として独立している法人の数足せるが影響大三つ以上、または海外法人がある
拠点・部門原価や採算を分けて見たい単位の数足せる階層を持たせたい（事業／地域／工場の多段）
通貨記帳・評価・報告に使う通貨の数ほぼ足せない二つ以上、または外貨建の残高評価が要る
連結自社で連結を締めるか、外に出すか足せるが体制が変わる自社で締める、または四半期開示がある
取引の型量産・個別受注・プロジェクト・保守契約など同居する型の数足せる四つ以上が同居し、原価の作り方が型ごとに違う
内製できる人数稼働後に設定・マスタ・帳票を自社で触れる人数増やせるが時間が要る情シスと経理で三人以上置ける

三列目が判断の中心だ。実装の現場で本当に困るのは、機能が足りないことではなく、後から足せないものを足そうとすることである。通貨の設定は典型で、単一通貨の前提で組んだ会計に後から二つ目の通貨を入れると、過去の残高をどう遡って評価するかという問題が必ず出る（SAPの通貨設定（複数通貨・レートタイプ）｜あとから足せない通貨の決め方）。組織構造も同じで、会社コードや利益センタの階層は稼働後の変更が最も重い領域になる（SAPの組織構造設計（会社コード・管理領域・利益センタ）｜アドオンで直せない唯一の領域）。

逆に「取引の型」と帳票の本数は後から追加できるので、型が多いこと自体はSAPを選ぶ理由として弱い。型が多くて、かつそれぞれの原価の作り方が違い、しかも同じ管理会計の器で並べて見たいときに初めて、標準の懐の深さが効いてくる。

「後から足せないもの」がいくつ動くかで分岐する

六つを埋めたら、判定はこう置く。三年後までに動く変数のうち、後から足せない側（法人・通貨・組織の階層・連結の自社実施）が二つ以上あればSAP側に寄せる。一つなら、その一つを中堅向け製品でどう受けるかをベンダーに具体的に説明させる。ゼロなら、SAPは過剰になる可能性が高い。

同じ「複雑さ」でも、後から足せるかどうかで意味がまったく違う。
後から足せない構造の複雑さ
設計の後戻り ●●●
稼働後の変更コスト ●●●
標準機能で吸収 ●●●
法人の増減、通貨の追加、組織階層の多段化、連結の自社実施。過去データの持ち方まで遡って作り直しになるため、稼働後の変更は事実上プロジェクトの再実施に近い。ここが二つ以上動くなら、最初から受けられる器を選ぶ。
後から足せる運用の複雑さ
設計の後戻り ●○○
稼働後の変更コスト ●○○
標準機能で吸収 ●●○
取引の型の追加、帳票の追加、承認ルートの変更、部門の組み替え。稼働後でも追加で作れる領域で、これが多いことだけを理由にSAPを選ぶと、使われない機能の保守料を払い続けることになる。
足せない変数が二つ以上動くならSAP側、ゼロなら中堅向けで足りる。合計本数で決めない。

内製人数の変数だけは、他の五つと性質が違う。これは会社の複雑さではなく、会社の体力の話だからだ。SAPを選ぶということは、設定を触れる人を社内に持つか、触れるベンダーを継続して押さえるかのどちらかを選ぶことでもある。稼働後に自社で触れる人がゼロのまま入れると、勘定科目を一つ増やすたびにベンダーへの依頼票を書くことになり、その依頼票の積み上がりが数年後の運用費として表に出てくる（SAP移行後の経理運用を内製で回す｜ベンダー依存を減らす体制づくり）。

選定はこの順で回す。製品比較から入ると必ず外す

選定を製品の機能比較表から始めると、比較表の行はベンダーが用意したものになる。用意された行に丸を付ける作業は、自社の複雑さを一度も数えないまま進むという意味で、選定として成立していない。順番はこうなる。

ERP選定は、製品を並べる前に自社の型を数える四工程で決まる。
STEP 1
現行の型を棚卸しする
伝票の型・原価の作り方・帳票の出口を実物で数える。件数でなく種類を数えるのがこの工程の目的
→
STEP 2
三年後の増分を確定させる
法人の新設、海外展開、連結の自社実施、事業の追加を経営計画から拾い、六変数の三年後の値を確定する
→
STEP 3
標準への当て込みを実データでやる
デモでなく自社の実物の取引を持ち込み、標準機能のどこに載るか、載らない型がいくつ残るかを数える
→
STEP 4
稼働後の運用体制を先に見積もる
設定を触る人、マスタを守る人、帳票を作る人を名前で置く。置けないならその分は外部費用として年額に積む
土台土台＝比較の行を自社が作ること。ベンダーが用意した比較表の行に丸を付ける作業は、選定ではなく承認である。
この四工程を終えてから初めて、製品と見積を並べる意味が出る。

三工程目の「実データでの当て込み」が、選定で最も省略され、最も高くつく工程だ。デモ環境の取引はきれいに通るように作られている。自社の実物、たとえば締めた後に届く請求書、部分検収、値引きとリベートが後から乗る取引、有償支給と無償支給が混じる委託加工を持ち込むと、標準で載る型と載らない型がはっきり分かれる。載らない型が何本残るかが、そのまま追加開発の見積の下敷きになる。この作業をどこまでやり切るかが、稼働後のアドオン量を決める（SAPアドオン（追加開発）をどこまで作るか｜Fit-to-Standardの判断基準）。四工程目を選定の段階でやるのも同じ理由だ。運用体制を稼働直前に考え始めると、その時点で残る選択肢は「ベンダーに継続してもらう」しかない。

導入時のどの判断が、何年後にどの費目で跳ね返るか

選定の判断は、その場では機能の話に見える。しかし数年後には全部、費目として損益計算書に現れる。実装側から見ると、対応はかなりはっきりしている。

導入時の判断跳ね返る費目表に出てくる時期
標準に載らない型をアドオンで受けた保守料と、更新のたびの回帰テスト工数二年目以降、毎年
組織構造を現状の組織図どおりに刻んだ組織改編のたびの再設定費用、過去比較の作り直し最初の組織改編時
通貨を一つの前提で組んだ通貨追加時のデータ再構築、期中の手作業評価海外取引が立ち上がった期
帳票要件を絞らずに全部作った使われない帳票の維持費と、改修のたびの影響調査三年目以降、じわじわ
内製の担当を置かなかった依頼票ベースの運用委託費、軽微な変更の外注化稼働直後から恒常的に
旧システムを残してデータを移さなかった旧環境の維持費と、参照のための二重運用稼働翌年から

どれも稼働判定の時点では見えない。カットオーバーを乗り切った時点では、すべて「動いている」。差が出るのは二年目からで、しかも一度に来るのではなく、保守料・改修費・運用委託費という別々の費目に分かれて少しずつ現れる。だから社内で「ERPが高い」という話になったとき、原因を探しても特定の一箇所には辿り着かない。原因は導入時の判断に分散しているからだ。

中堅向け製品を選ぶなら、出口を設計してから選ぶ

六変数を数えた結果、SAPが過剰だと判断したなら、それは正しい選択でありうる。ただし実装側から一つだけ条件を付けたい。出口を設計してから選ぶことである。

出口とは、複雑さが増えたときに乗り換えられる状態を指す。具体的には三つだ。第一に、マスタと過去伝票を標準的な形式でまとめて取り出せること。契約時にデータの持ち出し方法と、その作業に追加費用がかかるかどうかを文書で確認しておく。第二に、勘定科目体系と組織コードの採番ルールを、製品固有の制約に寄せすぎないこと。製品が要求する形式と、自社が本来使いたい体系が違うなら、その差分を一覧で持っておく。乗り換えのときに読み替え表を作る作業がそのまま省ける。第三に、連結の受け皿をERPの外に持てるようにしておくこと。単体の会計だけならどの製品でも回るが、連結を自社で締め始めた瞬間に、子会社からの収集と消去の工程が新しく立ち上がる。

この三つを契約前に詰めておけば、複雑さが増えた三年後に選択肢が残る。詰めずに入れると、乗り換えの検討自体がデータ移行の見積待ちで止まる（SAP ERP 2027年問題とは｜いつ何を決めるべきか、移行の全体像）。

現場では
ある製造業では、老朽化した基幹システムの入替えにあたり、当初はSAPと国産の中堅向け製品を金額で比較していた。差は大きく、社内は中堅向けに傾いていた。選定チームがやり直したのは、比較表を一度捨てて、自社の伝票の型を数える作業だった。数えると、量産品、個別受注、装置の据付工事、保守契約、有償支給を伴う委託加工の五つが同じ会社の中で走っており、原価の作り方が型ごとに違っていた。加えて、三年以内に海外に販売子会社を作る計画が経営計画に載っていた。ここで六変数の三年後の値を埋めると、通貨が二つになり、法人が三つになり、連結を自社で締める前提になることが分かった。後から足せない側が三つ動く。金額差は残ったが、選定の結論は入れ替わった。決め手になったのは製品の機能一覧ではなく、自社の型を数え直した二週間の作業だった。加えてこの会社は、稼働後に設定を触る担当を経理と情シスから一名ずつ名前で確保し、その人件費を比較表に載せた。総額の差はさらに縮んだ。

作り切る順番は、数えるところから始まる

ERPの選定を規模で決めると、決めた理由は数年後に誰も覚えていない。残るのは、毎年の保守料と、標準に載らなかった型を受けたアドオンと、依頼票を書き続ける運用だけだ。順番はこうである。まず自社の型を数える。次に三年後の六変数を確定する。それから実データを標準に当て込み、載らない型を数える。最後に、稼働後に設定を触る人を名前で置く。ここまで終えてから製品と見積を並べる。この四工程をやり切った会社は、SAPを選んでも中堅向けを選んでも、選んだ理由を三年後に説明できる。飛ばした選定は、どちらを選んでも同じ場所で詰まる。

まとめ
ERP選定で「うちの規模でSAPは大げさか」という問いに売上高や従業員数で答えると外す。導入工数を決めているのは件数ではなく設計の分岐の数であり、見るべきは規模でなく複雑さの本数だからだ。複雑さは六つの変数で数える。法人の数、原価や採算を分けて見たい拠点・部門の数、記帳と評価に使う通貨の数、連結を自社で締めるか、社内に同居する取引の型の数、稼働後に自社で設定を触れる人数。これを現在と三年後の二時点で埋める。判定に効くのは合計本数ではなく、そのうち後から足せない側がいくつ動くかである。法人・通貨・組織階層・連結の自社実施は、稼働後に足そうとすると過去データの持ち方から作り直しになる。ここが二つ以上動くならSAP側に寄せ、ゼロなら過剰になりやすい。選定の工程は製品比較から始めない。現行の型を棚卸しし、三年後の増分を経営計画から確定させ、デモでなく自社の実データを標準に当て込んで載らない型を数え、稼働後に設定を触る人を名前で置く。この四工程を終えてから製品と見積を並べる。特に実データでの当て込みは省略されやすく、載らない型の本数が追加開発の見積になる。導入時の判断は数年後に費目として現れる。アドオンは保守料と回帰テスト工数に、組織構造の刻みすぎは改編のたびの再設定費に、内製担当を置かなかったことは運用委託費に返る。中堅向け製品を選ぶ場合は、データの持ち出し方法、採番ルールの自社性、連結の受け皿という三つの出口を契約前に詰めておく。

関連記事