数据分析团队的结构

爱职场
爱职场
爱职场
358
文章
0
评论
2020-04-1803:05:00 评论 540 1450字
摘要

数据分析人员要怎样分配,才能既满足各个业务方的需求,又能使团队本身价值最大化?

这是我最近常常在想的问题,从事数据分析多年,做过业务部门内部数据分析,也呆过专门的数据分析部门,总感觉两种形式都有些天然的缺点和局限。

1.分散于各业务部门的数据分析(分散式)

分析师属于具体业务部门,与需求方待在一起。比如,做运营分析与运营人员在一起,通过运营团队,向COO汇报工作。做营销分析与营销人员在一起,同样也是通过营销团队向营销负责人汇报。

优点

  • 更了解真实的业务场景,分析结论及解决方案更有实操价值。
  • 将分析师放在最需要的地方,使他们沉浸在解决问题当中。

缺点也很明显

  • 长期来看,分析人员会遍布在公司各个业务部门,他们技能和背景相似却不属于同一个部门。
  • 分析师长期负责一个固定模块的分析,个人成长空间有限。分析师之间没有任何交流和学习,各部门之间也别指望紧急借人救火。
  • 这种模式下分析人员普遍缺少晋升通道,比如你在运营团队做分析,只有老哥一个分析,升上去管谁?在运营体制下是否有分析的晋升通道,也不太确定。有上升规划的分析师一般不会喜欢这种组织结构,这肯定不是一种吸引人的职业发展道路。

所以,这种分散式的分析结构,可以充当短期解决方案,长期来看并不合适。

2.集中于专门的数据分析部门(集中式)

在公司的组织架构里,只有一支专门的分析团队存在,如"商业分析部",支撑公司所有业务部门的数据分析需求,向COO或CFO汇报。

优点

  • 可以按需分配分析人员。依据各业务方需求的工作量及重要程度,方便合理的调配。
  • 可以给分析人才提供机会,获得跨部门的经验,接触到多种类型的分析,这对分析人员来说是一种挑战,可以快速提升技能。

缺点

  • 离实际业务太远,没有深入到特定的业务场景,最后会造就一批通才。什么都了解,但也什么都范范(这就是为什么,很多商分部门的人给出的解决方案,会被实际业务人员喷"方案是不过脑子拍出来的")。
  • 不同的分析人员,在同一个业务项目中换来换去,对业务部门造成损害。

分散式满足业务方需求,无法保证分析人员发展,集中式配置对分析师和公司长远规划是双赢,但是却无益于业务问题的深入解决,那有没有两全其美的办法?我觉得可以,数据BP制是可以个解决这个问题的很好方案。

数据BP制

类似我们常听到的HRBP,由HR深入的用人具体部门,了解部门业务和人才管理方向,进行一对一的,有针对性的招聘和人才管理培养。

数据BP:

组织架构上,分析人员属于唯一的专业的数据分析部门。

具体工作内容和场景上,属于具体业务需求方。

为什么写数据BP,是有感于之前参与了两个月的数据BP制度,自己总结起来并不成功,原因:

  1. 对内,没有有力的数据技术支撑,导致分析人员还在从事跑SQL导数,做临时数据报表。另外,需求多人员不足也是主要内因;
  2. 对外,没有跟业务方确定划清明确界限,什么应该做,什么不该做。结果,导致我们接了过多低级需求,开发临时报表、验数,导数,而不是对他们更有帮助的分析。
  3. 公司大环境,复杂的环境导致业务方对自己的业务捂的很严实,不希望外部门人了解与参与,业绩不需要你的分析支持。

我想这几个主要的问题,是推行数据BP制的人都要关注的问题。

数据BP制应该是一个过程,在人员不够的情况下,需要一步步慢慢摸索,由个别部门个别案例逐步推广至全范围。

虽然我的参与时间短暂且不太成功,我仍相信数据BP制度,未来会被越来越多的公司认可和普及,尤其是数据底层建设较完善的大公司。

再次强调的是,最重要的不是组织结构,而是让正确的人处于正确的原因做正确的分析。同样重要的是,要创造正确的环境,以便招聘、培养和留住合适的分析人才。

End

作者:Joan

来源:知乎

  • 我的微信公众号
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: