コラム
効率的・効果的なERP導入方法 第4回：パッケージ/導入ベンダー選定 2011.2.14 末松 康祐
今回はパッケージ／ベンダー選定のポイントをご紹介します。
現在国内で利用出来るERPパッケージは100種類程度存在します。
また、同じERPパッケージでも複数の導入ベンダーが存在するものもあります。
ERPパッケージや導入ベンダーには会社規模や業種、業態などで得意/不得意があり、 誤った選択をすると大きな失敗に繋がります。
弊社では公正な選定をするためのポイントを以下のように考えています。
�機ァ鋲韻古敝供匹派床舛垢�
パッケージベンダーや導入ベンダー各社は同じRFPに対する提案でも往々にしてその内容が大きく異なります。
提案内容が異なる主たる要因と提案内容の差は以下のように考えられます。
多様な提案を比較／評価することは非常に困難です。
可能な限り”同じ土俵”に合わせることが公正な選定をする最も重要なポイントです。
特に複数のパッケージ、複数のベンダーの組み合せで提案を受けると最も難しい選定を強いられます。
期間的な余裕があれば、まずはパッケージを選定し、その上で導入ベンダーを選定する２段階選定がよいと考えます。
（少なくとも２つ程度のパッケージに絞り込むことがよいと考えます。）
また、導入ベンダーの提案では以下の内容について提案の差異を把握／整理します。
●システム化範囲（実現機能）
●ベンダーの役割（作業範囲）
●コスト
これらが相違している上では正当な評価ができません。
各社との調整を行い、このうち２点（または少なくとも１点）については”同じ土俵”となるように 提案を修正して頂き、評価すべきと考えています。
�供ヂ審囘�な視点で評価する
感覚的な評価でパッケージ/ベンダーを選定し、失敗するプロジェクトを多く見てきました。
評価に際しては、如何に多角的な視点でバランスよく評価するかが肝になります。
また、誰が評価するかによって全く異なる評価結果となります。
各々の視点の評価項目と評価者を適切に決めるプロセスが最も重要と考えています。
弊社では下記の視点で評価項目を作成し、各々の視点の評価者をクライアントと検討します。
評価を多角的にするために、様々な立場のメンバーで評価することも重要です。
しかしながら、プロジェクトへの参画度が低いメンバーは表面的な評価をする恐れもあります。
適切な評価者を選定することもさることながら、評点の集計方法を工夫することも必要です。
評価者が多い場合や部門別の偏りがある場合、一旦部門別や役職別等で集計したの後に全体集計することで偏りを是正できます。
また、評価者に加重をつけることで適正の高い評価者の評価を重用することができます。
弊社では、これまでの多数のプロジェクト経験から作成した評価表テンプレートを保有しており、 クライアントの状況に合わせてカスタマイズ（項目の追加/削除や加重の見直し）することで迅速かつ公正な評価を進められるようにしています。
評価項目については、”粗すぎる”と感覚的な評価となってしまい、”細かすぎる”と加重の設定が非常に困難となり、 妥当な評価であるかを判断できなくなります。
多角的な視点を常に意識しながら、評価結果の集計や評価項目をバランスよく設定することで公正で失敗しない評価となります。
�掘ゥ螢好�を比較／評価する
評価項目に従い点数をつける事に加え、潜在するリスクを明らかにすることが重要です。
失敗プロジェクトの殆どが当初想定できたはずのリスクがプロジェクト推進のアキレス健となったと言えます。
各パッケージ／ベンダーにおけるリスクを意識した選定プロセスとすることが必要になります。
＜リスクを意識した選定プロセス＞
・まず、自社の状況により、容認できないリスク（＝キラーコンテンツ）を定義
・パッケージや導入ベンダーの開示情報でそのリスクに該当する場合はRFP提示候補の対象外
・開示情報で明確にならない場合、RFPで情報提供を要求
・提供された情報で明確に容認できないリスクが認められる場合は、書類審査にて落選
・提供された情報及び提案内容からリスク顕在化の確度、回避可否、軽減可否を評価
・リスク顕在化確度が高く、容認できるレベルに回避・軽減ができない提案は総合評点の結果に依らず落選
何を容認できないリスクと定義するかは企業の状況によって異なります。
下表のようにQCDSの視点で企業の状況とリスク評価すべきポイント整理を行うことで、重大な漏れをなくすことができます。
これらの点に留意することでで公明正大な選定が可能となり、社内でも納得感が得られる選定になると考えております。
次回は要件定義/プロトタイプを推進するポイントをご紹介します。
【次回以降の掲載予定】
第5回：要件定義/プロトタイピング
第6回：移行
第7回：チェンジマネジメント
第8回：プロジェクトマネジメント
現在国内で利用出来るERPパッケージは100種類程度存在します。
また、同じERPパッケージでも複数の導入ベンダーが存在するものもあります。
ERPパッケージや導入ベンダーには会社規模や業種、業態などで得意/不得意があり、 誤った選択をすると大きな失敗に繋がります。
弊社では公正な選定をするためのポイントを以下のように考えています。
�機ァ鋲韻古敝供匹派床舛垢�
�供ヂ審囘�な視点で評価する
�掘ゥ螢好�を比較／評価する
�機ァ鋲韻古敝供匹派床舛垢�
パッケージベンダーや導入ベンダー各社は同じRFPに対する提案でも往々にしてその内容が大きく異なります。
提案内容が異なる主たる要因と提案内容の差は以下のように考えられます。
| 要因 | 提案内容の差 |
|---|---|
| コストを低く見せようとする | システム化対象とする業務範囲が異なる （RFPで提示した全領域に対する提案ではない） |
| ベンダーの作業範囲が異なる （RFPで提示した作業の一部が”お客様作業”となっている） |
|
| ベンダーが業務を知らない | システムで実現する機能が異なる （業務視点で現実的ではない実現方法が提示されている） |
| ベンダーが業界を知らない | システムで実現する機能が異なる （業界固有の要件が考慮されていない） |
| パッケージの理解度/導入スキルの差 | パッケージの標準機能の適用範囲が異なる （標準機能で実現可能な機能が追加開発対象となっている） （標準機能では不足する要件にも標準機能適用となっている） |
| 周辺システムに関するスキルの差 | ERPパッケージ以外に導入する周辺システムが異なるため、 実現機能やインターフェース開発工数が異なる |
多様な提案を比較／評価することは非常に困難です。
可能な限り”同じ土俵”に合わせることが公正な選定をする最も重要なポイントです。
特に複数のパッケージ、複数のベンダーの組み合せで提案を受けると最も難しい選定を強いられます。
期間的な余裕があれば、まずはパッケージを選定し、その上で導入ベンダーを選定する２段階選定がよいと考えます。
（少なくとも２つ程度のパッケージに絞り込むことがよいと考えます。）
また、導入ベンダーの提案では以下の内容について提案の差異を把握／整理します。
●システム化範囲（実現機能）
●ベンダーの役割（作業範囲）
●コスト
これらが相違している上では正当な評価ができません。
各社との調整を行い、このうち２点（または少なくとも１点）については”同じ土俵”となるように 提案を修正して頂き、評価すべきと考えています。
�供ヂ審囘�な視点で評価する
感覚的な評価でパッケージ/ベンダーを選定し、失敗するプロジェクトを多く見てきました。
評価に際しては、如何に多角的な視点でバランスよく評価するかが肝になります。
また、誰が評価するかによって全く異なる評価結果となります。
各々の視点の評価項目と評価者を適切に決めるプロセスが最も重要と考えています。
弊社では下記の視点で評価項目を作成し、各々の視点の評価者をクライアントと検討します。
| 視点 | 評価方法 | 評価者に必要なスキル | 評価者（例） | |||
|---|---|---|---|---|---|---|
| 事務局 | IT部門 | 業務部門 | 経営層 | |||
| 提案内容（書面） | 評価項目に対して 評価者が評点 |
・論理的思考能力 ・RFP提示内容 ・業務基礎知識 ・IT基礎知識 |
○ | △ (一部) |
△ (一部) |
|
| プレゼンテーション | 評価項目に対して 評価者が評点 |
・論理的思考能力 ・コミュニケーション能力 |
○ | ○ | ○ | ○ |
| コスト | 基準とする額からの 乖離額で点数化 |
− | ○ | |||
評価を多角的にするために、様々な立場のメンバーで評価することも重要です。
しかしながら、プロジェクトへの参画度が低いメンバーは表面的な評価をする恐れもあります。
適切な評価者を選定することもさることながら、評点の集計方法を工夫することも必要です。
評価者が多い場合や部門別の偏りがある場合、一旦部門別や役職別等で集計したの後に全体集計することで偏りを是正できます。
また、評価者に加重をつけることで適正の高い評価者の評価を重用することができます。
弊社では、これまでの多数のプロジェクト経験から作成した評価表テンプレートを保有しており、 クライアントの状況に合わせてカスタマイズ（項目の追加/削除や加重の見直し）することで迅速かつ公正な評価を進められるようにしています。
| 視点 | 評価項目の例 | |
|---|---|---|
| 提案内容（書面） | パッケージ | 導入実績 |
| 実現可能機能 | ||
| インフラ | システム構成 | |
| セキュリティ要件 | ||
| ベンダー | 導入実績 | |
| 導入アプローチ | ||
| サービス内容 | ||
| 体制 | ||
| プレゼンテーション | コミュニケーション能力 | |
| RFP理解度 | ||
| 業務理解度 | ||
評価項目については、”粗すぎる”と感覚的な評価となってしまい、”細かすぎる”と加重の設定が非常に困難となり、 妥当な評価であるかを判断できなくなります。
多角的な視点を常に意識しながら、評価結果の集計や評価項目をバランスよく設定することで公正で失敗しない評価となります。
�掘ゥ螢好�を比較／評価する
評価項目に従い点数をつける事に加え、潜在するリスクを明らかにすることが重要です。
失敗プロジェクトの殆どが当初想定できたはずのリスクがプロジェクト推進のアキレス健となったと言えます。
各パッケージ／ベンダーにおけるリスクを意識した選定プロセスとすることが必要になります。
＜リスクを意識した選定プロセス＞
・まず、自社の状況により、容認できないリスク（＝キラーコンテンツ）を定義
・パッケージや導入ベンダーの開示情報でそのリスクに該当する場合はRFP提示候補の対象外
・開示情報で明確にならない場合、RFPで情報提供を要求
・提供された情報で明確に容認できないリスクが認められる場合は、書類審査にて落選
・提供された情報及び提案内容からリスク顕在化の確度、回避可否、軽減可否を評価
・リスク顕在化確度が高く、容認できるレベルに回避・軽減ができない提案は総合評点の結果に依らず落選
何を容認できないリスクと定義するかは企業の状況によって異なります。
下表のようにQCDSの視点で企業の状況とリスク評価すべきポイント整理を行うことで、重大な漏れをなくすことができます。
| リスクの視点 | 企業の状況（一例） | 対ベンダーでリスク評価すべきポイント |
|---|---|---|
| Quality ＝業務品質/システム品質 |
システムトラブルが売上に直結する | 品質管理プロセスの精度 |
| 他社における実績有無 | ||
| 定着化支援の体制 | ||
| IT部門が各業務内容を把握できていない | 業務視点でのコミュニケーション可否 | |
| 業務課題の解決能力 | ||
| Cost ＝導入価格・保守価格 |
特殊業務が多い | 追加開発を抑える仕掛けの有無 |
| RFPて提示した機能要件が粗い | パッケージに業務を合わせるアプローチ可否 | |
| Delivery ＝スケジュール遵守 |
業務部門がITに疎い | 業界/業務の理解度 |
| 同一業界の導入実績 | ||
| Service ＝サービス |
将来的に海外展開を考えている | 海外拠点の有無 |
| 海外での導入可否 | ||
| 多言語・多通貨対応可否 | ||
| IT業務のアウトソースを考えている | 保守サービスレベル | |
| 汎用的なシステムスキルの有無 | ||
| 充実したサービス体系の有無 |
これらの点に留意することでで公明正大な選定が可能となり、社内でも納得感が得られる選定になると考えております。
次回は要件定義/プロトタイプを推進するポイントをご紹介します。
【次回以降の掲載予定】
第5回：要件定義/プロトタイピング
第6回：移行
第7回：チェンジマネジメント
第8回：プロジェクトマネジメント
