2019电商生意经（五）：明确中台化的概念、形式与战略

前序 BI . 先聊生意

从事过大数据、算法和AI的各种工作，

但一直很喜欢“BI”这个词。

 

“BI，要先搞清楚‘B’，生意；然后再来讨论‘I’，怎么去实现”。

“不懂B，只懂I，只能是没有灵魂的BI团队。”

搞清楚生意如何做，知道目前的技术能干什么，才好谈AI和数据项目如何设计...

 

 

"大中台，小前台"

看上去简单，但各家有着不同的解读甚至误解，具体到某个公司、某项业务、某类应用、某个产品，又很难规划与落地。

中台化的定义：主要是针对一定体量的集团型公司，把前线多个事业部或子公司（我们统称为BU吧）的职能，尽可能下沉为公共部门的职能，集团层面统一化建设，统一支持各BU，让在前线的BU能够轻装上阵，这个就是中台化。

 

中台化的误区

中台的误区众多，我们只更正三个主要方面：

中台本身是：指职能，而不是指一种具体的技术形式。技术形式只是为职能服务的，是为了更好达成职能效率的方法，这一点上往往受到"中台"字面意思的误导，容易联想到平台、前端、后端之类的技术形式，中台的具体形式可以是：技术中台、业务中台、组织中台，也可以进一步细化为SaaS云、数仓、报表平台、XX平台、配制化、定制化开发等多种形式。纠结于技术形式，反而会理不清楚中台化的体系。

需要无视的后台，业内目前，中台化提的比较多的是“大中台，小前台”，大家自然就会想到“后台”是什么？但实际上中台化，本身强调的是从前台的下沉，剥离成中台，并不是为了强调与后台的边界。已经不需要强行定义后台了，过份纠结于中台与后台的边界，往往会令中台化难以理解、无法落地。

“中”的涵义：中央、集中、统一。中台的“中”字，并不是指软件模块层次和调用关系的“中间层”或“中间件”，也不是指业务流程中的中间环节。也不是说员工用的就是后台，用户能接触到的UI是前台，夹在中间的就一定是中台；前台的“前”字，指是的业务前线，并不是指前端页面，对于互联网公司来说，它的承载形式确实主要是前端产品的形式，但并不是等于前端，它是指业务前线的职能。中台的“中”字，强调的是中央化思维、全局化视野、集中集团数据和能力、统一建设，支持业务前线（前台）。

 

中台的形式

中台化是职能的集中化，但是当前，即使在传统公司，公司的各项职能也不是能脱离信息化系统、脱离具体技术形式的，互联网公司更是如此。中台化的技术形式基本可以分为三种：

1. 技术中台的形式

• 偏传统的做法,或者应该称为“平台”，或者PaaS、IaaS，以基础技术或基础数据的统一化支撑的形式，来实现中台化职能。公共做原始数据，或半成品数据的支持，BU依其需求，做数据深加工、业务、产品设计和上线；
  
  可以看成公共只提供好铝材、钢铁、橡胶，BU负责生产各种大飞机。然后农、工、商的各BU，分头用公共(技术中台)提供的铝材、钢铁和橡胶，来自主来建自己业务所需要的工用、商运、农用等大飞机。技术中台并不是纯粹的中台化，因为各BU的繁重职能，并没有统一化和集中化，各个BU依然在重复建造大飞机，BU并没有轻装上前线。

2. 业务中台的形式

• 业务中台，是以统一的业务信息化系统SaaS的形式输出，来实现中台化职能，亦可称为BPaaS、SaaS加速器。是可以轻量化、配制化支持各BU不同的业务需求。目前业内，主要是做各BU现有业务职能的通用化公共下沉，业务中台自身只做面向未来的全局性稳步创新和迭代，战略性和长态性赋能全BU，需要兼顾全局视野和各BU兼容性，能够灵活支持各BU的业务变更和稳步创新，有能力保证比BU独立研发更快。
  
  可以看成公共不仅弄好铝材、钢材、橡胶，而且构建了大飞机制造的80%环节的成熟流水线（业务中台），余下20%的环节： 依BU场景情况，联合开发；或者以柔性制造的方式（对应业务中台的配制化和平台化），依然可以流水线支持BU定制化的业务需求和稳定创新；“小前台”的工作：BU负责把飞机刷上自己的外漆、Logo，快速配上各BU业务所需的经济舱座椅、头等舱座椅、物流用隔断、医用床位与设备、消防设备，制定好自己客用、货用、消防等BU业务模式和运营方式，就能全司全BU上线了。至于发动机、导航、动力学、航空材料的迭代升级，由公共的业务中台统一完成，不需要BU重复推迭代了，业务中台只需要保证这些新、旧版本的模块，能兼容各个BU不同的业务需求。
   

3. 组织中台的形式

• 组织中台，是以某一团队的组织形式，来实现中台化职能。主要是在面对一些技术和业务难度大的创新项目，在业务中台尚不能很好支撑的情况下，依靠组织中台来创新或研发。组织中台并不拘泥、不纠结于传统的分工和技术实现形式，强调团队人员的“三全”： 以具全局化视野、全域数据、全栈研发能力的团队，精减项目人员，打破传统技术栈分工，来攻坚和孵化，一些技术难度大的创新产品/业务，灵活应对创新过程中不断出现的技术难点和业务困局；以强弱矩阵结合的方式，打破部门壁垒，不考虑对各BU的兼容性，轻装上阵，以产品创新、线上验证为主线。项目验证成功后，再考虑：技术层面，是否需要下沉为业务中台，反向赋能各BU；产品层面，是否需要成立新BU，来运营这条产品业务线。如果该创新涉及跨BU的，应以“组织中台”主导，保证有好的全局观和全局能力；如果创新内容只涉及单BU的，应由该由BU基于现有中台支持下，独立完成，技术难度大，需要重构业务中台逻辑的，也建议由BU来主导，联合“组织中台”来协同创新。
  
  可以看成，集团或BU提出大飞机的创新需要，但是在大飞机的技术可行性、业务可行性都没有全面验证的情况下，指定一个全局性团队（实体或虚拟团队），专心做好最有潜力的一种大飞机，以最灵活的组织架构，确保产品迭代的周期最快化，来应对层出不穷、不可预期的技术难题和业务瓶颈。比如：先造出客用飞机，再结合公司现有农、工、商的BU格局，去中台化，以第2种方式，赋能农、工、商等BU，形成他们所需要的农用、工用、消防用、医用的大飞机，同时孵化出空中客运的新业务线。

 

中台化的价值：

这里主要是指业务中台和组织中台，单纯的技术中台并不能充分体现这种价值。

1. 避免重复造轮子

a) 对于新业务线，集团层面，不用去重复从头造个性化系统、客服系统、订单系统、商品系统、HR系统等。

b) 对于各BU现有业务系统，比如有60%的模块，是可以统一迭代升级的，中台化后，也不用重复研发了。

2.全局化视野&全量数据

事业部或子公司独立迭代出来的业务系统，势必缺乏全局化视野，也缺乏全量数据的整合，特别对大数据类应用，很难形成“大”的规模效应。中台化是打破业务线的数据隔阂，以全局视野，来构建公司各类业务或技术能力。

3.高效创新

• a) 更高效的新业务创新。中台化后，公司层面，可以更高效地支撑新业务的创新。新业务不需要从头建造所有的业务系统。
   
• b)公共模块的创新落地更快。中台化后，特别对于业务中台，大飞机的发动机、导航、动力学、航空材料的统一迭代升级，直接赋能给农、工、商各BU，中台引擎的创新落地更快

• c)试错成本降低。创新都是有业务风险和技术风险的，拥有全局信息、全局视野的业务中台和组织中台，更像一个创新的HUB，一项创新无论是成功或失败，经验都会传播给其它BU，避免BU之间的重复试错。

 

中台化的战略布局

 

一般来说，有二种转换方式，但长远来看，终极目标都是向“业务中台“转化，因为从长远看，“业务中台”方式最为高效。

1. 第一种转换方式：一般是对历史或现状的正视，从技术中台的形式，稳步下沉为业务中台。以技术中台，支持BU的独立的业务研发和摸索，但从公司层面来说，新业务线的研发难，需要重复造轮子，而且BU独立设计的业务系统，本身就可能缺乏全局视野，缺乏全局的数据整合和能力整合。通过下沉到公共，以全局视野，来轻量重构成业务中台，战略上统一做全BU的支持，统一迭代，也方便公司层面做高效的新业务创新。
2. 第二种转换方式：有些具体的业务创新，在没有现成BU业务系统、司级业务中台能支持的情况下：
   1. 如果创新内容涉及跨BU的，以有“三全”能力的“组织中台”为主导，快速迭代，验证技术、产品、业务可行性。因为“组织中台”是团队，本身非常了解自己开发的这个系统，可以快速地重构成业务中台，赋能给各BU，回避了交接和消化现有系统的环节。
   2. 如果创新内容只涉及单BU的，应由该BU独立完成，如技术难度大，需要重构业务中台逻辑的，也建议由BU来主导，联合“组织中台”来协调创新。