中台在社会保险业务中的应用

金定勇，吴 斌，董加志

（1.南京莱斯信息技术股份有限公司，江苏南京 210014；2.南京市六合区人力资源和社会保障局，江苏南京 211500）

0 引言

2015 年以来，阿里巴巴集团等一线互联网企业开始启动中台战略，在业界产生了广泛的影响。在当今互联网时代，社会保险也面临同样的选择，如何快速响应业务的需求，中台建设是否能产生重要价值？

1 社会保险业务发展对中台建设的要求

社会保险信息系统建设从最早的城镇职工养老单险系统发展为城镇职工养老、工伤、生育保险等三险系统，再到城镇职工养老、工伤、生育、失业、医保等五险系统，再到企业五险、居民养老、居民医保、机关事业养老等八险城乡一体化社会保障信息系统。随着我国社会保障体系的不断完善，社会保险服务对象越来越宽泛，从单位职工到城镇居民，再到农村居民，实现城乡人群全覆盖，其社会保险系统也相应进行了多次升级和改造。但大部分还是按照项目进行开发，这导致：（1）系统规模化建设使得部门之间、系统之间和应用之间难以实现有效管理，影响制度有效执行。（2）系统多年不断地进行补充式开发，导致系统内出现了数据库表冗余多、应用程序部署大、系统模块之间关联不清的情况，使得系统基本情况无法得到有效梳理，易造成系统运维的安全隐患。（3）系统过于庞大，通过人为的管理易造成工作盲点，导致系统发展的无序和不可控制，无法对社会保险有形的技术资产和无形的知识产权形成可持续性发展及保护。

阿里巴巴集团“小前台、大中台”架构体系［1］对社会保险行业架构转型有一定借鉴意义，但两者又存在较大差别。一方面，电商企业不同业务单元（如淘宝、天猫、1688）在业务模式、业务流程等方面有很大的相似性，容易形成可复用的组件和单元，但社会保险的业务线相对复杂，政策性强、涉及面广、涉及的险种多，人群多样，参保、基金征缴、个人账户、基金支付、财务管理等业务条线的业务模式差异巨大，从众多差异巨大的业务中抽象出可供复用的业务组件并不容易。另一方面，阿里转型成功不仅是技术因素，而且在组织架构上也做了一定调整。其将“共享业务事业部”的重要性提升到整个集团层面，各前台业务单元必须对接“共享业务事业部”负责的业务中台，才能实现各单元间的互联互通和信息共享，这极大地增强了“共享业务事业部”的话语权和重要性，使其能够在业务发展过程不断将集团内各前端业务单元的功能沉淀到业务中台，形成了集团内共享共用的业务和技术能力。

2 社会保险中台建设

2.1 社会保险业务线分析

通过对社会保险业务的分析，可以把社会保险多个核心业务中的公共的、通用的业务以服务的形式进行沉淀。整个社会保险的核心业务能力均建立在一套的共享服务体系之上。下面结合行业趋势、类似项目的比较以及自身的经验，对核心业务的场景进行分析，便于业务中台抽象、包装和整合后台资源，转化为便于前台使用的可用、可共享的核心能力。

劳动和社会保险的所有信息化业务均可归入以下6条基线，分别是资源线、参保线、征缴线、支付线、财务线和管理线。社会保险业务共享建设原理如图1所示。

（1）资源线，包含了以人的一生为主线，记录从出生到死亡的整个生命历程。以单位信息库和个人信息库为中心，覆盖各项劳动保障业务，实现“统一入口、统一标准、统一管理、分工维护、全程记录、完全共享”的劳动保障基础资源数据库；通过业务分析、整合和重构，沉淀为资源中心。

（2）参保线，涵盖了自然人的各种业务状态的关联，形成了基本信息与业务信息互动过程，同时也对参保人的所属单位进行关联，包括个人账户（包括养老和医保）和缴费信息管理；通过业务分析、整合和重构，沉淀为参保中心和险种中心。

图1 社会保险业务共享建设思路

（3）征缴线，涵盖参保单位和参保人的社会保险费申报核定、社会保险费结算和基金征集、社会保险费补缴以及社会保险关系转移等业务；通过业务分析、整合和重构，沉淀为征缴中心、个人账户中心和异地业务中心。

（4）支付线，涵盖参保人所参加的养老、医疗、工伤、生育和失业等险种的待遇计算和支付以及异地医疗保险的支付等；通过业务分析、整合和重构，沉淀为养老、工伤、失业待遇中心、待遇支付中心和医保（生育）支付中心。

征缴线和支付线通过业务分析、整合和重构，沉淀为结算中心。

（5）财务线，涵盖基金征缴财务和基金支付财务的管理，实现基金财务管理的统一性和规范性。通过业务财务一体化衔接，实现财务和业务数据间及时、准确、完整的对账；通过业务分析、整合和重构，沉淀为财务中心。

（6）管理线，涵盖劳动和社会保险整个业务办理过程，包括业务协同、基金监管等内容；通过业务分析、整合和重构，沉淀为政策中心、用户中心和电子档案中心。

2.2 社会保险的“薄前台、厚中台、强后台”IT架构体系

经过社会保险业务线分析，将社会保险业务间可共享的业务能力抽取出来，形成不同的“业务中心”，业务中台具有高内聚、低耦合特点，拥有相对独立的数据资源，有独立运营能力，可独立部署提供业务服务，可通过沉淀支撑上层应用系统实现快速迭代和创新；通过不断的自我完善实现业务高效共享和复用，从而解决系统扩展能力差、业务功能重复建、系统稳定性差、无法支撑高并发等问题。社会保险的“薄前台、厚中台、强后台”IT架构体系［2］如图2所示。

图2中，最底层的部分是基础实施层和应用支撑层；中台层，就是各自业务的核心抽象以及沉淀，包含了多个业务中心，是“厚平台”的真实体现，为社会保险各种前端业务提供最为专业、稳定的业务服务；数据中台涵盖了数据资产、数据治理、数据模型、数据服务等多个层次的体系化建设；最上面就是中台支撑的各自的垂直业务线。架构提供能力开发平台与第三方系统进行对接。

3 中台服务给社会保险业务服务带来新的变化

（1）业务中台为社会保险业务的快速创新和业务试错提供一个坚实的基础［3］。

利用已建设好的社会保险业务中心服务，在投入少的情况下，快速收获更多的结果，解决传统做法中，一定需要申报预算和立项来落实业务创新，还要承受项目可能失败的风险。如在已有城镇职工养老保险系统后，由于政策的要求，现在要开发农村失地农民养老保险系统，通常做法立项、招标，当作一个新项目来做，运行后，根据实际情况，还要不断地完善和调整，周期长，不能快速响应用户的要求。如果打造了很好的业务中台，即养老支付中心，就可以让基于中台提供的核心服务在很短的时间内就能建设农村失地农民养老保险系统，根据业务办理情况快捷调整，试错的成本非常低。

图2 社会保险的“薄前台、厚中台、强后台”IT架构体系

（2）业务中台提高多部门协作效率、服务对象办事简便、业务管理成本下降。

社会保险业务部门根据业务条线，通过业务中台提供的服务进行编排，助力业务的快速响应和创新。如在业务经办窗口实现一站式业务办理，实现诸如单位和个人信息管理、缴费基数申报、退休人员信息申报、工伤人员信息申报、生育人员信息申报、失业人员信息申报、医保报销、异地业务办理、电子档案管理、公共服务等业务功能，通过协同办公实现多部门协作，各经办部门只要审核自己的业务信息即可。达到高频事项实现“最多跑一次”的要求。

对参保单位经办人员来说，社会保险部门可以通过业务中台，提供适合的业务功能，如参保人员信息登记、缴费基数申报、退休人员认定、工伤人员认定、生育人员认定、电子档案管理等功能，不用到经办窗口，可以直接在办公室实现业务办理，同时上传相关电子档案信息。社会保险部门只要审核就可。提高了办事人员效率，真正实现“群众少跑腿，数据多跑路”，社会保险部门通过信用评价功能对参保单位经办人员提供的信息进行信用打分，防止虚报和假报。

对参保个人来说，除了通过社会保险部门提供的日常服务平台获取服务外，还可以根据数据中台提供的服务目录进行信息订阅，定期推送消息到参保人员的手机上，另外，参保人员还可以根据服务目录定制自己的比较关心的信息。

4 结语

社会保险业务随着我国社会的发展是在不断改进和完善，导致了业务得不到沉淀和持续发展，从而造成服务不能真正成为可重用的组件，不能适应新的需求。同时，业务中台的服务数量和业务覆盖范围越来越大，应用和业务架构越分越细，服务越来越专业化，应用不知道有哪些下游业务在使用我的服务，当服务要升级或者变更时，与依赖业务方沟通要花费大量的时间。

4.1 服务需要滋养

服务需要不停地滋养，只有在滋养中才能从最初仅提供单薄业务功能的服务，逐步成长为全功能社会保险业最宝贵的IT资产，不断满足社会的需求［3］。服务能力的沉淀和价值的体现是完全成正比的，需要一个长期、持续的过程，在业务发展过程中不断打造这些服务，为这些服务能够变得更加专业和稳定带来急需的需求养分。

4.2 服务需要治理

服务分散在各种底层基础的分布式基础服务上，这些服务各自都有自己的后台管理平台去实现管理。一是缺乏对这种分布式服务层面各种服务能力的抽象模型；二是缺乏从整体角度把各种分布式服务能力管理起来的产品。可通过服务治理工具如阿里巴巴集团的共享服务平台（Shared Plat form as Service，SPAS）来解决，目标是对服务更好地进行治理和共享，也可以看作是服务能力在线化、数据化的过程。