首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >数据团队做什么,看这篇就够了!

数据团队做什么,看这篇就够了!

作者头像
Datawhale
发布2021-10-26 14:55:58
1K0
发布2021-10-26 14:55:58
举报

作者:Louise de Leyritz,译者:追风者

随着企业认识到数据对实现业务目标的决定性力量,大多数企业希望将数据置于其业务和产品战略的主导地位。这就需要建立一个强大的数据团队,能够有效地将其洞察力传播到企业的不同领域。显而易见,这不是一件容易的事。

要做到真正的数据驱动,公司需要建立三种能力:数据策略、数据治理和数据分析。

数据驱动型公司的3大支柱:策略、治理、分析

策略 :数据策略是你的组织利用数据来实现其目标的路线图。它需要清楚地了解业务策略中固有的数据需求。你为什么要收集数据?你是否想赚钱,省钱,管理风险,提供卓越的客户体验,以上都是?

治理 :数据治理是一个流程、角色、政策、标准和衡量标准的集合,它能够确保信息的有效使用,使你的组织实现其目标。一个精心设计的数据治理策略可以确保你公司的数据是信任的、准确的和可用的。

分析:数据分析一词是指分析原始数据的过程,以得出关于它们所含信息的结论。通常情况下,在一个组织中参与数据分析的人员是数据工程师、数据分析师和数据科学家。

最终,你利用数据的能力将取决于这三个支柱。如果你读到这里,意识到你的组织不具备这些,不要担心,这就是本文要解决的问题。一个好的开始是建立一个强大的分析团队,一个与你的企业战略目标紧密相连的团队。它是你的数据组织的第一个支柱,也是这篇文章的重点。

在建立一个数据分析团队时,数据主管通常要解决以下问题:

  • 这个团队应该有多大规模?
  • 有多少数据工程师、数据分析师、数据科学家?
  • 该团队如何与组织的其他部分互动?
  • 数据团队的结构是什么?集中式(中心化模式)还是嵌入式(去中心化模式)?

他们这样做是正确的! 拥有一个强大的数据团队不再是一种奢侈,而是对今天公司的生存起到重要的作用。

不过,让我们从最基本的开始。

01 你在数据旅程中所处什么位置?

在建立一个数据团队之前,重要的是要意识到你在 "数据之旅 "中的位置,因为这将直接影响你的团队结构。因此,这一部分专门用于简化数据成熟度评估。请注意,公司规模和数据成熟度是两码事。你的组织可能很大,但在数据层面却不成熟。

数据成熟度是指从你的数据资产中看到实际价值的过程。我们提出了一个简单的数据成熟度评估框架,在这个框架中,可以衡量你了解的过去,知道你的现在和预测你的未来的能力。我这样说是什么意思?

在大多数公司,每个部门都有自己的一套KPI,以支持企业战略的执行。仅仅定义它们是不够的,还必须清楚地跟踪它们,而且你还必须有能力根据这些关键绩效指标预测未来的结果。这种能力建立在对你现在的清晰了解之上,而这种了解又建立在对过去的深刻理解之上。做到这一点,你就找到了一个简单的方法来评估你的数据成熟度。例如,如果无法确定你的公司的收入驱动因素(你的过去),这意味着你需要在寻求预测未来结果之前,通过为你的业务带来可见性来努力提高数据成熟度。我们不建议跳过这些步骤。这就像马斯洛的需求层次,但对于数据而言。

让我们来看看几个实际的例子:

营销投资回报率:通过使用确定的归因模型,定义你的投资回报率,跨越多个渠道。然后了解它在过去12个月的演变,特别是它的驱动因素(确定执行渠道,一年中的时间,产品等等)。然后通过你信任的报告工具(当前),每天/每周/每月跟踪其演变。根据这些预测模型来预测你的营销预算(未来)。

客户满意度:定义你的客户满意度衡量标准。是NPS还是CSAT?公司的每个人都应该对它的计算方法有一个共同的理解。就像我们前面的例子一样,计算它在过去12个月的变化,找到它的驱动因素(过去)。然后用可信的计量板每天跟踪你的客户的满意度。确定从今天开始要采取的行动来提高它。你对过去和现在的客户满意度的理解将使你能够有效地预测客户的流失(未来)。

了解你的过去和现在通常被称为执行描述性分析。描述性分析通过提供背景来帮助关键利益相关者解释信息,从而帮助组织了解其业绩。这种背景通常以数据可视化的形式出现,包括图形、计量板、报告和图表。当你分析数据以预测未来时,你正在从事预测性分析。预测性分析的想法是采取历史数据,将其输入机器学习模型,考虑关键模式。将这个模型应用于当前数据,并希望它能预测未来。我们将在整个文章中使用描述性分析和预测性分析这两个术语来指代对过去、现在或预测未来的理解。

如果你意识到你的组织还没有完全成熟(即对你的过去和现在没有清晰的认识),这个链接(https://www.castordoc.com/blog/where-are-you-in-your-data-journey)是我们对你的数据团队下一步应该做什么的建议。

2. 数据分析团队中的关键人物

一个数据分析团队通常由四个核心功能组成,详见下文:

  1. 数据工程师:他们负责设计、构建和维护可在数据项目中利用的数据集。因此,数据工程师与数据科学家和数据分析师紧密合作。我们在这里也包括分析工程师这个新角色,尽管在实践中,这个角色介于分析和工程之间。
  2. 数据科学家: 他们使用先进的数学和统计学,以及编程工具来建立预测模型。数据科学家和数据分析师的角色相当相似,但数据科学家更注重预测性分析,而不是描述性分析。
  3. 数据分析师: 他们使用数据进行报告和直接分析。数据科学家和工程师通常在原始或未经提炼的状态下与数据互动,而分析师则与已经被清理并转化为更多用户友好格式的数据一起工作。
  4. 业务分析师/运营分析师: 他们帮助组织改善其流程和系统。他们专注于计量板(dashboard),回答业务问题并提出其解释。他们思维敏捷,跨越IT和业务之间的界限,帮助弥补差距,提高效率。他们经常与特定的业务领域合作,如市场营销或财务,他们的SQL知识可以从基本的计量板分析到高级分析。
  5. 数据分析主管:他们为数据团队提供战略监督。他们的目标是创造一个环境,让所有不同的人都能轻松地访问他们需要的数据,培养企业的技能,从数据中得出有意义的见解,并确保数据治理。他们还充当了数据团队和主要业务部门之间的桥梁,既是远见卓识,又是技术带头人。

3. 团队应该有多大的规模?

不同的公司会建立不同规模的数据团队,没有一个尺寸适合所有。我们研究了300多家公司的数据团队的结构,员工人数在300-1000人之间,得出了以下的见解。

1. 作为一般规则,你的目标应该是在你的公司中拥有总共5-10%的精通数据分析的员工。一些公司,如亚马逊或Facebook,正在培训很大一部分员工,但我们的分析中排除了他们。

2. 一个全新的数据团队的第一批员工通常是数据工程师和数据分析师。仅凭这两个角色,企业已经可以从事一些基本的描述性分析。当建立一个更大的团队时,要从你所需要的技能方面考虑。一个典型的数据项目需要以下技能:数据库,软件开发,机器学习,可视化,协作和沟通技能。具备所有这些技能的人是非常罕见的。因此,你应该意识到每个候选人带来了哪些技能。无论你决定雇用多少人,你的团队最好能涵盖这一技能组合。你在数据旅程中的位置也会影响到你在哪个阶段雇用的人。一般来说,数据分析师专注于了解过去。也就是说,他们利用你所拥有的数据,试图了解增长的驱动因素和其他指标。商业分析师/职业分析师是面向现在的。最后,数据科学家专注于预测未来的结果。因此,如果你在理解你的过去方面有困难,请雇用一个数据分析师,而不是数据科学家。

3. 最终决定数据团队规模的是业务问题陈述的数量和最严重问题的复杂性。查看路线图的规模,确定你需要多少人在合理的时间内完成你的数据项目。如果你意识到你的数据团队需要一年以上的时间来完成项目,那么可能是时候扩大团队了。我们还鼓励您查看运行和构建比率。你的数据团队成员在处理日常业务运营时会“运行”,重点关注组织的当前绩效。他们在从事长期项目时会“构建”,例如为产品添加新功能。你的数据团队应该有2/3的时间是在运行,1/3的时间是在构建。如果你的数据团队把所有的时间都花在了日常需求上,这就会危及到公司的未来,可能是时候扩大团队了。

4. 最后,你可能要做一些针对项目的招聘。如果你是一家金融科技公司,正在进行一个关于欺诈检测的项目,或者是一家专门从事物流调度的公司,你可能想聘用一个了解你的行业具体情况的人。

4. 数据团队如何与公司结合?

对于分析团队来说,没有完美的结构,你的结构很可能会多次改变。如果你的数据团队结构在过去两年没有变化,那么它很可能是一个次优的结构。为什么呢?因为你的公司的数据需求正在快速发展,要求你的数据团队的结构进行调整。同时请记住,你的组织越是静态,下一次改变就越难。出于这个原因,我们不会规定一个给定的结构,而是介绍最常见的模式以及它们如何适合不同类型的企业。

构建数据团队的第一步是找到组织中已经存在的数据人员。他们可能不只是头衔中带有“数据”一词的人,还可能是任何不惧怕数据分析或已经具备 SQL 技能的员工,例如业务分析师/运营分析师,例如业务分析师/运营分析员。如果你不花时间仔细定位预先存在的数据人员,你很可能最终得到一个没有计划的数据团队结构,不太可能适合你的业务需求。

4.1 中心化模式/集中式模式

中心化模式是最容易实现的结构,它通常是以数据驱动为目标的公司的第一步。然而,这种模式也有一些缺点,下面会提到这些缺点。这种结构通常会导致一个集中的数据 "平台",数据团队可以访问所有的数据,并在各种项目中为整个组织服务。这个团队中的所有数据工程师、分析师和科学家都由数据主管直接管理。在这种结构下,数据团队以顾问/客户类型的关系,向基于业务部门的数据利益相关者进行虚线报告。

这种灵活的模式可以适应不断发展的企业的需求。如果你正处于数据之旅的初期,也就是说,你还在努力对你的过去和现在有一个清晰的认识,这就是我们推荐的结构。数据团队的第一个项目将寻求为企业带来可见性,确保你的组织中的所有部门都有他们可以信任的关键绩效指标和计量板。这种结构特别适用于可重用性和数据治理很重要的分析。

优势

✅ 数据团队可以帮助其他团队的项目,同时为自己的议程工作。

✅ 该团队可以对整个公司的项目进行优先排序。

✅ 在一个集中的团队中,人才和技能的发展有更多的机会。事实上,数据团队从事的项目种类更多,数据工程师、科学家和分析师可以从同行的见解中受益。

✅ 数据主管对公司的战略有一个集中的看法,可以将数据人员分配到最适合他们能力的项目中。

✅ 鼓励职业发展,鼓励职业发展,作为数据工程师、数据科学家对资历角色有明确的看法。

缺陷

❌ 数据分析团队和其他业务部门之间脱节的几率很高。在这种模式下,数据工程师和数据科学家没有沉浸在其他团队的日常活动中,使他们难以确定要解决的最相关问题。

❌ 分析小组有沦为 "支持 "职能的风险,其他部门不承担其责任。

❌ 当数据团队为其他业务部门服务时,其他业务部门可能会觉得他们的需求没有得到适当的解决,或者觉得规划过程过于官僚和缓慢。

4.2 去中心化/嵌入式模式

在一个分散的模式中,每个部门都雇佣了 "自己的 "数据人员,同时拥有一个集中的数据平台。在这种模式下,数据分析师和科学家专注于他们特定的业务部门所面临的问题,与公司其他领域的数据人员很少互动。在这种结构下,数据分析师直接向他们各自业务部门的负责人报告。

优势

✅ 由数据人员组成的嵌入式团队是灵活的,反应迅速的,因为他们致力于各自的业务职能,并拥有良好的领域知识。

✅ 产品经理可以将数据任务分配给最有资格从事这些工作的人。

✅ 商业数据团队不必为建立他们的数据项目而争夺资源,因为资源就在团队中。

缺陷

❌ 缺乏真实来源,数据内容重复。

❌ 由于不同团队之间缺乏沟通,数据人员最终会在多余的问题上工作。

❌ 筒仓的建立导致生产力的削弱,因为数据人员不能像在集中式模式中那样利用同事的专业知识。

❌ 这种模式使得在不同的项目上优化配置数据人员更加困难。

❌ 通常缺乏技术背景的业务经理会发现很难管理数据人员并了解他们的工作质量。

4.3 卓越中心/联合模式

联合模式最适合那些已经达到数据成熟度、有明确的数据战略并从事预测性分析的公司。

在卓越中心模式(COE)中,数据人员被嵌入业务部门,但仍有一个集中的小组提供领导、支持和培训。如果数据分析师和科学家被部署在各个业务部门,你仍然会有一个数据领导(或根据公司规模有一个核心的数据领导),负责优先处理和监督数据项目。这可以确保最有利的数据项目被首先处理。

这种策略最适合于具有明确数据路线图的大型企业规模的公司。卓越中心的模式需要一个更大的数据团队,因为你在COE和不同的业务部门都需要数据科学家。如果你是一个小型或中型公司,你的需求可能不需要这样规模的数据团队。

这种方法保留了集中式和嵌入式模式的优点。它是一个更加平衡的结构,在这个结构中,数据团队的行动得到了协调,但也保持了数据专家在业务部门的嵌入。

同样,了解你的数据人员是谁非常重要。当在你的数据之旅开始时建立一个集中的团队,确保你没有业务分析师/操作人员嵌入到其他部门。否则,你最终将得到一个不需要的混合模式,在你的组织中造成完全的混乱。当创建一个COE时,你需要确保它是想要的和计划好的。

优势

✅ 卓越中心模式提供了集中式和嵌入式模式的优势。

缺陷

❌ 这种模式需要额外的协调和沟通,以确保COE和业务部门之间的一致性。

❌ 不适合中小型组织,所以这些公司可以将其与这种中心辐射模型带来的好处挂钩。

原文链接:

https://www.castordoc.com/blog/how-to-build-your-data-team

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-10-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Datawhale 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 01 你在数据旅程中所处什么位置?
  • 2. 数据分析团队中的关键人物
  • 3. 团队应该有多大的规模?
  • 4. 数据团队如何与公司结合?
    • 4.1 中心化模式/集中式模式
      • 4.2 去中心化/嵌入式模式
        • 4.3 卓越中心/联合模式
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档