当前，国内新实施ERP的企业很多是年销售额一般在1到10亿元左右的中小企业。这些企业大多处于高速成长期，他们在市场与研发上都是非常进取的，也知道如何努力，但是，在整体的内部管理上，往往感觉不顺利，而且还找不到突破口。这时候，他们想到了ERP，再由软件商与实施方的推销，就更是看到了解决这一问题的美好前景，当然不是具体的，而是一个朦胧的概念。
1、内部管理面临的问题
这些中小企业是从小到大发展而来的，多年的运作形成了自己的一套方法。但是随着企业的高速发展，业务数据日益庞大、业务流程越趋复杂、组织效率却低下起来。将这些问题具体罗列出来都是老生常谈的那些：数据不统一、不规范、不准确，业务流程不固定又缺乏执行力，经营分析缺乏数据支持，等等，都是经营、决策之外的基础管理问题。
曾经见过一个企业，辛辛苦苦拿到了一个大单，很不容易的，甚至对一个这样规模的企业来说非常难得。然而，结果却很糟糕：因为成本测算不准，在报价上吃亏了，实际上是亏本生意;生产组织不顺，迟迟不能按期交货，罚款不说，破坏了进一步合作的基础，失去一个优质客户。面对这样的问题，公司如何不急!但是，不管怎么急，问题总是看不到改善，有无从着手的意味。这是一个非常具体的例子，但实际上，这种混乱处处皆是：库存总是不准确，或是给人的感觉要做准确、梳理清楚是不可能任务;如果是产品比较复杂的行业，生产停工待料的情况太多;采购及供应商管理缺少有效的手段等等基础管理问题。
分析这些问题，都是因为业务数据、业务流程及业务控制的问题。业务数据缺乏有效的管理，不能有效的利用(共享)。业务流程不明确、不系统，或是有业务流程但只是纸面上的，没有控制手段，或者说可执行性不强。
2、对ERP的期望
对上述的各类基础管理问题，可以一一罗列并分析原因，但我们在ERP实施过程中发现，多数身陷其中的企业并不能很系统地看到这些问题，他们对ERP的期望是处于一种不具体的理想状态。所谓理想是指，期望ERP是高度智能、高度自动化的，诸如流程控制要自动化、替代人为控制，各种数据无限细化或者说可以提供我想要的所有数据等等。不具体则是指业务部门对问题没有系统化的认识，在谈业务需求时，总是强调他们所遇到的一个个的问题点，没有轻重缓急以及不了解问题之间的内在关系。
任何问题的改进都是一个循序渐进的过程，ERP实施也是一样，对于这种基础管理差的企业，就更是如此。首先要理顺数据、规范及明确业务流程，系统地逐个从根本上解决那些具体的问题，然后才能降低企业运营成本、提高管理效率，进而，为企业的扩展提供一个良好的平台。
但是，我们上面说到，企业对ERP的期望通常是不具体的理想化的，ERP实施项目组与业务部门的沟通效率非常低下，效果往往也十分有限。并且，在项目实施伊始，有时候还存在信任问题，业务部门甚至对于实施方所说的问题有动机上的怀疑，认为项目组总是想把方案向简单的方向引。在这种情况下，项目组有必要考虑实施方法上的调整。
3、ERP实施的应对之道
中小企业的ERP项目规模一般也是相对较小的，但是问题可不少，有时因为基础差，甚至更不好处理。而且，他们本身的经验有限以及有并不实际的期望，项目的沟通也不容易。我们需要在实施方法上就这个状况有所应对。
Oracle ERP实施方法论把ERP的实施过程分为五个阶段：项目准备、需求调研、方案设计、系统集成、上线切换。这种划分是合理的，我们在遵照这个实施方法的基础上，要在实施阶段安排上以及各阶段的具体工作方面有针对性的调整，下面逐项说明。
3.1 项目进程安排
项目进程安排上简单来说就是要压缩项目准备、需求调研、方案设计这几个准备及相对“务虚”的阶段，给系统集成以及上线切换这些“实战”阶段留下足够的时间。
之所以这样安排，是因为沟通效率的低下，而且很难通过延长时间或加大强度来弥补，只有实际的准备以及运作才能让相关各方尽快的进入角色。通过实际的运作，用户能更好的理解做细的重要性，以及做细的代价，并进一步明白细节做好才能做大，系统才能更好地为经营决策服务。在实际的运作中，很多在前期的讨论中久议不决的议题往往能够很快获得解决，大家有了感性的认识和评估。
3.2 项目准备及需求调研
这个阶段，项目组最重要的事情是了解企业的现状，重中之重是问题。我们通常说现状主要侧重在业务的现状，这个当然是项目组要了解的，但是，企业的问题可能更重要，例如管理上的特点，执行力存在的问题等等。项目组了解这些问题才能提前有所应对，不能一开始合作的很愉快，后来发现问题越来越多，这样就浪费了宝贵的项目时间。
在项目准备阶段，重要的工作是筹建甲方的项目组，这里需要注意一点：在对企业初步了解的基础上，双方的项目经理沟通，不要把无关的人拉进项目组，特别是项目管理机构。因为，这不仅是浪费，更对项目后面的沟通没有好处。
需求调研阶段，要尽快完成，并注意充分挖掘用户实质的需求。这需要项目组有足够的行业经验以及实施经验，在对行业了解的基础上，略去过场性的内容，重点了解业务的异常，形成自己的认识并与用户沟通确认。针对用户提出的需求，分析其问题背后的实质需求，并与用户沟通确认。
3.3 方案设计
方案设计阶段也是要快，方法是分层次沟通。我们提出的方案，大部分都是常规性的业务运作，例如进销存的、产销衔接的等等，所以在方案沟通中，这大部分的问题都可以很快确认。对一些焦点问题，可以加强沟通的强度。但是，也有一些问题是非常棘手的，可以分成两种：一种是需求理想化的问题，一种是需求过大的问题，甚至超出了项目范围。
对于需求过于理想化的问题，提出者肯定是基于对自己有利的角度考虑的，但这种情况下，往往会有一个数据受害者，就是别的部门要为他这个需求做出额外的工作才能够实现。这时候，可以让他们坐到一起解决，必要时请上级裁定，肯定可以确定的方案的。麻烦的是后一种，他的需求要客制化处理并且风险大，或是超出了项目范围之外，而且不易说服，因为他可能会怀疑项目的动机是“避重就轻”。这种情况下，通常是用户没有操作实务经验，不明白问题的轻重，可以将这类问题作为方案未解决项或是备忘，约定在上线后解决。通过实际的运作，用户通常都会理解。
在方案设计阶段，我特别强调要缩短物料编码方案的讨论时间，并简化编码方案。大家往往认为编码方案非常重要，并赋以非常多的管理重任，因此，参加编码讨论的部门很多，每个人都有自己的想法。要把这些想法综合起来是非常困难的，所以比业务解决方案还难确认，有时要一个月甚至两个月的时间才能讨论确认。在这里花了时间，就耽误了我们后面要说的数据收集时间了，而这又是对基础不好的企业来说最重要的。
其实，在这里存在误区，编码并没有那么重要，在ERP系统中，编码的管理职能有各种属性及相关设置来担当，编码的作用就是识别，帮助用户在制定编码时快速归类、检索，避免重码。况且，还没有听说因为编码不好导致项目失败的，信息系统也是有生命的，视企业的发展速度，一般是5-10年，要搞好当前的工作，不能背太多的包袱。当然，编码的本质上的特点是一定要照顾到的，例如：编码的可扩展性、分类完整性、唯一性等等。其实，在一些产业面非常广的企业(例如，有化工、机械加工、贸易等多个分厂的)，想把管理意义丰富的编码整合成一套完整的规则几乎是不可能的。
3.4 系统集成
技术的问题我们不谈，这里重点说明数据收集。基础不好的企业，必然是没有完整、规范的数据，而且往往执行力、业务衔接存在问题。因此，数据收集也肯定是困难的，所以要提前收集。一般是在方案确认后才开始收集数据，但对基础不好的企业来说，显然太晚了。要在编码方案一确定就着手收集数据(所以编码方案确定时间要短)，在方案没确认的情况下，物料数据、库存数据起码是可以先做的，这个也是基础的基础。
数据准备越充分，项目上线推进的困难就越小，而数据在基础差的企业中又是非常困难的，所以提前着手、加强跟踪就为项目成功多了一份保障。
3.5 上线推进
上线之初，除了要辅导用户，确保业务按方案的规定运转之外，重点关注各项执行过程的异常。基础差的企业普遍执行力存在问题，很多工作往往不能执行到位。业在系统中集成运行之后，一个问题影响到的就是一条线，如果不能控制这些偏差，对项目来说有时是崩溃性的，问题越积越多，直至无法解决。所以，及时发现问题，并将难处理的问题提交给管理层，给他们以压力，逐步促进业务的改善。
用户在使用了系统之后，常常会有很多想法，提出各种需求。这些需求也需要引导，并与方案阶段遗留的问题一道解决。项目组可以提出一整套业务操作方案，与业务人员一同在实际业务处理中落实下来。
总之，对于在基础不好的企业实施ERP，更多的要靠实际运作的磨合来改善现状、推进ERP的上线使用，而不是花很多时间在需求及方案的讨论上。