选择企业软件的挑战

本文是我们的“从战壕”集合的一部分。 它介绍了企业系统实现需要如何能够适应和发展才能取得成功。

若要下载本文的Word版本,请参阅选择企业软件的挑战

若要查看更多文章,请参阅 “从战壕”白皮书

选择企业软件的挑战

它一直在这里发生。 客户将“建议请求” (RFP) 发送到办公室,并指示在几天或几周内完成响应,然后将其发送回,以便考虑购买我们的企业系统。 RFP 几乎看起来都一样。 通常有一个简短的概述,说明你需要做什么来考虑你的响应,包括需要如何设置格式以及何时发送回响应等。然后是一个长网格,需要特征和一些额外的论文问题来编写答案。

RFP 的挑战在于它们不适合选择企业软件,在遵循 RFP 流程时,随之而来的情况并不能保证为组织做出最佳决策。 RFP 是由采购界设计的,目的是以最好的价格获得最好的商品,他们仍然做得很好。 当产品/服务具有可比性时,决策过程可以专注于最佳价格,只需一两个附加变量 (,例如发货日期) 。 如果可能的解决方案属于同一常规类别,但与企业软件) 相比,根本不是可比 (,则购买者必须考虑的变量数量巨大,RFP 过程不会为选择增加价值。 大多数公司如何选择企业软件 让我们首先看看企业软件的任何供应商或解决方案提供商中一直发生的过程。 我将讨论企业项目管理软件或企业时间表软件,这是我的公司提供的内容,但范式几乎适用于任何企业系统选择。

大多数公司如何选择企业软件

让我们首先看看在任何企业软件供应商或解决方案提供商中一直发生的过程。 我将讨论企业项目管理软件或企业时间表软件,这是我的公司提供的内容,但范式几乎适用于任何企业系统选择。

在大多数组织中,寻找企业软件的动力来自一些问题。 也许问题是由现场人员浮出水面的。 也许问题是由高级管理层的人确定的。 但是,该计划必须得到高级管理层的支持。 基层选择一个将影响整个企业的制度,即使是最进步的组织也是一种幻想。 因此,一位高级经理决定,“我们需要这种企业制度。

典型的企业软件选择过程如下所示:

  1. 管理层说我们需要一个新的企业系统

  2. 已选择“项目经理”

  3. 向所有相关部门征求请求

  4. 将所有请求合并到一个大型电子表格中

  5. 将要求网格发送给许多供应商

  6. 获取大量响应

  7. 简短列表

  8. 观看演示

  9. 洽谈

  10. 获取管理验收

  11. 让管理层决定其他事情

选择工作的项目经理是自愿的。 他或她做我们都做的事 - 转到 Internet,加载搜索引擎,并键入“EPM 软件” (或任何所需的企业系统) 。 立即返回 50 万次命中。 也许勤奋的项目经理会浏览前十几个左右,以了解在继续操作之前可能可用的系统类型。 显然,没有人有时间浏览50万或更多的点击,看看最后一个是否是组织的理想系统。

项目经理现在毫不畏惧地从受这种新企业系统实施影响的人中组建了一个选拔委员会。 委员会中的一些人可能来自最初确定组织需要的外地人员。 其他人可能不会。 这个选拔委员会中可能有一些人,他们在选择什么样的系统方面有着不同的兴趣。

无情的项目经理现在请委员会的每个成员投票他们的代表小组,了解他们在新企业系统中的需求。 每个委员会代表如何做到这一点? 嗯,首先,不是每个人都投入同样的努力,但对于那些做家庭作业的人,他们要求他们的员工提交一份他们觉得重要的功能列表。 然后,他们,也访问互联网和浏览一些供应商网站。 他们可以从这些网站的宣传册中看到的功能进行复制和粘贴,因为每个网站都会给他们新的想法,了解他们可能能够对新系统发出哪些类型的请求。

现在,委员会已重新组合,每个委员会成员的长电子表格与其他成员合并为一个大型电子表格。 对要求进行分类,但存在一些挑战。 首先,由于从广泛的角度要求特征,该委员会的各种需求现在变得更加明显。 委员可能位于不同的部门,但也在不同的国家/地区,甚至不同的部门。 几乎总是有一个请求与同一列表中的另一个请求发生冲突 (例如,系统应该非常简单,并且没有很多提示,并且系统应该非常灵活,并且每个用户) 的大量选项。

最后,供应商将看到的组合电子表格已完成。 它具有数百个功能请求,并且对于每个功能请求,供应商应说出“是”、“否”或“是”。 还可以附加加权系统来说明此功能是“必须拥有”、“重要拥有”还是“可拥有”。

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

RFP 几乎已准备就绪。 将有一些论文问题,通常是关于选择的技术体系结构,并且,根据对这些要求进行轮询的人数,体系结构请求 (可能同样有冲突,例如,系统必须将所有数据存储在SQL Server数据库中,并且系统必须允许任何数据存储在本地用户的计算机) 。

实际上,到目前为止听起来还不错,你不认为吗? 毕竟,我们将返回一堆供应商响应,显示谁可以提供我们需要的所有功能。 实际上,到目前为止听起来还不错,你不认为吗? 毕竟,我们将返回一堆供应商响应,显示谁可以提供我们需要的所有功能。

但实际上,到目前为止,我所描述的还有一个根本问题:当我们将 RFP 过程用于商品而不是企业系统时,这个问题不会发生。 就是这样:企业系统是某种解决方案。 但到目前为止,我们什么也没说这个问题。 这是一个如此常见的事件,技术行业已经接受它作为正常和可接受的。

为什么以这种方式选择企业软件不起作用

几十年来,购买者一直在使用此方法,没有人质疑它,但企业软件业务中的人们知道,选择企业软件的经典 RFP 方法存在根本问题。

首先,仅仅因为你有一个很长的功能列表,这并不一定意味着你更接近于解决业务问题。 事实上,如果你甚至没有阐明你试图解决的具体业务问题,那么你可能会使事情变得更复杂,最终更糟,而不是更好。 RFP 流程旨在购买商品。 当我们有同质产品,如鞋子、土豆或糖时,以这种方式购买这些商品可以产生成本最低的投标人,并从可能的供应商中获得最佳选择。 对类似商品的 RFP 的响应使得比较可能的供应商变得非常简单。 当组合中每个产品的变量是无限 (与企业软件) 那么 RFP 的响应也具有无限数量的变量,并且该过程产生价值不大的结果。

当我们使用 RFP 方法选择企业系统时,RFP 看起来大多相同。 这是因为它们都是为了响应相同的刺激而创建的。 项目经理请求“你将需要此企业系统中的内容”的列表,而大多数中层经理必须响应该请求的唯一词汇表是功能列表。 因此,对 RFP 的响应看起来都相同。 它们是作为系统一部分或系统一部分提供的所有功能的清单,需要付出一些努力。

对于选择团队来说,最常见的情况是,他们将收到大量对 RFP 的响应,他们会浏览数百页,完成后,他们不会觉得比他们开始时更接近解决方案。 对于购买者来说,这是非常令人沮丧的,他们付出了巨大的努力,创造什么应该是一个公平的建议请求,在评估答案,却发现练习是徒劳的。

更糟糕的是,经验丰富的企业销售人员知道该过程将产生令人沮丧的结果,并且从他们听到将创建 RFP 的那一刻起,他们就会开始工作。 它们未处理 RFP 响应。 这不相关。 相反,他们在管理结构中工作了两三个级别,寻找 RFP 启动的原始动力。 他们寻找一位高级管理人员,他阐明了一些业务挑战,并启动车轮,以便采购商和其他中层管理人员最终创建 RFP 并将其发送给供应商。

当 RFP 响应最终对采购过程中几乎从未明确说明的业务问题做出明确答案时,企业销售人员准备跳入行动,让高级管理人员完全绕过流程,根据自己与高级企业销售人员的个人关系选择一个系统。

如果你觉得这听起来很硬,你就错了。 事实上,与通过 RFP 流程购买相比,在高管级别通过个人关系选择软件可以提供更好的案例。

但是,概念证明或试点呢?

因此,我们知道经典购买过程在购买企业软件时存在缺陷。 如果是这样,我们应如何选择企业软件,例如企业项目管理系统? 一种常用的方法是使用概念证明或试点阶段方法。

这两个术语通常同义使用,因此让我们首先讨论什么是概念证明或试点部署。

概念证明。 在概念证明中,潜在组织以有限的方式部署企业软件,以证明它可以完成技术挑战,而解决方案克服该挑战的能力存在一些疑问。 例如,数据量可能为 。 “我们担心该产品可能无法处理我们每个项目拥有的那么多的任务。 我们希望你随软件一起,拍摄两个或三个示例项目,每个示例项目有 500 个任务,并向我们展示如何将这些任务加载到软件中,以及该软件仍然可以使用此卷执行其基本功能。

试点阶段。 试点阶段是企业软件的安装,但范围有限。 试点部署可能适用于一部分用户;例如,1000 人中只有 10 人会在 4 周内完全使用此软件。 或者,它可能用于功能的子部分或数据量的子集;例如,500 个项目中只有 10 个项目会被加载。

如何使用概念证明或试点阶段? 经常遇到的问题是如何应用试点阶段或概念证明。 当潜在组织致电并要求我们提供概念证明建议时,这种情况非常罕见,并且还可以确定需要证明的技术概念。 “你希望证明什么,我们如何能够衡量我们已经证明这一点?

最常见的是,中层管理人员已经确定了一个企业软件,他们希望这些软件能使他们在组织中的生活更轻松。 高级管理层根本不参与其中,中层管理人员甚至没有阐明他们试图克服的业务挑战。 他们希望,如果解决方案只是在大楼里,那么下次管理层的人会在走廊上闲逛时,他们会“意外地”看到解决方案在运行中,并立即为企业部署带来祝福。 借用电影《梦域》中的一句话,“如果我们建造它,他们就会来。

试点阶段选择无效。

它很少成功。 企业软件的问题在于,我们需要高级管理层的参与才能使部署成功。 高级管理层将成为此企业系统报告和分析的“客户”。 高级管理层需要亲自投资,以便让一系列员工有时间设计、配置和接受企业软件培训。 高级管理层必须接受甚至帮助重新设计属于任何企业系统部署的业务流程。 没有高级管理层不仅给予他们的祝福,而且没有他们的隐含支持和直接援助,任何概念证明都无济于事。

试运行阶段也是如此。 如果公司没有从最高层次承诺通过使用企业软件解决一些业务问题,那么引入试点阶段是没有成效的。

有效的试点阶段选择。

这不是说部署的试点阶段没有位置。 它们确实在成功部署中具有关键位置。 该地点是在购买决定完成后立即完成,企业系统的设计已经结束。 现在,试点阶段非常适合测试企业系统设计,并对其进行微调,以便进行常规部署。

如果完成试点阶段,希望看到软件在运行中会导致管理层选择它,那么我们的试点无效,并且不会在选择过程中取得进一步的领先。

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

企业系统每天由中大型组织购买,虽然 RFP 方法可能不是最有效的,但有几种方法可以选择非常有效的企业软件。 下面是创建自己的有效企业选择流程的一些提示。

  • 阐明问题。 首先,阐明问题。 这意味着高级管理层必须参与其中,而要阐明的问题是业务问题,因此应从业务角度进行阐明。 要问的一个好问题是,“我们现在不能做出什么业务决策,或者我们只能做出很大的困难,通过部署此企业系统解决方案,可以简化哪些业务决策?

    使用此企业系统可能要解决一系列业务难题。

  • 为供应商提供一些创建解决方案的余地。 一旦明确了业务问题或问题,请与可能的供应商联系,并确保与协助该过程的高级管理层联系是透明的。 当管理从一开始就成为过程的一部分时,与高级管理层的“机密”供应商会议就变得不可能了。 让供应商了解问题,并给予他们一些答案的余地。 在解释这些业务挑战对你的影响时,你可能会发现更多关于你的组织,而不是你意识到的,当你不尝试向潜在供应商描述解决方案时,你肯定会看到更广泛的可能的解决方案。

    当你与可能的解决方案提供商交谈时,请确保他们明白他们必须同时面对技术和业务流程挑战。 从未有过对组织流程没有一定影响的企业系统解决方案。 如果解决方案提供商无法帮助解决该过程将如何受到影响,则你只会查看解决方案的一部分。

  • 去认识一些人。 当你了解几个可能的解决方案提供商时,请要求与一些现有客户交谈。 更好的是,看看供应商是否会让你去访问他们的一些现有客户。 优秀的解决方案提供商通常有客户在自己的部署中取得了成功,并且他们有足够的时间与潜在客户见面。

    你将在几个小时内与经验丰富的客户一起了解可能的解决方案,这比从阅读 RFP 响应或查看供应商销售演示中学到的要多。 当你向供应商询问可能的客户参考和现场访问时,你可能会认为理想的公司与你的公司完全相同。 情况并非总是如此。

与其他行业相关或有些相似的公司见面通常非常有价值。 你还可以从比你大或小的组织学到很多知识。 更加强调组织在解决方案方面拥有多少经验,而不是他们正在使用的版本,或者它们是否与你所在的确切规模或所在行业相同。

如果你幸运地访问了现有客户,请记住,它不是供应商。 要尊重、礼貌和感激。 带一份小礼物,也许公司徽标宣传材料往往很受欢迎。 当你与组织在一起或在电话中与参考资料交谈时,一些可能的问题可能包括:

  1. 你使用什么过程来选择此解决方案,而选择其他解决方案?

  2. 此解决方案对业务流程有何影响?

  3. 部署最具挑战性的方面是什么?

  4. 到目前为止,最有价值的投资回报是什么?

  5. 你如何看待解决方案从此处演变?

不要指望只有快乐的答案。

完全无法提供引用的供应商必须比拥有大量满意客户端的供应商更可疑。

最后,选择后,分阶段部署。 本专栏中介绍了如何在分阶段与大爆炸模式下部署的其他文章。 这将降低任何企业系统部署所涉及的风险,并帮助随着系统的发展微调部署过程。

请记住,任何企业系统部署都是一个动态过程。 这不是一次性的决定,快乐的结果永远月复一月地到来。 最成功的企业部署从选择开始,包括关键人员,他们将成为部署过程的一部分,从最高级管理层到现场最具战术性的人员,并分阶段继续通过系统的发展。

有效的企业系统选择只是该过程的第一阶段。

关于作者

Chris Vandersluis 是总部位于加拿大蒙特利尔的 HMS Software(Microsoft 认证合作伙伴)的总裁兼创始人。 他拥有麦吉尔大学的经济学学位,在项目控制系统自动化方面拥有30多年的经验。 他是项目管理研究所 (PMI) 的长期成员,并协助创立了 Microsoft 项目用户组的蒙特利尔、多伦多和魁北克分会 (MPUG) 。 克里斯撰写的出版物包括《财富》、《重型建筑新闻》、《加拿大计算》杂志和PMI的PMNetwork,他是《项目时报》的常任专栏作家。 他在麦吉尔大学教授高级项目管理,并经常在北美和世界各地的项目管理协会职能部门发表演讲。 HMS Software 是 TimeControl 面向项目的计时系统的发布者,自 1995 年以来一直是 Microsoft 项目解决方案合作伙伴。

可通过电子邮件联系 Chris Vandersluis,地址为: chris.vandersluis@hms.ca

若要阅读 Chris Vandersluis 与 EPM 相关的更多文章,请参阅 HMS 的 EPM 指南网站 (https://www.epmguidance.com/?page_id=39) 。