基于PLM平台的项目管理实践与反思

　　对于项目管理，目前市面上有不少管理平台或软件，但基于PLM平台，以制造业的产品开发或研发为视角的项目管理平台较少，而且使用PLM平台进行目管理也鲜有赢得客户口碑的案例。有鉴于此，本文以甲乙双方不同人员的视角，试图复盘某企业的项目管理实施过程，分析从业务调研，技术实施乃至项目管理过程中的得失，以期抛砖引玉，促使后续其他项目能更为健康有序的实施。

　　本期项目是PLM的二期工程，一期已经实现了基本的产品数据管理，具体完成内容如下：

　　1.CAD与PLM/PDM集成，实现通过MCAD数据生成EBOM。

　　2.物料及各类图纸发布和变更流程。

　　3.数据查询，可通过字段进行常规数据查询，也支持通过Solr引擎进行模糊搜索。

　　4.产品库，文件夹结构，权限管理，实现基本的数据存放及取用。

　　5.物料取号，结合物料分类（和SAP）获取物料料号。

　　6.SAP集成，实现物料基本视图及产品结构（EBOM）向下游自动准确传递。

　　项目管理的几个先决因素

　　对于项目管理的实施，而且还是基于PLM平台的项目管理，需要甲乙双方步调一致。双方至少需要明确：这是一个中高层级的项目，要站在更高的角度，宏观的来看待。对于项目管理这类项目，应该要对下述问题进行正面回答：

　　1.平台给谁用

　　项目管理平台通常涉及的部门、人员非常广泛，那么如何回答这个问题才能***企业当下的实际情况？项目管理平台通常是企业**次实施，此时最需要考虑得就是企业管理层面的需要。具体来讲涉及以下几点：

　　a)项目类型定义及划分

　　在项目管理实施初期，切忌求全思想。通常企业内部的项目有如下几种：产品开发（变型设计及订单交付）、产品预研（包括市场调查、竞品分析、工业设计等）、技术预研（这部分主要为超前技术研发，例如含WIFI功能的插座面板、多插座转换器等）、精益设计/生产项目等等。

　　通常，没有经过管理咨询的企业，其项目类型的定义及划分的边界是不清晰的，所以往往在实施过程中，会经历频繁的变动，在此建议甲方，在未经过实际实施及验证的情况下，不要贸然进行类型及划分的修改，应在有使用平台的经验后再进行调整。

　　b)项目交付物及齐套性检查

　　对于订单型交付项目，需要将产品研发过程中的交付物进行统一管理。部分企业为了避免相似问题的频繁发生，会考虑进行交付物的过程管理，所以需要进行项目交付物管理。这部分实施内容包括：交付物模板管理，交付物编号/版本管理，交付物的齐套性检查（按项目阶段），交付物变更管理等。

　　c)项目进度及基线管理

　　在企业领导层的日常管理中，常需要关注项目进度。当企业制定了年度战略目标后，就会根据目标并将其拆分给每个部门，并订立KPI考核基准。所以年度目标是否能完成，就势必依靠项目计划来进行统筹。考虑到各任务的难易度不同，每个项目也会给予不同的缓冲时间。所以项目实际总周期及项目预计总周期是PM及PMO都十分关注的重要信息。

　　d)项目变更及控制管理

　　项目执行时，会因各种情况（计划内或计划外）而导致项目周期、交付物、人员、费用、范围等发生变化。此时若对项目总周期或阶段周期有较大变化时，则必须要进行项目变更管理控制。但控制到何种程度？给予PM多大的自由则需要根据企业的实际情况进行斟酌。

　　e)资源负载均衡管理

　　目前企业常面临着骨干工作量过多的现象，具体表现为：只要有新的重大项目就需要技术骨干参与，新员工或者技术较弱的员工常处于“游离”状态，结果就是技术骨干随着资历增加工作忙碌程度也日益增加，且也时而发生多项目并行而顾此失彼的现象，出错也就在所难免了。所以企业急需一套行之有效的人员状态管理工具，以便于项目执行及新项目开发时，进行资源负载平衡。

　　f)项目报表管理

　　项目报表作为项目监控的主要依据，需要体现项目的实际情况。但对于企业，必须要选择合适的数据以避免失真的数据影响PM或者PMO的判断。所以除了要求用户使用系统，并从系统获取原始数据外，还需要制定适合当下的规章制度。让所有人在同一套制度下协同办公，这才是企业项目管理能获得成功的必要条件。

　　2.平台怎么用？平台使用目的是什么？

　　只有在确定系统主要给哪些部门或者哪些角色用之后，才可以回答使用的方式及目的。其使用方式有：全手工，手工+系统，全系统3种方式。使用目的可根据企业自身情况分为：资源合理安排及交付物管理（侧重项目安排），进度及风险管控（侧重监控）以及全流程全要素协同（侧重协同）。

　　使用方式

　　三种模式的差异，并不一定意味着哪种模式**。而是要根据企业当前的现状，结合项目类型进行选择及剪裁。

　　a)全手工

　　适用于企业成立时间较短，尚未形成稳定且统一的项目制度，难以提供出一套适用于所有项目相关部门的执行制度。

　　也适用于技术预研或产品预研类型的项目，对于未知领域，项目的执行不能完全按照WBS，需要根据每一个任务的实际情况进行手工微调。甚至当预研出现较大变化的时候，需要及时止损并暂停项目，归档项目执行过程中的所有交付物，以便后续条件合适时再重启。当然也有可能因为外部条件变化，导致项目**关闭。

　　b)手工+系统

　　适用于企业已具备一定的项目制度，但因种种原因导致项目执行效率并不乐观，所以除系统按WBS执行时，还需要辅佐一定的人为干预，此类情况大多为临时性的，一旦企业理顺项目类型及进度任务关系，并适当修订规章制度后则可全部转为全系统执行。另外如果因为任务涉及核心技术或者交付物中涉及战略客户，则为了保障信息不被泄密，可以将核心信息暂存他处，并沿用手工+系统执行的方式。

　　c)全系统

　　适用于企业已制定较为完备的规章制度，且项目相关人员可以在此制度下默契执行项目。此类模式主要应用于成熟产品的改型设计及订单交付，很少适用于研发性质的项目。

　　使用目的

　　通常使用目的得根据主要使用部门来定，比如项目管理部作为主要使用部门，研发、工程、物流等部门为配套部门时，多以项目进度及交付物为主要管控目的，所以此时偏重于订单合规交付以及项目进度的纠偏。

　　若以研发、工程部门为主要使用部门，则多以项目质量为重。所以综合来看：当企业初具规模时，因各条件尚不具备，所以项目经理多以资源协调及交付物管理为重。当项目管理平台使用半年后，整体项目管理模式成熟及项目经理可以通过数字化平台纵览全局后，则能提升至项目进度监控及风险管控。此时项目经理会根据各成员执行情况进行干预甚至提前协调任务优先级，并管控订单交付或研发过程中的部分质量问题，此时WBS及交付物可能出现比前期更为频繁的变更，所以此阶段的各部门磨合期会持续较长时间。从PMO管理甚至企业战略的角度来看，企业高层在此时应更多的处理好部门及角色的职能边界问题，当岗位职能及执行策略都形成具体的“方法论”后，则进入至全流程全要素协同的状态（可参考IPD）。

　　2.1 创建项目计划

　　分解复杂项目和方案成可管理的组件，在一个非常大的项目或者方案中，定义一个顶层结构，接着定义一级的活动计划和任务接受者，一级任务接受者可定义二级的活动计划，三级的依次类推。

　　1.WBS在项目立项阶段，其定义过程如下（包括前后事件关系）：

　　2.项目经理根据项目类型（ODM/OEM……etc.）通过模板创建项目；

　　3.系统支持将现有项目另存为新项目。

　　4.通过项目模板创建项目，同时项目经理将OA中关于项目立项的信息填写在创建的项目属性中；

　　5.由项目经理或者财务、产品经理完善项目相关的财务、采购等信息；

　　6.项目经理维护项目团队及其主要成员，例如各职能担当；

　　7.线下通知担当，由担当将项目过程中所需要的其他成员添加至团队中；

　　8.在项目启动前项目经理与各职能担当一起完善WBS，并针对具体的活动设置必要的交付物；

　　9.当项目经理及担当都完成WBS及交付物定义后，由项目经理做最终确认，并执行“启动”操作，至此立项阶段所有工作事项完成。

　　以企业某项目实例为例：

图1 项目计划（WBS工作分解结构）

　　系统可根据子任务的完成情况，自动计算其父活动的工时。并且通过逐级计算的方式，自动统计项目所使用的工时，便于项目经理实时浏览查阅。

　　2.2 项目一级计划锁定

　　在项目执行过程中，会因为各种计划内或计划外的情况变化而导致项目周期及交付物、甚至参与人员发生变化，若项目经理经常随意改动WBS及参与人员，则会导致PMO对项目进度、质量、费用的监控失败。但是如果不授予项目经理一定的权限，则又会导致变更在逐级审批时的时间浪费，从而影响项目的实际执行。为折中两种情况并兼顾岗位职能，所以仅针对一级计划进行PMO层级的管控，以确定大的项目周期变更处于可控范围内，同时授予项目经理修正除一级计划外的其他任务权限。

　　在WBS中，一级门槛计划需要被设置为锁定。非一级计划可视情况需要定义其是否锁定。锁定意义为：

　　1.此任务的所有信息都不可被更改，但不包括交付物。

图2 项目一级计划锁定

　　2.当任务完成后（百分比为100%），系统自动将任务设定为锁定。

　　非一级计划的交付物不受锁定限制。其保证项目在进行过程中，可以对过往交付物进行变更或者替换，项目经理可通过“齐套性检查”查看项目所有交付物状态。

　　3.一级计划解锁需要上传变更单。

　　将本地的变更单上传后，所有锁定的任务将临时解锁24小时。若在24小时内修改没有完成，则寻求PMO项目管理员协助，重新解锁。

　　若24小时后发现项目经理修改不正确，则线下执行纠错流程，通过后由PMO项目管理员手动重新打开锁定，项目经理线上重新调整。

　　2.3 项目资源管理

　　建立多层级的资源库管理架构，满足不同企业的组织架构需求和业务扩展需求；例如：针对一个集团性的企业组织结构，不同的子公司定义和管理自己的资源库，这些资源将用于每一个子公司的项目。

图3 项目资源结构树

　　多层级的企业资源库,以下是系统中每一个组织的资源库。如果要管控项目的资源成本，则需要为每一个资源定义单位成本（价格）；同时，需要为人力资源定义角色。每一个人力资源可以承担多种角色。

图4 项目资源池

　　关于资源费用这部分，为保证系统的可扩展性以及兼顾未来与HR系统对接，预留人力资源成本内容，现阶段可不用考虑维护这部分属性信息，待后续时机成熟，再引入人力资源成本信息，以统计项目的人工费用。

　　针对某个项目的团队，可以根据企业的实际业务定义，灵活的添加角色，以及在角色下添加相应的成员。项目的团队模板可以提前定义，便于提高项目团队定义的效率。当项目创建后，团队成员也可根据实际情况进行调整。

图5 项目团队

　　基于资源，系统可以依据企业的业务需求按多维度统计透视资源（按部门、按职位、按项目）。基于项目计划工作量估算，可实现资源短期冲突分析。

　　ODM/OEM/策划/精益的角色与新产品开发项目保持一致，若实际项目发生偏差，可在项目启动时进行角色裁剪。

　　2.4 工时管理

　　工时是WBS的一个有机组成部分，不可或缺。系统根据WBS的主要功能，结合实际业务场景，定义了一系列的计算规则，现将影响工时的因素罗列如下：

　　1.日历

　　根据不同国家/企业，定义系统**的日历。例如：周一-周五为工作日，周六周日为双休。

图6 项目工作日历

　　2.资源及资源使用率

　　在系统中，每一条任务都会自动计算工时。任务工时的统计量由承担任务的各个资源乘以其使用量再乘以其工期计算得出。因任务持续时间（工期固定），所以系统默认将所有资源对于任务的使用工期都定义为任务的工期。

图7 项目活动

　　以上图T0制作任务为例，共使用市场担当、采购担当等14个不同类型的资源，同时默认每天8小时工作时间，持续工期为38天工作日，所以总工时为14*8*38=4256工时。

　　若将市场担当的资源使用率改为20%，则工时为13*8*38+8*0.2*38=4012.8工时

图8 项目活动及其资源分配

　　其业务含义为：在固定的38天工期内，由14人资源组成的团队，根据其不同的使用率，计算出此任务的工时总额。

　　若将此任务类型改为固定工时，则以上一次修改的总工时倒算出所需的工期。例如以4012.8工时为例，现将类型改为固定工时。同时将资源由14人调整为22人，且每人的使用率为100%，则工期为4012.8/22/8=22.8天。

图9 资源负载及工时统计的关系

　　2.5工时填报

　　当项目经理及担当完成了工时及工期定义后，就会发起项目。项目在执行过程中，每个任务的参与人员都要根据实际情况，进行工时汇报。单个任务工时汇报如下：

图10 跟踪工时

　　在WBS界面中，找到跟踪工时按钮，点击进入工时填报界面。系统会自动根据自己所使用的资源情况，计算出可以填报的总工时。工程师需要根据业务情况，填写任务完成百分比。

　　例如：

　　1.任务完成50%

图11 完工率填报

　　系统会根据完工率*工时得到实际工时，此处为50%*182.4=91.2小时。

　　2.任务完成16小时

图12 工时填报

　　系统计算逻辑为：

　　完工率=实际工时/工时=16/182.4=8.7%≈9%

　　剩余工时=工时-实际工时=182.4-16=166.4小时

　　2.6项目基线及交付物管理

　　计划基线会创建计划在某一时刻的快照，在计划基线中可捕获以下对象：

• 　　计划

  
  

• 　　活动、汇总活动和里程碑

  
  

• 　　可交付结果

  
  

• 　　资源

  
  

• 　　资源分配任务

　　项目基线的主要目的在于项目计划变更前后的对比，用以使项目经理快速获悉变更的差别。比较A：

图13 基线对比（概览）

　　活动计划与当前计划进行对比，通过查看排程中的差异比较视图

图14 基线对比（无差异）

　　因两基线工时及工期都没有偏差，所以差异显示为0。比较B：

图15 基线对比（概览）

　　因两基线工时及工期都有偏差，所以差异比较页签中显示如下：

图16 基线对比（含差异）

　　基于交付物管理业务，对项目管理功能进行分析，定义系统实现的业务逻辑，实现交付物管理模板、交付物完成率校验、质量评判和过程交付物齐套性管控。

图17 交付物与WBS的关系

　　另外，在 PLM项目管理 中构建交付物的文档类型，将输出交付物的模板在系统进行统一管控，做到过程交付的标准化与规范化管控。

　　基于计划活动的关联交付物校验机制，并增加项目计划活动实际完成时间的设置机制，校验交付物完成 100%、计划活动汇报 100% 后系统自动设置计划活动的实际完成时间，供项目过程监控管理进行项目执行进度偏差率的统计，进而掌控关键计划活动的进度情况，尽早识别项目过程风险，调配团队资源和计划活动的执行方案，或加强项目执行过程沟通，使计划活动按照预定的流程和时间节点执行。

　　项目团队的成员进入项目页面后，切换至计划页签。点击交付结果，系统自动刷新以下界面：

图18 交付物齐套性列表

　　2.7项目风险及问题管理

　　想要消除风险对项目的消极影响首先应该将其识别出来，比如风险的来源、产生的条件等，并分析该风险发生的概率和对项目造成的影响。项目风险的识别并非是一蹴而就的事情，应当贯穿于项目的整个生命周期内。

　　记录风险的相关信息，风险的的描述，风险的信息可以根据业务的需求进行扩展，指定风险处理的负责人。风险因未发生，所以只做风险登记，尚不需要流程审批。

　　在项目进行过程中，应当建立一套健全的问题管理机制，这样在发生一些问题的时候可以快速反应，有效决策，防止问题的进一步扩大。

图19 项目风险列表

　　当项目问题单独定义为产品问题，除产品以外的问题，则可暂不在PLM系统中管理。其具体管理方式如下：

　　1.项目经理（问题管理员）将问题处理区分为需短期处理措施的问题及需长期处理措施的问题。

　　2.项目经理线下召开会议讨论问题的处理办法。

　　3.讨论确定后，根据Excel模板，填写相关内容，线上导入至系统中，系统根据Excel单元格位置，自动提取相应数据。

　　4.短期措施处理的问题导入后直接处于已发布状态。

　　5.长期措施处理的问题需执行问题关闭确认流程。

　　6.长期措施的问题，支持项目经理线上编辑（应对措施驳回）。

　　7.当所有内容确定无误后，项目经理（问题管理员）手工选择需长期措施解决的问题，将问   题提交问题措施确认流程。若流程通过，则批量提起的所有问题都通过。若被驳回，则所有问题都被驳回。

图20 产品问题清单

　　2.8项目看板及报表管理

　　通常项目经理通过报表及看板来监控项目的运行状态，并根据具体信息进行纠偏。所以此部分信息的准确性则尤其重要。但从项目管理推进的角度来看，在项目管理**期就制定详细的项目报表则风险非常大，其原因在于：项目管理平台上线使用初期，会伴随着磨合甚至职能调整的情况。在此之前就进行报表的规划会因为业务的调整而面临报表信息变化的可能，而且这种可能性会非常大，建议企业在项目管理平台落地后再行规划。

　　但本次企业依旧对项目报表提出了如下实施内容：

　　1.项目预算

图21 项目预算看板

　　2.项目变更

图22 项目变更看板

　　3.单项目看板

图23 单项目报表原型

　　4.项目问题报表

图24 项目问题报表原型

　　5.人员负载表

图25 资源负载表原型

　　6.多项目看板

图26 多项目看板原型

　　项目管理模块是很多企业继PDM项目实施后会跟进实施的项目，但常因实施结果不理想，对企业内部的项目管理起不到作用而废弃不用。究其原因在于，项目实施时一味的求大求全导致项目实施困难重重，又因企业内控不佳，导致岗位责任制度不明确，一味的求效率而忽视职能之间的配合，最终使项目管理流于表面，并未解决项目的实际问题。

　　在本次项目实施过程中，最值得注意的就是如何进行部门权益之间的平衡，本身产品开发过程中就会牵涉多个部门，如何平衡各部门的关切是需要甲乙双方重点关注的内容。

　　项目管理功能还需要在实际应用中不断优化，项目成员也在项目不断中磨合，以期让PLM项目管理发挥应有的作用，为客户的项目管理提供有力支撑。

　　系统是最终将企业规章制度落地的工具，切不可将业务问题寄希望于系统来解决。管理问题终归需要管理来解决，不可缘木求鱼。每个公司的管理方式和关注点都不相同，本文只抛砖引玉，希望能与同行切磋交流并共同提升项目管理能力。