目次

------------------------------------------------
第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時代を切り拓く