券商究竟应如何进行中台建设？岩葶苈

4）中台建设中遇到的问题：一是关联系统不愿重构其产品模块；二是关联系统接口缺失，或接口不开放。对于关联系统不愿意重构改造的情况，可采用数据分发的方式，将中台数据推送到各关联系统。对于关联系统不开放接口的情况，可考虑直接访问其数据库，或采用模拟屏幕操作等技术实现数据同步。

5）几点体会：已有系统数量比较多，而且改造难度比较大的情况下，中台是优化系统架构、推进系统整合和数据共享的手段，是架构重构的实践探索；对各已有系统的改造力度较温和，但仍要依赖于各已有系统的支持配合。在已有系统积极配合改造的情形下，中台也可以退化为某个已有系统的内部组件，行业内也有类似案例。在完全自研、自主可控的情形下，中台应该作为一种以共享服务形式存在的公共组件，独立于上层应用系统。

以下为国联证券首席信息官汪锦岭会上发言全文：

各位同仁，大家上午好，很高兴能与各位新老朋友能够欢聚一堂，聊聊行业的一些热点话题。我讨论分享的是偏技术的话题——中台的建设问题，谈谈我们作为中型券商的一些做法和体会。

在谈中台这个话题之前，我们首先要明确一下到底什么是中台。虽然这几年中台的概念非常热门，各种文章介绍铺天盖地，但大家所说的中台概念差异非常大。我挑了业内三个典型的中台概念的解读，来与各位进行分享。

在一次行业交流上，一位券商介绍他们中台建设的一些体会和实践。以我的理解，他们所说的中台实际上就是可供前台各业务线共享的、由公司统一管理的运营职能。经纪、投行、资管等业务叫前台，运营体系如账户管理、资金收付、数据清分、持仓估计等叫中台。中台建设就是指这些运营职能不能按前台各业务线分别管理，应该在公司层面统一管理，比如账户，每个前台业务的账户管理要统一起来，做一个统一的帐户管理模块。数据清分、资金收付等也统一做管理，这就是中台建设。这种做法对于提高我们行业运营处理的高效性，实现运营的统一化规范化，提升业务服务能力，是非常好的探索，值得我们学习和借鉴。

在另外一位券商领导的专访中，也谈到中台实践。他们所说的中台，是在不影响原有系统稳定性的情况下，开发一个中间平台对接各系统，把各系统衔接起来，实现系统之间的互联互通。文中举了个例子，就是每个公司都有一个非现场开户系统，开户时，客户端可能出现各种情况，由于各种原因可能会发生开户中断，导致客户流失。为此他们做了一个中台，把开户系统与CRM、呼叫中心、短信等连接起来，客户一旦在开户时发生开户中断，这个消息马上就通过中台推到其他各个系统。CRM系统等就可以立刻干预，看看客户出了什么问题，然后帮助客户解决问题，让客户能顺利开户，提升开户成功率，也提高客户体验。这种中台实际上是消息的中间转发平台，优化了系统架构，对于改善客户体验、提升系统运转效率是很好的探索。

第三，一些厂商，尤其是一些大厂现在也在做中台，这些厂商说的中台和前面又不一样。他们的思路是把各个上层的应用系统里的基础性数据和基础性功能抽取出来，做成共享组件给系统共享，他们把这些共享组件叫中台。他说的前台就是一个个上层应用系统，如普通交易、两融、期权、投资者适当性、产品代销等系统。这些系统里面有一些公共的基础性数据，如把客户信息抽出来做客户中心，给各个系统使用；把产品信息抽出来，做产品中心；还有一些其他的公共信息如行情，做行情中心；支付是基础性功能，抽出来做支付中心……最后做很多中心出来，这个叫中台。

我们可以看到，对于中台的概念，行业内的意见领袖们的意见不统一，对中小机构来说也带来了不少困惑。我下面要介绍的中台建设，实际是参照上述厂商对中台的理解，建设一个个基础性公共组件，打造共享中台，实现系统架构优化和资源整合共享。

我们目前开发的基础性公共组件主要有这么几个：一是产品中心，把鼠毛菊属各个系统里代销的产品信息汇聚在一起，做一个系统管理起来，防止多头管理；二是客户中心，因为这些系统里面有各种客户信息，信息比较散乱，我们给公司层面做一个统一的客户号，把客户信息统计在一起，做统一的客户视图；三是互联网运营中心，互联网渠道如APP，微信小程序等，把这些内容管理整合起来，实现多终端统一运营和活动管理。比如，我们搞一个营销推广活动，推广活动的图片、文本、推文位置等，各个渠道都要统一，这样管理起来比较方便。

下面我以产品中心这个公共组件为例，与各位分享一下中台建设的一些实践做法。

为什么要建产品中心？上线前，我们关于产品销售相关的各系统的关系比较混乱。从渠道类系统看，我们有个APP，APP里有个理财模块，可以卖理财产品；网上交易系统也有理财栏目，可以卖基金理财产品；网上营业厅也有理财栏目，也能卖理财，这些都是渠道。此外，官网上还有用来做信息披露的理财栏目。这些系统和各个同业公司都是差不多的。

我们与别的公司有差异的是这些后台系统。我们使用恒生的代销系统也就是多金融平台，这个系统完成了所有客户的申赎交易和支付结算，是比较核心的系统。系统里面也有一个很大的产品模块，维护如产品基本信息、销售参数控制等产品信息。除了这个系统外，我们APP后台里面也有产品模块。在APP上卖的一些产品展示位置需要也做一些维护。我们官网后台也有产品模块，维护产品的信息披露文件。这些产品信息不光在官网上要展示，客户通过APP买产品的时候，也要调出来给客户看一下，所以好多地方都要用到这个产品模块。我们的CRM后台里面也有产品模块，也在维护产品销售参数。这主要是因为恒生系统里的销售参数不太够用，一些个性化的客户需求无法解决。我们还有资讯系统，主要给客户展示公募基金的历史信息。还有一柜通档案系统，用来管理客户买产品的签约合同。

我们可以看到，这个系统架构比较凌乱，也导致一些问题，如产品信息散乱、各自维护、维护以后系统之间有时仍不一致，造成一些不必要的混乱；另外产品管理、销售管理的效率也比较低，不同渠道控制销售参数的地方可能不一样，导致销售同一产品时，在手机或电脑桌面上的控制不太一样，给营业部带来困扰。这些问题导致技术响应业务、业务响应市场速度缓慢，现在又面临财富管理转型，产品销售的业绩考核也比较高，所以业务线呼声很强烈，希望我们解决这些问题。所以我们做了产品中心来解决这个事情。

舶梨榕我们改造之后的系统架构里，最核心的是产品中心。产品中心把产品的各种信息，包括基本信息、销售控制参数、历史净值、信息披露的法律文件等全放在里面统一管理，解决了各系统多头管理、各自为政的问题。图中产品中心旁边是产品销售系统，对销售活动进行管理，如销售交易、支付结算等。另外CRM系统采集产品的销售记录，计算员工和营业部业绩。APP、网上交易、网上营业厅、微信等渠道是直接面向客户提供理财功能。我们还做了统一的渠道接入模块进行总控，由这个总控模块统一访问产品中心和产品销售系统。通过对各销售渠道统一接入把关，保证对各个渠道的销售控制的一致性。我们大概三四个人做了四五个月，把产品中心做上线。上线后解决了之前的问题，整个系统架构比较清晰，另外就在同一个地方维护产品信息，减少了重复操作，也统一了数据。

我再分享一下做这件事的过程中遇到哪些困难和问题，解决办法是什么。一是周边关联系统不愿重构自己的产品模块，这时候的解决办法就是：对于自研系统，要求其进行相应改造；对于外购系统，可采用数据分发的方式，将产品中心的数据推送到关联系统。二是关联系统接口缺失，或接口不开放，这时候的解决办法就是：简单的系统可以直接访问对方数据库，复杂的系统只能采用模拟屏幕操作等技术来实现数据同步。三是关联系统产品数据结构差异大，这时候需要合理进行产品数据建模，保障数据的规范性、模型的扩展性。

最后谈几点体会。像国联证券这样，已有系统数量比较多，而且改造难度比较大的情况下，中台是一种优化系统架构、推进系统整合和数据共享的手段；是一种架构重构的实践探索，是组件化开发思想的实际应用；对各已有系统的改造力度较温和，但仍要依赖于各已有系统的支持配合，最起码要数据共享，最好能提供接口，或者进行配套功能改造。

在已有系统的厂商积极配合改造的情形下，中台也可以退化为某个已有系统的内部组件，行业内也有类似案例。在完全自研、自主可控的理想情形下，中台应该作为一种以共享服务形式存在的公共组件，独立于上层应用系统。这样层次化的系统架构可能会更清楚一些。