勇敢的第一步
近几年来，数据驱动变革的呼声很高，各个行业的许多企业，每天都在发生着数据驱动变革的事情，见的最多的打法是，企业一边借鉴别人的成熟经验，一边探索适合自己的方法和套路。
“为了盘活数据资产，赋能业务和管理，我们成立了数据团队”。
这是一家企业的真实案例。
听到这些时，经常会感受到对方迈出第一步时的勇敢，和对变化抱有的乐观期望，不仅如此，对方还会给出更多的事实，企业开启数字化转型，已经有一段时间了，上上下下对于变革已基本接受，甚至在行动上也看到了配合和支持。
数据团队成员来自于三个部分，一是原有的IT团队，大部分java背景，对数据和智能技术好奇且有兴趣；二是数仓团队，运维和报表开发经验；三是新招聘的数据科学家。
企业自己做到了突破零，但接下来我也做好了心理准备，听对方讲零突破之后的那些事情。
问题总会在那里
团队虽然成立了，但是，遇到了几个问题：
除了新招聘的数据科学家，大部分的成员身处两个团队，分身乏力，时间和精力分配很成问题。
应用开发和数据开发，能力上存在巨大鸿沟，如何做数据建模，如何获得数据库和数据架构的能力，是个问题。
高价聘请数据科学家，开发了一堆算法，实际上没有用起来，因为拿到数据难，部署算法难，理解业务难上加难。
总的来说，建团队容易，盘活团队难，要使团队产出成效，有一系列的问题需要解决，也有许多的障碍需要克服。
所以就会回到这个问题：当我们谈数据驱动变革的时候，如何让变革真正地发生？
先从理解工作机制开始
组织变革，通常会涉及到战略调整、业务重构、科技赋能、组织升级等话题，数据本身不会带来直接的变革，数据驱动变革，是通过改变人们理解和使用数据（技术）的方式，改变人们的合作方式，从而更好的支持业务和组织的发展而发生的。
数据如何在这个过程中发挥作用，可以通过这样一个简单的图示来理解一下，不同的区域代表不同性质的工作内容。
巧妇难为无米之炊，数据驱动的变革架构，来自最底层的支撑有两个，一是要有数据，二是要有与业务相关的场景，之所以这样设计，原因之一是脱离业务的数据没有价值，之二是业务场景牵引的数据获取和处理能避免不必要的工作和浪费。
最底层的工作，一部分偏技术，一部分偏业务，但两部分之间有重叠，那便是对数据的理解，技术人员通过理解数据更好的理解业务，业务人员通过理解数据更好的识别并拆解业务问题，在这个区域里面，两种角色紧密的协作，更好的保证了数据的有效利用和最有价值业务场景的识别。
在这基础之上，是数据工作的第二层，基于数据和对业务的理解，进行数据分析，产出洞察，在算法的辅助下，制定和优化决策，这一层的目标是完成从数据到信息的加工，并将价值投射到业务上面。
但这一层还不具备友好的业务体验或者用户体验，因为这一层的产出物可能是个报告，也可能是个报表，或者算法模型。
对于业务、市场、用户来讲，这些结果或者理解起来还存在一定难度，或者说不能拿来即用，所以价值呈现到这里还远远不够。
因此需要更上一层的集成、包装或者展现。
到了第三层，业务用户可能会得到一个集成了智能模块的应用系统，也可能会拿到一个工程化的智能应用软件，第二层的产出结果会被封装整合在这些应用里面，有了软件工程的加持，这一层的软件会有可视化的界面和友好的用户体验，到此，数据经过几层加工，”悄无声息“的融入进了业务里面发挥作用。
仍然，这还没有结束。
数据驱动变革的本质还是变革，变革不等同于开发了一个应用软件，而是在这之上给业务、管理、生态、价值链带来的结果，哪些结果是从零到一的突破，哪些结果是基于以前状态的优化。
这其实是一个商业故事，也是当变革发生时，能讲给人听且易于让人理解的那部分内容，这也是第四层的内容。
至此，从数据到变革的发生，有了一个四层的架构。
做事情，离不开团队、角色和能力
这几层的工作内容，依赖不同的专业知识，相应的也就需要不同的角色。
第一类角色，数据工程师，数据技术和平台的工作内容对数据工程师有很大的依赖，这部分的工作内容包含数据获取、数据处理、数据基础设施和运维、数据架构、数据安全、数据质量等相关的工作，获取和处理的数据量通常来讲还是大批量的，所以这部分的工作不仅依赖于技术手段，还依赖于对工具的熟悉和掌握，这是数据工程师的技能要求，不仅要具备技术和工具能力，还要懂数据工程。
第二类角色，数据业务分析师，有业务背景，熟悉业务，能够把业务的问题进行识别和拆解，同时也具备一定的数据思维和数据分析能力，这个角色对业务和产品有很好的感知，熟练掌握一些需求分析和产品设计的方法论，对领域建模、数据分析有很好的理解和经验，除此之外，还能和各种角色进行顺畅的沟通，分析问题、识别重点、规划场景，将痛点和需求转化为可以通过数据技术或者数字化手段解决的任务，这个角色是衔接业务和数据的桥梁
第三类角色，数据科学家，基于数据做进一步的挖掘和分析，产出洞察和模型，这个角色需要具备一些核心技能，比如Python/R语言，需要在理解业务指标的基础上构建特征工程，开发机器学习深度学习模型，并不断基于场景和条件调试优化模型，必要的时候还需要将数据分析或者模型产出的结果以可视化的方式呈现出来。
基于不同企业的背景和上下文，这几种角色在不同的企业可能还会有不同的定义，但核心工作内容是相对确定的，有了工作内容和能力的定义，能力建设就有了重点和方向，关于如何进行能力建设和赋能，这是另外一个话题，可以参考《谈谈数字化转型中的赋能》。
除此之外，在转型之初，角色的定义和团队的创建也需要摸索一段时间，很多时候，角色很可能会来自不同的团队。
因此，协作机制很重要
这是成事的关键。
虽然成立了团队，配备了角色，有的团队以实体形式存在，有的以虚拟形式存在，但在相当长的一段时间内，团队可能会比较脆弱，此时如果任由团队自生自灭或自我摸索，团队极有可能有名无实，说好的数据驱动变革，最终可能只会落实在口号上。
所以，组织需要出台一系列的机制来保障团队的存在、运转和成事，通常来讲，这套机制包括三个方面的内容。
首先，团队要有目标，目标解释了团队为什么存在，定义了团队的工作目标，和团队要解决的问题，这是团队存在的价值和使命，指导团队的行动，帮助团队在面临选择时，判断事情的优先级。
现实中，定义目标不困难，困难的是做事的过程中始终保证团队对目标有一致的认识，这就需要团队频繁拉通目标，甚至根据阶段性产出对目标赋予不同的含义，之所以这样做，是因为个体对于方向的理解会随着事情的推进有所变化，产出不同的解读，如果团队对于目标的理解不一致了，”人心“会散（三声），团队会散（四声）。
其次是激励机制，团队成员的时间，尤其是身兼数职的团队成员的时间如何分配，职责如何定义，工作的产出如何评估，这都关系到跨团队成员的投入和激励问题。
再次是协作机制，角色与角色之间是流程式还是重叠式协作，哪种方式最利于高效解决问题，也需要识别和定义，这是多角色跨团队工作的关键。
拿数据科学家与数据工程师来说，前者需要后者的协助来做大数据量的清洗、计算等复杂处理，后者需要前者的领域知识赋能，从而更好的理解数据和高效的处理数据，所以这两个角色之间既有分工，又有相互的协作；
再看数据科学家和数据业务分析师，前者需要后者的帮助来更好的了解业务问题、拆解业务问题、识别业务场景，后者需要前者的产出结果去解决问题、赋能业务，以及更好的讲故事，他们的协作模式也是有分工有协作；
数据工程师和业务分析师，也有许多协作的空间，后者理解业务痛点和诉求，将之拆解成技术人员可以理解的业务问题，前者理解数据、分析数据、处理数据，双方协作在数据的基础上理解业务，在业务的场景下理解、获取和处理数据，共同对数据平台基础设施、数据架构、数据模型负责。
甚至这三个角色也需要共同协作，来理解并推进数据治理、数据运营，共同识别、设计场景，促进数据价值的变现。
现实中，因为技术壁垒的存在、领域壁垒的存在、团队归属的问题，角色间两两合作会存在困难，跨团队的合作更是充满挑战，这是协作机制要解决的问题之一，也是数据能力赋能要解决的关键问题之一。
小结
"数字化转型之所以不成功，往往不是技术能力的问题，而是组织和团队不具备相应的能力来支撑转型"。— 杨国安《数智革新》
当我们谈数据驱动变革的时候，很多话题和行动也是围绕着组织和团队能力的建设展开的，这些行动既包括识别、培养和激励人，也包括建立有效的协作机制，打造既懂业务又懂技术和数据的项目团队，还包括一系列的培训和反馈机制，学习新工具、新方法、新思维，直到这些行动推动了变革的发生。
道且阻长，行则可至！
