「S/4HANAへの移行はいつまでに済ませればいいのか」。経営会議でこの問いが出るとき、たいてい話は期限とコストの一点に縮んでいく。だが、保守切れに間に合わせるためだけに数億円を投じるのは、もったいないを通り越して経営判断としてもったいない。移行は、十数年に一度しか開かない「会計と業務の配線をやり直せる窓」だ。ここを延命作業で閉じてしまうか、経営管理を一段上げる投資に変えるか。分かれ目は、移行スコープ（どこまでを作り直すかの線引き）をどこで引くかにある。本稿は、その線引きを具体的に設計する。
まず期限の事実を正確に置く——「2027年」は半分しか正しくない
議論の前提として、保守期限の数字を正確に握っておきたい。ここが曖昧だと、不要な前倒しや、逆に危険な先送りが起きる。
SAPの旧ERP（SAP ERP 6.0 / Business Suite 7）の標準保守は、エンハンスメントパッケージ（機能追加版、EhP）のレベルで終了時期が分かれる。EhP6〜8の環境は2027年末まで標準保守が続く。その後は延長保守を契約すれば、保守料に2％ポイント上乗せで2030年末まで延ばせる（SAP/Rimini Street、E3 Magazine）。一方、移行先のS/4HANAは2040年末まで保守が表明されている。
つまり「2027年がデッドライン」という言い方は半分正しく、半分ミスリードだ。延長保守を使えば2030年末まで猶予はある。ここで強調したいのは逆の話だ。猶予があるからこそ、ギリギリで駆け込むのではなく、設計に時間を使える期間として2027〜2030年を読み替えてほしい。期限を守るための移行と、経営管理を高度化するための移行は、必要なリードタイムが違う。前者は最短一年弱、後者は構想・設計に半年以上を先に積む。延命前提で走り出すと、この設計期間が消える。
なぜ「延命」で終わると損なのか——技術的負債を新システムに引き継ぐ罠
延命とは、要するに「今の業務とアドオン（個別開発したプログラム）をそのままS/4HANAに乗せ替える」ブラウンフィールド型の発想だ。プロジェクト期間が短く、リスクも読みやすいので現場は安心する。だが落とし穴がある。今の会計・原価・管理レポートの作り方に潜む技術的負債を、まるごと新システムに引き継いでしまう点だ（SAP Community）。
たとえば、月次の事業別損益が締めから一週間遅れて出てくる。製品別の限界利益（売上から変動費を引いた、各製品が稼ぐ取り分）を見るのに、会計の数字と管理会計の数字が合わず、毎月手作業で突合している。子会社をまたいだKPIが、各社バラバラの勘定科目をExcelで足し込んで初めて一枚になる。こうした「遅い・合わない・手作業」の構造は、システムが古いからではなく、業務とデータの設計がそうなっているから起きている。延命移行は、この設計をそのまま延命する。新しい箱に古い配管を通すようなものだ。
S/4HANAの本当の価値は、データ構造そのものが刷新された点にある。財務会計・管理会計・在庫評価などが「ユニバーサルジャーナル（ACDOCA）」という単一の明細テーブルに統合され、会計の数字と管理会計の数字が設計上ズレない（reconciled by design）構造になった（SAP Community）。延命だけを目的にすると、この一番おいしい部分を「ただの器の更新」として通り過ぎてしまう。
移行を経営管理高度化に変える——スコープの線引き三本
では、何を設計対象に「足す」のか。CFOzine編集部としては、移行スコープを三つの軸で意図的に広げることを勧めたい。技術更改の範囲に、次の三本を経営アジェンダとして差し込む。
第一に、収益性分析の作り直し。旧来の原価ベースCO-PA（製品・顧客別の儲けを分析する仕組み）を、S/4HANAでは勘定科目ベースのマージン分析へ寄せる。これがユニバーサルジャーナルに統合されるため、製品別・顧客別・事業別の限界利益が、総勘定元帳とリアルタイムで一致した状態で見えるようになる（SAP-PRESS、SAPinsider）。月次の事業別損益が「締めを待たずに、合った状態で」見える——これは経営の意思決定スピードを直接押し上げる。延命では絶対に手に入らない果実だ。ここは設計対象に必ず入れたい。
第二に、全社KPIの勘定科目体系（CoA）統一。移行は、グループ全体の勘定科目・利益センター・原価センターの体系を引き直す数少ない機会だ。各社バラバラの科目を一本化し、見たいKPIの粒度に合わせて設計しておけば、子会社をまたいだ事業別・地域別の損益が、Excel突合なしで一枚になる。逆にここを延命で放置すると、新システムでも連結の手作業は残り続ける。
第三に、意思決定スピードを規定する「締めとレポートの設計」。リアルタイムで明細が積み上がる構造を活かし、期中の途中経過を見える化し、決算の確定を待たずに着地見込みを回す設計に変える。マージン分析の統合により、期末の配賦・精算の回数そのものを減らせる余地がある（CONSILIO）。締めが速くなるのではなく、締めを待つ経営をやめる、という発想の転換だ。
全部作り直す必要はない——「攻める範囲」と「守る範囲」を分ける
ここで誤解を避けたい。経営管理を作り直そう、と言うと「ではグリーンフィールド（全面再構築）か」と身構える人が多い。だが全面再構築は期間もコストも跳ね上がり、現場の混乱も大きい。現実解は、スコープを一律に決めないことだ。
線引きの指針はシンプルにできる。「経営の意思決定に効く領域」——収益性分析、勘定科目体系、全社KPI、締めの設計——は攻める範囲とし、ここは標準機能に寄せて作り直す。アドオンを温存せず、SAPが推す「クリーンコア」（標準からの逸脱を最小化し、保守性を保つ考え方）の思想で設計する（SAP Learning）。一方、競争優位に直結しない定型業務——購買や経費精算の枝葉のアドオンなど——は守る範囲とし、既存資産を活かして堅実に移す。この「攻めと守りの二色塗り」が、ブラウンフィールドとグリーンフィールドの中間（ブルーフィールド／選択的移行）の実体だ（Kellton）。
線を引く主体は、情シスでもベンダーでもなく、CFOであるべきだ。「どのKPIを、どの粒度で、どのスピードで見たいか」を決められるのは経営側だけだからだ。ベンダーに丸投げすれば、線は技術的に引きやすい場所——つまり延命寄り——に落ちる。
最後に、現場の体温で一つだけ言い切っておきたい。スコープ表に、収益性分析・勘定科目統一・締めの設計の三行が「設計対象」として載っているか——それを確認するところから、この投資は経営に効く投資へ変わる。
- 収益性分析の作り直しが「設計対象」として載っているか
- 勘定科目体系（CoA）の統一が「設計対象」として載っているか
- 締めとレポートの設計が「設計対象」として載っているか