SaaS ERPをFTSで導入するためのチェンジマネジメント 総論賛成から各論反対／意識改革の分岐点 その5：CRP（Conference Room Pilot）と運用モデル評価《後編》
CRPは、ERP導入プロジェクトにおいて“変革の中核”を担うステップです。前編では、CRPの意義と5つの目的、そしてCRPを進める上で欠かせないチェンジマネジメントの視点について紹介しました。特に、ユースケースやクイックウィンによって、プロジェクトメンバーが標準機能に自信を持ち、「変われるかもしれない」という感覚を得ていく過程を描きました。
では、こうした感覚が、どのように「自分たちで使いこなせる」という実感へと変化していくのか。後編では、CRPを支える三つのサイクル（慣れる／検証する／仕上げる）に沿って、プロジェクトメンバーがどのように主体性を獲得していくのかを描いていきます。さらに、CRPで得た成果を基に、ユーザー自身が主導して行う「運用モデル評価」に至るまでの道のりを追いながら、変革を定着させるための最後のステップを明らかにします。
CRPの三つのサイクルの役割
この変化を支える仕組みとして、CRPは基本的に3つのサイクルで構成されます。そして、一つのサイクルごとに、製造業であれば、需要予測から生産計画、購買、製造、受注、出荷、入金、支払、財務レポートといった一連の業務領域を通しで実行します。各サイクルを重ねることで、ERPに組み込まれたエンド・ツー・エンドの標準業務が、自社の実務の中でどのように機能し得るのかを段階的に理解し、業務全体としてどう組み上がっていくかを明確にしていきます。
CRPサイクル1でERPに慣れる
CRPの第1サイクルでは、ERPトレーニングで得た知識をもとに、プロジェクトメンバー自身が標準業務プロセスを実機上で操作しながら、“慣れること”を最優先に取り組みます。画面構成や操作方法の正確さといった細部よりも、「業務全体の流れとしてどう機能するのか」「標準機能でどこまで実現できるのか」といった本質的な理解を得ることが、このサイクルの目的です。
このとき、検証対象とする要求は、MoSCoWマトリクスにおける「要求レベル」と「優先度」の両軸から制限をかけます。要求レベルは「業務要求」に限定し、優先度はMustまたはShouldに分類されたもののみを対象とします。
Mustは、プロジェクトの目的達成や法令遵守、顧客からの強い要望、制約条件に関わるもの。 Shouldは、取引先など対外的な関係性に起因する要請です。
一方で、Could（社内完結的な要望）に分類される要求や、「機能要求」レベルの検討については、サイクル1では取り扱いません。なぜなら、この段階でのプロジェクトメンバーのERP習熟度は「L（Learned：1人で作業できるが、指導を受ける場合がある）」のレベルにあり、ERPの構造や業務全体とのつながりを十分に理解しきれていないからです。
そのため、たとえMustやShouldの業務要求に対して課題を感じたとしても、すぐに「拡張機能開発要求」として起票することはしません。
その代わりに、「標準機能の工夫や設定変更、業務側の運用設計の見直しによって対応できないか？」という視点から、現場で柔軟に対応策を模索する姿勢が重視されます。これは、Fit to Standard（FTS）型導入において、「まず標準でやりきることを考える」という原則に沿った判断です。
サイクル1は、現場が新業務に“慣れ”、標準業務プロセスの構造を理解し、「ERPに業務を合わせていく」感覚を体に染み込ませていくステップです。そして、そうした理解が深まった次のCRPサイクル2で、はじめて機能要求レベルの検討や、拡張機能開発の是非を構造的に議論していくことになります。
サイクル1と2の間に、立ち止まって整理する
CRPサイクル1で明らかになったビジネスプロセス上の課題は、次のサイクル（サイクル2）に進む前に、しっかりと方針を定めておく必要があります。サイクル2ではより精緻な実機検証が求められるため、ここで課題を曖昧にしたまま進んでしまうと、検証の焦点がぼやけ、成果が得にくくなってしまいます。
そのため、サイクル1とサイクル2の間には、1ヶ月程度の課題検討期間を設けるのが理想的です。この期間で、サイクル1で見つかった論点に対する対応方針を整理し、CRPサイクル2で何をどう検証するのかを明確にしておきます。
また、このタイミングでは、ユーザー企業とベンダーの各チームメンバー間でCRP内容のすり合わせを行うことも非常に重要です。プロセスや設定、業務シナリオやMoSCoWに対する理解のズレを解消し、次のサイクルに向けてチーム全体で共通認識を持つのです。
サイクル1完了で、As-Is要求は取り下げられていく
サイクル1を終える頃には、プロジェクトメンバーが、プロジェクト開始前にRFPで起票したAs-Is要求を、実態に基づいて次々と取り下げていきます。
こうしたAs-Is要求の多くは、プロジェクト初期に十分なチェンジマネジメントが行われておらず、ERPに対する習熟不足や旧システムへの執着、不安の裏返しとして要求化されたものでした。
しかし、トレーニングとCRPサイクル1を経て、プロジェクトメンバーは標準機能の構造や制約、現場業務との接点を体感しながら理解を深めていきます。そして、ここまでの「その1」〜「その5」にわたるチェンジマネジメントの累積によって、メンバーの視座が大きく変化していきます。
「これなら標準でやれそうだ」「むしろ、今までのやり方を変えた方がよいかもしれない」そんな認識への移行が、As-Is要求の取り下げという形で現れ始めるのです。
CRPサイクル2で、To-Be業務と機能要求を本格検証
CRPサイクル2では、業務全体を通じてTo-Beプロセスの妥当性を本格的に検証していきます。ここでの狙いは、ERPの標準業務を「受け入れる」から「使いこなせそうだ」と思えるレベルへと引き上げることです。まだ完全に教えられるほどの習熟度（O）には達していませんが、プロジェクトメンバーの多くは“U（自分で操作できる）”レベルに到達し、標準業務をベースに現実的な判断ができる状態にあります。
そのため、サイクル1では控えていた機能要求レベルの検討も、ここでようやく扱える段階に入ります。To-Be業務への理解が定着し始めているからこそ、「この処理はこのパラメータ変更で対応できるのでは？」「この手順は他部門にどう影響するか？」といった改善の視点が、ユーザーから自然と出てくるようになります。
重要なのは、ここで出てくる声がAs-Isに引き戻された要求ではないという点です。これは、標準業務を前提にした上での改善提案であり、ERPと業務の“関係”が成立している状態といえます。
こうした機能要求の多くは、MoSCoWでいう優先度の「Could」、すなわち社内で完結し、標準機能や運用の工夫で吸収可能なものです。
例えば「製造報告の項目を変えたい」という要求は、現行踏襲や単なる見栄えの問題ではなく、報告単位の明確化、べき動率や総合設備効率（OEE）と言ったKPIや分析の目的に結びついた要求になるでしょう。
同様に「在庫照会を簡素にしたい」という要求も、単に画面を見やすくしたいという話にとどまりません。まず、そもそも「見なくても業務が回る状態」へと改善した上で、それでもなお確認が必要な情報に絞り込み、表示される項目がそのまま判断やアクションに直結するような情報設計を意図したものとなるはずです。
このように、Could要求であっても、その背後にある意図がプロジェクトの目的や将来の業務プロセスと結びついていれば、標準機能の範囲内で自社最適を模索する建設的な提案となります。
ただの利便性追求に終わらせず、「業務のあるべき姿」と「ERPの持つ標準構造」の関係を保ちながら再設計していく、その姿勢こそが、CRPサイクル2においてユーザーの視点が進化し、変革を担う意識が確立されていくプロセスなのです。
なお、この段階においても拡張機能開発に安易に流れることを避けます。むしろ、「このCould要求を、どうすれば標準機能で吸収できるか」という視点を大切にしながら、プロジェクトメンバーが自ら運用設計に関与し、構想・判断の主体として機能し始めることこそが、サイクル2の醍醐味です。
CRPサイクル3：課題に向き合い、自ら乗り越える仕上げの検証サイクル
CRPサイクル3は、これまでのサイクル1・2で明らかになったビジネスプロセス課題に対して、的を絞って実機検証を行う仕上げのサイクルです。FTSアプローチでは、新システムに業務を合わせていく過程で、「現場としてどこを工夫すれば対応できるのか」「運用で吸収できるのか」といった前向きな設計上の課題が浮き彫りになります。サイクル3は、そうした課題を整理・対応するための時間として計画されます。
このサイクルは、CRP全体の計画段階ではあえて“空白”にしておくのが基本です。というのも、サイクル1や2を通じて初めて見えてくる本質的な論点に柔軟に対応するためには、事前に検証テーマを固定せず、状況に応じてこの期間を活用できるようにしておくことが重要だからです。ここでは、業務全体ではなく、特定の課題に絞った局所的かつ実践的な検証を行います。
この時点でプロジェクトメンバーの習熟度はさらに高まり、一部では“O（人に教えられる）”レベルに近づいています。ベンダーの支援を受けつつも、標準機能で課題にどう対処するか、どこまでを運用で対応し、どこからを業務ルールとして整理すべきかといった判断を、自らの力で進められるようになっている段階です。
CRPサイクル3では、単に課題の有無を確認するだけでなく、運用開始後に向けた具体的な整理や落としどころを見つけていくことが大きな目的となります。ERPの標準に対して、現場の業務をどこまで合わせられるか、または業務側をどこまで柔軟に再設計できるか。そうした現実的な着地点を、自ら見つけ出していくステップがここにあります。
拡張機能開発要求とエンハンスリクエスト
CRPサイクル3では、これまでのサイクルで浮かび上がった業務プロセス上の論点や制約条件について、実機を用いて集中的な検証を行ってきました。その結果、標準機能だけではどうしても対応しきれない業務が、一部で明らかになることもあります。ここで初めて、「拡張機能開発要求」という選択肢を慎重に検討する段階へと進みます。
こうしてCRPを通じて浮上した拡張機能開発要求には、大きく二つの対応方針があります。ひとつは、自社でアドオン開発を行う道。もうひとつは、ERPベンダーに対して標準機能への組み込みを要請する“エンハンスリクエスト”の道です。いずれの選択肢を取るにしても、ビジネスプロセスオーナー（BPO）の判定と、ステアリングコミッティ（ステコミ）の承認を経て初めて実行に移されます。それほどまでに、標準機能での運用に強いこだわりを持つことが、FTS導入の要諦なのです。
なかでもエンハンスリクエストは、業界固有の業務要件や標準機能ではどうしても対応できないケースにおいて、ERPベンダーと協議のうえで製品ロードマップへの反映を目指すものです。他社にも共通する課題であれば、ベンダー側も標準化を前向きに検討する可能性があり、導入企業にとっても業界全体にとっても建設的な選択肢となります。
ただし、エンハンスリクエストが受理され、実際に開発・リリースされるまでには時間がかかるため、その間は一時的にマニュアル対応で業務を回せることが前提となります。その上で、「本当にその機能は標準として必要か」「暫定運用で対応可能か」といった観点から冷静に判断を下すことが、チェンジマネジメントとして極めて重要です。
このように、CRPの過程を経て導き出された拡張機能開発要求は、単なる“希望”ではなく、標準の可能性を徹底的に探った上での最終判断であり、プロジェクトの思想と設計方針が凝縮される重要な局面と言えます。
ブループリントのアップデートと運用モデル評価：自立運用への最終ステップ
CRPの全サイクルが完了すると、To-Beヒアリングの段階で作成されたブループリント初版が、CRPで得られた知見を反映してアップデートされます。この最新版のブループリントは、現場が新たな業務プロセスをどこまで実践できるかを示す、いわば「新業務の設計図」の完成形です。
この設計図をもとに、プロジェクトメンバー自身が主導して実施するのが「運用モデル評価」です。ここでは、ベンダーの支援に依存することなく、ユーザーが自らの手で実機を操作し、業務シナリオを一通り再現していきます。CRPのような“お膳立てされた環境”ではなく、プロジェクトメンバーが独力で回せるかを見極める、いわば自立運用への第一工程です。
このとき使用するシナリオは、より実践的かつ自社の業務事情に即したものとして、プロジェクトメンバー自らが設計します。その過程で、まだ習熟が十分でない領域や、業務の運用上の盲点が可視化され、導入前の最後の補強ポイントとして浮かび上がってきます。
この「運用モデル評価」は、トレーニングやCRPを含めて通算5回目となる実機検証であり、この時点でメンバーの習熟度はO(人に指導できる)レベルに達します。もはや、As-Isシステムへの未練や違和感を口にするメンバーは見当たらず、新業務と新システムを主体的に受け入れ、使いこなすステージに入っています。
運用モデル評価は単なる確認作業ではなく、プロジェクトメンバー自らが「このERPで、私たちは業務を回せる」と確信し、責任を持って受け入れるための重要な通過点です。チェンジマネジメントの観点からも、プロジェクトが“現場のもの”へと移行する、決定的なタイミングだと言えるでしょう。
まとめ
CRPを通じて、ユーザーは新しい業務とERPの標準に慣れ、使いこなす力を身につけてきました。変革の準備は整い、いよいよ実際の運用に踏み出す段階です。
次回は、こうして確立した運用モデルを、どのようにエンドユーザーへつなぎ、現場が主体となってERPを運用していくのかをお伝えします。
