早年，笔者所在的中国石油国际事业有限公司SAP系统在经过半年时间并行后开始独立上线运行，初步获得成功。在经过一年多时间的反复磨合和调整后，目前系统各项功能运转顺畅，基本实现了上线时的各项预期功能。在参与了整个项目的设计与实施，并作为推进项目进展的一个关键用户亲历诸多环节后，笔者有很多感慨与收获，在此仅就个人体会最深的几点拿出来和大家分享。

　　成功的经验

　　1.实施SAP决不是单纯的财务系统升级，而是一次组织的变革，它的成功不是依赖于项目实施团队把系统设计得有多好，而是取决于最终用户在实际工作中把系统用得有多好。因此，实施团队一定不要把自己想象成敢死队，一味冲锋在前，而是应该作为教练员和辅导员，耐心地帮助所有系统使用人员扎扎实实地掌握好系统的各项功能，这是项目能否取得最后成功的一个非常关键的因素。笔者所在实施团队在这方面采取了很多行之有效的做法。

　　（1）为督促项目使用人员扎实掌握相关技能，在人力资源部门的配合下，要求所有系统使用人员均须通过严格的培训和考试，拿到上岗证书后才能操作系统，凡不能掌握系统使用功能的一律换岗。

　　（2）最终用户的集中培训和考试内容以实际操作为主，基本理论、概念阐述紧扣实际操作需要。SAP是一个实际操作性极强的系统，培训时如果仅是泛泛地演示系统功能和操作，而不让最终用户去实际操作演练，一旦系统上线，很多潜藏问题就会暴露出来。笔者所在实施团队在组织最终用户培训时，70％以上的时间都是安排最终用户自己在系统中操作演练，遇到问题再帮助他们澄清基本概念和相关理论。最后过关考试时80％以上也都是上机操作题。这样做的好处是使所有最终用户都扎实地掌握了系统的各项操作，培训过程中的大量操作演练也使得很多在今后实际工作中可能遇到的问题得以及早发现并解决。

　　（3）注重操作手册的汇编整理工作。我们的操作手册不但有各项实际操作的具体步骤，还有专门的手册来讲述关键概念和案例分析；手册是按照掌握系统的熟练程度汇编成册的，编号靠前的手册讲述基本概念和基本操作，随着编号的递增，手册的专业性和复杂性也逐渐增强，最终用户能够根据自己对系统的实际掌握程度，依据手册编号顺序快速找到自己需要的帮助；手册全部在企业内部网上公开，供所有最终用户自学，并且定期修改完善，按版本进行维护。实践证明，操作手册在推广系统操作、帮助员工记忆培训内容、帮助新员工迅速掌握系统功能等方面发挥了巨大的作用。同时，手册的系统维护也确保了公司没有因为实施团队成员的流失而影响到其他用户对系统的掌握水平。

　　（4）注重和基层操作人员保持密切的联系，不断听取他们的意见。通常，能够进入项目实施团队的都是公司财务和业务系统的精英分子，那些处在基层、实际工作中最经常需要和系统接触的员工往往没有机会参与到系统设计中去。实施团队如果不能充分重视基层人员的意见，保持和他们的紧密联系，往往要到系统上线后才会发现一些功能的根本无法实现。

　　（5）充分利用BBS、RTX等在线沟通工具，在整个公司范围内建立起顺畅的沟通机制，使所有系统使用人员都有渠道来反映他们在系统操作中遇到的问题。为此，我们还安排专人对问题进行分类、整理，根据这些问题及时调整系统的配置，必要时通过新增开发来不断完善系统功能，使系统的使用越来越贴近实际工作需要。

　　2. 注重项目实施团队成员的选择。项目实施团队成员是否搭配合理，成员之间是否配合默契，是SAP项目成功实施的另一个关键要素。就笔者所在实施团队的构成来说，除了外聘的项目实施公司顾问外，公司内选派的项目实施人员中既有精干的中层干部，能随时向公司高层反映项目进展中的问题，又有熟悉日常业务、通晓业务需求的业务骨干和基层员工；既有资深员工，也有新加入公司的外聘人员，以使系统设计在符合公司既有业务模式需要的基础上，充分借鉴外单位的先进经验；既有财务部门的业务主管，也有业务部门骨干人员，使SAP系统的前台和后台的具体操作得以贯通；既有总部的关键用户，也有分支机构的一线操作人员，可以确保系统在满足总部管理要求的前提下也能符合分支机构的特殊要求。团队成员在性格和能力上的搭配也比较合理，既有善于指明方向的领导干部，也有扎扎实实埋头苦干的员工，还有同时通晓业务和技术的业务骨干。

　　系统上线后，实施团队的后期管理也是一个非常重要的环节。笔者所在公司在系统上线后专门制定了针对关键用户的管理制度，确保关键用户有足够的资源能够继续学习，同时也要求关键用户承担起不断完善系统、提升最终用户操作水平的责任。

　　3. 要学会善用公司领导资源。SAP实施是公司一把手项目，但如果在实际操作中拘泥于这一说法而要求公司领导事事支持，在笔者看来，既不现实，也不明智。SAP项目的实施通常需要花费很长的时间，期间遇到的问题有些是重要的、有些则无关大局，而公司一把手的精力和时间是公司极其珍贵的资源，因此，项目实施团队要善于利用公司领导这一宝贵资源，不到关键问题和重要环节，不要轻易动用领导资源。那么，哪些是关键问题和重要环节呢？依笔者看来，一是协调资源，二是处理关系。协调资源就是要领导确认项目支出预算及调整、安排部门予以配合支持、在项目实施过程出问题时追加顾问人数等。处理关系主要是指在SAP实施过程中通常会牵涉到部门之间工作量和利益的再分配和再调整。比如，因为实施SAP，一些部门由于工作量减少需要减员，而另一些部门因为工作量增加需要增加人，或者原来一些部门内部私藏的信息现在需要公开，诸如此类事情往往需要公司一把手来处理，以消除项目前进过程中的障°，使项目得以继续推行。

　　失败的教训

　　1. 对系统功能要有合理的预期。第一次上SAP的公司都容易把SAP想象成无所不能的系统，希望一步到位、一劳永逸，于是把所有管理提升的想法都一鼓脑地扔给项目实施团队，要求其在系统设计中予以考虑。事实上，这样做无异于拔苗助长，欲速而不达。因为，项目实施的资源和时间通常是有限的，要用有限的资源和时间去实现那些自己可能都未必想得很清楚的管理需求，很可能会造成企业最基本的管理需求因为投入不足而考虑不周，最后因为舍本逐末严重拖累项目的整体效益，同时也使整个实施团队陷入泥沼。因此，正确的做法是要把企业提升管理的需求按轻重缓急进行整理，分阶段实施。在向实施顾问提出系统功能开发需求时最好有领导把关，仔细审核，按需求缓急认真排序。实施顾问并不清楚企业的管理需求，他们只能根据公司提交的需求缓急来安排项目的开发顺序。如果企业自己在提交项目需求时没有经过成熟而充分的考虑，就会造成顾问宝贵时间的浪费。笔者在此次项目中就犯了这种错误，一些程序在顾问辛辛苦苦开发后实际工作中却使用很少，但是这些程序的开发挤占了顾问大量的时间，一些最基本的系统功能由于没有足够的时间去加以完善，最后只能再追加资源进行开发。

　　2. 要充分重视项目设计阶段的投入，包括时间和人员的投入，尤其是资深业务人员的投入。资深业务人员是公司的业务骨干，让他们投入项目会使系统设计少走许多弯路。但同时他们的投入无疑会在一定程度上影响公司正常业务的开展，因此公司在决策是否让他们投入项目开发时通常容易有所保留。但实际上，此时的一点保留看似确保了公司业务的正常发展，但由于这些业务骨干未能充分参与系统设计，系统设计上很容易出现问题。而此时再来解决设计中的问题，付出的成本往往要增加好几倍，实在是得不偿失。这个错误笔者已经犯过，希望后来者能够引以为戒。

　　SAP系统成功实施的影响

　　此次SAP系统的成功实施使公司管理水平有了大幅度的提升，具体体现在：一是由系统根据业务触发的业务工作自动生成财务数据，不仅确保了业务数据和财务数据的一致，而且由于数据共享，大大减轻了财务人员核对数据准确性的压力。二是总部直接能看到分支机构所做的每一张凭证，加强了总部对分支机构的财务管理力度，降低了财务报表做假的风险。三是由系统自动汇总各分支机构数百张报表并生成系统合并报表，工作效率和工作质量都明显提升。四是公司对业务采取单元一体化的矩阵式垂直管理系统，借助于SAP的BW子模块（Business Information Warehouse，商业信息数据仓库），公司能够实时获取单元整体的经营信息，而且通过BW的数据挖掘功能，总部能够从单元整体经营状况直接穿透到具体公司的某个具体产品的销售明细，极大增强了总部单元一体化的管理力度。此外，SAP系统的成功实施还使得公司在业务流程再造、内控制度建设、优化资源配置等诸多方面都取得了长足的进步，为公司实施下一步的战略转型打下了坚实的基础。

谁来主导ERP项目：

一个企业决定实施大型ERP时,遇到的第一个问题就是“ERP项目应该由谁来主导”。

在讨论这个问题前,有一个前置问题,那就是“ERP项目应该由谁来主导”这个问题应该由谁来决定。这是一个奇怪的形象,但是国内很多企业确实发生了。当企业决定上ERP后,无论是老总、总经理工作部、各级部门还是工作人员都异口同声地说“ERP很重要,一定要上”,然后呢,然后就没有然后了,开始进入混乱局面,因为没人知道“ERP项目应该由谁来主导”,更没人知道到底是谁应该来做这个决定,也许有人知道,但他不是重点利益相关方,于是他闭口了。于是经常会出现为了保障公司对ERP的进度要求,项目已经启动,但是却没有明确的主导方,各部门都在有限参与,原因是不要因为没有参与而被批评,但真正在推动方面,各部门又都不全力推动,这是可怕的一种局面,毕竟在最后项目效果不佳甚至失败需要有人出来被打板子时,真正要负责的部门终归是逃不脱的。

其实,这个问题也很简单,谁决定上ERP,谁就应该解决“ERP项目应该由谁来主导”这个问题,所以,决定上ERP的人,一定要明确ERP主导部门,否则ERP项目不会成功。

好了,终于能到正题,到底哪个部门应该主导ERP项目呢?对于这个问题,相信不同的人有不同的答案,并且每个答案都是对的,都是有道理的。主流观点如下:

1. 应该由财务主导,因为财务是一个企业的命脉,各业务部门均为财务服务,各业务的最后环节均是财务;大多公司的财务部门地位都很高,也有发言权;

2.对于生产型企业,应该由生产部门主导,因为生产部门的人数占了公司绝大部分人数,稳定生产是公司赖以生存的根本,信息化要保障生产,只有生产保障了,财务利润自然会来;

3.大多企业还是由信息部门主导,因为人的常识认为,ERP是信息系统,信息系统的实施当然是由信息部门主导了;

……

还有很多不同的情形,但每种情形在不同的企业都有成功案例、也都有失败案例,说明什么呢?个人认为,说明真正判断哪个部门主导ERP的判断标准不是上面的几条,个人认为判断应该由哪个部门主导ERP的判断标准如下:

1.应该由一个期望上进的部门主导ERP项目;

2.应该由一个有话语权的部门主导ERP项目;

只这两条即可,原因如下;

1.应该由一个期望上进的部门主导ERP项目

经常会听到有的企业的信息部门发出这样的声音“ERP是业务系统,应该由业务部门主导,凭啥让我们信息部门主导啊,我们又不懂业务”;也会听到有的企业的业务部门发出类似的报怨“ERP是信息系统,应该由信息部门主导,我们只是公司多个业务部门中的一个,我们怎么能管的了别的部门的事呢?老板也不知道怎么想的”,每当听到这样的话语,我心中总是泛起一个词“恨其不争”,也会泛起另一句话“也难怪你们的部门一直地位低下”,如果企业已经把ERP的建设任务交给一个部门,其实隐含的也就把协调各部门的权力交给了这个部门(ERP建设相关的协调权力,相关这个词的含义好丰富啊,你懂的),ERP实施又是一个全公司管理改进的工程,如果你的部门真的有实力,把ERP实施好,那你部门的地位就不可同日而语了。这是机会,而不是负担。我也亲历过有一个企业的信息部门,通过实施信息化、参与企业流程优化,最终更名为“流程优化及信息管理部”。

所以ERP要由一个上进的部门实施,因为公司已经给了他权力,剩余的就看他是不是想干一番成果出来。对于上进的部门,这是机会,对于推卸责任的部门,这是一个沉重的包袱。

2.应该由一个有话语权的部门主导ERP项目

这个主导的部门必须有话语权,有的企业把ERP交给信息化部门,最终失败,不是因为信息化部门不懂业务(虽然确实不懂,但这不是根本原因),而是因为信息化部门及上级领导在公司没有足够的话语权,想做的工作没有得到其它部门的有力支持。有的企业ERP由信息化部门主导非常成功,原因也在于有一个强势的信息化领导,或者领导信息化部门的副总(或老总)非常有话语权。

只要有上述两个因素即可帮助高层决定ERP的主导部门,部门领导懂不懂业务没有一点关系,真没有一点关系,但是要有懂项目管理、懂业务的人担任项目经理整体管理项目即可。

版权声明：

凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。