大家好！

今天和大家继续聊一聊数据和信息层面的孤岛化现象，关注处于孤岛状态的数据将如何影响业务的正常进行。

引子

处于孤岛化状态下的数据，犹如鲁滨逊漂流记中的那一幕，形形色色的数据如鲁滨逊般漂流到一个个毫无关联的小岛上，互相不知道对方的存在。

同时，这些数据又如一个个正在自谋生计，无意中到达与世隔绝之地的物种个体，不得不与其大陆表亲采取分道扬镳的进化方式，独自进化。

一旦数据或信息是实现孤岛化分布的，除了少数重要档案和文件可能由已知的部门管控之外，更多的则会分散在企业的各个部门，或是在每个人的电脑中，很多当事人自己可能也并不清楚，或是在每个人的大脑中，离职后将消失殆尽。

当我们的数据处在孤岛化状态时，我们无法知道目前有哪些数据存在，也无从得知数据从哪里来，到哪里去，更不清楚和谁确认相关事宜。

这种情况会让协作中充斥着各种不确定性，进而造成了协作结果的不确定。

这里举一个典型的例子，某集团的商务部门根据高层管理者的要求，需要梳理出一份面向某外部投资机构的商业计划书，由于这个工作比较重要，因此委派了该部门的一员专门写商业计划书的大将。

商业计划书是典型的协作产物，里面包含很多信息，如企业的商业模式、核心产品、解决方案、团队组成等等数据，而这些数据往往分散在不同的团队中，很多最新的状态信息也需要通过前线团队来进行了解。

在这一点上，孤岛化现象的程度将给数据收集的过程带来不同影响。下面，我们通过一正一反两个案例，来看看数据的孤岛化究竟会带来怎样的影响。

数据未孤岛化的情况

在没有数据孤岛化现象的企业中，这一工作的开展是非常高效的。

首先，各团队间的职责分工非常清晰，每个人都能知道自身和协作方的工作边界，因此，此次商业计划书的负责人能够非常精准地找到SME（原始素材提供方），成功获得所需信息。如果信息的介质是一篇文档，那么往往会提供一个文档链接。

然后，基于SME分享的文档链接，负责人可以在企业的SaaS协作平台上迅速定位到此文档（在更具开放度的企业，员工也可以直接输入关键词，自主定位到自己权限下的所有文档），获取信息。

日常情况下，该文档的内容会由相关人员进行整理和维护，假如每个团队都具有良好的版本管理意识的话，那么既能确保当前提供的是最新的版本，同时也能追溯到过往的修订记录，以备不时之需。

更进一步，在查阅该文档的过程中，负责人一旦发现目前的信息并不充分，还需要更多信息的话，可以和相关SME进行主动沟通，然后由SME对原始数据文档进行补充和更新，这样既能用于当前的商业计划书工作，又能使这篇文档本身得到“进化”，进一步提升未来的协作效能。

甚至，针对于这一项工作，我们可以在SaaS协作平台上新增一个由相关同事组成的临时协作空间，用于信息的共建和相互分享。

在该协作空间中，由此次商业计划书工作的负责人进行统一建设和维护，预先设计一张针对各模块的信息收集表，由相关同事对号入座进行填写，将自己所知的数据和信息同步补充至同一个表格中来，快速形成一份完整的原始数据文档。

基于这些信息，商业计划书的负责人就可以正式开始进行设计工作了，整体完成周期也会大大降低。

这里我补充一点，在数据的分享和传递阶段，我们并不需要过多在乎形式，只需要保持数据的结构化形式即可，最终输出的商业计划书是由文档专家进行专业视觉转化的产物。要确保良好的输出，其实只需要保证源数据的完整与准确即可。

数据孤岛化的情况

对于上述的协作过程，看起来是一气呵成，非常顺畅，但在其背后是有企业文化和制度的保障，也有每个人自驱的协作意识，没有这些从上到下的协作意识的话，也没有数据共享机制的话，这样的协作根本无法实现。

下面我们来看看，数据孤岛化下的协作又会是怎样的。

首先，在开展这一任务时，负责人几乎是无从入手的，虽然他的经验足够丰富，了解商业计划书所需要的内容，但他并不清楚如何获取这些内容的原始数据，也无法在一开始便知晓谁是合适的SME。也许需求方会提供一些初始信息，但这些信息是否准确，出处如何，往往连自己也说不清楚。

这个时候，商业计划书的负责人只能像“推理探案”一般找寻相关的SME，先从需求方这里挖掘一些他所知的SME信息，然后与各相关部门的领导进行确认，了解究竟有哪些SME。

然后，负责人就需要与这些潜在的SME进行沟通，获取信息。在沟通的过程中，可能会出现SME变更的情况，也可能需要追加新的SME来提供更多信息的情况。在这一阶段，沟通会消耗大量的时间，也会在沟通上调动大量的同事。即便如此，也没有办法保证SME的“穷尽”。

当素材最终磕磕绊绊收集到了之后，还需进行整理，因为这些素材往往并没有经过良好的版本管理，一般都是从自己电脑中随意拿出来的一个版本，遵循每个人自己的版本管理策略，因此往往会是过程稿，遗留着各种修订信息。

这个时候，负责人需要再次和SME进行沟通和确认，直至拿到符合要求的源数据。

基本信息均确认完毕后，就可以由文档专家进行初步的PPT设计了，但在完成设计后，企业内部没有公共平台可以上传，只能通过邮件或即时通信工具发送到各位SME，由其对内容的完整性进行确认。

当所有SME都确认和修改完毕后，再次对其交付的修改稿进行整合，最终完成交付。

在整合过程中，往往也会在重新设计上耗费较多时间，因为PPT和其他文档介质不同，即使是微小的内容改动，往往也会带来视觉上的较大改动，甚至是重新设计，特别是对于视觉要求比较高的商业计划书。

我们也会经常看到这一现象，在即将完成或者发布之后，并且已经进入后续工作流程时，突然间会跳出来一位SME，说自己这里有最新的信息，或者是有一位员工临时得知了这一工作，主动认领了SME，并依然从自己的本地电脑里拿出相关文件，这样又会带来更多的版本迭代。

通过上述对比，我们可以非常明显看出，数据的孤岛化会给协作带来非常大的障碍，不仅大大提升了过程中的沟通成本，还会使最终呈现结果的准确度和完整性上大打折扣，或者说充满风险。

在下一篇文章中，我将和大家探讨人性带来的孤岛化现象。敬请期待！