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

有大量商务人员在前期渠道准入的获取的渠道信息是没有实际同步实际运营人员的，在渠道准入之后有大量的实际对接工作在就会落在后端运营人员这，同样的，渠道方也会更换实际的运营沟通人员，大量的前期对接工作在运营人员未知的时候业务就流转到了下一个节点，如果对各个部分人员权限管理的再严格一点，很可能出现运营人员连实际的合作协议签署都还没确定的情况下就被业务推动着不停往前走，不停沟通合作尝试。
最后发现渠道甚至合作协议的签署，合作模式都不是很清晰，这种情况在这种0-1的创业公司、创业部门非常常见，实际业务需求推动过于紧张，但实际业务逻辑、运营逻辑的搭建被远远落在后面。
二、数据自由度数据自由度在实际业务场景下应当被定义为实际数据操作人员的数据规范化操作，就以简单的数据清洗补充为例，在线下的业务流程中，会有大量的数据以表格的形式在线下本地存储，需要把这部分数据以规范化的逻辑、格式上传至系统留存，才能汇总所有人的数据记录，在数据没统一上线系统之前，甚至“需求表-排期表-跟进表”三个不同功能作用的工作表的数据、文本都可能产生差距，就比方说需求表内法院信息补充为“厦门市集美区法院”，在实际排期表、跟进表中存储的法院信息为“福建省厦门市集美区人民法院”，这部分信息在系统的留存可能只能以一个标准字段的形式存储，用于代表用户的所生成的用户ID假设包含英文的大小写，同样要规范以统一的大写/小写的形式作为留存
举个例子，碰上底层如果对大小写敏感的JAVA、C++等语言撰写，同一个用户如果存储方式是“A”和“a”是完全不一致的，在甚至身份证号中的“X”和“x”都会被识别为两个用户，这样的数据不规范会在很大程度上影响数据的清洁程度，进而影响业务数据分析等方面；
一方面来说，数据自由在某种程度上确实很爽，可以以任何形式（CODE码，文字、数据等）留存关键数据，在业务流转过程中会很快乐，工作很迅速，如果这部分数据只是做无检验留存，在数据上传的时候甚至不会做任何校验，这样的数据在实际导入系统，做分析使用的时候都会产生比较大的问题。
在所有的线下业务中都可能会发生类似的情况，对数据自由度进行一定规范话，需要对所有要留存的数据设计留存格式、留存方式，在数据库中的更新模式（只允许新增数据/只允许覆盖数据），在规范化的操作下，才能保证部门内每个人的每一项线下工作都能按一定的逻辑交付，不会存在数据工作存在断档，同事无法接手、合作的情况。
三、底层数据表逻辑设计任何系统都需要在底层设计数据存储的表格形式，而每张实际存储的表都需要有主键作为唯一识别，根据不同维度的表格实现表于表之间的连接
我们以消费金融逾期资产处置为例，对于任何一种逾期资产处置的手段（电话催收、人民调解、法院调解、律所调解、诉讼等）来看，所有的处置手段的作用逻辑均在用户上，而单个用户下可能会存在多笔实际借款行为，单个用户在借款额度未用尽的情况下，多次操作借款，这样会在用户的维度下生成多笔借款记录，每一笔借款记录在最细的维度上都是以借款订单的账单维度展现的，而订单维度的借款行为构成了用户维度的行为。
在逾期资产处置上，又是以多个用户绑定的方式推送给渠道，渠道对不同的用户下多笔借款行为实际跟进处置，所有的处置逻辑是一层一层挂钩的，这种层层嵌套的数据结构，需要在实际操作的业务流程中，根据不同的业务流程中的主要展示表，去做表之间的不同关联形式，以下是各个维度的底层表可能会涉及的字段：