上海外高桥从1999年开始实施ERP系统到现在，已经10年时间。在这10年中，我们没有遇到过特别大的困境，今天主要是想跟大家探讨从什么角度来看运维，运行和维护。如果从困局来看会有一堆困境来困扰着你，如果换个思路，冷静的去看运维，那无论是对你这个企业，你的团队，运维中的每个人，都是一种提升和积累。

　　其实我们也碰到了一些问题，在运维的过程中，最大的问题就是你的老板能不能看到你花费的投入有回报，因为身为商业公司，看重的是投入产出。从他的思维上，对你的运维投入是很谨慎的。包括企业里最主要的那群人，就是中层管理人员，在使用ERP的时候，如果不借助一些其他工具，无法在SAP系统看到清晰的流程，所以中层管理者在使用的时候也会觉得很难。因此会导致你的运维做得很辛苦，付出的功劳和苦劳没人看得见，如果运维成功那别人认为这是应该的，如果做得不好，比如业务部门变革的时候IT运维没有及时跟进，那IT部门就要负责。随着系统越来越庞大，购买时的软件成本和硬件投入，服务器去支撑这个系统，服务能耗也越来越大，特别是经济危机以后，企业如果要卡费用的时候，常规来说会对IT部门下手，这是作为一个运维人员来说做困难的事。10年期间我们这些问题都碰到过。我想谈一下，在这个过程中，我们是怎么走过来的。

　　首先我想介绍一下我们系统的大致概况，我们是在2000年开始实施的，01年上线。05年7月份-06年1月份我们对实施的系统做了一次评估，并对系统的未来做了整体规划，这个评估对于我们现在所讲的运维机制有深远意义。07年做了ECC6.0的升级，现在大概到6月底就把BO做完，我们用了这个系统近10年，一句话总结就是这是个好东西。其实我们一开始也有犹豫，我们是第一批使用的用户。在这个过程中，针对刚才提出来的那些所谓的困惑，我们在解决上有我们的一套思路，主要是这几条，

　　1.打动老板，老板作为资金支出人，哪怕是买一台服务器，不打动他什么都买不到，靠什么来打动他呢？只能靠这个系统状况清晰的展现在他面前，我们企业运行的状态是怎么样的，问题出在哪里，把这些告诉他，让他觉得你这套系统是能根治这些问题的，他就会掏钱，而且还会督促你做好，只有有钱和老板的压力做运维就不是那么难了。做运维不能只是IT部门在努力，如果老板和业务部门对于运系统没有兴趣，会做得很累。

　　2.绑住中层，我们有一套办法，我们把SAP的应用情况跟SAP的培训，报表，财务运行程度，包括业务覆盖率联系在一起，开发了一个对标系统，通过这些指标我们在系统里能清晰的看到ERP系统运行状况是什么程度，每个部门的应用程度到哪一级，然后适时公布在首页上。我们在跟业务部门打交道的过程中，发觉对业务部门的考核最好的方式不是扣钱，其实是作为业务部门的领导的面子很重要，柳传志在管理联想时有过这样一个例子，公司在开会时有人迟到，刚开始就规定迟到了要扣多少钱，实施一段时间发现效果很差，于是改变规定，凡属迟到的人站着开会，试了几次以后发现会议的到会率很高。我们平时做团队运作就可以用这个方法，人其实很要面子，所以当中层人员面子挂不住的时候他就会督促下面的人来用好这个系统，同时为运维减轻负担，是靠大家来做，不是靠IT部门来做的，

　　3.在2005年，我们对R3系统进行后评估和未来的规划，总结了从上线到05年R3应用的经验和教训。我发现运维不是着眼于一个点去考虑的，在大部分企业里，ERP是代替不了整个公司的系统，肯定还有别的系统来支撑企业的整体运作，所以其实这个运维不是一个点而是一个整体，如果把整体一块考虑，就会发现运维的效率会大大提高，包括把一些用户集中起来管理，包括把安全事件，服务器，客户端，就不会为了这个系统而运维。在企业中，不要为单个的应用去运维，人员有限，会很累，从整体思考，会对运维的时间，效率整体提高。

　　在ERP系统中，在业务的演变过程中，会发现一些流程或者报表会发生变更，作为运维如何来适应变更，合理变更，因为企业在做整个信息系统规划的时候，整个ERP在系统里是属于战略这一层的，下面还有各种专业的系统，在做变革的时候会理性的思考这个功能是不是一定要ERP去实行，有的专业系统去实现你的业务可能会更好。在这个时候，就要思考整体的变更和合理的变更，如果确实要在ERP系统下作变更，同时作为运维来说，这个变更是不是合理，因为有的变更是某个业务部门提出来的，从单个的业务部门理解来说，局部来说是优，如果摆到全局里看，这个变更有可能不是最优的，这个时候就不要变更，要合理控制。就要有话语权。

　　在做运维时，我们要有一整套的体系保证，在我们企业里，我们一直在探索一种更合理，更有效的组织体系，人员会走，一种是离开公司，一种是到别的部门，人员的流动在我看来很正常，作为企业的管理者来说要容忍这样的流动。像我们这个团队从01年上线，人才失去6个，但是我们自己培养了10个。人和人才是两个概念，我们走的6个有4个是PA顾问，另外两个我们打算当PA顾问来培养，每次送走一个人我都会谈一次心，对他来说是个更好的发展，作为企业来说我们就要主动应对，要出实招。我们就要找自己的问题，这些人在业务部门，工作量很大，又要担任系统的运维工作，怎么办呢，对于我们的内部顾问，岗位加半级，权利和义务要对应，通过这种手段，我们想留住这样的人才。同样，我们也思考，我们有了这样的机制，为什么还会有人离开，这个时候就要有宽容之心，以“人”为本。同样塞翁失马焉知非福，比如他走了可以提供帮助我们的信息，还有位置空出来可以提供给下属。

　　在做运维的时候如何保证数据的准确性，我们使用的是IBM的主数据管理工具。把一些重复的，各个系统共有的数据通过这个平台给它很好的管理起来，做到数据的唯一性和可控性，做到系统的基础数据和主要数据都是可用的，同时，还会担心人走了会不会把知识带走，那新人上来，通过系统的资料，再通过内部顾问的培训，就能很快上手，这个对企业很重要。知识一定要传承下来。

　　最后谈一下现在做运维的一些新的思路。据我们了解，SAP在去年推了一个新的概念，RUNSAP，它做的阶段不一样，是针对运行阶段开始的方法论，整合了SAP的运行规则。我们现在把所有的系统都集成起来，用刀片服务器，比原来服务器能耗降低，效果也相当明显，还有就是虚拟化，我们也试过。通过虚拟化能把数据虚拟到刀片服务器上，我们大概运行了2个多月，将5个系统虚拟到一台服务器上，没出问题。这也是提供给大家的方向。节约你的能耗和投入。还有就是现在讲的比较多的就是外包，外包有几个层次，一个是硬件托管，还有就是基本服务，再一个是应用和开发，还有全部包给别人，但是收费不一样。所以我个人感觉是要根据自己企业的情况，人员的状况来决定你的外包，因为ERP上运行的很多是企业核心和敏感的数据。

　　做运维的感悟，首先我们以往都是基于系统功能去做运维，这个会带来一系列的问题，必须要基于流程来做运维，才能和业务部门对上话，跟业务部门更好的沟通。二是无论对企业还是个人都是一个提升，对于企业来说运维做好了，就能为企业创造更多的价值，对于个人而言，很多人一开始是不知道ERP是什么，但是对业务很了解，但熟悉ERP以后，对业务的提升是一方面，然后对ERP了解，学到新的知识，同时对他的人变成了企业很好的管理人才，又懂业务又懂技术，也就有了跳槽的本钱。经济危机下，很多紧缺的人才还是需要的。最后一点运维是一个生态圈，我们不要把它看成是一个固定的东西。是一个生物链。只有把这个生态圈建设好了。对于运维就是帮助，跟老板，中层管理人员，团队共荣共进。

　　答来宾问题：

　　运维期间和实施期间有个很大的转变，领导力这块。在系统的实施期间，项目的领导力是非常强的，但是在运维期间普遍会减弱，可能就会把领导力交到信息中心。作为话语权比较弱的信息部门，如何来协调其他部门？

　　我个人体会还是我们不要把ERP当成一个项目在做，这点很重要，如果当成项目就会遇到项目做完了，剩下的就是信息中心的事。在过程中，每隔一段时间老板会来跟你拍板一些事项，然后项目经理每周开例会来传达。那做ERP很重要的一点就是实施之初我们要想清楚，一是从项目实施之初就要不停给老板灌输一个理念，ERP是一个持续的，改进的项目，不断投入。咨询公司也要导入这个概念，二是做为项目组，容易被忽略的一个问题。就是在刚在做ERP的时候做出来的系统是在给业务部门在用，并没有给老板用。所以当项目做完了。老板就会跟你们说拜拜。他看不到他花的钱到底有没有用。在这个当中，我给大家的建议是你在做启动项目的时候。无论如何要给老板打动他，下个套给你老板，先做这个就不会被他甩掉。同时对于项目来说压力很大，老板是很忙的人，第一个套中的话，以后的套要求会越来越高。你要渐进实施，否则不能满足他以后的要求，也会被甩掉。三是在项目实施过程中，我们的国情和国外不一样，执行力不如国外，员工在这个时候思考的是多一事不如少一事，上了ERP后，对每个人来说对每个人工作量都增加了。在这个时候你要让你的人保持这种精神状态，不靠一开始的不断洗脑是不行的。

　　三个问题：人才培养，从信息的支持怎么转到业务支持，二，SAP的权限要求很严，但是权限有扩大的趋势，怎么解决。

　　一：信息人员怎么转型业务人员，我们的体会是，首先信息部门的头，我们自己首先要懂业务才能做信息，头不会干，下面的人不会。我原来大学里学的是计算机，到了单位我做的是市场部，做完以后才到了It部门。这样带来的好处就是知道业务部门想要什么，在做的过程中跟他有平等的语言，沟通方便。二是我们选拨人员是从业务部门里抽人到信息部门。人在信息部门呆久了也会有惰性，所以我们现在尝试信息部门的人也要去参加业务部门的会议，去了解更深的业务需求，包括我自己每天就去生产线了解生产，我们现在也能参与企业一些重要决策。

　　二．SAP的展示界面比较古板，不方便，德国人做事寻求简洁的方式达到你的要求。那我们用什么手段展示给你的管理层看呢。我们是这样做的，最早我们在R3上，拿出有效的数据给老板，后来老板处了数据，还想深层次的了解，现在用BO，解决了SAP的界面老的问题，会让老板很亮的感觉。所以我们的我们的手段要一点点改变。

　　三．关于授权问题，我当时做过将授权全部打开，到底要放到什么程度，我的建议是实施的时候，除了财务，其他的都放给别人。然后在过程中，。持续一点点去收权利。因为首先初上，不知道权限的交叉在一起会产生什么结果，每个人的权限到底定在哪。所有的终端机都在管理，所有的操作都可以追溯，在做权限的时候我们并不担心，要做到放多少，收多少心里有数。

　　问：两个问题，一是系统的流程变更，有的借助SAP来完成，有的借助第三方来完成，还有在SAP里要在流程最优化的时候来完成变更，你在最优化上是怎么判断的。怎么来把握？二是在系统上线很多年后，会产生垃圾数据，你们是怎么做的？

　　一，变更分几个阶段，在实施过程中的变更，上线以后的业务运作的变更，我们怎么来控制呢，你在最初要把握这样几个原则，首先在做启动项目之初，项目经理很重要。根据我们的经验，最好的项目经理不是一把手，因为一把手没时间跟你讨论流程合理还是不合理，你要招的项目经理必须有实权，并且有一把手的授权，有个借鉴，我们当时做的时候我们的项目经理就是业务总经理，是老总授权的，很很大幅度减少变更的需求。实施方项目经理也有很大权力，引进ERP的目的是要你照着它做，上线以后的变更也是一样的道理，在实施前要反复进行讨论，我们每个月会开一次SAP运行的例会，解决运行中的问题，哪怕是最细小的问题也会讨论，每季度会开SAP工作的例会，来决定重大事件，包括你讲的流程变更，如果涉及到业务变更导致业务无法运作，就开专题会。确定内部顾问全部到场，不是一个单业务的流程。难是难在跨业务的流程上。一定要控制二次开发量，开发量越大，你的运维和升级会碰到很头疼的事情。

　　二．有两种做法，一做评估，整体老数据，二是归档功能，对数据一个是控制源头，另一个是控制基础数据。过一段时间就要整理。

　　2个问题，一是在升级过程中，业务部门如何更好的去面对升级，二是后台配置能给业务部门吗？

　　一在升级过程中，不要为了升级而升级，纯粹的技术升级，业务部门不会支持，所以升级必须为业务去升级，要给业务部门引导，说业务部门的原来某个功能在系统里实现不了，升级以后能够实现，甚至可以做模拟版本来做测试。

　　二是后台配置不要给业务部门动。人都有好奇心，知道可以改流程，业务部门乱动，会导致整个业务部门的乱套。