您现在的位置是：首页 > 行业 > 制造 >

PDM项目实施手札之项目重启

2009-09-11 02:11:00作者：愤怒的公牛来源：

摘要PDM项目实施手札之项目重启...

我们首先去的是离武汉较近的A企业。A企业是该集团的核心企业之一，效益比较好，我们直接去拜访了负责这个项目的总经理助理。总经理助理年纪很轻，35岁不到，年轻人坐在一起谈信息化，自然就比较放松。总经理助理告诉我们，其实他并不了解我们的项目，因为在他负责信息化之前，他们企业的信息化项目一直是一位副总负责，后来那位副总辞职他才接手的，而且他主要是负责ERP项目，对PDM/CAPP项目并不是特别关注。不过他也表示，虽然不知道PDM/CAPP项目究竟是怎么回事，但是没用起来是肯定的，所以他还是希望我们能够加大投入，让这个项目步入正常轨道。

拜访完总经理助理，我们在企业PDM项目管理员的带领下到技术部去了解实际的情况。正如总经理助理所言，PDM基本就没用，CAPP倒是还好，有几个人用，但是也是问题一堆。当晚副总经理跟我商量，与其在一块破布上打补丁，还不如重做一件新衣服。我当时稍稍有一点不情愿，因为这个项目就剩最后一笔尾款几万块钱，相比较其他实施人员手上几十万的项目，我这连“排骨”都算不上。副经理看出了我的犹豫，他对我说：你不要急，在湖北，就这么两三家有影响力的企业，你把这家做好了，不愁后面的项目。我极不情愿的接受了项目推倒重做的要求，不过后来的事实证明了副经理的眼光长远和判断正确。

第二天，我们找了由企业总经理助理参加的项目会议。会议的气氛异常凝重，主要技术人员怨声载道，技术部门的领导则默不作声，总经理助理则认真听取这技术人员的抱怨。我心里想：完蛋了，又变成了一次“声讨”会。

等技术人员发泄完了，副经理开始发言了：他首先代表公司对项目进展了如此之长的时间却没有任何效果表示道歉，然后宣布推倒重做这个项目，并阐述了新制定的“十二规程”。由于会议之前，我们就项目重新实施一事跟总经理助理和企业具体负责实施的管理员就项目推倒重做进行了沟通，因此当副总经理宣布完后，总经理助理马上对重做表示认同，并指定发牢骚最多的工艺部的部长具体负责技术部门的实施工作。后来我还了解到，总经理助理随后将PDM/CAPP项目建设的任务划入了工艺部部长的KPI（关键绩效指标），这对这个项目的成功打下了坚实的基础。

会议开完，副经理指示我立刻将会议记录通过邮件发给总经理助理、工艺部部长和项目管理员，按他的说法，是以防万一。他同时告诉我，以后到企业里来进行任何工作，最后都要形成书面的文档发给相关的人员，并且请他们签字确认，这样以后即便实施出了问题，通过这些文档，企业也很难否认我们的工作。

处理完这些事情，我们马不停蹄的赶往B企业。在路上，我向副经理讲了去年那个失败的项目会议，并向他请教为何这次的会议会开的如此成功。

副经理问我：你觉得这次会议的目的是什么？我回答：应该了解项目的现状，并且讨论项目下一步的走向。副经理笑着对我说：错了！其实领导召开此类的会议，并不是真的向征求与会者的意见，领导在开会之前，早已经有了结论，只不过是通过这个会议宣布他的决定而已。但是直接宣布又显得较为生硬，不给与会者说话的机会会让下面的人说话，也会显得独断专行，因此领导一般都会装作非常认真的听取下面人的意见，然后找个机会将自己的决定宣布出来，一锤定音！

顺着这个思路，就不难理清究竟如何召开一个成功的会议：首先，需要搞清楚这次会议的目的是什么？就拿这次的项目会议来说，会议的目的不是讨论下一步该如何进行，而是确定项目重新启动并且指定项目负责人。那么要达到这个目的，就必须征得与会的最高领导的认同，因此，事先必须与总经理助理进行沟通，得到他的认同；他同意之后，事情就好办了，再跟工艺部长和PDM项目管理沟通一下，不过不必获得他们的同意（当然如果同意也再好不过），这个会议就可以开了。这样不管会议进展如何，几个主要的负责人心理都已经有了谱，就很容易形成会议结论。而我去年那个会议，失败就失败在，事先没有进行充分的沟通，会议的目的也不够明确。

谈到会议，这里我说一点题外话。开会是中国人日常生活中不可避免的活动，其实开会有很深的学问，同样的会议内容，不同的人去开，会产生两个截然不同的效果。在我看来，如果开会的技巧不是特别高的人，最好不要贸然去召开所谓的“讨论会”（现在流行的说法叫“头脑风暴”）。因为这种会议如果缺乏高超的沟通和控制技巧，很容易就变成一个主题发散的“牢骚会”，最后也无法形成任何实质性的结果。我自问没有这样的能力，因此在日后的实施和交流过程中，再也未开过“讨论会”。

到达B企业后，我们首先见到了IT部门的负责人，出乎我们意料，一见面他就很不客气的说：“我们这个项目没什么好谈的了，要谈就谈谈如何结束这个项目吧。”副经理耐心的给他分析当前项目的情况，并把我们在A企业沟通的结果向他进行了阐述，并表示也会重新实施他们这个项目。沟通了2个多小时，该负责人的口气才有所缓和，并答应下午带我们去见总工程师。

与总工的见面就更加不顺利，在表明了来意后，总工毫不客气的对我们说：“其实当年我就反对选你们的软件，想选另外一款国外软件，但是集团那边决定上你们的，我也没有办法，现在实施成这个样子，我们还有什么可谈的？”说完就借口有事，离开办公室，把我们晾在办公室。后来我每每回忆起这一幕，我都觉得不可思议。这个总工是清华的MBA

毕业，受过高等教育，却缺乏对人起码的尊重，在面对问题的时候，考虑的更多的是如何脱身而不是如何解决问题。在他领导的关乎企业生死存亡的产品研发项目中，他的这种性格缺陷显露的更加明显。

IT部门的负责人对此也非常尴尬，不过他表示认可我们的方案，项目可以继续实施，后面的事情他来搞定（后来才了解到他跟总经理关系非常好，后期项目中的很多障碍都是他通过总经理扫除的）。

基于这种情况，我们没有像在A企业一样召开项目会议，在留下了一份备忘录后就离开了B企业，等待IT部门负责人与相关部门沟通好后再制定下一步的计划。

就这样，我们用一周的时间走访了2家企业，制定了下一步的实施方针——重新实施。刚刚回到武汉，B企业的IT部门负责人就来电话了，告诉我们已经跟技术部协商好了，继续实施。得到这个消息后，我非常高兴，马上开始着手编制项目计划。

项目计划制定好后，我拿给副经理审核。副经理一看又笑了。他告诉我，所有的计划都不是“做”出来的，而是“商量”出来的。他进而对我说，很多实施人员在项目开始的阶段容易犯一个错误，就是“做”计划。他们根据自己的设想在Project上摆弄着甘特图，然后将这份所谓的“计划”发给企业，然后告诉企业我们准备按照这个计划来进行实施。

但是实际上，从项目立项之日起，项目就不再是软件公司一方面的事情，需要企业和软件公司坐下来耐心的沟通。这个项目的目标是什么，有哪些工作，需要双方怎么配合，都需要事先沟通清楚。这些内容沟通清楚之后，再制定一个初步的计划，然后拿着这个计划去跟企业方面进行沟通，看看他们能否及时的将项目所需要的资源安排到位，项目实施是否与他们其他的产品研发项目相冲突等。这样商量出来的计划，不是某一方强加给另外一方的，所以大家执行起来就不会有什么怨言。

听完副经理的话，我决定再去这两家企业一趟，一来了解一下企业应用的实际情况，二来也就项目计划等情况跟对方进行一个沟通。出差申请打上去，很快就被副经理打下来了。原因是：出差目标不明确！

目标不明确！这么明确的任务目标还说不明确？副经理耐心的向我解释道：很多实施人员出去之前犯跟你一样的错误，“了解企业应用的实际情况和沟通项目计划”根本就算不上什么任务目标，你此去的目的是去调研，并制定项目计划，因此你的任务目标是完成调研报告、制定初步的项目计划并得到对方认可！“记住，所有的目标都是可以量化的，并可以最终形成文档！”他最后向我强调。

按照副经理的要求，我又重新填写了一份出差申请，再次踏上了去这两家企业的征程。由于之前副经理的提醒，我这次做了充足的准备，带上了调研提纲和以前工程师留下的需求报告、方案和相关的配置。由于有了去年82天的连续出差和副经理的“在线”支援，这次我的胆子大了很多。有时候我回想起这段经历，总感觉那时候是我受益最多的时候，没有那82天的锤炼，我可能早已无法适应长期的出差和用户的白眼，退出这个行业；没有副经理的耐心教导，我想我也很难摸索出一条行之有效的实施方法。

我带着轻松的心情上路了，一切似乎都在向好的方向转变，但是隐隐的，我还是有点担心——技术上的问题对我来说都好解决，但是如果再出现去年那种情况，技术人员就是不用该怎么办呢？

（编辑：eva）

(本文不涉密)
责任编辑：

上一篇：PDM项目实施手札之四——风暴来临

下一篇：IT软件系统之间的协作关系