1、前言
  我们常说PLM项目的实施是一个复杂的系统过程。之所以这么说，一方面因为对实施PLM的企业来说，PLM系统的贯彻执行涉及很多横向和纵向的部门，覆盖多个业务流程，会对相关员工的日常工作产生巨大影响，具有一定的推广难度；另一方面因为对供应商来说，系统实施周期较长，投入的人力多，需要有专人从整体上把握进度和控制质量，确保项目按期完成，使公司的专业服务进入良性循环。在这样一个过程中，项目经理扮演着一个非常重要的沟通和协调角色。
   

  项目管理非常重视计划、执行和控制，但是要让项目的计划、执行和控制得以顺利进行，沟通和协调是不容忽视的一个重要方面。本文拟从供应商项目经理的角度出发，谈谈沟通与协调对于项目实施的重要性，以及如何通过良好的沟通与协调，给不同的项目阶段营造积极、热情的工作氛围。

  2、启动阶段（Startup Stage）
  启动阶段的主要目的是正式确认项目的存在，客户和供应商双方的领导层承诺为项目的开展提供资源，并授予各自的项目经理使用资源的权利。在这一阶段，PM应该着重做好的事情包括：
   

  2.1、通过Kick－Off会议正式启动项目
  Kick-Off会议参与者通常很多，包括双方的领导层、项目经理、项目组成员和业务部门代表等。客户领导发言宣布项目启动，强调项目对于实现企业业务目标的积极意义，任命客户方的项目经理；供应商领导强调对项目的重视程度，承诺为项目的实施提供一切必要的支持，宣布供应商方的项目经理。在Kick-Off 会议上，项目经理通常还不是主角，但会被要求向大家简单地做个自我介绍。 Kick－Off会议通常不要很长，1个小时左右即可，虽然没有太多的具体内容，但是它标志着项目的正式启动，其形式意义不容忽视。
   

  2.2、界定项目范围和总体进度
  这两点不但是必要的，而且是非常重要的。
   

  现实中有很多项目进展到后期无法正常收尾。双方对项目范围的理解不一致是导致PLM项目无法正常收尾的一个重要原因。为什么会这样呢？在向客户投标的过程中，供应商需要编写并宣讲自己的方案建议书；在这个过程中，由于各种原因，供应商通常会较多地强调方案的完整性和鲁棒性，有时大篇幅介绍系统的标准功能。而事实上这些功能点未必将来都会在项目中实施，具体范围还要受项目进度、客户预算等因素的综合制约。最终的范围应以双方拟定的作为合同附件之一的工作说明书（SOW, Statement Of Work）为基础。这一点往往被客户所忽视，作为供应商项目经理必须在项目启动后立即与客户项目经理沟通，结合SOW，将项目的具体范围进一步明确，澄清容易造成误解的描述。将哪些内容要实施，哪些内容不包括在本期项目中等信息明确的表述清楚，并以文字形式写到《项目工作手册》中。需要注意的是，这样做目的是使项目范围对双方来说都很清晰而且便于操作和衡量，而不是为了刻意缩减项目范围。已经在SOW中明确表述的内容不能减少，因为这是合同的一部分。就项目范围与客户进行讨论和确认是对项目经理沟通能力的重要考验，这个问题处理的越晚，对项目的损害越大。
   

  关于项目的进度安排，通常在启动阶段还很难细化到每一天做什么；但项目经理必须就其中的一些重大里程碑点与客户达成一致意见，如项目四个阶段（启动、计划、执行和移交）各自的起始和结束日期等等。由于启动阶段结束后项目将进入计划阶段，因此为了指导后续工作，在启动阶段的项目进度计划中，应对计划阶段的工作进行细致的安排，如什么时候开展访谈调研？什么时候完成初步设计？什么时候完成详细设计？如何评审等等。对于执行和移交阶段的工作安排，其时间节点可以先粗分，等到信息足够充分时再对其进行细化和更新。为了强化全体项目组成员对于项目进度的意识，建议每次项目组例会时都以相同的格式、用图示化的方法再次强调项目的进展状态，如图1所示。

 2.3、确定工作场所和沟通模式
  为了增进沟通，PM最好能够通过协商请客户提供一个专用的项目办公室，用于项目组日常的工作和讨论。项目组的沟通方式也应该以文字的形式记录到《项目工作手册》中。如每周举行一次非正式项目例会，每月举行一次总结会，每个阶段（启动、计划、执行、移交）结束时召开一次正式的项目组会议等等。
   

  值得重视的是，启动阶段需确定项目相关文档的存放和管理办法。为了保证数据源的唯一性和访问的方便性，我们可以建议客户在其内部网上放一个有权限控制的共享文件夹，在该文件夹下针对不同的文档分类建立相应的子目录。项目开展期间，PM将各种正式文档（如项目工作手册、项目计划、设计方案、会议纪要、讨论决定等等）交给客户的信息员，通过他/她将资料放到共享文件夹中相应的子目录下供项目组成员访问，如图2所示。
   

  2.4、启动阶段总结会
  作为启动阶段的总结和承接计划阶段的开始，启动总结会是非常必要的。双方项目经理，项目组核心成员都应被通知参加这一总结会。在总结会上PM回顾启动阶段的各项工作，将双方在启动阶段进一步明确的项目范围、总体进度计划、工作场所和工作方式、项目文档管理办法等信息非常准确地传递给会议参加者。特别地，PM还应介绍项目最终的验收程序和标准，并力争获得客户的同意和认可。我们往往对这一点有所畏惧或感到为难，一方面怕客户怪我们太迫不及待，项目刚刚启动就想着验收；另一方面，觉得系统设计还没开始，不知最后是什么样子，难以衡量什么样的情况表示项目可以验收。其实不然，项目是强烈地以目标为导向的，对供应商来说按时完成项目验收很重要，对客户来说，也只有项目验收了项目组的工作才能得到认可，项目成果才能得到进一步推广。从这个意义上来说，按时验收项目是双方的共同目标，需要共同努力才能实现，而明确验收程序有利于这个目标的实现。而且，这里谈的只是验收程序和总体标准（如按时提交指定的各项交付物，通过测试场景是否满足来验证系统的功能是否满足等等），并不涉及具体功能要到什么程度。事实上，具体功能的定义是在计划阶段才进行的。
   

  从启动阶段总结会开始，PM开始融入角色并且全面的安排和协调项目的各项工作。

  3、计划阶段（Planning）
  “计划阶段”更确切地应该被翻译成“规划阶段”，它是对PLM项目进行规划、初步设计、详细设计的阶段，这个阶段的主要产出物是《系统设计》文档。由于后续执行阶段的工作将以《系统设计》为依据，《系统设计》文档的不足或者错误往往会导致返工和延误，从而给项目造成较大的风险。因此PM应该协调各方力量，把握好这一阶段工作的质量。具体来说：
   

  3.1、组织和协调好需求访谈
  访谈的目的是为了更好地了解客户的业务流程，更好地在既定的范围框架下了解客户的具体需求，从而为系统设计奠定基础。好的访谈应注意三个环节：制定访谈计划、提高访谈质量和适当地回访。
   

  在访谈之前PM需根据项目范围，结合客户的组织结构与客户一起制定一个详细的访谈计划。该计划在得到客户项目经理的认可之后，由客户通知各相关单位的人员参加。建议在访谈前召开一次访谈者通气会，会上PM详细说明访谈的目的和过程，需要做什么准备等等，这样可以避免在访谈过程中被访者不知所措。另外，PM可以通过这个会议宣布访谈计划，让与会者确认自己的时间与访谈计划安排是否有冲突，从而及早发现问题，及时调整解决。

  为了高效利用有限的访谈时间，可以采取以下几个措施：
  （a）访谈前通过通气会向每个人就访谈目的、方式进行沟通，这样在每一段访谈开始前就无需重复；
  （b）建议被访者在参与访谈时携带一些本部门常用的文档模板和文件样本，以及与其它部门之间沟通时常用的文档模板和文件样本，这样做可以大大节省需求调研时间；
  （c）请被访者先简要介绍一下所在岗位的日常工作流程，并请他们描述工作中需要PLM系统进行改善和提高的方面；然后实施顾问结合项目的范围，有针对性的进行补充询问；
  （d）访谈结束前，简要总结所收集的信息，请求被访者核实，感谢他们为访谈付出的时间和进行的准备。
   

  我们必须尊重每一位受访者的时间，每次访谈都应该尽可能按时开始，准时结束。在两个访谈之间应该安排半小时左右的间隙。这个间隙既可以用于实施顾问简短的休息，也可以用于整理上一段访谈的内容，或者用作适当延长某些特别的访谈段落。但有时情况复杂，即使用完这半小时的缓冲，还是无法收集和了解所有信息。这时为了不影响与已经等候在一旁的其他人的访谈，PM还是应该非常果断地结束访谈。结束访谈前PM应该向被访者说明必须结束访谈的原因，并且商定一个对他进行单独回访的时间，以保证信息完整。

  3.2对需求进行整合和筛选
  PM以及实施顾问需对调研得到的信息进行汇总、分析、筛选和整合，形成需求调研报告。整合后的调研报告至少包括以下几个方面的内容：
  （a）被访谈人员的需求信息汇总；
  （b）结合项目范围分析哪些与本期项目相关，哪些不在本期项目范围内；
  （c）对于与本期项目范围吻合的需求，其优先性如何？ 哪几点是至关重要因而需要重点考虑和关注的？调研报告完成后，PM应召集一次项目组会议，邀请接受访谈的人员一起参加，宣讲调研报告的主要内容，与客户就以上(a)(b)(c)三点取得共识。
   

  需要注意的是：PLM项目中不同的部门、不同的人从各自不同的角度出发，总会有这样、那样不同的需求，有些需求甚至是互相矛盾的。PM必须从总体上沟通和协调这些需求，使得他们和项目的整体目标保持一致，这样才能使项目在既定的进度和预算下完成，盲目地承诺和扩大需求是对项目致命的损害！
   

  3.3、《系统设计》评审和修改
  这里想强调的是：项目计划中必须给《系统设计》文档的评审和修改留有足够的时间，因为从《系统设计》初稿完成到该文档评审定稿还有很多工作要做。第一稿通常是供应商根据需求调研报告，结合从客户那里收集来的其它文档和表格等资料而完成的。《系统设计》是面向后续开发的一份文档，它从各个方面定义了未来系统的数据模型：如文档、零部件的分类和属性定义，审批流程定义，角色及数据访问权限定义，与其它系统或者CAD应用程序的接口定义等等。初稿出来后，客户需要时间组织相关的业务人员进行讨论和确认，然后给供应商提供修改反馈意见。由于涉及各个部门、各个方面，这一反馈和修改过程通常需多次反复才能完成。PM至少应该预留一到两周的时间来完成这一活动，形成经过评审的最终定稿。

  3.4、定义项目业务场景
  与《系统设计》不同，业务场景是从客户的日常业务操作角度出发，对未来系统的一种描述方式，因而更容易用作与客户进行沟通。图4为业务场景的一个示例。如果PM能够在规划阶段与客户一起工作，定义出这些业务场景并得到客户认可的话，则项目能够成功完成的可能性将大大增加。测试场景给供应商指出了明确的努力方向，同时也为客户对未来系统提供了更好的理解。

  3.5、调整和完善项目计划
  各项工作的展开和《系统设计》文档的完成，后续的各项工作（特别是“执行阶段”的工作）变得更加清晰，这时PM需要根据这些信息在“规划阶段”结束前对项目计划进行调整和更新，并在获得客户认可后重新发布修订后的项目计划，用以指导后续的工作。在这个过程中，有几点值得注意：
  (a) 对原项目计划中比较粗的活动的下一级进行细化，落实到人，具体到天；
  (b)不要触动和修改大的里程碑时间点。这是项目计划修改的前提，基于这一前提进行的修改很容易得到客户的理解和支持，而对大的里程碑时间点的修改需要经过特定的更改流程，除非万不得以PM应尽量避免这种情况的出现；
  (c) 项目计划中既要包含面向项目管理的活动，也要充分体现面向最终交付产品的活动。PLM项目有很多相似性，因而有时我们倾向于使用以前某个项目的项目计划作为模板，在此基础上进行修改。这一做法无可厚非，但一定要结合本项目的范围和特点，将本项目特有的一些工作（如XXX CAD接口设计与配置，零件族PFM规划与定义等等）加入到项目计划中去，否则项目计划很容易留于形式，不具有可操作性。

   4、执行阶段（Execution Stage）
  “执行”就是项目组按照项目计划中的安排积极地工作。PM在这个阶段主要工作是监控工作结果及其质量，并与项目计划进行对照，寻找和纠正偏差。如果一个项目在“规划阶段”工作开展地足够细致，团队成员对于自己的任务和职责比较清楚的话，那么在“执行阶段”PM的工作不会很多，开会的次数也相应地减少。对于PLM项目的执行阶段，PM应该注意抓好以下几件事：

  4.1、加强综合变更控制
  由于这样或那样的原因，“执行过程”中的工作结果与计划进行对比时难免会出现一些偏差。小的偏差可以通过调整工作顺序、适当加班等方式完成；如果偏差比较大，则可能需要对总体进度甚至《系统设计》文档进行更改。对于这些更改，应该遵守的几点原则是：
  (a)尽最大努力保持关键里程碑时间点的相对稳定；
  (b)尽量避免对方案主体部分的更改。随着时间推移，改动越大对整个项目的影响越大；
  (c)更改应该与系统提供的客户化框架、开发逻辑相符合。避免改动系统的底层架构。
  因为这样的改动一方面影响系统的稳定性，另一方面在未来系统版本升级时，这些更改将成为潜在的风险。
   

  特别值得一提的是：PM应设法说服客户处理好整体业务需求和对系统IT特征的追求之间的关系。很多PM会有这样的体会：PLM项目最花费时间的不是那些用于满足主体业务功能而进行的开发、配置工作，而是那些系统本来未提供相关开发框架、但应客户中特别追求IT特征的个别人的要求而要进行的开发工作。这些既费时又容易引起BUG的开发工作往往只是为了满足一些细枝末节的功能，如界面的色彩变化和按钮的特征调整等等。我们不能说这些要求都不合理，但我们必须考虑工作的投入与产出之间的平衡。如果系统的某一项IT特征需求需要大量的投入，并且给后续的维护带来很多额外负担的话，我们应该考虑使用一些替代的办法。信息系统的实施必须以业务目标为导向，不能单纯以IT层面的功能为导向，这是必须遵循的基本原则。企业要的是一个能够满足业务目标需求的可用的系统。这个系统可以是一个高科技的产品，但是并不代表它的菜单、按钮、界面、鼠标点击方式都能够尽善尽美，事实上每个使用者的要求和使用习惯也会有所差异。当然系统在满足业务功能的同时，应该在允许的范围内尽可能将界面做的更加人性化，更加符合大多数用户的要求。但是作为实施方和客户都必须把握一个原则：业务目标第一位，IT特征应在软件框架许可的范围内进行调整；过分追求IT特征需要付出昂贵的代价，并且很容易忽视业务的主体需求。
   

  4.2、外包工作的管理
  很多PLM项目需要将部分工作外包给第三方合作伙伴。这种情况下，PM应该注意管理好与合作伙伴的工作关系，确保他们按时、高质量地交付相应的工作成果。为了达到这一目的，以下几点值得引起我们的重视：
  (a)详细、准确地提供外包工作说明书——SOW。合作伙伴通常是编写代码的高手，但在业务方面他们没有太多的经验。因此一份详细、准确的SOW可以减少很多不必要的沟通和返工； 
  (b)尽可能重用代码。代码重用即可以节省工作量，又可以保证质量，因为能够重用的代码通常已经在其它项目中经过了必要的实践检验；
  (c)尽量避免同一个项目的开发工作过于分散。过于分散的开发工作给代码的合成和综合测试带来很多额外的工作和风险，出现问题时责任方比较难以界定；
  (d)在项目计划中应留有足够的测试、调整时间。开发工作完成后经过单元测试，最终还需要在用户现场进行综合测试，这个环节由于环境的不同（如开发者使用Windows系统，客户使用Unix系统；开发者使用虚构的测试数据，现场使用真实的业务数据；数据量可能增加几十倍等等）会涌现出很多之前没有发现的小问题，需要对系统进行调整和完善。另外，在测试过程中，客户往往还会有一些新的需求。当然，对于大的修改要尽量避免，但是有些小改动在所难免。这不是
   

  开发者的问题，但是作为PM必须面对它，有时需要请开发人员帮忙给予调整。所有这些都需要时间，因此在项目计划中，应充分重视系统测试这一环节，给它留有足够的缓冲。

  5、移交阶段（Transition Stage）
  相对“执行阶段”，PM在“移交阶段”需要进行的沟通与协调工作有所增加，主要包括：
   

  5.1、获得《测试报告》的签字认可
  测试工作应在“执行阶段”完成，《测试报告》也应该在测试过程中形成。但是由于测试过程通常伴随着一些小的改动和调整，因此《测试报告》正式定稿并获得客户认可的时间通常在“移交阶段”的早期。测试报告中应该详细记录测试日期，测试参与人员，测试环境描述，测试场景，测试结果、遗留问题及最终结论。
   

  一份好的能够作为验收报告附件的测试报告，在最终结论中应该清晰地表达出：“系统测试完成，测试结果符合要求，满足PLM进一步上线推广的要求。”等字样。当然，也可能产品本身存在一些缺陷，无法通过项目组开发人员在短期内解决。 这些问题也应记录在案，PM通过向公司总部报告IR，待问题确认后通过打Patch的方式给予解决。 在这个过程，PM或者MES人员需向客户及时通报问题的解决状态。除非问题很严重且影响了主体业务功能的实现，一般这些IR的存在不应成为项目验收的障碍。
   

  5.2、协调和安排用户培训
  用户培训是系统上线前的一个必要步骤，PM根据最终用户的数量来确定培训方式和方法。一般来说，如果最终用户数量较多，PM应该考虑先进行Trainer培训，即从用户中挑选一些骨干人员先进行培训，培训完成后由这些骨干人员再组织和安排针对最终大批量用户的培训。这样做不仅仅为了减少工作量，更主要的是客户自己需要建立一支精通系统使用和配置的技术队伍，使企业具备自主进行系统推广的能力。对于用户群较小的客户，PM可以考虑直接对最终用户进行培训；但是既便是这样，重点培养几个熟练使用系统的人员也不失为是一个对双方都有利的双赢措施。
   

  5.3、收集、整理验收材料，进行项目总结
  “移交阶段”的最终目的是为了系统上线和项目验收。PM应在移交阶段针对合同及其附件的要求，与项目组成员一起对所有的交付物进行收集和整理。在验收前向客户提供完整的项目资料（包括电子的和签字的纸质文件）。 这时候你会发现，如果项目组在“启动阶段”就已经定义好了文档的存放和管理方式、并且在项目实施中一贯严格执行的话，现在的收集和整理工作就会非常轻松。
   

  项目总结对于PM及项目组的成长和发展也是非常重要的。回顾整个项目的发展历程，将好的、值得借鉴的东西以书面形式总结出来供他人参考引用；将不好的、需要规避的东西也以书面形式总结出来给别人提个醒，这些都是非常有意义的事情。
   

   5.4、验收报告会
  当项目的各项工作顺利完后，PM就可以和客户项目经理进行沟通，请他/她在《验收报告》（AL, Acceptance Letter）上签字，确认项目的正式完成。签字过程可以单独完成，也可以作为项目报告会的一部分在会上完成。项目报告会是总结项目并正式宣告项目完成的一种形式。PM应协调和邀请公司高层领导、客户高层领导、客户项目经理、客户项目发起人、项目实施组核心成员、应用部门代表等重要的项目厉害关系人（Stakeholder）参与这一会议。

  6、结束语
  项目之所以称之为项目，一是因为它有明确的起始和结束日期，二是因为它所提供的产品具有独特性，三是因为项目实施过程是一个逐步完善的过程。每个实施PLM的企业因其所在的行业和产品不同，其系统实施策略和侧重点也各不相同，这就决定了每个PLM项目都具有各自独特的特点。这样的事实注定PM在项目实施过程中将面临一个充满未知因素的环境，这样的环境中既有风险，也存在机遇，它给善于总结经验教训、喜欢探索新鲜事物的人提供了一个可以充分施展才能的舞台。
   

  项目管理是一门实践性很强的学科，目前虽然有很多项目管理方面的书籍、培训和认证，但是没有任何一本书、没有任何一门培训、没有任何一种认证可以确保你成为一个合格的项目经理。它们提供的是一些基本知识、技能和工具，PLM项目的项目经理需在实践中综合运用这些知识、技能和工具，在特定的项目环境下针对不同的问题采取最恰当的应对措施。项目管理是一个很大的概念，沟通和协调是项目管理过程中项目经理必备的能力，PLM项目的项目经理尤其应该重视沟通与协调对于项目成败的意义。“成也沟通、败也沟通”，希望各位同仁能够通过良好的沟通与协调给自己的项目注入活力，给项目组成员营造积极、热情的工作氛围，为项目的成功验收奠定基础。(e-works)