如何建立你的数据分析团队?

157 阅读17分钟

并与你的组织成功整合

图片来自Castor网站

同行评审:Kat Holmes- ITV数据总监

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

为了真正实现数据驱动,公司需要建立三种能力:数据战略、数据治理和数据分析。

数据驱动型公司的3大支柱 - 图片来自Pitch

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

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

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

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

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

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

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

让我们从最基本的开始。

你的数据之旅在哪里?

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

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

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

数据需求层次 - 图片来源:Louise de Leyritz

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

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

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

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

如果你意识到你的组织还没有完全成熟(即你没有清楚地了解你的过去和现在),下面是我们对你的数据团队下一步应该采取的建议。

数据分析团队的关键人物

一个数据分析团队通常由四个核心职能部门组成,具体如下。

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

这个团队应该有多大?

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

  1. 作为一般规则,你的目标应该是在你的公司中拥有总共5-10%的精通数据分析的员工。一些公司,如亚马逊或Facebook,正在培训很大一部分员工,但我们的分析中排除了他们。
  2. 一个全新的数据团队的第一批员工通常是数据工程师和数据分析师。仅凭这两个角色,企业已经可以从事一些基本的描述性分析。当建立一个更大的团队时,要考虑到你所需要的技能组合。一个典型的数据项目需要以下技能:数据库,软件开发,机器学习,可视化,协作和沟通技能。具备所有这些技能的人是非常罕见的。因此,你应该意识到每个候选人带来了哪些技能。无论你决定雇用多少人,你的团队最好能涵盖这一技能组合。你在数据旅程中的位置也会影响到你雇用的人和哪个阶段。一般来说,数据分析师专注于了解过去。也就是说,他们利用你所拥有的数据,试图了解增长的驱动因素和其他指标。商业分析师/职业分析师是面向现在的(仪表盘)。最后,数据科学家专注于预测未来的结果。因此,如果你在理解你的过去方面有困难,请雇用一个数据分析师,而不是数据科学家。
  3. 最终应该指导你的数据团队的规模的是业务问题陈述的数量和最严重问题的复杂性。看看你的路线图的规模,确定你需要多少人在合理的时间内完成你的数据项目。如果你意识到你的数据团队需要一年以上的时间来完成项目,那么可能是时候扩大团队了。我们也鼓励你看一下你的运行与构建的比例。当你的数据团队成员从事日常业务操作时,他们会 "运行",专注于组织的当前表现。当他们从事长期项目时,如为产品添加新的功能,他们就会 "构建"。你的数据团队应该有2/3的时间是在运行,1/3的时间是在建设。如果你的数据团队把所有的时间都花在日常需求上,你就会危害到公司的未来,可能是时候扩大团队了。
  4. 最后,你可能要做一些针对项目的招聘。如果你是一家金融科技公司,进行一个关于欺诈检测的项目,或者是一家专门从事物流调度的公司,你可能想雇用一个了解你的行业具体情况的人。

数据团队如何与公司整合?

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

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

集中式模式

数据团队的集中模式 - 图片来源:Louise de Leyritz

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

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

优势

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

该团队可以在整个公司范围内确定项目的优先次序。

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

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

鼓励职业发展,因为数据工程师、科学家们都有明确的资历角色观点。

缺点

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

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

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

分散/嵌入式模式

数据团队的分散模式 - 图片来源:Louise de Leyritz

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

优势

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

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

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

缺点

缺少真相来源,数据内容重复。

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

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

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

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

联合模式/卓越中心

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

卓越中心模式l- 图片来源:Louise de Leyritz

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

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

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

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

优势

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

不过,它仍然有一些缺点。

缺点

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

❌ 不适合中小型组织,所以这些公司可以把它与这种中心和辐条模式带来的好处挂钩。

最后的话

如果你的公司要成为数据驱动的公司,建立一个强大的分析团队是你需要建立的一个关键支柱。你从数据中提取商业价值的程度最终取决于这个团队的实力,以及它与你的其他业务部门的共生关系。对于你的数据团队的规模、组成和结构,没有现成的建议。这就是为什么你需要了解你的组织的数据成熟度,这样你就可以建立一个适合你的业务需求并与你的业务战略相一致的数据团队。

在Castor,我们写了关于利用数据资产时涉及的所有过程:从现代数据栈,到数据团队的组成,再到数据治理。我们的博客涵盖了从数据中创造有形价值的技术和非技术方面。

在Castor,我们正在为Notion, Figma, Slack这一代人建立一个数据文档工具。或者为Fivetran, Looker, Snowflake, DBT爱好者提供数据方面的服务。我们把我们的目录设计得很容易使用,令人愉快和友好。

想看看吗?请联系我们,我们将向您展示一个演示。

原文发表于 https://www.castordoc.com.


如何建立你的数据分析团队?最初发表在Medium上的Towards Data Science,人们通过强调和回应这个故事继续对话。