以前我们觉得，只要PDM真能给用户提供价值，用户就一定能够自我激发从而促进项目的实施。我个人也在这种理论的影响下实施了2年，后来发现其实不是这样的。就像我在前面说的，人自励自发一定有外力驱动，这种外力要不就是压力，要不就是动力。比如说一个软件公司突然改变策略，要求用Java重新开发新的平台，然后它要求所有的程序员必须学会Java，否则就走人。程序员们肯定惶惶不安，人人自危--这是压力；但是公司换个方式，告诉所有的程序员，学会了Java，等这个新平台开发出来给所有人加薪200％，程序员们肯定喜笑颜开，发奋图强--这是动力。
但在PDM实施中我们面对的到底是压力还是动力呢。以前我们希望用价值让用户产生动力，但是效果并不好。道理很简单，设计人员的价值与企业上PDM的价值并不统一。设计人员希望的是快速提高自己的业务能力，希望以后的个人事业能够有比较大的突破；而PDM的价值在于帮助企业实现TQCSE的和谐统一，虽然它也能对设计人员提高业务能力有所帮助，但是这些帮助非常有限，远不如设计人员看书考研之类的来的直接。
动力这条路看来是不通了，只好试试压力了。前面已经说了，设计人员尤其是老资格的设计人员多数都是企业大爷般的人物，领导都拿他们没办法，就更别提软件公司了。那怎么办呢？其实设计人员一般都受过良好的教育，受过良好教育的人一般都比较讲道理，比较遵纪守法，企业里面设计人员很少有迟到早退的就是这个道理。所以要想给设计人员压力最好的办法就是制度！
有人说了，你这也是废话，上信息化的都知道要在制度上予以保障。但是我这里说的制度还与企业那种上纲上线的制度不太一样，那种制度很死板，而且真要立那样的制度还要经过层层审批，并不是件容易的事情。我这里说的制度是找一个点，只要在这个点上进行严格把关，就能给设计人员形成很大的压力。我在另外一个企业实施的时候发现，工艺部门接收设计部门的图纸时都需要经过工艺签审这一关，而负责工艺签审的人工作又不是特别的繁忙，于是我就重点培训了他，并让技术部门领导口头下令，所有交给工艺签审的图纸必须进入PDM系统，否则工艺部门可以予以拒绝。OK，这招非常管用，短短6个月，PDM中就已经有了各类零部件图纸8000余张。
那有了制度，企业设计人员也用起来了，PDM中也有数据了，能不能说这个PDM项目成功了呢？别高兴太早，还不行！
刚才谈到成功标准的问题，其实就是一个PDM项目的项目目标问题，就算用起来了，没有达到项目目标，我们一样说这个项目没有成功，但是反过来，达到了项目目标，没有真正用起来，却可以说这个项目是成功的。
有人说，你这个观点好奇怪，没用起来怎么可能达到目标呢。但是在我们国家这种体制下就是可能的。比如有些PDM项目是科研性质的，要求的是系统的先进性，虽然也重视实用性，但是先进性是主导的。这种事情在很多高校承接的PDM课题项目中并不鲜见。就好像很多电子产品，在市场上是失败的，但是在技术上是成功的。这实际上是一个组织目标与业务目标的命题。组织目标与业务目标一致，这个项目往往比较容易得到应用，但是如果组织目标与业务目标本来就不匹配，那么往往只能牺牲业务目标而达到组织目标。
所以，在实施PDM的时候，首先需要明确定义的就是项目实施目标。个人觉得现在是回归理性的时候了，企业也好，软件公司也好，应该摒弃所谓的项目管理、协同设计之类的花哨名词，转向更加实际的，可以量化的项目实施目标，比如要求在什么时间内满足什么需求，在什么时间内，达到多少数据量等等。
看过国内某知名Smarteam代理公布的数据，Smarteam70％的用户只做了图文档管理；一个参与Teamcenter在FORD实施的朋友介绍，Teamcenter在FORD实施了三年，也只做了图文档管理。那个朋友还告诉我，Teamcenter一些花哨的功能FORD一概不要，它要的就是实用和稳定。由此看来，比起国内企业动不动就要PDM实现项目管理、协同设计之类的功能来，老外还是比国内的企业务实一点。
项目目标一旦确定，所有的实施活动都按照这个目标进行倒排就行了，项目的时间进度、人力资源的分配等等项目要素都可以随之展开。PDM的项目管理我这里就不展开了，否则就可以写一本书了。我这里要说的是PDM项目实施过程中最容易被人提起也最容易被人忽视的内容--项目沟通。
看过部分外国PDM系统的实施方案，发现每周一个项目例会是写在方案里面的。以前以为只是做秀，后来一了解，还真就是那样，而且老外组织开项目例会不流于形式，非常坦诚，行就是行，不行就是不行。就拿提BUG或者需求这事情来说，Teamcenter将BUG或者需求分四级，0级是解决不了系统就不能正常运行的，比如不兼容某个操作系统之类的；1级是不解决无法开展业务的；2级是可以采用其他办法解决但比较麻烦需要优化的；3级是目前已经能够解决但是有更好解决方案的。用户在向Teamcenter提出BUG或者需求的时候，是双方项目组通过充分的沟通产生的按级别区分的报告。但是在国内，除了软件公司内部的BUG库，很少有那个软件公司能如此细致的区分用户提出的BUG或者需求。无法区分一方面是缺乏对用户业务的足够了解，另外一方面就是没有保持足够的沟通。
在PDM实施过程中，客户提BUG或者需求简直如家常便饭，而且应用越深入提的越多。但是用户缺乏对软件的足够了解，要么觉得这个问题软件公司改起来非常容易，要么就把一个不怎么重要的BUG或者需求上升到不解决就不验收的地步。用户不了解情况不是他的错，但是实施人员不去主动判断，不去主动沟通就不对了。
我在实施过程中，开发人员经常拿着一叠BUG/需求报告跑来问我："哪些是紧急的必须要改的，你挑出来我优先解决。"我对他说："我提这些主要是想帮助公司的软件进步，事实是不需要任何的开发我也能够让用户将这个系统用起来，因为我们的PDM已经比较成熟，基本功能是够用的。"我说这些并不是说我有多牛，我是想说在一个已经相对比较成熟的已经得到过大量用户验证过的PDM系统面前，一些基本的功能是稳定且实用的，在向开发人员提出BUG或者需求之前，应该多想想如何通过沟通打动用户让他把这些基本功能先用起来。
沟通还有一个重要作用就是增进双方感情，减小实施阻力。当然这也是废话，因为所有的PDM实施项目都非常重视实施人员的沟通能力，企业在挑选自己的项目组成员的时也会选那些沟通能力比较好的。不过不管承认不承认，双方的项目组成员在沟通时都有意无意的保持距离，似乎大家都抱着不可告人的秘密。
企业里面的秘密我不知道，但是软件公司的秘密我还是有所了解的。软件公司无非就时怕实施人员出去乱说话，比如垂头丧气的表示对软件的无奈或者乱向用户做出承诺等等。以我的看法，乱说都比不说要强。呵呵，又是一个语出惊人是不是。
现在人都不是傻瓜，现在PDM软件厂商的销售经理都深感用户原来越理性，所以现在瞒天过海的伎俩已经不实用了，所以在我面对用户的时候，尽量保持坦诚。除非是公司的核心商业机密，否则个人认为没有什么不能说的，唯一的问题是说的时机。这就像打牌，你手上的牌早晚都是要出的，只是看先出还说后出。我曾经当着用户的面跟我们的开发测试人员打电话发表强烈不满，曾经愁眉苦脸的跟用户高层述说实施过程的艰辛，曾经大声向用户宣布我们打下的新单……当然，这存在一个时机问题，至于时机的把握，那就看实施人员的能力了。
刚才谈了一下沟通的态度，现在谈谈沟通的方式，个人认为这也是实施过程中非常重要的一环。其实沟通的方式无外乎就是电话沟通、邮件沟通、当面沟通和书面沟通几种。但是很多PDM实施项目小组的成员往往忽略了对沟通进行记录，这个是非常要命的。我在实施过程中，每天都写工作记录，每周形成工作备忘录交给用户，通过沟通了解形成的需求或者BUG也一定形成文档。每次项目例会一定有专人负责记录，会后保证参与人员人手一份会议记录。最后这些记录文档在验收过程中形成了巨大作用，我用详尽的数据和记录向用户证明，我们做到了什么，有那些没做到，为什么没做到，项目发生延期的原因。看到这些记录，用户高层几乎没有考虑就在验收报告上签了字。
关于实施的话题其实很长，从实施方法的角度而言，国内国外PDM软件的虽然细节有很多不同，但是方法基本都是一样。我个人认为也没必要非要争出个孰优孰劣，时间自然会证明一切。关键是怎么看待PDM的实施问题，我觉得只要肯投入（未必是金钱方面的，但是金钱也是必不可少的），本着共同实施，共同承担风险的态度，多沟通，多让用户参与，PDM的项目就一定能实施成功。
网友评论