随着市场的逐步成熟，要想保持企业的长期竞争力，运营和产品改进工作需要越来越精细化。
比如，在游戏行业，玩家留存率是一个关键指标，为提升·留存率，需要精细化地分析玩家是哪一步流失的，根据游戏进程推进过程，按照先后顺序设置关键节点，分析各个节点流失情况数据，可以形成一个玩家流失漏斗。有了玩家流失漏斗，我们可以选择流失率高的环节进行进一步精细化分析，找到流失原因，比如机器适配问题，引导缺乏吸引力问题，数值设计问题等，根据这些原因就可以针对性的在产品和运营侧做改进了。
image
又比如保险行业，为了提高销售效率，可以先通过模型预测用户的销售响应率，然后将用户划分为几等，分别交由不同级别的销售人员跟进。我们现在在谈论的用户画像，产品画像，增长黑客，或者个性化推荐等等，其本质上其实都是在实现更精细化的运营或产品改进。
精细化产品改进和运营对企业应用数据的能力提出了很高的要求，因为这些改进决策的制定不能全凭经验，它们很大程度上还需要建立在坚实的数据分析结果之上。
企业应用数据的能力可以简称为企业数据能力。从整体上看，它应该是由企业数据驱动业务的文化、具有特定技能的人及具有特定功能的IT系统共同构成。
既然市场对于企业的数据能力要求越来越高，那么要如何建设数据能力呢？
为了尝试回答这个问题，我们先看看主要有哪些数据工作内容。
数据工作内容
回顾上面的玩家留存率分析过程，可以发现主要有三部分工作：
- 寻找数据
- 加工数据
- 分析数据并提出产品改进的建议
如何支持这三部分工作呢？也可以从三个方面来看：
- 数据的日常维护和管理。它将包括数据仓库/数据湖的建设，数据质量、标准、模型、安全等数据治理内容。这将提高寻找数据的效率，保障使用数据的安全。
- 针对特定问题的数据分析。包括基于业务的各种指标计算，建模分析等。
- 数据管理及分析过程中的相关工具及平台。这将辅助进行数据管理和数据分析。
为什么是这三个方面呢？事实上，这三个方面分别对应了三个不同的专业领域，它们需要的技能很不一样，企业内部甚至常常需要分成不同的团队来支持。数据的日常维护和管理需要数据工程能力，数据分析需要的是分析和建模的能力，工具平台的开发则需要软件开发能力。
其中，工具平台研发和前两者的相关性很高。
数据管理工作除了包含大量的规范文档定义、流程设计、沟通宣导之外，要在企业内部实现落地则是可以通过工具平台内建流程来支持。事实上这种方式越来越成为一个企业数据管理的演进趋势。这样一来，企业内部往往可以只设置少量数据管理专家，然后通过配合一个数据工具平台研发团队来实现数据管理。举个例子。比如对于数据质量管理，数据管理专家可以针对具体的业务数据定义专用的数据质量规则，如空值规则，值域范围规则等。通过数据平台可以将这些规则进行落地（规则脚本化并配置到平台）。然后数据平台定期运行相应的质量检查脚本来生成数据质量报告或发出数据质量告警，从而指导团队进行数据质量改进。
数据分析工作同样离不开工具平台的支持。即便简单的能通过sql查询实现的分析工作，也至少需要提供一个查询界面，随着分析工作日渐复杂，直接粗放的使用数据库工具来支持会显得越来越吃力和低效。事实上，一般我们会将这里的分析进一步细分为即席查询分析，定期报表，实时报表，建模分析，线上模型推理等内容。想要较完善的支持这些分析工作，没有一个高效的工具平台支撑是很难完成的。甚至业界常常采用数据平台和机器学习平台双平台来进行支持。
这三方面的工作可以图示如下：
image
从前面的分析来看，企业除了要从需求端发展数据管理能力和数据分析能力，工具平台的建设也是必不可少的，工具平台成熟程度常常与数据管理和数据分析的效率正相关。随着企业的逐渐发展壮大，工具平台往往越来越成为其数据能力的核心内容。这集中体现在工具平台越来越难以满足数据管理和数据分析的需求，大量的工具平台定制化需求被提出。
不同的企业具体情况不同，这三个方面的工作量及对应的人员需求量也不同。比如，有的企业中，数据相关工具和平台完全来自外部采购，功能相对完善，则可能只需要完成工具平台运维，内部系统集成和管理流程落地，工具平台研发人员也可以尽量减少。而与之相对应，如果工具和平台采用基于开源工具自建，有较多的自定义功能，则往往需要扩大工具平台的研发团队。而有的企业中，如果数据管理人员和数据分析人员拥有较强的软件研发能力（比如大量来自开发人员的角色转型），则工具平台的研发可能直接会合并到数据管理和分析工作中去。
企业数据能力建设思路
基于数据工作的拆解和分析，我们可以尝试从以下几个维度来思考如何进行企业数据能力建设。
第一是数据人才资源建设。
从角色及其能力要求上面划分，可以大致将数据人才资源分为数据工程师/数据架构师，数据分析师/数据科学家。我在另一篇文章中探讨了这些角色的工作范围和能力要求，可以作为这些角色定义的参考。从这里的角色定义出发，企业就可以根据自身具体情况规划出符合自身文化的数据人才资源体系结构，从而在招聘和培养人才上面有一个整体的思路和规划。
第二是人员组织和协作。
有了人，如何才能将大家组织起来，形成合力，做好事情呢？
企业组织结构一般可以分为职能型、项目型和矩阵型。
职能型组织将核心的工作划分为不同的功能部门，如产品，运营，销售，财务，审计等，这些部门按照职责范围大小组成从上到下的层级，最终形成金字塔型的结构。职能型组织结构一个典型的例子就是政府部门和一些传统的大型国企。其优势是利于各部门形成自己各自的专业优势，劣势是难以组成项目组以面向问题的方式解决企业问题（部门间常常合作困难，相互推诿和争利）。
项目型组织以面向项目的方式组成项目组来实现人员组织和协作，其典型的例子是以外包业务为主的服务型公司。其优势是解决问题的效率高，但是不容易积累沉淀组织能力。
矩阵型组织则希望避免职能型组织带来的部门墙问题，在职能型组织的基础上引入项目组织形式，在项目需要时从各职能部门抽调人员形成项目组，由项目组来统一管理。矩阵型组织常常使得某一个角色存在多位领导，从而给员工晋升及工作安排带来问题。实际企业中往往是各种组织形式并存，其中重要的是要注意由于部门划分带来的部门墙，它对于工作效率常常带来巨大的负面影响。
image
对于刚起步的小型企业，人才资源有限，往往需要一个人当一个团队用，过于清晰的划分将显得过于重量级而无必要。
对于一个中大型企业而言，可以设立数据部，内部进一步细分为数据管理、数据分析、数据工具平台研发三类角色岗位，形成职能型的垂直组织结构。然后，从各类细分角色抽调一部分人组成项目组以支持业务线数据分析工作。这样一来，便形成了矩阵型的组织结构。
以上简要的做了组织结构分析，要想做好数据工作，还涉及很多需要更多智慧的管理工作细节。
第三是工具平台建设。
为什么要单独谈工具平台建设呢？因为工具和平台往往是数据能力的依托和沉淀。数据管理中的标准和流程需要工具平台的支持否则很容易变成空中楼阁。而数据分析的无数脚本也需要有机沉淀，并需要在组织内交流和分享，否则就只是数据分析师自身的能力而已。
一般而言，工具平台的建设有三种模式：
- 外部采购。时间成本可以节省不少，但需要注意采购的产品的功能边界，并注意该产品是否可以和内部系统有效集成，是否可以支持灵活的功能定制。
- 自建。一般考虑根据开源的项目进行改造，这样的方式的优势是可定制能力极强，其劣势就是需要大量的相关人才并需要一定的时间周期。
- 还有一种中间的方式，那就是采购产品的同时采购定制化服务，或者和第三方技术公司合作在开源产品上联合开发定制所需功能。
对于这些不同的工具平台建设模式，不同的企业会做出各自的选择，但是长远来看，一个技术驱动的企业一定对可定制能力有很高的要求，所以可定制能力将是一个必选项。
另一方面，从功能上来看，采购的产品和服务往往难以完整的实现企业特定的数据管理和分析需要，可能要考虑基于这些产品提供的api来进行定制化开发而舍弃掉它们提供的功能界面。
比如，如果我们用aws的数据服务，数据质量管理如何实施呢？这时可能需要基于aws的api来开发一个质量管理的工具，通过定义质量规则，配合定期的质量检测任务调度来实现。
所以，开发一个企业自己的数据平台界面可能是企业数据工具和平台建设的关键一环。这个界面相当于定义了企业自己的数据工作接口，而采购的服务是这一接口的某个具体实现。
接口的定义往往比实现更重要，因为会有太多的企业资产依赖这样的接口去实现，比如大量的etl脚本。接口就如同电脑主板的插槽，接口定义好了，企业就可以按照自己的方式去设计主板布局及开发上层软件，主板布局和上层软件构成了企业的核心资产和竞争力，而某个接口的具体实现，比如摄像头、内存或硬盘，则应该可以较为轻松的替换而不影响企业主要业务。
总结
总结一下，以上内容从数据工作做什么出发简要分析了企业如何进行数据能力建设，结合以往经验从三个方面（人才资源建设、人员组织合作、工具平台建设）分享了一些自己的认识。
文/Thoughtworks廖光明
原文链接：https://insights.thoughtworks.cn/enterprise-data-capability-building/
更多精彩洞见请关注微信公众号Thoughtworks洞见。
网友评论