据分析师对一个企业是很重要的，了解数据分析师对一个企业的价值和工作内容也就十分必要了。

  不可否认数据分析师未来10年是一个非常朝阳行业，那么我们回过头来看，就从个人的职业发展来看，数据分析师的成长路径是什么，能力等级是如何划分的，如何成为一名数据分析师等问题，是我们要一一了解的。

  初级公司设计一个数据分析岗位服务其他部门，工作的形式更多偏重于从业务系统中拉取数据，主要在Excel中进行，没有单独的数据仓库，很多时候由技术部的相关研发人员为数据分析人员手工从后台数据库临时写脚本提取。

  第一个我们说的分散式分布，这种在财务部门、市场部门、营销部门和运营部都会有自己的分析师，那么这个分析师可能就是服务他所在的这个部门，处理问题可能就是所在的这个部门问题，这样的一种情况下共用的数据源都来自数据仓库。

  因为你就是业务部门直接的一份子，很清楚这个业务部门的业务情况，以及每天都在做什么内容，因此你对整个业务的流程、业务人员的工作内容、部门的一些问题很清楚。我们把它叫做分散式的业务模型。

  但是也有一些问题，因为你只服务这个部门，所以你看到的数据或者关注的数据，仅限于这个部门，做的一些分析、报告和观点可能会出现一定的偏颇。

  比如你从市场部的角度来看，只关注市场投放有关数据，但是后面市场流量引进来以后，后面那些会员的数据可能看到的就比较少，或者看不到这部分数据。

  分散式业务模型的优点就是对本部门业务很熟悉，很清楚业务部门问题，或者说业务部门需求是什么。

  因为你服务的对象仅限于本部门，而其他部门、其他的业务需求，相对来说的比较少。因此当你做一些分析的时候，结果可能会有偏颇性，或者说不那么的完整，这是缺点之一。

  现在大部分大一点的公司都会有一个部门，叫法可能不一样，有的叫商业智能部，有的叫大数据部，有的叫数据决策，但都是一个独立的部门。这个部门是跟其他部门并行的，甚至有可能是一个一级部门，这个部门绝大多数都是直接向老板汇报，这个部门有一个好处就是，它能够正常的看到整个公司的数据，那么它更多的可能是站在老板的角度、公司的角度去考虑一些问题。

  这个部门或者团队，因为负责所有的数据，所以它能从数据中了解公司的所有的环节的情况是如何的。在这样的架构里能了解营销、能了解财务、能了解运营，你所看到的数据是完整的。当要去做一个市场分析的时候，可能要拿运营相关、财务相关、会员有关数据，来从各个角度的解析、或者说剖析这个问题。

  有一个问题，就是相对来说，它跟其他部门是并行的，所以它离其他部门相对来说可能会远一点。不像刚才我们提到的，你在业务部门，因为你是业务团队的，所以你得到的整个业务信息相对来说是很及时的。

  如果你是在独立的业务部门，那么相对而言，你得到的业务信息可能会出现一些滞后，或者说不那么的完整。

  这个团队可能会在技术部下面，在技术上会有一些分析或报表设计、报表开发，或者需求分析。但在每个业务部门之间，都有自己独立的分析师，这个有一个好处是说数据底层是统一管理的。在开发这块，从上面记录就有了接口；从业务部门提需求到这个部门，有统一的接口，相对来说，在数据流程上相对来说会比较的流畅。

  但是最终做分析、做挖掘，或者真正了解需求的，可能并不是在业务团队，而是在数据仓库团队。

  业务团队把信息传递到数据仓库或者技术团队接口的分析师，在沟通上可能有些一些问题。

  以上这3种是比较常规的架构，这3种架构相对来说没有说哪种好哪种不好，大公司现在一般用的是第二种，即独立的部门。它是将数据底层，数据分析、挖掘团队，都放在一起的独立部门。这个部门负责整个公司所有的数据，都由这个部门来充当接口，对一些比较大的公司来说，是一个很成熟的架构。

  但有一个问题：这个部门跟其他部门是并行的，如果说在一些业务对接，或者分析师对接的情况下，如果这种制度不是那么好的话，非常容易导致这个数据分析师团队会脱离业务，就不清楚业务到底是怎么样子的，这是一种。另外一种原因是是在不同部门，沟通成本上可能会有一些增加。

  那另外两种在业务部门本身有自己的分析师，分析师对整个业务的问题很清楚，这是他最大的优点，但是他比较大的缺点是说因为他没办法看到整个的数据，这是他的劣势。

  但他跟数据仓库这个部门又不在一个部门，分析师跟技术的沟通可能会出现一定的隔阂。所以这样的一种情况下，业务团队的分析师把信息传到开发，可能就有一定的不完整性。所以这个沟通成本也是一个很大的问题。那另外一个就是，从分析师角度来说，可能是你没办法看到整个公司的数据。

  那么这三种架构可能在不同的公司，因为整个组织关系，可能会使用不相同的形式。所以说在我认为，第一个对于小公司来说可能，他没那么大的数据团队。这样一个时间段的数据分析师或者说数据分析人员，人数比较少，可能会挂在业务团队下面。那么他的数据源，可能会在技术部。

  那么对于分析师在这种架构下，我的建议是应该经常，除了在自己的业务团队外，多跟技术团队下面对口的开发的同事也好，多去沟通。

  让他们了解你的业务到底是要说明东西，要说明数据。那么这个就是更多的需要分析师去往后走。这种架构下，技术团队离业务比较远，他对数据的感觉、数据需求是不知道的。因此你平时多跟他沟通，介绍业务情况，那么对数据的梳理或者说对底层的建设、架构会比较好。

  接到业务部门的需求的话，更多的去沟通，这个所谓的沟通可能是一周，你要用两天或者做几天，到业务团队里坐下来，真正的去跟他聊一下，了解业务问题，参加他们的周会也好，分析会议也好，去参与进去。示范型部门就是让分析师去往前走，走向业务部门。

  所以说不管是哪一种，可能都是要分析师更主动、更积极一点，一个是往前、一个是往后。

  对于一个小公司来说，可能没必要成立一个独立的部门，更建议把分析师放在业务团队里面。返回搜狐，查看更加多