数据分析团队的结构

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

1.分散于各业务部门的数据分析（分散式）

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

优点：

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

缺点也很明显：

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

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

2.集中于专门的数据分析部门（集中式）

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

优点：

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

缺点：

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

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

数据BP制

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

数据BP：

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

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

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

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

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

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

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

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

End

作者：Joan

来源：知乎