从信息化、数字化到AI，转型的方式变了
在过去做信息化和数字化的时代，企业已经很熟悉这套方式：购买软件、采购平台，或者订阅一项 SaaS 服务。服务商交付一套相对成熟的功能，再组织企业人员培训，学会录入数据，甚至为了系统的功能去改变原有的工作流程。
在过去做信息化和数字化的时代，企业已经很熟悉这套方式：购买软件、采购平台，或者订阅一项 SaaS 服务。服务商交付一套相对成熟的功能，再组织企业人员培训，学会录入数据，甚至为了系统的功能去改变原有的工作流程。
SaaS 的全称是 Software as a Service，标准中文是“软件即服务”。很多时候，我们其实是把软件本身作为这项服务的交付结果。
而到了 AI 阶段，最后交付到企业里的，看起来可能仍然是一个软件。但它和以往功能被锁死的信息化系统不一样。它可能是一个 Agent、一个 RAG 知识库或者一个系统交互界面，真正藏在这些软件背后的，是一套 AI 进入工作流、提升工作能力的底层业务逻辑和辅助能力。
所以从外表上看，它好像仍然是一项 SaaS；但现在有一种说法，是把 Software 和 Service 调换了位置。
Service as a Software 可以直译为“服务即软件”。信息化时代的 SaaS 更强调交付软件，AI 时代的 Service as a Software 更强调交付服务结果。整个服务过程由一系列 AI 工具、Agent 和业务逻辑共同完成，最后虽然也可能形成一个看起来类似的软件界面，但一个强调的是软件这个交付结果，另一个更强调服务发生的过程和最终形成的业务结果。
那么，企业拥抱 AI，和传统 ERP 系统所代表的信息化转型并不完全一样。如果还是沿用过去 SaaS 的合同和验收逻辑，系统部署完成了，Agent 做出来了，RAG 知识库也部署好了，就认为已经完成交付，我觉得这里会有很大的问题。
一家传统企业真正需要的，是企业能不能继续生存和发展，而不是有没有部署一个系统、一个软件或者一个 AI。外部团队告诉我“AI 已经给你做好了，所以应该付款”，这还不能证明这项工作已经产生了企业需要的价值。
现在比较常见的说法，就是要计算 ROI。但是站在内外部的视角，看到的 ROI 并不一定是同一件事。
ROI 是 Return on Investment，中文通常译作“投资回报率”，简单说就是投入以后，究竟带来了多少可以确认的回报。
站在外部 FDE 的角度，可能看到的是某个岗位因为 AI 的介入提高了工作效率，原来需要几个人，现在减少了多少人，或者相同的人数和时间能够多输出多少份方案。
站在企业负责人的角度，需要看到的是这些过程变化能不能让公司承接到更多项目，能不能降低真金白银的成本，或者真正提高企业的管理水平。
如果一切技术投入只有技术的自嗨，而没有形成实际的开源或节流，那么这项投入本身对企业来说就没有价值。
所以，软件或者某一个工作节点上的 ROI，和企业的 ROI 不是同一件事。如果只是理论上提高了效率，却没有转化成企业经营和管理上的结果，对企业来说还是没有形成直接收益。这样的应用场景现阶段就没有必要实施；当然，如果它对数据积累有价值，也可以从长计议，这个话题留到以后记录。
并且到了 AI 阶段，模型始终还存在概率性和幻觉。一个知识库部署完成、一个 Agent 能够运行，并不代表它在真实的业务环境里每次都能一直做对。如果继续把“部署完成”当成交付结果，难道后续对 AI 幻觉的处理和持续迭代，还需要像过去的软件从 1.0、1.1 到 1.2 一样，再逐次支付迭代费用吗？
另外，对于软件系统形成的过程，我觉得：即使软件开发到一定程度，可以比较确定地实现一组功能，让业务为了适应软件功能、为了让系统里有数据而改变真实业务中的工作习惯和流程，这种系统建设方式本身也一直值得商榷。
当然，AI 也会改变工作场景、工作习惯和数据标准。但这种改变应该服务于新的业务流，是因为企业愿意按照新的业务逻辑去工作，而不是为了配合一套软件顺利验收。
这个时候，我们就不得不引入 FDE 这个概念。当然，我现在张口 FDE、闭口 FDE，有时候也觉得自己像一个神教的神棍。但基于我们公司的性质，我确实觉得这个角色有必要存在，也需要用它来解释为什么会有下面这些结论。
FDE 是 Forward Deployed Engineer 的缩写。这里更重要的不是怎样翻译这个职位名称，而是这种工作方式：进入真实业务现场，和业务人员一起发现问题，从需求梳理、方案设计、动手实现一直做到实际使用，再把反馈和有效的方法持续沉淀下来。
我想先用“物理反应、化学反应和工艺包”这组概念，解释为什么企业内部需要自己的 FDE。
我觉得，信息化和数字化时代的转型，在业务层面更多发生的是一种物理反应。就像把钢板切割或者焊接，外观和组合方式发生了变化，但材料本身的性质没有发生变化。
很多业务因为信息化被重新拆分到不同岗位、部门、流程和管理层级，由不同的人去完成流程上的工作，但工作的性质并没有发生太大变化，因此对业务 ROI 的改变也往往停留在物理层面。
AI 时代开始出现的则可能是化学反应。它要求回到第一性原理，重新思考这项工作到底应该怎样完成。过去分属于 A 业务和 B 业务的共性工作、同质数据，很难在原有部门边界里重新定义归属；而在化学反应的视角下，更重要的是它们怎样被 AI 贯通，怎样形成比现在更好的企业 ROI。
化学反应发生以后，旧的“化学键”断裂，新的“化学键”形成。某项工作原来属于哪个部门、由谁管理，不再是唯一的出发点；真正需要判断的是，重新组合以后给企业带来的价值是不是比以前更大。我觉得，这就是 FDE 的第一性原理。
推动这种变化当然会遇到人力资源、人情世故和利益划分，也会反复遇到先有鸡还是先有蛋的问题。但这恰恰是每一家企业需要培养自己的 FDE、自己定义 AI 怎样改变企业的原因。外部的服务团队进入一家企业以后，遇到谁都是半个业主，很难主动去触碰人际和利益关系，它的第一性原理更可能是合同里的付款条款。
所以对公司来说，内部 FDE 就像化工行业里掌握“工艺包”的人，他们决定这场化学反应怎样发生；外部技术服务商更多提供模型、平台、开发、硬件和部署能力，围绕化学反应的目标，完成相应的物理反应工作。如果公司内部有 FDE，就不应该只是坐在那里听外部 IT 企业介绍：他们能做一个什么样的知识库，在别的单位做过一个什么 Agent，然后把同样的东西拿回来使用。否则，我们又会回到过去购买软件、再让业务适应软件的状态。
内部 FDE 首先要从企业的业务 ROI 出发，把场景切开，明确现阶段 AI 的能力和企业能够提供的资源，再决定这一块要实现 AI 赋能还是 AI 原生，定义这条业务流最终要发生什么变化。外部软硬件服务商提供的能力，都应该围绕这个场景展开。
AI Added（AI 赋能）：在原有业务流中加入 AI，由 AI 提供辅助能力。
AI Native（AI 原生）：从业务目标出发，把 AI 作为核心能力重新设计业务流，而不是只在原来的流程上增加一个 AI 功能。
所以，企业内部要培养或者挖掘自己的 FDE，才是 AI 时代要做的最重要的第一项工作。这些人真正要盯住的，不是系统有没有部署、Agent 能不能运行，而是企业的 ROI 有没有形成。只有业务目标、应用场景、评价方法，以及责任边界应该如何改变先被定义，外部技术服务才有明确的交付对象，这时候你才比较大概率能找到不忽悠人的外部服务团队。
而且我们说 AI 最重要的不是学，而是用。服务团队能够解决的是部署，让你学会上手；真正让你一直能够用下去的，还是内部的 FDE。
- 暂时没有评论，来说点什么吧