什么样的ERP架构思想才是正确的

来源: 畅享博客作者:周传刚
2010/8/20 9:09:22
kaiyun体育官方人口 :国内企业实施ERP的时间较外国晚,对于ERP企业资源整合全面电算化的经验和专业应用普遍较欧美企业晚起步二十年以上。

分享到: 新浪微博 腾讯微博
本文关键字: ERP架构思想 畅享原创

由于国内企业实施ERP/SCM的时间较外国企业晚,对于ERP/SCM企业资源整合全面电算化的经验和专业应用上普遍都较欧美企业晚起步二十年以上.因此,有许多MIS和经营管理咨询公司的专业从业人员都可能会误认为:'欧,美,日国家的ERP/SCM企业资源整合全面电算化的专业技术肯定比国内先进,完美!'.这个想法也许可以被容许,但是却不是绝对正确的看法.罗马帝国发展得比美国还早N千年,如果照前面这个道理推理的话,美国的科技永远都赶不上罗马帝国,这个误解能称得上是个道理吗?先做的人不必然做得更好,慢做的人也未必然做得不好,巧思妙用完全存乎于不同专业人才的脑海构思规划里,谁家天下则是自有安排.

首先说个简单的故事:有一天早上,一辆载满货物的卡车冲进了遂道,由于高度超过了遂道高度,卡车的前半身卡在遂道里,后半身则露在遂道外头,进退不得,卡车司机没有受伤,可是却把整个遂道堵得水泄不通,绵延了数公里的车队.交警找来了各种车辆协助将卡车拉出遂道,来来回回三,四个小时都无功而返,周边围了四,五百人看得膛目结舌,就是拿不出一个法子.突然一个七岁的孩子走到这个地方围观,他开口说:'就把卡车的所有轮胎泄了气,卡车就不会卡住遂道了,不是吗?',结果众人一试,卡车轮胎泄了气,就少了近40公分的高度,果真卡车就顺利拉出来了!如果你说:'我吃的盐巴比你吃的饭还多上千百倍!',这个只有倚老卖老的人才会有这么个无知的说法,所谓:'后生可愄',这个肯定是个平凡的道理.

如果你具备一定的经营管理专业知识,有相当年资的软件规划和开发的实务经验,加上在制造产业实际辅导ERP全面电算化实施的经验,你将能够轻易的发现,目前国内、外很多ERP软件系统规划的架构理念是有严重的错误的,一套良好的ERP系统不仅仅是功能要完整,整合程度要高,运行效率要快,实施过程要短,必须具备QRM快速反应机制,维护作业要简单,移植能力要好,还要实质上能大幅降低营运成本.可是,当你使用过国内、外ERP软件,你会发觉,这些ERP的最终的诉求,他们大部份都无法实现.

举个案例来说:国外软件在系统架构上,将所有关系企业的数据都存放在同一个数据库Database里,光是这个规划方式,就是一个非常严重的错误.我们把几个问题范例给予提列出来:1.多家关系企业的数据都存放在同一个数据库,把没有任何关系的数据存放在一起,系统执行的速度肯定会变得更慢,这已经违反了ERP提高工作效率的原则.从10,000笔资料中查找一笔符合条件的资料,和在100,000笔资料中查找一笔符合条件的数据,你认为不会影响速度吗?将一个公司过期的ERP资料结转到历史文件,和将十个公司过期的ERP数据结转到历史文件,所使用的时间会是一样的吗?一套好的ERP软件系统的使用量是非常惊人的,每个User占用Data server或AP server的时间越长,就表示电脑提供服务的时间就越久,运行的效率就越差.对于只有白天上班的企业来说,其利用下班时间来处理大量的批次过档数据,可能还有相当充裕的时间,可是对于24小时轮班的企业而言,晚上时间还有大量的电脑用户在执行工作,如果要将多家关系企业的大批量过期资料结转到历史档中,这就会严重的干扰到其他User的工作执行.这个和单独将一家企业的过期资料结转到历史档中所需要耗费的时间和速度是非常不一样的.

2.任何一种ERP的资料Table,在每一家关系企业,都有不同的属性或用途,例如:料品主檔,相同的一个料品,在AX01公司属于原材料,在BL01公司属于半成品,在DX03公司属于制成品,在FC02公司则是属于商品,到底由哪家公司的人来负责定义这个属性?为甚么别人公司的数据要由某个人来统一设定呢?另外,属于研发机能的属性该由谁来设定?属于采购机能的属性该由谁来设定?属于生产机能的属性该由谁来设定?属于营业机能的属性该由谁来设定?属于委外加工机能的属性该由谁来设定?属于生管机能的属性该由谁来设定?属于物控机能的属性该由谁来设定?属于财务和成本属性的数据该由谁来设定?本来各公司自行设定,既快速,又简洁,现在把它搞在同一个Database,就变得复杂无比,每建立一个新的产品,就可能有几十项到几百,几千项新的子阶料品,就需要等待这些料品都建立完毕,才能开始顺利运作,这算是有效率的管理模式吗?为了每一个关系企业而设定的不同属性的数据,能够放在同一个Table里定义吗?10个公司的属性和50个公司的属性,如果存放在一起,字段数量肯定不同,因此,肯定必须放在不同的Table里,这就让系统的复杂度变大了,如果有30个关系企业,对于不同的属性数据,就必须开30个Table,在系统的维护工作上,不就变得非常复杂了吗?一个人有一个头,一个身体,两条胳膊,两条腿,五脏六府......,这是何等的灵活而有效率,现在把30个人的头,身体,胳膊,两条腿,五脏六府......等等全部结合在一起,这个架构能够更有效率的运行吗?从30个合倂的人体中让其中一个人运作,速度可能会变快还是变慢?这么一个复杂的人体结构,一旦动起手术来,会比帮一个人东手术快吗?这个道理应该非常的简单.

3.一个料品在两个关系企业中,可以使用不同的料号,既然料号不必然相同,资源也不能共享,将两家公司的料品放在一个Database数据库里,有任何意义吗?把30家公司的料品放在一个Table里,在计算机执行的效益里能达到何种好处?如果要求所有关系企业都必须使用相同的料号,这个本身是不现实的,首先,相同的料品,不同的产地,其成本结构可能有相当大的差异,使用同一个料号是行不通的.其次,当集团公司购并一个新的关系企业,员工有6000人,料品有50,000项,是否要求必须将该企业所有料品都依据集团料号整编后,使用相同料号才能开始运作?到底整编一家6000人的企业需要投入多少时间?在没有完成整编之前,就不能独立运作吗?就不能产生集团财务合并报表吗?如果各关系企业允许使用不同的料号,每个关系企业有20,000种料品,30个企业就有600,000笔料号,把这样无法相互利用的数据堆放在一起,有任何意义吗?能提升系统运行的效率吗?

4.同样是会计总帐,不同的企业可能就有不同的营业型态(Business model),就可以规划不同的会计科目,不同的公司就有不同的簿记账册,产生不同的财务报表.把多家公司的会计总帐资料放在同一个Database中,用公司代码加以区隔,并不能提升任何工作效率,而且,不属于某家公司的会计科目,全部显示出来让会计人员选择,还会出现误用会计科目的可能,如果每个企业使用的会计科目以公司代码将其分隔,避免误用会计科目,则会计科目就无法资源共享.对于无法达到资源共享的数据把它们放在同一个Database,到底有甚么意义?当集团企业在进行集团内部交易调整/冲销分录之时,这些关系企业的会计总帐的传票(凭证)也不能提供任何合并汇总的用途,集团财务是拿各关系企业的电子表格进行合并汇总作业,这种合并调整和冲销分录和会计总帐的会计传票属性和做法完全不同,集团财务合并报表属于合并汇总的观念,而不是像总帐会计的簿记账册的观念,把这两种属性不同管理体系的数据存放在同一个Database中,除了把系统搞得更复杂,能够得到其它任何效益吗?所以,从总帐会计和集团财务合并报表的角度来分析,这种架构规划也是完全错误的规划方式.

5.不同的关系企业可能分布在不同的国家或地区,使用不同的记帐币别,拥有不同的汇率体系,将30家关系企业的数据放在同一个Database,各自设定不同的记帐币别,建立不同的每日汇率,这和将数据存放在不同的Database数据库有何差异?资源无法共享,却造成数据量变得庞大,执行效率降低,系统维护工作也变得更复杂,这对集团企业有产生任何价值吗?

6.不同的关系企业就有不同的采购员,生管员,物控员,仓管员......等等,这些人员的工作都完全独立,并不需要将数据拿来分享,A公司的生管员并不需要知道B公司的任何数据,B公司的生管员也不需要知道C公司的任何数据,C公司的生管员并不需要知道D公司的任何数据......等等,将30家关系企业的数据一起存放在同一个Database,除了导致系统执行速度变得缓慢之外,还能得到甚么其它效益吗?生管,物控,采购,仓管,制造......制造成本......等等的数据都不具备资源共享的价值,有必要将所有关系企业的数据都存放在一个Database吗?

7.当集团公司将一个子公司出售时,如果想要将该公司的ERP数据也一并出售给别的法人公司,如何从合并在同一个数据库Database的所有数据中进行移转?并确保其移植出去的数据库数据没有遗漏.这就要大动干戈,才能确保将该公司保留在原有数据库的数据,完整无误的移植出去?如果每一家关系企业的数据都规划为各自独立数据库,只要把ERP系统软件和Database复制过去就好了,甚么其它工作都没有.清楚,乾净利落.

8.人力资源,固定资产,制造成本......等等管理体系......,从任何角度分析,把所有关系企业的资料存放在同一个数据库,肯定是不合理的规划方式.由于将多家关系企业的资料存放在同一个Database里,如果想要共用数据资源,就要把各个公司无法共用的数据屏蔽掉,这个工作任务就变得非常繁重而复杂,如果没有把各个公司无法共用的数据屏蔽掉,就有可能造成User误选数据,导致后续许多的数据错误.当User数据选用错误之后,再来事后清理的话,这就等于把狗或猫放在公园到处排泻,事后再来清理一样,绝对是一件非常不好玩的苦差事.如果这些存放在同一个Database里的资料使用公司代码给予区隔,不让部同的企业共享数据资源,那又何必将这么庞大的不同公司的数据存放在同一个数据库Database里呢?

从ERP物流,帐流,信息流,资金流的任何一个角度来看,每个关系企业都是一个独立的个体,都有各自的独立帐套,每个关系企业的物流数据不得和其它关系企业混杂在一起,每个关系企业的帐流数据不得和其它关系企业混杂在一起,每个关系企业的资金流数据, 不得和其它关系企业混杂在一起,每个关系企业的信息流数据也不得和其它关系企业混杂在一起,就算最基本的公用基本数据和参数设定都不能混杂在一起.所以,没有任何一家公司的资料可以完整的提供其它关系企业直接延用.既然如此,将集团企业里的每个关系企业的ERP数据合并在同一个数据库Database里的做法,除了导致数据量非常庞大,系统执行效率变得更加缓慢,维护成本变得非常沉重之外,并不能得到任何实质的效益.在进行集团财务合并报表的处理作业时,其数据结构型态和单一法人公司的数据型态完全不相同,也没有必要将Consolidate的数据合并在单一法人公司ERP系统的同一个数据库里头.你认为欧美公司的ERP软件系统这么一个规划设计的构想,有甚么先进性,优越性可言吗?

一套完整的ERP全面电算化整合信息管理系统所包含的范围非常的广泛而博大精深,不论从基础工程的规划设定,系统参数的规划设定,往来客户和厂商的规划设定,仓储管理的规划应用,总帐会计的规划应用,财务资金的规划应用,营销收款循观体系的规划管理,采购付款循环体系的规划管理,生产制造循环体系的规划管理,生产管制体系的规划应用,物料管制体系的规划应用,委外加工体系的规划应用,质量管制体系的规划应用,固定资产体系的规划应用,人力资源管理体系的规划应用,制造成本分析体系的规划应用,税务管理体系的规划应用,关务管理体系的规划应用,短期投资体系的规划应用,融资贷款体系的规划应用,产品研发体系的规划应用,自动立体仓储体系的规划应用,厂务管理体系的规划应用......等等,每一个企业实体都有各自独立运作的相关体系.不同关系企业之间的数据是不可以搞混在一起的,就算是亲兄弟的公司也得明算帐,何况,在现今国际金融体系跨国快速运作的环境下,今天是关系企业的公司,明天就可能不再是关系企业,今天不是关系企业的公司,明天却可能就是关系企业.今天是属于控股公司的,明天就不是属于控股公司.在分分合合的国际金融购併体系下,把随时都有可能改变关系的公司数据存放在同一个Database数据库中,你认为这样的系统集成结构规划方式是个合理的架构规划设计吗?

就算一个集团企业拥有几十家或几百家关系企业,30年内都不会改变其关系企业的持股状态,A公司的采购资料,营业资料,库存资料,生管资料,会计资料,人力资源资料......等等,和B关系企业有甚么关系?和C关系企业有甚么关系?和D关系企业有甚么关系?......等等.和任何企业都没有任何关系,每家关系企业都是独立营运,独立核算的.既然这些资料或凭证都是和关系企业没有任何关系,为甚么有必要存放在同一个数据库里?有这个必要吗?有需要把File layout搞得这么复杂吗?

这不是一种批评,或是一种攻击的言论,纯粹是站在一个Open式的学理和实务的探讨,真理是越辩越明的.ERP最关键的效益就是建立合理化,高效化,标准化,制度化,系统化的营运模式,提高工作效率,减少工作量,降低营运成本,建立企业的神经网络,提升企业的异常反应能力.可是我们不难发现,国外软件产业竟然将所有关系企业的数据存放在同一个Database数据库中,甚至连集团财务合併报表的数据也存放在同一个Database数据库中,你相信这样的规划设计方式能够提高工作效率吗?能够加快电脑的执行效率吗?如果因为这样的规划设计方式导致每笔数据读取需要增加20%的时间,就表示每个人的工作效率是降低20%,因为每个人都必须要多Waiting20%的时间.何况,把几十家公司的资料全部混在一个Database数据库中存放,只会降低20%的运作效率吗?任何一个企业的信息,耽误20%的时间,就可能丧失许多商机,增加许多成本,何况是耽误50%或更多的时间?这是算数问题,并不需要特殊专业的学问才能判断.从这么简单的角度分析,外国软件到底有甚么地方称得上可以提升产业竞争优势的?这就是值得国内专家和学者进行思考的其中一个问题!

作者博客链接:http://blog.vsharing.com/281164760/A1162711.html

责编:穆琳琳
vsharing 微信扫一扫实时了解行业动态
portalart 微信扫一扫分享本文给好友
畅享
首页
返回
顶部
×
畅享IT
    信息化规划
    IT总包
    供应商选型
    IT监理
    开发维护外包
    评估维权
客服电话
400-698-9918
Baidu
map