编辑导语：公司各个业务部门之间都会存在一定的数据交互行为，此时，大量不同类型的数据可能留存，如何更好地做好数据存储、数据交互，便成为重中之重。本篇文章里，作者就跨部门间的数据交互体系搭建做了总结，一起来看一下。

数据的存储形式，在各个部门的系统留存逻辑都是不完全一致的，甚至留存的口径都存在问题。

以整个互联网消费金融的系统为例，前端订单系统和业务风控系统记录的是用户申请贷款到实际发放贷款为止，用户的所有还款行为、催收员的跟进行为对用户产生的影响放在贷后跟进系统，最后经历了一整个资产回收周期到末端的逾期资产处置的系统上面去对用户进行更进一步的操作。这部分所有的数据，在一定程度上可以构成用户在互联网消费金融方面的整个用户流程行为。

用户在消金公司的行为线可以简单归纳为：

在用户的实际行为下，会有大量不同类型的数据以各种类型留下来在各个系统中，不同类型的数据和用户行为都会被留存下来，这一部数据需要以统一的方式和逻辑被留存在系统中。

这就涉及了公司各个业务部门之间数据中台的建设，如果没有放大到所谓数据中台的建设上，也仍然涉及了大量跨部门之间业务数据流转交互的过程。

一、数据交互口径

对大部分公司来说，主要是业务部门产生数据，由数仓、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日还款。

从上面的事实记录模式看，两者时间实际只有时间记录颗粒度的差距，线上订单系统的记录能正常精准到秒，但实际以线下行为（且行为的记录主体是催收员，和线上的行为记录主体用户完全是两套不同的记录角度），这种颗粒度差距看起来差距不大，但是在实际快速响应的风控系统中，会产生很大的影响。

简单来说，用户在经过催收员沟通之后在一点时间内回款，这个时间差从日期来看是天数的差距，而不是小时、分钟的差距，这个回款天数差能够用于实际评估用户的还款能力。

举个例子，用户在接到催收电话后马上还款，那可以根据模型估计用户的还款行为是代表其有较强的还款能力的，这种有借款行为且有高还款能力的用户在风控上就可以相对提高用户的额度。

同样的，用户如果都在催收员跟进当天内进行还款，又可能代表了不同行为特征的用户。如果均按“0天”进行计算，就需要从别的维度补充这部分数据，可能是催收员进行跟进的文本维度，这就需要NLP介入进行判断。

某种程度上来说，更复杂的模型让各个系统之间的握手次数和交互流程更为复杂，这和实际业务上的追求就相悖了。

所以，在各个系统的交互上，更需要将所有的交互结构、尤其是数据颗粒度，数据产生的逻辑进行统一。

这就需要从公司层面上进行业务线梳理，明确哪一条是核心业务线，根据核心业务线的用户流程去进行各个系统之间的改造。不然就像我刚刚说的，不同的系统之间有不同的服务目标，这是好事，但过多的服务目标会导致底层数据的存储逻辑不同意，在高并发的核心业务部门会导致大量数据被无效拉取计算，这就不利于核心业务线的增长。

二、数据交互时效

除了数据交互口径可能会产生不一致冲突的情况，数据交互时效也会对不同业务系统产生差异。

几乎大部分涉及线上业务的公司都会有数仓和大数据这两个部门。从公司业务反馈来说，一般数仓是历史数据的留存处置，大数据用于线上实时业务数据的更新计算。

从某种意义上，传统数仓的模式也更容易按统一的业务规范，按数据仓库工具箱：维度建模（第二版）中Kimball说：“我们花了二十年的时间往数据库中加入数据，现在该是拿出来使用的时候了。”数仓对公司整体业务的发展实际上是起到底层数据夯实奠基的作用。

大数据部门的作用则更多体现在实时数据的生产，由于传统数仓本身依托于大数据量级的关系型数据库建立，很难大量、同时提取数仓的数据去做到即时性的分析，而从用户的维度则更希望看到实时的结果（这种需求在涉及供需、金额变化的业务场景会更为突出，像12306的实时车票计算系统），突出的特点就是“及时性”、“快”，高速响应用户的所有定制化需求，用户的这种需求在互联网消金公司显得尤为关键。

尤其是当用户收到我方催收作业下还款的场景下，会更希望在APP前端展示的欠款产生变化，这种及时性的需求就会要求系统能直接调用大数据的接口完成实时账单的计算。

这时候就需要考虑如何将这部分数按统一的规则落库到数仓中，去记录用户各个事件节点收到影响的行为变化，就需要数仓留存的数据是按业务流转节点去进行记录的，这些互相之间数据的交换。

如果在事件随时发生就随时交换，会极大影响系统的性能（这种大量判断的逻辑会极大影响交互逻辑，如果发起交互超时了未报错，会导致实际收集的数据不全等情况），这种情况并不只发生在某个系统中，而会出现在每个系统和数仓、大数据的交互中，而一个系统尚且会碰上数据交互时间、事件维度不统一的情况，多个系统想要完成两者逻辑的汇总，更是难上加难。

而每个系统所能拉取数据的时间点也不尽相同，这是困扰所有发展中公司，尤其是线上线下业务同时发展的公司，这种不同业务系统上的数据交互时间，也是需要按最核心的业务线进行判定，通过核心业务线的业务逻辑，完成各个系统数据交互时间逻辑的改造。

三、最后

以上两点在互联网消金公司中都会发生，怎么做到两者的统一，还是需要从整体业务架构的改善中去调配。

虽然核心业务线是居最高位置的，但它不一定是最能代表公司营收的业务线，就像在大部分消金公司中，还是以风控能力、用户评分卡作为核心业务能力，但根据每个消金公司的业务形态不一样，业务发展周期不一样，公司的核心业务线就行发生改变，这就需要更加稳固的集中化数据服务平台对整体业务发展进行评估，确定核心业务的发展和所有业务线的粘合方式。

当然，作为一个偏业务后端的从业人员，也是希望后端的数据能被更多人关注，之后看时间谈一谈互联网消金后端风控的逾期资产处置对前端业务的作用吧。

作者：Logan_RRRC，公众号： Logan的运营学习日记

本文由 @Logan_RRRC 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议