“做个解决方案买家”白皮书

本白皮书是我们的“一线快报”系列文章的一部分。它描述了未来的软件买家如何应用容易理解的业务分析方法,更有效地与软件供应商打交道。本文介绍的实践有助于通过有效确定软件解决方案需要解决的问题,建立软件评估标准。

若要下载本白皮书的 Word 版本,请参阅做个解决方案买家

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

做个解决方案买家

软件采购很多时候是基于功能列表、广告推销或者朋友推荐。本文描述未来软件买家如何应用容易理解的业务分析方法,更有效地与软件供应商打交道。

今时不同往日。让软件在企业环境中运行已不再称作安装。现在,术语实施或部署更恰当地描述了让新软件包正常运行所需的条件。

越来越多的软件供应商都说他们卖的是解决方案,这已经不足为怪。在我们考虑部署 Microsoft Project Server 或 Microsoft CRM 之类的企业系统时,我们必须首先考虑将涉及到的不同技术层,而且在我们开始做这一步之前,我们必须考虑我们总体业务将受到的影响。

销售解决方案自然带来了解决方案销量。如果您真的理解这一点,您就会知道,全世界几乎每一家针对中大型企业的高科技公司都在努力把自己重新打造成解决方案销售交付商。Microsoft 当然也在这些公司之列。Microsoft 在过去几年里展开了广泛的工作,意在将解决方案销售确立为其一线销售和实施工作组的指导原则。

那么解决方案销售员是什么样的工作?毫无疑问,他们仍然是销售人员。但是,解决方案销售员的目标不是当盒装软件的“搬运工”,而是要建立有助于客户改善其境况的解决方案。

这听上去不错;销售人员的终极梦想不就是希望改善人们生活吗?但是,这也带来了挑战,而克服这种挑战的关键就在于您,也就是潜在客户可以参与进来。

关注问题

大多数解决方案销售员在踏入市场时所面临的挑战是,我们对解决方案应该是什么样子,已经早有先入之见。我们太习惯于关注软件的功能和特点,在我们跟软件销售人员交谈时,谈话几乎不可避免地会直接转向“你的软件能做这个吗?你的软件能做那个吗?”有经验的软件销售人员,以及转入解决方案销售职位的那类销售人员,太习惯于销售功能和特点,以至于他们常常忘了问最基本的问题:“问题是什么?”

现在,这听上去可能有点傻,但是回想一下您与软件销售人员的最近几次谈话,您可能会吃惊,这个问题居然很少有人问。像 Microsoft 及其合作伙伴这样的供应商每年都会收到很多建议征求。在这几年里,我见到过几百份这样的建议征求,它们几乎一成不变地是一个冗长的表格,里面列出了希望供应商实现的各种功能。这样一个庞大的电子表格通常是答复客户的核心内容。

我们很少见到与每项功能所针对的业务需求有关的描述。这很容易陷入我们已经在以前的产品中熟悉的功能,或者我们在什么地方看到有人推销的功能,要想不关注新产品一开始就引起我们兴趣的功能还真不容易。这在对于解决方案选型,很多人会提出很多意见的企业环境中尤其如此。发出请求,请大家列出他们希望新软件系统提供的所有功能,要比讨论他们的特定业务需求容易得过。

如果您开始思考也许自己错过了什么明显的问题,那么您不是唯一这样做的人。这种情况目前在软件行业非常普遍,以至于称为“业务分析师”的新一类咨询师应运而生。这些人受过培训,可以将业务需求与软件功能联系起来。让我们花几分钟时间了解,如何像业务分析师那样,在企业级软件评估中应用这些基本概念。

确定业务需求

首先要考虑的是,最初是什么样的业务需求促使您寻求新的软件系统。我们自己的公司经常为有意实施企业项目管理软件的公司做咨询。当我作为咨询师到达某间公司时,我会先问这家公司目前是如何执行项目管理的,很久以后我们才会讨论是不是要购买软件。

在他们回答完后,我总是会追问这样的问题:“这种方法对您有效吗?”奇怪的是,客户通常都回答是的。对我来说,关于项目实施的会谈只能到此结束了。我解释说“如果没有问题,我显然做不出可以解决问题的解决方案!”这样的回答通常令人语塞。我会问“为什么召集我们来开会?”反应可能各不相同,但通常,他们会环顾房间,然后想起来还有很多没做完的事情亟待处理 - 而我们的会谈不到 5 分钟就结束了!

所以,开门见山地问“我们的业务需求是什么”是很好的切入点。几乎总是会有一个可以解答这个问题的总体目标 - 一个一开始就激发最初动机的目标。

展开愿景行动

接下来,您需要从软件功能的角度更深入地研究其意义。当我们在组织中实施 Microsoft Project Server 之类的企业项目管理软件时,我们总是先从愿景行动开始,愿景行动涉及关键人员(评估软件的人)和高级管理层(支持行动的人)。只与技术人员执行此行动还不够,因为此行动的目的是将业务目标与技术功能联系起来。

下面是执行此行动的有效方法:请关键人员进入房间,房间里放一块大白板。把白板分成 4 列:先从最右一列的标题开始。在这里写上“业务决策”。

具有四列的白板,包括“业务决策”列

在右列中,您将列出您希望使用您所考虑的新系统制定的业务决策。在与客户一起执行此行动时,人们首先想做是列出很多功能,所以您必须坚持,至关重要的回答是业务决策。例如,某位与会者可能会立即说“我需要所有资源及其工作负荷的清单。”当然,这也许没错,但是您需要了解是,他们将通过这份清单做出什么业务决策。

业务决策的例子可以是:

  • 某个特定部门招聘或裁员

  • 制定项目可行或不可行决策

包含“业务决策”列和业务决策列表的白板

一旦获得像样的业务决策列表,先暂停一下。现在正是复查业务决策列表,并确定最优先决策的恰当时机。您可能需要自问这样的问题:在这些业务决策中,如果您只能解决其中一个决策,那么解决哪一个会给企业创造最大价值?在整个过程的现阶段挑选前三个决策总是最容易的。

如果您已经做到这一步,那么您已经领先于挑选企业项目管理软件的大多数组织。能够向系统供应商提供最重要业务决策的优先列表,就已经向完成整个流程迈出了一大步。如果您可以告诉系统供应商您需要作出什么业务决策,他们就可以跳出讨论简单功能的圈子,转而讨论如何使组织效率更高。

接下来,看一看每一项决策,然后提问“为了作出该业务决策,您会需要什么样报表?”在第 3 列标上“报表”。对于每一项位列前三的决策,在该列中列出对应的决策所需要的报表。

例如,为了确定某个部门是要雇人还是裁员,我们需要一份显示资源产能规划数据的部门报表。这包括对期望工作负荷、期望资源可用性和计划的提前预测。如果您是中等规模的企业,现金流可能也很重要。例如,您可能需要更多人手,但是没有现金来雇佣他们。现金流报表包含现金的估计收入和流出,从而提供流动收支。

包含“报表”和“业务决策”列的白板

如果我们填写确定为优先的每一项决策的“报表”列,那么我们所需方案的雏形也就开始明朗。做完这步后,您也就得到了一份列表,在其中列明了需要目标系统提供的实际输出结果。

这里再停一下,看看组织中已在使用的现成报表是否属于您所确定的那种类型。这样的报表很可能已经存在,但是格式很多,并且可能有不完整的数据,或者生成这些报表需要大量工作。如果您发现已在组织中用得很好的报表格式,那么可以将它们添加到系统要求列表。现在您已然可以向系统供应商再提供更多信息。

现在确定了关键报表后,我们就可以转向生成这些报表所需要的系统元素。将标题“分析”添加到图表的第 2 列。对于每个报表,确定生成该报表所需的分析或算法。例如,对于资源产能规划报表,我们可能需要来自项目管理系统的关键路径进度表以及资源调平分析。

包含“分析”、“报表”和“业务决策”列的白板

这些分析包含了无数功能,供应商常常在这些功能的基础上推销这些分析。(是的,逐功能销售依然盛行不衰!)您需要能够确定的是,这些功能最低限度将交付您需要的报表,然后您可以凭借这些报表制定或改进已经确定的业务决策。您可能会惊讶,为了满足您的实际业务需求,您所需要的功能竟然如此基本。对于某些报表,根本不需要分析或计算;这些报表只需是可以根据新系统的数据直接生成的简单汇总。

最后,我们来到图表中的第一列。在确定了所需的分析后,就可以转而确定需要将哪些数据元素提供给这些分析。

在图表的第一列中添加标题“输入”。

在上面的例子中,我们可能需要该部门的工作所涉及的每个项目的完整任务列表。这很可能也是这家公司的每一个项目。我们还需要有关每个资源的可用性,以及每项任务定义的工作负载的完整资料,这样当任务进入进度分析时,工作负载就能进入资源调平分析。此外,请回想一下,我们是如何着手特定部门的雇人或裁员决策的?我们还需要能够按部门确定资源。

包含“输入”、“分析”、“报表”和“业务决策”列的白板

我们可以像这样从右边的输出转到左边的输入,直至找出新的企业系统所需的方方面面。

评估风险

完成此行动后,我们可以回到每一项输入,并确定这些数据元素是否存在、是多是少,这样做是值得的。您可能会发现,这些数据项中的某些项根本不存在(我们也经常发现这种事情)。例如,某些组织没有保留资源可用性的完整列表。您可能还会发现,并不是每个项目都有资源负荷计划表(显示该项目所产生的资源负荷)。在很多组织中,某些类型的项目根本不进入任何类型的系统。紧急工作、技术支持工作或日常维护工作都是常见的例子。

如果无法获得实现业务价值所需要的基本数据,那就不能不将该系统元素视为高风险。例如,如果我们发现,组织 80% 的项目可以确定资源负荷计划表,那么我们能不能合理地期望改进我们增员或减员的业务决策?答案很可能是“不”。为什么?因为未进入系统的 20% 的项目很可能相当于某个特定部门 80% 的工作量。如果不掌握所有数据,就永远不会知道财务报表是否准确。

当然,这几类问题都有解决方法。其中一个方法是,将组织中您无法获得其数据元素的那些方面的所有业务流程隔离出来。项目不进系统的部门也不会列出他们的资源。这种方法做起来并不是在什么情况下都这样简单;您必须一项一项查看才能确定这些业务流程和业务决策对您的实施有多大风险。此时在流程中重新排定您希望改进的最终业务流程的优先级,这种情况并不少见。您可能有一个非常理想的决策,但结果证明风险很高,并因此不值得在部署早期阶段推行。

记录您的行动

在召开这类会议时,指派一个书记员 - 他/她的工作就是在整个过程中记录注解与评论。如果没有良好的笔记以供以后参考,那么为什么某个特定业务决策的优先级定得高或低,或者为什么某个事项被视为高风险的原因就会被忘记。

记录下面的内容很重要:

  • 您在白板上写了什么

  • 哪些人参与了过程

  • 谁为每一个最终业务决策负责

如果您现在感到不知所措,别害怕。这项行动从头到尾可以很快完成,即使是在最大的组织中也是如此。通常只要一天,也许两天就能完成整个过程。让正确级别的管理层进入房间是获得成功的关键。此外,这类会议最好由组织以外的人主持,因为他或她不容易按照组织惯有的方式行事。

知识就是力量

如果您正在考虑企业项目管理系统(其实就是任何一种企业系统),那么在与软件系统供应商打交道时,完成此行动能让您本事大涨。您可以立即区分出对您重要和不重要的系统元素。软件供应商可以获得您要作出的报表和决策的列表。

您可能会对供应商发回给您的某些答复感到意外。优秀的供应商不会拘泥于用列功能的方式来进行答复 - 那其实是拿方的功能去套圆的需求 - 而是会告诉您,如何充分利用他们的系统来应对您的业务挑战。

执行此行动最大的好处是:您建立了行之有效的评估标准。现在,在概念证明阶段,您可以立即关注系统是否提供了您需要的信息,让您改进必须作出的决策。

关于作者

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 支持专员。

×