ERP需求采集

lynn.yu

作者：Richard Cushing


这些年来，人们不断提及——无法评估客户的真正需求才是企业中，或整个供应链里部署新技术失败的主要原因。当然了，关键问题在于部署新技术时，对“失败”和“成功”的定义，不是吗？


思考


如果“项目成功”被定义为：项目部署按时完成、没有超过预算，并且达到了质量预期，这时阻碍项目成功的因素是什么呢？


有时候是技术上的问题。但是，根据我的经验，更为普遍，同时也更让人头疼和难以避免的原因是，新技术的“客户”（也就是用户）埋怨称最终结果与自己的期望值不相符。情况往往因为这种抱怨而加剧：“我们压根用不了这个功能！”


很多时候，人们的期望往往是针对界面外观、视觉感或功能问题；要点击几次鼠标才能执行这些任务或查找到那些数据；获取某份数据的难度有多高（尤其是和当前所使用技术的对比）。





这种不满很大程度上是源于在项目早期的一个流程中，无意识产生的一种期望定向。这一流程被称为“项目采集”。


项目采集毫无章法可循


维基百科中，“商业需求”被定义为：用商业术语描述的，必须交付或实现，用以创造价值的需求。（Wikipedia.org 2007）


不幸的是，当今很多技术项目中，所谓的“需求采集”结果几乎与“商业需求”毫无瓜葛。东拼西凑的“需求清单”通常只列出了不同员工在当前应用中习惯使用的一系列功能，与提供商业价值没有丝毫联系。其他内容也只是当前用户提供的锦上添花的愿望清单。


一些功能可能确实极为重要，在过渡过程中不可丢失，这无疑是正确的。


然而，如果先入为主地认为，用户对新功能的概念——就如他们在“需求文档”里所表述的那样——就是新技术将（或应该）拥有的实际功能，那么这很有可能让一些人在使用到新技术时大失所望。


转换企业难题


员工的难处通常不会得到合理的表达。要花时间把员工的痛点转变为商业价值，或者企业所缺乏的价值。以下是一些实例：





写下这些痛处所在，“增值”内容就浮出水面了。


“商业需求”应该是什么样


真实、有效的商业需求——也就是能够创造实际商业价值，带来快速的投资回报的需求，我们认为应该是这样的：





创建这类“商业需求”能够使标准更高，更容易衡量，使加值型经销商和技术供应商更容易达到标准。产品演示成为了概念验证的一种通用方法，如果您从供应商那里购买了技术，他们是不能照搬自己的“经验法则”，套用在您企业的成功之道上的。


不仅如此，创建“商业需求”清单还意味着，跨职能“技术选择团队”能够专注于重要的商业成果，而不是需要哪些模块、外观如何，或者点击几次鼠标这种无关痛痒的问题。这才是能够带来实际和快速的投资回报（ROI）的思维方式。