数据|线下业务数据体系搭建(三):跨部门数据交互体系搭建

编辑导语:公司各个业务部门之间都会存在一定的数据交互行为,此时,大量不同类型的数据可能留存,如何更好地做好数据存储、数据交互,便成为重中之重。本篇文章里,作者就跨部门间的数据交互体系搭建做了总结,一起来看一下。
数据|线下业务数据体系搭建(三):跨部门数据交互体系搭建
文章插图
数据的存储形式,在各个部门的系统留存逻辑都是不完全一致的,甚至留存的口径都存在问题。
以整个互联网消费金融的系统为例,前端订单系统和业务风控系统记录的是用户申请贷款到实际发放贷款为止,用户的所有还款行为、催收员的跟进行为对用户产生的影响放在贷后跟进系统,最后经历了一整个资产回收周期到末端的逾期资产处置的系统上面去对用户进行更进一步的操作。这部分所有的数据,在一定程度上可以构成用户在互联网消费金融方面的整个用户流程行为。
用户在消金公司的行为线可以简单归纳为:
数据|线下业务数据体系搭建(三):跨部门数据交互体系搭建
文章插图
在用户的实际行为下,会有大量不同类型的数据以各种类型留下来在各个系统中,不同类型的数据和用户行为都会被留存下来,这一部数据需要以统一的方式和逻辑被留存在系统中。
这就涉及了公司各个业务部门之间数据中台的建设,如果没有放大到所谓数据中台的建设上,也仍然涉及了大量跨部门之间业务数据流转交互的过程。
一、数据交互口径对大部分公司来说,主要是业务部门产生数据,由数仓、BI、大数据等等部门去做数据留存、交互,除了在业务衔接上会各个相关部门会有接触外,还有同类型的业务部门会产生数据上的交集。
像信贷商城部门、风控部门有大量业务衔接节点,同样作为逾期资产处理的催收部门和用更有利手段的进行诉讼催回欠款的法诉部门互相之间都会有大量业务交互的部分,这都需要各个系统在交互逻辑上是保持一致的。
以互联网金融风控系统为例,因为“互联网”和“消费金融”这两者的特殊性,导致了用户实际在线上操作申请贷款的流程需要尽可能快速,但是交易的金额量又较高,前端业务风控系统的计算逻辑就需要尽可能减少多的握手次数,也需要风控引擎读取的相关字段尽可能简单,业务逻辑更清晰。
但这样快速响应的系统在某种程度上就在本地服务器上留存大量数据,进行较为复杂的查询工作,碰上免息、折扣的活动,大量用户参与前端风控评测的时候更容易产生风控系统崩溃的情况(这也就是为什么大量企业在自己的页面前端加入验证码防止前端页面被刷)。
传统金融业的订单数少,订单金额高,借贷期限长,客群资质好,风控预算高;而科技金融公司实施的互联网金融业务所面临的业务场景则是订单数多,订单金额低,借贷期限短,客群资质差,风控预算低。
这就是为什么所有的互联网金融消费公司都需要将风控系统和公司其他所有系统的数据交互口径调整一致。
数据口径的统一是什样的?举个简单的例子,以互联网消金公司的两套系统为例,订单系统、贷后催收跟进系统两套系统中,用户这个个体的所有行为,都需要统一:

  1. A用户在订单系统中的按订单的维度记录数据:A用户于XX年XX月XX日XX时XX分XX秒借款了3000.00元,订单到期日为XX年XX月XX日XX时XX分XX秒;
  2. A用户在贷后催收跟进系统按催收处置流程的维度跟进收集的记录:A用户于XX年XX月XX日XX分XX秒开始逾期,欠款本金2000.00元,欠款罚息100.00元,逾期天数XX天,催收人员于XX年XX月XX日接入催收,用户于XX年XX月XX日还款。