サプライヤー評価プレゼン：基準と根拠をそろえて比較する

よいサプライヤー評価は、単に順位を付けるだけではありません。どの基準を重く見たのか、どの根拠が確認済みで、何が未確認なのかを示します。構成にはプレゼンテーションのデータストーリー（英語）を使い、問い、確認できる事実、限定した提案の順に並べます。

選定理由、点数、条件を整理したら、Presentiのテキストからプレゼンテーションを作成する機能で、スライドの初稿にまとめられます。サプライヤーの評価はチームが行います。

判断する目的と範囲を決める

最初に、採用するのか、次の審査へ進めるのか、根拠不足で保留するのかを明記します。基準日、対象範囲、決裁者、期限、対象期間、譲れない要件も記録してください。各社の見積もりが同じ業務範囲を含む場合にだけ、公平に比較できます。

契約の承認や未検証の展開までを、単なる選定の提案に混ぜないことが大切です。

評価基準と根拠を集める

総コスト、納品能力、サービスレベル、品質、連携の手間など、判断を変える少数の基準に絞ります。提案書の主張と、実績、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のサービス評価を相殺しているため、二つの差を生む根拠とともに説明します。

この架空の例では、各点数に重みを小数で掛け、四つの値を足し合わせます。重みの合計は100％なので、合計点も1〜5の尺度で比較できます。計算の内訳は次のとおりです。

この例では、点数が高いほど有利な条件を表します。コストなら同じ条件で比較した費用が低いこと、導入なら進めやすいことです。点数そのものが金額や作業日数を表すわけではありません。

例えば、パイロットの結果を受けてBの導入評価が5から4に下がったとします。重みとほかの点数が変わらなければ、Bは1 × 0.25 = 0.25点を失い、3.65 − 0.25 = 3.40となります。Aは3.60のままなので、順位が逆転します。当初の0.05点差は、導入評価の1点を裏付ける根拠に左右されるということです。順位を確定する前に、パイロットでその根拠を確かめます。

争点の評価を1点変えるだけで結果が逆転するなら、パイロットやリファレンス確認などの追加検証を提案します。現在の情報では二つの選択肢が実質的に同等だと示すこともできます。

合計点を大きく左右する基準を少なくとも二つ示します。重みを妥当な範囲で変えたとき結論が変わるかも確認します。

順位が反転しない場合でも、どの仮定が結論を支えているかを明記します。

根拠を追跡可能にする

重要な点数ごとに、主張、出典、確認日、確認者を記録します。「提案書で確認」「デモで観察」「顧客リファレンス」「未回答」などのラベルを使います。別の顧客での成功は関係性を示すだけで同じ結果を保証しないため、規模、体制、連携の違いも注記します。

提案には条件と担当者を付けます。例えば、サービス範囲を確認し導入費を解決したうえで限定的なパイロットを勧める、という形です。会議では承認、却下、追加根拠の要求のいずれかを記録できます。

出典一覧は付録に置いても、各点数の隣に短い参照を残します。提案書の記述、デモで観察した結果、契約に書かれた条件、顧客への確認は、それぞれ別の問いに答えます。根拠の種類を混ぜないことで、聞き手はどの点を追加確認すべきかを判断できます。

数値や評価方法は、閲覧者が会議後に再計算できる程度に説明します。尺度、重み、対象期間、未回答の扱いを脚注または付録に残してください。原データの更新で結論が変わったときは、スライドの日付を更新し、以前の判断と新しい判断の違いを記録します。

更新日と評価者も表紙の近くに記載します。

不足を確認質問に変える

未確認の根拠や重みの大きい基準から、具体的な質問を作ります。SLAなら測定方法、例外、エスカレーションを、コストなら数量、契約期間、切り替え工数を尋ねます。各質問に担当者と期限を割り当てます。

判断を中心にスライドを並べる

1. 判断の問いと基準日
2. 比較可能な要件と対象外
3. 評価方法と重み
4. 結果と基準別の寄与
5. リスク、未確認の根拠、感度
6. 提案、確認事項、担当者

すべてのスライドで同じ尺度を使い、例示の数値には「例」と明記します。口頭説明がなくても検討できる形にしておくことが重要です。

詳しい計算と出典は付録に移します。

一枚のスライドには一つの役割を持たせます。契約条件の違いは表、基準点の比較は棒、コストの感度はシナリオ表が適しています。大きな点数表、グラフ、長い説明を一枚に詰め込まないでください。

各スライドのタイトルは判断の問いとして書き、表の列見出しには単位と期間を入れます。専門用語を使う場合は最初に短く定義します。これだけで、同じ資料を初めて読む人でも比較の条件と不確実な部分を確認できます。

記録できる判断で終える

会議の成果は、承認、却下、または追加根拠の具体的な要求です。選んだ提案と同時に、受け入れたトレードオフも記録します。例えばサービスの根拠を得るために導入工数を受け入れたなら、実行する担当者にも見えるようにします。

共有前に、モデルを作っていない人へ「なぜこの提案なのか」を説明してもらいます。合計点しか繰り返せないなら、根拠とトレードオフの説明を補います。よい資料は判断を分かりやすくし、次の担当者が追える記録を残します。

最後のスライドでは、採用する案、条件、未回答の質問、担当者、確認日を表にします。判断が保留なら、その理由と次に得る証拠を一行で示します。点数だけを残すのではなく、チームが次に動ける状態を作ることが評価プレゼンの目的です。

会議で質問された点は、判断ログに戻し、採用理由と除外した案を残します。後から同じ比較を繰り返すとき、前提を変えたのか、証拠が増えたのかを区別できます。

評価結果が示さないこと

点数は将来の成果を保証しません。選んだ方法と基準日時点の根拠を表しているだけです。最後のスライドで、提案、前提、今後確認する事実を分けて書きます。

契約条件、実証結果、参照先の確認が変われば、推薦も見直します。