提案されたシステムが本当に正しいものか、知る必要がありますか？
資金を投じる前の、アーキテクチャ、コスト、ベンダー提案のレビュー。独立した立場で、具体的に、文書の形で。
課題
自信に満ちたアーキテクチャ図、価格、スケジュールを添えた提案が届き、承認すべき人たちはそれが正しいかどうか判断できません。ベンダーは嘘をついていませんが、自分が答えられる問いに答えているだけです。よくある結果は、課題の3倍の規模のシステム、事業が成長した途端に高くなるライセンスモデル、難しい部分は後で対処すると暗黙に前提する設計です。
取り組み方
提案を、抽象的なベストプラクティスに照らすのではなく、それが解決すべき問題に照らして読みます。数字を確認します。ユーザー数、データ、スループット、五年間のコスト。書かれていない前提を確認します。何かが間違っていれば、何がなぜ間違っていて、代わりに何を求めるべきかを伝えます。提案が良ければ、それも伝えます。価値は欠点探しではなく、明確な答えにあります。
事例
見積もりを検討し、範囲を半分に
ある物流会社は、五年間で40拠点向けに価格設定された倉庫管理システムの提案を持っていました。拠点は六つで、残りについて具体的な計画はありませんでした。私たちはアーキテクチャとライセンス条件をレビューし、コストの三分の二が契約終了までに使わない容量を買っていること、そして本当に重要な部分である会計システムとの連携が、価格のない後続フェーズとして記載されていることを見つけました。見直した範囲は六拠点を対象とし、連携を最初に価格付けし、拡張の選択肢を残しました。ベンダーは同じままでした。契約はおよそ半分の規模になりました。
納品物
- あなたの実際の課題と数字に照らした、提案書の文書による検討結果
- 具体的なリスク、欠落、価格付けされていない前提の一覧
- ベンダーに持ち帰るための具体的な質問と変更点
- 行動に移せる推奨。提案どおり進めるべきという結論も含めて