深入解析：BI取数难背后的原因 - 永洪社区

大多数企业，都有BI或类似BI的部门或团队，它们肯定有两项基础工作，一项是提供报表，这个大家都懂，还有一项是取数，即根据业务要求临时性的提供数据解决方案，比如提供营销清单或决策分析的数据。

大多数时候，取数的量远远超过报表的量，因为报表往往是成形的指标的系统固化，而取数往往是具有探索性和分析型，因此数量可能会非常庞大，比如一些企业一年的报表新增或修改不到几百张，但取数却有上万个。

取数是一个企业非常依赖的一项基础IT工作，除了常规的KPI和报表,其实放在领导案头的多数分析数据，往往来自临时性的取数，典型的场景如下：

“领导发现了KPI的一个异动问题，业务分析人员要尽快核查清楚问题，但常规的报表然并卵，业务人员会作一些设想，然后设计大量的分析表格，而这个表格的数据，则需要BI团队中的取数人员临时性的提取并提供。”

现在大数据很热，人工智能很高大上，但其实大多企业的日常决策，靠的还是这种数据支撑模式，IT在里面的价值，就是提供这些数据。

取数是当前大多数企业决策的生命线，也是IT价值的重要体现，这个评价我想在当前毫不为过，虽然业务人员可以风光的将取数人员的成果最终展现为漂亮的图表和分析报告，但完成分析的时候，也请千万别忘了感谢一下取数人员。

这里为取数人员的价值正名，虽然可能在老板年终总结报告上只有一个呆板的数字，但又有哪一页跟取数脱得了关系，虽然很多人并没意识到。

但业务人员却经常抱怨取数的速度和质量，取数看起来并不那么容易。

自己有过很多年的取数经历，虽然现在已经不做取数了，但还是要回过头来谈谈关于取数的看法，希望有所启示。

取数，到底是IT人员的职责还是业务分析人员的职责，从传统的角度来讲，存在的即是合理的，在大多数企业仍然是IT人员的职责，毕竟IT人员离数据最近，既然系统是你建的，从上面取个数理所当然是你的职责，况且还要写代码，更加不可能是业务人员的事情。

但从另一个角度讲，取数是业务人员的职责也是合理的，做分析，讲究的是个数据探索，探索本来是个不确定的事情，而且需要反复迭代，取数中业务人员和取数人员的沟通成本是很大的，两个不同背景的人，在业务口径和数据口径上要达到统一，对于双方要求都很高。

取数的迭代成本其实蛮高的，一般以天计，给取数设置一个指标，比如反复取数率，估计这个指标也是惊人的。

各个企业需要根据实际情况做取舍，没有绝对的边界，取数放在哪边都有合理的地方，但如果业务人员抱怨速度太慢，可以转换下思维，尝试下自己去取数，这个并不是纯技术活，懂点SQL就能应付大多数场景，在数据处理灵活性上，比那个EXCEL强很多。

玩数据，不要太相信人家端到你面前的，那也是信息量打了很多折扣的，业务分析人员应该看到企业最鲜活、最原始的数据，那个最有价值。

因此建议业务分析人员应该具备取数能力，这为数据分析和创新提供了无限可能，虽然会牺牲一些取数时间，但争取来的沟通成本降低、IT技能增长及数据分析视野拓展，是完全值得的，取数让你更具竞争力。

对于取数人员来讲，如果有可能，可以先尝试着开放一点集市让业务人员自己来取，你不开放，不去推动，业务人员也许永远不会走出第一步。

除了传统习惯，业务人员所以不自己取数，往往是因为市场竞争没到那个份上，数据分析快点慢点没关系，也不是关键环节，但如果是个数据驱动型的企业，还是要做一些变革。

但有一点需要承认，如果错位不改变，无论取数系统多快，由于沟通成本很难降低，取数速度没法获得几何级的上升。

取数人员，对于某个取数，要知其然并知其所以然，什么意思呢？

当前BI取数人员，大多是从数据仓库或报表库等OLAP系统提取数据，数据仓库的模型表往往是已经加工好的表，其在提供取数方便的时候，也过滤掉了大量源系统数据的信息，这往往导致一个取数需求明明可以取，但由于数据仓库的限制而无法取的情形，取数人员就像井底之蛙，只能看到数据仓库让你看到的东西。

这种现象普遍存在，因为系统早就在那里，你接手的是一个成熟的系统，现在开发都讲封装，但封装在提供开发便利的时候，也让我们的新手缺少了接触本源信息的机会，从而扼杀了创造力，我们不是站在巨人的肩膀上，而是被限制在巨人的肩膀上，不敢去怀疑哪怕是半点。

要成为取数专家，特别强调的一点是一定要理解源系统数据，只有这样才能理解数据仓库模型的本质，才能更好的理解业务需求，通过刻意训练，你成为了公司内唯一能够连接起业务人员、仓库人员、源系统开发人员的桥梁，你才可能成为专家。

专家不仅仅是满足需求的人，还能主动创造需求和给出建议，比如能对于数据仓库的模型提出改进意见，能对业务人员提出的需求进行质疑，这都来源于你对于数据认知的深度，但这样的人，其实很少，因为需要刻意训练。

举个例子，公司内CRM菜单上的某个条目，你知道对应于源系统哪个数据吗？并且影响到数据仓库哪个模型吗？业务人员往往不管你从哪个系统取数，总是从看得见的地方提出问题和需求，如果你是普通的取数人员，一旦仓库没有对应数据，是否就不清楚如何作答，但专家不是，这就是差距。

数据分析的价值在于多领域数据的融合分析，这就需要取数人员对于公司的大多领域数据要有充分的掌握，数据广度往往决定了取数人员的视野，也决定了其发展潜力。

但取数还是比较容易陷入“做熟做专”困境，因为平常接触到的取数需求可能大多比较狭隘，因此掌握更多领域的数据似乎无此必要，这也是专家和普通取数者的区别，但如果你对于数据有更多的大局观，你就能适应不同场景的需求，就能融会贯通。

领导所以为领导，有一个特别重要的，就是它接触的领域比你广太多，对于取数的人来说，更广的数据视野让你取数游刃有余，有更大的发展潜力。

比如，你要做业务，可以，企业最需既懂数据也懂业务的综合人才，你要做系统，可以，因为你懂源系统的数据，你要做模型，可以，广褒的数据视野和强大的取数能力是你独一无二的分析武器，你要做项目，可以，很多综合的取数人员往往能走上BI项目经理的岗位，你要做技术，也行，平台要获得成功始终要依赖业务和数据的深入理解。

做一个合格的取数人员很不容易，特别是要成为专家型的人物，那也是需要付出巨大的代价的，没人逼你做这些又红又专的事情，想选择怎样的道路，全赖自己。

但有一点是肯定的，如果你希望通过被动的接收一些取数需求就能获得更大的提升，那基本也不可能，取数这个事情，2-3年就可以很熟很上手了，应付岗位诉求绰绰有余。但要让业务人员对你建立起完全的信任，真心的称呼你为专家，则是两个境界的事情。

取数人员的使命是让取数更快更准，这将越来越成为企业的核心竞争力，因为新的时代市场变化越来越快，取数越快越准，企业的决策成本就能越低。

记住，取数不总是那么变幻万千，它也是有一定规律的，这为自动化提供了可能，比如有两类典型取数类型，营销清单型和复杂分析型，营销清单型，往往跟一线执行相关，70-80%的规则是比较简单的，通过配置往往就可以提供，复杂分析型，则规则比较难抽象，但也是有规律可循的。

不少企业，正是建立了自助取数平台，通过提供前台配置界面，从而让业务人员自助完成取数工作，这能够解决很大部分取数工作，好处很多，以XX运营商为例：

当然这类取数平台建设比较艰难，除了体验要好，性能要高，还要去做持续的运营，而且改变业务人员取数习惯很难。

但取数人员始终要有一颗自动化的心，以前笔者和同事坚持做这个平台2-3年，最后算是推广开，而这个平台现在还活着，至少占据着公司40%的取数量。

作为一个IT人员，最大的褒奖应是自己倡导或建设的平台有人仍然在用，并持续的发挥出价值吧，而笔者以前在5年里拉磨似的取的上千个数，还有谁会记得呢？

这个其实也带点平台化的思维，取数人员一定要努力形成取数的平台生态，你发力的点不在一个个取数，而在于建设及运营好取数这个开放的平台，不要仅仅是自己在这个平台孤独的跳舞，要能创造足够好的数据模型，提供足够好的操控体验。

大数据时代，现在领先一点的都开始搞人工智能了，虽然我们是传统企业，但也不要被拉的太远，要有一颗“平台”的心，关于取数自动化后面我会专门撰文，敬请期待。

以前报表取数人员横跨业务和数据，号称是企业的综合型人才，但现在已经远远不够了。

大数据时代技术突飞猛进，随着数据量的变化，IOE已经无法走遍天下了，你要取数取得快，需要升级你的平台引擎了，我能打造更牛逼的自助取数平台吗？最近也一直在问，我们传统企业的取数挖掘，能不能全部搬到SPARK？

大数据结构越来越复杂，业务场景越来越多，SQL显然不够用了，我们的取数人员未来是不是要掌握各类语言，以适应不同的取数场景？比如，能否取出近3分钟的上网流数据并统计给我？能否临时爬虫看看公司的负面舆情如何？

大数据时代更强调算法了，我们半路出家的取数人员，如果面对业务人员这个问题，该如何作答？能否给我取个数，看看杭州的公交司机有多少？这个还是传统的取数吗，是吗？不是吗？