你是否需要知道，报价给你的系统是不是正确的那个？
在资金投入之前，对架构、成本和供应商方案进行评审。独立、具体、落在纸面上。
问题
一份方案到来，带着自信的架构图、一个价格和一份时间表，而必须批准它的人分辨不出它是否正确。供应商没有撒谎，但他们回答的是自己知道怎么回答的问题。常见结果是：一个比问题大三倍的系统，一个恰好在业务增长时变贵的许可模式，或者一个悄悄假设困难部分以后再处理的设计。
我们的做法
我们对照方案本应解决的问题来读它，而不是对照抽象的最佳实践。我们核对数字：用户、数据、吞吐量、五年的成本。我们核对那些没有写下来的假设。哪里有错，我们就说出错在哪里、为什么错，以及应该改要什么。方案好，我们也照实说。价值在于一个清楚的答案，而不在于挑毛病。
实际案例
审查一份报价，范围减半
一家物流公司拿到一份仓库管理系统的方案，按五年内 40 个站点定价。他们有六个站点，其余的没有具体计划。我们评审了架构和许可条款，发现三分之二的成本买的是他们在合同结束前都用不上的容量，而真正要紧的部分，也就是与他们财务系统的集成，被列为没有报价的后续阶段。修订后的范围覆盖六个站点，先给集成定价，并保留扩展的选项。供应商没变。合同大约缩小了一半。
你将得到
- 对照你的实际问题和数字，对方案的书面审查
- 一份具体的风险、缺口和未定价假设的清单
- 可以带回给供应商的具体问题和修改要求
- 一份可以据以行动的建议，包括建议按报价原样推进的情况