よいサプライヤー評価は、単に順位を付けるだけではありません。どの基準を重く見たのか、どの根拠が確認済みで、何が未確認なのかを示します。構成にはプレゼンテーションのデータストーリーを使い、問い、確認できる事実、限定した提案の順に並べます。
判断する目的と範囲を決める
最初に、採用するのか、次の審査へ進めるのか、根拠不足で保留するのかを明記します。基準日、対象範囲、譲れない要件も記録してください。各社の見積もりが同じ業務範囲を含む場合にだけ、公平に比較できます。
評価基準と根拠を集める
総コスト、納品能力、サービスレベル、品質、連携の手間など、判断を変える少数の基準に絞ります。提案書の主張と、実績、SLA文書、テスト結果などの根拠を分けて記録します。情報がない項目は「未確認」とし、いきなりゼロ点にはしません。
重み付けを見える化する
基準ごとの重みと尺度を示します。素点、重み、加重点を並べた表で十分な場合が多いでしょう。合計点を大きく左右する基準を少なくとも二つ示し、重みを妥当な範囲で変えたとき結論が変わるかを簡単に確認します。
短いスライド構成にする
- 判断の問いと基準日
- 比較可能な要件と対象外
- 評価方法と重み
- 結果と基準別の寄与
- リスク、未確認の根拠、感度
- 提案、確認事項、担当者
すべてのスライドで同じ尺度を使い、例示の数値には「例」と明記します。口頭説明がなくても検討できる形にしておくことが重要です。
不足を確認質問に変える
未確認の根拠や重みの大きい基準から、具体的な質問を作ります。SLAなら測定方法、例外、エスカレーションを、コストなら数量、契約期間、切り替え工数を尋ねます。各質問に担当者と期限を割り当てます。
評価結果が示さないこと
点数は将来の成果を保証しません。選んだ方法と基準日時点の根拠を表しているだけです。最後のスライドで、提案、前提、今後確認する事実を分けて書きます。
要件を分類する
要件を、必須条件、点数で比較する基準、未回答の問いに分けます。必須条件を満たさない提案は候補から外せます。点数の基準は、最低条件を満たした選択肢を区別します。未回答の問いは次の約束の前に解決します。合計点が高くても必須条件の失敗を隠してはいけません。
例えば、顧客の問い合わせを処理するパートナーを選ぶチームなら、合意したサポート時間と顧客情報の扱いを必須にできます。サービス品質、導入工数、総コスト、レポートを点数化することもできます。これは説明用の例であり、実際の要件は担当チームが決めます。
見積もりの前提をそろえる
通貨、税、契約期間、含まれる数量、導入費、更新条件、対象外を確認します。オンボーディングや超過料金が別にあると、月額だけでは安く見えます。前提を行、各社を列にした表を作り、回答がない項目は「なし」ではなく「未回答」とします。
基本シナリオと、妥当と考える需要の変化を並べ、数量と期間をスライドに明記します。利用量への感度を示せますが、将来需要を予測したことにはなりません。
小さな点数表を使う
基準と重みを最終結果を見る前に合意します。結果を見て重みを変えると、好みの提案に合わせたモデルになってしまいます。1〜5の尺度なら、3は許容できる根拠で要件を満たす、5は合意した強い標準に照らしてさらに確かな根拠がある、というように意味を定義します。
例として、サービス品質40％、導入25％、コスト20％、レポート15％とします。Aが4、3、4、3、Bが3、5、3、4なら、加重点はそれぞれ3.60と3.65です。差が小さいこと自体が重要な発見で、Bが決定的に優れているとは言えません。導入の容易さがAのサービス評価を相殺しているため、二つの差を生む根拠とともに説明します。
争点の評価を1点変えるだけで結果が逆転するなら、パイロットやリファレンス確認などの追加検証を提案します。現在の情報では二つの選択肢が実質的に同等だと示すこともできます。
根拠を追跡可能にする
重要な点数ごとに、主張、出典、確認日、確認者を記録します。「提案書で確認」「デモで観察」「顧客リファレンス」「未回答」などのラベルを使います。別の顧客での成功は関係性を示すだけで同じ結果を保証しないため、規模、体制、連携の違いも注記します。
提案には条件と担当者を付けます。例えば、サービス範囲を確認し導入費を解決したうえで限定的なパイロットを勧める、という形です。会議では承認、却下、追加根拠の要求のいずれかを記録できます。
判断を中心にスライドを並べる
短いレビュー資料は、判断と提案、要件と対象外、比較可能なコスト前提、加重結果、決定的なトレードオフ、確認事項、次の行動の順にすると読みやすくなります。詳しい計算と出典は付録に移します。
一枚のスライドには一つの役割を持たせます。契約条件の違いは表、基準点の比較は棒、コストの感度はシナリオ表が適しています。大きな点数表、グラフ、長い説明を一枚に詰め込まないでください。
記録できる判断で終える
会議の成果は、承認、却下、または追加根拠の具体的な要求です。選んだ提案と同時に、受け入れたトレードオフも記録します。例えばサービスの根拠を得るために導入工数を受け入れたなら、実行する担当者にも見えるようにします。
共有前に、モデルを作っていない人へ「なぜこの提案なのか」を説明してもらいます。合計点しか繰り返せないなら、根拠とトレードオフの説明を補います。よい資料は判断を分かりやすくし、次の担当者が追える記録を残します。
感度を確認してから結論を出す
一つの評価を絶対的な真実として扱わず、議論のある評価を上下させて結果を確認します。順位が反転するなら、比較は確定ではなく、追加のデモ、契約確認、参照先への質問が必要な状態です。反転しない場合でも、どの仮定が結論を支えているかを明記します。
見積もりに含まれる範囲や数量が各社で違う場合、合計点の前に同じ条件にそろえた比較を示します。推定を使うときは、サプライヤーが確認した価格と分け、推定の理由と変更できる箇所を書きます。これにより、レビュー参加者は数字の出所と限界を追えます。
最後のスライドでは、採用する案、条件、未回答の質問、担当者、確認日を表にします。判断が保留なら、その理由と次に得る証拠を一行で示します。点数だけを残すのではなく、チームが次に動ける状態を作ることが評価プレゼンの目的です。
資料の冒頭には、選定する範囲、決裁者、期限、対象期間を置きます。契約の承認や未検証の展開までを、単なる選定の提案に混ぜないことが大切です。必須条件、比較基準、確認事項を最初から見せると、参加者は点数だけでなく判断の境界を確認できます。
出典一覧は付録に置いても、各点数の隣に短い参照を残します。提案書の記述、デモで観察した結果、契約に書かれた条件、顧客への確認は、それぞれ別の問いに答えます。根拠の種類を混ぜないことで、聞き手はどの点を追加確認すべきかを判断できます。
推薦が一つに決まらない場合も、失敗ではありません。二つの選択肢が現在の情報では同等であること、差を決める根拠、次に検証すべき項目を明記すれば、チームは安全にパイロットへ進めます。
数値や評価方法は、閲覧者が会議後に再計算できる程度に説明します。尺度、重み、対象期間、未回答の扱いを脚注または付録に残してください。原データの更新で結論が変わったときは、スライドの日付を更新し、以前の判断と新しい判断の違いを記録します。
各スライドのタイトルは判断の問いとして書き、表の列見出しには単位と期間を入れます。専門用語を使う場合は最初に短く定義します。これだけで、同じ資料を初めて読む人でも比較の条件と不確実な部分を確認できます。
会議で質問された点は、判断ログに戻し、採用理由と除外した案を残します。後から同じ比較を繰り返すとき、前提を変えたのか、証拠が増えたのかを区別できます。
提示した点数は、あくまで基準日時点の判断材料です。契約条件、実証結果、参照先の確認が変われば、推薦も見直します。この前提を最後に示すことで、数字を将来の保証と誤解されにくくなります。
更新日と評価者も表紙の近くに記載します。
こうすれば、結論だけでなく根拠と次の検証が共有されます。
この確認を次の選定会議の準備項目にも反映します。
全員が同じ前提を参照できます。
