京东保险供应链的前世今生

原创京东保险李赟京东技术

2025年01月10日 12:00

跨入2025年，回顾牵头保险产品供应链系统建设的四个年头，4年间经历的林林总总，记录下这些年的发展历程，也为2025年开个头。

前文【京东保险-技术平台部-平台研发部】一群AI卖保险的程序员提到，供应链研发就是负责从保险公司进货，进货快是最核心的价值。区别于实体商品，保险产品作为一种虚拟商品，整个交易过程都需要与保险公司进行实时的交互，严格按照保险公司对产品的各项细节要求进行展示、填单、投保、核保、保全、理赔。但如果每个业务系统都完成这一系列复杂的工作，整体效率会非常低下。所以，保险供应链研发负责把各家保险公司的差异进行标准化，对内部各交易场景，我们就是一家标准保险公司。对外部保险公司，我们代表京东保险制定接口标准，并完成所有保险公司之间差异的兼容。供应链系统的建设从零基础，到保险公司覆盖率第一的技术平台，经历了一个漫长且艰辛的历程...…

第一阶段：2021年初，抽丝剥茧，定位问题

一、初识“接品”，缘起到入局

入职京东的第一天，我的工位旁边坐着一位负责接品的研发小姐姐，人称霞姐。霞姐工位总是熙熙攘攘，人头攒动，来来往往络绎不绝。我好奇地问了身边另一位同事，霞姐负责什么工作。带我熟悉环境的同事告诉我，“霞姐负责接品”。“接品”这个两个字就此走进了我的职业生涯，至于什么是接品，也跟同事简单请教了一下。就是经纪或代理公司把想要销售的保险产品，从保险公司对接过来，在京东的系统上线之后，才可以销售。似乎并不复杂，“好在”我当时并不负责这个工作，至于“千万别碰”只是留下了一丝敬畏和好奇。

时间很快来到2020年的10月份，我开始负责质量效能工作，主要包括测试团队和项目管理的职责，开始正式参与到“接品”的工作中。

二、入局容易、破局太难

成为接品工作中的一环之后，最明显的体感就是琐碎，产品对接是所有经代业务开展的最基本前提，属于基本工作中的基本工作，所有业务部门都会提出需求，都说着急是常态。也借机向同行了解了一下各家接品的主要做法，发现这是一个行业普遍存在的痛点。最常见的问题如下：

1. 信息爆炸

保险中介平台往往需要同时对接多家保险公司，信息的碎片化和沟通渠道的多样性使得工作极具挑战性。团队成员需要处理大量的沟通群和邮件，信息更新频繁，导致工作效率低下。信息的爆炸并不仅限于外部，内部参与人数同样较多，每一款产品在上线过程中都会经过多个岗位，同时并行推进5个产品，就会有50个不同的状态，这些状态的变更难以高效地管理。

2. 工作压力大

接品工作的总体负责人是一名产品经理，作为负责接品的牵头人，这个人需要统筹所有的信息和工作状态。日常需要不停地在几十个群里进行快速沟通。并行推进的接品工作哪个能更早进入排期，需要在会上进行多角度的争取。最终问题的焦点，聚焦到了“什么时候可以不分优先级，想接尽接”就好了。

3. 优先级难题

在资源有限的情况下，如何合理分配优先级成为一大难题。各方利益的冲突和优先级的不确定性在行业中普遍存在，这需要通过更为科学的方法来进行管理和调配。再加上各级领导在商务沟通过程中会有高优先级需求加入，当时的优先级对于技术团队类似于电车难题。

4. 流程复杂

一个正常流转状态下的保险产品，从商务对接到上架可销售，一共需要大约10余个环节，每个主环节点中还会有分支环节，并且其中每个节点执行多次也是很正常的。

三、破局有道，道阻且长

读到这里，不难发现，接品工作需要一套标准化的流程机制去拉通各个方面的信息，通过一套系统进行流转。明确好各方的职责边界和上下游协同机制，就可以有效改善当时的状态。这个所谓的方法，其实每个参与过这项工作的同事都可以快速得出这个“解决方案”，但这个机制需要规范几十个人的行为标准，系统化的周期较长。好在经过2个多月的沉浸式接品，问题都明确定位出来了，当年的解决方案如下：

PS：时隔4年再看当年汇报的PPT，解决方案写了如此务虚的标题，自觉非常雷人。再往深入想，其实更主要的是当时对于能否彻底解决问题的信心不足，口号喊得响亮一点儿，除了具有汇报效果之外，也是给自己打气。

现在方法有了，如何解决没有系统的问题，咨询了身边很多同事，“咱公司有没有一个可以自由配置表单和审批流程的系统？无所谓长什么样，能流转就行”。在疫情居家办公的一天，在内网搜到了当时刚上线不久的XBP系统。果断联系到对方的运营同学，开通了账号，配置了第一个接品流程，可用，大喜过望。第一阶段的基本问题，解决了。下图为XBP系统早期截图

自2021年1月将XBP引入保险业务流程，截止发稿近4年时间，供应链建设也伴随了XBP系统的持续迭代。XBP的易用程度之高，导致后期想推动业务团队转回保险自有系统也着实费了一段时间。

第二阶段：2022年，快一点！统一标准，全面下沉

有了XBP的助力和各部门对标准流程的逐渐适应，2021~2022年接品工作进入了新的阶段。在技术层面统一标准，让各业务线的交易系统以及各保险公司的IT团队，可以通过统一的标准进行开发，降低标准不同造成的研发资源浪费，缩短产品对接周期，是2022年的主要工作目标。

自京东保险经代业务成立以来，系统的归属、组织架构和人员经历了多个发展阶段，在2021年初，各业务系统直接对接保险公司的情况仍然存在，自然形成了多套差异化较大的对接标准。要推动统一标准，对内对外都是一项大工程，好在保险产研团队快速达成了共识，优先在职责上统一由一个研发团队与保险公司进行对接，就是现在的保险供应链研发部（当时称为“保库团队”，还不是一个独立的部门）。但凡事都有两面，问题紧跟着就来了。统一对接就最容易成为瓶颈，“接品进度卡在了供应链研发”的声音似乎每个月都会有，但人力不足恐惧症，肯定不是通过持续加人来解决的。

既然2021年初的标题第一句就是“标准化”，势必要把标准落实到位，团队顶住压力，一边交付产品，一边持续推进标准接口的改良和推广应用，熬过了沉寂又扎实的一年。截止2022年底，内部所有交易系统在投保、退保、回执、回访等9个能力域实现了统一标准。并对外部保险公司更新并切换为统一的标准接口，为2023年推行开放平台奠定了基础。整个2022年，供应链团队完成了100+款保险产品的对接，全部以京东保准接口进行对接，随着标准的落实，供应链的对接周期可以维持在5天左右，不再成为卡点。但新的挑战，也在2022年浮出了水面，虽然伤害性不大，污辱性确极强。

四、线下寿险，它来了

自2021年7月份以来，随着组织架构的调整，保代业务的接品需求也由供应链系统开始承接。我们遇到的线下长期寿险的产品对接需求，第一家，就是寿险公司A。这是一段从确定需求，到系统上线经历了9个月的可怕经历，超过了所有人的预期。

在寿险公司A之前，供应链对接的产品都是在互联网上销售的产品，以京东生态场景为主。各保险公司同意按京东接口标准进行开发。但进入线下长险，在没有绝对业绩支撑之前，是必须按保险公司的标准进行开发的，且不论是开发联调节奏、还是加密方案、拉通专线等等方面，都需要按保险公司的要求来。其中必须走专线这一项需求，就是在产品上线前一周提出的必要条件，光这一项就增加了2个月的周期。

寿险公司A的这一次对接，开启了以保险公司接口为标准进行对接的新时代，为2024年的“保链天下”专项埋下了伏笔。说它伤害不大，是因为当初业务发展并不强依赖保险公司的API对接。说它污辱性确极强，是因为在互联网行业，9个月什么都可能被颠覆。

第三阶段：2023年，更快一点！！开放平台，在线联调

进入2023年，随着供应链接口标准化的程度越来越高，如何能更快一点，投入的人力更少一点，成为了2023年的主旋律。恰逢2023年业务部门提出了保险品牌营业厅的规划，单这一个业务场景就需要在当年至少完成180款产品的对接上线，远超过2022年全年的总量，按当时的对接速度和人力投入是不可能完成的任务。把更多的工作在线上自动化完成，是主要路径。2022年完成的标准化建设，实现了统一标准，但缺少对外的高效沟通协作机制，研发人员还是需要在微信群里回复问题，与保险公司和内部各业务系统进行联调，沟通的时间大于写代码的时间。

2023年，接品开放平台正式投入运营，完成了所有接口从文档到在线联调、到保险公司接口状态监控的全面线上化，保险公司不再需要依赖京东的研发查询日志才能进行联调，在开放平台就可以自主完成任意产品的报文生成和联调。第一次实现了产品并行对接数量和研发人力数量的解耦。

2023年全年，供应链完成了260+款产品的对接，但同时投入的接品产研人力减少了50%，人均接品效能对比2022年提升了4倍。然而，继2022年折戟寿险公司A之后，2023年我们迎来了寿险公司B，还是熟悉的配方，还是熟悉的味道。

五、线下寿险，它又双叒来了

在2022年寿险公司A的API对接投入了过多的资源，周期太长，佐证了该模式不适用于短期的业绩目标场景，更适合于需要建立长期合作的保险公司。2023年7月，业务部门和位于上海的寿险公司B达成了合作协议。有了上一次寿险公司A的对接教训，团队做好充分的准备，紧盯保险公司的进度，过程中有任何延迟随时升级。为此安排了专人开日清日节会，专程出差去上海和LJZGT的高管进行了沟通，双方在沟通效率上把能排除的风险点都排除了。最终，从产研介入到产品上架销售，一共花了3个月零8天的自然日周期。事后整个团队开复盘会，详细梳理了这3个月过程中发生的每一件事，发现在当前模式下不进行彻底变革，极限周期也需要2个月左右。因为过程中重度依赖保险公司的节奏和时间，这在2024年与另外两家寿险公司的对接中，也得到了印证。面对这个局面，如何再次破局，成为了新的挑战。

第四阶段：2024年，再快一点！！！保链天下，行业第一

经历过多家寿险公司的对接之后，我们意识到，不改变思路寻求变革的话，以保险公司API为标准对接一家线下寿险公司，并完成第一款产品的上架销售，极限效率是2个月。这在瞬息万变的市场中，是无法满足要求的。想要再快一点，除非我们把国内所有的保险公司都对接一遍，不论它是否跟京东开展合作，只要它还存在，我们就把它接上。市场上哪个保险公司出了新产品、市场爆款，只要商务层面能达成合作，技术团队都可以以最快的速度上架。好在这个世界上的保险公司是有限的，范围缩小到中国大陆地区，一共有180家保险处于运营状态。不过想的倒是挺好，实现起来困难重重。

1. 外部挑战

刚开始，项目组面临着来自各个方面的质疑。经常会有人问：“我们为什么要投入这么多研发资源来做这件事？现在又没有业务需求，不创造价值，什么时候能创造价值不确定，这不是浪费资源吗？”。有这种质疑很正常，在业务主导的需求交付逻辑下，这么思考问题完全正确。但亲历者都知道，业务主导模式下的交付效率已经不可能再有较大的突破了。面对这种质疑，由衷感谢领导给予的认可和支持。市场的变化是瞬息万变的，只有在全行业处于产品供给效率的第一名，才有可能持续助力业务赢得市场先机。

2. 自我怀疑

除了来自外部的质疑，项目组内部也存在自我怀疑。“保险公司的文档，需要我们去想办法获取吗？我们又不认识保险公司的人，这样对方会不会觉得很排斥。这是我们的本职工作的内容吗？如果我们拿到错误的文档，是不是会白白浪费时间，将来还会推倒重来？”。为了打消大伙的顾虑，项目组组织了一次研讨会，让每个人把最真实的想法都说出来，一项一项进行了解答。虽然我也并不是对每个问题都有100%的把握，但最终会议的落脚点，落在了只做第一！最终说服大伙从内心接受这一挑战的，是在结尾说了一段：“保险供应链做了这么多年，在不断被挑战和质疑的过程中优化迭代。但还没有扎实地证明过，我们已经做到了行业第一。组织给我们一次机会，在不影响业务需求交付，不增加人力投入的情况下，给我们半年的时间做到行业第一。这是一次千载难逢的机会！” 。2024年5月29日，团队打消疑虑，统一思想，决定跳出岗位职责，一切以结果为导向。

图片放大来看，当天的讨论还是非常充分和坦诚的

3. 明确目标

在半年时间内完成所有保险公司的接口对接，在理论上就是不可能实现的。部分保险公司是没有接口的，另有一部分保险公司并不开展经代业务，例如大部分头部银行系的保险公司，仅开展银保渠道业务。如何确定一个明确可量化，并且可以做到行业第一的目标是第一步。好在，监管的明文要求帮了我们这个忙。按监管要求，每一家保险中介机构，都必须在官方网站上公示自己合作的保险公司清单。于是我们迅速浏览了国内所有知名保险中介机构的的官网，整理出了每个中介机构的合作保司清单，一家一家核对，哪怕它的官网披露的只是合作，并未进行API对接，我们也都算在内。至此，明确了项目的目标：“在2024年底，成为中国大陆地区，保险公司覆盖率第一的中介平台”，要实现累计覆盖107家保险公司的接口，成为行业第一的技术平台。

4. 4DX高效执行

一家一家保险公司的文档，从阅读到写代码，看似差不多，实际又千差万别。每一名有技术追求的同事都难以长期坚持这一枯燥繁琐的工作。项目历时半年左右，如何保证能拿到最终的结果，项目组利用公司培训给到的4DX方法，设计了有趣的过程PK游戏。以积分的方式鼓励团队成员在过程中进行比赛。一个文档20分，一个接口设计5分，一个接口实现5分，一个测试用例3分。"保链天下"的英雄榜每周都公示在团队内部，过程中兄弟们互相鼓励，以必赢的心态接通一家一家的保险公司。

“保链天下”这个项目名字来源于团队内部的一次投票，每人提一个名字，每人有3票，现场投票。我首先给出了“保连登”这个名字，起初担心我在现场参与投票，容易带节奏。可喜的是，张臣臣同学提名的“保链天下”获得了最多的票数，项目组的名字就此确定了。

5. 文档你在哪里？

保险公司的接口文档，属于半开放式信息，互联网程度较高的保险公司会建设开放平台系统，接口文档是开放的在线文档。没有建设完成开放平台的保险公司，文档仍处于离线维护状态。在有商务合作的情况下，通常由商务同事进行索取。所以最常规的做法，是通过业务侧在有商务合作的情况下，由商务同事去跟保险公司的商务对接人索取。但在该模式下，常常会陷入“我不想跟你合作，就不给你文档”的尴尬状态。

为了解决这一难题，项目组成员打开思路，从一度人脉找到三度人脉，从熟人圈子到陌生拜访。他们从业务线到技术线，从保险公司到中介公司，想尽一切办法解决问题。为此，团队还建立了保险公司文档墙，逐一分析保险公司的多个维度，从业务合作情况到所在地区，从股东背景到公司评级，从信息披露到微信群搜索联系人。

6. 技术优化

工程结构优化：搞到文档之后的第一个问题，就是解决多人快速开发接口代码的协作效率问题。为此团队在动手处理新文档前，优先升级了所有相关的工程结构，将所有与具体保险公司无关的代码按领域分别归拢。所有保险公司强相关的代码统一放在vendors包内。此后在组织分工上，每人负责一个保险公司的接口开发，避免相互影响造成冲突，也实现了接口风格相近的保险公司代码可以快速复制，在多个细节处不断追求工程效率上的最大化。

大模型助力：各家保险公司的接口虽然不一样，但需要提供的服务分类基本相同，文档形式分为在线URL，word、excel、pdf四种，大模型可以提供快速分析和代码生成的能力。基于大模型能力开发了智能接口适配器（2024京东黑客马拉松大赛项目），设计1家保险公司只需要2人/天，效率提升了50%。

7. 结果第一

经过半年多的努力，京东保险的供应链技术团队覆盖了中国大陆地区108家保险公司。对比业内的友商，京东保供应链平台，在保险公司接口覆盖数量排名全国第一。

覆盖率的绝对第一，带来的是供应链效率的提升。2024年全年，供应链在满足全年接品需求的基础上，额外完成保险公司覆盖度专项、保险代理业务数据回传专项等工作。自此，接品开放平台正式升级为：“999接品平台”，以999命名，代表新的目标：90家寿险公司、90家财险公司、9大能力域全面覆盖，是终点也是起点。

项目成果：

1.业务接品效率

1）前置开发，在商务环节提前确认产品流程与接口开发，供应链效率提升80%

2）业务线准备好后，可直接发起与保司联调，整体接品效率提升约50%

3）接口覆盖市面上绝大部分保司，有新品对接时可以做到来之即调，加快业务上品过程

4）改变单一的对接标准，支持业务按京东+保司的标准进行产品对接，缩短80%以上的开发时间。

2.保司路由

1）扩展性：添加新保司，新方法对原有逻辑无侵入，支持多人并行开发

2）可维护性：保司、接口映射独立变化，无耦合

3）颗粒度细：支持到保司方法维度

3.数据回传标准化

1）扩充经代对接渠道，便于修正保代历史保单错误数据与新保司对接增量数据

2）扩充对接保司数据覆盖度，更加灵活的扩充支持不同保司&不同类型数据

3）规范化现有数据回传流程，新对接保司数据回传时预计至少提效30%

4.保司代码生成器

1）统一代码风格

2）提升开发效率

3）降低专项开发门槛

5.测试效能提升

1）产品样例：提升保司接品建品时效，对接保司可使用本次产品库创建的产品样例，减少配品时间

2）测试案例：共新增测试案例2100+条，覆盖了所有新对接的接口，为自动化验证奠定了基础

3）效能提升：商务对接不需要新增测试用例，正式对接保司时可直接使用已有接口进行冒烟测试，提效40%

6.数字化的保险公司接入状态系统：形成了数字化的保险公司接入状态系统，一目了然所有保险公司的对接情况、包括对接形式、产品清单、保费规模、合同清单，形成了有价值的数据资产。

写在最后：做实事、有价值的事、长期的事

"保链天下"项目的价值，不仅体现在业务成果上，更体现在对“只做第一”精神的落实，面对挑战时的勇气、创新和坚持。项目结束，最深刻的感受是感恩，感恩能在京东坚持做实事、有价值的事、长期的事。

期待在2025年，可以创造更大的价值！

祝大伙新年快乐🎁🎁🎁

推荐阅读

【京东保险-技术平台部-平台研发部】一群AI卖保险的程序员

利用大模型服务一线小哥的探索与实践

浅谈API错误码设计

Daniel H. Wagner Prize | 京东供应链创新与实践：应用数据驱动的库存选品和调拨算法提升履约效率

关注我们

供应链2

保险1

京东保险技术1

继续滑动看下一个