项目实施经典案例之管理≠技术.doc

国内某巨大型国企源能公司与著名的软件公司签订了管理软件合同。软件公司实施队伍进入源能企业后开展了调研。调研阶段中，能源公司的采购部对管理软件中的物资管理功能非常感兴趣，多次与软件项目经理讨论、沟通。按道理来说，作为软件实施方来说应该很高兴甲方如此的积极，但是随着沟通的深入，项目经理开始发现情况不妙，以下就是沟通的情景：采购部专工：你们的物资编码采取什么标准？能介绍一下吗？项目经理：不同的企业理解不一样。对于我们软件供应商来说，你们提供物资编码，我们可以协助做物资系统的初始化工作。采购部专工：怎么你们不提供物资编码吗？其他项目用的是什么物资编码？项目经理：其他项目的物资编码我可以给你们作为借鉴。但是您的部门以及使用人员不一定熟悉这套体系，这会为将来的物资管理和统计工作带来隐患。采购部专工：对了，我们的物资编码要有两个单价体系。比如：管道。竣工决算是按照吨来执行的。所以出库领料是按照吨。但是需求计划是从设计图纸分解出来的，设计的时候是按照米来的，所以提需求计划的时候得按照米来。你们得建立米和吨的转换。采购部的领导也参与进来了：采购部领导：你们能否给我们提供一份成熟的采购管理方案吗？项目经理：我们可以提供其他的项目作参考。介于本行业的每个项目的差异很大，能复制的地方不多。采购部领导：那你们就没有成熟的解决方案吗？项目经理：我们是软件实施商，不是管理咨询公司。应该是你们拟定解决方案然后我们来实现。采购部领导：我们现在非常需要XXX的解决方案，你们帮我们找找案例。项目经理：这个得你们提出管理目标，以及管理细致程度。根据我们了解的情况，以往采购部可能存在多个管理目标并且有可能冲突，您需要排出优先级。然后你们一步一步落实具体的管理方法，我们可以根据调研情况形成软件需求报告以及软件应用规划。采购部领导：你们实施了这么多项目，应该有很丰富的经验，就不能跟我们说说采购管理过程中有哪些风险？他们是什么样的管理思路和方法？项目经理：每个企业的管理目标不一样，展开工作所具备的条件、环境、资源都不一样，这些解决方案并不一定适用你们企业。我们建议你们先明确管理目标，制定相应的基本流程、标准规范。在这些内容形成后，依然有一些特例或者异常超出我们管控的范围的，这个时候，我们可以介绍其他企业的具体解决思路和方法供您参考。(讨论没有结果)随着时间的推移，关于采购部管理制度和流程的讨论提升到公司层面。公司领导、各业务部门主管以及专工聚集在一起对采购部的流程以及管理思路进行讨论，会议情况大致如下：财务部关注物资的竣工决算后的转资以及合理避税。技术部关注系统的运行效率以及具体的技术标准。控制部关注物资的进度计划编制及完成情况。设计院希望采购部根据供应商以及物资专业划分整理出相关说明，配合设计。内容越来越多，采购部明白了很多，也有更多的不明白了：这也要做那也要做，到底该怎么形成一套体系。最后某采购部业务专工冒出来了：不怕，我们有XXXX项目管理软件，它都可以搞定。有它在就没有问题了。（言下之意出了问题就是软件的问题，这个帽子可扣大了）这回软件实施团队彻底郁闷了：应该是你们将业务问题进行分析，明确了解决方案之后再给我们指示而不是我们来帮你们分析问题理清业务逻辑。采购部的问题还没解决，公司领导、信息部门也“添砖加瓦”了：公司领导：软件设计方面要尽量灵活。你们的流程管理能不能做成自定义的，当前步骤操作人员可以自己选择下一步骤操作人员。就像发邮件一样，自己想选谁就选谁。项目经理说：流程怎么能想发给谁就发给谁呢？流程是科学的，每个环节都是有价值的，是根据流程服务对象以及对象所要求的目标所确定的。公司领导：建设期有太多的不确定因素，现有的流程一定要灵活、快速响应。项目经理：信息部门把话题接了过来：另外，有些不走流程的就让各业务部门上传扫描件。对了，输入扫描件中的文字内容能查询出这个工程扫描件吗？据我所知汉王公司是可以做到的。（项目经理彻底沉默了）信息主管继续说道：你们在考虑问题的时候要面面俱到。我过去碰到一件事，某软件供应商设计A方案，但是不适用。我们根据实际情况拟定B方案。于是软件供应商开始根据B方案进行了很多定制化改动。最后我们使用过程中发现流程走不通了，想退回A方案，又退不回了。所以你们要在设计的时候考虑功能灵活性。通过这次会议，大家看到很多问题，不过这一切好像都是软件技术问题，是可以解决的。于是就这么定了，甲方当场宣布了后期应用规划：各业务部门以及参建单位以后都要将本部门的业务数据录入管理系统中。但是在推动过程中，软件实施人员频繁遭到了业务部门以及参建单位抱怨和质疑：业务部门：1你们能不能将所有的操作都集中在一个界面，操作太麻烦了。2你们能不能提供excel导入，自定义表单，自定义报表功能，减轻我们的负担。参建单位：1我们本身就有一套管理软件，如果使用你们的管理软件，会存在重复性劳动。2虽然可以做接口自动导入业务数据，但是我们的软件供应商未必肯给你们开放接口。3X位置得修改，XX界面也得修改，业务与系统的磨合程度还不够。以上场景只是项目实施过程中的一个片断。这里我不想做需求分析，而是对问题的本质做一个分析，同时如何实施做一个抛砖引玉：信息负责人：表面上，信息负责人既懂业务又懂技术还了解企业现状，对软件供应商与企业方起着良好的推动作用。但是实际过程中，由于业务部门的专业程度，信息部门很难提出建设性的意见。在业务解决方案这条路走不通的时候，往往就只剩下技术解决这条路了。同时，信息部门也喜欢在企业里面显示自己的技术见解，主动用技术方案去承担管理问题（国企性质还存在屁股决定脑袋的问题），这就为日后的重复开发，模糊焦点埋下了巨大隐患。最后出了问题就指责软件实施团队技术水平不够，要求增加人力。业务部门及操作人员：业务部门及操作人员喜欢钻研各种操作并尽可能的找出漏洞，以达到破坏管理系统，使自己脱离领导管控的目的。通常，他们喜欢从业务、技术、操作等多个角度将问题不断抛出，并且尽可能的将需求以及描述复杂化。最后被追责的时候一本正经的说道：业务说了几次也不懂，他们的软件问题太多，无法使用。公司领导：公司领导将管理问题归结于技术问题，因为你不了解他的价值观。最后他可以作为领导通过大家的质疑来使你在这一块无法推动最后停滞。那么项目经理该怎么做呢？首先，我们要了解领导的价值观。比如，领导说：在一切管理目标发生冲突的时候，以进度为第一。这句话就表明了管理目标的优先级别。了解了领导价值观之后，我们就会介绍：可以按标准分类以上传的方式完成各类文档维护，并给予相应业务部门的权限方便查阅。反过来，如果领导说：我们要对管理的一些盲区进行挖掘，不留一处死角。那么就表明要将所有过程全部体现在系统中，这个时候如果你说附件上传，领导显然会不满意，因为达不到他的管理目标。对于信息部门，由于他们往往是“采集流程对IT的需求”，软件实施商可以尽量不去“打扰”他们。