发表于：2016年1月20日
作者：Richard Cushing
这些年来，人们不断提及——无法评估客户的真正需求才是企业中，或整个供应链里部署新技术失败的主要原因。当然了，关键问题在于部署新技术时，对“失败”和“成功”的定义，不是吗？
思考
如果“项目成功”被定义为：项目部署按时完成、没有超过预算，并且达到了质量预期，这时阻碍项目成功的因素是什么呢？
有时候是技术上的问题。但是，根据我的经验，更为普遍，同时也更让人头疼和难以避免的原因是，新技术的“客户”（也就是用户）埋怨称最终结果与自己的期望值不相符。情况往往因为这种抱怨而加剧：“我们压根用不了这个功能！”
很多时候，人们的期望往往是针对界面外观、视觉感或功能问题；要点击几次鼠标才能执行这些任务或查找到那些数据；获取某份数据的难度有多高（尤其是和当前所使用技术的对比）。
这种不满很大程度上是源于在项目早期的一个流程中，无意识产生的一种期望定向。这一流程被称为“项目采集”。
项目采集毫无章法可循
维基百科中，“商业需求”被定义为：用商业术语描述的，必须交付或实现，用以创造价值的需求。（Wikipedia.org 2007）
不幸的是，当今很多技术项目中，所谓的“需求采集”结果几乎与“商业需求”毫无瓜葛。东拼西凑的“需求清单”通常只列出了不同员工在当前应用中习惯使用的一系列功能，与提供商业价值没有丝毫联系。其他内容也只是当前用户提供的锦上添花的愿望清单。
一些功能可能确实极为重要，在过渡过程中不可丢失，这无疑是正确的。
然而，如果先入为主地认为，用户对新功能的概念——就如他们在“需求文档”里所表述的那样——就是新技术将（或应该）拥有的实际功能，那么这很有可能让一些人在使用到新技术时大失所望。
转换企业难题
员工的难处通常不会得到合理的表达。要花时间把员工的痛点转变为商业价值，或者企业所缺乏的价值。以下是一些实例：
| 员工感受到的难处 | 转换表达 |
| 我们要能够从新软件里输入和输出数据。 | 需要能够以切实可用的方式输入和输出数据……能够把有意义的数据输出到报表数据库中。 |
| 我们要有灵活的会计科目表。 | 灵活的会计科目表，比如多个层次的账目。 |
| 我们要能够打印生产报告。 | 必须有生成生产报告的功能。 |
写下这些痛处所在，“增值”内容就浮出水面了。
“商业需求”应该是什么样
真实、有效的商业需求——也就是能够创造实际商业价值，带来快速的投资回报的需求，我们认为应该是这样的：
| 商业需求 | 需要交付的商业价值 |
| 实施供应链集成和可视性解决方案，在120天内不增加任何存货投资的情况下，把脱销的前20%库存量单位（按生产量排序）减少到不到5个/月。 | 产出量提高12.5%，9.5%（前9个月里）的增长来自于重新拿回可能损失的销量，剩下的3%（前6个月里）则是挽回了我们之前作为这些库存量单位供应商时，认为我们缺乏可靠度而丢失的客户。 |
| 实施商务智能（OLAP）解决方案，按照客户、销售人员、销售经理、大区、产品线、库存量单位和其他地域分类，为市场营销团队提供可视化销售数据，从而在按照细分市场（如有需要，细化到每一个客户）开发“不可拒绝的产品供给”时，建立有效的市场划分，以供使用。 | 增加产出量达22%（在12个月内），按照市场营销团队列出的估算和计划达成这一目标，无需增加运营成本。 |
| 减少库房里基于纸面的选货、包装和发运，并且要能够在平均每小时里准确挑选、包装和发运16个订单（约为117 条生产线），在不增加运营成本的前提下，支持产出量的提高。 | 保持运营成本不变，同时强化我们的库房发运功能，直至每小时16个订单，准确率超过99%。 |
创建这类“商业需求”能够使标准更高，更容易衡量，使加值型经销商和技术供应商更容易达到标准。产品演示成为了概念验证的一种通用方法，如果您从供应商那里购买了技术，他们是不能照搬自己的“经验法则”，套用在您企业的成功之道上的。
不仅如此，创建“商业需求”清单还意味着，跨职能“技术选择团队”能够专注于重要的商业成果，而不是需要哪些模块、外观如何，或者点击几次鼠标这种无关痛痒的问题。这才是能够带来实际和快速的投资回报（ROI）的思维方式。
