写点什么

数据思维的关键,不只是要“善用数据”更要能“解决问题”

  • 2022-08-11
    北京
  • 本文字数:7462 字

    阅读完需:约 24 分钟

数据思维的关键,不只是要“善用数据”更要能“解决问题”

写这篇文章的初衷,是因为最近和一些企业交流时,发现大家在数字化转型的过程中都或多或少遇到了同一个困惑——如何提升员工的“数据思维”,让每一个人都能理解数据的价值和规律,甚至都具备数据分析的能力。即便是对于金融这样走在数字化前排的行业来说,也在受类似问题的困扰。


和其它传统的实体行业不同的是,金融几乎就是一个基于数字的“游戏”。但是,拥有数据是一回事,能把数据价值释放出来又是另一回事。


不少金融企业表示,虽然行业整体在平台建设和数据整合方面取得了可观进展,然而对于如何提高数据的利用率,真正释放数据要素价值,还有很多问题亟待解决——比如,内部员工如果不具备数据思维,就不能在日常开展业务的过程中把数据的价值纳入考虑范围,即便企业坐拥海量数据,也可能形同虚设。


所以,InfoQ 带着“如何提升企业员工的数据思维”这一问题,采访了曾在被奉为“数据驱动金融先驱”的 Capital One(美国第一资本银行)任职多年的晋梅博士。


晋梅是中国科技大学数学系本科、美国乔治华盛顿大学统计学博士,毕业后就加入了 Capital One;回国后,她先后在量化派、顶象技术、全量全速等公司任职,现在是神州信息资深金融科技专家。对于金融和互联网的业务经营、数据建模、运营分析和风险管理,她拥有着非常丰富的实战经验。


而针对我们的“迷思”,晋梅可以说是“一言惊醒梦中人”——她说——企业数字化做不好,大概率是因为,只看见了数据思维中的“数据”,但对“解决问题”鸵鸟式逃避。

数据不是越多越好,模型不一定越复杂越好


一提到“数据思维”,我们常常会听到这样的说法,一定要积累海量的数据、一定要用上复杂的算法和模型、一定要实现对业务的颠覆式创新。事实是这样吗?晋梅认为,数据思维的本质,不是追求数据的积累或是算法的复杂度,而是要清楚地知道,如何用好数据、更好地解决实际问题。


“比如说,有的企业的基础设施不够完善,业务线上化程度和数据积累也很有限。但他们在业务逻辑上想得很透、对业务流程的拆解很到位、对提升和增长所需要重点关注的环节抓得很准。在重要环节上,他们敢于提出问题和关键假设,然后有的放矢地去积累数据。他们及时复盘,基于分析结果一边优化、一边提出新的问题和假设——在这个过程中,即便他们只使用了几张不超过 10M 的 Excel 表格、只运用了小学生都能熟练掌握的四则运算,我们也不会认为这样的企业没有‘数据思维’、算不上‘数据驱动’。”晋梅强调,“能够踏实做到这一步的企业,就算是已经吃透‘数据思维’的内核了。”


她举了个例子:拿所有银行都在做的公众号来说,即便是在没有后台权限的情况下,运营分析师也能根据有限的公开数据——比如推文标题、位置和时间、内容和形式等信息,判断出某个分行或者业务部门在特定时间段内对公众号渠道的定位是什么、重点关注哪些客群、营销什么产品和服务、主推什么卖点和权益、覆盖广度和投入力度如何等等。如果进一步结合每个推文的阅读量、转发量、点赞量、评论关键词等数据,还可以做定性和定量的主题分析,围绕分行或业务部门经营目标有针对性地给出内容运营的优化思路和测试路径,甚至还能在用户运营和权益规划方面给到非常有价值的建议。


换言之,数据是否具备业务价值,不完全取决于规模或体量,而是看是否能解决需求或问题。即便数据资源有限,在特定场景下也可能创造价值。反之,数据体量大固然蕴藏着更大的潜力、更多的可能性,但如果没想清楚要解决什么问题、为什么利用数据就能提供更有效的解决思路、如何使用数据才能达到预期效果这些问题,就会既增加数据成本、更增加决策难度。


那么,越来越流行的AI分析工具以及复杂的模型或算法又是不是必选项呢?晋梅的答案依然是否定的。“和到底是要用铲子还是挖掘机、要用水果刀还是手术刀这类问题一样,我们要分析数据、挖掘洞察,应该选择什么方法、使用什么工具,依然需要具体情况具体分析,合理、有效、划算的才是好的。”


比如,当下非常火的短视频或直播,对于拥有海量用户和内容的平台来说,需要相对复杂和专业的算法来识别用户的偏好、内容类目,通过给用户和内容分别打上标签,进行及时和准确的推荐,以此增加用户的粘性、催生更多有需求的内容。


但是,在这个生态中,能利用数据去成就和放大业务价值的,除了专业的算法团队,还有运营团队。在直播的过程中,运营全程紧盯人气数据、带货数据,分析观众画像、流量来源、观众互动和商品转化,捕捉有可能影响交易量的潜在因素,通过持续测试和优化投放策略、调整直播间的“人-货-场”来创造价值。


“在这个过程中,他们常用的分析方法在绝大多数情况下并不涉及复杂算法和数学模型,很多运营指标也只是基本的加减乘除,但这完全不妨碍优秀的运营人员利用数据去解决转化的问题。”晋梅表示,“我合作过不少顶级的运营,他们不会写 SQL、没听过逻辑回归、也弄不懂 GBDT,但他们把坚持数据驱动作为信仰,是真正具备数据思维并从中获益的人。”


所以,在她看来,是否需要 AI 分析工具、使用什么复杂度的模型,先要明确业务的目标,基于这个目标去做细化拆解、梳理环节,提出关键问题和假设,再结合数据的实际情况,综合评估不同方案的可行性、投产比、优势短板后再做选择。

数据是锦上添花,而不是救命稻草


尤其是在数字化愈演愈烈的当下,市场上不乏打着“数字化转型”的旗号贩卖焦虑者,也不缺把“数字化”当作救命稻草,或者拿着锤子到处找钉子的企业。越是这样,企业越是要从做业务的初心和商业的底层逻辑出发,对自身的核心竞争力有清晰的定位,对市场需求和趋势发展有客观的判断,对数据科学的优势和局限性有必要的认知。否则,很容易陷入先把“数据思维”当作万金油,一顿操作猛如虎却没有感受到业务突飞猛进的尴尬境地。到了最后,只能“甩锅”给数据。


以这些年业界对Capital One的解读风向变化为例:晋梅表示,因为短短几十年 Capital One 就跻身全美头部银行,很多人给它贴上了“大数据风控先驱”的标签,而后冒出来很多主打“大数据风控”的公司,号称他们的风控模型里用了成千上万个特征,智能到恨不得每分每秒都在自我迭代,甚至可以连模型带系数从 A 银行直接迁移到B银行去帮后者快速冷启动。但随着后期 Capital One 遇上股价波动、业务调整,业界同样着急下结论——表示“Capital One 走下神坛”。


那么,事实果真如此吗?晋梅解释道,“成就 Capital One 的肯定不是所谓的‘大数据风控’,Capital One 也没有什么秘密武器,只是一直遵循着‘提出问题、分析问题、解决问题’的结构性思维方式,让数据恰如其分地发挥价值罢了。”


据她介绍,在日常的业务推进过程中,Capital One 的算法模型团队会频繁和业务反复沟通金融产品要素、目标客群、推广渠道、营销策略、市场环境和宏观趋势。双方不仅对业务的历史、现状、未来规划都有充分共识,还会对建模样本的选择策略、模型的框架、建模的方法、模型适用性、模型的验证、上线后的监控、可能会出现哪些问题、出现这些问题后的应对预案等信息去做充分的讨论——包括对入模的原始数据、衍生特征的业务价值和投入成本客观评估,以及对关键变量的系数从符号到数值是否合理、映射到业务上代表着什么等问题逐一明确。


“脱离了具体业务和场景的模型不但很难放大数据的价值、甚至可能带来毁灭性的灾难。”晋梅强调,“在 Capital One 工作这么多年给我的启示就是,永远不要在没梳理清楚‘产品-营销-运营’闭环的业务逻辑和关键问题之前,盲目扎入漫无边际的数据海洋;不预设问题、说不明白要验证什么的建模和分析,都是低效甚至无效的。“


所以,商业的本质,归根结底还是供给和需求的匹配,是用对的产品或服务、在对的时间和空间、以对的方式满足用户的需求。对于大多数企业来说,直接创造价值的不是数据本身,而是让数据助力实现供给和需求之间的极致匹配。


换句话说,企业自身如果没有好的商业模式、好的产品和服务、好的客户体验,那么即便是再先进的技术、再优秀的算法模型、再多的数据也无法帮助它扭转乾坤——比如风靡一时的共享单车,背后也有海量数据在驱动资源配置,但是商业模式变现慢、服务管理不完善等问题同样导致了它最终的失败。过度高估数据价值,指望数据创造奇迹,让本就不符合逻辑的商业模式翻身,那多半会失望而归。

要运用数据,先忘掉“数据”


“所以,我觉得‘数据思维’,归根结底是因为有了数据加持,从而更有底气和把握做出正确决策,继而更高效地解决问题的思维。我们不能拘泥于字面上的、狭义的‘数据’这个词本身。”晋梅强调,“甚至可以试着先忘掉‘数据’,捋一捋业务模式、搞清楚要解决的核心问题到底是什么;在此基础之上,再引入数据、考虑数据能帮到什么,进而刷新对业务模式和核心问题的理解。”


具体来说:第一,理解业务、提出问题;第二,拆解成多个子问题;第三,逐个分析和评估;第四,总结和决策。晋梅表示,这种结构化思维指导下的、解决问题的框架在如今的数字化背景下非常适用。


“首先,企业要明确目前业务上面临的核心问题是什么,大家充分探讨和论证、要达成共识;然后,是对问题进行拆解,可以根据业务流程、关键要素或者部门职能等维度细分成多个子命题。围绕每个子命题要敢于提出关键假设、圈定测试范围、排好优先级;第三步用包含数据分析在内的手段,对第二步拆解出来的问题和假设进一步量化、验证和评估。最后一步,基于前面的分析结果,总结和决策。在落地执行、业务迭代的过程中一定还会碰到新的挑战、出现新的问题,这时候再从第一步开始、螺旋式推进。”


银行的权益运营为例:


第一步,明确要解决的问题是,通过丰富的权益持续满足客户的需求,提升客户体验、加强客户的粘性,继而提升客户的经营价值;


第二步,要做到在对的时间、把对的权益、以对的兑换积分金额和对的兑换方式去满足客户的需求。可以按照“人-货-场”的运营模型进行细分拆解,围绕着每一个维度,做好基础标签体系的建设,梳理交互环节,根据可提升空间和价值明确优先级;


第三步,对关键环节开展数据采集、积累、分析和建模并提炼洞察。比如,通过兑换数据,可以把同一个 AUM 层级的客户按照兑换品类的偏好进一步细分群,也可以评估兑换流程的转化效率、从而定位优化兑换体验的环节,还可以根据权益单品的兑换热度调整选品策略和组合策略;


最后,通过对这些信息的综合分析,业务团队和运营人员就可以更有据可依地开展分群运营、渠道优化、商品管理和供应商管理等工作。


晋梅告诉 InfoQ 记者,很多企业尤其是技术人员在推动数字化的过程中,经常把自己局限在第三步,没有考虑具体问题和具体场景的全貌,只是接受一个笼统的需求、确认下字段的口径就开始做分析和模型,最后往往不能提供业务用得上、切实辅助决策的输出。


比如,建模同学 M 接到需求说要给 A 产品做信用评分卡,他兢兢业业找出来 A 产品的历史数据、认认真真建模和回测,感觉都没问题了就交付给策略同学 P 使用。没过多久,策略同学 P 就抱怨 M 的评分卡不好使,时灵时不灵。


后来才发现,业务团队为了完成增长 KPI,自行调整了 A 产品的受众群体,把过去只聚焦在优质客群的 A 产品推向基数更大但信用资质略差的客群。为此,他们新增了 A 产品的进件合作渠道,在展示坑位、流量费用等方面也都做了调整。但是,在推进这些尝试的过程中,他们只使用了过去优质客群的历史表现数据,自然,M 同学原来建立的评分卡的有效性就非常有限。


所以,晋梅认为,解决问题的经典框架中的每一步如果没有放在整体逻辑中去考虑,很难有价值可言。上面这个例子的漏洞就出在没有对问题进行合理的拆分和定位。除此之外,还有的企业会在第一步明确问题的过程中,就开始出现目标上的偏差。


“比如,有些银行在做 APP 的时候要拼日活数据,为了达标玩命地在 App 里添加功能,俨然一副要和字节拼内容、和腾讯拼社交、和 PDD 拼电商的架势。且不说银行 App 在这类比拼中到底有什么优势,就说日活数据的提升如何与银行经营指标挂钩?或者流量真的来了,银行要用什么产品和服务去承接去变现?而这些接得住流量需求的产品和服务目前是什么状况、有没有需要优化的地方、优化的节奏又是什么?完整的商业模式、业务链路和实现节奏企业自己是要先想清楚的。否则就是盲目投入,很可能钱花了不少却总说不清产出在什么地方。”


也就是说,这背后要求企业对自身业务的走势有清晰认知和合理的规划,能够识别和解决到业务的“真问题”而不是“伪需求”。

每个人都该有“业务体感”和“数据思维”


那么,在一个企业当中,究竟谁应该具备这种结构性思维和解决问题的能力?在传统认知中,我们通常认为创造业务价值并且在这个过程中负责解决具体问题的,是冲在前线的业务部门。而技术部门扮演的是执行者的角色,只要在幕后负责接收业务需求,然后针对性地做开发、找技术、做模型。


但是,时过境迁,如今数字化转型的背后需要源源不断的技术内燃力,技术已经成为其中的关键角色,这意味着过去这一套协作模式无法奏效。


所以,晋梅的答案是——无论是一线的业务人员还是中后台的技术人员,所有人都应该具备上面所说的解决问题的思维和能力——更确切来说,每个人都要有“业务体感”和“数据思维”。


她讲了某区域银行的例子:“在诊断这家银行营销系统时发现,他们很多营销活动的响应率居然都能达到 90%以上。即便是非常牛的互联网爆款产品,也很难达到这么高的响应。所以,当我们把这些数据拉出来看的时候,就发现了问题。这些高响应率活动的营销方式都是短信,而这个所谓的响应率其实是送达用户手机的比例,除了被拦截的短信,超过 90%多都能送达。事实上,短信送达后用户并不一定会点击参与这些营销活动,而这一步的点击率是比短信触达率更具业务价值的指标。更让我震惊的是,这个数值高达 90%、以‘响应率’自居的指标,在这家银行的营销系统里已经静静躺了几年了。”


在晋梅看来,这就是缺少“业务体感”,进而对数据的业务意义和价值、对数据所反映出来的业务漏洞也不敏感的一种表现。很多企业拼命花钱做项目、上技术,最后要么没效果、要么说不清楚效果,就宣告项目失败,其实背后可能不是技术水土不服,而是围绕业务闭环本身该做的思考和论证太过敷衍和草率。


但是,现实情况是,这种兼具“业务体感”和“数据思维“的人才非常稀缺,他的基本能力要求是既要懂业务又要懂技术,复合能力叠加,培养难度也加倍。晋梅指出,企业要解决的当务之急,需要业务人员与技术人员的“双向奔赴”。


“一方面,技术一定要去理解业务,明确业务目标、流程和痛点,你要清楚自己通过哪些技术、算法能产生什么样的影响,带来什么样的价值;另一方面,业务对技术的理解,不要只在大数据、人工智能这些热词表面,比如,当你的业务对技术、对数据的依赖越来越重,起码要知道关键技术的基础原理、构建逻辑、优势、短板和局限性等。”晋梅指出。

业务技术双向奔赴,“说人话”比“造新词”更重要


很多人认为,技术与业务人员之间的隔阂是天然存在的,由于工作内容的差异,双方关心的问题并不相同,无法在同一套话语体系下沟通是非常普遍的现象。晋梅表示,这个问题不是没有解,但也没有捷径。


“业务、技术、数据等核心部门首先都不要回避这个问题,其次要一起迎接这个挑战。技术不要认为业务背景的人肯定听不懂技术和数据,高段位技术的一个重要能力,就是让业务人员听懂技术的价值;同样,业务也不要认为技术人员弄不明白商业模式,高段位业务一定要具备的重要能力,就是简单、直接地讲清楚业务本质。”


据晋梅介绍,Capital One 把这样的文化观念通过制度和流程的方式做了固化和沉淀。


比如,在人才招聘过程中,无论是业务、数据还是技术岗,面试时都会安排一轮案例分析。主导这一轮的面试官都是 VP 级别的高管、拥有一票否决权。而在整整一小时、和高管 1V1 的面试中,候选人会被提供一个具体的业务问题,围绕着这个问题会被给到业务背景、数据报表等信息,但这些信息不是一次性、一股脑给到候选人的(这也符合我们在实际工作中碰到的情况),而是由候选人和 VP 展开多轮互动,询问、确认、提出假设、分析解读、给出建议,然后再被提供更多信息后,进一步分析和优化建议。


也就是说,在整个面试过程中,候选人身上没有“业务岗”、“数据岗”、“技术岗”的标签,而是一个先快速吸收背景知识,然后提出问题、分析问题和解决问题的角色。


再比如,在部门协作过程中,Capital One 模型团队在每一次对模型进行调整时,都会和业务充分沟通调整的原因和方式,调整前后的对比,新模型的优势、短板和局限性;反之,业务团队每一次做业务策略调整时也会把调整背景、调整方向、预判影响等信息同步给模型团队。并且,在整个流程中,双方不是对立的状态,也不是各自扛各自的指标,而是一起扛业务最终的收益。


此外,Capital One 在培训体系中还有一个比较有意思的做法,是在内部培训中设立了一门叫做“COF Lessons Learned”的课程。这是一门不断积累案例的培训,积累的都是公司付出过代价、在践行数据驱动业务的道路上实实在在踩过的“坑”。而培训的老师,首选是那些曾亲身参与和经历过这些“坑”的同事、尤其是负责人。案例的内容很丰富,包括对这些项目的业务背景、入坑复盘,梳理当初的思路是什么、为什么会出现问题、是哪个点没有考虑清楚、或者沟通上不够顺畅,最后导致了什么样的业务结果等等。


并且,为了让每一位员工清醒认识数据中既有真相、也有盲区,模型会揭示规律、也会制造错觉,Capital One 还有另一门叫做“Statistical Pitfalls”的内训课,专门讲述各类统计模型和数据分析在支撑业务决策的应用过程中,可能存在的局限性和常见的误区。


“任何技术、任何工具,只有对它的优势、短板、适用性、局限性等有客观的认识,才能把好钢用在刀刃上、真正发挥它的价值。而在这个过程中,前台不应该自诩为商业奇才、中后台也不应该以‘技术大神’自居,探讨问题要以表达清楚、阐述明白为目标,不刻意、不做作。”晋梅强调。

总结


2020 年 4 月,《中共中央国务院关于构建更加完善的要素市场化配置的体制机制的意见》发布。这是中央第一份关于要素市场化配置的文件,首次将“数据”与土地、劳动力、资本、技术等传统要素并列,明确数据是一种新型生产要素。


在这样的背景下,企业需要对数据有客观清醒的认知:首先,数据作为关键生产要素,的确能够给企业带来竞争力提升;但是,数据又不是万能的,它解决不了根本的业务模式问题;另一方面,数据驱动文化的构建、数据思维的培养并非一朝一夕,即便是像 Capital One 这样曾经被“封神”的公司,它的文化价值观也是在不断跌进去、爬出来,再跌进去、爬出来的过程中反复总结和打磨出来的。


所以,留给企业的课题是——在数字化转型过程中,如何尊重规律、尊重分析、讲究逻辑和依据——以业务为船舵,用数据做引擎。

2022-08-11 15:397399

评论

发布
暂无评论
发现更多内容

go实现类似spring BeanUtil工具

Z.K

太强了!GitHub大佬白嫖的SpringCloud微服务进阶宝典,啃完感觉能吊锤面试官!

程序知音

Java 微服务 SpringCloud java架构 后端技术

网络安全之从原理看懂XSS

网络安全学海

黑客 网络安全 安全 信息安全 渗透测试

微服务中的鉴权该怎么做?

江南一点雨

SpringCloud Gateway openfei

Getaverse - 基于Web3.0数字认证引擎协议的元宇宙生态服务平台

Geek_Web3

Web3 Daily #区块链# did web3

从一个 issue 出发,带你玩图数据库 NebulaGraph 内核开发

NebulaGraph

图数据库 开源贡献

Gin路由添加流程

Z.K

Spring 事务失效的六种情况

江南一点雨

spring 事务

大数据培训学习方法有哪些

小谷哥

直播预告丨泛CG元宇宙分会场云桌π—从NVIDIA XR到云渲染,如何构建元宇宙虚拟场景生态闭环

3DCAT实时渲染

CG 渲染 虚拟现实 元宇宙 元宇宙开发

学习java参加培训哪个比较好呢?

小谷哥

基于训练和推理场景下的MindStudio高精度对比

华为云开发者联盟

人工智能 华为云 12 月 PK 榜

智慧交通的待解谜题,中科视语在首届昇腾AI创新大赛交出金奖答案

脑极体

笔记2022-12-06

mklop

学习笔记 构架

Redis事务、pub/sub、PipeLine-管道、benchmark性能测试详解

C++后台开发

redis 中间件 性能测试 后端开发 C++开发

TDH 社区版上新宽表数据库 Hyperbase,轻松实现海量数据的毫秒级精确检索

星环科技

数据库

王者荣耀商城异地多活架构设计

Jack

架构实战训练营9期

Getaverse月报 - 11月

Geek_Web3

区块链 Web3 Daily #区块链# did web3

埃文科技完成数千万A轮融资

郑州埃文科技

网络安全 企业融资 数据服务

HummerRisk V0.6.0:列表高级搜索,对象存储、操作审计扩充支持

HummerCloud

云安全 云原生安全

Getaverse测试网即将上线,节点销售火爆,是否成为下一个GALA?

Geek_Web3

区块链 Web3 Daily #区块链# did web3

SoviChart数据可视化:条形图(Bar chart)

2D3D前端可视化开发

数据分析 数据可视化 可视化图表 sovitchart 条形图

web前端培训应该怎么做

小谷哥

艾瑞《政企数智办公平台行业研究报告》,政企数智办公「百宝书」

融云 RongCloud

办公 数智化

制定数据战略的三大要素和五个步骤!

用友BIP

微服务开发平台 Spring Cloud Blade 部署实践

北京好雨科技有限公司

Kubernetes 微服务 云原生 Spring Cloud

带你了解基于Ploto构建自动驾驶平台

华为云开发者联盟

人工智能 自动驾驶 华为云 12 月 PK 榜

消息队列跨区域协同方案的演进

移动云大数据

kafka pulsar

前端培训学习需要什么条件?

小谷哥

小游戏的前世今生

FinFish

微信小程序 休闲游戏 小游戏 H5小游戏

学习web前端培训怎么样呢

小谷哥

数据思维的关键,不只是要“善用数据”更要能“解决问题”_技术管理_高玉娴_InfoQ精选文章