智慧仓储欢迎您 企业微信服务商
欢迎体验进销存软件
新闻动态
News
行业动态
您的位置:库管王 > 行业动态 > 如何进行PDM系统的实施?
如何进行PDM系统的实施?
作者:admin;更新时间:05-29 13:35

  核心提示: 谈到PDM的实施,很多人微微一笑:PDM跟ERP一样,同属于企业信息化的组成部分,企业信息化实施不就是那么几条么,什么'一把手工程',什么'整体规划,分步实施'么。再难,它也就管理那么一点...

    谈到PDM的实施,很多人微微一笑:PDM跟ERP一样,同属于企业信息化的组成部分,企业信息化实施不就是那么几条么,什么"一把手工程",什么"整体规划,分步实施"么。再难,它也就管理那么一点业务,能难到那里去?可是渐渐的,很多企业发现,PDM实施的难度一点不亚于其他信息化系统,但是又说不清楚到底难在什么地方,更谈不上找到实施PDM时的突破口。下面谈谈个人一点粗浅的认识。
   
    首先让我们看看"一把手工程"。废话,一把手是企业的最高领导,别说信息化,企业里的事情只要"一把手"发话,没有办不好的(当然,除非下面办事的不想在企业混了)。那么凭什么这句话就成了企业实施信息化的必胜法宝呢?
   
    再让我们看看"整体规划,分步实施"。还是废话,除非哪个企业领导有魄力停工停产,管理体系推倒重来,否则谁都知道 "一口吃不了个胖子"这个地球人都知道的道理,为啥到了实施信息化的时候就成了尚方宝剑呢?
   
    面对上面的问题,我只能悲哀的说:那是因为没有找到实施方法。当然,这里我不能说我就一定找到了实施的方法,我只想谈谈我的感想。
   
    首先,"一把手工程"这句话在实施PDM的时候是不起作用的。因为PDM的主要用户是以金属加工为主的制造业企业(也包括设计院、研究所),而这类企业的"一把手"往往负责生产,技术则由副总负责,而PDM是技术管理信息化,最直接面对的高层领导就是所谓的技术副总。技术副总在企业往往只能是"三把手"或者"四把手"("二把手"往往负责财务)。在这种情况下,所谓的"一把手工程"在实施PDM的时候只能是句口号。
   
    其次,"整体规划,分步实施"在实施PDM的时候同样不起作用。因为PDM的实施是线性的,不可能像ERP或者其他系统一样并发。举个例子来说,所有的企业实施PDM都是从图文档管理着手,然后逐步推广到工作流甚至是项目管理,目前还没有听说哪个企业跳过图文档直接实施项目管理的。有了这样的前提自然谈不上什么"整体规划",因为"分步实施"已经是约定俗成的了。而ERP就不是这样,企业可以有选择的上若干个实施周期短、见效快的模块然后再上其他模块,这种模块之间的搭配往往非常灵活。
   
    再次,PDM与ERP等系统一个显著的差别就是,PDM系统是一个见效缓慢的信息化系统。一方面体现在,只有PDM中的数据量达到一定程度以后,PDM的价值才能显现。另外一方面,PDM有点类似保险,不出事的时候没人觉得它重要,一旦出事PDM的某些价值才能闪光,比如最基础的图文档管理。而ERP的"进、销、存"等模块几乎是一上就有效果,因为它促使企业把许多年都盘不清的库存盘清楚了。
   
    最后,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的和谐统一,虽然它也能对设计人员提高业务能力有所帮助,但是这些帮助非常有限,远不如设计人员看书考研之类的来的直接。
   
    动力这条路看来是不通了,只好试试压力了。前面已经说了,设计人员尤其是老资格的设计人员多数都是企业大爷般的人物,领导都拿他们没办法,就更别提软件公司了。那怎么办呢?其实设计人员一般都受过良好的教育,受过良好教育的人一般都比较讲道理,比较遵纪守法,企业里面设计人员很少有迟到早退的就是这个道理。所以要想给设计人员压力最好的办法就是制度!
   
    有人说了,你这也是废话,上信息化的都知道要在制度上予以保障。但是我这里说的制度还与企业那种上纲上线的制度不太一样,那种制度很死板,而且真要立那样的制度还要经过层层审批,并不是件容易的事情。我这里说的制度是找一个点,只要在这个点上进行严格把关,就能给设计人员形成很大的压力。我在另外一个企业实施的时候发现,工艺部门接收设计部门的图纸时都需要经过工艺签审这一关,而负责工艺签审的人工作又不是特别的繁忙,于是我就重点培训了他,并让技术部门领导口头下令,所有交给工艺签审的图纸必须进入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的项目就一定能实施成功。

Tags:如何 如何进行 进行 系统 系统的 实施 

读过这篇文章的人还读过:

仓储管理的任务

从三个角度浅析如何成功实施ERP系统?

云南工业企业也要玩转营销_云南用友授权中心

cache
Processed in 0.002981 Second.