一般来说，企业上马ERP系统后，都会相应提高关键用户、基层操作用户的薪筹待遇，但只是从薪筹待遇入手是远远不够的，人力资源方面的一个权威调查显示，真正因为薪筹流失的员工仅占所有流失量的30%，所以怎样培养关键用户、怎样留住他们也成了ERP系统管理的一个重要内容之一。除基本的人力资源手段外，笔者建议:

● 提供不间断的系统知识培训。如读书、ERP系统提供商的培训、顾问公司讲座、参与相关高峰论坛。

● 组织对其他模块知识的学习和操作。学习其他模块，了解自己工作节点上下游的操作方法及信息查询，可以帮助员工了解流程设计原理，清晰流程边界部门配合工作的重要性，同时也提升了他们的知识储备。

● 轮岗学习，帮助他们找到对工作的新鲜感，同时培养业务流的意识，使他们成长为BPR(业务流程重组)的中坚力量。

● 鼓励对系统功能提升的使用发现。通过各类手段，对能够挖掘出系统新功能的员工进行奖励，调动关键用户的积极性。

● 除此之外，也要在日常有意识地从基层用户中选拔苗子，加入到关键用户培养的队伍中去，不断地增强后备力量，补充新鲜血液。

5 ERP系统与实际业务结合部的知识管理

如果说战略规划是大脑、企业文化是心脏、业务流程是脉络、ERP系统是骨骼，那么知识管理则是血液，它流转于整个身体，支持着大脑思维、帮助心脏跳动、联系脉络的接点、协助骨骼运动。对ERP系统来讲，失去了知识管理就等于人体失去了血液，也便失去了生命力。

对于ERP系统的知识管理，最核心的部分就是与实际业务结合部的知识积累与管理利用。

业务情况千差万别，问题五花八门，这就需要关键用户们不断地探讨解决方案。大家都知道有了ERP，各部门就都成了一根绳上的蚂蚱，谁也离不开谁了，其好处自不必多谈，信息统一、集成。但问题就在于，一旦一个环节出现问题，就要求各个相关部门都有动作才可以纠正错误，或者说是解决问题。企业的ERP管理部门需要不间断地收集汇总问题，确立解决方法后，还要不间断地记录和总结下来，形成ERP系统的FAQ，放在指定地点统一使用。这样日积月累，当一个问题重复出现的时候，各模块操作人员就可以直接调出FAQ按部就班地进行处理，不必再一次沟通、再一次协调、再一次确认。在实际工作中，FAQ着实节省了很多的时间，提高了处理问题的效率和业务响应速度。

同时在实际操作中我们发现，由于ERP系统的基础数据源丰富，所以在报表取数上就对各模块的规范操作非常苛刻，没有整体的知识管理，各模块面对非常规操作乱下手术刀，其结果是非常可怕的，最严重的可能直接造成成本问题及佣金计算问题，使得各部门对系统的可信度下降，其损害程度大不一般。

所以在实际管理中，应当要求各模块对于非培训手册规定内的操作及时向管理部门反映，得到确认后方可继续操作，随后补充操作方法入FAQ，形成操作规范体系。

6 业务部门应与技术支持部门紧密配合

笔者认为，如果没有ERP，信息技术部门永远不可能真正成为企业运营的一份子，而总是以一个协助者的形象出现，而且多数时候，很少有销售或者是管理部门会主动地与他们沟通，那么理解公司的运营流程简直就是不太可能的事情。ERP是一根红线，它也是使业务与IT结合的红娘，ERP系统的充分开发和利用使得销售、人、财、物充分意识到了IT技术的力量，这是任何沟通都不能替代的真实感受。配置修改、报表开发，技术部门也在不断的需求满足过程中，锻炼了自己的队伍，逐渐熟悉了企业业务流程和各部门开发需求书背后真正的需求目的。作为实际工作的参与者，当看到一次次开发的成果极大地解放了生产力，提高了数据的质量，当年小学课本中的那句培根的名言总是在笔者心中油然而生: “知识就是力量！”

7 加强系统开发及测试工作的专业化和规范化

信息系统的开发过程要制度化，目的是为了最大限度地提高系统开发的工作效率，尽量减少和避免错误的发生。

简单归纳分为以下几个阶段:

1.需求分析及确认(开发人员和相关业务人员进行沟通，形成需求分析文档)。

系统开发的第一阶段尤为重要，它就相当于河的源头，如果被污染了，河的下游也不会好的。不但浪费开发资源，而且对实际业务也只能是弊大于利。

完成了需求分析书后，要求业务部门进行书面再次确认与签字。这样做不但是对需求调研的一个阶段性确认，也是需求提出部门再思考的一个过程，切实保证源头的纯净，并在开发过程中做到有章可循、有法可依。

2.系统设计(可细分为概要和详细设计，形成技术文档)。

人们常说：“管理出效益”，ERP系统也不例外！它是一个智商很高、能力很强的“好员工”，但是教它如何适应市场环境、适应团队整体步调、根据不断提高的管理需求调整自己的出击方向，就必须依靠管理。“只有不断打磨的利器，才有可能路上商战的变化，适应商战的需求”。

3.系统开发(主要是编码和局部测试)。

4.系统测试(由业务人员进行全面的详细测试，形成系统测试文档)。

测试文档的核心部分就是业务情景，没有多元化的业务情景就非常容易在实际上传生产系统后出现问题和漏洞。所以测试文档必须是涉及各模块联写，务必做到详细、周全，尽量通过业务经验把可能出现的情况一一道来，一一测过。笔者在实际系统管理中，就经历过由于测试没有“尽善尽美”而导致后续的数据垃圾清理起来颇感头痛的问题。

5.系统验收(由ERP核心管理部门成员、相关业务人员和开发人员参加，形成系统验收报告文档)。

6.后期维护(可能有一些小的修改，但不应有架构性的改动)。

在中小企业的实际管理过程中，如果没有充足的人力资源支持，至少在第一阶段和第五阶段，ERP核心管理人员、相关业务部门人员和开发人员一定要进行阶段评审，确保业务需求的正确性、合理性、可行性和实用性，保证系统的开发和公司的管理需求及业务流程的改进、优化思路相一致。