一场疫情，让银行数字化转型再次提上日程。ldquo;无接触银行rdquo;不再是战略规划中亮眼的提法，而是如今各银行经营中不得不面临的切实问题。而中台，作为数字化转型中最火热的概念，这两年在行业里风头无两。中台是数字化转型的一剂良药，还是另一个风投炒作的概念?银行应该做中台吗?盲目上马中台项目有什么后果?本文尝试给出一个答案。
为什么要做中台?数据中台打通数据孤岛
主流的观点认为，做数据中台是为了打通数据孤岛。在互联网企业确实可以理解， 但是银行对于数据的应用很早就开始了。大行普遍 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 系统，所以说，银行并不是中台战略的追随者，而深感数据孤岛、烟囱式架构之痛的银行人，一直是中台战略的践行者，只是没有把这些尝试体系化、结构化而已。
支持前台快速迭代
前文提到，市场、用户和监管的变化速度，远远快过业务系统迭代的速度，为了抹平这个差异，我们需要让业务系统，尤其是前端面向客户的系统尽量的敏捷。这也是目前业界流行的ldquo;小前台、大中台rdquo;提法的由来。
其实微服务的思想就是将大的系统，拆分为小的应用和服务，高内聚、低耦合， 发布有价值的服务，即可被使用和共享的服务。而高内聚、低耦合也一直是银行设计架构的基本原则。因此，我们可以看到，银行的架构设计、微服务体系、中台架构一脉相承，都是为了共享功能下沉复用，减少重复造轮子的现象。
这带来的好处，就是新建应用的时候，可以通过已有成熟模块的组装，实现快速上线，从而加快业务系统的迭代，真正实现ldquo;小前台rdquo;，更好更快的相应市场、客户和监管的变化。
综上所述，中台建设是银行进行数字化转型的关键举措，势在必行。
中台是什么?
2019 年被称作中台元年，一时间，各种中台概念、各种形式的中台方案如雨后春笋一般层出不穷。目前，中台并没有一个放之四海而皆准的标准定义，根本原因， 在于中台并不是一个标准化的产品，根据每个企业自身的情况，中台的建设方案可能千差万别。
不过，可以达成共识的，是中台的特点，它是企业共享能力、共享数据的组织或平台，并且具备业务属性，能够实现业务价值，有响应的组织架构支撑。
中台的形式也五花八门，除了公认的数据中台、业务中台以外，还有技术中台、研发中台、AI 中台、移动中台、算法中台等等。参照中台的特点，我们认为凡是与业务不直接相关的，都应算作后台，虽然其他中台也是能力的复用，或者间接产生了业务价值，但是为了厘清边界，明确讨论范围，我们将集中就数据中台和业务中台展开论述。
数据中台是什么
上一节我们探讨了做数据中台的原因，由此我们可以给出数据中台的使命，是为了打通数据孤岛、实现业务数据化，让数据更快更好的产生价值。
结合数据中台的使命，我们可以将其分为狭义的数据中台和广义的数据中台。
狭义的数据中台，指的是一套数据应用和工具，包括分布式 ETL、数据资产管理、数据标签管理、数据沙箱、自助分析平台、元数据管理、数据质量管理等等，底层则已现有的数仓、大数据平台等为数据源，为企业提供数据资产管理的能力， 并持续挖掘数据价值，持续提供数据智能服务。
广义的数据中台，则在狭义的数据中台基础之上，包含了顶层数据战略，数据治理体系以及数据管理及运营、数据文化培养和组织架构支撑，是一套持续管理和运营的体系。
可以这么说，狭义的数据中台，是专为达成数据中台的使命而打造，一类是让数据更快的处理、整合、加工，比如分布式 ETL 工具。随着传统数据被大数据平台逐步替代，ETL 工具对于大数据平台的适配也需要与时俱进，支持分布式计算、弹性计算，并且减少开发量。
另一类是让数据更好的产生业务价值，比如数据标签管理，自助分析平台等。数据标签大家都在用，但是真正深度使用的企业都会感觉:建好容易用好难，如果没有一套标签管理系统，标签是否重复加工，标签的使用率、准确性等都无从掌控，业务部门想要针对近期营销活动新建一个标签，还得走开发流程，时效性也难以保证。
数据标签管理系统就是为了解决数据标签的使用问题而建立。自助分析平台则是方便业务人员自助进行数据分析、加工、探索的平台，它与数据沙箱结合，直接将去隐私话的生产数据提供业务人员分析，使数据更快的产生价值， 支撑关键决策。
广义的数据中台，则是辅助狭义数据中台达成使命的机制，虽然看起来都很ldquo;虚rdquo;，但是却是数据中台成功落地的必要保障。
没有数据战略，在推进数据中台建设，甚至建成后的日常运营中，难以沟通协调各部门利益，缺少ldquo;尚方宝剑rdquo;。没有数据治理体系，数据管理无凭无据，无章可循，很容易造成 Garbage In-Garbage Out 的现象。
但是这里必须澄清一点，在银行信息系统这样复杂的环境中，数据质量的问题永远存在。因此，ldquo;等数据治理好了，等数据质量控制好了，我们再开始做数据应用，做数据中台rdquo;，这种想法是不切合实际的，因为不存在数据质量控制好了，数据治理好了的那一天，这是一个持续的过程，好到什么程度算好?谁来决定这个标准?
我们认为，数据质量很重要，需要持续改善，但是不影响数据中台建设， 应该以用促治，在使用场景中有针对性的开展数据质量管理和数据治理。
没有数据管理及运营，数据应用的价值无法持续产出，甚至会出现便宜甚至错误。缺乏数据文化，则会造成数据应用没人会用，没人想用，没人愿意相信数据结论， 没人愿意尝试数据驱动，没人愿意基于数据决策。没有组织架构支撑，则会让数据中台这样跨部门的体系难以推行，最终胎死腹中。
业务中台是什么
同样，业务中台也可分为狭义与广义，狭义的业务中台，指的是由多个共享中心组成的服务整合平台，通过梳理各业务系统共性的功能，在每个中心里将服务拆分、共享。我们建议，可以按风控中心、产品中心、用户中心和旅程中心等维度整合共享，底层的数据能力由数据中台提供。
广义的业务中台则包含了支撑各中心运营的组织架构和体制机制。正如前文提到， 没有组织支撑，中台不过是另一个大烟囱。每个业务中台的子中心，都应有对应 的组织支撑，可以是虚拟的，也可以是实体的，最好由业务+科技+风险+数据的 综合人员构成，小团队作战模式，以产品使用率、稳定性、客户满意度等为 KPI， 为业务中台保驾护航。
风控中心管理全行所有的风控模型，以及对客产品交易、账户层面的动态安全策略，以底层机器学习平台为支撑，共享全行风险管理能力。产品中心管理全行所有渠道的产品，控制购买额度、购买条件，灵活上下架等。
用户中心基于数据中台打通的全行用户信息，建立用户成长体系、权益体系，管理用户标签画像，分析用户行为轨迹，为旅程中心完成客户全渠道一致体验打下基础。
旅程中心以用户视角出发，以用户体验为最终目标，梳理、贯穿各渠道流程，整合、复用各渠道功能，最终达成全渠道客户体验统一。
结语mdash;mdash;中台的边界
了解了中台是什么，最后，我们来看看中台不是什么，或者说，中台的边界在哪里。
首先，中台不是银弹。
没有银弹:没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步
mdash;mdash;《人月神话》
软件工程领域的ldquo;圣经rdquo;《人月神话》早就提出了没有银弹的说法，中台也不例外。不要妄想通过中台，解决企业内部一切的数字化问题。即使是上文提到的广义中台，也仅仅是包含了企业数字化转型中，与数据、业务中台相关的组织和机制，但是仍然无法涵盖一个组织在数字化转型过程中遇到的各种问题。中台与其他新技术体系一样，可以帮助企业降本增效，但是如何选择业务方向，如何团结一心，如何切入市场，如何找到目标用户等等，都是企业在中台之外还需要努力的方向。
其次，中台不是一个可以买来的即插即用产品。
不必为了做中台而做中台，也不必大干快上，一起步就是一个五年大工程。由于中台与企业内部的数据、业务系统高度相关，虽然有相对标准化的产品可以预先研发，但是更多的工作，在于中台与存量系统的对接、优化。
最后，中台不是一个筐，别什么都往里装。
当一个新技术体系难以明确定义时，最常见的现象就是边界模糊，什么都可以放进去。最典型的例子就是ldquo;大数据rdquo;了。虽然有类似ldquo;5Vrdquo;的定义，但是大数据的定义从来没有统一，这也导致现在只要提到数据，都会冠以ldquo;大数据rdquo;之名。实质上，大家所指的绝大多数数据，并非是ldquo;大数据rdquo;，都是ldquo;小数据rdquo;。
概念的模糊，使得炒作时，无数企业挤破头往里冲，也导致行业发生合规风险时， 与ldquo;大数据rdquo;沾边的企业都风声鹤唳，草木皆兵。这种现象，对于行业的发展弊大于利。
因此，我们必须厘清中台的边界:无共享，不中台;无业务，不中台;无组织， 不中台。
没有共享能力、数据的整合，不算中台;没有直接服务于业务，产生业务价值， 不算中台;没有组织支撑，仍然服务于某个部门，不算中台。
行文至此，希望解答了大家心中的疑问。简言之，做了中台不见得就是数字化领军企业，不做中台也不见得就是古典互联网时代的落后作坊。关键是认清自身的数字化现状，拟定数字化目标，制定数字化路径，优选场景，实现价值。中台只是这条道路上，一套切实可行的行动方案。糟糕的公司治理，三天打鱼两天晒网的战略定位，部门银行的组织架构，即时搭建了中台，也徒有其表，如此，中台是砒霜。
坚定的战略，清晰的目标，合理的组织架构，搭配中台，可以使数据更快更好的发挥其价值，业务模块更好的融合，用户体验得以更好的提升，如此，中台是蜜糖。
