中台之于银行，蜜糖还是砒霜？

一场疫情，让银行数字化转型再次提上日程无接触银行不再是战略规划中亮眼的提法，而是如今各银行经营中不得不面临的切实问题而中台，作为数字化转型中最火热的概念，这两年在行业里风头无两中台是数字化转型的一剂良药，还是另一个风投炒作的概念银行应该做中台吗盲目上马中台项目有什么后果本文尝试给出一个答案

为什么要做中台。数据中台打通数据孤岛

主流的观点认为，做数据中台是为了打通数据孤岛在互联网企业确实可以理解， 但是银行对于数据的应用很早就开始了大行普遍 2008 年前后就建成了数据仓库，数据层面早已将烟囱系统打通，那么数据中台的意义何在

银行确实在数据方面很早就开始了尝试，加上金融是个低频场景，因此在相当长的一段时间内，T+1 甚至 T+2 的整合数据基本够用了，更多数据整合和加工为的是满足监管需求。

伴随着移动互联网时代的到来，用户行为，市场，监管都发生了变化，各类服务移动化的趋势下，用户的使用时间碎片化，金融，特别是支付，理财等行为也变成了中高频交易，并且伴随着互联网巨头的进入，市场变化不可同日而语，银行的危机感日渐增加。

业务需求响应再快，也赶不上市场，客户，监管的变化速度，而应用开发速度就更慢了，大银行半年左右，中小银行三个月左右是常态应用系统上线后，传统的基于数仓，数据集市的数据采集和整合方式在时效性上已经很难满足要求可以说，银行在打通数据孤岛方面，或者更全面的说，在数据加工，分析，及发挥数据价值方面，尝试得很早，但是效果不佳mdash，mdash，既不快，也不好

不快很好理解，即时效性达不到要求，利用最新的流数据处理，分布式 ETL 技术， 数据中台可以更快的整合，加工数据可是打通效果不好该如何理解呢

业务数据化

有句话说得好，数据是物理世界在数字世界的投影既然是投影，那么光源和视角的不同，可能投影的结果也不同

举个例子，同样一个事件，比如客户刷卡消费，在财务视角看来，是一笔应收账款，在业务视角来看，是一笔客户消费，账户/卡活跃，积分增加，从科技角度来看，交易流水表增加一条记录，账户余额表修改一条记录我们很难用数据去精确描述一个事件，或者说，在银行的实际使用场景中，每个部门看待同一个事件的角度就是不同的，各部门需要从不同的角度看待同一件事，以便更好的完成自己的职能在这里，各部门其实都是数据的使用者，即数据用户，那么，我们可以得到一个结论:数据用户对于数据的需求各不相同

这也是银行要打造数据集市的原因，数据仓库采用相对标准化的数据模型将数据聚合了起来，但是仍然难以满足所有业务人员的需求因此各部门都提出了自己的数据集市需求

正如上节中提到的，伴随着市场变化越来越快，客户变化越来越快，业务需求已经越发追不上他们变化的速度了，而数据的采集和加工速度则更慢，难以支持数据决策于是，各部门又经常提出各类报表和数据提取的需求，这些都是针对临时的，紧急的，监管要求的，营销统计的数据需求，虽然这些需求更加贴近业务需求，但是在分析和开发上通常也要花费不少时间

现在，我们可以回答上一节末尾提出的问题:数据孤岛打通的效果不够好，指的是数据的业务友好度不够。

总结银行数据加工的现状，可以得出下图:

在我们传统的数据应用中，伴随着数据对于业务友好度的增加，其时效性也在减弱而我们的目标，显然是数据又快又好既然各部门的需求都不一样，为何不让业务自助分析数据呢于是我们有了右上角的目标状态但是这个理想状态和我们现在的数据应用中间有巨大的空隙，靠什么来填补答案是数据中台

业务中台优化烟囱系统架构

银行的数据之所以很早就在进行打通的尝试，主要原因就在于产生数据的业务系统，长期存在重复建设和烟囱系统的问题到底是什么原因，造成了这个现象

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

mdash，mdash，Melvin Conway

换句话说，就是组织的沟通方式，决定了其设计的系统架构回想银行内部的沟通方式，我们不难发现这些现象:以部门为中心，以部门 KPI 为导向，部门墙现象严重，跨部门沟通协作及其困难由于 A 部门管理的 A 系统无法配合改造，为了实现相似的功能，B 部门只好新建一个 B 系统，这种情况屡见不鲜这种种现象导致了银行信息系统的建设和管理都是面向部门的，换句话说，形成了烟囱式架构

因此，中台的建设，必须包含组织架构的相应调整否则，如果我们把中台具象为一个具体的产品，仍然按照原来归属某一部门或业务条线管理的话，无非是又增加了一个大烟囱而已

那么，烟囱式架构到底带来什么问题呢。

对外，可能造成同一机构的不同产品，不同渠道，对客服务的体验不一致，甚至账号不互通，每用一个产品还需要客户新注册，开户，体验极差。

对内，成本高，可能造成重复建设，浪费本就紧张的科技资源，挤占排期时间， 激化内部矛盾，烟囱系统产生的数据，形成数据孤岛，为后期统计分析带来极大的困难，进而造成数出多门，甚至错误数据导致错误决策的严重后果，模块无法复用，经验无法共享，烟囱系统各自独立，无法复用其他烟囱的模块或经验，哪怕他们高度相似。

其实，银行也很早就开始烟囱式架构的治理，比如在渠道层，新建渠道整合平台， 在用户层，新建 ECIF 系统，所以说，银行并不是中台战略的追随者，而深感数据孤岛，烟囱式架构之痛的银行人，一直是中台战略的践行者，只是没有把这些尝试体系化，结构化而已。

支持前台快速迭代

前文提到，市场，用户和监管的变化速度，远远快过业务系统迭代的速度，为了抹平这个差异，我们需要让业务系统，尤其是前端面向客户的系统尽量的敏捷这也是目前业界流行的小前台，大中台提法的由来

其实微服务的思想就是将大的系统，拆分为小的应用和服务，高内聚，低耦合， 发布有价值的服务，即可被使用和共享的服务而高内聚，低耦合也一直是银行设计架构的基本原则因此，我们可以看到，银行的架构设计，微服务体系，中台架构一脉相承，都是为了共享功能下沉复用，减少重复造轮子的现象

这带来的好处，就是新建应用的时候，可以通过已有成熟模块的组装，实现快速上线，从而加快业务系统的迭代，真正实现小前台，更好更快的相应市场，客户和监管的变化。

综上所述，中台建设是银行进行数字化转型的关键举措，势在必行。

中台是什么。

2019 年被称作中台元年，一时间，各种中台概念，各种形式的中台方案如雨后春笋一般层出不穷目前，中台并没有一个放之四海而皆准的标准定义，根本原因， 在于中台并不是一个标准化的产品，根据每个企业自身的情况，中台的建设方案可能千差万别

不过，可以达成共识的，是中台的特点，它是企业共享能力，共享数据的组织或平台，并且具备业务属性，能够实现业务价值，有响应的组织架构支撑。

中台的形式也五花八门，除了公认的数据中台，业务中台以外，还有技术中台，研发中台，AI 中台，移动中台，算法中台等等参照中台的特点，我们认为凡是与业务不直接相关的，都应算作后台，虽然其他中台也是能力的复用，或者间接产生了业务价值，但是为了厘清边界，明确讨论范围，我们将集中就数据中台和业务中台展开论述

数据中台是什么

上一节我们探讨了做数据中台的原因，由此我们可以给出数据中台的使命，是为了打通数据孤岛，实现业务数据化，让数据更快更好的产生价值。

结合数据中台的使命，我们可以将其分为狭义的数据中台和广义的数据中台。

狭义的数据中台，指的是一套数据应用和工具，包括分布式 ETL，数据资产管理，数据标签管理，数据沙箱，自助分析平台，元数据管理，数据质量管理等等，底层则已现有的数仓，大数据平台等为数据源，为企业提供数据资产管理的能力， 并持续挖掘数据价值，持续提供数据智能服务。

广义的数据中台，则在狭义的数据中台基础之上，包含了顶层数据战略，数据治理体系以及数据管理及运营，数据文化培养和组织架构支撑，是一套持续管理和运营的体系。

可以这么说，狭义的数据中台，是专为达成数据中台的使命而打造，一类是让数据更快的处理，整合，加工，比如分布式 ETL 工具伴随着传统数据被大数据平台逐步替代，ETL 工具对于大数据平台的适配也需要与时俱进，支持分布式计算，弹性计算，并且减少开发量

另一类是让数据更好的产生业务价值，比如数据标签管理，自助分析平台等数据标签大家都在用，但是真正深度使用的企业都会感觉:建好容易用好难，如果没有一套标签管理系统，标签是否重复加工，标签的使用率，准确性等都无从掌控，业务部门想要针对近期营销活动新建一个标签，还得走开发流程，时效性也难以保证

数据标签管理系统就是为了解决数据标签的使用问题而建立自助分析平台则是方便业务人员自助进行数据分析，加工，探索的平台，它与数据沙箱结合，直接将去隐私话的生产数据提供业务人员分析，使数据更快的产生价值， 支撑关键决策

广义的数据中台，则是辅助狭义数据中台达成使命的机制，虽然看起来都很虚，但是却是数据中台成功落地的必要保障。

没有数据战略，在推进数据中台建设，甚至建成后的日常运营中，难以沟通协调各部门利益，缺少尚方宝剑没有数据治理体系，数据管理无凭无据，无章可循，很容易造成 Garbage In—Garbage Out 的现象

但是这里必须澄清一点，在银行信息系统这样复杂的环境中，数据质量的问题永远存在因此，等数据治理好了，等数据质量控制好了，我们再开始做数据应用，做数据中台，这种想法是不切合实际的，因为不存在数据质量控制好了，数据治理好了的那一天，这是一个持续的过程，好到什么程度算好谁来决定这个标准

我们认为，数据质量很重要，需要持续改善，但是不影响数据中台建设， 应该以用促治，在使用场景中有针对性的开展数据质量管理和数据治理。

没有数据管理及运营，数据应用的价值无法持续产出，甚至会出现便宜甚至错误缺乏数据文化，则会造成数据应用没人会用，没人想用，没人愿意相信数据结论， 没人愿意尝试数据驱动，没人愿意基于数据决策没有组织架构支撑，则会让数据中台这样跨部门的体系难以推行，最终胎死腹中

业务中台是什么

同样，业务中台也可分为狭义与广义，狭义的业务中台，指的是由多个共享中心组成的服务整合平台，通过梳理各业务系统共性的功能，在每个中心里将服务拆分，共享我们建议，可以按风控中心，产品中心，用户中心和旅程中心等维度整合共享，底层的数据能力由数据中台提供

广义的业务中台则包含了支撑各中心运营的组织架构和体制机制正如前文提到， 没有组织支撑，中台不过是另一个大烟囱每个业务中台的子中心，都应有对应 的组织支撑，可以是虚拟的，也可以是实体的，最好由业务+科技+风险+数据的 综合人员构成，小团队作战模式，以产品使用率，稳定性，客户满意度等为 KPI， 为业务中台保驾护航

风控中心管理全行所有的风控模型，以及对客产品交易，账户层面的动态安全策略，以底层机器学习平台为支撑，共享全行风险管理能力产品中心管理全行所有渠道的产品，控制购买额度，购买条件，灵活上下架等

用户中心基于数据中台打通的全行用户信息，建立用户成长体系，权益体系，管理用户标签画像，分析用户行为轨迹，为旅程中心完成客户全渠道一致体验打下基础。

旅程中心以用户视角出发，以用户体验为最终目标，梳理，贯穿各渠道流程，整合，复用各渠道功能，最终达成全渠道客户体验统一。

结语mdash，mdash，中台的边界

了解了中台是什么，最后，我们来看看中台不是什么，或者说，中台的边界在哪里。

首先，中台不是银弹。

没有银弹:没有任何技术或管理上的进展，能够独立地许诺十年内使生产率，可靠性或简洁性获得数量级上的进步

mdash，mdash，《人月神话》

软件工程领域的圣经《人月神话》早就提出了没有银弹的说法，中台也不例外不要妄想通过中台，解决企业内部一切的数字化问题即使是上文提到的广义中台，也仅仅是包含了企业数字化转型中，与数据，业务中台相关的组织和机制，但是仍然无法涵盖一个组织在数字化转型过程中遇到的各种问题中台与其他新技术体系一样，可以帮助企业降本增效，但是如何选择业务方向，如何团结一心，如何切入市场，如何找到目标用户等等，都是企业在中台之外还需要努力的方向

其次，中台不是一个可以买来的即插即用产品。

不必为了做中台而做中台，也不必大干快上，一起步就是一个五年大工程由于中台与企业内部的数据，业务系统高度相关，虽然有相对标准化的产品可以预先研发，但是更多的工作，在于中台与存量系统的对接，优化

最后，中台不是一个筐，别什么都往里装。

当一个新技术体系难以明确定义时，最常见的现象就是边界模糊，什么都可以放进去最典型的例子就是大数据了虽然有类似5V的定义，但是大数据的定义从来没有统一，这也导致现在只要提到数据，都会冠以大数据之名实质上，大家所指的绝大多数数据，并非是大数据，都是小数据

概念的模糊，使得炒作时，无数企业挤破头往里冲，也导致行业发生合规风险时， 与大数据沾边的企业都风声鹤唳，草木皆兵这种现象，对于行业的发展弊大于利

因此，我们必须厘清中台的边界:无共享，不中台，无业务，不中台，无组织， 不中台。

没有共享能力，数据的整合，不算中台，没有直接服务于业务，产生业务价值， 不算中台，没有组织支撑，仍然服务于某个部门，不算中台。

行文至此，希望解答了大家心中的疑问简言之，做了中台不见得就是数字化领军企业，不做中台也不见得就是古典互联网时代的落后作坊关键是认清自身的数字化现状，拟定数字化目标，制定数字化路径，优选场景，实现价值中台只是这条道路上，一套切实可行的行动方案糟糕的公司治理，三天打鱼两天晒网的战略定位，部门银行的组织架构，即时搭建了中台，也徒有其表，如此，中台是砒霜

坚定的战略，清晰的目标，合理的组织架构，搭配中台，可以使数据更快更好的发挥其价值，业务模块更好的融合，用户体验得以更好的提升，如此，中台是蜜糖。