PDM项目实施手札之四——风暴来临

2004年元旦一结束，公司就公布了一项任命——任命原南方大区的一名高级咨询顾问任实施部副经理。因为我是唯一一个手头暂时没有项目的实施工程师，他就带着我去他负责实施的一个项目中帮忙。

那时候公司刚刚推出了新一代的PDM，而我因为一直在外做CAD项目，几乎没有接触过PDM。所以当时的工作主要就是学习，并帮助客户进行软件安装。那个时候，因为软件刚刚推出，BUG非常多，经常无缘无故的自动退出，而且系统慢的几乎无法忍受。不过因为客户关系非常好，客户也对我们表示理解。

新一代的PDM软件与公司过去的PDM相比，最大的不同在于，过去的PDM软件是面向产品结构的管理方式，而新一代的PDM软件是面向对象的管理方式。这种管理方式即便在今天国内PDM软件产品当中，都是非常先进的。所谓面向对象的管理方式，简单来说，就是没有零部件，也没有产品，统统视为“对象”，所有的产品数据都围绕“对象”来组织，对象可以分类，一类对象可以有相同的属性，相同的文档类型，相同的流程。而产品结构，只是对象的一种表达形式而已。所有的对象存放在一个以分类为基础的对象库当中，通过视图可以查看每个零部件对象的结构以及与之相关的所有产品数据。

当时我参与的这个PDM项目是公司为数不多还“幸存”的新版本PDM项目之一，之前也签过几个新版本PDM项目，但是由于BUG太多，以及客户的对新概念的接受程度不高而纷纷“夭折”。同时，公司内部尤其是实施部内部也出现了一些质疑的声音。对于实施工程师反映：他们自己都无法理解什么是“对象”、什么是“关联”，就更不要指望客户能够理解了。

后来新任的实施部副经理告诉我：他就是要用一个项目来证明新版本的PDM是可以实施的，而且肯定比老版本的PDM优越的多。他挑中我，一方面是我在PDM方面如同一张白纸，比较容易接受新的概念，另外也是要向老实施工程师证明，新版本的PDM并没有那么难学。

由于临近春节，且受到软件BUG修改进度的制约，那个项目进展缓慢，平均2周左右才到现场去，用刚刚开发出来的修订版本替换客户的老版本，并进行相关测试。由于软件尚在外部测试过程中，所以既没有帮助手册又没有人指导，很多功能只有开发人员自己知道怎么用。所以那段时间我经常工作到很晚，开发人员在的时候请教一下操作方法，开发人员不在的时候就自己摸索。这种状态一直持续到春节后。

春节后，公司组织一年一度的员工培训及考核。在所有接受新版本PDM培训的员工当中，我的成绩最好，所以副经理就要我负责对其他员工进行指导。在这次培训及考核当中，对新版本的PDM的反对声更加强烈，一些已经在公司工作了很多年的实施工程师拒绝参与新版本的PDM项目实施工作当中，实施部上空弥漫着紧张的空气。副经理终于按耐不住，露出了“杀气”——裁员！

最先被裁掉的是一位已经来实施部工作了3年多的实施工程师，裁掉他的公开理由，是被客户投诉。但是私底下，我们都很清楚他是因为不愿意参与新版本的PDM实施工作而被裁。不过若干年后，当我够资格参加公司一个季度一次的核心员工会议的时候，我才知道，从2003年开始，公司开始从盈利转向亏损，2003年年底公司召开经营会议，决定裁员，每个部门划定一定的名额，而实施部划了一个名额。

裁员没多久，公司就对实施部进行了改组，将实施部一分为三：一部分人负责老版本PDM的实施，一部分人负责新版本PDM的实施，另外抽调几位有丰富经验的实施人员进行需求分析和实施方案管理。

这其实是公司的一个缓兵之计，因为公司已经明确要求营销部门停止销售老版本的PDM产品，同时撤掉了老版本的开发维护部门，将所有的开发人员全部并入新版本PDM的开发团队，只修改过去的BUG，不响应新的功能需求。公司的一系列动作，向负责老版本实施工作的实施人员发出了最后通牒——要么实施新版本的PDM，要么走人！

公司的态度很快让老版本PDM的实施人员做出了他们的选择——辞职！在春节过完后的两个月内，实施部门累计有7名实施人员辞职。这种不太正常的人员变动引起了公司的注意，公司高管把刚刚到任4个月的副经理拉去谈话。副经理回来后，出人意料的给我发了一封e-mail，请我分析一下这些人离职的原因。

由于那段大家接触比较多，我根据我知道的一些信息进行了简单的分析，并写了一份分析报告。大致是介绍了一些这些人的家庭背景和离职理由，最后得出的结论是：留下的实施人员，要么是因为家庭相对比较困难，需要一份稳定的收入；要么是单身一族，可以适应长期出差。

我的这份分析报告后来也被传递到公司高层那里，以至于在我离职后，负责人力资源的老总在跟我进行谈话的时候，还提到了这份分析报告。

后来听一些留下的老实施工程师说，他们离职还有一个重要的原因：对新的绩效考核制度不满。说来可笑，2004年春节算起，我进入公司已经半年，还不知道实施人员是如何考核。直到春节过后，公布新的考核制度，我才知道以后要按照项目回款的比例和客户的满意度进行考核，根据项目回款比例，实施人员可以拿到一定比例的提成。而在这之前，实施人员没有提成，相应的，他们也不对项目回款和客户满意度负责。在过去的模式中，实施人员只需要根据前期销售人员与客户签订的《技术协议》完成相应的功能配置即可，至于客户是否真的应用，应用后是否满意，并不关心。离职的实施人员不认可新版本的PDM，认为如此复杂的PDM系统，客户根本无法应用，如果再将自己的收入与项目回款捆绑在一起，收入就很难保证……

坦率的说，从我的认识来看，实施人员不对项目成功和客户满意度负责，本身就是一件非常可笑的事情。虽然我做过的项目没有他们多，但是我也很清楚，客户需要的不是一堆功能，他们希望花钱购买的软件能够真正应用起来。那么到底用什么方法，能够让客户将软件真正用起来呢？

副经理毫无保留的告诉我：信心+方法论。

做过很多售前咨询的副经理告诉我，在跟客户交流过程中，必须表现出足够的信心。因为如果你对你自己公司的软件都没有信心，又如何让用户相信你，相信你们的软件？他进一步分析到，大部分离职的实施人员，其实都对自己的产品信心不足。在实施过程中，客户抱怨几声是非常正常的事情，软件有不足也是正常的不能再正常的事情，但是作为实施人员不能受客户的情绪影响，而是应该用自己的信心去强化客户的信心。

而方法论则是项目实施的规范。过去客户对项目的满意度主要依赖实施人员的水平和能力，但是这实际上将客户置于一个高风险的境地——遇到认真负责的实施人员还好，如果不幸遇到实施人员正在成长过程中，那么项目的成功率就很难保证了。因此，必须有一套规范去指导实施人员的实施方法和实施步骤，让一个项目，无论是哪个实施人员来实施，都可以达到相同的实施效果。经过深入的分析和研究，公司的几个资深的实施人员研究出一套实施方法论，因为它有十二个步骤，我们管它叫做“十二规程”。

“十二规程”涵盖了从项目启动到最后的服务所有的过程，并且详细规定每个过程所要完成的文档、PPT以及相关的模版。我不知道业内其他的公司是否在2004年就有了这样一套实施方法论，但是后来的实践证明，这套方法确实行之有效，有效缩短实施周期，客户满意度大幅提高。后来有不少从公司离开的人将这套方法论带到其他同行那里，同样得到了不少同行的认可。

离职的实施人员，手上一般都有项目没有收尾。这些项目很自然的就移交到我们这些“新人”手上。分配给我的项目，说是一个项目，实际上是两个项目。这是分布在两个城市、生产两种完全不同产品的两家公司，但是他们同属于一家集团公司，因为合同是跟集团公司签的一份合同，所以只算一个项目。

前任负责实施的实施工程师在跟我交接的时候显得异常轻松：这个项目已经差不多完成了，所有的配置都做完了，客户也应用了一段时间了，满意度比较高，这个项目还有最后一笔尾款，几万块，只要再服务一下就可以收款了……至于更多的细节，他要我看留下的文档。

我花了大半天的时间去看他留下的文档，但是里面有价值的内容不多，只知道这是一个PDM+CAPP项目，已经实施了近2年，所有的配置都已经完成，CAPP在其中一个企业得到

了应用，而另外一个企业却不愿意用，但是功能都已经实现了。PDM是新版本的，所有的功能配置都完成了，但是没有安装部署……

从表面上看，这个项目确实是万事俱备，只要到现场一安装，然后再进行一些相关的服务即可。我当时的想法也比较简单，根据留下的资料，我简单做了一个项目计划，拿去与副经理沟通。他看后提醒我两点：

首先，虽然事实上是两个项目，但是我要将其当成一个项目来对待，因为一个应用了，一个没有应用，最后的尾款还是拿不到；

其次，这样的项目，要先从最难的企业开始，而我之前想从应用较好的企业开始切入，尽快完成之后，全力做应用不好的企业。从较难的企业开始，都投入一些精力，最后可以两个企业一起验收；

第三，不要太相信交接的材料，计划要到现场去跟企业沟通，因为所有的计划都是沟通出来的，不是做出来的。

我按照副经理的意见草拟了一份计划，分别发给两个企业的项目负责人，并约定好了拜访时间。这是我第一次独立负责一个项目的实施，心里难免七上八下。副经理看出了我的担心，决定与我一起去企业拜访。

（编辑：eva）

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。