S：对数据工作做了总结之后（分为两大模块：数据平台、数据使用），想了解当前社会对数据分析工作的定位是如何的；引发通过了解 数据分析部门所处的组织架构去认识
W：通过对组织架构的研究，去定义/剖析不同组织架构下数据分析部门当前所处的阶段与机制；
B：达到状态：能够去辨别一家公司对数据分析工作的定位与重视度
在一个企业中，可能数据部门在一个公司中组织架构中的位置，决定了部门的定位和一些做的事情，数据部门所处的组织架构对数据价值实现是一个很重要因素。
[TOC]
数据部门发展的阶段
这是一个必须要经历的过程。
数据工作的两大模块
数据部门分成二个部门：
- 后端：数据仓库，大数据平台等；
- 前端，例如：数据分析，数据挖掘，数据产品等;
常见的部门架构
分散式
数据平台由技术部建设，技术没有数据分析/业务分析人员；这部分人员都分到各个业务块中。
技术部负责搭建大数据平台(在传统主要叫数据仓库)。目前大数据平台，如果比较大型的公司基本上会包括几块内容：
- 分布式：hadoop 平台;
- 实时计算: storm平台
- 内存计算：spark 平台
- 传统关系数据库
业务分析人员获取数据
- 向数据平台接口人提需求，最终以报表的形式获取数据。把业务方的进行转化，转为PRD文档，让ETL开发工程师，报表开发工程师实现 。【业务人员是没有访问数据仓库的权限的】
- 开放所有给业务人员进行去访问，业务可以自己访问部分数据，去写SQL去取数据。
适合情况： 在一些业务变化不快，或者业务相对不那么复杂的公司可能比较好。
对一些业务复杂，业务变化非常快的可能就不适合：
- 数据平台/仓库建议跟不上业务变化。造成数据仓库效率低，数据口径混乱。因为数据仓库架构离业务比较远，对业务理解不深。
- 业务数据分析师很多人的知识不能很有效沉淀下来。
这会导致业务要求为各个业务建议自己 “数据集市”，当这种数据集市我的时候，又会造成数据仓库负担中，各个业务方的数据“各大自为政”。最终公司数据混乱，后面大家对数据都摇头。
对于不把数据分析独立存在的公司，数据分析只是个数据展现工具，根本谈不上分析，而形成不了整体的营销能力.
集中式
公司所有的数据相关都归到一个部门中。业务方有任何需要都会向数据部门提出，数据部门会在内部对这些需求和报表进行沟通，避免重复开发，也便于对需求进行总结。
优势：所有的数据都是一个部门出，相对来说数据的口径会比较统一;
劣势：如果部门组织的不好。会造成数据部门离业务比较远 ;有时候对于数据的思考不够深入，造成与业务部门的沟通成本上升。
混合式
大数据平台建设由技术负责，他们核心是把数据平台建设的足够强大。
- 有一个比较大的数据部门，负责数据分析，挖掘，数据统一工作。一般来说这个部门会直接像管理层汇报，主要服务公司管理层;同时也会和业务方的数据分析师合作一起解决某个具体问题。
在业务方也会有自己的小数据分析团队。
- 这个数据团队主要服务由自己这个业务团队，同时也会和公司的数据部门有沟通和合作。
传统BI
问题：为什么传统BI没有达到今天互联网数据应用的高度呢?
在传统的BI中，更多只实现最底层价值。
$$ < 数据存储技术与成本 \to 数据运算效率 \to 公司数据价值意识 \to 数据相关部门架构 > $$
- 传统的BI，更多是偏重数据仓库的架构，根据需求来帮报表。
- 在数据部门没有一批主动去思考业务，思考业务与数据关系的人。这种人很可能都是在业务方，他们更多把业务问题转为要看的报表，然后与数据部门沟通报表开发，数据部门收集需求沟通后，进行排期
对当前公司架构的思考
组织架构：混合式的优化版
- 大数据平台、数据仓库由技术部门统一负责
- 各个业务团队成立独立的数据分析部门，进行数据分析、挖掘、数据统一工作。也是由专业的数据分析人员构成，而非业务端的人员担任。
优势：(1) 分析人员独立于业务部门，可以统一数据口径，并给出客观中立的报表； (2) 站在业务与后端IT 中间，作为两者最佳的构成桥梁，减少了沟通成本
劣势：一方面并没有真正贴近业务，另一方面偏离数据源有一定距离；一个是业务的理解，一个是资源分配与沟通；若处理不好，会进退两难；但若管理得当，是一个强有利的推进器。