如何提升业务对数据团队的满意度?
这是大鱼先生的第11篇原创
正文开始
首先要澄清一个概念,所谓业务对数据团队的满意度,是站在企业的角度来看这个满意度,而不是某个业务人员、某个业务部门对数据团队的短期满意度。
比如数据团队跟业务部门A关系好,需求总是及时满足,还获得了一定的口碑,但为了做A的需求,把公司最关注的B需求放在一边,这就不可取,因为格局小了。
因此,数据团队跟某个业务部门关系好,不代表真正的满意度,当然如果业务部门对数据团队抱怨很多,那估计实际做得也不咋地。
只有公司层面认可了数据团队对于业务的贡献,才叫作获得了真正的满意度,比如数据团队打造的产品上了总经理的会议或PPT。
那么怎么做呢?
这里就结合自己的实践谈一谈,共分为五个方面:理解数据团队的使命、增加数据人员的投入、依靠数据技术的红利、用产品解决最后一公里及进行服务模式的创新。
1、理解数据团队的使命
不少数据团队认为业务高人一等,只会被动的接收需求,不太关注这个需求的业务价值,而且理所当然的认为及时完成需求就能创造最大的业务满意度。
这种天然的“奴性“,一方面受公司所在行业和公司领导关注度的影响,比如很多数字化水平很低的企业不懂数字化,数据人员基本就没有用武之地。另一方面则是数据团队自身缺乏想法,导致被公司边缘化。
但站在企业的角度看,要提升业务的满意度,数据团队对自己的定位,一定不是哄某个业务方开心,而是为公司创造业务价值,你跟业务首先是合作关系,然后才是服务关系。
笔者曾经在《主动性的四个层级,你处在哪一级?》一文提到过数据人员主动支撑业务的四个等级,下面做了一个示例,你越往上走,业务赋能就越强,业务满意度就会越高。
第一级:周末的时候业务给提了个紧急取数需求,数据人员加班加点完成,虽然由于业务理解不一致导致的反复很多,但还是完成了。
第二级:数据人员针对业务需求仔细做了分析,跟业务人员详细了解了业务的背景和使用场景,然后指出了业务口径不合理的地方并给出了建议,最终高质量的完成,没有延时和返工。
第三级:数据人员针对本次取数中碰到的业务问题进行了经验总结,并将这些经验固化到了知识库,然后在取数工具上做了优化,确保整个数据团队都能获益,最终整个团队对于业务的响应度提高了。
也就是说,数据团队要有系统性思维,能帮助业务方去思考业务,用系统的方式更有效地解决业务中遇到的问题,做到数据与业务的深度融合,成为最懂数据的业务专家,从而才能用数据驱动业务。
第一级的人员虽然执行力很强,很“听话”,表面上,满足了业务方的要求,实际上对于公司的价值有限。
当然,即使业务发展的很好,数据团队的满意度也不一定高,但如果业务发展的不好,数据团队的满意度肯定不会高。
2、增加数据人员的投入
笔者刚进公司的时候,业务部门的主要需求就是报表和取数,当时数据团队负责报表取数的只有2个人,大量的需求只能排队,需求的实现周期短则3-4天,长则一个多礼拜,业务部门时不时的会催一下。
“这个领导要的,能不能加急下?”
“明天就要汇报了,能不能今晚就给我?”
“周一领导要看到报告,能不能周末加班一下?”
在笔者和其他一位同事加入后,情况得到了缓解,毕竟人力资源增加了一倍,而且我们还很勤奋。有段时间业务人员看到我,就会说最近取数速度快了很多,那个时候是非常开心的。
在业务的初始阶段,数据团队增加人员的效果立竿见影,从而可以有效提升满意度,但这种状态大多不会持续很久。
不久就会发现,由于市场的发展非常快,业务越来越多,各部门提取数需求的人也越来越多,对于取数的速度要求也越来越高。
比如原来一个取数需求你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%以上的企业的业务模式不是这样的,它们的业务大都在线下,要获取真实的需求难度大得多。
因此,数据团队不能整天窝在家里做报表、取数、分析和模型,要多到一线实地去看看一线的业务流程到底是怎样的,一线人员到底是如何获得和使用数据的,也许他们需要的不是模型,而是打通数据流程,这些才是王道。
但现实中有这种意识的数据团队很少,大家的眼睛习惯往上看,在决策支持上花了太多精力,性价比并不是很高。
但即使是人工智能,现在也解决不了多少决策支持的问题,大多只能在低级的一线操作场景来解放生产力,比如识别个图片啥的。
希望我的分享于你有所启示。
—————— / END / ——————
分析最新的数据思想,与百万数据从业者一起成长
“一平台、两体系、三性特征、四个统一、五个超越、六类服务 ”一篇读懂数据治理、共享和应用(值得收藏)