如何提升业务对数据团队的满意度？

首先要澄清一个概念，所谓业务对数据团队的满意度，是站在企业的角度来看这个满意度，而不是某个业务人员、某个业务部门对数据团队的短期满意度。

比如数据团队跟业务部门A关系好，需求总是及时满足，还获得了一定的口碑，但为了做A的需求，把公司最关注的B需求放在一边，这就不可取，因为格局小了。

因此，数据团队跟某个业务部门关系好，不代表真正的满意度，当然如果业务部门对数据团队抱怨很多，那估计实际工作做得也不好。

只有公司层面认可了数据团队对于业务的贡献，才叫作获得了真正的满意度，比如数据团队打造的产品上了总经理的会议或PPT。

那么怎么做呢？

共分为五个方面：理解数据团队的使命、增加数据人员的投入、依靠数据技术的红利、用产品解决最后一公里及进行服务模式的创新。

1、理解数据团队的使命

不少数据团队认为业务高人一等，只会被动的接收需求，不太关注这个需求的业务价值，而且理所当然的认为及时完成需求就能创造最大的业务满意度。

这种天然的“奴性“，一方面受公司所在行业和公司领导关注度的影响，比如很多数字化水平很低的企业不懂数字化，数据人员基本就没有用武之地。另一方面则是数据团队自身缺乏想法，导致被公司边缘化。

但站在企业的角度看，要提升业务的满意度，数据团队对自己的定位，一定不是哄某个业务方开心，而是为公司创造业务价值，你跟业务首先是合作关系，然后才是服务关系。

数据人员主动支撑业务的四个等级，下面做了一个示例，你越往上走，业务赋能就越强，业务满意度就会越高。

第一级：周末的时候业务给提了个紧急取数需求，数据人员加班加点完成，虽然由于业务理解不一致导致的反复很多，但还是完成了。

第二级：数据人员针对业务需求仔细做了分析，跟业务人员详细了解了业务的背景和使用场景，然后指出了业务口径不合理的地方并给出了建议，最终高质量的完成，没有延时和返工。

第三级：数据人员针对本次取数中碰到的业务问题进行了经验总结，并将这些经验固化到了知识库，然后在取数工具上做了优化，确保整个数据团队都能获益，最终整个团队对于业务的响应度提高了。

也就是说，数据团队要有系统性思维，能帮助业务方去思考业务，用系统的方式更有效地解决业务中遇到的问题，做到数据与业务的深度融合，成为最懂数据的业务专家，从而才能用数据驱动业务。

第一级的人员虽然执行力很强，很“听话”，表面上，满足了业务方的要求，实际上对于公司的价值有限。

当然，即使业务发展的很好，数据团队的满意度也不一定高，但如果业务发展的不好，数据团队的满意度肯定不会高。

2、增加数据人员的投入

业务部门时不时会催促：

“这个领导要的，能不能加急下？”

“明天就要汇报了，能不能今晚就给我？”

“周一领导要看到报告，能不能周末加班一下？”

在业务的初始阶段，数据团队增加人员的效果立竿见影，业务人员会说最近取数速度快了很多，可以有效提升满意度，但这种状态大多不会持续很久。

不久就会发现，由于市场的发展非常快，业务越来越多，各部门提取数需求的人也越来越多，对于取数的速度要求也越来越高。

比如原来一个取数需求你3天完成了，业务人员下一次就有2天内完成的冲动，一旦你能2天内完成，人家就有要求1天内完成的冲动，等到你真的1天内能完成了，他最好你即时完成，这种欲望是无止境的。

因为市场是贪婪的，而业务提需求也没有什么门槛，大家都被无形的市场鞭子抽打着往前走。

这个时候，往往只能靠引入更多的人来解决问题。但这样就形成了怪圈，你想提升满意度，就得加人，加人后市场要求进一步提高，还得继续加人，直到受困于成本。

因此，业务人员对数据团队的满意度最终会停留在一个固定值上，说不上好，也说不上不好，这是很多数据团队的一个生存现状。

因此，数据团队如果希望靠简单的人力投入来提升业务部门的满意度，在初期可能有点效果，但边际效益会越来越低。

更坏的情况是，数据团队由于做不出显性的贡献，因此也要不到公司的HC，甚至屡屡被抽人，形成了恶性循环，这就没什么满意度可言了。

3、依靠数据技术的红利

在人力受限的条件下，数据团队就要思考自动化、智能化的手段，善于通过数据技术的改进来提升业务的响应度，进而提升满意度。

比如要提升取数速度，方法是非常多的，笔者这里列一些手段。

从平台角度看，将原来的小型机升级到更高档的小型机，从小型机升级到X86集群，从100台集群规模升级到2000台甚至更多。

从系统角度看，将原来的ORACLE升级到DB2，从DB2升级到MPP，从MPP升级到SPARK、ES、Kylin、Flink等细分场景。

从工具角度看，将后台脚本从串行改成并行，从并行脚本升级到可视化平台，从可视化平台升级到一站式数据工具链。

从模型角度看，将明细表整合成汇总表，从汇总表整合成宽表，从关系建模到维度建模，从仓库模型到挖掘模型等等。

数据团队可以持续采用新的技术来提升数据的处理和查询速度，这种技术红利对于报表取数的价值很大，一线员工也会有较多感知。

但数据技术红利提升的满意度是有限的。

你会发现，公司领导对于报表取数有天然的质量和速度要求，数据团队做好是应该的，但想靠这个来邀功，就天真了。

公司对于数据团队的真实诉求永远是数据驱动业务，而不是简单的展示数据。数据团队的命跟CRM团队的命是不一样的，不可能以稳定性、及时性、高可用等指标来衡量，数据团队需要找到更多数据驱动业务的办法。

4、用产品解决最后一公里

假如我问你，阿里数据技术团队的业务能力怎么样？

你大概只有一种办法去了解，即通过他们打造的生意参谋产品和酷炫的双11数字大屏，这是阿里数据团队的一张名片，代表了数据赋能业务的无限可能，虽然他们内部每年也要支撑成千上万的枯燥的报表和取数。

数据团队的存在感有限，满意度不高，很大原因是数据团队的输出物没有真正触达客户，其业务价值的呈现过于间接，无论是报表、取数、分析还是模型，而只有产品才能解决数据价值传递的最后一公里问题。

无论数据团队是跟其它产品团队协同，还是自建设数据产品，都必须依托产品这个媒介来体现数据的业务价值，没有第二条路可以走，即使数据团队的模型建得很好。

比如同样是展现数据，可视化大屏展示数据和报表工具展示数据的业务价值是不一样的，这在以前很难为数据团队理解：搞个噱头而已嘛，我的本职工作就是数据质量和数据模型。

但如果让数据团队自己去做大屏，就会有完全不同的感受。因为做一个大屏产品能让数据团队真正的换位思考，即数据如何才能让别人愿意读、读得懂，而只有在读得懂的基础上，才有机会让别人进一步理解你牛逼的数据模型。

其实越是后端的人，越需要产品思维，越需要证明自己的存在，从而获得生存空间。如果数据团队能把取数，报表，分析或模型当成产品来运营，就会发现这是另一片新天地。

5、进行服务模式的创新

但数据团队要直接创造业务价值谈何容易，比如做产品对技术栈的要求很多，数据团队光靠自己其实很难搞定，这是由数据团队所处的价值链位置决定的。

在数字化服务的背景下，除了传统的接受需求的服务模式，数据团队还是要讲究一些策略，进行服务模式的创新，从而起到四两拨千斤的作用。

当前数据团队起码有两种值得尝试的模式：一是授人以渔模式，二是听得见炮声模式。

（1）授人以渔模式

前面提到过，数据团队需求做的再快，业务人员要求就会提得越高，由于沟通成本不可避免，因此传统的需求的服务模式永远不可能做到所见即所得，业务人员永远不会满意。

很多年前BI提出了自助分析的解决方案，希望业务人员可以基于可视化的工具，采取拖拉钻取的方式自动的获得所需的数据并且进行自助分析，这种工具现在很多了。

但自助分析无法有效解决灵活性问题，现在自助分析平台建了不少，但有几个企业依赖自助分析平台有效减少了人工取数量？

最可能的情况是自助分析平台激发了大量简单取数需求，但存量稍微复杂点的需求仍然只能靠人工获取。

业务人员必须要革自己的“命”，掌握SQL甚至Python是未来所需要的，这才是最大的敏捷。而数据团队的主要工作，第一是打造好用的数据中台，第二是做好数据技术的普及培训，这样更能事半功倍。

（2）听得见炮声模式

授人以渔模式是数据团队自己不做最终需求，而让别人基于数据团队打造的中台来实现业务价值，这是一种平台化的思维，但其带来敏捷的同时，也带来另外一个问题，即数据团队如何确保打造的中台能满足业务的要求。

数据团队处于IT部门的后端，IT部门处于业务的后端，数据团队处于后端的后端，现实中离一线实在太远了，数据团队要听得见一线的炮声，必需主动出击获得价值需求，才可能迭代出更好的中台。

大多数数据团队所处的环境跟互联网公司也是完全不同的，互联网公司信息化程度非常高，也许可以通过网络来方便的理解自己的员工和用户，但95%以上的企业的业务模式不是这样的，它们的业务大都在线下，要获取真实的需求难度大得多。

因此，数据团队不能整天窝在家里做报表、取数、分析和模型，要多到一线实地去看看一线的业务流程到底是怎样的，一线人员到底是如何获得和使用数据的，也许他们需要的不是模型，而是打通数据流程，这些才是王道。

中翰软件：专注数据治理17年（http://www.jobhand.cn）

免责声明：本网站所发布的文章为本网站原创，或者是在网络搜索到的优秀文章进行的编辑整理，文章版权归原作者所有，仅供读者朋友们学习、参考。对于分享的非原创文章，有些因为无法找到真正来源，如果标错来源或者对于文章中所使用的图片、连接等所包含但不限于软件、资料等，如有侵权，请直接致电联系，说明具体的文章，后台会尽快删除。给您带来的不便，深表歉意。