浅谈数据分析团队该如何分工

文章开篇先介绍两种互联网行业常见的组织架构，一个是事业部制，一个是职能制，这背后是管理思维的体现，跟业务发展的阶段相关。我更喜欢事业部制，互联网行业更常见的也是事业部制，这一组织架构反映灵活，更适应瞬息万变的互联网发展环境。

事业部制

组织架构往往是事业部制与职能制交叉，第一级部门按照事业部分设的是事业部制，每个事业部内部可以选择按照事业部制还是职能制进行管理。事业部制下每个事业部是独立经营，可以自闭环，即产品、运营、研发、测试、数据等人员齐备，HR、行政和财务是BP给事业部，集团从宏观层面把控事业部的方向和运作方式即可。事业部制适合快速发展期的企业，典型：今日头条、新浪微博（按垂类方向划分组织架构，向纵深发展，获得更多的发展机会）。事业部制示意图（仅一级部门）：

职能制

第一级部门按职能划分部门的是职能制，职能制下完成一个产品或一个项目，是需要很多跨部门协作的。事业部制业务发展成熟后，会出现重复工作较多/浪费资源的问题；容易本位主义，忽略本业务与其他业务间的关联关系。近几年从阿里开始，出现中台这一词汇，本质是不同条线研发以及数据结耦，来提升效率，这便是事业部制下结合职能制的体现。一般公司不会完全采用职能制，因为职能制会影响部门间的协作效率，为了增强主人翁感，加强协作，有些公司会实行双线汇报，即本职能部门和业务部门双线汇报，但又会衍生出问题，一旦出现双方领导建议不一致，下属无所适从，所以现在公司完全采用职能制的很少。更多的是存在与事业单位或国企。

职能制示意图：

我的体会

笔者在总裁办就职，分析深度不符合管理层的预期一直是我们整个团队的痛点。

集团的组织架构是事业部制，不仅总部是事业部制，各城市也是区域事业部制。而总裁办的组织结构是职能制，特点是：一个项目，owner设计指标体系大而全，BI根据项目owner需求产出所需数据，负责PPT撰写的小伙伴根据所得数据，写PPT，完稿，然后进行下一个大而全的项目，能按时完成已是加班如山。

长此以往，BI思考的是我如何更高效的支持所需数据；PPT小伙伴思考的是我通过提升PPT内容的精美度、产出的效率和内容的广度来提升文档质量，而管理层要的是分析的深度。组织架构决定了BI和写PPT的小伙伴努力的方向。那么，如果想改变大家努力的方向，达到增加洞察深度的目标，就需要在组织结构上做变更：从职能制调整为事业部制，调动积极性，具体如下图所示。管理层要大而全的内容来看全局本身需求没问题，那么组织架构调整后，深耕某条业务线的一个个小分队，分析深度会远好于职能制。

那么，有没有职能制的分析团队呢，多的是。

• 大数据部。

相信各大公司都有大数据部这样一个部门，这样的部门因为是职能部门，深耕于大数据技术，往往会做出些业务无关痛痒的数据应用，被大家所吐槽。即使是数据中台，也不是完全靠职能部门能完成的，应是与业务紧密结合的团队才能做到。

• 事业部制下，事业部中的数据分析团队

事业部制下按职能制划分较常见，多见于中小型事业部。数据团队如该事业部中的大数据部，业务线提需求，分析师和RD满足需求最最常见，无法调起分析师的主观能动性，业务方也无法强化数据化运营意识与能力，公司的数据化运营名存实亡。

我认为真正能发挥数据在业务中作用的，数据分析团队组织结构应该有如下特点：

• 组织结构与集团（或业务）组织结构耦合。

组织结构反映了管理层在近一段时间发展业务的思路，数据团队想分析作用于业务，应与业务组织结构一致，专人专项。

• 事业部制

1.数据分析师专门服务于某一个业务方向，在该方向不断深入、沉淀、驱动数据化运营，与业务方建立良好的沟通与服务关系，借机驱动业务发展。这也往往是一线的分析师和业务人员最希望的，因为你也遇到过：（1）业务人员我这个需求好急，分析师却在忙于其他事物；（2）分析师做了洞察报告，分享给业务人员，业务人员却歇斯底里地想：需求都没满足好，做什么洞察or这个洞察，common sense啊。

2.即使在职能制下，应该保持事业部制的思维，分析师人员BP给业务方，才能时刻把握业务动向，才有可能产出真正服务于业务的数据产品和分析模型，驱动业务发展。

笔者也见过几个数据研发团队，在业务初期，忙的如火如荼，当数据模块化后，数据中间表覆盖90%的常见需求了，这个团队只剩维护的工作，慢慢只能离职。与业务同行，才能时刻保持对业务的敏感性，才能在数据这条路上长久。

End.

专栏作者原创文章，禁止未经允许擅自转载