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