浅议企业中产品数据管理的实施

申请免费试用、咨询电话：400-8352-114

谈到PDM的实施，很多人微微一笑：PDM跟合肥OA一样，同属于企业信息化的组成部分，企业信息化实施不就是那么几条么，什么“一把手工程”，什么 “整体规划，分步实施”么。再难，它也就管理那么一点业务，能难到那里去？可是渐渐的，很多企业发现，PDM实施的难度一点不亚于其他信息化系统，但是又说不清楚到底难在什么地方，更谈不上找到实施PDM时的突破口。下面谈谈个人一点粗浅的认识。

首先让我们看看“一把手工程”。废话，一把手是企业的最高领导，别说信息化，企业里的事情只要“一把手”发话，没有办不好的（当然，除非下面办事的不想在企业混了）。那么凭什么这句话就成了企业实施信息化的必胜法宝呢？

再让我们看看“整体规划，分步实施”。还是废话，除非哪个企业领导有魄力停工停产，管理体系推倒重来，否则谁都知道“一口吃不了个胖子”这个地球人都知道的道理，为啥到了实施信息化的时候就成了尚方宝剑呢？

面对上面的问题，我只能悲哀的说：那是因为没有找到实施方法。当然，这里我不能说我就一定找到了实施的方法，我只想谈谈我的感想。

首先，“一把手工程”这句话在实施PDM的时候是不起作用的。因为PDM的主要用户是以金属加工为主的制造业企业（也包括设计院、研究所），而这类企业的 “一把手”往往负责生产，技术则由副总负责，而PDM是技术管理信息化，最直接面对的高层领导就是所谓的技术副总。技术副总在企业往往只能是“三把手”或者“四把手”（“二把手”往往负责财务）。在这种情况下，所谓的“一把手工程”在实施PDM的时候只能是句口号。

其次，“整体规划，分步实施”在实施PDM的时候同样不起作用。因为PDM的实施是线性的，不可能像合肥OA或者其他系统一样并发。举个例子来说，所有的企业实施PDM都是从图文档管理着手，然后逐步推广到工作流甚至是项目管理，目前还没有听说哪个企业跳过图文档直接实施项目管理的。有了这样的前提自然谈不上什么“整体规划”，因为 “分步实施”已经是约定俗成的了。而合肥OA就不是这样，企业可以有选择的上若干个实施周期短、见效快的模块然后再上其他模块，这种模块之间的搭配往往非常灵活。

再次，PDM与合肥OA等系统一个显著的差别就是，PDM系统是一个见效缓慢的信息化系统。一方面体现在，只有PDM中的数据量达到一定程度以后，PDM的价值才能显现。另外一方面，PDM有点类似保险，不出事的时候没人觉得它重要，一旦出事PDM的某些价值才能闪光，比如最基础的图文档管理。而合肥OA的“进、销、存”等模块几乎是一上就有效果，因为它促使企业把许多年都盘不清的库存盘清楚了。

最后，PDM的主要应用群体集中在企业的技术部门，我国几乎所有的制造业企业的领导都承认（外国暂时还没了解），技术人员在企业是最不好管理的一个群体，打打不得，骂骂不得。面对这样一群企业里面的大爷，企业自己的领导都束手无策，PDM厂商这些外来的和尚的经自然就不是那么好念了。

那PDM究竟要怎样实施呢？如何才能实施好PDM呢？

按照系统的大小和难度，PDM目前主要有两种实施方式。一种是以Teamcenter和Windchill为代表的先培训，再实施的方式；一种是国内厂商为代表的边培训边实施的方式。

具体来说，Teamcenter和Windchill在实施开始阶段会对项目实施小组进行培训，让他们了解整套系统，然后让各业务部门组织讨论，提出具体的需求。根据这些需求，软件厂商再编制解决方案，当然，这个解决方案是比较偏技术层面的。当解决方案获得双方认可后组织相应的开发和实施。然后再培训，再开发。如此往复，项目进展呈现一个螺旋上升的状态。而国内厂商一般都是先进行需求调研，然后进行配置开发，然后培训推广，然后结项。在实施开始的阶段，企业对PDM的认识和了解完全来自销售人员的演示。

现在无法评述两种方式的好坏，国外软件的实施方式比较适合大型系统，企业投入大，项目周期长。国内软件的实施方式比较适合小型系统，项目周期短，回款快。不过两种方式都强调了培训，可见培训在PDM实施过程中的重要性。为什么培训如此重要？个人认为一个词就可以解释：参与感。

其实任何信息化系统的实施都面临一个这个很现实的问题。我常常听见实施人员抱怨：“技术人员就是不用，我能有什么办法呢。”这就是企业的终端用户参与感不够的集中表现。没有足够的参与感，用户就无法认同你的工作乃至整个PDM系统。在走访了一些实施不好的企业发现，往往实施人员忙的昏天黑地，技术人员或者技术部门的负责人还不知道这个系统是干什么的，为什么要上。直到最终按照技术要求验收了，整个系统还是没有得到应用。

记得我实施的第一个项目是接上个项目经理的烂摊子，按照功能基本都满足了，但是技术部门一个客户端都还没有安装。用户非常恼火，第一次见面直接就跟我说：“现在我们谈谈如何终止这次合作吧。”在实施重新启动后，我做的第一件事就是让用户从技术部门抽调2个人配合实施。我花了三天时间，从PDM的原理到我们PDM产品功能全面给他们进行了培训。然后又手把手教他们配置和二次开发，随后的事实证明我的方法是正确的，验收时PDM中 60％的数据都是由他们两人在日常工作中录入的，最终对系统的肯定意见也是由他们最先提出的。我不想说明这个项目有多成功，我只想说明的是，当用户有足够的参与感时，这个项目基本上就已经成功了。这就好像自己养大的孩子，想不管他还真不是那么容易的。

刚才谈到PDM项目的成功问题，应该来说是一个比较敏感但又不得不谈的话题。在这里我想借用发哥在广告中的话问问：“成功是什么？”说的直接一点，就是如何评价一个PDM项目是否成功？或者说PDM项目的成功标准是什么？

很多人说PDM成功的标准是用户。用户天天在用，而且满意，就说明这个项目成功了。在这里我想说的是：这不叫成功的标准，这最多只能算成功带来的后果之一。要是按照用户满意读这个标准，这个世界上简直就没有成功的信息化项目。

不管你是否承认，每个人与生俱来就抗拒新生事务。比如上海人到了四川就吃不下饭，四川人到了广东也没办法习惯当地的饮食。想想我们所谓的IT人自己，用惯了 VC的人，你让他改用其他的工具，还真不是那么容易的事情。己所不欲、勿施于人，当一个人被迫改变某种习惯，一定是受外力影响，不得已而为之，内心里是未必情愿的。所以我个人认为，依靠PDM的所谓价值去驱动用户自己的主观能动性基本是不可行的，因为PDM的那些所谓的价值什么的在实施当中根本起不到多大作用。

以前我们觉得，只要PDM真能给用户提供价值，用户就一定能够自我激发从而促进项目的实施。我个人也在这种理论的影响下实施了2年，后来发现其实不是这样的。就像我在前面说的，人自励自发一定有外力驱动，这种外力要不就是压力，要不就是动力。比如说一个软件公司突然改变策略，要求用 Java重新开发新的平台，然后它要求所有的程序员必须学会Java，否则就走人。程序员们肯定惶惶不安，人人自危——这是压力；但是公司换个方式，告诉所有的程序员，学会了Java，等这个新平台开发出来给所有人加薪200％，程序员们肯定喜笑颜开，发奋图强——这是动力。

但在PDM实施中我们面对的到底是压力还是动力呢。以前我们希望用价值让用户产生动力，但是效果并不好。道理很简单，设计人员的价值与企业上PDM的价值并不统一。设计人员希望的是快速提高自己的业务能力，希望以后的个人事业能够有比较大的突破；而PDM的价值在于帮助企业实现TQCSE的和谐统一，虽然它也能对设计人员提高业务能力有所帮助，但是这些帮助非常有限，远不如设计人员看书考研之类的来的直接。