近些年,一个越来越明显的趋势可以看到,很多数字化转型的项目与传统IT项目之间的差异越来越大了。
“领了需求,回去开发”的项目交付模式,几乎再也行不通——事实就是,数字化项目在实施的过程中和客户的耦合变得越来越紧密了。
数字化项目越来越像服务项目,而不是传统意义上的IT外包项目,尽管可能提供IT能力的仍然是同一拨工程师。
早期信息化时代,绝大多数企业都完全没有接触过IT能力,业务体系也相对简单,简单定制几个管理工具,或者稍微配置变更一些ERP流程,企业就可以快速享受到“数字化”的红利。
而当今,好做的“数字化”基本上都做完了。
剩下的几乎都是“非标业务”,需要深度的行业“Know How”,要么就是以系统集成和总体架构变革为目标的复杂任务。
前者,需要长期跟业务人员一起“通吃同住”积累经验,无法短平快得到解决方案,并且即便是建设完成,也要被业务人员“长期折磨”。
而后者,又会陷入到各部门、各单位之间的协调扯皮之中,直接把“企管部”的活儿也给做了。IT厂商顶上去统筹,有责任但没权利。
“数字化应该是轻建设、重运营” 这几乎成为了的行业共识。
如果干软件、干数据,真的就只是盯着自己所掌握的技术那块一亩三分地,啥也做不成
IT和业务要求实时同步,融为一体。
数字化能力和业务能力几乎是同时建设或升级。但是,所谓的“业数融合”,真的那么容易么?
提供数字化能力的厂商都希望项目可以按照产品的方式进行交付,但是又经常被客户拖到“重服务”的泥潭中。
“个性化交付的比例越来越高,利润率越来越低”
身边的厂商都在这样抱怨,但这确实是大家当前不得不面对的一个行业普遍现状。
不前期投入,就不知道应该干啥;不后期提供维护,就证明不了技术价值。
厂商干的越来越卷,与此同时,客户的意见也一直都在“反增不减”。
数字化项目的成本哪儿去了?
成本不在工具研发,而更多地消耗在所谓“业数融合”的各个环节中了。但是这个所谓“沟通”、“维护”的工作经常被认为是免费的、附赠的,不大会被买单。
“开发那几个功能模块就值这么多钱么?况且还不太好用。”很多客户都曾这样质疑。
数字化项目,逐渐变成了“鸡肋业务”。
其实,不管是厂商也好,还是亟需数字化转型的客户也好,大家都不希望数字化是产品、是工具,而不该是繁冗的服务。
但是,“非服务化”形态的数字化项目,它就是很难“落地”。
当今,市场上不是没有数字化需求,而是缺少容易交付的数字化需求。如果商业上的链路走不通,这些需求就势必成为伪需求。
对于IT厂商来说,未来,比拼的不是谁有提供数字化技术的专业能力,而是谁的项目交付成本更低,谁的项目交付形式更敏捷。
因此,在数字化项目中,IT工具的可扩展性和自适应性就变得非常重要。
当需求变更时,马上就可以进行低成本的调整,甚至能够快速扩展到不同的业务领域。
与此同时,“低代码”的策略也将变得越来越流行。
在特定的应用架构下,把技术变更的权利“转交”一部分给真正懂业务的客户自己。
当然,真正的“低代码”不应该是真的让用户自己去“自助”完成工具的配置,毕竟愿意这样做的客户并不多。
“低代码”工具,应该具有更强的业务理解能力和更友好的任务交互能力。
例如,这两年关于“大模型”的技术出现,提供了很多优秀的产业实践思路。用户自己去配置软件系统很难,但是用“大模型”的门槛很低。
例如,我们的Note Keeper项目在这方面做了很多探索性的实践。
我们基于“大模型引擎”,充分整合了企业知识应用和数据治理方面的需求,让用户可以自主配置数据加工链路,更加高效释放数据资产价值。
同时,用户可以自己按需去“配置”各类应用的逻辑范式,从而更加灵活地将成熟的数字化能力融合到各项业务环节中。
企业数字化转型,到底是重工具,还是重服务。其实这并非是选择题,这只是一个成本平衡的决策问题。
如果有高效、柔性的工具,有效降低了“业数融合”的鸿沟,依然可以很好地进行兼顾。
相信随着生产工具的改进和服务模式的改进,就像早期互联网行业的发展和产业化进程一样,以后的数字化项目可以不用做的这么“痛苦”。
猜你想看更多文章,关注公众号“大话数字化转型”