1. 什么是中台？
看到几篇关于中台的博客，是国内提出的一个新的概念，稍微研究了下，很有意思的概念。
中台，在我看来，从业务上来讲，可以说是为了解决系统的复用性的问题而出现的。一个简单的例子，阿里刚刚开始的时候只有淘宝，但是后来出现了天猫，二者尽管顶层业务逻辑有不同，但是他们都是需要一套订单，商品，库存，仓储，物流的各种系统的。如果每次我们想做一个新的业务模块的时候，都要来实现这样一套系统，迭代速度会很慢，而且很容易在做改动的时候因为各个类似功能的系统的改动不一致产生错误。
因此，将这些公用的系统提升，做成–中台，统一来使得各个业务部门重复使用，将需要反复建设的功能和系统进行统一的规划和管理。
主要解决的问题实质上有两类：
- 需要业务需求或者功能需求是高度类似的，通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设、导致复用性很低，效率低，研发资源被浪费，用户体验也不够统一
- 早起业务发展过程当中，为了解决当下的一些业务问题，垂直的个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑非常多，导致了在新业务新市场的拓展过程当中，市场没有办法直接复用，甚至没有办法快速迭代。
2. 为什么要中台，为什么要平台化？
引述《白话中台战略》当中的内容，“因为在当今互联网时代，⽤户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍”
不断快速响应、探索、挖掘、引领⽤户的需求，才是企业得以⽣存和持续发展的关键因素。
那些真正尊重用户，甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展；⽽反之，那些在过去的成就上故步⾃封，存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。很残酷，但这就是这个时代最基本的企业⽣存法则。
平台化能够赋予或加强企业在以用户为中心的现代商业战争当中最为核心的能力 –> 用户响应力。
中台，可以说是与前台，后台相对应的。
前台
- 由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或者交互的系统，是企业与最终用户的交点。
后台
- 后台系统组成的后端平台，宝具哦企业的核心资源 – 数据 + 计算
- 财务系统
- 产品系统
- 客户管理系统
- 仓库物流管理系统
中台
- 因为企业后台往往不能很好的支撑前台快速创新，响应用户的需求
- 前台直接使用后台，会遇到处理复杂，迭代速度缓慢的问题
- 前台要处理的是快速响应用户的需求，但是后台拿着整个公司的数据，是需要越稳定越好的，随着公司的发展，按照对速度和稳定的追求的冲突会越来越多
- 有了中台以后就可以将前台系统当中的稳定通用业务能力沉降到中台层，恢复前台的响应力
中台是企业级能力复用平台，整个中台的构建，实际上是将业务数据化，将数据业务化。是需要建立业务中台和数据中台的。业务中台通过抽象，封装可复用的逻辑，提升企业的响应力；数据中台通过打通企业的数据，构建自学习服务的数据能力，让企业更加智慧。
3. 通用化通用能力
目前大部分企业实现的中台，主要是将遗留下的后台系统，比如ERP MES CRM的公共部分进行拆解复用，形成类似交易中心，用户中心，订单中心这样的微服务集合供前台调用，从而保证逻辑的一致性同时更快响应前台的变化
Reference 1 当中举了订单服务的演进过程的例子，很值得一看。当平台需要开放多渠道来完成订单的时候，保证用户有着类似的体验是很重要的一项，包括整个系统的的scalability。
在这种情况下，一个数据中台能够使得用户可以看到在各个平台各个渠道自己下的订单。从平台角度来说，有了数据中台，维护成本，发生错误以后的修改成本都会减轻很多。
略微解释下，如果是分开的系统，那么每个系统都会有自己的数据库，我们需要做数据的join操作，然后返回给前端用户需要的正确的信息。当发生了逻辑上的错误以后，我们很有可能需要在分开的几个子系统当中来做修改，很容易出错，修改的整个时间消耗也会很长。而且数据仓库在多个系统的情况下，抽取数据，再进行分析是有比较大的时延的，一般都是加一天的样子，无法看到实时的数据。
4. 使用中台去ERP化
ERP， 即企业资源管理系统。最最开始的时候，企业的需求是将企业的流程梳理清晰，做到资源的集约化管理，本质上来讲是为了解决流程复用，业务能力化的问题。
但是当前ERP软件存在着如下的一些问题：
- 商业软件，响应慢
- 企业只有使用权，这就导致企业的业务发生变化的时候，需要找到原厂重新配置或者重新开发，响应比较慢
- 封闭架构，不开放
- 套装ERP软件是封闭架构，技术不开放，导致企业无法对其进行大的功能上的扩展，只能像打补丁一样，构建一些外挂，而且效果往往不会很好
- 单体架构，弹性不够
- 单体架构，很难支持持续增长的各种需求
- 升级 维护成本
- 套装软件升级和维护成本非常高
过去人们需要ERP更多的是因为我们需要流程，需要知道具体应该如何去组织。但是在互联网化的今天，原来静态化，标准化的业务流程已经不足以支撑企业的快速响应了。因此，诉求从原来的流程化变成了需要能够快速响应前台市场的变化。
企业组织结构从流程式协作走向了平台式协作。
ERP更像是一种计划式的经济，希望每个角色都按照分配的任务来走，共同完成一个任务，但是这种共同完成会导致不同角色之间的利益相互冲突。局部利益大于整体利益。
需要的转变是 —- 要开始学习以客户为中心去动态组织资源来提供服务，将原本以流程为独立单元的模块拆解为以客户价值为独立单元的模块。
以客户价值为独立单元，如何评定绩效就是个很关键也很困难的问题，尤其是对于那些为后端赋能的业务单元，如何将其关联到直接的客户价值当中。这需要数据中台提供这方面的能力，来利用全域的数据分析，建模，通过敏感性分析等算法技术来实时计算。
5. 数据中台成熟度的评估维度
数据战略
- 理念
- 究竟做数据中台是为了什么
- 一个组织的愿景和目标，来指导我们接下来的行动
- 确定组织，团队对于战略的理解是一致的
- 行动
- 如何保证战略落地
- 如何处理冲突，不一致
- 如果构建决策流程
- 战略/行动的优化和调整机制
- 确保战略目标能够被有效分解
- 能够在部门团队之间落地
- 一个管理组织
- 制度建设
数据治理
- 元数据相关
- 如何做元数据分类
- 技术和业务元数据的管理
- 维护机制
- 数据字典相关
- 数据模型相关
- 数据质量相关
- 数据标准相关
- 数据安全相关
- 数据生命周期相关
数据资产管理
- 数据资产审核能力
- 注册申请
- 数据资产发布能力
- 将数据提供给消费者查询使用的能力
- 数据资产标签
- 客户特征标签
- 关键业务的指标标签
- 数据资产地图
- 通过地图或者目录的形式，提供数据资产的查询功能
- 实现数据资产的可视化
- 数据资产开放能力
- 通过接口提供给内外部用户使用
- 数据资产盘点能力
- 数据资产定价
- 效益评估
数据平台和架构
- 基准
- 易用
- 稳定
- 可扩展
- 支持多应用的平台架构
- 架构标准
- 架构规划
- 基础架构
- 评估机制 数据服务化
- 同业调研
- 选型
- POC
- 决策部门
- 架构选择的流程
- 架构方法
- 数据中心以什么样的方式向外界提供服务呢？
- 量化的评估标准
- 服务目标
- 提供方式
- 流程
- 优先级
- API调用
- 服务标准的确立
- 服务监控和维护
- 数据服务的评估和优化
数据产品化
- 产品
- 报表分析等
- 业务支撑能力
- 所能支撑的业务是否能反映战略的方向或战略的执行情况，功能支撑能力是不是能被周期性评估和优化
- 业务分析响应能力
- 响应机制
- 数据可视化能力
- 是否支持业务友好的使用方式
- 统一服务的能力
- 是否能够将业务需求沉淀成统一的服务的能力，从而服务更多业务团队
中台运营
- 将整个平台作为一个产品来看，是否有运营的指标和控制机制
- 中台管理平台
- 文档
- 规范
- 流程等
- 成本分析
- 存储
- 计算
- 研发
总结
为什么需要平台化
- 赋予企业用户响应力
什么是中台
- 企业级能力复用平台
- 基础的理念和架构
- 可以联通，支持上端的业务
- 需要能够将后台各式各样的资源转化为前台易于使用的能力 –> 以用户为中心的持续规模化创新
- Platform as a product
- 亚马逊大量使用微服务，关于微服务与中台，可以想象成中台是多个有平台化能力的微服务的集合，通过隐藏内部的信息和不- 必要的接口，对外呈现为单独一个具有平台服务能力的微服务。
中台分类/ 为什么要建平台
- 内部研发效能提升
- 资源整合
- 新零售
- 全周期
- 全渠道
- 开放银行
- 多品牌战略
- 全球化战略
- 产业互联
- 构建商业生态
阿里的数据业务双中台
- 业务中台将后台资源进行抽象包装整合，转化为前台友好的可重用可共享的核心能力，实现后端业务资源到前台易用能力的转化
- 数据中台从后台及业务中台将数据流入，完成海量数据的存储，计算，产品化包装的过程，构成企业的核心数据能力
阿里技术中台
- 将使用云或者其他基础设施的能力以及应用各种技术中间件的能力进行整合包装，过滤掉技术细节，提供简单一致，易于使用的应用技术基础设施的能力接口，助力前台和业务中台数据中台的快速建设
组织中台
- 中台建设真正困难的地方在于组织上的重构，技术架构与组织架构的匹配！！
- 组织中台很像企业中的内部风投和创新孵化机构，为前台组织和团队构建创新型前台应用提供类似于投资评估（项目甄别）、投资管理、投后管理（孵化与风控），真正从组织和制度上支撑前台组织和应用的快速迭代规模化创新
中台建设的难点 – 需要关注组织架构的调整
- 组织架构的调整和演进以及利益的重新分配
- 战略的落地是需要靠组织架构的调整来实现的，企业的发展取决于企业正确的战略以及企业的组织结构。前者决定了后者，后者能够保证前者的落地实现
- 如果将中台和前台之间的关系定义成服务和被服务的关系，很容易会因为大量需求占据大量时间，短期利益和长期利益的博弈，造成很多问题
- 产品化思维，将中台当做一个产品，和其他组是产品之间互通的关系
关于中台 - 产品化思考以后的问题
- 愿景是什么？
- 中台作为产品需要有自己的愿景定位，不一定需要满足所有前台客户的需求，这同样也意味着前台可以选择不使用中台的某些能力而选择自建。
- 用户是谁？如何划分？
- 中台作为产品需要有自己清晰的用户定位和用户划分，前台作为中台的用户不再是平等的，VIP 前台用户的需求要优于免费前台用户的诉求，通过产品上常见的用户划分来解决需求膨胀、排期、优先级和冲突问题
- 解决了什么问题？
- 中台作为一个产品，需要想方设法体现自身的价值，真正为前台客户解决实际问题，并关注前台用户体验，通过营销和售前等手段获取前台客户，通过清晰的用户定位和产品力吸引前台客户，让其主动选择采购中台产品
- 竞争环境？团队构成？
- 产品的建设初期，不一定启动资金直接从业务上切分，可能需要类似于天使投资的企业战略投资进行初始孵化，减少中台前期建设的业务交付压力，甚至作为企业的战略级产品，需要一些内部保护和孵化，但仍需要快速验证其价值，获取客户，实现自负盈亏
- 如何获取用户？营销？售前？
- 如何向用户提供服务？
- 产品的建设过程可以借鉴精益创业思路，需要尽快体现其商业价值，如果一定时期内无法获取相应的前台用户（前台不用），或是其他考核指标不达标，则需要进行中台建设止损，类似于创业失败
- 甚至在特殊情况下，允许同一类型的中台产品存在合理的内部竞争，同时对两个相似的中台产品进行孵化，使用类似于内部赛马的机制解决内部服务差异性带来的内部产品垄断和定价困难问题
- 中台产品为了用户留存，需要对于前台客户提供产品级 SLA，提供客户运营，客户售后服务，保持产品平滑更新，关注用户满意度，实现客户留存与转化
- 如何验证价值？成本核算？定价机制？
- 如何保证服务质量？
- 如何升级演进？产品运营？
引用文献
