御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか（技術評論社） [電子書籍]

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか（技術評論社） の 商品概要

• 成長戦略という錦の御旗のもと，システム化やDX推進の指示が増大しています。しかし，あわててITプロジェクトを始動したあなたに，次の法則が立ちはだかります。「プロジェクトの半分以上が失敗する」。これは一体なぜでしょうか？　著者によれば，プロジェクトは「上流がにごれば，下流はもっとにごる」もの。ITベンダーが決まるまでの長い道のり「超上流」に問題のほとんどが集約されています。本書は，前著では触れることのできなかったこの問題に焦点を当て，ユーザー企業が安易な選択をしてしまうワナから説き起こします。そして，ベンダー選定の究極ノウハウ「ファネル選定」を提唱します。前著をお読みでない方も，本書を手引きにまずはこの最優先課題に取り組んでください。
  

• 目次

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

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか（技術評論社） の商品スペック