ORACLE EBS 系统架构与应用实践6072466354(4)

所谓“决策型用户”，通常是指在EBS系统中从事诸如计划调度（Planner）、绩效分析与管理（BI/EPM）等等之类工作的用户，这类人员不仅要求对相关EBS系统逻辑、功能流程有透彻的了解，熟练掌握EBS系统所提供的各种模拟分析工具的使用，同时对于企业实际业务必须有丰富的经验积累，并且还要有强大的管理推动与跨部门协调能力。这类人员在企业里虽然可能没有高的行政职务，但由于其工作结果与工作质量影响的全局性、重要性，通常在企业里占有举足轻重的地位。国内某高科技企业的计划人员就享有“用金子堆出来的人”的说法（半指其高工资高待遇，半指其工作质量可能导致公司巨额损益）。但这类系统用户毕竟还是涉及企业很少的一些人。

所谓“事务型用户”，主要是指那些只需严格按照EBS系统操作规程在规定的时间里完成规定的系统操作即可的那些用户，他们在企业里占绝大多数，例如采购员（Fulfillment Buyer）、仓管员、发货员、发票会计等等。对于这些事务型用户来说，基本上无需详细掌握EBS系统是如何定义的、业务流程在系统中是如何运转的，大概了解一点就可以了，会上网也就基本能玩得转。ORACLE高度集成的EBS系统就是把企业变成一部高度自动化的机器，大多数人则成了机器的一部分。

所以，对于使用ORACLE EBS这样的高端ERP产品来说，对企业员工的素质要求出现的是“两极分化”现象，综合看来，所谓“国内企业员工普遍的素质问题”根本就不是高端产品的使用障碍。问题通常出在企业对于高端的系统维护与应用实施人才的使用与培养的态度上，出在对有真才实学的高端咨询顾问“知识价值”的真正尊重上。国外发达国家企业管理水平普遍较高是事实，但国外管理

咨询服务市场更为发达也是事实，而管理水平已经很高的大企业在“咨询顾问服务”上常年保持很高的预算投入水平更是普遍现象。反观有些国内企业，往往在买好车、做办公豪华装修等方面可以一掷千金，但在提高管理水平的投入方面却十分吝啬。须知全靠“小米加步枪”就可以打天下的时代已经过去了。

国内业界在谈到高端ERP的企业应用时，还有一种说法认为：高端产品包含有丰富的管理思想，企业应用通常需要进行业务流程重组BPR，伤筋动骨，弄得不好会把企业搞死（即“上ERP是找死”）。这种说法也未免有些危言耸听。

首先，就ORACLE EBS系统而言，其包含的所谓“管理元素”，根本就不是什么象有些人故弄玄虚的“这思想、那模式”的神秘东西，它只是一些最朴素、最简单的基本管理原理与管理原则，例如“决策与执行的职责分离、专业化的分工协作、需求与供应的平衡”等等（有关EBS中的所谓“管理思想”的详细讨论，容以后结合具体的应用模块再来逐个做点评）。这些简单的道理很少有企业不懂或不能接受，系统只是提供了一种较之于“手工”更容易、更简单实现这些基本管理准则的工具而已。

这就好比城市街道中央虽然划了禁止跨越的“双黄线”（类似公司的规章制度），但大部分人开车总是会时不时地图方便压线超车或掉头，即使心知可能会被“电子眼”拍到而遭罚款，但还是难以杜绝。但仅在街道中央立起一道低低的隔离栏（类似企业上了系统），问题马上解决，交通混乱状况立刻得到根本改善。企业上系统首先一定是为了解决已经存在的或者潜在隐患的问题，绝不会只是为了简单地“模仿或复制”当前的手工业务过程，因此，能够解决问题的、有效果的管理改进或改良，一般不会在企业内产生很大阻力。

有人或许会觉得，把ERP中神秘的“管理思想”比喻成街道中央的那一道低低的“隔离栏杆”，这也太简单、太看轻系统了的吧！其实，问题的关键就在于那道隔离栏杆用在什么时候、什么地方，怎么来用（类似于ERP系统的实施水平）。请再看下例：

有一居民小区大门口有一长约几百米的窄窄街道，双向仅两车道，街道两旁有些商店饭馆，于是经常有些人就图方便把车停在路边。如果停的车数量较少倒也影响不大，但车停多了变成靠边一长溜，两车道变成一车道，对小区的车辆进出麻烦就大了。经常出现小区一进一出的两辆车被堵在中间而进退两难的情况，于是抱怨、投诉，立禁止停车的告示牌，甚至把交警请来抄牌、开罚单等等，种种招数使尽，但都还是难以从根本上解决问题。直到有

一天，窄窄的路中央突然冒出高不到一尺、低低的一溜隔离U型弯管（学名：U型护栏、分道栏），如下图所示：

原本就很窄的两车道变成了事实上更窄的双向、单车单行线。虽然对于小区车辆进出来说，没了以前掉头灵活、来去自由的方便，但路边乱停车而导致进出堵塞的现象却忽然从此就彻底没有了，这是为什么呢？相信许多人开车或坐车在比较窄的街道上都见过那种在中间起隔离分道作用的一长溜U型弯管，但有谁想过它居然实际上还蕴含着一种十分高明、堪称完美的“管理思想”呢？（这里卖个关子，且不点破，留给读者思考）。为方便表述，姑且将其名曰管理上的“栏杆效应”，在以后EBS系统各应用模块有关“管理思想”的探讨中，本系列文档可能还会反复引用到它。

其次，ORACLE EBS系统的应用架构设计如前所述，从企业应用角度来看，从内到外、从初级阶段到高级阶段有很强的可伸缩性，可以适应企业不同发展阶段管理进步的需要；即使是具体到EBS每一个模块内部，其实现功能也有“基础应用、增强应用与高级应用”之分。企业信息化与管理水平的提高是一个循序渐进、不断完善的长期过程，那些抱怨实施效果不理想或失败的企业，很多是因为急于求成，把信息化看成是“一锤子买卖”，想“一口吃成个胖子，结果反而被噎住”造成的。例如，有些企业认为EBS有那么多模块，自己应用的还不到总数的5%就很不甘心，还有些人鼓吹“MRP已经落后，要上就上APS”等等。

不过，需要指出的是，由于制造型企业核心的“价值增值与价值实现”业务过程对于系统在“数据集成性与流程集成性”方面有很高要求，那种“先财务，后进销存，再生产制造”的做法也是很不可取的。作为一个完整的基本“企业级”应用，将EBS系统的那十

多个核心模块割裂开来使用， 将严重影响系统整体功能与效益的发挥。这个道理 有点类似管理上的“木桶原理”,木桶能装多少水是由最短的那块板决定的。同 样的道理，那种财务用国产的，生成制造用进口的，进销存等模块又用另外一家 的“拉郎配”式的系统集成实施方案，于核心业务系统的整体实施效果，大多数 情况下也是极不科学、极不可取的做法。最后，引用美国 BOSS 咨询顾问公司关于 ORACLE EBS 核心业务模块实施的

难易程度的经验数据，供大家参考，其中假定总

账 GL 的困难程度为 100,其它 都是相对数：应用模块 1 2 3 4 5 6 7 8 9 10 11 12 13 14 总账 GL 应付帐款 AP 应收帐款 AR 固定资产 FA 采购管理 PO 库存管理 INV 订单管理 OM 物料清单 BOM 工程 ENG 主生产计划 MPS 物料需求计划 MRP 生产能力计划 CAP 在制品 WIP 成本管理 CST 相对困难程度 100 80 90 80 120 100 170 80 50 90 150 30 100 120 MPS/MRP 实际是一个值针对原 OE,OM 当更高

备注

模块

注：1、难易程度相对于不同行业、不同企业以及不同业务背景的人来说有一

定差别。2、 系统实施上线的难易程度与学习掌握的难易程度不尽相同，有些可能

恰好相反。莈薀袄膃 膁蒆羃袃莆莂 薀羅腿芈蕿 肇莅蚇薈袇 膇薃薇罿蒃 葿薆肂芆莅薅 膄肈蚃薅袄 芄蕿蚄羆肇 蒅蚃肈节莁蚂 螈肅芇蚁羀 莀蚆蚀肂膃 薂虿膅荿蒈 虿袄膂莄蚈羇 莇芀螇聿膀 蕿螆蝿莅蒅 螅袁膈蒁螄 肃蒄莇 …… 此处隐藏：4420字，全部文档内容请下载后查看。喜欢就下载吧 ……