随着PLM系统的深入应用，项目管理功能越来越受到企业的重视。然而，如何上线好、推广好、使用好项目管理系统，面临着诸多困难和挑战。本文结合作者近几年来项目实施的经验，分析总结了影响项目管理系统成功的因素，并根据这些分析，提出了相应的实施建议，供读者参考。
本文所说的“项目管理”，不是指PLM系统实施过程的“项目管理”，而是指系统的“项目管理功能”，帮助企业管理产品开发过程中的人员和过程的系统能力。
在笔者以往实施的PLM项目中，尤其是初上PLM系统的项目，往往聚焦在“数据管理”功能。项目管理往往在数据管理之后再考虑。但在最近几年实施的PLM系统项目，“数据管理+项目管理”几乎成了标配。仔细分析一下，可能有以下几个原因：
（1）PLM市场的成熟。以往实施的PLM项目，处于PLM导入期。如何管理好数据本身，已经是一个很大的挑战。因此对于项目过程的管理，即使需求迫切，也不会马上提上日程。但经过近二十年的熏陶，数据管理已经比较成熟，加上市场竞争压力增大，企业对于设计结果的“数据”，和设计过程的“项目”，都希望能管理起来，因此项目管理实施越来越多；
（2）项目管理的普及。现在项目管理越来越普及。这一点，从每年参加PMP考试的人数就可以看出。采用“项目”的方式开发产品已经成为普遍做法，因此对于“项目管理”的管理，已经成为企业不得不面对的问题；
（3）内部管理的压力。随着竞争压力的增大，企业每年要并行很多个项目。每年上百个项目同步开发很常见，并且根据市场的要求，中间还会增加临时项目或紧急项目。企业是否有充足的资源并行开发这么多项目？资源是否已经充分利用？是管理层和领导层都关注的问题。获取和分析资源的利用情况，往往也是企业迫切想上项目管理的原因之一。
以上是本人分析的项目管理越来越普遍的原因，也应该是企业想上项目管理的原始动力。不管最终原因是什么，上好项目管理系统，利用项目管理系统管好项目，成为每个上项目管理系统的企业的“初心”。然而，在实际实施和推广的过程中，却往往有伴随着很多挑战和困难。
实施和推广项目管理的难度，往往比数据管理大。这倒不是因为项目管理本身很复杂，而是项目管理中涉及到很多“人”的因素。相比于数据管理所管理的“物”（数据），项目管理所管理的更多的是“人”。对于“人”的管理，光靠系统是不行的。对于项目管理系统成功推广的概率，我总结为以下公式：
项目管理成功概率=项目管理制度完善度 x 系统功能支撑度 / 变革阻力
项目管理制度完善度：企业项目管理制度本身的完善情况及执行情况。这里所说的完善度，不仅仅是有一份《项目管理规章制度》，而是在切实执行，并且在企业内部得到普遍认可的“完善的”制度。
制度越完善，项目管理成功的概率越大。
系统功能支撑度：项目管理系统功能的完整性和
符合性。企业的项目管理，往往都有一些通用的部分，和一些个性的部分。项目管理系统必须对通用的部分提供“最佳实践”，对个性的部分，提供可定制的能力。系统功能支撑度越高，项目管理成功的概率越大。
变革阻力：推行项目管理，往往需要做一些改变，包括工作的习惯，考核的办法，可以算得上是一个小的“变革”。如果企业没有变革的基因，就会在各方面遇到阻力，最终导致制度和系统难以推广。因此，克服内部变革阻力，也是项目管理实施面临的重大挑战。变革阻力越大，项目管理成功的概率越小。
以下，我将从这三个方面，根据个人经验进行总结分析。
完善的项目管理制度可以说是项目管理的首要因素。关于项目管理制度，几乎每个公司都有一份制度文件，内容往往相似但又不尽相同。我认为，一份完善项目管理的制度，必须包含以下几个方面的内容：
图1 项目管理制度需要包含的4个方面
管理决策：在项目成立和执行过程中，面临着很多决策点。如项目立项的决策，项目执行中的管理评审，项目变更的决策，等。这些决策过程必须有明确的规定，并且对决策人或团队充分授权。如果决策定义不清晰，项目就会面临推诿扯皮的现象，执行人无所适从。所以，项目管理制度中，必须要有对项目管理决策点的明确规定。
流程规范：企业可将产品开发过程按照过程不同归为不同的项目类型，如全新产品开发，变型产品开发，课题研究项目等。对于同一类型的项目，可以总结经验，整理为标准的产品开发流程，包括项目阶段，参与角色，角色人物，等，从而形成标准的WBS。这样可以做到分工明确，任务清晰，方便整个过程的管理。因此，规章制度中，必须要明确项目分类，并对每类项目的标准过程进行定义。
组织能力：项目管理归根到底是“人”的事情。每个项目成员如何分工？职责是什么？权力如何分配？直接关系到任务能不能分下去，干下来。因此，人员职责的定义，能力的要求，是管理规范中必须定义的内容。这一部分，甚至高于“流程规范”。
绩效指标：如何评价项目，如何考核成员，往往是项目成员的原始动力。项目绩效指标需要在定义指标的同时，定义如何最终测量指标达成率，以及考核办法。然而，因为测量方法不好定义，或最终利益不好分配，很多管理规范中避讳谈绩效考核这一块，这也造成了项目过程中成员动力不足，推行困难。所以，完善的项目管理制度，必须包含项目绩效指标的定义，测量方法和考核办法。
企业在实施项目管理系统之前，首先要审视一下本企业的项目管理制度。如果以上方面有缺失，建议先完善项目管理制度，并贯穿实施一段时间，观察效果，持续改进，直到制度能够完全贯彻执行。如果管理制度不够完善，或贯彻不下去，想通过系统来代替制度，无异于缘木求鱼。
项目管理系统属于工具层面，在规则制度得到贯彻的前提下，借助有效的项目管理系统，可以很好的记录和汇总项目执行中的数据，方便项目过程的记录和追踪。并且，好的项目管理系统，还能实现一定程度的自动化工作，对于管理层和领导层监视项目执行情况，带来很大便利。
一般而言，PLM项目管理系统会提供以下功能模块：
3.1 计划和进度管理
按照PMP的理论，“计划”包含九个领域的计划。但在实际执行中，计划往往等同于“进度计划”。对“进度计划”的管理，也就是我们项目经理常说的“计划管理”。现在的项目管理系统，计划管理也常指进度计划，是系统的核心功能。以下是某系统“计划和进度”管理的核心过程。
图2 某系统项目计划和进度管理的过程
“计划和进度管理”的核心是WBS。通过WBS，系统可以将人员、活动、交付物，以及报表联系起来。实现计划的在线制定、任务的自动分发、任务进度的收集，以及报表的自动生成。这一部分，与“项目管理规章制度”紧密配合，能够达到比较理想的效果。
3.2 交付物管理
这部分是“产品数据管理”和“项目过程管理”的最佳结合点，也是很多企业进行项目管理系统选型时需要考虑的点。任务交付物与项目任务关联，甚至交付物完成驱动任务完工，是一个很自然的逻辑。如果项目管理系统与数据管理系统为同一个系统的两个模块，则这两部分一般会很自然的结合。但如果项目管理系统和数据管理系统是两个分开的系统，则面临着系统的集成，对于系统实施是一个不小的挑战。
3.3 预算和实际费用管理
项目预算和实际费用的管理，是很多项目经理和财务关注的问题。这一部分功能，往往很难在一个系统中实现。原因很简单：实际费用往往来源于ERP或财务系统，不太可能在项目管理系统中记录。因此，对于预算和实际费用的管理，往往是在项目管理系统中进行项目预算管理，然后与ERP或财务系统集成，定期获取实际费用信息，与预算值进行对比分析。
3.4 项目报表
项目报表是领导层和管理层最关注的功能。因此，有针对性的项目报表往往会极大提升系统的价值。然而不幸的是，项目报表的变化性很大，不同人可能关注不同的数据，因此，想穷尽所有的报表类型，往往不可能，并且代价太大。对于这种情况，建议分角色精选报表。针对不同角色，系统定义几个其最关注的报表。其它类型报表，可以从系统导出数据，自行分析。几类角色的典型报表包括：
公司领导：整个公司所有项目的分类展示、状态展示、异常项目的分布情况；
部门领导：本部门参与项目的情况，部门员工项目参与情况；
项目经理：所负责项目的状态和进度，项目任务状态和进度；
员工：参与项目情况，所负责任务清单及状态。
以上是建议的几类报表，也可以根据公司实际情况定义一些特殊报表。但要记住，不要试图通过系统得到所有的报表。
3.5 项目问题管理，风险管理
项目管理系统一般会提供项目问题和风险管理。这部分功能主要需要考虑清楚项目问题和产品问题的区分。在产品数据的变更管理中，一般也会提供“问题管理”。这里主要指“产品问题”，产品问题触发变更请求，变更请求引起数据变更。这两个有重合的部分。我们一般可以定义：产品相关的问题，通过数据管理模块处理。项目管理相关的问题（会引发项目范围，周期，预算等变更的问题），通过项目管理的问题管理模块进行管理。
所有的变革都会遭遇阻力，只是阻力的大小不同而已。PLM项目管理实施中的相关人，典型分为以下几类（圆圈大小代表人数多少）：
图3 项目管理系统相关方分
析
领导层：领导往往对项目管理系统持支持态度。实际上，实施项目管理系统往往是领导推动的。因此，领导层往往是项目管理系统的支持方。并且，领导层拥有决策权，对项目管理系统有很多推动力。但领导层也面临着来自广大员工的压力。
部门经理：部门经理对项目管理系统一般持反对看法。因为项目管理系统会一定程度上削弱部门经理对部门员工的权力。如果执行“项目制”或“强平衡矩阵”，则意味着项目经理可以直接为部门员工分配任务。对部门经理而言，项目管理系统若不能给他带来部门管理方面的价值，他们多半会反对项目管理系统。
项目经理：项目经理对项目管理系统比较矛盾。一方面，他们希望借助项目管理系统分发和跟进任务，避免以往靠他们“嗓门大，关系好”的方式推项目。但另一方面，项目管理系统依赖细致准确的项目计划，则又对项目经理提出了挑战。所以，项目经理们对项目管理系统的需求，是希望系统能简化项目计划的过程，但又能借助系统跟进任务和收集信息，可谓“爱恨交织”。但总体而言，偏向于支持。
项目成员：广大员工是项目管理系统的直接使用者，也是有力的反对方。因为对于员工，项目管理系统并不能直接为其带来价值，反而需要他们反馈工时、交付物、填写进度，增加“额外工作”。因此他们基本都是反对的。并且人数众多，是项目管理推进的主要阻力。
基于上述的分析，建议在项目管理系统实施过程中，采用“满足领导层，争取中间层，方便基层”的策略。
对于管理层，要满足其通过系统了解公司项目执行情况，资源使用情况的需求。通过系统报表功能，及时、准确地为管理层提供项目信息。
对于部门经理和项目经理，需要充分了解其对项目管理系统的需求，为其提供管理价值。同时也要简化他们的操作，减少来自他们的阻力。
对于广大的项目成员，实施的主要工作是尽量简化系统操作复杂度，让其在项目数据反馈上面所花的时间降到最低，减少他们的抵触情绪。
当然，以上都是在系统层面的努力。我们还需要在管理方面予以配合，尤其在推广初期，需要借助统计、通报，甚至一定的奖励惩罚措施，保证系统一开始能推动起来。
总之，项目管理系统是随着PLM数据管理的成熟，项目管理方法的普及，以及企业内部管理的压力共同作用的结果。按照我们实施的经验，项目管理系统实施的成功率，是由“项目管理制度完善度”、“系统功能支撑度”和“变革阻力”共同决定的，并不能通过单独改善某一个因素达到理想的实施效果。企业在实施PLM项目管理前，先要审视本身项目管理制度的完善性；在PLM项目管理系统选型中，要审视系统功能的匹配性。二者可从借助分析模型进行分析（如图4）。
图4 项目管理系统实施的分析模型
另外，在实施和推广的过程中，要想方设法减小变革阻力。建议采用“满足领导层，争取中间层，方便基层”的策略。并配合一定的奖励惩罚措施，才能使PLM项目管理系统顺利推行下去。
