如何打造以不变应万变的业务中台？ - 知乎

中台是真正为前台而生的平台，它存在的唯一目的就是更好的服务前台的规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。

以不变应万变。

随着数字化和互联网时代的来临，云计算、大数据、微服务、物联网、移动互联等各种新兴技术为IT产业带来无限机遇的同时，也为企业业务不断发展带来了最底层的支撑，伴随着企业规模不断扩大、业务的多元化、创新化的发展，“大中台、小前台”的技术架构模式逐渐出现。

在开始讲什么是中台之前，想先给大家讲讲中台的发展史。

01.中台的起源

中台并不是近几年才有的一个新名词，它早在两千零几年就已经出现在了投资银行的组织结构中：

前台（Front office）是与客户和顾客（无论是个人客户还是公司客户）直接互动的岗位，诸如大堂经理、客户经理、柜员等。

中台（Middle office）是指直接支援前台工作的所有人员，使用前台或后台的资源，为前台提供专业性的管理和指导，并进行风险控制，比如风险管理、合规、财务管控以及IT服务等。

后台（Back office）指幕后的职能岗位，行使管理职能，比如结算、清算、会计、人力资源等。

在互联网领域中，中台的概念最先由阿里提出。

15年的阿里巴巴在淘宝和天猫已拥有规模庞大的个人会员和企业会员，业务种类纷繁复杂，业务之间交叉依赖，业务团队众多，不能及时响应业务的要求。

同年的12月，张勇通过内部邮件宣布启动阿里巴巴2018年中台战略，构建符合DT时代的更创新灵活的“大中台、小前台”的组织机制和业务机制，实现管理模式创新。

即将产品技术力量和数据运营能力从前台剥离，成为独立的中台，包括搜索事业部、共享业务事业部、数据平台事业部等，为前台即零售电商事业群提供服务。从而前台得到精简，保持足够的敏捷度，更好地满足业务发展和创新。

同时，很多互联网公司也在快速跟进中台。

滴滴出行在2017年12月分享了《如何构建滴滴出行业务中台》。滴滴出行在前端业务上形成了出租车、快车、专车、代驾等多业务共同发展的业态。虽然各业务的应用场景不同，但所有业务本质都是出行，交易流程是相同的。如果各业务独立发展，则业务间缺少协同性。

京东也在2018年12月宣布采用前台、中台和后台的组织架构。

2019年，中台全面爆发。

02.我眼中的中台

提升企业竞争力的核心是快速响应，快速创新。

而中台利用可复用的中间层技术支撑业务快速创新，就是中台的核心价值所在。

1.多业务线

当做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景，寻找可复用的能力进行沉淀的。从而可以通过能力的复用一方面消除数据孤岛、业务孤岛，一方面支撑企业级规模化创新，助力企业变革，孕育生态。

所以虽然中台的建设过程虽然可以自下而上，以点及面。但驱动力一定是自上而下的，从全局视角出发的，并且需要一定的顶层设计。

这也解释了为什么在企业中推动中台建设的往往都是跨业务部门的，因为只有这些横跨多条业务线的角色和组织，才会经常去反思与推动企业的能力复用问题。

这一点也引出了中台建设的一个关键难点，就是组织架构的调整和演进以及利益的重新分配是技术所不能解决的，也是中台建设的最强阻力。

同时企业级也是区分企业中台化与应用系统服务化的关键点，简而言之中台化是企业级、是全局视角，服务化更多是系统级、是局部视角。

所以从中台的兴起与爆发可以看到一种趋势——无论是由于企业运营效率的原因还是由于创新发展的需要，越来越多的企业对于企业全局视角跨业务线的能力沉淀，都提高到了前所未有的战略高度。

2.复用性

中台提供的服务是应该可以即取即用的；不仅如此，这次用完，下次还来；业务A用了，业务B也可以用。

服务的高复用是对技术层级上针对共用服务的抽象设计能力的一大考验，需要尽可能近地靠近业务、靠近用户。

一个中台提供出的公用服务的价值高低，是“可用”和“可复用”的区别。

3.中间层

传统的企业数字化规划更多的是围绕业务架构、应用架构和数据架构展开。产出也是一个个基于应用和系统的数字化建设规划，问题常常出现在两个方面：

  • 一个是大单体系统的业务响应力有限，缺少「柔性」，当业务发展到一定阶段后，必然产生大量定制化需求，随着内部定制化模块的比例逐渐上升，响应力成指数下降，成为业务的瓶颈点。
  • 另一个则是系统间的打通通常比较困难，容易形成业务孤岛和数据孤岛；

而中间层的出现，可以很好的对前台和后台进行适配，从而给业务提供足够的「柔性」，来满足对于业务的快速响应和复用的需求。

前台职能是理解和洞察客户需求和行为，通过产品创新和精细化运营服务客户，最终实现和提升客户价值。

中台通过沉淀、迭代和组件化地输出服务于前台不同场景的通用能力，作为为前台业务运营和创新提供专业能力的共享平台。

后台职能则提供基础设施建设、服务支持与风险管控，为中、前台提供保障。

03.为什么要做中台？

随着「企业IT架构转型之道·阿里巴巴中台战略思想与架构实战」那本书在 17 年的出版，中台开始走进更多人的视野，而到了 2019 年，中台的热度迅速攀升，火爆程度有点类似 16 年的 VR、18 年的区块链。

许多公司开始风风火火的打造起了自己的中台产品，我认为做中台之前一定要搞清楚我们为什么要做中台？适不适合做中台？

首先，中台是支撑公司多个业务产品的共享服务，如果你的公司只有一个业务产品，能做的最多只能是良好的架构设计，没有多个业务产品的实际场景输入，是难以直接做出中台。

其次，中台的目标是提高业务产品的研发效率，但为了达到这个目的，在一段时间内是需要以降低效率为代价的，时间长短取决于系统复杂度和团队能力。

我们做了5年的金融CRM，随着业务范围的不断扩张，客户需求逐渐多样，传统的标准化平台产品早已不能满足日常需求。

以不变应万变是所有做SaaS产品的目标，LeanWork也是。

04.我们如何做中台？

LeanWork于今年正式启动了CRM3.0的项目。和许多创业者一样，在打造中台的过程中，也不断面临着新的挑战，我们采访到了LeanWork CTO 阙太富，他为我们分享了一些对于解决中台研发中所遇挑战的经验。

挑战1：与前台需求的矛盾

中台团队同时在做前台需求，从业务看中台响应慢；

多业务线企业，中台团队无法同时对接多个前台团队需求；

开发为了准时完成功能，牺牲架构设计，导致中台根基不稳。

解决办法：想清楚为什么要建设中台

决定要开始做中台的时候就知道这一定会长期耗费大量的骨干人力，我们也有正在已经成熟的金融CRM业务在跑，做中台一定会从已有的团队中抽调人员重新组建团队，那么可能会影响到短期目标。

这时候需要更多的耐心和长远考虑，从上至下需要统一认知，明白中台的建立虽然短期可能会给大家带来一些阵痛，但更重要的还是解决公司长远发展问题。

挑战2：相关方多，决策复杂

前台团队，业务团队，后台核心系统，中台团队，各自的KPI不同，诉求可能相互矛盾。

解决办法：明确中台的建设不仅仅是产品和研发的事

中台首先是一种战略选择，一种组织形式，其次才是一些有形的产品支撑和实施的方法论。一定要从上而下达成一致认知，理解中台建设过程中的决策。

中台战略作为一项重大变革，如果无法执行下去一定会沦为一场空谈。

目前公司规模不大，我们先组建了一个小的团队带着业务需求去做，从组织上业务功能和中台是向一个上级汇报。但我们设计架构时，会结合之前做金融行业CRM系统的经验，在考虑安全性稳定性的同时会考虑扩展和灵活。

在研发方面我们依然用精益的思路在走，MVP版本验证成功后，我们才会加大团队的投入，在团队内部我们后期会逐步区别业务团队和中台团队，因为两者需要的能力维度不同。

比如，中台类的产品经理会更强调抽象建模能力，业务类产品经理则更偏重对市场和业务的了解能力。同时中台类的产品对开发人员的要求也更高，能力纬度也更广，因此我们尤其注重对研发人员综合能力维度的培养。

挑战3：不能短期出效果

中台的核心价值——复用性效果需要一定业务场景的沉淀，通常大家看到的只是业务需求，看不到中台在这之间有什么价值。如果直接推动已经有大量客户使用的线上系统使用中台，涉及大量接入切换工作，和对客户使用体验的影响，也会涉及到各团队KPI和利益。

解决办法：明确中台要达成的目标

解决这个问题的根本我认为是要从目标出发， 原则为目标负责。

以LeanWork自身为例，我们在MVP验证阶段，整个项目追求的是快速迭代快速交付快速验证，因此前期中台的目标更多的是灵活性，后期业务稳定，中台的目标也会调整为更加稳定。

大公司已经有多条产品线，然后把不同业务线的产品共性抽像成业务中台；而我们是带着业务需求去做中台，一边做业务一边做中台抽象。

所以首先要坚持精益的方法——先出MVP，去寻找和明确我们产品要提供的价值。为了保证我们的方法不会跑偏，我们也需要敏捷的方式来不断做阶段性的交付产品，让我们可以快速的看到产品，不断发现问题，改进问题。

目前我们正在做的销售CRM应用的核心是客户信息，它们必须被正确收集和管理。一个灵活和强健的客户数据模型是客户信息管理的坚实基础。我们的业务中台这现阶段的目标就是保持业务领域的抽象灵活性，为以后新的业务应用场景提供复用的能力。

写在最后

最后想跟大家分享一下《企业IT架构转型之道》一书中提到的几点中台产品的基本构建原则：

1.高内聚、低耦合原则

高内聚是从中台的业务界域来说的，在一个中台内的业务应该是相关性很高、依赖性很高的；而中台之间应该是业务隔离性比较大的，即追求尽可能的低耦合。

2.数据完整性原则

这个原则其实和上面的“高内聚、低耦合”一脉相承，是把这个思想穿透到数据模型层面，因为中台架构一个很重要的业务价值就是数据模型统一。

3.业务可运营性原则

中台首先是从业务出发，单纯的技术层面抽象出来的服务框架一般不作为一个可运营的服务中心。单纯的技术型的中台可以存在，但更多时候是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。

4.渐进性的建设原则

渐进性的建设原则是从降低风险和实施难度这个角度出发，服务化架构本来就是一种敏捷的实践，推荐小步快跑的方式逐步推进，不是轰轰烈烈地推翻重来。

中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。

它像Pace-Layered中的SOD，提供了比前台更强的稳定性，以及⽐后台更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。

中台是真正为前台而生的平台，它存在的唯一目的就是更好的服务前台的规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接，以不变应万变。

文|Kaixin

特别鸣谢|阙太富·Sam-LeanWork CTO

原网址: 访问
创建于: 2021-03-23 14:22:45
目录: default
标签: 无

未标明原创文章均为采集，版权归作者所有，转载无需和我联系，请注明原出处，南摩阿彌陀佛，知识，不只知道，要得到

请先后发表评论
  • 最新评论
  • 总共0条评论