三论ERP仍然是企业信息化乃至数字化的底盘
1520
2018-08-16 10:22    文章来源:童继龙 童继龙笔记
文章摘要:云ERP的底盘是需要去中心化的SOA架构设计做支撑的;一个强壮的ERP底盘需要在企业CIO的领导下,整合各方IT厂商资源以生态合作视角进行共创共建才能实现的。

第一篇文章是王甲佳发了一篇文章《ERP仍然是企业信息化乃至数字化的底盘》,提出一个核心观点:ERP依然是企业信息化的底盘。

第二篇文章我写了《再论ERP仍然是企业信息化乃至数字化的底盘》,进一步论述了ERP为什么是底盘:ERP是企业信息化的底盘,但ERP在过去基本代表了信息化的全部,定位上来说现在的地位已经有了显著变化;技术与架构上来说意味着底盘有着更高的健壮性要求,简单来说就是需要更耐操;从外部可连接性来看需要有更好的可插拔能力;从创新赋能视角来看,必须能生长出各类创新型新应用。

没想到写完第二篇还是引发了许多新的评论和观点,那就接着有必要再写一写。

首先来看来自于朋友圈的评论:

点评1:在传统的场景流领域找创新和突破,ERP原先是企业内部资源管理,现在出现了各种内外部资源协同应用,从信息化角度看企业组织的边界在逐步模糊和延伸,企业的核心竞争力在转型,这也是为什么很多大型企业愿意花更多的代价自建,当场景成为稀有资源时,纯软企业发展方向是哪里?传统ERP重流程管理,是否会被技术颠覆?这是我们需要做新的思考。

点评2:领导问:我要奔驰的稳,宝马的锐,奥迪的控。CEO:我们坐飞机去。CFO:产融结合,我们投。CIO:我们是法系的板车悬挂。那CIO在面对着不同的领导的不同要求,应该怎么办?

点评3:这是一篇专业点评,题目为“ERP已死,ERP永存”,原文如下:

这两天甲佳兄写的《ERP仍然是企业信息化乃至数字化的底盘》以及后续童继龙的《再论》在朋友圈和微信群里转了不少。屈指算来,我接触ERP正好20年,大大小小用了不少,一直也有一些想法,借此机会,也谈一下。

ERP是企业信息化的底盘。从企业管理的角度,ERP是在系统层面上,第一次将物流,资金流和信息流打通了。作为一个all-in-one的平台,在企业信息化的过程中,ERP的启蒙和对业务流程的提升作用是不容抹杀的。实施ERP,不可或缺的步骤之一是业务流程梳理,也就是评估现有流程与ERP的标准流程或最佳实践,找差距。对于找出的差距,不外两个做法,或者改现有流程,或者在ERP定制开发。在早期阶段,企业普遍管理水平较弱,基本上都以第一种为主,以提升管理水平上一个新台阶。

随着ERP的普及,其神秘光环逐渐褪去。大家对ERP的认识也有所不一样。第一,作为一个大而全的系统,ERP的反应不及时。近年来,新的业务模式层出不穷,但ERP基本还是传统的模块,很难直接支持。通常的做法都是二次开发。为了支持业务,二次开发原来越多,。但是,因为ERP的封闭性,很多企业很难全面了解ERP的底层设计,从而不得不购买ERP厂商的原厂支持。因为产品的生命周期,ERP厂商会要求企业定期升级系统。每次升级都是劳师动众,大家对系统评估,测试,迁移。

现在,随着业务的细化,越来越多的功能都出现了专业的软件,比方仓储有专门的WMS系统,比起ERP的库存模块,功能更强大,流程更专业。在这种情况下,ERP的很多功能对退化为后台功能,一线员工不操作,不了解,数据都是通过第三方系统接口传入ERP系统。ERP系统沦为财务核算工具。在这种情况下,ERP系统的价值是什么?

历史是以不同的方式讲述同样的故事。看看汽车行业,开始福特是独立造车,每一个零件都要自己做,但随着工业分工的不同,出现了专业的零件厂商。福特只要关注整体设计和关键部件生产及最后组装,其他部件有大量配套厂商完成。这个合作就是基于明确的接口。

ERP的发展也到了这样一个阶段。现在的专业分工,出现了一批专注某一领域的解决方案提供商,微服务和企业架构让系统模块化和模块间通讯及时成为可能。现在,我们希望不同的厂商一起,可以制定出一个标准,WMS,MES的数据接口规范是什么?这样,不同的系统可以直接交换数据。只要在这个标准下,用户可以任意使用任何系统。只要保证接口不变,系统内功能也可以任意扩展。

天下大势,合久必分,分久必合。现在是重构ERP的时候了。大而全的ERP系统越来越不能满足业务要求,大而全的ERP系统已死。但是,企业信息一体化的趋势不可逆转,ERP的精神不死。

借用上述三位行家的评论内容,我想在三论中讨论ERP作为底盘如果要实现“重构”的话应该如何实现?ERP作为企业的核心生产系统,整个系统的重构过程中相当于飞机在飞行过程中更换发动机,这个过程中充分着风险和困难。而对于ERP要成为底盘,到底这个底盘应该如何进行定义呢?

ERP如果要作为底盘,我们首先需要考虑的是“架构规划”,要点在于去中心化的SOA架构设计:在过往的许多年里,ERP系统的实现一直都是说基于SOA架构的,SOA架构是目前业界被验证过的,真正赋予企业业务快速响应和创新的IT系统架构,包括现在比较火的微服务架构其实也是SOA架构不断进化与演变的一种而已。但在过往的ERP实践中往往把SOA架构朝着“中心化的SOA”方向而努力的,典型的代表产品就是ESB(企业服务总线),为了使各个系统以服务封装的方式实现了系统间的交互,但我们没有回答SOA精神最重要的价值:设计出基于OPEN API的服务最主要的商业价值在于“业务复用”,只有业务复用才能够支持不同业务领域的快速响应和创新(业务类服务的再组装)。有了以ESB为中心的SOA其实也有一个很明显的瓶颈,那就是ESB本身会成为瓶颈,如果将场景放到金融、物流、电商等海量数量的应用场景来看,就以双11的交易为例吧,根本没有哪一个ESB能够支撑所有的服务的调用,这就势必需要我们从系统架构上进一步思考:未来的方向应该是去中心化的SOA,即每一个“业务服务”都可以独立对外提供服务。

将ERP作为底盘中最重要的事情就是基于业务实体,站在集团资源共享的视角来构建“共享服务体系”,基于共享服务中心的思想来构建IT架构就能够最大程度地避免一个大弊端,“重复功能建设和维护带来的成本浪费”,而这个浪费除了资金与人力投入之外,其实还有就是业务服务兑现的速度太慢延误业务机会,更为严重的后果就是同样是一个“支付服务”,都是“财务接口服务”,因为各个不同的系统都要再写一遍,内部各个系统之间的数据打架情况时有发生,这也是让CIO非常苦恼的一件事情。如果在系统的架构设计时,能够将“共享服务”从原本的业务系统功能中剥离出来,形成一个独立的共享服务,站在集团视角向所有业务单元提供业务服务,那么这个服务就可以不依赖于ESB进行数据交换,自己就可以向外输出服务,基于OPEN API提供数据写入或是数据输出的相应服务即可。

因为共享服务是按照领域的业务成熟度来构建的,因此重构ERP的过程,其实不是一口气推倒重来的做法,而是基于“迭代思想”进行逐步构建的过程,而这个构建的过程最重要的指导思想是”基于共享服务的业务成熟度来构建IT系统架构”,举个国内某SaaS公司创始人给我讲过的例子,他的SaaS产品总共有7500个API,而他又是如何管理这些API的呢?主要是基于“流量”视角来看API,即这个API的数据流入量(流出量)有多大?在所有API的排名是如何的?这些API都是基于业务服务的需要一点点“生长”出来的,而能否持续存活下去就是要看“数据的流入/流出量“。

基于SOA架构的ERP底盘构建过程,是甲方IT团队与各类乙方单位共建共成长的过程,在ERP底盘构建的过程中,不太可能出现整齐划一的”大一统规划“,只要是遵守了SOA架构的规范要求,所有API的注册与下架规范之后,就需要甲乙双方或是多方单位一起寻找场景,构建多方协同工作场景,基于协同工作场景再来构建API,定义能力边界和服务输出标准,这首先是一个业务领域层面的定义与识别,再次才是IT系统构架的规模与构建,最后才是IT系统的开发实现、测试上线。这也就意味着ERP的底盘要真的是足够开放性,就一定是采用”生态伙伴共建“的模式,只有这样才是构建速度最快、吸取行业经验最完整、各自专注最深做透的良性结果。

基于ERP底盘思维来构建的是一个”平台“,而这个平台是由多方生态伙伴共建共荣的过程,只要哪一方(包括甲方单位)想着自己能够大包大揽全部搞定的话,那这个底盘很有可能就无法做成,主要原因在于:ERP底盘的这个平台太过于庞大了,所涉及到的领域太多太复杂,每个IT供应商也只能做其专注的某一部分,甲方单位能够投入资源更会聚集在业务领域洞察、API标准的设定、关键应用场景的识别与校验,但确实很难有精力将所有业务领域的共享服务API都自己做出来,如:HR领域的供应商就擅长将人才测评、人才绩效评估等领域的共性服务做通做透,甲方IT团队则将这两个服务应用于不同的业务板块(如农业、文旅、酒店不同板块)的HR类应用上;进一步来说,如果ERP的厂商需要将业务系统中的关键业绩数据输出给到HR的绩效考核服务,那可能也是一个微服务(OPEN API)调用的方式,这应该是一个价值链上的整体分工协同状态。

有了上述的论证过程,那我们就进一步可以说明,将ERP作为底盘并不代表着就需要自己走ERP系统的自主定制开发模式,就像今天某位CIO说道:”CIO应该从架构的角度来思考企业信息化的构建,底盘也好、核心也罢,都不重要,重要的是要找到适合企业的架构,并在此基础上搭建属于自己的信息平台,这是才是核心竞争力,不可复制。自主开发(只是一个实现手段),并非核心竞争力。“当然,在这个基础上,我还想补充一句:如果想要构建出一个强壮的ERP当底盘,那这个ERP一定是”云ERP“,它一定是在云计算环境下的,因为只有在云计算环境下才有可能快速、简单获取到可靠的海量计算资源;无论是哪家厂商提供的API服务都是基于SOA架构,经的起云计算环境的安全&可用性检验方可上线的服务,多方连接是畅通无阻的(在企业CIO的监管下)。曾经也说过一个例子,作为一个极端重要的API(如查询海量的药品GMP证书信息的API),它可能就需要有一个服务器集群来专门为这个API提供服务,这就是我们称之为”弹性计算“的能力。

以上内容写了这么说,再总结一下无非三个观点:云ERP的底盘是需要去中心化的SOA架构设计做支撑的;一个强壮的ERP底盘需要在企业CIO的领导下,整合各方IT厂商资源以生态合作视角进行共创共建才能实现的;一个可支持弹性计算与持续迭代的ERP底盘一定是基于云计算环境下的,而是否需要自主开发(包括选择哪种开发语言),这些都只是实现手段而不是目标本身。


版权声明:

凡本网内容请注明来源:T媒体(http://www.cniteyes.com)”的所有原创作品,版权均属于易信视界(北京)管理咨询有限公司所有,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,易信视界(北京)管理咨询有限公司将追究其相关法律责任。

评论