ERP项目实施过程中的甲方团队组织
一、前言
经过这么多年的实践和大量的专家的总结，关于ERP实施的一些话题几乎都被说完了。但是，总是有很多朋友问一些在实施过程中的具体问题，尤其是关于甲方的团队组织问题。
以前，大家不是很在乎这个问题，总觉得，我花了这么多的钱，你们乙方(服务商)应该替我全包圆了，如果我还是要花费这么多的精力，那我不是亏了么？
这个心态在很多情况下还是常出现的，大家有时候还是不自觉地以到商场买东西的这种心态来对待，有时候有的人就直接说出这类话来。不仅仅是在ERP项目上，在很多别的譬如PLM、OCS(协同办公系统)等方面，也有这样的情况。
这种心态可以理解，虽然目前ERP已经逐步达到要普及的程度，但是，问题也是越来越多了。就以我服务过的一家企业来讲，数年前我经朋友介绍加入这家公司，负责IT业务(后来又增加了一些别的业务)，当务之急就是一个执行到三个半月的SAP R/3 ERP实施项目。当时实际上情况是很紧急的，因为项目从调研开始已经过去了多半年，正式启动也已经三个半月了。但是，现状是很有些混乱的味道的。我到任的时候，除了老板和一位介绍我加入的高管之外，其他的人都不认识。更不用说部门级的主管们和业务流程了。一坐下来，我就知道了问题实在是很麻烦的。最后用尽了各种办法，最后还是成功上线了。我离开的时候，提醒过：半年到一年左右，必须重新整理一次；内部服务团队必须尽快优化一下。
不过，最近与了解他们的近况的朋友聊起来，说：现在那个系统无法满足新的业务需要了，搞得很有些混乱。因为业务也发生了很大的变化，增加了一个新的事业部，是与原来完全不同的产品。
为什么呢？
答案就是：项目实施前的很多该甲方做的准备工作不充分，尤其是甲方内部服务团队的构成，这会影响较长时期的应用效果。那家企业的问题在于，业务内容和结构都发生了很大的变动，但是，ERP的架构还是原来的。因为，如果不进行一次大的改动，是无法让这个系统适应现在的业务要求的。而为何到了现在才感觉到呢？甲方内部的服务人员干什么去了？
疑问很多，也是可理解的。
实际上，现在看那家公司，主要问题在于：一方面是当时选择的乙方服务团队不是很理想，这个话题很容易明白，因为要严控成本的原因，乙方无法找到足够专业经历和水准的专业工程师(我在这里不用顾问，而是用工程师)，这方面是一分钱一分货的。另一方面就是，甲方的服务团队组织不合理，这是因为甲方由于各种原因无法在项目启动前准备好理想的人员组合；项目上线后又没有适当地调整人员结构，以为万事大吉了，不成想把问题就一步步地积累下来了。
今天我们就专门就这后面的话题来谈一下甲方的团队的组织问题。
为了说清楚这个问题，我们首先就要搞明白甲方团队的使命是什么。甲方团队的使命就是把本企业的ERP实施项目从项目筹划、需求调研、项目启动、项目执行，一直到成功上线，并稳定运行。同时，让这个系统服务于本企业的经营管理活动。
这个使命决定了，甲方的ERP项目团队是一个基于整个项目生命周期的持续性活动。虽然甲方项目团队的最终使命是让系统成功运转，但是不同阶段的任务是不一样的。因此，要根据不同阶段的需求特点来具体考虑，而不是一群人一杆子扎到底就可以做得好的。不同的阶段的任务不同，参与人员和组织方式也需要调整，否则就很容易引起诸多的麻烦和意想不到的问题。
基于这个思路，我们从实战的角度出发，对甲方的团队在不同阶段的组成及组织方式，根据整个ERP项目周期的发展，进行详细的说明。
二、项目不同阶段的组织方式
1、前期的项目准备阶段
这段的主要任务如下：
Ÿ 组建项目启动小组，开始内部的准备工作：3人左右，主要要求的是对企业内部的情况比较了解，建议这几个人中安排一个懂财务业务的，如果有人同时对质量管理体系管理很有经验，更理想。
Ÿ 对企业内部的需求和现状进行分析和总结，提出初步的需求报告，报请高层讨论并批转准。 Ÿ 根据高层讨论的意见，开始选择管理咨询服务商或ERP系统实施服务商。这一点，我还是建议先找个真的懂企业管理的管理咨询服务商来帮助以下的好—唯一需要留意的是，他们必须与ERP系统实施服务商密切配合。否则，上世纪90年代的那些失败的管理咨询案例还会重演。
2、服务商调研阶段
Ÿ 根据上面确定的使命，重新组织这阶段的项目小组：这次的小组，主要的成员要求分析能力、沟通能力和文字组织能力，能够帮助项目经理来分析和整理调研带来的大量的资料，并提出建设性意见。除了项目经理，人数在3—5人比较好，其中1人负责资料和文档的整理与保存。
Ÿ 开始启动调研活动：一般的企业，很难专门拿出一支队伍来来这件事的。但是，con个长期利益上考虑，如果能保证有2-3个人是从开始就一直参加的，这对企业是很有好处的。 Ÿ 阶段性的评估：在初步调查潜在的供应商之后，需要尽快选定2-3家合适的左后最后的参考。不能低于2家，最好不要多于3家—太多了会让主持项目的人焦头烂额，待处理的信息太多。实际上，对于有一定经验的CIO来讲，这一阶段，已经基本上知道哪家合适了。但是，这时候需要在内部组织领导层来参加这个阶段性的评估会，让高层知道实际的情况。一个客观的对比和分析报告时必要的。
你可以看到，这阶段是非常重要的。这个活动，需要全程的记录，最好这样：当初步调查完潜在合作对象后，根据内部的评估，选定最后的那2-3家。然后就要着手准备参观他们的成功案例--这很重要，虽然没有一家企业是相同的，但是同行的使用经历是非常重要的，至少会为我们减少很多的风险。
3、对服务商的深入调研
Ÿ 这一阶段的任务是为最终决定与哪家合作做好所有的准备。这个阶段因为牵涉到很具保密性的内部讨论，项目组核心参加人员不得超过3人，免得人多嘴杂搞得项目执行过程谣言乱飞。 Ÿ 根据上阶段选定合作伙伴的意见和名单，安排进一步的很具体而全面的调研。一方面考察并落实对方的实施人员名单和具体的安排，同时要着手进行成功案例调研。这个调研，需要提前做好准备，我在以前的文章中列出了如何准备这样的事情的一些参考项。
Ÿ 对每个调研对象的信息进行分析和总结，提交评估报告。这个评估报告的具体方式，可能因企业的类型而不同，不过对于制造业来讲，可以大致给出个参考性的样板。
Ÿ 本阶段的结束，需要把所有的上阶段选定的合作伙伴的调研报告总结出来，拿出一个综合分析报告，交给高管层来做最后的决定。因此，制作这件报告的人，一定要少，1-2个人。然后着手安排一个最后的评估会——老板最好参加。
4、项目正式启动
这个阶段实际上很短，但是起着非常重要的作用，其使命就是尽快组建甲方项目实施团队，并启动项目：
Ÿ IT部门的主要成员：这部分的构成很容易理解。除了项目经理之外，财务、物料、生产、品管、销售和基础系统等部分是必须的，有的还需要一定的内部开发，也需要配置1-2个人。 Ÿ 业务部门的人员：除了上面的IT系统的成员，就是来自业务部门的人了。我以前参考在京东方时期的韩国同事们的经验，写了一些。我现在觉得，结合中国的情况，也可以给出适合中国情况的组合：每个模块所涵盖的业务部门都需要配置至少一个专门的业务骨干，这个人的要求是最少在这个业务上有五年以上的经验，对本部门所涵盖的业务有比较全面的理解，如果没有特别原因，应该由部门长担任；另外再配置一个关键用户，这个人需要三年以上的业务经验，有一定的IT应用基础最好。这两类人是保证业务流程能说得明白、画得清楚的关键。财务部门，必须抽调部长、科长层的核心员工加入，因为财务部门的工作占整个项目实质工作量的一般左右。
Ÿ 其他专业人员：除上面所言之外，建议再加上一个专职的文档管理人员(可以是在本项目中的专职)和至少一个质量管理体系方面的专业人员。这一点，我在以前的项目总结中也讲过，自己也深受其益。实际上因为习惯的原因，一般企业在组织项目组成员时大都是考虑计算机专业的，但是，这些人除了对技术比较明白之外，对业务实际上不清楚，而真正对企业的各部门流程了解比较全面的就是质量体系管理部门。这些人，在审核和确定业务蓝图的时候，可以帮上很大的忙；在后续的士哟哦能够和维护中，可以参与管理每一次的流程修改和变动、相关流程文件的确认以及物料编码等基础数据的总体管控。如果有条件，最好再聘请一个资深的ERP专家，最后外部的指导者，全程参与。但是，这人不是所谓的监理，是个知识何经验上的指导者。
5、业务流程梳理与业务蓝图的确定 5.1 梳理业务流程，确定业务蓝图
前面讲了很多，实际上都是序曲，这一阶段才是实施ERP的最实质性的阶段。这个阶段的使命是很明确的，那就是梳理业务流程，确定业务蓝图。到了这阶段，有时候会让人觉得可以松一口气，似乎要看到隧道口的亮光了，但还是别忙着乐观。
从技术上看，ERP是一个基于财务测算的生产与库存管理软件系统，除了生产和库存管理活动，还包括财务管理、人力资源和质量管理等业务内容。但是，如果没有对实际业务的分析和整理，并将系统与业务的应用结合起来，那实际上等于一个游戏软件，与现实无法接通，也就失去意义。
业务蓝图阶段是ERP实施过程中最为实质性的一部分，蓝图确定的过程就是对企业现有业务流程进行分析、整理和优化，并提出在应用ERP系统之后的业务流程的这么一个过程。 5.2 实施过程中的观念差异与不协调的处理
在这个转化过程中，起主导作用的主要是乙方的顾问和甲方的业务骨干（包括业务骨干和关键用户）。IT部门的人(也就是未来的甲方顾问)的作用更多的是作为乙方顾问的联系人和助手，主要是信息收集和对系统的学习，并在讨论过程中做好记录。这种时候，由于业务流程的梳理和优化往往导致员工之间以及部门之间的互相不理解，引起争吵甚至冲突。
实际工作中，绝大部分情况是观念上的差异，以及对各自习惯的盲从——这一点不仅仅是对甲方的业务人员而言，乙方的顾问也会经常犯错误。因为，每个顾问实际上都是在利用自己以前的经验和受到的训练来作为工作的基础。但是，现实中每个人的知识在实际的业务运转环境中都是不完备的，多年的实践活动中没有发现任何人能做到哪怕是对一个很专门的业务的所有情况的了解！因此，重要的是要互相沟通彻底，彼此理解对方的真意，而不是互相拿自己过去的经验和知识背景来抬杠！
对于确实有利益冲突的情况，也需要很认真的协调和裁判。在很多企业中，对业务流程和具体作业活动的了解和掌握，在某种程度上往往是和部门主管、业务骨干等人的个人利益和职权感有很强的关联的。在很多国企中，这甚至是一种权力的象征，直接关系着每个人的具体利益。这种情况下，任何理性的冷冰冰的逻辑都是需要认真的斟酌的，最佳的方式就是让CIO和企业高层介入来从整体上进行裁决。这个过程实际上是个利益博弈和均衡的过程。这也就是很多业内人士所谓的冲突和阻力。实际上在ERP实施中在所难免，但不是媒体上渲染的那么严重可怕，否则这家企业都没必要上ERP，先把自己的内部管理体系理顺是当务之急。指靠着一个ERP项目来做这件事，那是危险的！
但是，无论甲方还是顾问方，都必须从精神上对这个阶段高度重视。甲方的项目责任人，包括项目经理和CIO，都要紧密跟踪项目的进展，有问题的时候随时介入解决那种纠缠在一起的争吵和辩论。
5.3 业务流程梳理的价值
业务流程梳理和优化是个无法绕开的阶段，也是最有价值的阶段。现实中，最终的结果往往不是理想中的那种。但经过这样的讨论和博弈之后，对甲方是非常有好处的，可以让甲方的It人员学会如何梳理流程，如何与业务部门打交道，这在上线后顾问撤出之后，是有很现实的价值的。如果这个阶段甲方的工作做得不扎实，或者乙方的顾问不负责任，会在这个企业的管理中埋下很严重的隐患。
从这个意义上说，在实施ERP之前，进行一次比较专业的管理咨询，还是有现实意义的。
5.4 业务蓝图制作与审核的组织
本阶段的人员基本上就是在项目启动阶段确定的那些核心。有必要提醒注意的是，上面所说的质量体系管理的人员，这阶段应该跟进，最好介入到物料管理、生产计划、质量管理等几个是执行业务中去，让他们在这阶段也学会如何梳理业务流程、制作业务蓝图，同时作为内部的审查人员，及时纠正乙方因为不熟悉企业实际情况而导致的错误，并建立起以后在IT环境下进行质量体系管控工作的新的意识。文档管理员这时会很忙，主要做好版本管理，及时更新文件。
CIO或项目经理在这个阶段的初期就要确定一个专业、高效的“业务蓝图审查委员会”。这个委员会由甲方的CIO、双方项目经理、外聘专家、各部门的业务主管和质量管理体系的代表组成。委员会作为一个召集机构，执行时根据业务需求分成不同的专业小组。主要使命： 1) 把握整个活动过程的主要方向，确保项目的使命得到贯彻执行。
2) 处理业务流程树立过程中的冲突和误解，及时介入一些纠缠性的辩论和争吵。 3) 审核每个业务部门的流程文件，通过研讨不断优化业务蓝图，并最终确认业务蓝图。 4) 对重大的双方意见和冲突，经过充分讨论之后，将执行方案提交高层审核和裁决。
6、ERP系统的学习及数据的准备
ERP的实施，如果最终操作者对系统不熟悉，就会产生畏缩情绪，进而在上线的时候会发生很多问题。那么对系统学习的组织和监控就是非常重要的一环。我在实践中总结了一些很有用的办法，就是对各种类型的最终使用者，规定了学习计划和上系统时间，并在中间进行至少两次的挨个考核，以保证上线的时候操 作者对系统有足够的熟悉程度。
除了上面所说的业务流程和系统学习之外，数据的质量非常重要。业界流传一句话：ERP的实施，是三分系统、七分管理、十二分数据。这句话说得不是很严谨，但是，从程度上可以见识到业内人员对ERP系统中的数据的重要性的认识。
ERP的数据分为主数据和业务数据，两者都很重要。但主数据是基础性数据，其质量和准确性直接会影响业务数据质量和准确性，从数据质量和准确性角度讲，主数据是整个ERP大厦的基石。实际上，ERP里的业务流程运转的时候，主要就是在传递和处理各种数据。数据质量高意味着ERP系统内的数据将发挥所有预期功效，否则就是在产生错误和数据垃圾。因此，任何有经验的CIO或项目经理，对这一阶段的重视那是
这个阶段的团队组合，与上一阶段相同。需要说明的是，如下的工作：
Ÿ 成立ERP系统学习督导小组：这个阶段的任务就是把系统学得熟练。但是，经过初期简单的培训之后，实质性的学习需要在实际系统上运行，需要把数据准备到一定程度才可以运行。这个阶段实际上是与主数据的准备一起进行的。一边学习，一边检查问题。
Ÿ 成立一个数据审查小组：职责就是专门审查各部分业务的主数据和业务数据的类别、格式和准确性，保证数据的质量。并负责制定主数据和业务数据准备计划--这件事一般都是由乙方的项目经理或资深顾问来做的。主数据和业务数据的准备直接关系着上线实施的成败，因此，这个时刻，最好的办法是：甲方的CIO及高层经理、项目经理以及各部门的负责人都分别各守一摊，严控数据质量关。
Ÿ 指定一个小组负责编制“物料编码体系”或者物料编码规则：这个小组由质量体系管理人员和IT部门人员组成，指定专门联系人。物料编码是基础数据中最终要的一个，必须引起高度重视。这件事本来应该早做，但是，经常遇到的情况就是在实施ERP的时候才会想起来。实际上应该在之前的IT规划阶段，就开始进行相关的工作，并编制企业级的编码规则和体系，要涵盖所有的资源，包括物料、厂房基础设施、人员及职位等等。但是，很有意思的是，国内的企业几乎都是在上ERP时才想起来做这件事。实际上，这时再做已经有点晚了。
7、系统上线及准备
系统上线前需要准备好三样东西：
1) 业务蓝图 2) 完备的数据
3) 对ERP系统熟练操作的业务骨干
以上三样很容易理解，这是必须的，不可获取的最起码的三样。但是除此之外，还有几件事要注意：
1) 在准备上线切换之前，必须制定一个非常周密的计划（以后有时间再用实例具体谈），这个计划要由高管层、甲方IT人员和乙方的资深顾问组成，充分考虑到各方面的情况，尤其是数据的准备情况。
2) 制定好计划之后，就正式发出通知，通知所有相关人员，让他们知道这么明确的日期。这对于录入数据的各部门人员来讲，是个很残酷的过程，需要加班加点地工作。 3) 全面检查业务蓝图、数据和业务骨干对系统的使用熟练程度，检查所有部门的准备情况，人力保证，并与各部门的负责人、高管层都进行深刻的沟通，取得他们的真正的理解。。 4) 由于上线的时候，要把原来使用的系统或工具停掉或者停止手工业务，因而必须选择一个具体的时间点作为业务数据的切断层，作为项目组录入数据的参考线，因此，需要跟老板做个特别申请：一定时间的停工；同时准备好可能在上线的时候的停工时间的延长。小企业或者业务数据量不是很大的，有时候可以不停工，利用节假日或双休日的空档来作为系统切换的时间。
5) 这个时刻非常重要，CIO和双方项目经理一刻也不能离开现场。并随时保持与老板的联系，以应对可能出现的特殊情况。准备好连续加班的各种饮食和提神物品，CIO或项目经理要准备一定的预备人力和设备，同时注意安全。
很多CIO或项目经理在谈起上线切换的时候，都是心有余悸的感觉，似乎是鬼门关一样的。实际上，只要严格按照要求把前面的事情做充分了，这个切换的时刻是不会太紧张的。养兵千日，用兵一时。平时多流汗，战时少流血。就是这个道理。本文之所以要不厌其烦地仔细分段说明整个项目的执行过程中甲方该如何组织，就是要说明一个道理：ERP项目只要你严格遵循一些规律，认真准备和执行，就不会有太大的问题。
8、上线之后的工作
ERP系统经过紧张实施后，终于上线，也就是正式启动新的ERP系统了，在很多人看来就是等于成功了，照例会有老板的宴请和同僚的祝贺，还会有很多同行的探访和媒体的访问。很多人感到可以松口气了。其实不然，更多的问题会持续涌现出来，这个时刻还是很危险。
很多同行的专家反映，ERP系统在实施期间，由于工期紧，也由于很多项目都是在一个限定的时段内要完成得任务，导致很多基本问题可能并没有得到仔细处理，如软件系统、数据、流程等细节问题，可能因为急着赶工期，不得已甩掉很多细节问题，等到系统上线后，实际运行起来，这些问题也逐步暴露出来。很多项目的失败就是上线之后没有巩固好，因为一些关键细节问题处置不当，导致最终使用者和业务部门领导失去信心，最后沦为一个空架子。这个阶段如果控制不好的话，有时候会直接让前面的所有工作付之东流。
在现在这个时刻，只要是主流的ERP软件，出严重问题的可能不大，往往是技术顾问对业务不是很通引起的局部配置不当，或者软件不是很成熟，在使用尚不够方便，可配置性不够、扩展性不强等方面，这些都是软件行业常见的问题，随着主流供应商的成熟，渐渐不是问题了，甲方能解决的问题也不多，故此处也不再赘述。 本部分主要还是在上述的背景下，讲述在这个时段，甲方的团队该如何组织和管理。由于此时实际运行的业务流程要与ERP内部已经固化的流程切合，本阶段的使命就是要让ERP系统、关键用户和新的业务流程之间通过不断磨合实现一体，最终实现全部的项目目标。主要工作任务：
1) 做好ERP项目的收尾工作：理性对待业务部门的各种评价和非难；收集、整理项目期间的文件，尽快完成项目结算并结案；安排后续的技术支持和服务等；
2) 加强内部员工的培训和锻炼，应对外部顾问撤出之后的知识“断乳期”，并逐步建立一支具有专业素养的内部顾问团队，作为长期服务的基础力量；
3) 建立系统长期运行所需的规章制度，主要是针对企业内部的数据标准体系以及相应的管理制度；
4) 因应业务需求，优化、细化各部分的管理流程，实现管理的改善。 5) 加强各类数据的管理，增强相关人员的培训，严控数据的质量关；
6) 重新整理并归档实施期间的各类文档，建立系统维护与修改的纪录，尤其是内部的一些客户化开发。
这期间需要注意的问题，主要都是在数据和管理流程方面的问题，主要表现在：
1) 在运行中要不断排查初始数据的缺失和错误，该弥补的赶紧补。
2) 基础数据，尤其是物料编码，在使用和维护过程中，须要严格的措施，任何修改需要指定的部门和专业人员来负责，并做好书面记录。
3) 建立数据管理制度，保证输入系统的数据的质量，避免“输入垃圾，输出更多的垃圾”这种局面。
4) 新的报表功能的开发和扩展：随着企业发展和业务需求，可能需要更多的报表，这需要建立一个原则，来约束这种活动，并做好文档记录。
5) 业务流程的变动：随着应用的深入或者业务的变化，业务流程会有所改变，需要即时调整系统里的流程配置，使系统适应业务流程的变化。这种活动也需要管理制度，并做好文档记录。
6) 与其它应用系统的集成或数据接口：因为ERP系统是企业的一个工作平台，需要逐步整合各种业务数据，接口问题将是信息共享的关键因素，这时可以考虑在ERP系统中建扩展模块。这种系统集成或数据接口，如果有企业的全面IT规划方案，就需要参照这个规划的约束来执行；如果没有，就需要认真地分析并按照IT项目的执行原则来重新界定。这类活动，需要尽快制定规则，并做好文档工作。 这个阶段在时间上不好确定，不同企业的情况差别很大，大致在3到6个月的程度。主要的目的就是保证系统的稳定运行。但是，甲方团队的主要使命已经与上一个阶段有很大的不同，CIO或项目经理需要认真思考，谨慎执行。
9、长期运行和维护
度过“上线后”阶段之后，就是所谓的“长期运转”阶段，这是个大致的划分，主要的原因是，这个阶段的特征和使命与上个阶段有很大的不同。
这个阶段的特征是：
1) 大家对ERP都了解了，各部门能熟练应用并且能针对流程上的某些问题提出意见来。 2) 甲方的IT人员基本稳定，对于日常的小变动和报表的开发也能应对了。 3) 新的业务需求不断被提出来，并且需要认真考虑企业的整体的IT应用问题了。
