中小企业的实施ERP系统之路

  当前,国内新实施ERP的企业很多是年销售额一般在1到10亿元左右的中小企业。这些企业大多处于高速成长期,他们在市场与研发上都是非常进取的,也知道如何努力,但是,在整体的内部管理上,往往感觉不顺利,而且还找不到突破口。这时候,他们想到了ERP,再由软件商与实施方的推销,就更是看到了解决这一问题的美好前景,当然不是具体的,而是一个朦胧的概念。

  1、内部管理面临的问题

  这些中小企业是从小到大发展而来的,多年的运作形成了自己的一套方法。但是随着企业的高速发展,业务数据日益庞大、业务流程越趋复杂、组织效率却低下起来。将这些问题具体罗列出来都是老生常谈的那些:数据不统一、不规范、不准确,业务流程不固定又缺乏执行力,经营分析缺乏数据支持,等等,都是经营、决策之外的基础管理问题。

  曾经见过一个企业,辛辛苦苦拿到了一个大单,很不容易的,甚至对一个这样规模的企业来说非常难得。然而,结果却很糟糕:因为成本测算不准,在报价上吃亏了,实际上是亏本生意;生产组织不顺,迟迟不能按期交货,罚款不说,破坏了进一步合作的基础,失去一个优质客户。面对这样的问题,公司如何不急!但是,不管怎么急,问题总是看不到改善,有无从着手的意味。这是一个非常具体的例子,但实际上,这种混乱处处皆是:库存总是不准确,或是给人的感觉要做准确、梳理清楚是不可能任务;如果是产品比较复杂的行业,生产停工待料的情况太多;采购及供应商管理缺少有效的手段等等基础管理问题。

  分析这些问题,都是因为业务数据、业务流程及业务控制的问题。业务数据缺乏有效的管理,不能有效的利用(共享)。业务流程不明确、不系统,或是有业务流程但只是纸面上的,没有控制手段,或者说可执行性不强。

17

  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的上线使用,而不是花很多时间在需求及方案的讨论上。


cache
Processed in 0.011058 Second.