编辑导语:面对产品化程度高的金融项目,不知道从何入手?作者为我们分享了自己在做贷前流程全解耦时的经验,让我们一起来看一下。
其实这是我第一次参与产品化程度这么高的项目——贷前流程全解耦。其实稍有遗憾,我正式参与的时候,项目的雏形都已经有了,不过这完全不影响我抱着学习的心态去深度参与进去。
笔者平时喜欢将事情逻辑化,适当整理后反复复盘,前事不忘,后事之师。
坦白讲,这篇文章涉及内容是我2年前的工作内容,但是这段工作经历带给我的产品思维能力,方案决策能力是让我获益的。
在我后续的工作中每每遇到困难,我最经常问自己的是,如果是TA遇到这个问题,TA会怎么分析,怎么解决这个问题?TA就是我在工作中遇到的每一位优秀的老师,这个方法也一直让我获益。
结合现在做总账的账务经验,再回首之前工作中的贷款交易、形态转移、贷后管理等等,对业务流程的理解更加深刻,很多道理也是触类旁通。
书归正传,本文重点是介绍的是贷前解决方案。首先定义一下我理解的贷前流程:从进件到放款,在此基础上,可再细化为:授信流程、用信流程。
为了便于理解,我画了个图,下图是一个信用贷款贷前流程示意图,一些信息在图中说清楚的,也就不在文中赘述。区分开授信流程和用信流程,也是现在有很多信贷产品是在同一个授信有效期内循环用信,按天计息,也就是常说的随借随还。
考虑到触达客户,我们用“个人中心”的模块作为一个总入口,在和宿主APP的打通用户体系下,我们可以在个人中心查询并展示该userid的所有订单、所有订单的订单状态、订单详情信息。
这里为什么特意强调“订单状态”,因为订单状态将是推动这个作业流程前进的唯一关键!
一、订单管理系统
用户看到的是什么?用户如何知道当前申请的进展?如何触发下一步流程?这里,我引用“状态机”的概念进行解释,这因为需求分析中比较实用的一个方法。
状态机,即描述状态转移。由4个要素构成:触发条件,当前状态,执行动作,未来状态。(按百度百科的说法是状态机可归纳为4个要素,即现态、条件、动作、次态,其实一个意思)。
因为是长作业流程,所以订单状态的管理尤为重要。
根据下图中所示意的,系统可根据初始化配置的未来状态,直接展示给用户明确的操作指向。
途中只是举例示意了部分状态,实际业务流程中,多则会出现几十个中间状态,但通过这个状态转移的四要素进行梳理,逻辑上还是很清晰的。
订单管理系统的定位就是对所有的状态进行管理,说白了就是一个数据库,对外提供订单查询接口和订单更新接口的服务。
理论上,我们根据业务需求对每一个作业节点拆分,各子系统按照约定去获取特定的订单状态的订单即可。
这里还有一个重要补充,比如在多个产品,授信和用信流程并行的相关场景下,实践下来,仅仅靠订单状态的筛选还是不够的,因为订单状态会重复,所以产品设计引入了“场景”的概念。
场景是各个系统最高层级的配置,比如,进件场景JJ001,签章场景QZ001,风控工作流场景FK001,审批场景SP001,在工作流引擎中按照各个场景编号进行设置,通过设置判断条件及对应的执行逻辑。
例如:工作流判断订单状态为资信初筛失败,就不会调起风控工作流的服务,如果订单状态为资信初筛成功,就调永风控工作流服务,风控工作流就会查询相关订单状态的订单进行变量加工及决策判断。
另外,通过场景的概念,标准化各模块之间的通用接口,各系统之间也可以直接相互调用,进件需要调用签章完全不需要通过工作流,也可以直接调用,通过唤起SDK的方法,传入场景编号QZ001即可,签章处理完成后返回状态给进件即可。
至此,通过工作流引擎和订单管理,完成了系统间运转。下文对各个模块做介绍。希望大家不要纠结模块or系统,职能没有区别,只是是否独立部署而已。
二、进件模块(系统)
先谈谈系统定位,进件系统的定位是进件流程中采集字段,这些字段是进行后续流程的重要依据。
比如说人工审批,自动化风控,还款计划生成需要这些重要的信息录入,另外还需要兼顾监管合规要求,如:客户影像存储,客户信息脱敏等。
在实践过程中,进件面对的第一个问题就是创建订单的时点,理论上应该是必要信息完成填写后,才会去创建订单请求。
但是考虑到用户操作,需要有个草稿的订单状态,以便于帮助用户保留一些曾经录入的信息,增加一些用户体验。
进件字段类型种类较多,部分也是和用户体验息息相关。比如:
- 字符型,如姓名,地址;
- 码表型,如户籍所在省市。
需要集成一些服务,前面提到的影像上传,因为有合规性要求,需要对接专业的影像系统。
如客户证件的正反面,在人工审批或者贷后有影像调用查看需求,我们这么解决,进件调影像系统的上传服务,将返回的fileid作为Value和文件类型:授权书(authorization)、借款合同(contract)等作为key,update到订单系统中该笔订单号下,后续系统根据约定好的文件类型直接查回fileid直接调影像系统的下载接口即可。
考虑到不同渠道,也考虑了SDK和H5两种方案。
SDK的好处是,直接集成在手机银行APP中,native的还有一个好处是用户体验更佳,但是一旦改动换包需要提交应用商店,应用商店都有审核流程,实时性没有那么好。
也鉴于此,后来越来越多的设计直接在H5实现,视觉效果几乎一致,但是因为资源都是从服务器加载,非常依赖网络质量,弱网环境下用户体验极差。
基于以上设计,面对不同进件渠道,无论是线上合作导流模式,线上自营模式,还是线下传统模式,无非是不同的接口,大同小异的字段集。
至于是用户还是客户经理,其实本质还是一致的,通过标记区分,在个人中心查询订单的时候,通过标记筛选。
三、风控平台
之所以称之为风控平台,其实是由三个系统组成:
- 变量加工系统
- 风控引擎
- 风控工作流
还是要谈系统定位,在这个环节需要配置各种决策规则,在订单推进来的时候,得到审批结果。
决策规则引擎的输入集合其实说白了是一堆{key:value}的结构化数据,数据来源根据规则需要。
- 有内部的,如:财务数据,行内黑白灰名单;
- 还有外部的数据,如:前海,企查查,同盾等数据源。
对接内外部数据,使用订单的三要素或五要素,按配置接口,查询返回对应的数据源数据,作为原始变量,系统支持函数运算的衍生变量,形成一堆的key-value值集。例:
- 借款人手机在网时长(cust_mobile_status)=6
- 借款人配偶手机在网时长(custcouple_mobile_status)=12
- 借款人逾期期数(over_delay)=3
- 借款人近6个月申请贷款次数(loanapply_amount)=5
把变量加工的这些值集送给风控引擎,规则流、决策树、评分表的配置,使用这些变量根据配置的规则得到决策结果。
- ifcust_mobile_status >=6
- 执行得分+5
- else执行得分+0
- if 得分in (0,100)拒绝
- if 得分in (101,200)转人工
- if 得分in (200,250)通过
四、审批系统
根据风控结果,在工作流配置是否需要进行人工审批。这并不是一个必要环节,或者更准确的说任何一个环节都是可以配置的,业务流程上不需要就可以不配置。举个简单的例子示意:
- if risk_rult = ‘拒绝’,订单状态update为审批拒绝
- if risk_rult =’通过’,订单直接审批通过
- if risk_rult =‘转人工’,订单推入审批系统
审批系统为人工坐席岗位,信审人员会有各种的权限,系统自动分配,或者主动从公海取件,完成资料审批,电话审批后,输入人工审批结果,提交后系统会到订单系统中update 最新的结果。
五、结语
当系统模块解耦之后,通用解决方案如何去覆盖各类业务场景是实施过程中重要课题了。
信用贷基本上还是纯线上的,但是诸如房抵贷,车抵贷等会涉及房管所,车管所等缺乏成熟IT系统建设的线下部门,系统直接对接存在难度;还有就是线上流程中诸如电子签章和线下章样式不一致,合法性也不同于传统公章效力验证,这条路也还是有待持续探索。
这些复杂的作业模式涉及到线上线下融合,也不是完全走不通,在本文介绍的解决方案下,系统上新增具体的每一个场景的订单状态,然后线下靠客户经理,渠道经理人工干预进行信息补录,增加集中作业进行复核。
做这套系统曾经最大的乐趣,是用我们的通用解决方案去匹配实现业务的个性化需求,避免定制化开发。这不仅需要对业务的深刻理解,一定的前瞻性,更是验证我们的系统设计的灵活度,参数化程度。每次评估下来可以支持的时候,其实很有成就感!