你在软件选型流程中使用了POC吗？

作者：Robert Rudd 唐冬静 编译

欢迎访问e展厅 展厅 1 企业资源计划ERP展厅 企业资源计划ERP, 供应链管理SCM, 客户关系管理CRM... 一些研究表明，ERP、CRM实施失败的比例比较高。当然失败的原因比较多，但选型阶段被认为是出现问题的一个关键环节。本文从POC是如何适合软件选型流程、使用POC时体系的可变性、从客户和VAR视角来看POC的优缺点等方面进行了较为深入的探讨。为广大企业的软件选型推荐了一种较为适用的新方法。 1、前 言 一些研究表明，企业资源计划（ERP）和客户关系管理（CRM）实施失败的比例比较高。当然失败的原因比较多，但选型阶段被认为是出现问题的一个关键环节。 为了解决这些问题，在选型过程中，有时采用对观点提供证据（POC，Proof of Concept）这种方法。软件供应商和增值代理商（VAR）在咨询业务中经常使用POC。POC的目的是，在投资比较大的软件项目选型时较好地确定目标、适合的功能、客户化水平、资源和项目时间表。 关于POC有许多不同的说法，包括执行计划研究（IPS）、执行前期研究、售前评审、诊断等等。对POC来说，不同的定义有时反映了不同的流程结构。本文将深入探讨POC是如何适合软件选择流程，使用POC时结构的可变性，从客户和VAR视角来看POC的优缺点。 2、POC流程适用于软件的选型吗？ 一个软件选择的流程往往由以下环节组成： * 企业发展的环境是选型和成功的关键因素 * 软件供应商和VAR响应客户的需求决心和需求建议书（RFP） * 根据对RFP的响应，挑选出进入最后一轮候选名单的软件供应商或VAR * 解决方案的成功案例 * 筛选出首选的软件供应商、VAR和软件解决方案 * 商业谈判的条款和发出采购单 POC流程应该在确定出首选的软件供应商、VAR和软件方案之后启动，不能仅仅将POC流程视为两个解决方案比较的一种工具，它是主要的保证手段。此外，由于POC是指导解决方案和实施方案选型的方法，两个软件解决方案或VAR选型时，其POC就不能简单照搬。我们应该将POC用于评价首选供应商的状况，而不是仅仅建立POC流程。 3、POC的体系 POC的商业体系有一列变数，包括： * 软件订单在什么时候需要？ * POC是收费的咨询吗？ * 如果POC是收费的，那它是固定价格，按时间计费，还是按材料计费呢？ POC有许多不同的商业体系。这些体系有一个共同协议就是在POC之前或之后要完成专业性劳务服务、软件许可和支持。如果是在POC之前完成，那么一旦POC完成，合同就算执行完毕，如果是在POC之后完成，就要在POC的结束之前必须全部履行完合同。 4、POC的长度 POC的时间长短取决于流程的深度和签订的文件。POC的时间范围可以是从一个星期（或更少）到一个月。POC流程如果扩展到有争议的销售流程，当事人双方都拥有需求文件，其中包含的要素有识别客户化、项目团队和高质量地评估主要任务。 POC的完成体现在项目的全部分析和设计阶段。POC需要更多的调查去获得更多的表单。POC文件在流程方面将由以下部分组成：项目的详细目标、成功的关键因素、投资回报率分析、基础需求、主要定制开发的确认、高水平设计与项目详细计划的集成。 POC的时间长短将主要取决于项目协作的风险。POC流程越长，项目风险越大。 5、销售和咨询实践 售前或售后顾问都可以运用POC，售前顾问可以帮助销售小组或没有完成任务的销售代表。如果售前顾问完成了POC，那POC就成为销售流程的延伸。 售后顾问的主要精力是负责软件实施。他们注重获得产品的深层知识，而售前顾问更趋向于获得更广泛的知识，而没有实施所需的深层知识。因此，在POC流程，客户应坚持使用售后顾问。 无论是售前或售后顾问实施POC，如果是在许可、专业服务和支持合同完成之前执行POC，对供应商或VAR来说，POC流程会成为销售流程的剩余部分。在这种情况下，客户应该注意采取一些措施防止此类情况的发生，而不是更多地去关注严格的分析和设计流程。此外，因为销售始终是要冒风险的，售后环境下，参与的软件供应商或VAR与售前时相比，显得更不愿实话实说。 6、采用POC的理由 据介绍，POC是可以克服传统选型流程的以下缺点： * 夸张的或不切实际的期望值 一旦有商业机会去投资一个新的系统，人们就会对预期产生许多兴奋，期望改进当前业务流程。一些不切实际或夸张的期望就会在员工和管理者中间产生，这应归究于来自于软件供应商和一般报刊所提供的市场资料中所宣传的技术先进性。如果这些期待不能和供应商达成一致，期望的错位会导致项目失败。POC试图使项目目标和期望一致，必需努力执行更多的详细预算去完成项目。 * 缺乏主人翁意识 在项目初始阶段形成的管理责任者和决策工作小组对项目的全面成功是至关重要的。评估流程往往是由项目的核心团队进行管理，以限定对企业的影响，并保证流程不瘫痪。POC建立于各级管理责任者和职员相互沟通的基础之上，他们接收过这个流程的咨询。 * 卖空和功能缺口的辨认 作为咨询实践，当销售人员没按流程销售时，POC能把卖空行为减到最少。卖空是由于销售人员缺乏产品知识和责任心所引起的。 POC限制卖空、辨认功能缺口表现在： * 顾问比销售团队拥有更深层的产品知识 * POC提供了识别可能出现的产品功能缺口的方法 * 顾问对签订的合约负有责任 7、对客户而言，使用POC的好处和不足 对于客户而言，使用POC的好处主要有： * 预期效果和供应商保持一致 * 在选型过程中增加主动权 * 识别功能缺口或卖空的功能 * 更好地理解投资需求。更好地理解完成实施所需的投资需求，以制定正确的目标。 * 评价合作伙伴。POC流程允许客户不但能评价软件，也能评价合作伙伴。 当然，也应当注意POC是存在一定局限性的。主要包括： 业务的机动性。正因为一些POC方案存在机动性，客户可能很少真正应用购买的软件，尽管在时间和金钱方面已经作了重要的投资。甚至于，客户可能被说服在没有评估完所有解决方案就引进POC，因为在他们的脑海中已经形成了POC选型的低风险性这个认识。 销售实践。按照地方商业协议，POC可应用于销售活动的生命周期中，因此其揭发供应商的能力就受到限制。此外，在POC过程里产生的文档可能包含不能给项目增加价值的行销内容。 8、对供应商而言，使用POC的好处和不足 对于供应商而言， 使用POC的好处主要有： * 在销售过程中赢得有竞争性的挤入机会。POC是销售工具包中的另一个工具，在客户还没有正式许诺时，POC经常被用于推动下一步销售活动的挺进。 * 更好地选型，客户更满意。对于所有增值代理商（VAR）和软件供应商来说，成功的关键因素是拥有能准备按照设定的参考方法去行动的客户。任何用于提高客户满意度的方法都要检查。 对供应商而言，不利的方面有： * 销售的时机把握方面，POC能延长销售过程，而且时机把握（对于上市公司而言是重要的）就变得更加不可预测，使前景大打折扣。 * 对咨询资源的要求方面，因为POC的特性，要求广泛的咨询资源，代表性的就是需要更多的高级顾问，以确保POC获得更多的订单。 9、什么时候应该结束POC呢？ 当项目失败的风险比较高时，作为选型流程一部分的POC就应该结束了。风险可以用两个关键变量进行度量：需求的复杂度、选型和实施团队的专业技术水平。系统需求越复杂，从POC中获得的收益就越大。复杂度可以通过实施模块的数量、特性，客户化的数量，接口数量，数据转换的数量和质量来测定。 增加实施模块的数量（例如，单一财务模块的实施与财务、分销、仓库这些模块的实施相比）就扩大了实施的范围，也就加大了风险。此外，将要实施模块的自身特性也对风险有影响。例如，客户关系管理（CRM）套件的销售力量自动化模块（SFA）的潜在风险就远比像收款一类的财务模块的要高。 选型/实施团队的专业技术水平也是一项重要的指标。需要考虑的因素包括： * 行业知识 * 现有业务流程的知识 * 对高价值软件选型流程的理解 * 软件供应商管理的知识 * ERP/CRM系统的知识 这些因素经常应用于测量你们团队的专业技术水平。团队的专业水平越高，越能减少项目的风险。 下图说明了这些因素，以及如何评定选型过程是否需要POC。 (end)

文章内容仅供参考 (投稿) (1/26/2005)