“选择企业软件时面临的挑战”白皮书

本白皮书是我们的“一线快报”系列文章的一部分。 文中介绍了企业实施系统需要做出怎样的调整和演进才能取得成功。

如要下载本白皮书的 Word 版本,请参阅选择企业软件的挑战

若要阅读更多白皮书,请参阅“一线快报”白皮书

选择企业软件的挑战

这样的故事每天都在发生。 一位客户向办公室发了一份招标书 (RFP),说明应在几天或者一周内填写完成并予以发回,只有这样才能考虑购买我们的企业系统。 RFP 总是大同小异。 其内容通常为简要描述,说明您需要采取怎样的措施才能保证客户考虑您的答复,包括需要如何设置格式以及何时发回 RFP。此外,其中还包含详尽的必要功能表格和一系列需要答复的具体问题。

RFP 的挑战在于:它们通常并不适合用于选择企业软件,遵循 RFP 流程无法保证组织做出最佳选择。 RFP 由专门负责采购的人群设计,旨在以最优惠的价格获得最优质的商品,从这种意义上来讲,RFP 效果卓然。 如果产品或服务水准相当,决策过程可以专注于选择最优惠的价格,外加一两种其他变量(例如发货日期)。 如果可能的解决方案属于大致相同的类别,但并非完全相当(企业软件就是如此),那么采购人员必须要综合考虑大量变量,RFP 流程也就无法给选择流程增加任何价值。 大多数企业选择企业软件的方式 我们首先来看看所有企业软件供应商或解决方案提供商始终都要面临的情况。 我将探讨我所在公司提供的企业项目管理软件或企业时间表软件,但这种模式适用于选择几乎所有企业系统。

大多数企业选择企业软件的方式

我们首先来看看所有企业软件供应商或解决方案提供商始终都要面临的情况。 我将探讨我所在公司提供的企业项目管理软件或企业时间表软件,但这种模式适用于选择几乎所有企业系统。

在大多数组织中,寻找企业软件的动机都源自某些问题。 或许是现场人员提出的问题。 或许是高级管理层中某些人员发现的问题。 无论最初如何发生,下一步的行动总是争得某些高管的支持。 即便在最先进的组织中,基层选择能够影响整个企业的系统也无异于不切实际的童话故事。 “我们需要这类企业系统” - 这样的决策只能由高管制定。

典型企业软件的选择流程如下:

  1. 管理层表示我们需要新的企业系统

  2. 选拔项目经理

  3. 向所有相关部门征集要求

  4. 将所有要求整合为一个大的电子表格

  5. 将要求表格发送给大量供应商

  6. 获得大量回复

  7. 精简名单

  8. 观看演示

  9. 协商

  10. 获得管理层的认可

  11. 由管理层做出其他方面的决策

负责选择过程的项目经理完全靠毛遂自荐。 项目经理的工作方法没有什么新鲜之处 - 访问互联网、载入搜索引擎,然后在其中输入“EPM 软件”(或者所需的其他任何企业系统)。 然后就会获得数百万条的高点击量搜索结果。 勤勉的项目经理或许会在继续下一步行动之前浏览排名靠前的一些搜索结果,了解究竟有哪些类型的系统可用。 毫无疑问,没人有足够的时间浏览数百万条甚至更多的结果以确保不漏掉最适合组织的理想系统。

接下来,项目经理会组建起一支选择委员会,成员来自受此新企业系统实施影响的部门。 部分委员会成员可能是组织中最先发现相关需求的现场工作人员。 还有其他一些人员。 选择委员会的成员多种多样,感兴趣的系统类型各有不同。

接下来,不幸的项目经理需要恳求每一名委员会成员,以便对其代表群体进行投票调查,从而了解这些用户希望新企业系统提供的功能。 各委员会代表要如何完成这项任务? 首先,并非所有人都会投入同样多的努力,但那些勤奋地做了背景调查的人会要求其组织员工提交一份重要功能清单。 随后,他们也会上网去浏览一些供应商网站。 他们可能会复制粘贴这些网站的手册中的某些功能,每个网站都能帮助他们产生新的灵感,发现可以对新系统提出的要求。

在委员会成员再度碰面时,每一位成员都会呈交一份长长的电子表格,所有成员的电子表格汇总在一起形成一个庞大的表格。 包含各种要求的超大电子表格将会分类整理,但这里同样存在挑战。 首先,由于功能要求来自多种不同视角,委员会成员需求的多样性会进一步显现出来。 委员会中可能包括来自不同部门、不同国家/地区甚至是不同分公司的成员。 同一份清单中几乎总是存在相互冲突的要求(例如,系统应该极度简单易用,不必有过多提示;系统应该高度灵活,为每一位用户提供大量的定制选项)。

最后,供应商将看到整合后的最终版电子表格。 其中包含数百项功能要求,每项功能要求都需要供应商做出“可以实现”、“不能实现”或是“可以实现,但有点麻烦”这样的答复。 此外还可能有权重系统,表示功能是“必需”、“重要”还是“锦上添花”。

功能选择电子表格的代码段

到这里,RFP 基本就完成了。 此外还可能有一些具体问题,通常与选择的技术体系结构相关,根据投票选出这些要求的人数不同,这些要求也可能存在冲突(例如,“系统必须将所有数据集中存储在 SQL Server 数据库内”与“系统必须允许用户将任何数据存储在本地计算机上”。)

到现在为止,一切看起来似乎都井然有序,对吗? 最后,我们将收到大量供应商答复,表明谁可以提供我们需要的全部功能。 到现在为止,一切看起来似乎都井然有序,对吗? 最后,我们将收到大量供应商答复,表明谁可以提供我们需要的全部功能。

然而,我之前描述的过程存在一个根本性的问题:在使用 RFP 商品采购流程(而非适用于企业系统的流程)时无法轻易发现的问题。 那就是:企业系统是一种应对某些问题的解决方案。 但 到现在为止,我们完全没有提到过问题本身。 这是技术行业内已经公认存在并接受的现状。

为什么这种方法不适合用于选择企业软件

数十年来,采购人员一直在采用这种方法,没有人提出过质疑,但企业软件从业人员深知,运用传统 RFP 方法选择企业软件会产生一个根本性的问题。

首先,庞大漫长的功能清单不一定代表就能解决业务问题。 如果您从未明确表述究竟要解决怎样的具体业务问题,那么就有可能导致情况进一步复杂化,一切只会朝着更糟糕的方向发展,对问题解决毫无帮助。 RFP 流程专门为商品采购而设计。 如果有大量同质产品,比如鞋子、土豆或是白糖,通过这种方式采购商品能找到成本最低的出价者,从而在诸多备选供应商之间选择最理想的一家。 对于类似商品的 RFP 答复让采购人员可以易如反掌地比较供应商。 如果涉及到的每种产品都有着无穷无尽的变量(企业软件就是如此),那么 RFP 答复也就有着无限种变量,整个流程能带来的价值屈指可数。

使用 RFP 流程选择企业系统时,RFP 几乎总是大同小异。 这是因为它们都是为响应相同的动机而制作的。 项目经理要求各部门提供“企业系统需求”清单,而大多数中层经理只能通过功能列表的形式做出答复。 结果造成 RFP 的答复大同小异。 它们通常是系统中包含的功能或经过一定努力后可以纳入系统的功能组成的核对清单。

选择团队中最常见的情况就是收到大量的 RFP 回复,浏览数百页的文件,但在浏览完成后,他们往往感到毫无进展,对解决方案仍无头绪。 采购人员投入了大量心血,力图制作一份公平的招标书以便评估答复,但结果发现一切只是徒劳无功,这让他们无比沮丧。

最糟糕的是,经验老道的企业销售人员深知这种流程只会产生令人沮丧的结果,因此他们从听闻制作 RFP 这一消息的时刻起便会自行开始行动。 他们不会浪费时间去浏览 RFP 答复。 那并不重要。 他们会背地里接洽管理层中级别高两到三级的主管,寻找最初发起 RFP 流程的源头。 他们会寻找那些提出业务挑战并启动相关工作、促使采购人员和其他中层管理员工制作 RFP 并发给供应商的高层管理者。

如果整个采购流程中从未阐明业务问题,而最终的 RFP 答复又没有给出明确的解决之道,企业销售人员就会暗地里采取行动,请求高层管理者绕过整个流程,根据自己与高级企业销售人员之间的私人关系选择一种系统。

您或许认为这听起来就让人厌倦,但您错了。 如果出现这种情况,还不如彻底简化流程,直接根据高管层的私人关系选择软件,而不必经手 RFP 流程。

概念验证或试点方法又如何?

我们都已经了解,传统采购流程用于企业软件采购时存在缺陷。 在这种情况下,应该如何选择企业软件,例如企业项目管理系统? 一种流行的方法是利用概念验证或试点阶段方法。

这两个术语 往往视为同义,因此我们首先来看看什么是概念验证或试点部署。

概念验证   。 如果组织对解决方案克服挑战的能力存在疑虑,那么就会采用概念验证方法,此时作为潜在客户的组织以受限的方式部署企业软件,以便验证它确实能解决某种技术挑战。 数据量挑战就是一个例子。 “我们担心这种产品无法处理我们项目中的大量任务。 因此我们想请您用这款软件实施两到三个试点项目,每个项目分配 500 个任务,为我们展示一下如何将这些任务载入到软件中,以及软件在加载如此之多的数据量之后是否仍然能正常履行基本功能。”

试点阶段   。 试点阶段就是在受限的范围内安装企业软件。 试点部署可能面向一小组用户,例如总共有 1000 名用户,但仅选出 10 名用户参与试点,在四周时间内完整体验该软件。 试点部署也可能面向一小部分功能或数据量,例如总共有 500 个项目,但仅载入 10 个项目。

概念验证或试点阶段的运用方法    最常见的问题就是试点阶段或概念验证的运用方法。 作为潜在客户的组织很少会联系我们以征求概念验证建议或是确定需要验证的技术概念。 我们会问:“您希望证明什么?我们应通过怎样的度量指标表示我们已经完成了证明?”

最常见的情况是中层管理人员选出他们希望能解决组织问题的企业软件。 高级管理层完全不会参与其中,中层管理员工甚至不会说明他们要解决怎样的业务挑战。 他们只是希望,如果解决方案开始构建,下次某位高管在办公区中会“碰巧”看到解决方案已经正常运转,那么他们立刻会对企业所作的部署给予祝福。 借用电影《梦幻之地》中的一句台词:“只要动手去做,梦想终会实现。”

无效的试验阶段选择

但成功往往无法如此轻易到来。 企业软件的问题在于需要高管层参与其中,只有这样才能保证部署成功。 高管层将是这种企业系统生成的报告和分析的最终“客户”。 高管层必须亲身参与,给员工留出设计、配置企业软件和接受相关培训的时间。 高管层必须验收甚至是协助改造企业系统部署中涉及到的业务流程。 如果高管层不能亲力亲为,提供幕后支持和直接援助,概念认证将毫无价值。

这一点同样适用于试点阶段。 如果公司的最高管理层没有亲身投入到利用企业软件解决某些业务问题的过程当中,试点阶段也无益于提高生产力。

有效的试验阶段选择

这并不是说,部署的试点阶段并无意义。 试点对于部署的成功确实意义重大。 试点的意义体现在刚刚制定购买决策、完成企业系统设计之后。 此时,试点阶段能够很好地检验企业系统的设计,便于我们加以完善调优,有益于整体部署。

如果试点阶段的目的只是希望实际运行软件,吸引管理层做出选择, 那么可以说试点阶段效率低下,对于选择流程毫无促进作用。

组织应如何选择企业软件?

大型和中型组织每天都在购买企业系统,RFP 方法并非最有效的方法,还有其他一些非常有效的企业软件选择方法。 下面给出了一些帮助您自行确立有效的企业选择流程的提示。

  • 阐明问题   。 第一件事也是最重要的一件事就是阐明问题。 这表示高管层必须亲身参与,此外,由于需要阐明的问题属于业务问题,因此必须用业务术语加以说明。 适合在此时提出的一个好问题就是:“在我们目前无法制定或是只有克服极大的阻力后才能制定的决策中,哪些决策的制定会在部署此企业系统解决方案后得到简化?”

    您可能希望利用企业系统解决一系列的业务挑战。

  • 向供应商提出创建解决方案的某些限制   。 在阐明业务问题之后,应与候选供应商取得联系,务必保证与协助此流程的高管的接触公开透明。 如果管理层从最初起就参与到流程之中,供应商与高管层的“秘密”会议将不再可行。 保证供应商理解问题,并对他们的答复做出一些限制规定。 在解释这些业务挑战对您产生的影响时,您会对组织产生更透彻的认识;此外,由于直接提出问题,而不是费尽心力地向潜在供应商描绘自己心目中理想的解决方案,您将看到适合解决问题的、更广泛的可行解决方案。

    在与潜在解决方案提供商沟通时,务必保证他们充分认识到:他们必须要同时考虑技术和业务流程挑战。 没有一种企业系统解决方案对组织流程毫无影响。 如果解决方案提供商无法帮助您解决影响流程的问题,那么就表示您对于解决方案的考虑并不全面。

  • 与其他客户沟通   。 在确定了少数几家潜在解决方案提供商之后,您可以要求与他们的某些现有客户沟通。 最好能问问供应商能否安排您拜访其某些现有客户。 优秀的解决方案提供商往往有许多客户在部署中取得了成功,而且慷慨大度,愿意抽出时间与提供商的潜在客户会面。

    花上几个小时与潜在解决方案的老客户沟通,这将给您带来更丰富的信息,这是单凭阅读 RFP 答复或者观看供应商的销售演示所无法企及的。 询问供应商能否安排客户推介和现场访问时,您可能认为最理想的会面对象是与您的公司相似的其他公司。 但事实并非总是如此。

与其他行业中与您的公司相关或有某些相似之处的公司会面常常极有价值。 规模更大或更小的组织也能给您提供许多宝贵信息。 您应该更注重对应组织在解决方案使用方面的经验深度,而非他们使用的具体版本,也非他们是否与您处于相同行业、属于相同规模。

如果您有幸获得拜访现有客户的机会,切记他们不是供应商。 您应该保持尊重、礼貌、感激的态度。 最好带上一些小礼物,或许还可以带一些印着公司徽标的促销材料。 与这些组织会面或是通过电话沟通时,可以提出像下面这样的问题:

  1. 您当初通过怎样的流程从各种可行解决方案中选出了这种解决方案?

  2. 这种解决方案 对您的业务流程产生了哪些影响?

  3. 在部署工作中,最困难的方面是什么?

  4. 至此为止,这项投资给您带来的最有价值的回报是什么?

  5. 您如何看待这种解决方案此后的发展?

不要指望只获得正面的答案。

与拥有大量满意客户的供应商相比,对于完全无法提供客户推介的供应商必须保持质疑态度。

最后,在敲定选择后,应该选择分阶段部署。 您可以在本专栏中找到对比分阶段部署与 一次性大规模部署的文章。 分阶段部署可以降低企业系统部署的风险,有助于随着系统演进不断完善部署流程。

切记,任何企业系统部署都是一个动态变化的过程, 绝不是只需一次性决策,然后每个月都能提供理想成果的过程。 最成功的企业部署往往以这样的格局开场:将会参与部署流程的重要人员共同选择产品,包括最高层的管理人员,以及最有战术意义的现场工作人员;随后按照条理分明的阶段式方法不断演进系统。

切实有效的企业系统选择只是整个流程的第一阶段。

关于作者

Chris Vandersluis 是加拿大蒙特利尔的 HMS Software(Microsoft 认证合作伙伴)的总裁及创始人。 他拥有 McGill 大学的经济学学位,在项目控制系统自动化领域有着三十余年的丰富经验。 他是项目管理委员会 (PMI) 的长期成员,帮助创办了 Microsoft Project 用户组 (MPUG) 的蒙特利尔、多伦多和魁北克分会。 Chris 撰文的期刊包括《财富》、《Heavy Construction News》、《Computing Canada》杂志和 PMI 的 PMNetwork,他也是《Project Times》的专栏作者。 他在 McGill 大学讲授高级项目管理课程,经常在北美和全球各地发表有关项目管理联盟职能的演讲。 HMS Software 是面向项目的时间记录系统 TimeControl 的发布商,自 1995 年起成为 Microsoft Project 解决方案合作伙伴。

可以通过电子邮件联络 Chris Vandersluis:chris.vandersluis@hms.ca

如果您希望阅读 Chris Vandersluis 撰写的更多 EPM 相关文章,请访问 HMS 的 EPM Guidance 网站 (http://www.epmguidance.com/?page_id=39)。

扩展你的技能
了解培训
抢先获得新功能
加入 Office 预览体验计划

此信息是否有帮助?

谢谢您的反馈!

谢谢你的反馈! 可能需要转接到 Office 支持专员。

×