产品数据转移功能的应用场景和产品设计

　　当互联网巨头们纷纷把目光转向2B市场，数字化、智能化也成为2B产品圈子的热词。要实现数字化、智能化，数据是基础，数据也是企业信息领域的核心资产。对于2B产品而言，企业数据具有较强的安全性和私密性要求，数据的本质归属是数据的生产者企业本身。
　　一、为什么要进行数据转移？
　　如开篇所述，数据的本质归属是企业，企业运作依赖员工，因此，数据的实际承载是企业员工。企业员工据其岗位职责，负责不同的业务，生产、维护业务相关的数据。那么当数据主体因为业务需求发生变更时，就需要进行数据转移。
　　数据主体
　　员工因为业务的发生，在系统中记录、维护业务数据。因此系统中的每条数据根据其业务属性，理论上讲都有一个归属人和归属组织部门。
　　主体变更
　　因数据本质归属是企业，因此，当数据因为各种业务因素发生主体变更时，我们需要将该主体名下的数据进行转移，这就是数据转移的应用场景。主体变更会存在以下几个场景：
　　数据因素数据负责人所属部门变化：负责人A名下的数据，由于A不能及时处理，或者业务需求上的变更，需要将暂时不能处理的部分数据转移给其他负责人；某些数据特殊业务场景下所属部门发生变更，要求改变数据的所属部门。
　　负责人因素员工调岗离职：员工A调岗后，因为负责业务不同，基于前岗位A名下的业务数据需要全部转交给新的负责人，因此会有数据转移的需求。员工离职自不必说，工作交接当然也包括系统数据的转移。
　　组织因素部门删除合并：企业规模扩展、组织结构调整，都会导致组织结构的调整，那么当原有部门被删除、或者被合并时，那么原归属在该部门下的数据将如何处理？这都涉及到数据的转移。
　　二、什么类型的数据需要转移？
　　基于2B产品所覆盖的业务范围，笔者大致将2B产品所涵盖的数据分为三大类，并基于不同的业务数据类型，阐述哪些数据需要转移。
　　OA系统数据
　　所谓OA系统数据，指的是企业中常规的自动化办公系统所产生的数据，如即时通讯、日程、公告、考勤等数据。
　　一般OA系统具有即时响应的特征，因此OA数据具有即时性，且历史数据带有强个人属性，比如张三发出的信息参与的日程，即便是张三离职，也不可能将该数据转移到李四名下。因此OA系统数据不需要转移。
　　业务系统数据
　　所谓业务系统数据，指的是企业实际业务场景下所产生的数据，比如客户数据、采购数据、订单数据等等。
　　一般业务数据并不具有个人属性，只是由当前负责人根据业务执行状态进行跟进、维护，因此当数据主体发生变更时，避免业务停滞，需要有新的负责人来进行跟进，因此需要对业务数据进行转移，当然只有少数特殊业务数据可能不需要进行持续性维护，那么就不需要进行转移。
　　业务流程数据
　　所谓流程数据，指的是需要按照一定的规则执行的业务操作过程所产生的数据，比如业务流程、审批流程数据。
　　流程执行数据具有一定的个人属性，因此流程历史操作数据不存在转移，但是因为流程执行规则属于系统提前预置的数据，当流程执行到中间环节，其中未执行的环节执行人发生突发事件需要变更时，该用户名下仍然有未执行结束的数据，我们需要将该待办部分数据进行转移，交由新的负责人进行处理，以免耽误业务流程正常运转。
　　三、如何进行数据转移？
　　如前面所述，每一条系统数据根据其业务特性都具有它的所属主体，数据转移实际上是数据所属主体发生变更。因此，在数据主体发生变更时，我们只需要提供数据主体变更的工具（这就是数据转移产品的功能），并更改数据所属关系即可。
　　按数据进行转移前台数据转移场景
　　当某条数据因业务要求负责人发生变更时，需要管理员数据负责人，通过前台将数据转移给新的负责人或新的所属部门。那么交互的主体应该是数据，即选中数据，然后进行负责人或所属部门变更。
　　以下粗略交互示意：
　　按员工组织进行转移后台数据转移场景
　　当数据主体员工部门因为离职、调整等场景，需要发生变更时，需要管理员通过后台将员工部门名下的某些功能模块下的全部数据进行转移。那么交互的主体应该是员工部门，即选中数据主体，将其名下的数据全部转移给新的负责人部门。
　　以下粗略交互示意：
　　除了在数据管理入口下设计统一的数据转移入口；当在员工离职、部门调整场景下的入口也可以增加数据转移操作，便于在数据主体发生变更时，进行数据转移。
　　综上，数据转移功能虽然简单，但如开篇所讲，它是企业数据管理的基础和必备功能，且使用场景多样，不同的场景下，交互侧重点不一样。上篇文章《2BSaaS产品用户系统设计》中也有提及，因此，本次分享给大家。
　　以上，仅供参考。