以下文章来源于公众号-大鱼的数据人生 ，作者讨厌的大鱼先生  

有朋友困惑于团队报表取数太多的问题，跟我来探讨提升的方法，这其实是大多数据团队都会碰到的问题，原因无外乎以下几个：

、市场变化很快，取数要跟着市场节奏走，这意味着响应要尽量快，个性化程度却很高

第二、取数属于IT的后端，IT部门是企业的后端，也就是后端的后端，这种生态位让取数团队在企业中处于弱势地位，比如IT可以以稳定性、连续性为由制定一些业务不得不遵守的规矩，但数据团队就很难，连续性无法成为数据团队的理由

第三、取数对于大多数业务部门来讲，不需要付出什么成本，业务人员只要在EXCEL上填几个字段，发个邮件或起一张工单，就有一堆IT人员为你服务，叫我也拼命的提

当然如果每次取数为企业创造的价值总是大于IT付出的成本，那取数肯定越多越好，但现实应该不是这样，可以做2个思想实验。

个思想实验：

想象你跟业务部门处在一个真实的市场环境中，你要求业务部门为每次取数付钱，你觉得他们能向公司申请到多少成本来支付这笔费用？业务部门一定不会为取数付出太多，他们会放弃可有可无的取数，并将费用投在对业务更有价值的地方。

第二个思想实验：

假如你的取数团队有10个人，让2个人放弃取数去干一些不一样的事情，比如开发，那这两个人开发创造的价值能不能比取数更高呢？我相信一定可以，只是个人或管理不作为而已。

取数要提升效率，单位时间内尽量做的多一点，但也要追求效能，因为做的太多，边际效率会降低，机会成本却很大，站在企业的角度讲，数据团队全去干取数了，就没有机会去干其他更有价值的事情了，如果这个平衡未做好，对于企业就是实实在在的浪费。

我们不仅仅要追求取数速度，更要追求点取数的效能，这是我写这篇文章的立足点。

提升取数效能的方法有很多，我这里总结了四个方面十二条策略，包括机制创新、人员优化、组织革命、技术提升等等，大家可以结合自身的事情挑选一二尝试之，但不要生搬硬套，因为每个公司的情况不一样，比如有些公司IT很弱势，管理的手段一般不好用，那就可以试试技术手段。

一、机制创新

条、建立标准取数流程

如果你们现在的取数流程还是线下为主，比如邮件往来啥的，一定要尽量把取数这个流程数字化，为什么？

1、没有数字化就意味着拿不到取数流转数据，没有流转数据就意味着没法进行分析，没法分析就无从谈起取数的改善，假如某一天业务部门领导找你抱怨取数太慢，请先去看看实际的数据，也许根本不支持这种观点，你却很容易被忽悠。

2、在线化后能够提升取数需求的质量，因为可以强制业务人员填写一些必需的信息，比如背景、口径、分类等等，这提升了规范性，同时增加审批环节后也是对业务人员的一种约束，至少不能乱提。在取数小作坊的年代，取数需求怎么提都可以，但规模大了就是不一样，一定要标准化，规范化。

第二条、推动取数透明管理

取数流程数字化后，通过数据分析可以让你和业务方知道取数的真实情况，能够增加彼此的理解，促成双方的有效协作，以下是一些透明化的做法：

1、取数一般分为需求分析、需求提交、需求审批、需求分配、取数开发、结果审核、结果上传、结果下载等环节，但取数方和业务方对于取数的耗时可能有不同的理解。

业务方所谓的取数时长是端到端的，也就是从需求分析到结果下载的总耗时，因为他一般是站在领导的角度看问题；

而取数方计算的耗时一般是指从需求分配到结果上传的总耗时，他是站在技术的角度看问题。

比如业务方从接收到任务到提交取数需求，花了整整一天，业务方如果把这个时间消耗算在了取数团队，是不是不合理？业务领导审批就花了一天时间，如果把这个消耗也算在取数头上，是不是也不合理？取数团队明明昨天已经上传了结果，但业务方今天才下载结果，是不是更不合理？

信息不对称导致了很多的误解，取数团队很容易背这个锅，如果能清晰的告诉业务方真实的时间消耗，会发现取数慢既有技术的原因，也有业务的原因，这个时候取数效能提升就成了双方共同的事情。

2、取数团队同时服务的部门和业务人员往往很多，但每个部门和个人其实只关注自己需求的完成情况，取数一旦慢了就很难达成谅解，某业务人员会说，我只是提了一个取数需求，而且非常简单，为什么要这么久？

如果取数团队能将各个部门和个人的取数代-办清单和优先排序结果甩给他们看，也许会得到一定的理解，至少业务人员在跟自己的领导汇报进度时也有个说辞：他们取数的确很忙，你看其他部门的需求已经排到下周了，要么领导你帮忙协调一下？

业务部门领导的面子很贵，他会权衡利弊来决策是否要跟取数团队的领导做沟通，这样就能避免一些紧急程度不太高的取数需求。

3、取数紧急是业务挂在嘴边经常说的事情，左一个领导要求，右一个领导要求，但取数是否紧急不能光看别人怎么说，还要看他是怎么做的，这个还是要用数据说话，请统计下业务人员取数结果及时下载的比例，相信你会对所谓的紧急有新的认识，至少经验告诉我，一旦你加急取好了，业务人员下载的动作可并不一定很快，有些甚至就从没下载过。

取数团队用取数的方式来支撑业务用数据说话，更要懂得用取数的方式来支撑自己用数据说话，否则就是知行不合一。

第三条、实施取数配额制度

公司给予的取数资源是有限的，一般取数团队对于取数需求的管理方式还是比较粗犷的，谁先来就给谁先做，可能的结果就是对于公司不太重要的取数需求做了一堆，但特别重要紧急的取数需求支持倒不是特别给力，如果公司的取数规模大了，那么实施取数的预算分配制也是可以尝试的。

这个流程跟投资预算啥的分配原则差不多，就是根据历史年度的取数资源消耗计算出每个业务部门今年大致的额度，预留出部分动态资源，然后每个月通报下使用进度，超了就提醒一下，如果长期超过，虽然不能直接拒绝需求，但至少要让业务知道并欠一份人情，等到向公司申请资源调整的时候，业务至少能帮说一下话，否则很难得到理解。

第四条、提升取数加急门槛

以前做取数的时候，观察到业务系统运维侧做的比较好的一点，就是虽然他们有严格的上线管控要求，比如一月上2次线，但紧急上线也是挺多的，很多是业务的要求，然而他们有个铁律，就是凡是加急的上线，都需要开发或业务的领导出面，否则决不会开口子。

而数据团队在这方面立的规矩就很少，没什么挡取数需求的习惯，一方面可能跟取数反复迭代的特点有关系，另一方面也可能跟生态位有关系，但任何事情还是要有个度的，否则容易小鬼当家，当取数的资源冲突越来越大的时候，适当提升取数的加急门槛是需要的，至少不要让一个业务的小兵随意的加急，否则取数团队会被累死。

二、人员优化

第五条、优化关键接口人员

机制和流程是死的，人是活的，再好的机制和流程，在不同人手上发挥的作用也是不一样的，一般取数团队都会设置取数接口人，其会对取数工作进行统筹，但如果安排一个老好人去干这活，估计要累死三军。

企业内一般有权威文化，如果你这个人在专业上有发言权，那么别人对你会有信任度，这就少了很多扯皮的事情。就拿取数来讲，业务人员如果问专家取数，专家说了能取就能取，不能取他也就死心了，但如果换做一个新兵，显然应对上就会差很多，业务人员这么试试那么试试的事情可多了。

令人遗憾的是，取数团队的接口人，老好人性格的比较多，所谓服务意识好吧，不得罪人吧，数据团队的leader一般也不会把专家或管理型人才放在取数团队，取数显得容易被人“欺负”，而业务方会提取数需求的往往是业务专家，或者比较强势，这进一步“恶化”了取数团队的环境。

第六条、激发人员自主创新

取数的不变是暂时的，而变化是永恒的，这是由市场决定的，当前成熟的平台、模型及流程在给取数人员带来便利的同时，也是一种限制，比如新人一进取数团队，我们可能就给他立了很多规矩，让其很难越雷池一步。

宽表现在是大多数取数人员的救世主，但现在的很多取数人员，即使干了很多年，估计也很难有意识或有胆量去优化工具、优化宽表来提升响应能力，有点想法的取数人员，估计做几个月或一年就被调走去做什么产品、模型和分析去了。

取数人员要多思考下自身发展的可能性，在骂仓库模型垃圾的同时看看能不能自主优化，取数团队的leader则要多鼓励这些行为，试想如果没有熟悉一线的取数人员的积极参与，仓库模型怎么可能获得提升？

三、组织革命

第七条、实施授人以渔制度

20年前，我们完成一个取数平均耗时3天，10年前降低为1天，现在估计1天能做几十个取数了吧，但取数取得再快，业务也会提的更快，比如我们曾经通过技术创新大幅提升了取数速度，这让业务人员高兴了一下，但马上又有了新的期待。

靠传统的需求支撑模式是永远无法达到理想的彼岸的，因为市场是贪婪的，没有快，只有更快，在取数的平台、数据、技术达到极限的时候，能压缩取数时间的就是减少沟通成本，那干脆就让业务人员自给自足，自己清这就是取数的“授人以渔”模式。

数据中台成立后大大加速了这个过程，但这种模式一般只会发生在市场竞争激烈的地方，发生在对数据有想法的地方，同时需要有一点运气，即导火索。

业务人员自己取数从技术角度来讲是没有任何问题的，SQL是个人都能掌握，关键是业务观念的改变，数据人员的观念也要发生变化，即“建数据中台才是自己的本职工作”，而不是日复一日的取数。

这种模式是一种趋势，传统行业比较难，大多是时机未到，但做了的企业，可能就尝到了甜头，而且再也回不去了。

第八条、设置一线取数组织

“授人以渔”这种方式比较激进，那么退而求其次，在业务部门设置小IT也是一种降低沟通成本的做法。中台推出后，“大中台，小前台”让IT前置有了很多可能性，而小IT里，设置取数团队是常规的做法，作为业务部门自己的人员，他们紧贴业务，跟业务一起办公，大幅提升取数效率是不言而喻的，这种模式在很多企业以不同的形式存在。

当然这种小IT组织也有弊端，即取数人员的职业发展问题，其在IT技能上精进很难，却也难成为业务部门重点发展对象，有些想法的取数人员可以转岗做业务，那么其它人呢？

四、技术提升

第九条、加强取数模型提炼

现在都在提数据中台，数据中台核心的东西就是融合模型，评估数据中台是否好用的一种方法就是看对取数的支撑是否给力，有两个指标可以来衡量：

个是取数支撑度，就是所有的取数中，直接利用融合模型支持的取数比例有多少，融合模型预计算了一些取数逻辑，理论上取数速度会大幅提升，如果取数还是要走基础模型，那这种融合模型不要也罢。

第二个是取数复用度，就是融合模型被重复使用的平均次数，如果这个次数是1，那就说明模型没有共享可言，这对计算资源的浪费是多的。

取数团队要与数据中台团队进行有效协同，取数作为输入，数据中台进行优化，取数再进行评估，由此形成良性循环，这才是在技术层面提升取数效率的方法，很多数据团队的取数和模型走的是两条路，需要反思这个问题。

第十条、升级取数计算引擎

我一直希望取数团队能扔掉HIVE，直接用sparkSQL，CK等数据库来取数，这种直接吃技术红利的方法简单粗暴好用。

当然更换计算引擎不是你想换就能换得，现实中有三个方面的挑战：

，涉及到技术路线的选择，周边生态的配合、投资的计划、时机的选择、存量迁移的代价和人员技术栈更换等等复杂因素。

第二、很多取数团队看到机会不会去抓，因为做生不如做熟，少点风险好，反正现在也能支持。

第三、很多取数团队整天围着业务走，早就忘了数据技术是怎么回事了，更别提统筹规划技术路线了。

第十一条、提升取数自助能力

自助取数并不是新的概念，其通过固化指标和维度，并刚过拖拉钻取的方式来完成一个取数。但自助取数跟取数市场化的特点是相冲突的，市场要求取数适应变化，比如维度和指标都在变，而自助取数则要求不变，自助取数平台就需要在这个夹缝中去寻找生存机会，这个夹缝的大小在不同的企业是不同的。

业务一线的工作以执行为主，简单的清单级取数比较高，变化也比较小，因此自助取数在基层会用得会好一点，但管理层级越高就越难支撑，因为往往涉及到复杂的统计，连人都想不清楚的事情，就不能奢望机器了。

但无论如何，自助取数对于提升一线取数效率肯定是有帮助的，至少它能激发使用需求。

第十二条、优化取数开发体验

PLSQL Developer这款Oracle数据库管理软件至今让我念念不忘，因为取数体验做的相当不错，但随着Oracle退出大数据领域，这款软件也逐步退出历史舞台。

我们需要在hadoop、MPP、流处理等复杂的技术栈上完成取数，在相当长的时间内没能研发出一款能与之匹敌的取数产品，这极大的降低了取数的效率。

在刚开始用Hive的时候，以前用Oracle取数的同事就说取数体验一下子从天堂掉到了地狱，至今仍然有少量的取数人员坚守在仅剩的几台Oracle机器上取数，他们宁可不厌其烦的去倒数。

为了提升使用体验，我们为取数工具设置了专门的产品经理后，才逐步解决问题，魔鬼都在细节中吧，作为数据团队的leader，一定要亲自体验下自家大数据平台的取数工具，这个对于取数生产力的影响实在太大了。

十二条策略讲完了，当然你可能还有其他的策略，但相信已经不多了，个人的经验是：解决取数的问题，管理手段一般是优先于技术手段的，不要就技术论技，数据团队的leader必需身先士卒，如果你真的想解决问题。

从长远来讲，一个数据团队沉迷于取数是不正常的，毕竟取数是边际效益递减的工作，符合2/8原则，你一年完成20%的取数跟完成，价值上区别不会很大，至少带给领导的感知就是这样，但如果这些取数资源能用来做一些更长远的工作，比如报表优化、数据分析、数据产品、数字化转型等等，我想这是任何公司的领导都希望看到的。