你没踩过的坑我都踩过，数字化转型不走弯路

企业IT建设的核心诉求是什么？

当下，中台是一个从2016年到现在都一直很火的词，之所以从提出到现在持续这么久而热度不减，究其原因其实是企业在当下数字化经济时代的核心诉求发生了变化。在信息化时代，企业主核心焦虑更多在意内部、流程的管理，以及自身效率的提升问题；但今天企业主的核心诉求聚焦在外部、商业、数据以及运营。在这个核心发生的变化的时候，对于企业来说，他们其实更关注的是自身敏捷响应业务需求的能力。相信在信息化时代，大家都听过一句话“上ERP找死，不上ERP等死”，其实就是反映企业内部效率管理问题。而在数字化经济时代的今天，企业核心问题在于解决：当外部商业不断快速的发生了变化时，业务部门随之对业务创新提出了高需求，而这时候企业到底有没有这样能力去支撑和实现这些诉求，这背后的所需要的正是敏捷响应业务的能力。

从技术演进看中台架构

阿里的中台并不是老马一句话就设计出来的，它一共经历了四个阶段，三次演进。最早在2008年的时候，阿里自身IT还是烟囱式的架构，当时淘系一共300名工程师，经常会碰到即便加人效率也提升不上去的情况，第一个问题就是我们每改任何的一个功能都要做全量回归；第二个则是性能问题，哪怕我们可以部署很多实例，但是数据容量不够了，本质上是性能拓展和开发上线效率的难题。因此针对这种情况我们通过做了“千岛湖”和“五彩石”两个项目将阿里IT从烟囱式到服务化的转变，即所有服务模块拆分开来，解决了架构性能问题，不再有单点故障，它沉淀的是什么呢？是互联网的一些中间件和研发框架。

各个BU还是各自都做了自己的一套系统，这时候我们发现其实有很多重复的没必要的建设，产生了很大一部分的能力浪费。对于消费者来说，他们所面对的前端界面肯定是一致的，但是我们后端系统的割裂对我们业务创新会带来极大的挑战，且人力成本消耗浪费也很庞大。为了提升业务响应能力我们完成了服务化到平台化的转变，这种转变的核心在于自上向下去做整体的架构设计，将能力领域重组并且做成熟，因此我们成立了“共享业务事业部”，把公共的业务能力划归到共享业务事业部去做，如我们的交易中心、商品中心、结算中心等，此时我们注重的还是业务边界职责的划分。

那么阿里又是是如何从平台化演进到中台的呢？现在阿里发展的越来越快，可能有上百个BU，这个时候就会碰到以下问题：新的业务需求不断提给交易平台，排队的情况也愈演愈烈，就有种原始的烟囱式架构那种感觉。这个时候我们做了一个决定，去掉“业务”两字，变为“共享事业部”，那我们到底共享的是什么？其实是为业务提供标准能力，例如交易场景中的担保交易、货到付款等基础能力的标准化，然后由上层业务自身去决定如何实现创新。从平台化到中台，它核心解决的是快速和低成本的创新。这个时候我们更注重的是业务能力标准、运行机制、业务分析方法论、配置管理和执行系统这一系列问题。以上就是阿里中台演进的一个完整过程。

企业更需要的是中台级的服务

中台架构为代表的数字化趋势是非常明显而且不可逆的，业务打通，技术打通，数据打通，这是企业的基本诉求。中台的诞生对于目前很多企业来说其实是一个比较大的一个刚需。但是对于要上中台的企业来说，到底我们今天是为什么买单？是为中台级的服务买单，还是为中台级的团队买单，还是为中台级的项目买单？在回答讲这个问题之前，我先大胆抛出我自己多年中台实践下来的观点：企业更应该关注中台级的服务，并且如果没有低代码加持的中台，其实都是在收企业的智商税。

大部分中台公司都会告诉我们中台是需要持续迭代的，快速演进的，所以企业要去构建一个中台级的团队，然后不断的去完善这个迭代。但对一家企业来说，如果我已经有了这样一个中台级的团队，那我再找一个中台级的软件公司来给我服务呢。反过来说，这种说法背后意思其实是如果中台建设一旦出了问题，即对业务的响应速度不够快时，责任就又回到了企业即我们在座的CIO身上，那是因为团队没有建设起来。而另一方面，实际上大部分企业也并不太能招到那么多精通互联网架构的人才和好的研发人员。因此，如果让甲方企业去靠自建一个完美匹配的团队去上中台来维持这样一个庞大的体系，其实反而是起到副作用的。除此之外，运维这么一套庞大的体系，也可能需要向这类中台公司去支付额外的一些底层诸如PaaS、Devop等成本。综上所述，最后的结果往往可能是各位花了钱，但没有达到效果，这便是中台今天的一个困境：大多数企业组织的能力其实是达不到当下互联网中台的要求。这也是我们为什么说中台需要结合低代码。如果现在还有中台公司告诉你说，你需要庞大的团队去运作，然后去支撑这个业务，那我觉得你可以大胆去讲，我们需要的是中台级的服务，我们需要敏捷响应业务的能力，但是我能否不建这样的团队，同样去享受这样的能力呢？

今天我们再说说中台级的服务，为什么中台级的服务需要低代码的加持？本质上其实是今天软件行业需要对服务的要求发生变化。我们从信息化到数字化，从企业的内部到外部的跨进，外部的变化越来越快，那其实同时也代表着我们软件公司这个服务能力需要变的越来越强。一个需求的变化，我们如何快速的响应，这个其实是最核心的。信息化时代是项目制的服务，一次性、长周期、重咨询是他的特点，以往企业就是不断的进行项目制的轮回，不断的和软件服务商在项目上进行谈判，这繁杂的过程意味着就整个项目的迭代就是比较慢。而现在我们认为未来的服务应该是在线化的，什么是在线化？是轻咨询，短周期，高频次，并且对甲方的这种人员要求相对比较低。只要你懂业务，你就能够在这一套平台上快速去构建、迭代和响应。项目制的特性意味着他本身的服务是“交付即结束”，上线后就是个基础的系统没有持续的迭代。我们提倡的理念服务在线化后是“交付即开始”。发生这种变化的原因在于：以前上ERP是大工程，一上几年不变。今天上中台也是大工程，但是上去就变，上中台就是为了应对变的时候能从容点。所以项目交付后企业的诉求是不一样的，对软件公司的后续服务提出了更高的要求。

这里我们说低代码中台驱动服务在线化，我们把互联网中台架构带来的复杂性都被内聚到了APaaS里面，让懂业务的人就可以通过低代码工具去驾驭这套系统。

数式Oinone低代码中台为企业赋能

分享一个我们的客户案例，我们利用我们自研的低代码中台产品PAMIRS帮其布局了一整套完整的商业全场景数字化。雾芯是中国目前最大的一家电子烟公司，产品品牌叫RELX悦刻，每年以3、4倍的增长水平发展。这样一家高速发展的企业，他们为何会选择我们这样一家年轻的公司去帮助他们实现数字化转型呢？此前，也面临着系统异构的难题，此前它靠十几套系统来支撑他的业务拓展，之间数据其实是完全割裂的，而随着规模的壮大，他一旦需要业务创新，每次需要找多个系统供应商去做协同和商务谈判，项目周期以半年为单位，非常不利于未来业务的发展，因此他们决心搭建一套互联网中台架构来解决。他们选型找了很多家中台公司，大家给的都是同样的中台能力：数据统一，业务和技术打通。而最终选择我们的原因是我们不单能帮他们完成上中台的诉求，同时我们也会把敏捷响应业务能力赋予他们：通过我们低代码的能力，在未来他们的产品经理、业务顾问都有能力利用中台去快速迭代进行业务创新，这也是我们和其他中台服务商的区别点。也正是因为这个区别点，才让我们这个去年才成立的公司得到了很大企业的信任，不乏一些新品牌如雾芯、斯可馨、老爸评测这类以新经济为主的企业，还有像中国烟草、上海电气、中航国际这些大的国企央企都在选择我们。这也在此证明，当下数字化经济时代，企业所需要的不仅仅只是中台，而是需要是中台级的服务，即快速和敏捷响应业务的能力。

我们希望数式Oinone在数字化这个时代，为行业带来改变，为客户带来价值，帮助企业数字化转型不走弯路！

同时感谢各行业生态伙伴们对数式Oinone的认可！也期待更多的合作伙伴加入数式Oinone生态体系，共建生态,共赢未来！

欢迎咨询了解！