原标题：从ERP到EBC，企业的数字战斗力引擎
火爆的抖音带货，对于平台来说是典型的创新型系统，这不是传统的业务，没有标准化模型，更新迭代速度非常快，一个短视频作品可能在两三周以后就失去了热度，因此，创新业务对迭代效率、对产品的松散性要求非常高，需要跟着周期快速调整变化。
那么对于企业来说，如何搭建适合自己的系统呢？强调差异化和创新化就需要新的思路去解决这个问题。
对于企业来说，系统围绕着行业业务搭建，往往不是定制化、标准化的产品，同时变化也比较快，要跟着时代与时俱进，对系统的架构要求希望能够更加的柔性。
–EBC时代，打造数字共生体–
为支撑企业的业务快速响应能力和规模化创新能力，Gartner提出了速度分层理念，有效地帮助企业及信息部门将信息系统映射到对应的业务能力。
根据三层来分，传统的ERP系统，如果面对差异层就有点吃力，如果面对创意层，每天一变的新需求，按照传统的单体架构，很难满足业务快速变化的要求。这就需要一个新的系统、一个新的思想、一个新的技术架构去解决，把单体的烟囱式的架构转换成一个平台。
2019年Gartner在全球推出这个名词EBC（Enterprise Business Capacity），是企业业务能力英文的缩写，相比ERP，强调的是capability，也就是企业的业务能力。
01
EBC与ERP到底有何不同？
关于盈利方面，EBC包括：
1、信息化系统
这往往是企业内部与员工互动的传统模式，将企业内部进行管理，与客户或其他消费者的连接称作客户体验平台，这部分负责拓客，与消费者和客户产生关联。
2、生态协会平台
生态协会平台指的是与自身上下游进行联系，例如想出售哪款产品、快递如何配送、如何完成支付操作、渠道商怎样协助分销、供应商如何供货等。
3、物联网平台
对于企业来讲还需要物联网平台，因为软件要和硬件做连接。例如智能设备、机床，通过系统的连接。
那么，将协作平台、生态平台和物联网平台与信息化系统有效地结合在一起，需要大数据智能决策平台。而这5个平台构成一个整体成为企业内部的业务能力，EBC系统相比单体架构的架构范围要大很多。
ERP与EBC的差别是什么？
ERP明显是关注资源、信息化，是业务驱动的，也叫流程驱动，主要用来做内部经营管理。EBC是数字化系统，通过数据驱动，强调的是敏捷性，同时关注的是企业本身的能力，因此这两个系统的差别很大，对于企业来说，从ERP到EBC的过程也是从信息化向数字化转型的必然过程。
EBC提供五大数字战斗力：
1、链接客户的能力
面向客户的体验平台：客户全接触点+在线化的全交易流程，以及售后的服务流程。
2、链接伙伴的能力
面向伙伴的生态平台：企业上下游、第三方服务、政府公共事业等在线系统平台，数据跨企业共享，商品与服务跨企业在线交易。
3、链接员工的能力
面向员工的信息系统平台：内部人、财、物、协同的管理与运营系统。
4、链接万物的能力
面向物的物联网平台：人与设备、人与商品建立连接，不只是数据的穿透，更多的是可以互动操作。
5、数据驱动的能力
智能数据分析平台：构建基于统一的数据中台服务，利用AI+数据能力，为其他四个平台提供智能数据的分析与洞察。
因此，当EBC系统构建后，让企业具备5大数字战斗力，而相比此前基于内部管理的系统来比较，毫无疑问企业面对社会竞争和商业的变化和不确定性的应变能力都增强了。如果打造企业的业务能力或五大数字战斗力，需要搭建平台。
EBC不一定是标准化的系统，需要很多定制化的功能，想要打造基于企业本身与行业结合的客户体验平台、伙伴生态，就需要与企业内部的管理和战略是相关，打造一款适合的平台去去重构企业的数据战斗力，而企业核心竞争力一定与平台能力相关。
02
企业能力平台
此前做软件系统，例如财务、协同、人力资源管理都习惯竖向画架构图，但是在云架构下往往是横向着画顶层的SaaS，高等级是围绕着场景去拓展的。
而中间将有PaaS高生产力的平台帮助去构建SaaS战斗力，底端还有IaaS层，目前基础设施无论是公有云混合云还是私有云，云建构出来全新的EBC平台一定是按照这种三层方式去构建的，而要打造好 的SaaS产品需要PaaS。
而新平台的特性最重要的两点：
1、云原生
这是一个技术架构的要求；第二点是需要中台架构，只有达到这两点才能形成又稳又快又好用的平台，系统的运行就像人跑步，按照传统的架构很难做到又稳又快。
可以用两种方式解决整体的使用感，第一个是云原生技术。什么是云原生技术？实际上是一组技术，包含容器、微服务、分布式架构、弹性的伸缩计算、低代码的开发平台，OpenAPI、DevOps等。通过一组技术可以实现敏捷柔性、高可用、弹性拓展、多租户等一系列特性。
其实，很多消费互联网公司已经用了很多年云原生技术，这类公司最擅长解决的问题就是面对海量的终端用户快速迭代、变化。例如，淘宝的页面每天都在变化，微信每天都在推送新的内容，而版本升级是非常快，这就是在消费互联网上的运营商架构，如果将它成为企业级运营商架构，既可以保障企业的稳定性，也能够去实现敏捷性，实现企业级的云上架构，这也解决了又稳又快的问题。
2、中台
无论是平台的应用还是保持一定稳定性去快速迭代，实际上都需要关键字–复用。很多公司在谈中台，而这部分主要分为三类：
1、利用技术动态帮助企业具备一定的技术实力；
2、利用数据动态帮助企业实现数据闭环的管理；
3、利用业务中台能够为企业快速构建水平产品。
而这三个中台结合在一起就是中台共享化的服务中心，也是中台架构下PaaS平台的重要的价值。实际上它并不是模型也不是技术，实际上是一种思想，既可以用到架构上，也可以用到组织上。
例如美方军队，在进行战争的时候，陆军进入到一个地区，可以通过渗透能力快速发现对方的要害，然后呼叫中台进行炮火支援。
如果利用导弹要将哪个目标消灭，其后台是一个稳定的供应链为中台提供弹药，为中台保证了运行效率，因此，这种模式也是前中后台的思想，企业不要被中台思想困住，不同的层次、领域、行业都有自己的中台思想，要选择适合自己的方式去构建属于自己的中台。
因此，当企业的中台架构逐步沉淀积累，形成一种思想和方式，是企业在整个数字化战斗力过程中的必备过程。
–三大中台分析–
01
技术中台
技术中台实际上包含了两部分，第一部分是连接IaaS层，就是基础设施层，能够提供控制力，可以管理资源。第二层是去帮助前台应用服务，帮助快速定制化开发，提供流程、集中服务和社交服务，同时具备区块链、AI的特性，帮助企业提高生产力。
而这需要SaaS和PaaS联系起来共同关注，企业内部需要高控制力PaaS，要管理资源，就需要高生产力PaaS帮助企业管理应用，构建场景。
企业数字化平台从技术视角看，硬件与应用系统解耦将形成基础架构云(IaaS)，业务与支撑软件环境解耦将形成平台软件云(PaaS)。
技术中台的建设包括两个方面:
1、高控制力PaaS：基于云原生架构和分布式架构，提供基础技术能力，向下链接和聚合IT云基础设施能力，向上支撑应用和数据的构建和运行的能力。
2、高生产力PaaS：以元数据驱动为核心，构建业务和数据中台所需要的服务，通过基础服务能力，将各个业务应用系统中的基础运行组件和服务进行聚合。
传统ERP是单一的数据库，没有云架构，其上层是一个中间件或者中间层，再往上就是应用，当运行之后往往会成为许多烟囱，数据库容易形成瓶颈，应用服务层也没有办法弹性扩容。例如，某家生产月饼的企业，想要扩容非常麻烦，首先要对企业进行改造，包括对人员、硬件资源，其弹性很差，因此在传统 ERP时代，单体架构往往比较笨拙，相对耦合。
那么，企业级云原生技术的特点是什么？
在底层的数据库上做了分库表，将按照应用模式把数据库做了分拆，在上层的应用层，根据应用模式做了微服务的拆分和治理，同时可以根据使用模式放到不同的容器中，而每个容器都是独立的应用空间，如何保证事务和数据的一致性，通过统一的微服务框架、数据中心建保障事物一致，也保证了数据一致。通过这种结构可以让系统的性能、可靠性得到极大的提升，同时可以敏捷快速地迭代，最重要的一点它可以弹性扩容，可以按需更新，更好地运维，进而保障企业业务跟随市场的变化逐步变化。
云架构实际上已经成为了现在很多企业在选择IT设施的基本门槛，而服务化、容器化、云化这个词大家经常听到，微服务的治理和开发是从单体架构中升级而来，此前是单独的数据库并用一套软件磨合在一起，如今按照微服务做了多个应用的拆分，优势就是互相影响很小，无关联性内容的服务费独立部署，小团队也可以独立开发，同时也可以做轻量级的迭代，比如说在A中融资，在B中更新，在C中运行。从单体加入到微幅的架构之后，让很多的企业服务运行的快速、敏捷，这也是微服务化对单体服务的变化和优势。
企业级研究架构化微服务化与消费互联网不同，消费互联网要求开发与部署是一致的，由于本身企业内部软件与业务是吻合的，例如财务的凭证提交就一定会有借方和贷方，这两者不能拆分，而记账与支付一定吻合，在处理过程中有先后顺序，因此也是根据该需求部署，按照云或应用动态去组合，而不是按照开发顺序，同时在拆分时，不代表越细微越零散越好。
例如QQ、微信和淘宝的微服务化非常细致，这些软件的业务关联性不强，聊天、购买绿钻同时进行王者荣耀的游戏，这些应用本身没有先后顺序，也没有强制关联，相对比较松散。而在企业内部是有逻辑顺序，A在做账的同时B在跟进，同时C的数据跟B进行对比，根据对比逻辑关系到D，因此这是非常偶合的，因此企业经营架构跟普通的消费互联网的原型架构区别很大。
低代码与AI机器人能帮企业降本增效。
低代码这个词非常火，市面上的幼儿编程语言已经模型化，通过拖拉拽就能实现，然而关于产品，一方面需要具备市面上低代码开发平台的特性，另一方面需要具备动态铝模型，金蝶在这个行业中做了27年，因此将其抽象成各种各样的模型，能够在开发中去直接调用，不需要重新构建，通过模型、原数据去描述新的客观事物，让开发者在拖拉同时也能够实现很多业务领域的开发。
这里边包含了整个应用的管理，例如控件表单的构建、模板的定制、符合互联网化的模型等，也包含移动表单的开发，概选的特性的字段、参数的配置，以及工作流的配置等服务，这些都需要按照新的模式去实现，才能构建出云的电代码的开发平台。如果需要为产业开发编辑脚本，也可以通过代码去开发，这个开发模式与传统开发模式的差别不大。
低代码与很多企业息息相关的，这不仅是拖拉拽的模型，同时还要根据业务对象的模型进行抽象和复用，通过模型驱动开发、行业积累，通原数据的描述去做资产沉淀，不依赖背诵语言和编程框架。
其实，企业内部不具备非常专业的开发人员，也不需要去做专业的底层开发，而更需要的是快速实现场景化的应用，因此可以利用相对复杂的架构，高效拼出一些模型，非常适合企业的业务设计人员。将复杂的内容留给架构，让业务简单化。
而AI机器人可以拥有电代码的图纸界面，能够让企业内部开发自己的机器人，能够通过界面配置，将机器人的语义和逻辑配置出来与人对话。
企业内部面临很多场景，这些场景如果通过高代码的方式成本很高，同时在使用的过程不消耗人力，而例如从出差到报销流程到报销费用的流程，从出差到审批，出勤方案的选择、报销过程、财务的审核到记账、递交发票等这个过程是比较漫长的，如果通过传统的方式开发往往成本会很高，但是我机器人技术实际上可以把很多事情做成自动化覆盖这种端到端的流程，而所谓的智能财务就是这样的。
而开放能力是非常重要的，如果这部分做的一般，那么开发能力、动态领域模型、AI技术等都没有办法与第三方集成，没有很好的发布企业也很难把它用起来。因此，一个好的平台需要全站式开放，能够让所有的产品和业务系统能够应用起来，让使用者理解、应用。同时安全也非常重要，保障系统是安全要基于企业自主可控的技术去构建系统。
02
数据中台
这是数据整个的闭环寻闭环的数据管理而存在的，一个好的数据平台能够帮助企业将数据管好，数据资产用于建设中，而整个应用规范是一体化的。
在整个数据中台中最核心的三点：
1、业务数据化，如何将业务通过数据描述出来，让所有业务成为数据的展现者；
2、数据资产化，业务数据化之后如何把这些数据变成资产，可以被管理、治理，并拥有资产的标准化体系；
3、资产价值化，有了数据资产如何利用好，形成更智能的决策进而提升企业竞争力。
资产价值化之后又会反哺企业业务，因此整个企业的数据变成一个价值的闭环，能够生生不息地发展帮助企业提高能力，因此数据中台的核心就是把数据形成一个数据价值闭环。
此前企业内部关于数据的展现、商业的智能决策一般是依赖于报表工具和编译工具，尽管功能强大但是比较难用，门槛比较高，往往需要一些非常专业的人员去做建模，而企业内许多场景做的是轻量级的分析，例如做一些嵌入式分析。
关于决策评分，例如一张报告单据的核心信息的检测，就可以利用算法判断该报告的各个事项是否存在敏感字，最后通过大数据分析平台打分，可以帮我们实现更智能化的管理，假设审核下来表单的分数是95分就可以直接通过，如果是55分没有到及格线，那么就需要人工审核，通过这种方式可以将业务更加清晰，也可以授权给业务部门，产生企业内部的信用机制。
当下许多企业都应用类似的案例，例如万科集团的财务自动化已经自动化实现50%的单据不需要审核，10%通过信用，40%通过检查项。而在收付资金的管理上有99%是智能收付，为了保证使用，大概有8000个业务规则。
关于零售行业，例如一家销售短期面包的企业，发现用户粘性差、流失率很高，配速效率也不高，线上线下了业务沉淀的数据没有打通。而该企业搭建零售数据中台后，能够将小程序商城里的卖点提炼，形成数据资源体系，进而构建数据驱动的个性化弊端配置，例如阴雨天对面包的售卖是否有影响，周五对面包销售有什么要求，怎样配速才能做到人货场集中等。通过这些工作，该企业的购买频次提高了两倍，退货率从12%下降到3%，这也实现了从流程和业务驱动转化为，价值从数据上驱动。
03
业务中台
相比技术平台和数据中台，业务中台实际上是相对模糊的，每个企业都有自己的业务，每个行业中的业务如何构建属于自己的业务中台，实际上在业内讲是众说纷纭的。
企业构建业务中台的话，有三大结构因素：
1、业务架构
首先要思考，企业的商业模式、管控模式、业务模式和业务流程是什么？只有将自己的业务业务架构想清楚后，才知道哪些点是通用的，可以在业务状态中复用。
2、应用架构
那么，如何协作企业的组织、架构，如何控制权限呢？这是整个企业内部的基础数据、基础模型技术的一些引擎，一般是可以通用的。
3、技术架构
该用什么样的微服务如何拆分、治理、部署呢？如何构建底层模型，如何去运维，往往也具备一定的通用性；而在构建业务状态时，如何构建底层模型，如何去运维，往往也是具备一定的通用性。
因此，当构建一个业务状态时，往往要考虑这三大架构因素来决定哪些内容可以复用，哪些部分要构建业务中台，哪些部分可以直接开发不需要中台。
业务中台大概要分：
1、基础能力层
这部分可以跨越所有领域的公共服务能力，包括数据、服务等，并形成一个为所有的领域和系统服务的公共能力。
2、领域能力
这部分往往按照领域区分，例如财务、供应链、人力资源等，它们在企业内部具备一定的共性。其实也分为三个种类，第一是引擎类不包含数据的一些规则，第二部分是基础类，包含数据等基础资料，第三部分是业务类，往往跟业务相关的一些共享服务。
3、业务类
基于跨所有领域的公共服务能力和按业务能力，按业务划分的能力层构建业务共享中心，能够去为不同的业务领域提供共享的服务。
当有了这三点后，企业才会快速的搭建一个前台化的场景应用，实现不同业态不同行业的敏捷的产业化应用的构建。
例如采购订单、采购收货入库检验后的财务记账是比较漫长的过程，每一项都有很多关键的事项，需要通过数据、表、单的流程，再加上后台的开发逻辑去实现构建，因此对开发人员要求是比较高，开发过程也比较漫长。如今有一个好的业务增开后，就不需要做这些事情，可以从能力中心选择，例如采购订单，选择合同、采购、库存和预算等的能力，就构建了一张采购订单。
同理包括采购、收货、入库、检测、应付进项发票等，都会以这种能力方式拼凑，将断路流程展现出来，如同搭积木一样，优势是第一速度飞快，第二应用灵活，第三相对稳定，而业务中台也是通过这种群体思想，帮助企业提升了敏捷性和稳定性。
例如会计引擎是比较典型的业务终端能力，在企业内部往往开始生成单据的是业务单据，因为在财务记账时需要知道这张业务单据发生的财务背景。而一方面业务人员不懂财务资产是什么，而使用成本比较高，另一方面有一些字段导致业务不够敏捷，因此希望能够通过复用将会计的一些规则抽象出来，让一张业务单据干干净净，只有业务的数据和语义，通过快递引擎的加工变成一张业务凭证，具备一些财务特性，最后生成一张真正的财务的单据。
而这个方式对业务的要求比较低，同时也可以让数据反哺前台，让前台更智慧，形成一个敏捷的闭环。
业务单据的会计引擎最大的价值是可以实现事项会计法向价值会计法的转型。实验会计法是找人，有很多的局限性，而价值会计法实际需要做很多新发的延迟，并缺乏一些决策的依据，而实现市场会计法就是利用会计引擎帮助提高良好的思路，并通过整个的业务财务结合去实现这部分的价值，展现会计引擎可以更好地执行市场会计法。
另一个案例是多维库存的更新服务，在企业内部的商品实际上是有很多特性，有些商品的特性相对比较标准化，例如仓库库位批次物料的名称，而根据产品不同一定会有很多特性，例如钢材可以有质量标号，而大型的集装箱可能会有长宽高属性，这些属性往往通过行业客户的扩展去实现属性的扩展。
那么如何形成联动呢？实际上是通过引擎的多微课程更新服务实现，通过沉淀库存的更新模型将这部分能力开发，让产品通过配置为整个余额做更新，这样不需要在每张的扩展单据上做开发，也不需要做每一次的余额更新动作，而整个库存管理可以实现得更敏捷，让产品的可配性变得更强，这也是比较典型通过业务中台提高管理效率的案例。
企业的业务规则其实都可以通过这种方式去实现，只要增加复用性的都可以抽象出来变成规则，同时让产品和业务变得更加密集。
除了财务供应链等中台，还有很多其他中台，例如办公层面上可以通过流程把审批新闻知识筛选出来变成协同业务中台。而业务中台并没有固定的模式，是根据企业内部的需求自己研发的，也需要企业根据目前的理论和模型去探索。
–经典案例分享–
EBC与ERP不是完全的替代的关系，可以在短期内进行组合，例如2019年提出了速度分层的理论，实际上将企业内部的很多稳态业务认为通过ERP可以解决，但对于一些稳定业务，可能ERP产品就不适合，需要通过一些云的方式去解决。而在企业内部既有稳态业务又有稳定业务，根据不同的业务来判断它属于不同的层次，需要采用不同的计算方法，而这实际上是双模的组合。
例如有些大型企业在全球部署业务，构建全球化的应用，这类企业需要管理的员工也非常多，他一定会面对不同的地区、不同语言、不同法律法规、不同的管理方式等问题，而不同的业务模型怎么去通过管理方式去实现，其中最重要的就是要将业务中台使用起来。
合同台账在不同的地区是不一样的，有些地区是标准化的，有些地方可能要通过合同清单去导出，而有些地方要通过项目预算的导入，同时还包含了资金计划、发票管理、索赔、签证履约失误等。而不同地区的需求也不同，想要解决这类问题最好的方式不是开发一套非常庞大的系统，也不是做多套小系统，而是通过中台的能力把核心流程标准化，同时将一些暗虚实的流程通过参数配置化，通过财务中台按需使用快速构建。
当公司在进行一个项目的时候建立子公司，那么完成项目就要解散吗？很显然，公司可以解散但是业务不能解散，不管是核算还是流程单据审批都需要继续下去，工作流需要贯穿行政组织，也需要拉通核算实体和项目实体，打破组织的边界。而大部分系统都需要支持社交化和移动化，因此也需要支持多语言，这也考验平台国际化的能力，在众多语言的情况下，能够构建系统，既达到管控要求又能让业务快速变化。
关于国内农业相关的民营企业，农业行业本身相对比较传统，而很多的农企都在做产业互联网的转型，也在利用平台去构建采购和渠道的商城。
而目前供应的系统包含了比较敏捷的前台，也包含了分销管理、财务业务管理和农户管理的业务中台，而根据底层的技术中台就是语言上的PaaS平台，包括云化的基础设施。
想要打造成现代农业产业互联网平台许多内容不能标准化，也没办法标准化，一个好的技术平台对企业的帮助非常大，可以实现大数据的管理，让整个产业互联网快速开发，也能够实现一些黑科技。
有些企业做到了移动化，例如鸡舍安装了温度监控，可以快速监控鸡的状态，能够与物联网设备做一些交互。
责任编辑：