谈谈数据项目的挑战

近几年,随着数据和人工智能越来越受关注,数据与人工智能项目(统称数据项目)也遍地开花,和传统应用类项目相比,数据项目有其自身的特点和挑战,本文就来盘一下这些挑战。

01 数据质量,横亘在理想与现实之间那道坎

企业想从数据里面发掘价值,首先需要有数据,大部分企业面临的问题不是无数据可用,而是无可用数据。

多年的业务经营,许多企业已经积累了大规模的数据,看上去是一笔巨大的财富,这就会造成一种假象,会让企业的管理者和高层过高估计数据给他们带来的价值,相应的也会对数据项目产生过高的预期。

理想状态下,数据是能够带来价值的重要的生产要素,但现实是,真正打开之后,才会发现可以直接拿来使用的数据并不多,比如数据存在各个系统孤岛里,获取不到;比如,数据的标准不统一,口径不一致;比如,数据中出现大量的错误,许多关键数据是缺失的,矛盾的,等等,这些都是数据质量问题。

举个典型的例子,服务过的某家车企,想做一些老客深挖、通过老客引入购车机会的事情,这个工作需要基于数据分析老客的特点和行为特征,从而预测老客带来新客户的可能性,但当真正基于数据做客户分析和模型开发时,发现只有不到40%的数据可用,可想而知,模型结果也就不具备很高的参考性,这和企业的期望是相背的。

所以数据项目从立项那一刻起往往就背上了一个不切实际的预期,项目被认为是炼丹炉,数据进去,丹药出来,包治百病,很少会有人考虑炼丹成功的几率问题。

要提高胜算的几率,也是有方法可循的,比如盘资产、提质量、推确权,解决历史数据中的遗留问题,从源头上管控好数据的生产问题,也就是把企业的数据统一、科学、专业的管理起来。

唯有如此,才有可能提高数据价值兑现的可能性,但这需要一个过程,这也是企业的系统工程。

总的来说,数据质量问题,是横亘在理想与现实之间难以逾越的那道坎,解决这个问题,需要决策者保持清醒的头脑,也需要决策者拥有大胆革新的魄力。

02 跨部门合作问题,人的问题最关键

许多企业里面,数据的生产者、使用者、管理者、所有者来自于不同的团队,所以和应用类项目的开发比起来,数据项目需要更多的团队和部门参与和支持,但由于大部分部门的KPI是和部门内部的职责相关的,每个部门的权责利清晰,当跨部门的协作和本部门的资源或者利益出现冲突,协作的动力便会出现问题,所以跨团队合作在很大程度上增加了数据项目的复杂度。

举个现实中的例子,曾参与过某家零售企业数据驱动的供应链数字化转型项目,项目由一把手推动,轰轰烈烈展开,启动会议上,各部门的负责人也是拍着胸脯喊口号、表决心,给人一种上下一盘棋、未来可期的壮丽景象。

但当真的着手开展工作时,会发现各部门有各部门的生存压力,年度指标压着,部门考核绑着,资源计划空着,整个数据项目就是在各自KPI之外的“爱心工程”,项目进展到第二个月,大部分部门的参与度就已经明显降低,信息收集不上来,任务推进不下去,接口人频繁变更,最终连会议也很少参加了,刚开始的时候,一把手过问一次,紧迫感提升一点,但一把手也苦于没有精力紧盯执行细节,渐渐地也就相信了各部门已经尽了最大的努力在做好份内的事情,数据工作不是想象的那样立竿见影,可以在未来徐徐图之,只是这个未来在什么时候,是不确定的事情。

这就是为什么很多数据项目,会经历高高举起、轻轻放下的过程。

总的来说,数据项目要做到有始有终,有目标、有行动、有结果,跨部门协作是绕不开的话题,归根结底这也是解决人的问题,这需要在立项的时候,相应的有组织设计上面的辅助支撑,比如,责权利的重新界定,比如KPI的调整设计,等等,跨部门协作的事情如果不能得到解决,企业里一系列和数据相关的工作,很容易变成只有开始没有下文的结局。

03 价值衡量的问题,一个悬而未决的问题

数据项目还会遇到另外一个挑战,也和跨部门协作相关,那便是如何衡量价值,如何测算ROI(投资回报率),这是很现实的一个问题。

因为要持续获得投入和支持,就要看项目的产出结果,也要看投入产出比,要获得跨部门多个团队的支持,就要给对方带来看得见的利益和价值,归根结底,数据项目如何衡量结果和价值呢?

这些价值对应到应用类开发项目,可以是上手的功能,华丽的界面,友好的用户交互体验,可以用“姣好的颜值”、顺畅的流程、提升的效率来衡量结果,也可以用获得的客户满意度来证明价值,但很多数据项目,大部分工作隐藏在“冰山”之下,比如,数据接入、数据处理、数据清洗,比如,模型开发、测试、优化,比如,数据治理,套用冰山模型来解释的话,这些数据工作如果能让人看到冰山之上30%的结果,通常代表冰山之下至少有70%的投入,所以,数据项目的投入产出比经常会受到挑战。

尽管有许多从业者已经在不断寻求和验证数据项目的衡量标准,但直到现在业界没有很好的实践和标准供参考,在这个标准被找到之前,估计还会有很长的一段路需要摸索。

04 业务与技术的调和问题,志不同则道不合

业务团队和技术团队的出发点不一样,经常会体现在诉求的不一致上,但项目的成功依赖于两个团队对于目标的认识保持一致,也需要双方对行动方案给予支持。

现实场景中,业务拥有最多的上下文,希望技术团队快速满足业务诉求是最高优先级,哪怕诉求还没有成体系,也可能会存在频繁变更的可能,但“多快好省”是永远正确的追求,但技术团队要考虑变动带来的影响,要考虑架构,考虑资源,考虑远期目标与短期需求,所以,满足了“多”,不一定能“省”,要追求“好”,实现起来不一定“快”。

比如,建设中台,或许能解决远期的效率,但未必能提升近期的速度,比如,数据治理,能辅助未来的决策更贴近“精”和“准”,但既需要业务团队参与,又需要时间周期,而业务团队背着指标分身乏力,开展业务紧迫在时间上往往也等不起。

业务和技术的矛盾,尤其在数据工作上,调和起来有很大的难度和挑战,但两个团队又互相依赖,在很多企业里面,业务依赖技术团队走项目流程,技术依赖业务提供需求上下文,并给予产出结果肯定或反馈。

解决这个问题,需要双方共同努力,业务和技术分享业务上下文,帮助技术了解诉求背后的原因和压力,技术帮助业务了解数字化和数据背后的原理,双方统一语言,频繁沟通,最终实现认知和理解上的一致。

以上是一种理想的状态,要达到这种状态,企业在文化上要鼓励沟通,尤其是跨部门沟通,在环境上要营造开放的氛围,倡导包容与理解,在组织结构和绩效考核上,要设置一些促进信息共享、跨部门合作的标准和激励。

如此,企业在整体的协作上得到调和,企业级的信息共享问题才有可能得到缓解或解决。

05 数据思维问题,一切问题的起点

在这个上下文中,数据思维是一种思考的能力,简单来讲就是如何看待数据,以及对数据能带来什么价值、如何带来价值的认知。

近几年,数据被提的次数多了,加上数据经常会和人工智能一起被提及,不同的人对数据思维的理解有着千差万别,这里面也不乏有一些错误的认知。

比如,数据是面魔法镜,能够看过去知未来,如果数据告诉不了我答案,那一定是方法有问题;比如,数据问题是技术问题,和业务没有关系;比如,数据如果不正确,一定是计算逻辑出了问题,系统的错;比如,技术是个魔法棒,如果结果达不成预期,那肯定是能力跟不上。

之所以出现这样一些认知,是因为数据思维还没有建立起来,确切的说,是科学合理的数据思维没有建立起来。

很多应用类项目的开发,是思维先于行动的,也就是说,先对结果有了相对合理的预期,然后开展行动,而很多数据项目是从尝试开始的,过程中充满探索,充满未知,许多传统企业沿袭的是“不承诺结果便不能投入”的决策规则,所以数据项目立起来困难重重,即使是冲破各种困难走上探险之路,在开发的同时,也肩负着和具有不同数据思维的人沟(ZHAN)通(DOU)并影(JIAO)响(YU)他们的工作,这些都会使数据项目的困难度和复杂度陡增。

总的来说,数据如同企业的生命线,它的产生和流转贯通企业的业务和运营,数据的工作牵一发而动全身,绝不是拿着钳子拧螺丝就能解决的简单明了且具体的事情,要把数据工作想清楚,规划好,执行下去,既要做正确的事,又要正确的做事,需要企业上上下下具备数据思维。

这种思维需要在业务和数据之间建立联系,既要创新又要谨慎,既要守住优势,又要探索新知,不保守不冒进,所以说,数据思维是企业整体的能力,建设这种能力也是数据项目的挑战和使命。

总结一下,和应用类项目比起来,开展数据项目会面临一些新的挑战,这些挑战给数据项目的开发和管理带来了新的困难,如何更专业更成功的管理好数据项目,这些实践值得被探索和总结。

发表回复

您的电子邮箱地址不会被公开。