“创建 EPM 部署计划”白皮书

本白皮书是我们的“一线快报”系列文章的一部分。 本文介绍如何创建企业项目管理 (EPM) 部署计划。 本文确定了 EPM 部署计划中的阶段和关键点,并预估了拥有数百 EPM 系统用户的中等规模公司各阶段所需时间。 还确定了可能影响各阶段预估工期的因素。

若要下载此白皮书的 Word 版本,请参阅“创建 EPM 部署计划”白皮书

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

创建 EPM 部署计划

“您能否帮助我安装 EPM 系统并让该系统在几天内上线运行?” 是 EPM 部署公司最常面对的请求之一。 不幸的是,无论组织处于何种规模,都只能获得一个简单明了的答案:“不能”。挑战不在于技术;而是在于,一系列的策略、流程、程序和实践问题可能会带来影响深远的组织变动。

我们来了解一下 EPM 部署计划必须包含的内容以及您如何创建自己的 EPM 部署计划。 我已在文中确定了要点,甚至还给出了拥有数百位 EPM 系统用户的中型组织在每个步骤上需要耗费的预计时间。 在以太短或太长为由反驳各个步骤的预估时间之前,请思考下您自己的组织需要开展哪些工作才能完成该步骤。 工期并不是按工时进行预估,而是按照日历时间预估,因此,请牢牢记住为了完成所需类型工作而集结某些类型的员工所需的时长。

1. 建立 EPM 系统部署团队

若不建立项目团队,项目就没法走得长远。 必须集结多位员工以将这个项目从创意阶段一路实施到生产阶段。 在参考总览计划的情况下,您要思考的是,哪些人员将陪伴项目长达数年?

第一阶段的关键步骤包括:

确定关键利益干系人

在项目启动前,通常存在一名关键利益干系人。 该人员通常隶属于管理层,并且感受到了缺失此类系统所造成的不足。 这是一个良好的开端,但距离此类项目取得成功还有很长的路要走。 要实现成功的 EPM 部署,就必须并且立刻确定系统的业务所有者。 业务所有者指的是能够享用完成后的系统带来的优势并且认识到系统完成过程所存在的价值的人员。 还可能存在一名或数名执行发起人。 执行发起人可能是会用到最终项目成果的管理层人员,也可能是参与项目完成过程但不参与 EPM 环境最终运营的人员。 可以没有执行发起人。 但不能没有业务所有者。

确定内部专业资源

确定业务所有者(以及可能存在的执行发起人)之后,项目团队应确定项目推进需要用到哪些内部专业资源以及这些资源的可用性。 通常,我们会发现自己缺乏有关特定技术(比如,当前版本的 EPM 软件)的专业知识,但这并非是我们所需的唯一一种专业知识。 要推动项目流程的实施,组织内部就必须了解自身的流程、实践、程序、 角色和职责以及数据的存储位置。

让外部专业资源参与项目(如有必要)

在从非企业项目管理过渡到企业项目管理时,经常会发现项目团队中出现知识或技能缺口。 如果出现这种情况,则表示项目团队必须找到具备相关知识的人员。 必须尽一切可能让外部专业资源加入项目,以弥补内部资源在相关方面的缺口。 在项目发展需要用到此类人员的情况下,可以通过咨询或外包合约或长期聘用的方式让这些人员加入项目。 内部开展针对此类专业知识的培训这一做法很少能够取得成功。 我们在这方面遇到最多的一项挑战是,内部资源需要承担培训职责,但他们却不具备相关知识或者仅仅具备有限的知识。 “我曾经使用过 EPM,所以组织现在要求我负责部署这套系统。” 是我时常听到的抱怨。

您的团队规模取决于项目最终涉及的范围有多广。 经常可以看到,有些人参与了几个月项目,然后随着项目阶段的更改,他们又被其他人所顶替。 这时,关键还在于,必须建立起团队的权限和管理层的支持。

噢,还是那句老话。 将此项目视为一个项目! 虽然听上去很神奇,但要说一个组织中有哪些项目在部署过程中最有可能遗漏其他部署计划中所包含的元素,那必然就是 EPM 部署了(和鞋匠的孩子没鞋穿一个道理)。 因此,请制定项目计划、预算、特许执照、分配足够的资源,等等。

完成这一步骤所需的时间:四周。

2. 确定业务目标

现在,我们已经组建好了团队。 是时候让他们开始工作了! 我们现在已经确定了项目范围,如果范围过大,请将其细分为多个阶段,然后为这项工作创建一个计划。

以下为我们需要在此阶段完成的工作:

管理层和利益干系人研讨会

这是必经的一步。 创建 EPM 环境的根本目的在于帮助管理层和最终用户更好地制定业务决策。 因此,在实施流程开始时,相关管理人员需要花一些时间来帮助确定该系统将用于制定哪些决策。 我在过去的文章中已介绍过如何开展此类研讨会(参见“做个解决方案买家”白皮书),但怎么开并不重要,重要的是必须开。

开发团队可以借助这一机会引起管理层的重视并获取另外两件无比重要的东西。 首先是管理层对于流程、工作和最终效益的承诺。 其次(并且重要得多)是合理的管理层期望。 管理层最常抱有的期望是可以在数天或数周的较短时间内完成整个流程。 当管理层领悟到流程所涉因素的影响时,就可能不再提供支持。 如果这种情况无法避免,那就早点发生为好,总好过为那些没有足够时间或资源就没法完成的事务徒费心力。

这些(没错,可能需要开不止一次)研讨会总结出的成果将转化为构成项目范围的业务目标,并最终决定了日程计划。

确定管理层角色影响

业务目标获得管理层同意后,必须再开一两次会议来确定对于管理层的角色和职责产生的影响。 例如,资源产能规划 就常常面临这种状况。 在高技术公司中,管理层几乎总是希望通过 EPM 系统实现资源产能规划,那么,谁又在这个过程中负责分配资源、管理冲突和为不同部门员工的工作划分优先级呢? 您在此时无法解决这些问题,因为您没有定义明确的流程,但这时您必须确定受到影响的管理层人员,如此一来,您才能在时机成熟时回过头来将这些人包含在流程之中。

为业务目标划分优先级并创建主部署计划。

几乎可以肯定的是,应将该计划划分为多个阶段。 对于几乎每个 EPM 部署而言,管理层都期望 EPM 系统能够提供广泛的功能。 此时,为了保证项目取得成功,必须为要首先实现的目标划分优先级。 将前两或三个目标划归于一个阶段,其他的则往后顺延。 每个阶段都应交付一个有效且具备自身价值的 EPM 生产环境。

建立里程碑和指标

我们是项目经理,对吧? 我们要为项目建立一些里程碑并遵照某些可以衡量的指标。 对于任何企业系统部署而言,确保各项工作处于正轨是流程的关键所在。

在获得了第一阶段的详细信息后,我们现在应该已经拥有了足够的信息来开发总体计划。

完成此工作所需的时间:四周

阶段 1

每个阶段都会有一些需要重复的任务。 步骤 3 到步骤 9 都属于一个阶段。

3. 库存流程

在我们接近工具阶段之前,我们需要确定此阶段中最终需要实现哪些流程的自动化。

哪些流程存在并且可以采用?

我们开始审视组织中已存在哪些流程、实践和程序可用于此阶段中确定的业务目标并确定其中哪一些可以在新的 EPM 环境中采用。 通过找到可现成采用的已有流程,可以获得两个好处。 首先,这些流程已被创建并且为用户所熟知。 其次,通过采用这些流程,可以与其创建者建立良好关系。 现在可以将这些人任命为该流程方面的主题专家,从而简化部署。

必须设计哪些流程

我们永远无法找到所有需要的流程、实践和程序,但我们必须确定缺少其中哪些。 这可能比找出已有流程要难。 您是在寻找缺失之处,而这需要具备丰富的经验。

流程白板探讨会

对于那些需要修改相关工作或者需要重新创建的流程,您需要召开几次使用白板的研讨会。 与项目完成后的最终用户一起合作,才能最高效地制定总体流程计划并解读其所有含义。 记录所有会议内容

调解受影响的管理角色

请记住,在确定即将发生的更改可能会影响到哪些高管或经理时, 请再次与这些人员召开会议。 对于那些会影响到角色、权限、层次结构或现有职责的、新设计的流程,您需要组织会议解决这些问题。

该会议最终会草拟出一份流程指南。

完成 流程实践所需的时间:四周。

4. 采用、修改和设计流程

审查、修改和验收设计的流程

并非每个人都会参与上一组任务中包含的每个流程实践。 因此,必须将新流程指南的草案发布给利益干系人、经理和受影响的各方。 很多时候,该指南都会经历多次审查,甚至还会安排额外的研讨会来解决流程中的冲突。

经过这一过程后,组织最终会完成并验收一份流程文档。 请别大意,“验收”流程可能会经历几轮审查,甚至还需要最高管理层的干预,但如果没有经过验收的流程,那自动化也就无从谈起。 好消息是,即便部署流程止步于此,组织也已经获得了巨大的价值。 必然可以预见的是,那些经历了这些内部流程的人可以了解到之前从未考虑过的组织相关信息。 因此,他们的效率将会更高,从而可以立刻开始此类流程。

完成完善的流程指南所需的时间:八周

5. 评估和选择 EPM 工具

为供应商准备“问题陈述”文档。

如果您已读过我撰写的其他文章,则应该知道,我强烈支持为潜在供应商提供 EPM 问题说明,然后让他们来告诉您如何解决这些问题。 毕竟,他们可是从事的解决方案业务。 那就让他们来设计您的解决方案吧。 与用电子表格列出您想要的所有功能相比,这种做法要略微困难一点,但其重要性不言而喻。

征求供应商的回应

并且别只做一次。 您可能已经知道谁是您的首选供应商,但即便您认定您的选择正确,也请作出适当的比较。 供应商不同,其帮助您解决问题的方式也不同,因此,请保持开放的心态,准备好迎接惊喜。

最终候选清单

即使您在寻找的某个产品具备多个实施方时,也请认真考虑要亲自与哪一家进行会面。

供应商和实施方演示

啊,到演示的时候了。 观看演示能够让您获得很多有价值的东西,但绝不要轻易陶醉其中。 所有供应商都对销售演示进行了谨慎编排。 如果您对于某个视图、报告或仪表板尤为兴奋,请明确询问,“开发相同的视图需要耗费多长时间?”

工具选择和采购

然后,就该开展大型采购了。 我知道,您本认为这个阶段才是起点,应该出现在本文的开头。 好吧,别担心。 总之我们还是到达了这个阶段。 选择好您的 EPM 系统,然后下订单吧!

经过此阶段后,一套全新闪亮的 EPM 产品便会出现在您的组织中。

完成此阶段所需的时间:八周。

6. 自动化设计和配置

将流程设计文档应用于所选 EPM 工具

既然我们已经知道所选的工具,我们就可以开始通过流程文档创建系统设计文档,并最终落实为功能规范。 我们可能希望为新安装的 EPM 系统建立一个“开发”实例,从而可以测试或验证某个设计标准。 此时,我们首次 需要让系统专家加入实际系统的配置流程。

设计和实施标准

我们必须建立许多标准。 其中每个标准都代表了系统架构和设计中的相关含义。 例如,日历经常被忽视。 我们将拥有一个还是多个日历? 我们是否将拥有资源日历? 谁有权更改它们? 我们是否知道更改资源日历对于日程计划和进度数据造成的影响? 以及其他诸如此类的问题。我们需要为以下 EPM 系统元素建立标准:

  • 日历

  • 命名约定

  • 资源层次结构

  • 项目和非项目工作的资源负载标准

  • 费率和成本核算标准

  • 角色和职责

  • 审批结构

  • 项目和任务层次结构

  • WBS 和其他编码结构

  • 文档管理

  • 通信模板

  • 项目模板

我们还需要其他一些设计,甚至可能还需要为源于第一阶段业务目标的元素编码。 可能需要考虑的一些元素包括:

  • 设计和实施自定义编码

  • 设计和实施仪表板

  • 设计和创建外部系统链接

  • 设计和创建工作流程

  • 设计和实施报告

  • 设计和创建 EPM 工具培训

  • 与受影响的各方一起审查设计

经过此流程,我们可以获得一套做好充足准备上线运行的 EPM 工具。 此时,它应已具备迁移至工作环境所需的所有配置。

此阶段所需的时间变动很大,具体情况视所需的自定义工作量而定,但如果我们严格遵守了第一阶段的要求,则此阶段差不多需要耗费十二周。

7. 试点 EPM 工具

既然我们已经让系统准备就绪,我们就必须确定试点群体并让他们参与试点。

第 1 阶段 安装/配置/迁移数据

我们需要在试点实例(而非开发实例,我们将在未来阶段继续使用该实例并将其用作支持和培训系统) 中安装新配置的系统。 我们还需要更新配置以匹配开发实例并将试点项目从现有环境迁移到新系统中。

培训

培训在项目部署中的地位,就跟可怜的继子一样。 它常常在部署计划中被遗忘。 确保试点人员获得所需的培训,帮助他们正确使用系统。

运行活动项目

现在,根据您耗费了大量时间定义的流程、实践、程序和自动化来管理这些试点项目。 试点本身需要具备一个日程计划,该计划通常围绕着项目的持续时间而建立。

经验教训和文档

完成试点项目后,应该重新集结相关人员,一起了解创建的解决方案是如何解决预设挑战的。 此刻便是制定必要的调整、更正或基本变更的绝佳 时机。

完成试点项目和审查所需的时间:十二周。

8. 将第 1 阶段部署到生产

上线运行

是时候了。 让适当的用户开始使用新系统并迁移相应的数据。 别忘记在系统上线的同时提供培训、支持和后续跟进。

实施的时间很大程度上取决于用户总数:四周。

9. 审查和修改主部署计划

审查和调整主计划以准备迎接下一阶段 主计划可能已有数月时间未经历审查。 此时应该再次进行审查并了解最初为第二阶段安排了哪些计划。 在关注下一阶段的情况下,团队必然能够产生一些不同的见解。 毕竟,他们已经拥有了第一阶段的经验。

完成此阶段所需的时间:两周。

10. 第 2 阶段 - 再次完成步骤 3 到步骤 9

我们只完成了第一阶段,当您审视未来阶段时,您需要重复步骤 3 到步骤 9(步骤 5 除外)。 请记住,每个阶段都应交付一个可帮助组织提高效率的有效 EPM 生产环境。

您是否计算过第一阶段中每个步骤的工期? 总共为 58 周。 上文定义的摘要步骤的日程计划如下所示:

显示 58 周流程的甘特图

如今,所有组织都各有不同。 很多因素都会影响项目的总工期。 其中最重要的是现有企业项目管理流程的成熟程度。 接下来则是组织的规模以及复杂性。 相比那些分散在多个部门、办事处、城市乃至国家/地区的组织而言,集中在单座大楼内的组织明显能够更加轻松地部署 EPM 系统。

每个部署的日程计划都有所区别,工期不一定会更短。 管理层几乎总是会施加压力,期望可在数天乃至数周内完成日程计划,但要实现成功的部署,就必须不仅仅考虑 EPM 软件的安装。

关于作者

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

×