“资源管理”白皮书

本白皮书是我们的“一线快报”系列文章的一部分。 文中介绍了资源管理各个层面面临的挑战,并提供有关如何创建资源管理系统的建议。

若要下载本白皮书的 Word 版本,请参阅资源管理

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

资源管理

资源管理是组织利用 Microsoft Office Project Server 等系统,从单一项目管理转换到企业项目管理的最常见的理由。

您或许认为,这意味着我们将获得一份全面的“剧本”,详述如何通过此类系统实现最好的资源管理。

但这只不过是愿望而已。

资源管理定义

与企业系统的其他许多方面一样,第一个问题就是定义“资源管理”的确切含义。 根据视角的不同,资源管理可能有多种不同的含义。

资源平衡

首先从最单纯的视角开始。 这种观点来自超过 15 年前的从业人士。 项目管理软件最初以商业产品的形式推出时,是一种关键路径方法 (CPM) 调度工具。 这些早期系统完全没有考虑到资源。 首先使用系统制作计划,然后再通过滚筒式绘图机(主要用于支持技术绘图行业)打印出计划,利用它们制作项目的条形图或逻辑(网络)图展示,这样的过程令人兴奋。

如果这些系统考虑到了资源,那么其目标就是通过加入资源增强最初的计算。 算法虽然各有不同,但目的总是为了确保足够早地 - 早在聘用人员并安排其投入工作之前 - 发现交易数量不足造成的延误。 稍后我们将进一步探讨资源平衡的话题。

关键链式规划

关键链式规划这种概念存在已久,但我相信,一定有些人从中发掘出新鲜的意义,并对此充满兴奋感。 对于以计划为中心的用户,关键链式规划直接对计划应用资源约束,关注对计划履行影响最大的资源。 或许这就是 CPM 最初的用意,如果能将其应用到正确的情景中,结果将十分具有启迪价值。

资源容量规划

将思路再放广一些,我们可以将前两种定义包含在管理资源容量的更广泛概念之中。 至今为止,这是最热门的概念,许多人都曾经要求我们在企业项目管理部署中实施资源容量规划。 资源容量规划致力于为组织决策者解答几个问题:

  • 我能否凭借现有人员兑现已经做出的承诺?

  • 如果不能,我需要做出哪些人员调整才能兑现承诺?

  • 在这种情况下,我还有哪些剩余产能可用于兑现其他承诺?

  • 如果我接到了其他项目,能否通过现有人员顺利完成?

  • 如果我不能调整人员,需要完成的新工作会造成 怎样的影响?

资源容量规划涉及到必须在项目管理流程中加以实现的多方面概念。 这其中包括:

  • 资源负载

    为着手应对资源容量规划挑战,我们首先要了解需要完成多少工作。 (如果没有需要完成的工作,就不需要管理资源。)为保证精准分析,必须准确了解各任务要完成多少工作以及需要由谁负责完成工作。

  • 技能调度

    在 Microsoft Project 等现代项目管理工具中,我们可以从部门或个人的层面上管理资源需求,而现在也可以从技能的层面上加以管理。 技能调度包括管理资源需求,以及通过清单的形式管理技能可用性,整体而言,这种方法比单纯管理各部门中的可用人数更加有效。 您可能拥有数据库管理部门,但如果人员缺乏 SQL Server 2008 技能,而下一个项目又必须要用到这项技能,那么就仍然无法顺利完成项目。

  • 资源分配

    谁负责分配哪些资源完成任务? 必须制定一项流程,确定如何定义并满足资源需求。 第一步工作是否应该是请求资源类别或资源能力? 您是否应该请求处于“提议”模式的个别资源,然后让拥有相应权限的某人将其改为“已承诺”? 是否应让不同项目具有相互独立的提议资源? 一名项目经理是否应能够提交不同部门的资源,或者部门主管是否应具有该权限?

  • 资源可用性

    您已经确定了项目的资源需求,但有哪些资源可用? 谁确定各资源有多少时间可以投入项目 和非项目工作? 谁确定休假时间? 您要如何确定每天可以有多少个小时的加班时间? 您要如何处理无报酬的加班时间? 是否要将其转为“补休时间”?

  • 资源平衡

    确定项目的资源可用性和需求之后,对两者加以比较即可了解资源分配是否超量,并了解应对过量分配的挑战。 项目是否应划分优先级,确保某些项目能优先获得资源? 任务是否应划分优先级,确保某些任务能优先获得资源? 您是否使用了自动资源平衡? 能否手动移动任务? 公司的某些部门在等待其他部门的工作时,应由谁负责协调冲突?

资源合约

这项术语常见于矩阵型组织,在其中,部门主管负责管理资源组,项目经理则负责管理这些资源必须完成的工作。 “资源合约”术语表示项目经理与部门主管之间协商,以将资源投入到某些工作中。 第一步是项目经理申请某人在某日期留出指定时间。 部门主管在答复时可能会“讨价还价”,推荐具有类似技能的其他人员,或是提议安排所申请的人员在其他日期留出时间。 随后,项目经理答复接受或是再度“讨价还价”,如此循环往复,直至资源需求得到满足为止。

资源跟踪

对于某些组织来说,资源管理中最重要的环节并非规划,而是确定实际情况。 “只要您能告诉我们员工究竟将时间用在了哪里, 我们就能大大提高效率,”一位高管这样说。 这些组织最为重视的就是企业项目管理系统的时间表部分。 即便未能与项目计划集成,按活动划分的清单也能为管理层提供无比丰富的数据,帮助他们了解各项任务的工作量成本。 它可以展现出有多少时间可以投入到项目工作中的,此外还能展示有多少时间用到了项目工作以外的方面。 如果能将时间表集合与项目计划联系起来,资源管理就可以扩展到预算 与实际情况分析。 我们可以看到各计划任务所需的时间、任务当前进度以及进度对该任务以及其他可能受影响的任务的预计完成时间造成的影响。

资源沟通

以往,在超大型项目建设环境中,我们不必过多地考虑资源沟通的问题。 工长会在清早从项目办公室处获得最新信息,然后在开工前将需要了解的信息告知员工。 在白领型高科技项目环境中,情况则完全不同。 项目团队可能由各种各样的人员组成。 除了项目调度人员和实际处理工作的资源之外,还可能包括高管支持者、用户、客户、分包商、外包开放人员等。 项目团队超越办公室边界乃至组织边界的情况绝不罕见。 在此类环境中,沟通变得至关重要。 这种环境中的资源管理可能要求与项目管理流程中涉及到的所有资源有效开展协作。

资源承诺

谈到项目管理系统,我们所指的常常是与算法密切相关的环境,但管理项目内的资源承诺也是完成任务的一个重要环节。 项目团队主管需要管理其已经申请的承诺以及已经做出的承诺。 可能会有人说“我会在周五之前完成这项工作。”这就是一项承诺。 承诺的时间可能与我们计划中的预计完成日期恰好相符,也可能不符。 这是一项承诺,因此不同于调度算法所给出的应该完成工作的时间。 资源承诺可以在 Outlook 或 Office SharePoint Server 中管理,也可以在白板或其他某种承诺工具中管理 - 但无论如何,必须予以管理。

资源分包

对于某些组织来说,单纯管理从其他公司采购的资源就足以视为资源管理。 如果涉及到分包,管理分包商的承诺、确保合同提供正确的奖励、得到分包商的尊重都是决定项目成败的要素。

这听起来非常简单。 无论如何,Microsoft EPM 解决方案中都有应对资源管理所有这些方面的工具。 Project Server 甚至是 Project Standard 或 Project Professional 的基本功能都涉及到了资源平衡、资源分配、资源负载、技能调度。 多项目资源分配可以通过 Project Server 中的资源置换向导或工作组生成器完成。 资源跟踪可以通过 Project Server 中的时间表完成。 默认情况下,资源合约并没有直接对应的界面,但整个“提议”与“承诺” 资源的概念与此密切相关,因此可以通过 Office SharePoint Server 基于 Web 的表单完成资源请求,直接将这种概念与功能相联系。 即便资源分包也可以 通过 Office SharePoint Server 中的功能加以处理。

挑战

您或许已经注意到,我并没有提到资源容量规划,原因并不是它无法实现。 资源容量规划通常是 EPM 部署中呼声最高的方面,但也是最难实现的一个方面。

在尝试对一组技能精深的资源应用资源平衡算法时,就会遇到一项根本性的挑战。 为了理解这项挑战,我们应该花点时间了解一下最初的设计人员在创建资源平衡算法时的思路。 我之前曾经提到过,我们会回过头来了解资源平衡乃至关键链式分析,原因就在于此。

回顾原始资源平衡引擎时,我们会发现,其最初是设计用于工程领域。 第一批项目调度工具是为包含大量工程和建筑项目而编写的,在这种项目中,每个项目的各种计算需要一次性完成。 实际上,整个组织的成立意图可能就是完成一个项目。 最初的商用工具针对国防以及石油和天然气产业,因为这些行业可以从此类工具能管理的海量数据中受益。 但如果观察此类项目中的资源,我们会想到的通常是常规资源。

无疑,此类项目的资源调度是按照技能完成的。 项目调度人员要考虑可能需要用到多少名机械工程师、电气技师和管道工。 资源平衡算法极为适合处理这种问题。 我们拥有一些资源,然后平衡任务,全职员工的人数可以根据需要增加或减少。 如果存在大量同类型的可互换资源,这种算法的效果十分理想。

现代项目管理是在最初为涉及到大量可互换资源的庞大项目而制定的概念基础之上发展出来的,然后将这些概念应用于个人层面。 尽管至少从理论上来说,算法仍然有效,但无疑只有在每次只出现一种资源的演示中切实有效。

举个例子来说明:

显示 Chris 超额预订的 Microsoft Project 视图

我在 Project Professional 2007 中建立了这样一个简单的项目。 这个项目最初开始时只有一个里程碑,随后我又添加了在该里程碑完成后立即启动的两个任务。 在我分配 Chris 负责这两项任务时,立即产生了一个资源平衡问题。 通过拆分屏幕可以看出,Chris 的可用时间中存在时间重合的任务分配,我是故意这样设置的。

现在,我们使用 Project 的资源平衡算法来平衡项目:

显示 Chris 的连续任务以便他不超额预订的 Microsoft Project 视图

同样,一切看起来都非常完美。 Chris 的任务分摊到了两周中,而不是之前的一周,这里展示了为什么必须将一个任务推迟到第二周,以保证正常完成所有任务。 此外,这里显示出 Chris 要连续从第一周工作到第二周。

这一切看起来都没问题,直到我们在计算中又添加了一个资源为止。 让我们回到第一个情景,为项目多加几项任务,然后将这些额外的任务分配给其他人:

显示 Chris 和 John 的任务的 Microsoft Project 视图

现在,有两名员工正在同时工作。 Chris 又回到了过量分配的情况(可以看到,他的两项任务都处于第一周内),另外我们还为 John 添加了与 Chris 的任务同时启动的三个任务。 但 John 的任务已经完成资源平衡,三个任务之间按顺序排开。 单独看 John 的情况时,一切都没有问题。 John 从第一周开始,连续工作到第二周,但如果现在运用资源平衡算法,会发生什么情况?

显示 Chris 和 John 的任务以及 John 的一周间隔的 Microsoft Project 视图

Project 会像先前一样平衡 Chris 的时间, Chris 的工作将从第一周持续到第二周。 但 John 会有整整一周的无工作间隙时间,他要等待 Chris 完成第二个任务后才能继续自己的工作。 我们绝不希望 John 闲上一个星期,只是坐在办公隔间里读读报纸,因此现在要由 John 和 Chris 的主管手动管理其时间安排。

在这里,我们只是举了一个包含两个资源的最简单例子。 如果涉及到一整支团队、影响多个项目、每项任务涉及多名人员,整个挑战会更加复杂。

这并不是 Project 的错。 市面上几乎所有具有资源平衡功能的调度工具采用的都是这种资源平衡方式。 首先计算关键路径,然后根据您选择的选项对计划应用资源限制。 不同的系统有着不同的选项,但在向个人应用资源平衡算法时,通常就会产生上述问题。 现代项目调度人员早已了解,如果必须在个人层面上执行调度,那么就不应该应用传统资源平衡。

这也是 Project 等分析工具不会向 Outlook 这样的资源承诺系统推送信息的根本原因之一。 究其本质而言,Outlook 应视为一种个人承诺系统。 每一天,您都要在 Outlook 中做出承诺。 您向某人承诺,您将在下周某天下午 2 点时前往某个约会。 (这里说的某人可能就是您自己。)您向某人承诺,在本周二之前完成某项任务。 今天,我们会查看 Outlook 来了解需要完成哪些任务和约会,然后使用系统的通信功能答复他人,说明我们做出或申请的承诺。

想象一下将这一功能与 Project(Project 本质上是一种分析系统)集成。 首先要将 Project 或 Project Server 中的活动移动到 Outlook 中,并检索相关进度。 如果某人的 Outlook 任务集成回了计划中,又会怎样? 我可能在下周清早约了牙医。 我是否应该让这个持续 4 小时的可用时间缺口影响我未来计划的每一项任务? 是否每项任务都应延后 4 个小时? 与我互动的所有人以及受我这四小时延误影响的人的计划又会发生怎样的变动? 是否全公司都应该收到表明全部计划延后四小时的电子邮件? 但这还不是最糟的,毕竟这里只考虑到我一个人的情况。 如果所有人的 Outlook 承诺都会影响到公司内每个人的每项任务,情况又会如何? 简而言之,整个情况将一片混乱。

如果我们要将 Outlook 这样的资源承诺或资源沟通工具与 Project 或 Project Server 这样的资源容量规划工具集成,我们就需要协调两种模式之间的理念差异。 设计 Project Server 与 Outlook 的链接时,必须要考虑到这些问题。 Outlook 应该可以接收 Project 中的任务,并将任务集成到 Outlook 日历或任务列表中。 但绝对不能允许 Outlook 向 Project Server“推送”任务。

创建资源管理系统

到了这一步,您可能希望我提供一些建议,告诉您如何创建资源管理,当然我也确实可以提出几条建议。

首先,最值得讨论的一个问题就是资源管理的哪些方面适用于您的组织,您可以迅速从哪些方面中获益。 资源管理的某些方面比其他方面更难实施的情况极为常见。 我总是渴望先实现那些触手可得的成果。 举例来说,您可能对资源容量规划更感兴趣,但发现创建此类流程以及 收集所有数据以创建一致的流程无比艰难。 与此同时,您或许发现实施采用时间表系统的资源跟踪可以帮助您减少企业文化方面的障碍。 因此,首先应该统揽全局,确定是否应从其他方面着手实施资源管理。

考虑资源容量规划时,必须认识到任何资源平衡算法在个人层面上的资源定义都存在问题。 既然如此,接下来就可以考虑在技能或一般层面上进行资源平衡,由团队主管负责个人的具体任务分配。 这往往是 EPM 部署中最令高管失望的一个方面。 任何没有全面考量所有潜在可能性的人都很可能设想出这样的系统:在某个中央位置集中完成分析,它不仅能神奇地协调所有人员的日常日历及个人和企业承诺,还能保证每个工作日都为每名人员分配足够多的工作量。

如果您关注资源容量规划,我想向您提出一条不那么常见的建议。 在任何高科技组织中,个人层面上的技能调度都十分常见,因为许多人都拥有一组独特的技能和支持组合,尤为适合负责某些类型的工作。 如果您的情况也是如此,那么就应考虑创建一个“关键资源项目”。 根据我的经验,组织中的关键资源仅占全部资源 5% 以下的比例。 这些关键资源就是对每个项目都有着重要意义的人才。 他们拥有他人所不具备的技能和知识组合,成功的项目经理了解如何确保争取到一名关键资源参与其项目,以力保项目成功。

关键资源项目可以是仅仅包括分配给这些人员的任务的清单。 您可以对其工作进行资源平衡,然后让团队主管去随意调度所有其他相关资源。 这项工作几乎可以立即投入实施,所需工作量也相对较少。 尝试过这种方法的组织发现,它能解决资源平衡中的大多数麻烦,而且不会像影响所有人的变革那样造成企业文化和流程改进方面的难题。

此外,在考虑解决方案时,最好不要局限于 Project Server,就像 Microsoft 的 Project 团队做的那样。 毕竟,“Microsoft EPM 解决方案”是一种技术堆栈。 如果能考虑到资源管理的所有不同方面,Windows SharePoint 服务、Windows 工作流、Office SharePoint Server(用于表单)、SQL Server 都能成为有用的工具,帮您打造出一种根据组织需求度身定制的理想环境。

关于作者

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

×