“我可能干了个假的数据分析师！”
经常有同学发出这种感慨，然后到处发《数据分析师是干什么的》《数据分析师、数据工程师、数据运营、数据挖掘工程师、商业数据分析师、我随便写个什么分析师之间到底有什么区别》。
之所以会这样，是因为大家看的常常是理想状态下的数据分析岗位职责与内容。
从本质上讲，数据分析是个技能，人人都可以学，人人都可以用。“数据分析”四个字拆开，可以细分成偏技术的“数据”部分——采集、存储、加工、展示数据；
偏业务的“分析”部分——定义问题，设计思路、寻找答案、验证假设、跟踪结果。技能人人可以学，但在企业中，具体的活是得有人干的。
在企业里，员工是按组织架构编排的。数据分析工作，最终还是要分配到某一个部门的某一个岗位。
因为数据分析不像销售、产品、运营一样是刚性岗位，大部分企业并不依靠数据分析挣钱吃饭。因此，数据分析岗位就不是一个常设岗位或者必须岗位。简单来说，这是个后娘养的部门。
因此组织架构的设置就千奇百怪。导致的后果，就是：理想永远是美好的，现实只能自求多福。大家在网上看到的各种科学合理的“数据分析流程”“数据驱动业务”，到了现实里就七零八落。
理论上，在技术端，至少需要数据仓储，数据分析两个组，才能扛得住工作。数仓组搞掂数据采集、架构、性能问题，分析组搞掂取数问题。可实际上有完整架构的屈指可数，草台班子满地都是：
这就是无数做技术的同学苦恼的根源：公司没有重视数据这回事，指望一个人把数仓到BI到建模全搞了，于是搞得办事的人各种没有办法。
即使一个人有能力全部做，他也没精力同时出现在业务部门开会的会议室，跑数的工位，开发的机房三个地方。且不说仅仅是清洗数据，就需要消耗大量精力。过度指望一个人大包大揽的结果，就是样样样都会一点，但样样不精通。
2，3，4步是开发的硬活，5，6，7步是数据分析的本质工作，但做算法、做专题、开发报表的工作细节完全不同，而1、8正是数据分析的起点与终点，不考虑业务需求，不跟踪业务效果，做了分析又有啥用呢？
在业务端，问题恰恰相反，是个人都想搞个分析，结果基层的表哥表姐越养越多。
业务部门需要的是分析结论，不是一个数字。
业务部门需要的是“这到底说明了什么问题”！做技术的同事，往往只能提供数字，而不是分析结论，所以业务部门养“分析专员”的风气就越演越烈。
相当多的领导都喜欢安排一两个数据XX在组织下边，这里只列了一点点，实际上的还有更多更多的表哥表姐岗位……
数据专员们的工作是很辛苦的。虽然名字也带“数据分析”然而做的工作基本就是在excel里搬数据（常常往返于csv格式与excel工作薄格式之间），做图表，贴到ppt里，在折线图下边写上：“本月销量低了，要搞高！”然后就能静静等着领导回复：“分析的一点也不深入！”了
谁愿意过这种日子？
业务端的分析，需要对业务本身有认识和较深的分析能力积累。这样才能有勇气和手段从合作部门嘴里了解到业务到底在干什么，才能在经营过程中准确定义问题，才能构建适合自己公司的分析思路。这些都不是花5000雇个表哥表姐能解决的。
可怜的基层表哥表姐们，往往都是新入职没两年，在公司人都不认识几个。别说分析问题了，连张嘴问别人问题，都会吃一个白眼：“关你什么事，做你的去”。这样的状态真的分析不了啥。
我非常能理解业务部门老大们对IT的不满。“就知道跑个数字，分析啥了？”这种抱怨从我入行第一天一直听到现在；我也非常能理解业务部门老大们用数据分析当招牌填充人员的做法。
所以理论上讲，最好的结构应该是业务端找有资历，有经验的少数人承担。技术端按需求排架构，多一些人把数据质量、数据处理、BI做起来。这样数据质量高，数据形式多，方便使用，同时业务上也能解读出含义，有能力推动数据成果落地——然而这又是一个理想。
从业那么多年，除了银行体系和少数大型互联网公司外。就没几个企业真的重视这回事，该招表哥继续招表哥。
总之不要被名字框死了思路，不要太纠结名字的文字。要看自己具体的工作内容，自己挂在哪个部门下边，具体分析，才能看清前途。
