SaaS ERPをFTSで導入するためのチェンジマネジメント 総論賛成から各論反対／意識改革の分岐点 その5：CRP（Conference Room Pilot）と運用モデル評価《前編》
ERPトレーニングを終えたプロジェクトは、いよいよCRP（Conference Room Pilot）という重要な局面に入ります。ここまでのステップでプロジェクトメンバーは、ERP導入が自社にとってどのような変革の意義を持つのかを知り、経営陣と志を同じくして、何を変えるべきかを自ら考え、必要な知識を身につけてきました。そしてCRPは、それらの知識と構想を現実の行動に移し、新しい仕事の仕方を自ら決定していく段階です。つまり、構想から運用への橋渡しとなる決断の場であり、チェンジマネジメントの核心ともいえるステップなのです。
従来の導入方法の問題点
従来のERP導入では、このCRPは「Fit & Gap」という手法に依存することが一般的でした。この手法では、現行業務や既存システムと新たに導入するERPを比較し、その差（Gap）が見つかれば、それを埋めるためにERP側へ拡張開発を施すというアプローチを取ります。このやり方は、ある意味で“簡単”です。なぜなら、ユーザー企業は現行の業務やシステムをよく理解しており、ERPとの差異を要件として挙げることは容易だからです。しかも、変革ではなく、変更で済む。すなわち、現行業務の根幹をいじる必要はなく、システム操作の変更点だけを学び直せばよいという発想になります。
さらに、ERP導入を支援するベンダー側も、「このようなアドオン開発の経験があります」といった過去の事例を示して、いかにも安心感のある提案を行います。ユーザー企業は、そのGapを埋めてもらうことで安心し、ベンダーは開発実績として誇らしく掲げる。この構造には、心理的な背景も存在します。ユーザーと仲良くしたい、目の前で困っているユーザーを助けたい、困っている理由がGapだから埋めてあげたい、ユーザーを変革するより言われたことを開発する方が自分たちのスキルを活かせる、そして、開発することでユーザー企業から感謝される。要は、変革を求めると嫌われることもありますが、変更ならむしろ頼りになると喜ばれるからです。開発にリソースの比重を持つベンダーなら、なおさら開発にリードしていくことでしょう。
こうした構図は、FTSアプローチを掲げている最近のプロジェクトにおいてさえ、未だに根強く残っています。表面的には「業務をシステムに合わせる」と掲げながら、実態は旧来のGap起点の要件整理に終始してしまっているのです。結果として、変革を志した経営陣にとっては、「思い描いていた改革と違う」と落胆し、その矛先は、提案や導入を担ったベンダーへの不満として表出します。ベンダーとしては、目の前のユーザーが喜ぶことを願い、要望に応じて開発を進めてきたつもりでも、経営層から見れば、それは本来目指すべき変革の道筋を外れた対応に映ってしまうのです。
その一方で、ユーザーは「このままでは仕事が回らない」と声を上げ、日々の業務を守るために従来のやり方を維持しようとします。その結果、DXという名のもとにレガシー業務の延命が正当化され、ERPを新業務に合わせるのではなく、従来業務にERPを寄せていくという逆転現象が起きてしまうのです。
プロジェクトの羅針盤であるはずのRFP、だがその実態は…
ERP導入プロジェクトにおいて、RFP（提案依頼書）は本来、プロジェクトの方向性を示す「羅針盤」の役割を果たすべき文書です。ところが実際には、現行業務（As-Is）を前提とした機能要求の集積となっているケースが少なくありません。
このようなRFPに基づくプロジェクトでは、ERPの標準業務プロセスとの乖離が生じ、結果として拡張機能開発が爆発的に増えるという事態を招きます。つまり、RFP自体が「変わらないこと」を前提に書かれてしまっているため、Fit to Standardの実現どころか、その足を引っ張る構造的な要因となってしまうのです。
一方、チェンジマネジメントを取り入れて進めたプロジェクトでは、こうしたRFPの問題に早期に気づくことができます。CRPの過程でERPの標準機能を実際に体感し、To-Be業務プロセスに基づいた新しい仕事の仕方を試行するなかで、「変えないこと」を前提にした機能要求そのものがそもそも不要だったのではないかという気づきへと、プロジェクトメンバーの認識が変わっていきます。
実際に、いくつかのプロジェクトでは、RFPに記載されていた機能要求が、CRPによってすべてリセットされたという例もあります。「変えることを前提にした導入」でなければ、真の業務改革にはつながらないということが、こうした事例からも明らかです。
第五ステップ：実践〜新業務にチャレンジ〜
ここまで見てきたように、Fit to Standard（FTS）アプローチを真に機能させるには、チェンジマネジメントの視点が欠かせません。そこで本パートでは、その中核をなすCRP（Conference Room Pilot）を取り上げ、各サイクルに共通する目的と考え方を整理していきます。
CRPの5つの目的
CRPは、単なる操作確認や業務テストではありません。プロジェクトメンバーがERPの標準機能に“慣れ”、その理解を深めながら、自社の新しい仕事の進め方を主体的に描いていくプロセスです。こうした観点から、CRPでは以下の5つの目的を一貫して追求していきます。
- 新業務プロセスとデータモデルの検証
ERPの標準プロセスが自社業務に適合するか、想定したTo-Be業務が実行可能かを確認します。 - システム運用条件（パラメータやマスター定義）の確定
業務ルールに基づく初期設定が正しく構成されているか、検証を通じて詰めていきます。 - 実践的な操作の習得
プロジェクトメンバー自身が、実業務に即したシナリオを通じて標準機能を深く理解し、エンドユーザーへ新システムを指導できるレベルに到達することを目指します。 - 拡張機能開発要否の判断と整理
標準機能では対応が難しい領域を明確にし、対応方針（運用での対応・拡張機能開発）を整理します。 - 次フェーズ以降の作業見積もり
次フェーズに向けて、どの拡張機能を開発すべきかを整理し、それに必要な費用と期間を見積もるための情報を蓄積します。
これら5つの目的はそれぞれ独立しているようでいて、実際には一つの軸に沿って構造的に連動しています。なかでも「実践的な操作の習得」は中心的な役割を担っており、これが進むことで以下のような波及効果が生まれます。「新業務プロセスとデータモデルの検証」はTo-Be像に沿って深化し、「システム運用条件の確定」は自ら判断できるレベルに引き上げられ、「拡張機能開発の要否」は不要と見なされる領域が増え、結果として「次フェーズにおける開発見積もり」も最小限に抑えることができるのです。
こうした成果を確実に引き出すために、CRPでは段階的なアプローチを取ります。そのため、CRPは三つのサイクル（慣れる／検証する／仕上げる）で構成されており、それぞれに明確な目的と活動が割り当てられています。
CRPの実践は、標準に合わせた再設計から始まる
CRPの準備段階では、まずベンダーがERPの標準機能を踏まえた業務プロセスとデータ構造をきちんとモデリングし、新しい仕事の流れを明確に描き出すことが求められます。これは、単なる操作手順の説明ではなく、「なぜこの流れになるのか」「どのように業務全体がつながるのか」を構造的に示す作業です。
ただし、こうして構築された標準プロセスを、実際に理解し、腹落ちさせ、運用イメージを膨らませていくのはプロジェクトメンバーの役割です。ベンダーが示すのはあくまで「型」であり、それを現場の知見でどう咀嚼し、自社の運用にどう根付かせるかは、プロジェクト全体としての共同作業になります。
また、標準機能ではどうしても補えない業務がある場合もありますが、その際もすぐに拡張開発に頼るのではなく、まずはERPに備わっている機能や設定の工夫によって代替可能かを検討することが重要です。ここで問われるのは、ERPに業務を合わせていくための柔軟性と工夫、そして本当に必要な変化を選び取る判断力です。
こうしたプロセスを通じて、ERPの標準機能をどう活かし、自社の業務をどう進化させるか。まさにその選択の積み重ねが、企業として「変わる覚悟」を持てているかどうかを浮き彫りにしていきます。
ユースケースとクイックウィン
この実践を支える手法として、CRPではユースケースを活用します。たとえば「顧客〇〇から注文を受けて、倉庫△△から出荷する」といった、自社の実業務を模したシナリオを用意します。ユースケースは、「誰が（アクター）」「どのタイミングで（トリガー）」「何を操作・判断し（アクション）」「どの情報を扱い（インプット）」「何を結果として得るのか（アウトプット）」という構造で記述され、実際の業務の流れを具体的にERP上で体験できる形式となっています。
また、こうしたユースケースは、MoSCoWでMustやShouldに分類された業務要求に基づいて設計されます。プロジェクトの目的や制約、対外的な要請といった「実現すべき業務」について、標準機能で本当に対応可能かを、現場が自身の役割で体験・評価するのが狙いです。単にERPの使い方をなぞるのではなく、業務として成り立つかを主体的に見極めるステップです。そこに初めて、「このプロセスでいけるかもしれない」という運用上の納得や、「部門間での情報の受け渡しが標準機能で成立する」といった業務設計上の確信が芽生えてきます。
このように、CRPにおけるユースケースは、業務要求と現実の運用の接点を作るものであり、プロジェクトメンバーが「変わる」プロセスの起点となる重要な手段なのです。
ユースケースを通じた実践の中で、特に重要なのが「クイックウィン（Quick Win）」の体験です。ここで言うクイックウィンとは、業務要求に対してERPの標準機能だけで解決策を導き出し、短期間で成果を実感できることを意味します。
例えば、Mustに分類された「顧客ごとの条件に応じて、適切な在庫を引き当て、正しい販売価格を自動的に設定できること」といった業務要求に対して、標準の在庫引当機能や販売価格設定で対応可能であることがわかると、現場には大きな安心感が生まれます。「この仕組みで本当にいけるのか」といった漠然とした不安が、実機を通じた確かな体験によって払拭され、「このプロセスなら現場でも回せそうだ」という納得と手応えが芽生えてくるのです。
このような体験を繰り返すことで、プロジェクトメンバーの中に「自分たちで標準機能を使いこなしていける」という感覚が育っていきます。これは単なる機能への理解を超えて、「変われるかもしれない」という意識の転換につながります。そしてその小さな成功の積み重ねが、やがて「自分たちの力で運用していける」という自信へと変わっていくのです。
CRPにおけるクイックウィンは、プロジェクト成功の呼び水であると同時に、プロジェクトメンバーの心理的ハードルを一つずつ乗り越えていくためのチェンジマネジメント上の重要な仕掛けなのです。
まとめ
ここまでで、CRPが単なる検証作業ではなく、「変わること」を前提にした設計であること、そして従来手法では実現できなかった変革のために、どのようなチェンジマネジメントが必要かを見てきました。
次回（後編）では、このCRPの三つのサイクルを通して、プロジェクトメンバーがどのように変化を受け入れ、主体性を育み、やがて運用を自ら設計できるようになっていくのか？ その内面の成長と、プロジェクトの成熟過程を追っていきます。
