在数字化转型的当下，大多企业都需要制定一部《数据共享管理办法》来为跨部门的数据开放保驾护航，自己近就在思考这个问题，但发现能参考的信息不多，无论是书上的、网上的、专家的，大多是在讲通识和理论，缺少细节，缺少案例，也缺了点地气。
我就自力更生拟定一个吧，以下是这个办法的要点，理解了这些要点，串起来，就能形成一个办法，虽然不完美，但它是可以落地的。
1、完全开放，可控开放和不可开放的概念内涵
三个词看着简单，其实挺难，比如完全开放大家都懂，但真要深究一下到底什么意思，实操到底怎么做，颇要费一些脑力，我去山上逛了一圈，然后把复杂问题简单化了：
完全开放：不需要走审批流程的数据开放叫完全开放。
可控开放：需要领域责任人进行审批的数据开放叫可控开放，因为领域责任人很难提前说清楚具体的开放规则，我不想陷入规则的泥潭，且规则往往是在实践中慢慢清晰的，那就暂时靠流程来一事一议。
不可开放：包括两种情况，种，公司信息安全明令禁止开放的数据，第二种，领域责任人明确标识的对某些领域不可开放的数据。
特别说明一点，数据属于哪种开放形式不是由数据本身决定的，而是由数据+开放对象决定的，这个数据对这个对象是完全开放的，对那个对象可能就是可控开放的，比如数据a对部门A是完全开放的，但并不意味着数据a的性质是完全开放，也许数据a对部门B就是可控开放的，也就是B来申请a开放时需要走审批流程，离开对象谈某个数据是否可开放很难具备实操性。
这个问题困扰了我很久，也许是受到了个人隐私数据不可开放这种标准的影响，但企业内大多数据的开放都应具有相对性，因此拿着政府的数据对外开放的管理办法来套企业内部的数据开放，应该是不行的，背景相差太大了。
2、建立数据开放权限矩阵
要建立跨部门的数据权限矩阵，有三个核心步骤，大家可以看看你的企业走到了第几步，走不完并不意味着不能开放，只是代表了可能的效率低下，完成这三个步骤是解决开放问题的关键。
步骤一、建立公司数据责任人制度
为什么要有数据责任人制度？举个例子就明白了。
比如人力资源系统的数据，it部门当然可以管，但它管不动，以前相安无事是因为以前人力资源系统的数据只有人力部在用，现在如果要开放给其他部门用，你看它会不会反对，既然人力系统的数据与人力部利益攸关，而且人力系统的需求也是人力提的，那么人力系统的数据归属人力部管理所当然。
但责权利要统一，人力部既然有反对数据开放的权力，那么它也要承担相应的义务，公司顶层设计就要干这事，明确人力部关于人力领域数据的权力和责任，而这恰恰是权限矩阵能够建立的前提。
现在大量的数据开放问题都是责任和权利不清造成的，开放数据的时候一堆人反对，但真要大家明确下开放的原则，发现这可是苦活累活，然后谁都不吱声了。
那谁来统筹推进这个事情呢，只有靠企业数据责任人了，它需要代表公司去统筹推进这个事情。
没有组织机制的保障，数据开放要有大的突破几乎不可能，有人反馈说数据开放没有问题，关键是数据质量不行，没法追责，其实这是同一个问题，数据开放当然要保证数据质量，割裂开放和质量，追根溯源还是你公司的开放机制有问题。
步骤二、盘点清楚领域责任人负责的系统和数据
即使公司建立了数据责任人制度，但如果没有建立企业级的数据资产目录，那这种制度也是形同虚设。
数据责任人制度一建立，就要像财务维护的资产负债表一样，马上安排领域责任人把自身领域的数据资产盘点清楚，并且要能形成企业数据资产目录的闭环管理能力，数据资产目录不应该靠一次项目推动建立。
为了做好数据资产盘点，公司数据责任人要制定统一的数据资产盘点标准和方法，比如分多少层级目录，每个数据资产怎么描述等等，就像财务管科目一样。领域责任人则要在公司数据责任人的指导下把领域数据资产目录梳理出来。
很多公司的领域数据责任人是业务部门，但系统的建设职责在集中的IT部门，即便是这样，领域责任人也要履行好相应的职责，不能两手一摊说没能力梳理，既然业务部门在系统建设上有那么大的发言权，能跟IT部门很好的协作，那就没理由梳理不出数据资产目录，不重视不习惯而已。
步骤三、明确角色与数据资产目录的授权关系
公司数据责任人要协同各部门明确要设置多少角色，这些角色有哪些数据的权限，可能的情况是，各部门希望自己的角色能访问数据资产目录中所有的数据。
领域数据责任人要审核这些部门角色的权限是否合理，其也许无法判断这些权限在业务上是否真有必要，但领域数据责任人可以基于自身的安全管控要求在不开放或可控开放上打勾，但不开放或可控开放也不是完全由领域责任人决定的，至少领域数据责任人要说明理由，比如人力认为薪酬信息不适合对部门开放，公司数据责任人则要审核这个理由是否充分，然后终决定部门角色与数据资产目录的授权关系。
数据开放权限矩阵的确定过程充满了沟通和权衡，如果能完成步骤三，那数据开放也成功了一半了，因为它已经把大多需要扯皮的事情通过数据责任人机制提前讨论清楚了，虽然也有妥协，但这个结果代表了公司的意志，而以往关于数据能不能开放往往取决于某个员工或某个领导个人的意志，小鬼当家的事太多了，这就太随意了。
至于数据开放水平是否有提升，这取决于公司是真得想开放还是说说而已，权限矩阵是一块试金石。
3、明确数据开放的服务承诺
一个制度如果只讲手段不讲目标，即使初衷是好的，手段再完美，结果也不会很理想，数据开放一定要设置速度目标，影响数据开放速度一般有三个原因，是管理流程，第二是平台能力，第三是数据准备。
点通过前面的举措已经解决，第二点是技术问题，不讨论，这里重点讲第三点，即数据准备。
华为数据之道针对数据准备给出了比较暴力的服务承诺，也叫“三个1”，即：针对已经发布的数据服务，一天之内开放；针对已入湖未发布的数据服务，一周内开放；针对未入湖未发布的数据服务，一月内开放。
实操中“三个1”比较难，可以做适当的改进，即针对已经发布的数据服务，一天内开放，针对未发布的数据服务，遵循公司数据开发管理办法要求，因为这个时候的数据开放问题其实已经变成了一个数据开发问题。
但“三个1”的确是很好的风向标，能提是好的。
4、建立配套的管理流程
没有流程护航的制度容易变形，为了确保数据共享管理办法的有效落地，至少需要建立四个保障流程，这些流程可以同步写进办法的实施细则。
流程一：开放账号申请流程
每个部门在企业权限矩阵中要有角色，这个角色决定了数据访问的权限，因此需要建立一个开放平台的账号申请流程，部门员工可以去申请这个平台的账号并授予部门的角色从而能获得所需的数据，需要说明的是，数据开放面向的对象是部门这个组织，而不是个人，部门要为这个账号的使用负责。
流程二：数据目的端申请流程
部门在数据开放平台订阅数据（数据文件，非API）后，平台需要将数据文件推送到一个受信任的部门数据库，这个部门数据库需要有独立的申请流程，至少要获得信安和IT等部门的授权。
流程三、数据上架申请流程
数据上架会涉及到敏感数据的评估，数据资产目录的变更和数据权限矩阵的调整等事宜，因此需要新建审批流程，由领域数据责任人，安全部门，公司数据责任人的共同审批才能发布。
流程四、数据开放申请流程
针对完全开放，可控开放和不可开放三种数据开放类型需制定不同的开放流程，完全开放不需要审批直接推送，可控开放走设定的审批流程，不可开放可以走特殊审批通道。
自己没写过什么管理办法，但回到“三个1”的目标，回到从根子上解决问题的角度出发，我想还是能逐步清晰起来的，管理办法不需要很完美，但必须能匹配实际，能落地执行。
