序章 · 第四次听见“这次不一样”

状态：公开初稿 v0.1.0 编校说明：文中项目现场采用作者多年观察的复合场景，不指向某个具体客户；个人经历只保留概括性表达，不作为行业事实的单独证据。

这些年，我至少听过四次“这次不一样”。

第一次是 ERP。那时候大家相信，只要把采购、销售、库存、财务全装进一个系统，企业就能像一台机器那样运转。流程定好了，权限分清了，数字对上了，以前靠人盯、靠嘴问、靠本子记的事，自然会消失。

后来是云。系统不用一套一套装了，企业也不用自己养那么多服务器。听上去，旧问题搬到云上，多少会轻一点。

再后来是大数据和数据中台。口号又往前走了一步：不只是把业务放进系统，还要把散落的数据收回来，统一口径、统一指标、统一服务。以后业务要什么，不必每次从头做。

现在轮到大模型。模型能读文件、听人话、写方案、调工具，大家又说，企业要被重新做一遍。

四次不一定数得准。中间还有移动互联网、SaaS、低代码、RPA，个个都说过类似的话。说的人也未必是在吹牛。每一轮技术都解决过真问题，也都留下过真东西。只是我干了十八年企业数字化，见过的另一个事实是：系统越来越多，Excel 没怎么少；报表越来越漂亮，照着报表办事的人不一定更多。

这就有点尴尬了。

一个项目最热闹的时候，通常是启动会。会议室坐满人，领导讲战略，乙方讲蓝图，PPT 上的箭头从数据源一路指向驾驶舱，最后落在“赋能经营”四个字上。

几个月以后，系统上线，项目验收。再过一阵子，业务部门又发来一个 Excel，说这个数麻烦重新核一下。

你问他，系统里不是有吗？

他说，有是有，但老板看的不是这个口径。

你再问，那到底哪个数是真的？

他说，都是真的，只是用途不一样。

我年轻时遇到这种事，第一反应通常是数据有问题。表没建好，ETL 没跑对，指标定义得不够严谨。技术人碰到问题，总觉得再加一层模型、补一张表、改一遍口径，事情就能变干净。

干久了才知道，很多时候数据并没有错。

麻烦在后面：看数的人没有行动权，有行动权的人不看这张表，最后承担结果的人又在看另一套数。系统解决了信息问题，企业还没解决谁判断、谁拍板、谁执行、谁负责。

这不是某一代技术的错，却是每一代技术都会撞上的墙。

数据是生意，还是生意留下的影子

这堵墙到了数据中台那一轮，变得特别明显。

很多互联网公司做数据，有一个传统企业很难照搬的条件：它的业务本来就长在软件里。

用户点了什么、搜了什么、买了什么，平台都能看见。推荐规则改一下，流量马上变；活动页面换一个版本，转化率很快就有反馈。数据从业务里产生，又能直接回到业务里。对这类公司来说，数据不只是分析材料，它本来就是产品和经营的一部分。

传统企业不是这么回事。

一间工厂的利润，长在原料、设备、工艺、交期和现场管理里；一家酒店的生意，长在房间、渠道、服务和客人的感受里；一家保险公司的风险，也不只在数据库里，还在合同、调查、审核和人的判断里。

这些企业当然也有系统，也会产生大量数据。但数据更多是现实业务留下来的记录，有时甚至只是影子。现场已经发生了，系统晚一点才知道；老师傅已经处理完了，原因却没有留下；报表看见一个异常，能改流程的人可能根本不在数据部门。

所以，同样叫“数据平台”，放在两类企业里，做的不是完全相同的事。

互联网公司把平台做好，可能直接改变产品和收入。传统企业把平台做好，往往只是让人更清楚地看见问题。至于问题会不会被处理，还要经过部门、权限、预算、流程和责任人。

这不是说互联网公司的办法一定不适合传统企业，也不是说传统企业注定做不好数据。更该问的是：一个方法原来依赖什么条件？搬到另一种企业以后，这些条件还在不在？

过去不少数字化项目，吃亏就吃在这里。我们搬走了架构、术语和建设方法，却没有一起搬走它背后的业务环境。最后平台建得很像，结果却不像。

AI 这一次，确实有点不一样

既然前几轮都没有跨过这堵墙，为什么今天还要认真谈 FDE？

因为 AI 这一次，确实把软件往前推了一步。

以前的系统大多负责记录、计算和展示。BI 发现某个指标变红了，接下来还是要有人判断原因、找资料、联系部门、修改系统。软件把问题送到人面前，人的活从那里才接上来。

现在的模型能读邮件、合同、图片和聊天记录，能把散落的材料拼起来，也能调用工具。它不只告诉你“这里可能有问题”，还可以准备下一步动作：生成回复、填写工单、修改订单、通知客户，甚至触发资金和生产流程。

软件一旦开始动手，事情的性质就变了。

以前报表算错，最多是有人拍桌子、重新出数。现在 Agent 做错，邮件可能已经发给客户，订单可能已经改了，钱可能已经付了，设备也可能已经停了。你不能只问模型准不准，还得问它有什么权限、谁批准、错到什么程度必须停、事后能不能把过程还原。

更麻烦的是，企业还会继续问那个最朴素的问题：花了这笔钱，到底多赚了什么，少亏了什么，还是只多了一个演示？

到了这里，传统的岗位分工开始不够用了。

业务顾问懂现场，但未必能把系统做出来；工程师能写代码，但未必知道什么问题值得做；实施团队负责上线，产品团队负责版本，销售负责合同，客户成功负责续约。每个人都完成了自己的部分，最后那个结果却可能没人完整负责。

FDE 就是在这个缝里变得显眼的。

它身上的每一项能力都不新：现场调研、业务建模、数据集成、写代码、陪客户上线，过去都有人做。变化在于，这些原来分散在不同岗位上的责任，被压到了同一个人或同一支小队身上。

他不能只说“需求不是我定的”，也不能只说“系统已经上线”。他得从问题有没有找对，一路跟到客户敢不敢用、用了有没有效果、出了事能不能收回来。

所以我不太愿意把 FDE 简单说成 BI 的下一站。

BI 没有顺着一条直线长成 FDE。FDE 的来路里，还有实施顾问、解决方案架构师、产品经理、客户成功和那些常年蹲在现场的无名工程师。

但我也不相信 FDE 是 2023 年以后凭空冒出来的新物种。

它面对的数据口径、需求失真、系统烟囱、部门壁垒和项目制，都是企业数字化踩了几十年的坑。不了解这些来路，就很容易把 Agent 做成更会说话的报表，把本体做成换了名字的字段字典，再把 FDE 做成收费更贵的驻场外包。

为什么这本书不从 Palantir 开始

讲 FDE，当然绕不开 Palantir。

这个岗位的正式历史、组织方式和今天的行业热度，都必须讲清楚。只是这本书不准备从那里起笔。

原因也简单。关于 Palantir 如何把工程师送到客户现场，OpenAI 和其他模型公司为什么重新重视部署，已经有人整理得很好。如果再沿着同一条线写一遍，我最多只是补几段中文材料。

我更想补另一段来路。

在 FDE 这个名字传进来以前，中国已经有很多人在干与它相似的活。他们在电信机房里对口径，在银行项目里跑批次，在工厂里梳理流程，在酒店和零售企业里做经营分析。他们的岗位可能叫实施、咨询、数据工程、系统分析、解决方案，甚至什么正式名字都没有。

这些人留下的经验，不会因为大模型来了就作废；他们踩过的坑，也不会因为岗位换成三个英文字母就自动填平。

这本书想做的，是把这段路重新走一遍。

不是为了证明老技术比新技术重要，也不是为了给数据老兵发一张 FDE 资格证。恰恰相反，老兵有老兵的包袱：容易迷信完整架构，容易先建平台再找业务，容易把技术上的正确当成经营上的有效。

新人没踩过旧坑，不是缺点。不知道坑在哪里，还坚持油门踩到底，才麻烦。

这本书会下判断，但不会假装有标准答案。哪些旧本事应该带走，哪些旧习惯必须放下；哪些 FDE 概念只是换了名字，哪些确实改变了软件交付；互联网公司的经验哪些可以借，哪些搬到传统企业就会变形——这些问题，我都会尽量说清楚。

最后还得回到那堵墙。

企业已经花了几十年，把现实业务写进系统，把系统里的数据做成报表，再把报表堆成平台。今天，AI 开始试着越过报表，直接参与行动。

这最后十米，过去主要靠人走。现在机器也想走。

谁给它带路，谁替它划线，走错了谁把它拉回来，走到了又怎么证明这趟路值得——这才是 FDE 真正要接下来的活。

而要说清这件事，我们得先回到最老、也最容易被忽略的一步：

企业为什么要把一笔真实的生意，写进系统。

序章资料

场景说明：序章中的启动、验收与报表使用情境为企业软件项目的复合场景。