傅一平:一文讲透ERP的下一代架构!

”5月22日,华为宣布仅用15小时便完成了全球88家子公司MetaERP系统的切换。这也意味着华为MetaERP系统研发取得胜利,成功摆脱外国供应商断供停服威胁,实现该系统的全栈自主可控。“

自己最近对ERP下一代架构有了兴趣,原因有四个:一是自己从事着ERP的相关工作;二是我是陈果公众号的粉丝,对他的ERP相关文章感兴趣;三是我也挺喜欢凯哥的中台文章,他对ERP的未来架构有着自己的看法;四是近来关于华为自研MetaERP的讨论很多。

凯哥、华为、陈果(以下称陈老师)等都对下一代ERP阐述了自己的观点,其中有不少异同,因此写一篇文章来谈一谈我的看法。

1、凯哥的ERP架构“去ERP化”

凯哥早在2020年就写过一篇文章《中台崛起的本质是“去ERP化”》,提到中台的崛起代表了一部分中国领先企业的“去 ERP 化”趋势,认为ERP会从以资源集约化为中心走向以用户价值为中心,从闭源单体架构的商业 ERP 套件走向分布式微服务架构的业务开放平台,并且给出了未来的ERP被中台化的二个阶段:

第一阶段:除了ERP中相对比较独立的财务,人力资源这些模块保留在后台 ERP 系统,其他的业务模块基本上都会从单体架构变成分布式的微服务架构。这个拆解重构的过程,最重要的一个标准就是将原来的 ERP 流程拆解出可独立提供业务价值的微服务,拆解的目的不是为了微服务而微服务,是为了能够对齐和提供客户价值。

f2b24216651cc9141d1165303272e495.png

第二阶段:在第一步的基础上,最终一个个的单体架构的后端系统都会随着云计算、大数据处理技术的发展,变成一个个的可独立运行的微服务。企业的后台系统会被分解成一个个的分布式的微服务架构,能够被管理、被编排、被治理,每一个微服务有自己基于云的数据存储,物理上是分布式的。

da807ae1d4097618d320841c665678b5.png

中台的构建过程是企业转型的过程,是企业从流程为核心走向以客户为核心的转型,是企业从以人的经验驱动走向数据智能驱动的转型。中台概念的崛起和落地代表了中国部分领先企业逐渐走入了企业管理体系的无人区,已经没有以前的西方先进管理经验可以照搬,需要的是快速试错和高速响应的能力。

2、华为的MetaERP架构蓝图

如果说凯哥提的ERP架构升级是企业本身的转型需要,是数字化的需要,那么华为自研ERP多少有点悲壮,在《华为ERP详细情况到底是什么样的?【内部资料】》中它提到了三个原因:

第一、从18和19年开始,美国开始打压华为,从19年开始更加深入,把制造芯片用到的工具软件全部禁用,包括ERP也是在禁止范围之内。迫于这个现状压力,必须要去构建下一代ERP的替代。

第二、现在数字化推进的如火如荼,整个业务的不确定性更加突出。现在业务上对ERP的现状越来越不满意了,随着现在整个业务的发展,ERP响应太慢,不能满足未来要真正实现数字化的诉求。

第三、ERP是一套非常庞大的单体应用,数据量超级大,周边有100多个系统,做一个简单的变更升级,至少得半个月,远远不能满足业务需求,需要架构升级。

华为下一代ERP构想,第一,基于数据构建未来的智能化引擎,即智能大脑,这是非常重要的一层,跟传统的ERP一个非常大的区别。在这一层其他层面比较大的变化。在数据的基础上,上一层就是构建全孵化的产品,把以前单体系统会拆成几十个微系统,以微服务的方式来提供给更上一层不同业务不同流程来组装去使用。

服务化之后,在上一层来讲,面向各个部门按照自己的业务去挑选服务,去拼接组装,组成业务场景需要的一些业务流程和业务能力。组装完之后,面向用户层,实现一站式服务。从底层面优化和升级之后,形成了华为整个一套面向未来的下一代ERP架构。

华为并没有直接给出新一代ERP架构图,但其实在《华为数字化转型之道》一书中已经给出了华为数字化转型的框架,ERP就是其中的一个业务子集,如下图所示:

30b5f16c43e4dded53a0709bb7e817e7.png

(1)客户联接:实现客户交互方式的转变,用数字化手段做厚、做深客户界面,实现与客户做生意更简单、更高效、更安全,提升客户体验满意度,帮助客户解决问题。

(2)一线作战平台:实现作战模式的转变,围绕两大主业务流,以项目为中心,对准一线精兵团队作战,率先实现基于ROADS的体验,达到领先于行业的运营效率。

(3)能力数字化:实现平台能力提供方式的转变,实现关键业务对象的数字化并不断汇聚数据,实现流程数字化和能力服务化,支撑一线作战人员和客户的全联接。

(4)数字化运营:实现“运营模式”的转变,基于统一数据底座,实现数字化运营与决策,简化管理,加大对一线人员的授权。

(5)云化IT平台:云化、服务化的IT基础设施和IT应用,统一公司IT平台,同时构建智能服务。

其中,“数字化运营”就是华为ERP中提到的智能大脑,“能力数字化”就是华为ERP拆分出来的微服务,也就是服务化,“客户联接”、“一线作战平台”就是基于流程编排实现面向用户层的一站式服务,这张图跟凯哥提到的“从闭源单体架构的商业 ERP 套件走向分布式微服务架构的业务开放平台”基本是一致的,只是凯哥的架构图更加抽象,华为的架构图更加具象化了。

3、陈果的下一代ERP架构

陈老师对ERP的未来架构和中台有他的看法,主要观点体现在《企业如何走向下一代ERP(Next Gen ERP)》、《用数字化否定信息化、用中台否定ERP,都是在误导企业》、《中国企业如何走向“下一代ERP”?》、《再谈下一代ERP | 不仅是架构现代化,而是流程管理理念的转变》等文章中:

陈老师主要以SAP ERP来说明下一代ERP的架构,强调ERP目前没有过时,未来也不会过时。它只是在升级换代为“下一代ERP”,尽量减少传统ERP的弊端,下图是发展历程图:

c2ca178578d47f177c860d2909641307.png

其将ERP纳入到企业数字化平台的整体框架进行考虑,认为在目前的发展阶段,ERP是和企业数字化平台并行的后台核心系统,亦即所谓的“稳态系统”或者“记录系统”(system of records),如下图所示,并强调的是ERP本身并不强求一步到位的微服务化、云化。

09aae9fb81d7781a24c6e5b21dc91304.png

陈老师提到,在BCG的企业数字化平台(DDP,也叫数据和数字化平台)架构中,ERP定位于处理企业业务交易的核心系统,有些人把“数字化”和“信息化”对立起来看,那么以ERP为代表的核心系统就属于“信息化”的范畴,而智慧业务层就是“数字化”。

5323144d7aba0d4c106a5691cd29a2c0.png

那么DDP的架构长啥样呢?

在陈老师的《数字化和数据平台——企业数字化转型的技术架构升级》有详细的说明,DDP模型共包含六层,分别是数字化应用层数据与分析层业务核心系统层云基础设施层集成与API层网络安全层

9c646fb47aa8fd30b20879234f182604.png

这里对数字化应用层数据与分析层业务核心系统层三层作简要介绍:

(1)数字化应用层

这一层是面向用户使用的数字化界面,并且支持用户交互提供服务。它的职责首先是实现全渠道接入以及用户的全旅程无缝体验,例如统一身份认证,统一流程编排等;其次是基于微服务框架,提供细粒度的服务组件,例如在电商应用环境下的用户管理、订单管理、商品管理等组件;再者提供数字化通用技术组件, 来支持业务组件运作,例如处理身份的人脸识别、文字转化的语音识别、支持智能交互的自然语言处理、支持智能决策的知识图谱等。

(2)数据与分析层

这一层也称作大数据平台或者数据分析平台,面向业务应用提供数据服务,主要职责有:1)对来自不同渠道(例如数字化营销的私域和公域以及后端核心业务系统等)的各种数据,包括结构化和非结构化数据,做统一接入与整合、存储与处理;2)建立数据治理机制,保证数据应用的质量;3)分析与服务,借助各类分析模型、算法和机器学习能力从数据中提炼洞察,基于这些洞察提供智能服务,例如个性化推荐、精准营销、定价决策、风险预警等。这些服务以API方式被其他应用接入。

(3)业务核心系统层

这一层和上述持续变化、敏捷的数字化应用层相对应。我们将支持企业内较为稳定、不常变化、处理内部管控信息记录及业务流程的信息系统称为“稳态系统”,没有必要或者短期内难以解耦为微服务化,这类系统归属于核心业务系统层,亦即从传统企业信息化时代继承过来的“遗留系统”。

上述两层从概念上接近国内流行说的“业务中台”和“数据中台”,那么本层可以认为是“业务后台 ”,比如大家熟悉的企业级解决方案——ERP系统、HR系统、CRM系统,以及各类业务执行系统(例如生产企业的MES系统、银行证券的核心交易系统、保险行业的保单和理赔系统等)。

下一代ERP在DDP的位置如下:

1a3cad63f0383a7ea275c0e39d88f67c.png

4、三者架构辨析

(1)三套ERP架构分层方式的异同

DDP对于应用的分层,是基于应用是否核心、是否稳定、是否前台来进行分层的。DDP把自认为难以解耦的ERP、CRM等应用单独设置了一个”核心交易层“,剩余的应用全部放到了“数字化应用层”,然后在“数字化应用层”又按照能力是否共性划分了二个子模块,分别是”全渠道应用“”业务服务组件“

华为、凯哥的架构则比较彻底,完全以能力的角度来进行应用层次的划分,针对应用中共性的能力,华为就会把它微服务化,下沉到“能力数字化层”,否则就维持在应用层(“客户联接”+“一线作战平台”)。

因此,DDP的一层其实顶了华为的三层,即DDP的“数字化应用层(”全渠道应用“业务服务组件”=华为的“客户联接+一线作战平台+能力数字化层”,同时DDP还多了一个”核心交易层“。可以看到,DDP的“数字化应用层”其实包罗万象。

DDP的“数据与分析层”和华为的“数字化运营层”则存在着一一对应关系。

(2)三套ERP架构解耦水平的比较

DDP的“数字化应用层”内涵非常丰富,包含“全渠道应用“业务服务组件,即应用和能力放在同一层,耦合性比较高,陈老师说该层对应着业务中台,这个说法值得商榷,因为“全渠道应用“ 明显不属于传统业务中台的范围。

华为的“能力数字化层”则单独成层,跟“客户联接+一线作战平台”这两个应用层完全解耦,这种架构设计灵活性和共享能力会很高。

华为独立的“能力数字化层”意味着其拥有了独立的组织和资源保障,可以有效实现架构目标,DDP则把代表能力的业务服务组件放在“数字化应用层”,一定程度是对能力灵活性、独立性和共享性的妥协,这种架构的能力很容易被应用化,最终形成一个个大烟囱,跨域共享更是不太可能,因为组织架构决定系统架构,这不以人的意志为转移。

(3)DDP架构的两点不合理之处

第一、DDP“核心交易层”存在必要性存疑

DDP的“核心交易层”包括了ERP、CRM等一系列核心系统,DDP认为这些系统目前是无法解耦的,从组织上、系统上、架构上都是如此。但事实上,现在CRM等核心系统在很多企业早已经不是一个大而全的系统了,更多是逻辑上的叫法,其实早已经被拆分成了多个中心而划分到了能力层,而ERP由于拆解的难度比较高其实仍然是铁板一块。

在这种情况下,把未拆分的ERP跟拆分的CRM放在同一层次,就显得逻辑不通,很多企业CRM架构和ERP架构并不在一个时代。

华为、凯哥的数字化架构对DDP架构其实是兼容的,DDP的“核心业务系统”按照能力共性的角度也可以被拆分到应用层和能力层,如果核心系统暂时解耦不了,那就先划到应用层,哪天核心系统某个模块解耦了,就下沉到能力层,这是一个更具鲁棒性的架构设计。

第二、DDP“数据与分析层”的架构表达欠妥

DDP的“数据与分析层”和华为的“数字化运营层”虽然存在着对应关系,但华为的“数字化运营层”纵向跨越了所有的层次,意味着是从所有的层次采集数据,而DDP的“数据与分析层”在应用层之下,核心系统之上,意味着只能从核心交易层汇聚数据,从这个角度看,华为的“数字化运营层”的画法更为科学,凯哥的架构图中数据中台和业务中台是并列的,并且横向互通,与华为要表达的逻辑一致。

5、ERP解耦剖析

ERP系统未来是否需要解耦,什么时候解耦,争议很大,这个需要具体问题具体分析,以下是我的四点看法。

(1)连续性考量

ERP包罗万象,先不说对于制造企业,即使是对于非制造企业,仅用一个总账模块也已经够复杂了。复杂了管理成本就会提升,业务支撑灵活性就会降低。其实很多时候做微服务不是业务的需要,而是拆分后提升稳定性、连续性的需要,动一发而牵全身的系统很多公司受不了。比如我就碰到过导入ERP的数据量过大(其实也不大)导致ERP整个卡死的情况,这对于搞过大数据的我来讲不可接受。

(2)性能的考量

随着企业数字化转型的深入,未来企业对精细化管理的要求会越来越高,ERP与前端业务流程的数据交互越来越多,处理的数据量也会越来越大,这个时候商业ERP软件的封闭性对于性能提升就是个挑战。现在很多业务是没有驱动力去拆分ERP的,但性能不够是硬伤,因此不得不拆,华为拆分ERP的一个驱动力就是提升性能。

(3)国产化考量

华为拆分ERP有被断供的因素,未来越来越多的企业也会面临类似的局面,这对很多大型企业的影响尤为明显,ERP走向国产自主可控是可以看得到的,如果有机会从0到1,大家一定会用云原生的架构对ERP进行拆分重构,甚至是财务模块,也要被拆掉。

(4)灵活性考量

国内SaaS软件生存环境不太好,企业都不太喜欢”循规蹈矩“,也许是市场竞争导致的,也许有文化的因素,大家都需要创新,需要定制化,ERP软件越重要,大家就越希望这个软件能跟着业务走,而不是企业跟着软件的规矩走。

当前阶段,大家对于自由的渴望很大,至少大家都希望拥有基于企业的实际调整商业ERP套装软件“最佳实践”的权利,并没有人否认这些最佳实践,但各行各业的业务复杂度根本不是由1-2个商业ERP软件的最佳实践所能定义的,虽然这些商业ERP软件已经做了很多开放接口,但远远不够,而华为已经证明了两者可以兼顾。

我曾经向ChatGPT验证一个想法,即ERP各个功能模块中,最稳定不易变化的是哪个模块,大家的答案是一致的:只有财务模块,因为会计准则全世界通用,而且极其细节和严格,而其他所有的模块没有这个业务条件,意味着定制化会逐步大于标准化,未来的商业ERP软件的核心系统会逐步塌缩到一个财务模块,而其他全部的接口是完全开放的,彻底的开放,当然这只是我的一个设想。

有观点认为商业ERP软件集成性,一致性好得多,我并不否认,但这跟当年oracle存储过程和dblink被逐步淘汰是一样的道理。为什么这么好用的功能都被淘汰了,因为替代它的技术足够好用,足够廉价且解决了集成性,一致性问题,微服务成为基础设施后,这些都不是事。

同时ERP也要考虑周边的技术生态,ERP最优并不代表对于企业全局最优,别老觉得企业的软件只有ERP,这跟企业数据治理是一样的道理。

当然对于很多中小企业来讲,对于很多传统制造业来讲,现在完全没必要拆分ERP,因为根本没那个数据量和复杂度,更没有业务驱动,这个跟企业是否需要上微服务架构是一样的道理。但这个并不妨碍我们构思下一代的ERP架构应该是怎样的,因为数字化的趋势和要求是看得到的,未来一个有竞争力的数字化企业其IT架构必然是需要解耦的,灵活的,能应对快速市场的变化。

但无论ERP软件是否被拆分,怎么被拆分,都不妨碍ERP的传承,因为ERP更多体现的是一种管理思想,不应被几个大型商业ERP软件所定义或限制。未来的ERP系统架构也许是中台化的,但不是说用中台取代ERP,ERP的管理思想会一直存在并持续进化。

从华为提出MetaERP,我们也能够看出华为的观点:ERP是必须要有的,但可以用新的技术、架构去实现,DDP固然不错,但也需要向更灵活、更开放、更包容的架构演进。

b20bd7360cee879ff9a0eb5f76055457.png

df78dcbc7395a304c92c1f5550cade4c.png

e9e236d9ad3af0575e7a0298ab285894.png

9d3cbc48c7dc46076cd56a7f40101101.png

数字化基本概念| 从“企业信息管理” 到 “数据管理”

国资委:“企业数字化转型”的61个典型案例

腾讯出品:国有企业数字化转型调研报告

企业数字化转型,失败率80% ,大批CTO被裁...

傅一平:业务流程的数字化到底是什么?

企业数字化必需的六个意识和习惯

从中台回到流程 |业务流程数字化仍是企业数字化转型的核心话题

查看全部文章

点击左下角“阅读原文”查看更多精彩文章,公众号推送规则变了,如果您想及时收到推送,麻烦右下角点个在看或者把本号置顶

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
好的,我了解了,下面是对于 Kotlin 协程的使用的简要介绍: Kotlin 协程是一种轻量级的并发编程工具,它利用异步非阻塞的方式来提高应用程序的并发性能。在 Kotlin 中,协程提供了一个简单易用的 API 来实现异步操作,这使得编写异步代码变得更加容易。下面是 Kotlin 协程的使用方法: 1.导入协程库 在 Kotlin 中使用协程需要导入协程库。可以在 build.gradle 文件中添加以下代码: ```kotlin dependencies { implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:version" implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:version" } ``` 其中 version 是协程库的版本号。 2.创建协程 在 Kotlin 中,可以使用 `launch` 函数创建一个协程。以下是一个简单的例子: ```kotlin fun main() { GlobalScope.launch { delay(1000) println("World!") } println("Hello,") Thread.sleep(2000) } ``` 在这个例子中,我们使用 `launch` 函数创建了一个协程,它会在 1 秒后输出 "World!"。在这个协程中,我们使用了 `delay` 函数来模拟一些耗时的操作。在主线程中,我们输出了 "Hello,"。最后,我们使用 `Thread.sleep` 函数等待协程执行完毕。 3.协程作用域 在创建协程时,可以指定协程的作用域。例如,可以使用 `runBlocking` 函数创建一个协程作用域,这个作用域会阻塞当前线程直到所有协程执行完毕。以下是一个例子: ```kotlin fun main() = runBlocking<Unit> { val job = launch { delay(1000) println("World!") } println("Hello,") job.join() } ``` 在这个例子中,我们使用 `runBlocking` 函数创建了一个协程作用域。在这个作用域中,我们创建了一个协程,它会在 1 秒后输出 "World!"。在主线程中,我们输出了 "Hello,"。最后,我们使用 `join` 函数等待协程执行完毕。 4.协程取消 在协程执行过程中,可以通过调用 `cancel` 函数来取消协程。例如,以下是一个例子: ```kotlin fun main() = runBlocking<Unit> { val job = launch { repeat(1000) { i -> println("I'm sleeping $i ...") delay(500) } } delay(1300) println("main: I'm tired of waiting!") job.cancel() job.join() println("main: Now I can quit.") } ``` 在这个例子中,我们创建了一个协程,它会重复执行一些操作。在主线程中,我们等待协程执行了 1.3 秒后,取消了协程。最后,我们等待协程执行完毕并输出一些信息。 这就是 Kotlin 协程的基本使用方法。当然,这只是冰山一角,协程还有很多高级用法,例如协程间通信、异常处理等等。如需了解更多信息,请参考 Kotlin 官方文档。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

傅一平

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值