第1章　選定ミスは終わりの始まり

• DXを成功させる大前提は「選定」が正しいこと
  • DXをやりたいと言うが
  • ノウハウをためるべき部署
  • DXが機能するための前提
  • 計画とは順番を定義すること
  • レガシーシステムは諸悪の根源
  • 基幹システム選定の状況変化
  • パッケージ導入の落とし穴
  • スクラッチ開発という難題
  • 攻めのITは「けもの道」
  • あるAIプロジェクトの末路
  • 最新技術が正解とはかぎらない
  • すべては「選定」にかかっている
• ロックイン問題は「選定」の結果である
  • 現行ベンダーへの不満
  • ロックインの元凶
  • 何がリスクなのか
• プロジェクトの成否は「選定」で決まる
  • プロジェクトからのSOS
  • プロジェクトの成功要因
• COLUMN　ユーザーロックイン

第2章　選定に入る前に方向性を定める

• 「選定」のための地図を作る
  • 候補がありすぎると途中で探さなくなる
  • 選定プロセスは選定の前から始まっている
  • プロジェクト計画書のよりどころ
  • ボトムアップの問題
  • トップダウンの問題
  • トップダウン？　ボトムアップ？
  • 経営層と現場を味方にする
• パッケージかスクラッチか
  • 経営層のジレンマ
  • パッケージでいけるか見極める方法
  • 消去法を愚直に進める
  • グランドデザインで大きな地図を描く
  • ERPは最初しか選択肢がとれない
  • 手に持っているものがハンマーなら全て釘に見える
  • 「内製」という選択肢
  • グランドデザインは順番をデザインすること
• COLUMN　なぜそのRFPは10億円を超えてしまったのか

第3章　RFIでベンダーを広く浅く収集する

• RFIとは何か？
  • その選定プロセスは正しいと断言できるか？
  • ファネル選定とは
  • ファネル選定を成立させる重要な技術
  • RFIとRFPの違い
  • RFIの6つのメリット
• RFIの準備
  • RFIはこう作る
  • ベンダーは何社探せばいいのか？
  • ある出版業システムのリストアップ事例
  • インターネット検索での注意点
  • この時点での現行ベンダーの扱い
  • 現行ベンダーの可能性
• RFIの手続き
  • RFIでは会わない
  • RFIでは順位を決めるのではない
  • RFIのノックアウトファクター
  • 5社以内に絞りきる
• COLUMN　RFIは悲劇をくり返さないための仕組み
• トライアルで深掘りする
  • このまま進めてよいか現場の反応を見極める
  • トライアルとは
  • トライアルの目的
  • トライアルは何社で行うべきか
  • トライアルの考え方
  • トライアルが現場の主体性を引き出す
  • 状況をみながらトライアルの有無を判断する
• COLUMN　トライアルにお金を払ってもお釣りがくる

第4章　RFPで自社要求を明確にする

• RFPに取り組む姿勢
  • RFPはムズカシイ？
  • RFPを出さない理由がない
  • RFPのフォーマットは悩まない
  • 要求機能一覧はRFPの「心臓部」
• RFPで押さえるべきポイント
  • RFPの書き方が変わってきた
  • そのパッケージRFPの失敗は必然
  • パッケージRFPはベンダーにアイデアを求める
  • パッケージTo-Beを評価する
  • パッケージvsスクラッチという異種格闘技戦
  • RFPを市場にアジャストさせる
  • そもそもRFPは誰が作るべきか
  • IT部門の一番の強みとは
  • RFPにおけるIT部門の役割
• COLUMN　情シスロックイン
• RFPでベンダーに提案を依頼する
  • まずはお会いしたい
  • RFPの前にNDAを交わす
  • NDAのフォーマットはどちらに合わせるべきか？
  • ベンダーへの期限設定
  • ベンダーの質問には公平に対応する
• COLUMN　A社のパッケージングと金太郎アメ

第5章　ベンダーを評価し，選定する

• 提案書を自社のフレームで評価する
  • 提案の5大評価ポイント
  • スコアリングに責任を持つ
  • システム機能はサブシステム単位できっちり評価する
  • FIT率「60％」をどう考えるか
  • 費用は5年トータルで考える
  • 実績は数と質の両方をみる
  • プロジェクト計画は，ベンダーの力量をはかるモノサシ
  • その他の評価で補完し，バランスをとる
  • プレゼンテーションの前に評価を完成させる
• 提案書でみえない部分をプレゼンで評価する
  • プレゼンで特に確認しておきたいポイント
  • プロジェクトメンバーの当事者意識の醸成
  • プレゼンのアジェンダをベンダーに提示する
  • プロジェクトマネージャーにどんな質問をするか
  • その質疑応答は誰が答えているのか
  • ベンダーのエース人材を見分ける方法
  • 質問はバリエーションが大事
• COLUMN　ダメPMの見分け方　～なぜPMにこだわるのか～
• 最終選考
  • 進め方は3パターンに分かれる
  • 最後の最後に心理的な恐怖は大きくなる
  • 唯一の背中を押してくれる存在とは
  • 導入先という「希望」に会いに行く
  • 現状維持という最大のハードルを越えるために
  • 現行システムは現状のままではいられない
  • ちゃぶ台返しをさせない
  • プロジェクトマネージャーが責任をもって全社承認をとりつける
• COLUMN　圧倒的に安すぎると，人は選べなくなる
• 契約締結まで油断しない
  • ベンダー決定が遅れてしまう
  • ベンダー決定を遅らせるとどんな不都合が生じるのか
  • 発注するベンダーは決まったが決まっていない
  • 内定をだしても確定はださない

第6章　最適なベンダーとサービスは未来を明るくする

• 選定後のプロジェクト処方箋
  • 苦境のないプロジェクトはプロジェクトではない
  • ベンダーチェンジは有効なのか？
  • 対処方法①　ベンダーPMチェンジ
  • 対処方法②　ユーザーチェンジ
  • どのカードを切るのが正解なのか
• ベンダーは共に歩むパートナー
  • 最適なベンダーは黙っていても導いてくれる
  • ベンダーを信じるということ
  • 「ファネル選定」でDX時代を切り拓く