避免前车之鉴：企业系统运作效率的改革

ERP项目虽然暂时中止，但企业系统运作效率的改革依然迫切，S集团公司率先跳出了短暂的行业寒流，很快重新达到满负荷生产的状态。IT部门也一直在为重启此项目做准备，管理层人事方面也传来好消息。经过几个月的短暂调整，S集团公司的高层管理团队日趋稳定，公司做了长期愿景，并对将来的5年提出了详细的发展规划，那么ERP改造问题更是绕不开的话题。IT部门也从2013年第三季开始，发现了气候的好转，项目重启的氛围逐渐升温，机会终究如约而至！

有了上一次的经验，IT部门很容易地重新勾勒出新项目的大致框架，2012年的经历已经让IT团队对于此案的认识已经高度统一。某种程度上说，挫折对于一个团队反而会激发团队的斗志，增强团队的凝聚力，印证了那句名言：“那些打不垮你的，终将成就你。”在2013年底的一次高层管理会上，IT部门将这个画卷给公司管理层及用户单位的同事们徐徐展开。

首先，IT部门将各使用部门之前所遇到的问题做了分类和汇总，将各使用部门所要解决问题的轮廓大体上勾勒出来，也列举了很多专项问题，比如集团内部买卖交易的重复工作，集团内部法定合并报表的困难性，人员数量随业务增长而线性增长等问题。

其次，IT部门解释了这个案子的困难：第一，这是一个大工程，企业流程再造牵涉公司诸多单位，涉及财务、销售、计划、采购等诸多部门；第二，这个工程涉及多部门职责的重新明确，牵扯到责任再分配，对于S集团公司这种多部门扁平化管理的公司，需要各部门向上落实解决；第三，这个工程还涉及所有用户的培训和适应期，需要各部门向下落实解决；第四，这是一项前所未有的开创性工作，之前业内也没有明确可参考的先例。

最后，IT部门提出了两点解决方向：第一，升级SAP主系统，毕竟这个系统老旧已经是不争的事实；第二，对于业务瓶颈做专项调研，专项解决，以实现流程彻底再造。

对于公司管理层而言，推动ERP系统的改革的决心早已下定，但是其中的困难和风险，仍是不可承受之重。所以，管理层要求两点：第一，我们需要对于2012年的案子进行一次全面的剖析；第二，我们还是要将最终方案再细化一下。毕竟之前的前车之鉴，而且这个案子涉及公司绝大部分部门，需要谨慎且要万无一失。

在公司决意推动ERP项目进展的同时，IT部门也与主要使用部门，包括财务、采购、销售、生产计划部门，马不停蹄的针对第一次失败的原因进行深入探讨，在起始的会议中，大伙笑道：“我们部门之前为这个项目开了蛮多追悼会了，这次大老板还要让我们来个尸体解剖。”不过玩笑归玩笑，终究大家必须针对问题检讨，大体归纳了第一次ERP项目中途暂停的原因有以下几点：

第一，项目范围不明确，扩展思路模糊。在策略上，第一次ERP项目是采用推倒重建的概念，以重新定义公司所有的企业流程为目标，立意虽远大，但项目战线拉得太广，没有清楚的项目范围，甚至说没有总体思路。项目范围的再扩大时，也没有方向性，没有在一个总体思路上。

第二，在项目范围尚不明确的情况下，限定了明确的项目完成日期，没有考虑余量，没有回旋余地。各部门的需求讨论的时间不足，只有3个月的时间作重建的需求讨论，造成在项目启动前，仅完成初步的需求讨论，而厂商并无法根据这么笼统的需求做出相对蓝图设计，使得在蓝图设计阶段变成是澄清需求的讨论，于是在蓝图设计较原先定义延长了2个月。

第三，没有使用部门的统一的协调者。也就是没有使用部门的业务经理代表来统一用户端需求，并协调确定相关需求。使用部门人员代表参与度不够，开会之前议题不明确，没有针对性，分工亦不明确，同时部分项目成员没有被授予足够的代表性，在项目会议中对流程无法做出决定，用户端代表无法拍板，很多会议连结论都没有，更不要说实施了。

第四，用户部门站在项目支持的角度参与项目，部分用户端人员担心新系统上线后对自身权责的变动的影响，对于涉及职责变更的部分有强烈的抵制情绪。

第五，合同结算方式不合理。公司和服务商签订的合同不合理，按时间和人数来计算费用，但如果实际上没什么进展，就造成了资金的浪费，这种签订模式，对于服务商的拖延和误工也没有约束力。

第六，追加预算超出预期，在蓝图阶段后，较具体的需求才被澄清，而且超出原先所提，于是厂商提出了追加预算要求，而且补充预算申请超出原预算高达100%。(www.xing528.com)

对于2012年的项目，虽说有当时内外的问题导致项目中止，幸运的是，公司管理层非常重视这个新项目，有了坚定的支持，在一切稳定就绪后，此时可以说是此项目重新启动的最佳时刻。

基于此“天时地利人和”，IT部门基于出现的问题，拿出更为详细的整改措施和解决方案。即采取更好的工作方式来规避这些问题的现象，以打消公司管理层的顾虑。

第一，CFO担任项目委员会会议主席，由其召开项目委员会议，邀请各单位最高主管与会，也取得各单位主管承诺，要求项目的成员对项目会议决议必须具有决定权。

第二，采用业务经理协调的制度。由使用部门安排本部门的业务经理，来统一协调所有用户需求及决议，来协调公司所在部门的进展，确认涉案人员的权责，周旋各部门的人事安排和情绪安抚工作，降低部分用户的抵制情绪。而IT部门的业务经理只要盯这些业务经理即可，避免跨部门的“政令不通”的问题。

第三，明确项目蓝图，流程再造时合理取舍。所谓“磨刀不误砍柴工”，为了避免实施阶段大方向上的变动，在蓝图阶段需要尽量详细地确立项目目标，并初步提出解决方案，还要初步讨论解决方案的可行性。这样使得项目范围是可控的，不再漫无边际，而且是具体可行的。同时，对于流程的再造，需要合理取舍，将重点放在那些当前无系统而用户需要极大人力来处理的流程。对于已运行良好的流程，仅看是否仍有改善空间。

第四，采用双周滚动的会议时间制度。为了避免意见纷杂不统一，严格限制会议人数，尽量只邀请关键用户参会，并选出模组组长及关键用户，协调本模组相关业务流程，包括协调一些非项目组成员。

第五，确立以会议目标导向的开会制度。为了提高会议上的高效率，事先协商好会议目标、需要讨论的模组问题、文档准备及合适参会人员，会上严禁讨论不相关话题，尽量不转移关键话题，一个会议目标一个会议目标的解决问题。

第六，明确每一个工作的细节和负责人，以确保各项任务按计划完成。如，确定了第二天会议的议题后，相关人员必须在会议之前充分准备会议相关的文稿，以确保会议效率。

第七，以实现最优化业务流程目标，给予项目时间一定的弹性，不强求项目周期而降低项目要求。项目启动时仅明确了蓝图设计的时间表，大致确定采用分两个阶段实现的目标，但具体的实现时间表待蓝图设计完成后再考量工作量设定项目实现点。如，蓝图阶段经充分的讨论和技术分析，采用SAP BW数据抽取和分析报表方式，取代原计划的SAP利润中心管理功能，更能实现基于销售团队和各个制造厂的获利分析，将该功能实现从原计划在项目第一实现阶段调整至第二阶段实现。

第八，签订以Milestone为节点的分批结算合同。和服务商签订合同时，需要按照完成项目的Milestone来结算的方式，各部门需要和服务商一起坐下来商议各个Milestone，然后签订分批结款合同，这样对于甲乙方都比较公平。

第九，细化项目预算，需要将项目预算进一步细化。在需求讨论上，确保在内部用户有足够的时间将需求澄清清楚，再请外部顾问提出方案。在外部顾问进场前，IT与用户要针对需求详细讨论，避免预算大幅追加的风险（事后证明，前期IT部门与用户部门进行了6个月的详细讨论，第二次ERP项目无任何的预算追加）。资金预算需要更细化，更精细化，不明确的地方要留足余量，或者告知服务商，避免预算追加的问题。

第十，明确服务商筛选条件。选取服务商时应当重点考量服务商是否具有类似的项目经验，是否在半导体具有行业经验，是否能对所要解决的问题提出合理的方案。总结如下：