【第11回】Fit to Standardで要件を決める秘訣は何か
◆この記事の要約
本記事では、ユーザー主導のERP導入における「Fit to Standard」手法を活用し、要件定義を効率的かつ効果的に進める秘訣を解説します。標準機能に基づく要件決定の重要性と、現場の声を反映しながらカスタマイズを最小限に抑えるポイントを独自の視点で紹介します。ERP導入成功の鍵となる実践的なノウハウが得られます。
- ユーザー主導のERP導入における「Fit to Standard」の役割とメリット
- 標準機能を基準にした要件決定の具体的な進め方
- カスタマイズを抑えつつ現場のニーズを反映する秘訣
- ERP導入の効率化と品質向上を両立させる実践的アプローチ
このようなことにならないために、何をすればよかったのでしょうか?
例えば、全体構想策定段階からERP候補を調査し、事前に標準機能とGAPになりそうな業務について、Fit to Standardで導入できるかを検証する方法があります。
そこで今回は、「クラウド時代!ユーザー主導のERP導入とは」として、基幹システム刷新におけるFit to Standardによる要件定義の進め方の秘訣をご紹介します。
オーソドックスな製品・ベンダー選定プロセスとは
「ユーザー主導のERP導入」シリーズでは、ERPの選定として、下記のプロセスをご紹介しました。
【図1】従来型のベンダー選定
全体構想策定では、業務・システムの現状概要分析、ユーザー部門の目指す姿や取り組みテーマ検討などを行い、全体ロードマップとプロジェクト計画を策定します。業務要件定義では、目指す姿を具体化し、業務改革施策の立案や新業務プロセス設計を行ったうえで、システム化方針を策定します。
この段階で、導入するERPと導入ベンダーの評価・選定を行います。
- 製品・ベンダーの評価・選定を精緻に行い、自社にとって最適なERPを選定するために、RFP(Request for Proposal:提案依頼書)が作成されます。
- RFPは初期調査によって選定された数社~10数社の候補に対して発行されます。
- 導入ベンダーからの提案内容は、事前に決められた評価基準によって評価され、その後のプレゼンテーションやデモなどを経て、最終的なERPと導入ベンダーが決定されるという流れが一般的です。
- ERPと導入ベンダーが決定したら、提案された導入作業やスケジュール、体制などを精査し、ベンダーとも協議のうえで導入にむけたプロジェクト計画を策定することになります。
これらは、スクラッチ開発(自社の独自開発)におけるウォーターフォール型の開発方法論に近い方法です。スクラッチ開発では、事前にソフトウェアがないため、業務要件が固まるまで提案依頼できないのが通常です。しかし、ERPは、操作可能なソフトウェアがすでにあるところが、スクラッチ開発との大きな違いです。
RFPを作成しても、なぜ蹉くのか
RFPは、現状の課題や次期基幹システムの位置付けを明確にし、システム刷新の意図を各社に伝えて適切な提案をしてもらうために作成します。RFPは各社からの提案品質を均一化するツールでもあり、各社の提案内容を客観的に評価するためのフレームワークになります。そういう意味ではRFPは非常に重要な役割を持っています。一方で、RFPを作成するまでの工数や、多くの候補ベンダーからの提案内容を理解し、比較検討を行う工数は膨大となり、非常にエネルギーの要る作業になります。
【図2】RFPによる評価選定
また、ERPと導入ベンダーを決定した後は、実際の導入作業としてシステム要件定義に移ります。
システム要件定義の段階でシステムの主管部門であるユーザー部門も交えて、ERPの持つ標準機能や標準プロセスを評価します。しかしこの段階で、RFP作成時やベンダー選定時には想定していなかったギャップが多く発見され、最悪の場合にはプロジェクトが頓挫するケースも少なくありません。つまり、一生懸命RFPを作っても、ERPやベンダーの見極めが正しくできるとは限らないということです。
【図3】よくある失敗例
Fit to Standardの早期検証
RFPは各社からの提案内容を一定レベルに保ち、客観的に評価を行ううえで重要なドキュメントであり、不要とは言い切れません。ただ、ERPの選定においてより重要なことは、検討候補となるERPの思想を理解し、それらを使って業務が遂行できるかどうかの見極めを行うことです。
特に、昨今ではERPの持つ業務プロセスに自社の業務を合わせるべきというFit to Standardの考え方が広まってきました。基幹システム刷新をFit to Standardで実現するためには、それらの持つ標準機能やプロセスを最大限活用することが成功要因となります。したがって、Fit to Standardで実現できるか否かの見極めを、早い段階から行うことが不可欠となるのです。
Fit to Standard検証では、導入企業とベンダー双方で、それなりの時間とメンバーが必要になります。ERPに関する詳細な機能説明を受けながら、想定する業務をERPの標準機能で可能かどうかの議論をするため、1日2日ではできません。Fit to Standard検証は、システム要件定義で行う実機検証(POC、CRP)を前倒しして、限定的に行うイメージです。
【図4】Fit to Standard検証
したがって、このような作業を行う候補ベンダーは自ずと絞られ、少数の候補に対して深い議論を行うことになります。Fit to Standard検証を行うことで、検討メンバーがFit to Standardの考え方に慣れ、製品選定前にERPでの業務をイメージできるようになり、新システムのスムーズな導入を期待することができます。
Fit to Standard検証の進め方
ERPの導入プロセスにFit to Standard検証を組み込む場合、一般的に下記のような進め方になります。
【図5】Fit to Standard検証によるプロジェクトの進め方
Fit to Standard検証を行うためには、その前にある程度候補となるERPを絞り込んでおくことが必要です。Fit to Standard検証は、導入企業側にもベンダー側にも工数がかかるため、多くの候補を検証することは現実的ではありません。場合によっては有償となる可能性もあります。そのため、候補は2社~3社に絞り込んでおくことを推奨します。
この絞り込みを行うため、RFI(Request For Information:情報提供依頼書)を作成します。作成したRFIをERP提供ベンダーや導入ベンダーに発行し、製品概要・導入実績・特有要件への対応事例・導入体制・サポート内容・製品提供形態・価格などの情報を収集します。書面だけで判断できない場合は個別の説明会やデモ等で確認することも必要です。
その後、絞り込まれたERPについて、要件定義の段階でFit to Standard検証を行い、標準機能での実現範囲や導入ベンダーの実力値(製品知識、Q&A対応等)を評価して、製品・ベンダーを決定します。
この段階ではまだ導入に関するスケジュールや費用は見えていないため、決定した導入ベンダーに対してRFPを発行し、詳細な導入計画の提案を依頼します。
こう見ると結局RFPを作成するように見えますが、従来のRFPが製品・ベンダーの選定を目的としているのに対し、ここでのRFPは導入に対する提案と見積の依頼がメインとなります。また、Fit to Standard検証により適合性が評価された状態での見積となるため、導入後の見積のブレのリスクを低減することができます。Fit to Standard検証は、システム要件定義以降も引き続き実施していくことで、ユーザー部門主導でERPの標準機能を使い倒すことが期待できます。
全体構想策定の前にFit to Standard実現性検証
全体構想を描く前に、その全体構想を実現するITやDXの現在地点を理解しなければ、全体構想が絵に描いた餅になりかねません。そこでレイヤーズ・コンサルティングでは、全体構想を描く前にFit to Standard実現性検証フェーズを推奨しています。
【図6】全体構想策定前のFit to Standard実現性検証
Fit to Standard実現性検証フェーズでは、ERPの標準機能を想定しながら、自社で大きく違うところはどこか、その違いをどう解決していくのか、解決するための利害関係者への対応はどうするかといった方向性を見極めます。また、Fit to Standard実現性検証により、ユーザー部門がERPの標準機能を事前に理解するため、全体構想策定フェーズにおいて「標準機能に無い自社都合の理想論の検討」にならず、自社の業務改革ポイントに集中した検討が可能になります。
まとめ
今回は、「クラウド時代!ユーザー主導のERP導入とは」として、基幹システム刷新におけるFit to Standardによる要件定義の進め方の秘訣をご紹介しました。今後の基幹システム刷新は、情報システム部門やベンダーへ丸投げはできません。ユーザー部門が主導して、ERPを Fit to Standardで導入していくことが成功の秘訣といえます。詳細な Fit to Standard でのERP導入のポイントについては、是非レイヤーズ・コンサルティングにお問い合わせください。


ソリューションに関するオンライン相談問い合わせる メルマガ登録
最新情報をお届け! メルマガ登録
職種別ソリューション







