SAP導入の進め方 ─ 工程表を「発注側が決めること」の一覧として読み直す

SAP導入の進め方を調べると、構想、要件定義、設定、テスト、移行、稼働という工程表が見つかります。導入を請ける会社が、自分たちの作業の順に並べた表です。発注側がこの表を見ても、自社がいつ何をすればよいのかは読み取りにくい。

筆者は、同じ工程表を「発注側が決めることの一覧」として読み直すことを勧めています。どの工程にも、発注側にしか決められないことがあります。それが決まらないと、導入を請ける会社の作業は止まります。工程表は、作業の順番である前に、判断の締め切りの一覧です。

SAP導入とは、業務の型を決め直す仕事

SAPは、販売、購買、生産、在庫、会計といった会社の基幹業務を、一つの仕組みでつなぐERPの製品です。SAP自身はERPを、コアビジネスプロセスを合理化し、活動を一元的に把握できるようにするソフトウェアシステムだと説明しています。

実際に時間がかかるのは、ソフトウェアを入れる作業より、受注から入金まで、発注から支払いまで、月次決算の締め方といった業務の型を決め直すところだと筆者は考えています。SAPの導入方法論であるSAP Activateも、事前に設定された業務プロセスに自社の業務が合うかを分析し、合わない部分を特定する工程を置いています。システムの導入であると同時に、業務の決め直しです。

SAP導入のメリットと効果は、標準に合わせた範囲で決まる

よく挙がるメリットは、情報の一元管理から始まる

SAPは、ERP導入の最大のメリットとして、会社の情報を一つのデータベースで一元管理できることを挙げています。部門ごとに持っていた情報が一か所に集まり、同じデータを見て判断できるようになります。あわせて挙げているのは次の4つです。

• 業務の効率と生産性の向上
• 手作業の自動化によるコストの削減
• 各国の法規制への対応と、内部統制の強化
• 会社全体の状況を見えるようにする、経営の可視化

効果が出にくい原因の一つは、いまのやり方をそのまま写そうとすること

メリットは、導入すれば自動で出るものではありません。ジャパンSAPユーザーグループ（JSUG）とSAPジャパンは、2019年3月までの議論をまとめた提言で、1990年代後半からのERP導入を振り返り、本来の目的だったリアルタイム経営やデータを活用した経営を実現している企業は必ずしも多くない、とまとめています。

原因の一つは、いまの業務をそのまま新しいシステムに写そうとすることです。SAPジャパンの年次イベントでは、登壇した導入会社のコンサルタントが、発注側から届くRFP（提案依頼書）は現行システムを前提にした型が多いと指摘しました。現行に引っ張られると要件がまとまりにくく、追加開発（アドオン）が増え、標準化が進まないという指摘です。

一元管理も可視化も、全社が同じ業務の型とデータの定義で動いて、はじめて得られます。部門ごとの例外を追加開発で残せば、その分だけデータはそろわなくなります。筆者は、SAP導入の効果は、標準の業務プロセスに合わせた範囲で決まると考えています。

SAP導入の流れ：6つの工程

SAP導入の流れは、会社や導入方法論によって呼び名が違います。ここでは発注側の目線で、6つの工程に分けます。SAP Activateは、導入の手順をDiscoverからRunまでの6つのフェーズにまとめています。両者の対応は次のとおりです。

表　6つの工程とSAP Activateのフェーズ。フェーズの説明は出典2による。工程との対応づけは筆者の整理。

構想：目的と範囲を決める

何のために導入するのか、どの会社のどの業務を対象にするのかを決めます。経営会議で決める4つのことは、SAP導入の構想策定の記事にまとめました。いまSAP ERPを使っている会社は、新しく入れ直すのか、いまのシステムを変換するのかという移行の方式もここで決めます。方式の選び方はSAP移行の方式の記事で扱っています。

ベンダー選定：前提をそろえて提案を受ける

RFPを書き、提案を受け、導入を請ける会社を選びます。RFPに書く項目はSAP導入のRFPの記事で扱っています。依頼先の型と、社内で先に決めておくことは、SAPコンサル会社の選び方の記事とSAPベンダーの選び方の記事にまとめました。

要件定義：標準と比べて、差の扱いを決める

SAPの標準の業務プロセスを実際の画面で確かめ、自社の業務との差を洗い出します。差が出たら、業務を標準に寄せるか、追加開発するかを一件ずつ決めます。SAPの導入手順の中で、発注側の判断がいちばん多い工程だと筆者は見ています。

設定とテスト：決めた型をSAPに入れて確かめる

要件定義で決めた内容をSAPに設定し、追加開発と周辺システムとの連携をつくります。テストは、機能ごとの確認から、業務の流れを通した確認、本番と同じ量のデータでの確認へ進みます。

データ移行と本番切替：何を移すかと、切り替える条件を決める

取引先や品目のマスタ、残高、明細を旧システムから移します。切替の前にリハーサルを行い、本番に切り替えてよいかを判定します。

定着：使い方を固め、改善を続ける

稼働のあとも、問い合わせへの対応、操作の教育、改修要望の整理が続きます。運用の体制は、稼働の前に決めておきます。

各工程で発注側が決めることと、決まらないと止まる作業

工程表を、発注側の判断の一覧として読み直します。IPA（情報処理推進機構）の「超上流から攻めるIT化の原理原則17ヶ条」は、「要件定義は発注者の責任である」としています。「要件確定の先送りは厳禁である」「ステークホルダ（利害関係者）間の合意を得ないまま、次工程に入らない」という趣旨の原則も並びます。判断を先に送ると、その先の作業が止まるか、決まらないまま進んで後でやり直しになります。

どの工程にも発注側が決めることがあり、決まらないと次の作業が止まる

工程 01構想目的と範囲を固め、経営の承認を得る発注側が決めること導入の目的、対象範囲、移行の方式、移行データと切替の方針、予算と期間の置き方決まらないと止まる作業RFPが書けない

工程 02ベンダー選定提案を受け、依頼先を選ぶ発注側が決めること評価の基準と、依頼先決まらないと止まる作業提案を比べられず、契約に進めない

工程 03要件定義標準と自社の業務の差を洗い出す発注側が決めること業務の型と、追加開発を認めるかどうか決まらないと止まる作業設定と開発に着手できない

工程 04設定とテスト設定し、開発し、テストで確かめる発注側が決めることテストの合格基準決まらないと止まる作業合否を判定できず、次のテストに進めない

工程 05データ移行と本番切替データを移し、切り替える発注側が決めること移すデータの確定と、切り替えてよいかの判定基準決まらないと止まる作業移行の手順を組めず、切替日を決められない

工程 06定着使い方を固め、改善を続ける発注側が決めること改善の優先順位と、保守の分担決まらないと止まる作業改修要望がたまり、手をつけられない

「決まらないと止まる作業」は筆者の整理。工期の悪化に影響している工程として要件定義を挙げた回答は69.0%で、最も多かった（JUAS「企業IT動向調査報告書2026」）。

読み方工程表の日付を、作業の予定としてでなく、発注側の判断の締め切りとして読む。締め切りごとに、決める人の名前を書き込む。

工程表は、判断の締め切りの一覧として読める。判断が遅れると、その先の作業が止まるか、決まらないまま進むことになる。

決める人まで含めて一覧にすると、次のようになります。

表　工程ごとの「決めること・決める人・決まらないと止まる作業」。決める人の置き方は会社によって違う。ここに示したのは筆者の整理。

筆者は、判断がいちばん集まるのは要件定義だと見ています。日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2026」は、システム開発の品質・予算・工期の悪化にどの工程が影響しているかを、複数回答で尋ねています。工期では、要件定義を挙げた回答が69.0%で最も多く、設計・実装・テストの51.7%を上回りました。予算でも要件定義が57.4%で最多です。品質では、設計・実装・テストが74.1%で最多でした。SAPに限った調査ではありませんが、要件定義が工期と予算に響きやすいことがうかがえます。

SAP導入の期間は何で決まるか

SAP導入の期間に、目安として示せる数字はないと筆者は考えています。規模ごとの期間は、公表された数字が見当たらないので、この記事では「何か月」とは書きません。書けるのは、期間を動かす要因のほうです。

対象の会社とモジュールが、プロジェクトの大きさを決める

対象の会社の数、国の数、導入するモジュール（会計、販売、購買、生産などの機能のまとまり）の数で、要件定義とテストの量が決まります。旭化成は、生産管理、在庫管理、販売・物流、会計、購買を対象に、SAP S/4HANAを一度に導入しました。SAPジャパンの紹介記事によると、プロジェクトのキックオフは2020年4月、本番稼働は2023年4月です。構想の段階を含めると約5年で、約80名のプロジェクトメンバーと約1,200名の社内関係者が関わったと紹介されています。一社の例で、目安にはなりません。それでも、対象を広く取った導入が年単位の仕事になることは読み取れます。

規模が大きいほど、予定どおりに終わりにくくなります。JUASの同じ調査では、500人月以上のプロジェクトの47.8%で、工期が予定より遅れていました。10人月未満では9.6%です。

追加開発と移行データが、後半の工程を長くする

追加開発は、つくる期間だけでなく、テストの期間も延ばします。旭化成は、約20年の運用で2,400本あったアドオンを、この導入で1,100本まで減らしました。プロジェクトの管理を担った同社の担当者は、開発の量を抑えなければ当初の予算と納期を守れないことは明らかだった、と振り返っています。

移行データも同じです。残高だけを移すのか、過去の明細まで移すのかで、移す作業と、移したあとの突き合わせの量が変わります。先のイベントでは、マスタデータの精度の問題で納期が遅れることがしばしばある、という指摘もありました。

表　期間を動かす要因。効き方と決める工程は筆者の整理。

SAP導入プロジェクトの体制：社内に置く役割と、外に頼む役割

決める仕事は、社内に残ります。外に頼めるのは、手を動かす仕事と助言です。先のイベントでは、別の登壇者が、失敗の要因に体制の準備不足を挙げました。現場の部門は日々の業務を抱えていて、プロジェクトに割く余力がないことがある、という指摘です。IPAの原理原則も、発注者に、業務部門とIT部門が二人三脚で要件定義を進めるよう求めています。

決める役割は社内に置く。外に頼むのは、手を動かす役割と、判断の材料づくり

社内に置く役割決める仕事

プロジェクトの責任者（経営）

役目

目的と範囲、予算を決める。部門の間で割れた判断を引き取る

PM（プロジェクトマネージャー）

役目

計画と進み具合を管理し、導入を請ける会社を管理する

業務ごとの責任者

役目

業務の型、テストの合否、移すデータを決める。割ける時間を先に確保する

情報システム部門

役目

周辺システムとの連携、基盤、稼働後の運用を取りまとめる

判断と材料が行き来する

外に頼む役割手を動かす仕事と助言

領域ごとのコンサルタント

役目

標準の業務プロセスを示し、要件定義、設定、テストを進める

開発と基盤の担当

役目

追加開発、周辺システムとの連携、データ移行の道具、基盤をつくる

PMOの支援

役目

計画、課題、リスクを整理し、判断が要る論点を経営に上げる準備をする

外に出せないもの

中身

業務の型を決めること、追加開発を認めること、切り替えてよいと判断すること

つなぐ場ステアリングコミッティで課題を経営陣と共有し、その判断を受けてPMOが要員を調整する（出典4で示された進め方）。

体制図は、作業の分担だけでなく、誰が決めるかの分担として書く。決める役割を外に出すと、判断の締め切りを守る人がいなくなる。

外に頼む役割を、どの型の会社に任せるかは、SAPコンサル会社の選び方の記事で扱いました。

つまずきやすい3つの場面

公表された事例を読むと、問題が表に出るのは本番切替やテストの段階です。原因をたどると、もっと前の工程で置く前提に行き着きます。

• 本番で処理する量の前提を置いていない。想定を超える量が流れ込み、出荷や納品が滞る
• 周辺システムとのつなぎ目と、切替の時期を早めに決めていない。切替の直後に連休明けや繁忙期の注文が重なり、処理が追いつかなくなる
• 仕様を固めたあとの変更を止める人がいない。変更が続いて、計画が崩れる

どれも、構想と要件定義で発注側が決めることです。事例と判決から逆算した5つの判断は、SAP導入の失敗事例の記事にまとめています。

費用の入口：見積もりは、工程が進むごとに確かになる

費用は、ライセンス、導入作業、基盤、運用保守の4つと、社内の担当者の時間でできています。要件定義の前に出てくる見積額は、まだ確定した金額ではありません。IPAのモデル契約は、工程が進むにつれて見積もりの精度を上げ、工程ごとに見積もり直す考え方を採っています。見積もりを取る前にそろえる12項目と、金額の比べ方は、SAP導入の費用の記事で扱っています。

Never Redは、構想の整理とベンダー選定の事務局から、会計領域の設計とSAPの設定、稼働後の定着までを支援しています。工程ごとの関わり方はSAP導入支援をご覧ください。当社が入った工程を事例ごとに並べた一覧は、SAP導入事例にあります。

よくある質問

SAP導入は、何から始めればよいですか。

導入の目的を、測れる言葉で書くところからです。月次決算を何営業日で締めるのか、受注から出荷までを何日で回すのか、損益をどの単位で見るのか、といった形にします。目的と対象範囲が決まると、RFPに書く前提をそろえやすくなります。

SAP導入の期間は、どれくらいかかりますか。

規模ごとの一律の目安は示せません。期間は、対象の会社とモジュールの数、追加開発の本数、移行データの範囲、社内の担当者が割ける時間で動きます。自社の期間は、この4つを決めたうえで、提案を受けて見積もります。

SAP ERPの導入と、SAP S/4HANAの導入は違いますか。

「SAP ERPの導入」は、SAPのERP製品を入れるという広い意味で使われることがあります。製品としてのSAP ERP 6.0は一つ前の世代で、メインストリーム保守は、拡張パッケージ（EhP）6〜8でも2027年末までです。これから導入を検討するなら、対象はSAP S/4HANAになると筆者は考えています。

SAP HANAの導入とは、何を指しますか。

SAP HANAは、データをメモリーに保存するデータベースの製品名です。SAP S/4HANAを新しく導入する場合、データベースはSAP HANAを使います。「SAP HANAの導入」という言葉は、SAP S/4HANAの導入を指して使われることもあります。

導入は、情報システム部門と業務部門のどちらが主導しますか。

どちらか一方では進みません。業務の型と追加開発の要否は業務部門が決め、周辺システムとの連携や基盤は情報システム部門が取りまとめます。部門の間で割れた判断を引き取る経営の責任者を、最初に決めておきます。

SAP導入の進め方や、工程ごとの決めごとについてのご相談は、お問い合わせからお寄せください。

出典

1. ERPの説明（コアビジネスプロセスを合理化し、活動を一元的に把握できるようにするソフトウェアシステム）と、ERP導入のメリット（情報の一元管理、業務効率と生産性の向上、コストの削減、コンプライアンスの強化、経営の可視化）：SAP Japan「ERPとは？」
2. SAP Activateの6つのフェーズ（Discover、Prepare、Explore、Realize、Deploy、Run）と各フェーズの説明、事前に設定されたプロセスの標準適合分析：SAP Japan「SAP Activate」
3. 原理原則［3］（要件確定の先送りは厳禁である）、［4］「ステークホルダ（利害関係者）間の合意を得ないまま、次工程に入らない」、［9］「要件定義は発注者の責任である」と行動規範「業務部門とIT部門が、二人三脚で要件定義を進める」：独立行政法人情報処理推進機構（IPA）「超上流から攻めるIT化の原理原則17ヶ条」
4. 現行システムを前提にしたRFPが多いという指摘、体制の準備不足と現場部門の余力、ステアリングコミッティとPMO、マスタデータの精度による納期の遅れ：SAPジャパン「エキスパートコンサルが明かす SAP ERP 導入の失敗と成功の法則」（SAP NOWレポート、2024年10月7日）
5. システム開発のQCD悪化に影響を与えている工程（図表7-1-9）と、プロジェクト規模別の工期の遵守状況（図表7-1-4）：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査報告書2026」（2026年4月）
6. 1990年代後半からのERP導入の振り返り（本来の目的だったリアルタイム経営、データを活用した経営を実現している企業は必ずしも多くない）：JSUG「日本企業のためのERP導入の羅針盤～ニッポンのERPを再定義する～」
7. 旭化成のSAP S/4HANA導入（対象の業務領域、2020年4月のキックオフと2023年4月の本番稼働、構想段階を含めて約5年、約80名のプロジェクトメンバーと約1,200名の社内関係者、アドオンを2,400本から1,100本に削減）：SAPジャパン「旭化成が SAP S/4HANA のビッグバン導入で目指す新たな成長基盤の再構築」（2023年11月22日）
8. 多段階契約と再見積もりの考え方：独立行政法人情報処理推進機構「システム開発の健全化に向けて ～『情報システム・モデル取引・契約書』から読み解く～」（2025年4月24日講演資料）
9. SAP HANAの説明（データをメモリーに保存するデータベース）：SAP Japan「SAP HANAとは何か？」。SAP S/4HANAの新規導入はSAP HANAデータベース上で動かす必要があること：SAP Help Portal「Getting Started With SAP S/4HANA 2025」（PDF）
10. SAP Business Suite 7のコアアプリケーション（最新3つのEnhancement Package）のメインストリーム保守が2027年末までであること：SAPジャパン サポートニュース 2024年7月（JSUG掲載）（SAP ERP 6.0 EhP6〜8のメインストリームメンテナンスは2027年末までの予定）、SAP公式「Innovation Commitment for SAP S/4HANA until 2040 – Clarity and Choice on SAP Business Suite 7」