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

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