解锁保险新世界-带你走进保险基本法

京东云开发者
• 阅读 240

作者:京东保险 薛艳凯

一、 引言

提到京东,大多数人的第一印象便是那座繁华的购物商城,便捷的购物体验深入人心。但在这片商业沃土上,还孕育着一群特殊的京东人——他们不卖“商品”,却以传递保障、守护幸福为己任,那就是京东保险人。我所在的部门是保代业务研发部,专注于为保险代理人提供全方位的技术与业务支持,我们致力于持续优化服务,为代理人创造更多机遇,共同推动保险行业的繁荣与进步。

代理人是客户与公司间不可或缺的信任桥梁,其角色在业务环境的多变与挑战中显得尤为重要。为了维护这一信任桥梁的稳固,确保业务运营的有序与高效,规章制度的建立成为了至关重要的任务。正是基于这样的需求,基本法应运而生,它不仅是一套管理、薪酬体系,更是引导与规范行业运作的智慧结晶。基本法如同基石,稳固地支撑着保险代理业务的健康发展,确保每位代理人都能在明确的框架内发挥潜能,并得到丰厚的佣金奖励。

为提升代理人和内勤的服务效率,需要搭建一套智能化、自动化、个性化的系统架构来实现业务流程的优化和创新,同时可以快速响应市场变化、精准评估风险。而现有的架构已不满足当前环境的需要,且系统问题频出,不仅给业务团队带来了沉重的负担,也严重影响了公司的运营效率和客户信任。面对这一问题,我们深刻认识到重构系统的紧迫性和必要性。接下来就让我们共同走进基本法系统的蜕变之路吧。

二、 基本法介绍

保险基本法,是针对保险营销员(包括代理人和从业人员)的日常基础管理规定,而非统一的法律条文。这些规定详细覆盖了展业、晋升、奖惩以及利益分配等各方面,是保险公司推动其营销队伍发展的核心工具。在京东保代业务中保险基本法主要服务于公司的外勤业务人员--代理人,通过设定明确的规则和标准,来指导代理人的职业发展、业绩考核以及薪酬分配。这不仅关乎代理人的收入和发展,更直接影响到保代业务的稳定和市场竞争力。

2.1基本法核心内容

日常管理: 包括代理人的签约、异动、解约等日常行为规范,同时提供员工培训,确保队伍的稳定性和专业性。

薪酬与福利: 明确了薪酬的计算方式,包括直佣、间佣、非现金奖励等,同时涵盖了员工福利,如养老金等。

业绩考核: 代理人从初级业务员到营业区总监,每一阶段都有明确的业绩要求和相应的激励措施,设定了清晰的晋升路径。从业务达成率、继续率、团队指标等多个维度进行考核,确保代理人的工作质量。

2.2 系统业务链路流程

 解锁保险新世界-带你走进保险基本法 

三、基本法面临的挑战

3.1 系统复杂性

数据处理复杂性:随着业务规模的扩大,需要处理大量的业务数据,包括客户信息、保单信息、业绩数据等。由于数据的多样性和复杂性,系统建设面临着巨大的挑战。

系统定制化需求:基本法现存在三套版本,共涉及36个佣金项、17个职级,后续还会有新增基本法的要求。三套基本法彼此存在较大差异,这要求系统开发团队不仅要具备深厚的保险业务知识,还要具备强大的系统定制能力,以满足业务团队对不同版本基本法的特定需求。

政策与法规变动:保险行业政策法规频繁变动,且受到严格的监管。为适应政策变化,及时更新相应基本法规则,确保基本法的合规性,系统必须具备良好的灵活性和可扩展性。

3.2 业务复杂性

产品种类多样化:保险公司提供的产品种类繁多,包括寿险、财险、车险等。每种产品都有其独特的保险条款和费率结构,这就对基本法的制定和执行提出了更高的要求。

销售渠道多样化:保代业务通过多种渠道销售产品,包括代理人线下渠道、网销渠道等。不同渠道的销售模式和客户需求各不相同,这就要求基本法能够灵活应对各种销售场景。

风险管理:保险业务本身就存在较高的风险性,包括信用风险、市场风险、操作风险等。基本法需要在促进业务发展的同时,加强风险管理,确保公司的稳健运营。

四、基本法系统蜕变

4.1 系统全场景架构

 解锁保险新世界-带你走进保险基本法



4.2 系统重构对比

 解锁保险新世界-带你走进保险基本法



重构前 重构后
可读性 代码高耦合、重复、混乱,难以理解和修改 代码低耦合、消除重复、逻辑清晰 复杂度降低,便于理解
系统灵活性 系统模块化程度低,不利于维护和扩展 模块化设计、易于维护和扩展‌
可靠性 0% 99.99%
安全性 错误处理机制缺失 自动复核、链路跟踪
性能 依赖实时数据,存在不必要的资源消耗,系统响应时间长、吞吐量低,执行时长6小时 指标预加载、引入drools规则引擎,响应时间短,执行时长30分钟

五、系统关键破局点深度介绍

5.1模块化解耦,明确职责划分

组件化设计: 组件化设计是现代软件架构的核心策略,将复杂系统细分为多个独立、自治的组件,每个组件专注于单一业务领域(如基础规则、业绩奖励、职位级别管理、绩效评估、团队协作等),极大地提升了系统的可维护性、可扩展性和复用性。这些组件内部封装了详尽的业务逻辑、精细的数据模型及标准化的服务接口,确保了组件间的低耦合与高内聚。

可配置化:赋予了系统极高的灵活性,允许通过直观的配置界面调整组件的行为与属性,无需修改代码即可快速响应业务需求变化。这一特性极大简化了基本法规则的定制流程,降低了运维成本。

 解锁保险新世界-带你走进保险基本法 

自由组合: 用户能够像搭建积木一样,根据具体场景灵活选择并组合不同组件的版本,快速构建出符合个性化需求的基本法,极大缩短了基本法的落地时间,满足了市场多样化的需求。



解锁保险新世界-带你走进保险基本法 

5.2引入规则引擎

针对基本法佣金和考核规则多样性,引入了drools规则引擎作为解决方案。通过声明性语言DRL(Drools Rule Language)极大地简化了规则的描述过程,使得业务逻辑更加直观易懂,同时也显著提升了规则编写的灵活性和效率。

规则与代码解耦:通过将业务规则以脚本形式存储在文件中,实现了规则与业务代码的解耦,便于规则的修改和管理。

抽取通用指标并预加载:识别并提取佣金计算和绩效考核中的通用指标,通过数据预加载机制,减少实时计算的数据访问压力。

规则配置化:

可视化配置界面:提供友好的页面视图,将抽离出的指标(FYC、RYC、R13等)、条件符号(如大于、小于、等于等)、算法符号(如加、减、乘、除等)、逻辑符号(如或、且等)作为可选项呈现给业务或研发人员。用户只需通过选择的方式,即可轻松组合出所需的业务规则,无需深入了解DRL脚本的语法细节。

自动生成DRL脚本:在用户完成规则配置后,系统将自动根据用户的配置选项生成相应的DRL脚本。这一功能不仅大大减少了研发人员的编码工作量,还确保了规则配置的准确性和一致性,有效避免了因人为错误导致的规则执行问题。

直观读取规则:通过页面视图展示的规则配置结果,用户可以清晰地看到每一条规则的构成和逻辑关系,无需阅读复杂的DRL脚本即可理解规则的含义。这种直观性不仅降低了配置人员的学习成本,还提高了规则审核和验证的效率。

 解锁保险新世界-带你走进保险基本法 

5.3多维度执行 + 数据版本隔离机制

基本法可以拆解到基本法版本、业务团队的不同维度执行计算任务,也可以将团队、佣金、考核组件单独执行,相较于之前架构更灵活高效。同时计算结果数据采取数据版本隔离,可以支持任务重复执行,并进行多个版本的数据比对,为佣金与考核预测提供坚实的技术支撑。佣金预测让代理人能够实时掌握任务进度,包括已完成的出单量、已获得的佣金收入、当前佣金与下一个佣金档位之间的差距等关键信息。这些信息可以让代理人认识到自己的提升空间,激发挑战欲望,提升工作积极性,为争取达到更高的佣金档位而努力。

 解锁保险新世界-带你走进保险基本法 

该技术实现不仅为佣金与考核的精准预测铺设了技术快车道,更为基本法制定者赋予了前所未有的灵活性。在基本法制定过程中,可轻松切换不同规则进行组合,即时验证方案可行性,有效降低了试错成本,缩短了决策周期。对于新基本法方案的推行,通过数据驱动的验证与优化,确保新方案既符合市场趋势,又贴合团队实际。

5.4完善研发核对机制

5.4.1数据核对

为确保本月对账手续费的佣金核算准确无误,我们在业务审核前增加了核对流程。基于手续费预设比例精准计算出应付佣金的合理区间,系统自动化地将直接佣金(直佣)、间接佣金(间佣)及其他各类佣金项进行汇总,通过比对汇总结果与预设佣金区间,确保所有佣金支出均严格控制在合理范围内,有效避免了人为错误。既保障了代理人的应得利益,也维护了公司的财务健康。此优化机制不仅提升了工作效率,还显著增强了数据处理的准确性和可靠性。

5.4.2 多维度业务数据分析

接入BI报表系统,实现了数据的多维度可视化分析,为数据验证与洞察开辟了新路径。不仅深化了对数据复杂性的理解,还显著增强了数据的可解释性和可信度。通过拖拽式界面轻松构建图表与仪表板,能够直观展现数据在不同维度下的变化趋势与关联关系,从而快速识别异常值,进一步验证数据的准确性。此外,多维度的视角还促进了跨部门间的数据共享与协作,共同挖掘数据背后的商业价值,为企业决策提供坚实的数据支撑。



解锁保险新世界-带你走进保险基本法



六、系统稳定性建设

6.1告警机制

系统接入应用监控(UMP)和机器监控(MDC)监控系统,配置了jvm监控、CPU使用率、磁盘使用率、连通性、RSS内存使用率、系统负载、TCP连接数、网络流入速率、网络流出速率、TCP重传数等告警项,全方位保障应用在处理基本法任务时能够持续、稳定、高效地运行。

6.2基本法任务执行链路跟踪

接入链路监控 (PFinder) :依赖PFinder能力,按多个维度指标进行监控,自动对 SpringMVC,JSF,MySQL,JMQ 等常用中间件进行性能埋点,自动梳理服务的上下游和中间件的依赖拓扑,在出现异常时可以基于请求的跨服务调用追踪,快速分析性能瓶颈。

系统任务链路监控: 关键任务(如团队任务、佣金结算、绩效考核等)按照预定的规则执行,将各节点执行信息进行留存,通过定时任务进行扫描任务各节点是否执行完成,超时未执行进行重试,重试3次仍未成功将触发邮件和电话告警,研发人员将在告警触达的第一时间响应处理,确保关键任务能够按照预定的规则顺利执行。

七、汇总展望

自系统重构实施以来,该系统已历经多轮严苛任务考验,其准确率跃升至99.99%,为超过4万名代理人提供了坚实的技术支撑与保障,彻底扭转了代理人及内勤团队对系统的旧有观念,得到了业务方的肯定。

未来,我们将坚定不移地聚焦于系统性能、稳定性及安全性的持续提升,确保每一环节的优化都能为业务的高速增长注入强劲动力。同时,我们将积极拥抱新技术,不断探索其在系统中的应用潜力,致力于推动系统向更加智能化、自动化的方向迈进。我们相信,通过技术的不断创新与应用,能够进一步释放生产力,加速业务流程的自动化与智能化转型,从而以技术为引擎,驱动业务实现跨越式发展。

点赞
收藏
评论区
推荐文章
Easter79 Easter79
3年前
Taro 在京东购物小程序上的实践
Taro简介Taro是一个基于React语法规范的多端统一开放框架,大家可以通过taro.aotu.io进一步了解。而前段时间Taro发布后,京东购物小程序就开始了部分页面基于Taro的重构工作,本文便是对商品分类页使用Taro进行代码重构的一些实践分享。混合开发模式过去的京东购物小程序未使用任何第三
京东购物车分页方案探索和落地 | 京东云技术团队
随着京东购物车应用场景的丰富化和加车渠道的多元化,京东购物车的商品容量从2015年至今一直在逐步增加。2015年京东购物车由80件扩容到120件;2018年由120件扩容到150件;2020年由150件扩容到180件;2021年京东PLUS会员扩容到了22
京东云开发者 京东云开发者
3个月前
【京东保险-技术平台部-平台研发部】一群AI卖保险的程序员
应【我在京东做产研】活动团队的邀约,想要介绍一下部门,用于面向新同事和潜在同事,分享团队的定位、职责、持续探索建设的方向、团队亮点\此类文章容易写得又红又专,思来想去,我还是写得尽量接地气一些,避免写成工作汇报体😅一、写在开头要介绍清楚我所在的部门【京东
京东云开发者 京东云开发者
2个月前
【我在京东做产研】校招 2 年,个人角度(成长)回顾 - 行且知
2022.6月毕业,然后入职于JD京东保险技术平台部,岗位后端开发工程师,至今已两年回顾毕业后的工作历程(文章会以现实时间为顺序来进行回顾),有很多大佬的帮助和指点。因此,想将自己的思考也分享给后来的同学们文章从个人角度(成长)出发,回顾工作点滴。会尽可能
京东云开发者 京东云开发者
2个月前
大模型时代下的新一代广告系统
京东零售广告部承担着京东全站流量变现及营销效果提升的重要职责,广告研发部是京东最核心的技术部门,也是京东最主要的盈利来源之一。作为京东广告部的核心方向,我们基于京东海量的用户和商家数据,探索最前沿的深度学习等算法技术,创新并应用到业务实践中,赋能千万商家和
京东云开发者 京东云开发者
1个月前
用JS实现简单的屏幕录像机
作者:京东保险张洁本文将介绍如何用JS实现简单的屏幕录像机。一、录制准备创建一个按钮Startrecording书写JavaScriptvarRECORDINGONGOINGfalse;varrecordingToggledocument.getEleme
京东云开发者 京东云开发者
1个月前
「软件设计哲学」于延保代码改造中的实践
作者:京东保险王奕龙本文主要给大家分享软件设计中的两个理念,为什么我称软件设计是“理念”而不是“方法”或“原则”呢?这个想法主要受《Aphilosophyofsoftwaredesign》的影响,它将软件设计称为“哲学”,而哲学本身没有严格的定论,同样地,
京东云开发者 京东云开发者
3星期前
【质量视角】可观测性背景下的质量保障思路
作者:京东保险郑飞背景介绍目前质量团队正在积极建设和完善应用监控能力,旨在能及时发现并解决问题,为线上服务稳定性保驾护航。随着可观测性概念的逐渐普及,监控的建设也有了新的挑战和使命。本文将探讨在可观测性背景下,作为一个测试人员在质量保障中的一些思路和个人思
京东云开发者 京东云开发者
3星期前
飞码LowCode前端技术(六)
作者:京东科技王光辉(如何便捷快速验证实现投产及飞码探索)\作者:王光辉\部门:京东科技市场与平台运营中心营销与数据资产部营销及数据平台研发部简介飞码是京东科技市场与平台运营中心平台研发部研发低代码产品,可使营销运营域下web页面快速搭建。飞码是单web页
自动化实践之:从UI到接口,Playwright给你全包了!
作者:京东保险宋阳1背景在车险系统中,对接保司的数量众多。每当系统有新功能迭代后,基本上各个保司的报价流程都需要进行回归测试。由于保司数量多,回归测试的场景也会变得重复而繁琐,给测试团队带来了巨大的工作压力。车险投保流程主要通过H5页面进行,核心功能集中在