2022
5/19
実績は、どう評価し、スコアをつけていけばよいでしょうか？
導入企業名や件数をただながめてしまうと、次のような主観的なコメントになります。
「お！大手企業にも導入しているな！」
「この会社に導入しているなら信頼できそう」
「100社も実績あるから大丈夫だろう」
これらを客観的に評価するために、実績を主に4つの項目で確認します。
① 実績数
ここは単純に数だけを評価します。パッケージであれば、そのパッケージを導入した企業数を見ます。スクラッチ開発であれば、そのベンダーがシステム構築した企業数を見ます。
この実績数は、いわばそのベンダーの「経験値」です。数が多ければ多いほど、そのシステムに関する業務知識とノウハウを保有しています。多くの解決策や修羅場をくぐってきた数とも言えます。
ただし、漠然とした数は、ベンダー側が誇張したり、ウソの数字で盛ることもできてしまいます。そのため、他の実績項目と合わせて確認する必要があります。
② 同業他社への導入実績
自社と同じ業界・業種の他社への導入実績も、大きな評価ポイントとなります。
特にパッケージの場合は「そのパッケージでヨソは運用できている」という証明にもなるため、自社でも導入できる確率は高くなります。できれば実名を出してもらい、本当に「同業なのか？」は確認する必要があります。
③ 規模実績
導入先のシステム規模があまりにもかけ離れていると、性能面で不都合が生じます。特に自社よりもはるかに小さな企業への導入実績しかなければ、かなりリスクは大きくなります。
性能面で大量データを想定していないからです。
例えば、一覧検索画面でレコード件数が多すぎてフリーズしたり、データの一括処理で長時間も処理が終わらなかったりします。
この事象の恐ろしいところは、プロジェクトの前半では問題が発覚しないことです。要件定義フェーズでは、プロトタイプ画面で件数が少ないため、サクサク動き、処理スピードは全く気になりません。
ところがプロジェクト終盤になると、本番データを大量に移行してテストするため、そこではじめて気づくのです。
しかもここで発覚する問題は、画面の項目やレイアウト変更などの軽微なレベルではなく、システム本体のロジックを全面的に見直すことになり、影響がとても大きなものです。急にプロジェクトが暗礁に乗り上げることになりかねません。
また、小さな1事業所で使う場合と、全国やグローバルといった規模で使う場合では、求められる機能もインタフェースも全く別モノとなります。
利用部署や人数が多くなればなるほど、「システム管理」機能も充実している必要があります。また、ポータル画面やお知らせ機能、連携機能やコミュニケーション機能など、操作性や使いやすさといった点でも、足りないものがたくさん出てきます。
基本的には「大は小を兼ねる」で、自社の規模と同等、または自社よりも大きい規模を想定したシステムが無難です。規模や人数が多くなっても、かゆいところに手が届く機能が充実しているからです。
ただし、自社よりもあまりにも規模が大きすぎる場合は、予算をはるかにオーバーしてしまいます。なぜなら、豊富すぎる機能を持て余してしまうからです。使わない機能や立派すぎる機能もすべて費用に含まれています。そのため、コストパフォーマンスが悪くなり、採算がとれなくなります。
規模は、自社と同じか、将来の拡大を見越してやや大きいぐらいがちょうどいいのです。
④ プロジェクト特性に応じた実績
プロジェクトやシステムの特性に合わせて、特定の実績を求めるケースがあります。
・○○○システムとの連携実績
・ノンカスタマイズの実績
・ジョイントベンチャーでのプロジェクト実績
・国や自治体、財団法人など特定組織への導入実績
これらは、プロジェクトにおいて、リスクだと思われる事項をそのベンダーが「経験」しているかを、実績で問うのです。ベンダーが他社で経験していれば、その対処ノウハウがあり、安心することができます。
この項目は、プロジェクトごとに設定していくことになります。
これら実績評価の①～④にウェイトを設定し、それぞれスコアリングしていきます。
実績は、その「数」と「質」の両方を見ることが重要です。
（関連記事）
【提案評価】定量評価と定性評価をどう使いこなしていけばよいか？
【提案評価】ベンダー提案の5大評価項目とは
【提案評価その1】要求機能が最重要
【提案評価その1】要求機能のFIT率60%をどう考えるか？
【提案評価その2】費用は5年トータルで考える
【提案評価その4】プロジェクト計画の6つの評価項目とは？
【提案評価その5】その他項目を評価し、バランスをとる
