当互联网巨头们纷纷把目光转向2B市场，“数字化”、“智能化”也成为2B产品圈子的热词。要实现数字化、智能化，数据是基础，数据也是企业信息领域的核心资产。对于2B产品而言，企业数据具有较强的安全性和私密性要求，数据的本质归属是数据的生产者–企业本身。

一、为什么要进行数据转移？

如开篇所述，数据的本质归属是企业，企业运作依赖员工，因此，数据的实际承载是企业员工。企业员工据其岗位职责，负责不同的业务，生产、维护业务相关的数据。那么当数据主体因为业务需求发生变更时，就需要进行数据转移。

数据主体

员工因为业务的发生，在系统中记录、维护业务数据。因此系统中的每条数据根据其业务属性，理论上讲都有一个归属人和归属组织–部门。

主体变更

因数据本质归属是企业，因此，当数据因为各种业务因素发生主体变更时，我们需要将该主体名下的数据进行转移，这就是数据转移的应用场景。主体变更会存在以下几个场景：

• 数据因素–数据负责人/所属部门变化：负责人A名下的数据，由于A不能及时处理，或者业务需求上的变更，需要将暂时不能处理的部分数据转移给其他负责人；某些数据特殊业务场景下所属部门发生变更，要求改变数据的所属部门。
• 负责人因素-员工调岗/离职：员工A调岗后，因为负责业务不同，基于前岗位A名下的业务数据需要全部转交给新的负责人，因此会有数据转移的需求。员工离职自不必说，工作交接当然也包括系统数据的转移。
• 组织因素-部门删除/合并：企业规模扩展、组织结构调整，都会导致组织结构的调整，那么当原有部门被删除、或者被合并时，那么原归属在该部门下的数据将如何处理？这都涉及到数据的转移。

二、什么类型的数据需要转移？

基于2B产品所覆盖的业务范围，笔者大致将2B产品所涵盖的数据分为三大类，并基于不同的业务数据类型，阐述哪些数据需要转移。

OA系统数据

所谓OA系统数据，指的是企业中常规的自动化办公系统所产生的数据，如即时通讯、日程、公告、考勤等数据。

一般OA系统具有即时响应的特征，因此OA数据具有即时性，且历史数据带有强个人属性，比如“张三”发出的信息/参与的日程，即便是“张三”离职，也不可能将该数据转移到“李四”名下。因此OA系统数据不需要转移。

业务系统数据

所谓业务系统数据，指的是企业实际业务场景下所产生的数据，比如客户数据、采购数据、订单数据等等。

一般业务数据并不具有个人属性，只是由当前负责人根据业务执行状态进行跟进、维护，因此当数据主体发生变更时，避免业务停滞，需要有新的负责人来进行跟进，因此需要对业务数据进行转移，当然只有少数特殊业务数据可能不需要进行持续性维护，那么就不需要进行转移。

业务流程数据

所谓流程数据，指的是需要按照一定的规则执行的业务操作过程所产生的数据，比如业务流程、审批流程数据。

流程执行数据具有一定的个人属性，因此流程历史操作数据不存在转移，但是因为流程执行规则属于系统提前预置的数据，当流程执行到中间环节，其中未执行的环节执行人发生突发事件需要变更时，该用户名下仍然有未执行结束的数据，我们需要将该待办部分数据进行转移，交由新的负责人进行处理，以免耽误业务流程正常运转。

三、如何进行数据转移？

如前面所述，每一条系统数据根据其业务特性都具有它的所属主体，数据转移实际上是数据所属主体发生变更。因此，在数据主体发生变更时，我们只需要提供数据主体变更的工具（这就是数据转移产品的功能），并更改数据所属关系即可。

按数据进行转移–前台数据转移场景

当某条数据因业务要求负责人发生变更时，需要管理员/数据负责人，通过前台将数据转移给新的“负责人”或新的“所属部门”。那么交互的主体应该是“数据”，即选中数据，然后进行“负责人”或“所属部门”变更。

以下粗略交互示意：

按员工/组织进行转移–后台数据转移场景

当数据主体“员工/部门”因为离职、调整等场景，需要发生变更时，需要管理员通过后台将“员工”/“部门”名下的某些功能模块下的全部数据进行转移。那么交互的主体应该是“员工”/“部门”，即选中数据主体，将其名下的数据全部转移给新的“负责人”/“部门”。

以下粗略交互示意：

除了在数据管理入口下设计统一的数据转移入口；当在员工离职、部门调整场景下的入口也可以增加数据转移操作，便于在数据主体发生变更时，进行数据转移。

综上，“数据转移”功能虽然简单，但如开篇所讲，它是企业数据管理的基础和必备功能，且使用场景多样，不同的场景下，交互侧重点不一样。上篇文章《2B SaaS产品用户系统设计》中也有提及，因此，本次分享给大家。

以上，仅供参考。

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

题图来自Unsplash，基于CC0协议