维度|线下业务数据体系搭建（二）——逾期资产处置系统数据底层逻辑设计

编辑导语：本文就线下业务数据体系的搭建进行讲解。以自己公司上线系统后出现的问题为例，从四个方面进行讲解，解决了系统数据构建问题。推荐想要搭建线下业务数据体系的用户阅读。

文章插图
最近开始上线系统，公司目前又没有数据产品经理参与系统设计，勉勉强强上线了系统，但是在系统上线之前经历的打断数据清洗迁移系统的过程，是想记录下来分享给大家的。
整个产品项目提出大概是去年年末今年年出，确定初版原型图设计大概是6月份，需求调整、开发、测试、灰度，到现在才开始进行实际业务测试，期间经历了很多困难，实际在业务的生产中，我们在7-8月份实现了整个部门业务处置能力的飞跃，整体的业务模式也发生了比较大的变化，这导致实际开发进度远落后于业务的进步。
一、业务逻辑在很长一段时间内，我们一直依靠数仓建立的一张极高自由度的表结构下操作，大量的数据由实际前端业务员汇总，导入数仓留存，这样的操作就导致了，在实际业务逻辑中，有大量存在强逻辑相关性的字段，并没有按实际的固定的逻辑进行留存，像类似有一部分用户/订单委派给了渠道进行诉讼处置，但渠道回传的案件进度数据中，只给定了诉讼结案时间，却没有立案时间。
但由于这张极高自由度的表格，会让这样不合业务逻辑的数据被留存下来，如果渠道在中途不再合作，立案时间这个字段可能就彻底丢失，在系统数据中转化为错误值，在业务中的有效数据因为工作流程上的不规范成为了无效数据，这是得不偿失的。
所以，在实际设计线下业务数据体系的时候的时候，第一个需要考虑的就是业务上的逻辑，简单以诉讼为例。

文章插图
这是一套简单的诉讼流程，实际在作业中，我们需要明确，有哪些事件的发生是带有强关联性的，这在一定程度上能帮助我们对数据是否合理，是否真实进行校验，同样能对合作的三方机构、渠道的作业能力、作业方式有一定的了解。
在上述流程中，如果同时出现二审受理时间和驳回诉讼申请的反馈，可以说明在某一程度上数据是有问题的，同样的，有二审审理开始时间却没有一审结束时间同样是数据有可能产生问题的点。
按业务逻辑校验数据，除了能在流程数据校对中发现一定问题之外，还能通过这部分流程数据获取渠道不愿意同步的情况，尽量减少信息不对等的问题，减少我方损失，例如渠道在递交材料这个环节没有同法院沟通顺畅，就要求我方提供大批量同类型案件处置，却最终反馈撤诉的情况下，很有可能在最初渠道反馈的他们可合作的法院便是不接受这类案件，且无法处置的，这时候说明在前端商务沟通层面上，渠道反馈的作业信息是有误区的，这种误区会容易耗费大量的人力物力。
所以，数据在之前先做好稳定收集校验的工作，是能够稳定判断渠道的实际作业情况的。
当然，我们实际业务中碰上的问题便是没有先进行业务逻辑校准，便补充了看似准确的业务数据，这部分不符合业务逻辑规范的数据在系统强关联的操作步骤中无法正常体现，甚至导致历史数据迁移的时候报错，无法导入，这时候就需要数据组校准逻辑之后对核准判断并清0从业务数据体系建立的逻辑层面上关注，就需要一开始从部门业务起始到最末端的数据回流收集，需要根据实际业务建立一套完整规范的数据收集体系，规定在某个时间节点获取某些指标数据，这样也利于从一开始摸清实际业务中会出现的问题类型，以渠道准入为例：