编辑导语：面对产品化程度高的金融项目，不知道从何入手？作者为我们分享了自己在做贷前流程全解耦时的经验，让我们一起来看一下。
其实这是我第一次参与产品化程度这么高的项目——贷前流程全解耦。其实稍有遗憾，我正式参与的时候，项目的雏形都已经有了，不过这完全不影响我抱着学习的心态去深度参与进去。
笔者平时喜欢将事情逻辑化，适当整理后反复复盘，前事不忘，后事之师。
坦白讲，这篇文章涉及内容是我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系统建设的线下部门，系统直接对接存在难度；还有就是线上流程中诸如电子签章和线下章样式不一致，合法性也不同于传统公章效力验证，这条路也还是有待持续探索。
这些复杂的作业模式涉及到线上线下融合，也不是完全走不通，在本文介绍的解决方案下，系统上新增具体的每一个场景的订单状态，然后线下靠客户经理，渠道经理人工干预进行信息补录，增加集中作业进行复核。
做这套系统曾经最大的乐趣，是用我们的通用解决方案去匹配实现业务的个性化需求，避免定制化开发。这不仅需要对业务的深刻理解，一定的前瞻性，更是验证我们的系统设计的灵活度，参数化程度。每次评估下来可以支持的时候，其实很有成就感！
本文由 @青雨轻寻 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议
热门跟贴