解密Palantir系列一：2. 传统软件的三大断裂

解密Palantir系列一：2. 传统软件的三大断裂

第一性问题

为什么企业买了 BI、ERP、数据仓库、数据湖、AI 平台，决策还是慢、断、不可追责？

上一节我们讲过，一次完整决策至少包含三件事：

1. 数据（Data）：我知道什么；
2. 逻辑（Logic）：我怎么判断；
3. 行动（Action）：我改变什么。

再加上行动后的结果回流，才构成真正的决策闭环。

但现实中的企业很少缺软件。大多数中大型企业不是系统太少，而是系统太多：

1. 有 BI，看得见指标；
2. 有 ERP / CRM / MES / WMS，能执行业务动作；
3. 有数据仓库 / 数据湖 / ML 平台，能存储、加工、建模；
4. 有飞书、钉钉、Teams、邮件、Excel，能临时协作；
5. 甚至还有 RPA、iPaaS、数据目录、数据中台。

问题是：

这些软件分别优化了“看”“想”“做”的一部分，却没有天然组成“看 → 想 → 做 → 回流”的决策闭环。

这就是传统软件的三大断裂。

传统软件的三大断裂：BI、ERP、数据湖没有天然形成决策闭环

图：传统软件各自很强，但 Data、Logic、Action 之间没有天然闭环。

目标

你能：

1. 说清楚企业里的 Data / Logic / Action 分别通常由哪些软件承担；
2. 解释 BI、ERP、数据仓库/湖仓/ML 平台之间的结构性断裂；
3. 避免把问题简单归因成“工具不够好”或“再买一个工具”；
4. 理解为什么 Palantir 要把 Ontology 放在核心位置；
5. 用一个具体业务场景诊断你自己公司的决策断裂。

一、先给答案：不是工具不强，而是工具之间没有共同语言

企业软件大致可以按三类理解：

图：Data、Logic、Action 分别被不同软件承载，局部强大，但缺少共同业务语言。

看起来很完整。

但只要进入真实业务，就会发现一个问题：

这些系统的对象不一样、语言不一样、权限不一样、动作不一样、记录方式也不一样。

同一个“订单”，在 ERP 里可能是财务凭证和交付项；在 CRM 里可能是客户机会的结果；在 WMS 里是拣货和发货任务；在 BI 里是一行聚合指标；在数据湖里是一组分区表；在业务经理嘴里则是“这个客户能不能按时收到货”。

所以，传统软件不是没有能力，而是能力被切成了不同孤岛。

Palantir 相关材料里反复出现一个核心观点：现代企业需要的不是单纯数据架构，而是围绕决策组织起来的软件架构。Ontology 白皮书把决策拆成 Data、Logic、Action；AIP Overview 把企业 AI 需要连接的对象分成 Enterprise Data、Enterprise Logic 和 Systems of Action；Foundry 白皮书则强调，数据集成、可视化和点状分析不足以真正驱动企业运营，关键是形成跨数据、分析和业务团队的软件定义反馈环。

这三份材料指向同一个问题：

传统企业软件通常优化局部能力，Palantir 想修复的是全局闭环。

二、断裂 #1：BI 只看不动

1. 典型场景

一家连锁零售公司，分析师在 Tableau 或 Power BI 上看到一张图：

华东 3 号仓某类商品库存周转异常，未来 5 天可能出现缺货。

这时候，BI 做得很好：它让问题被看见了。

但下一步呢？

分析师通常不能直接在 BI 里：

• 创建调货单；
• 修改补货计划；
• 通知仓库和物流；
• 调整门店库存策略；
• 写回 ERP / WMS / SCM；
• 记录“这次为什么调货、谁批准、结果如何”。

现实流程往往变成：

BI 看板发现异常 ↓ 截图发群 ↓ @ 业务经理 ↓ 经理再打开 ERP / WMS ↓ 人工判断、人工操作、人工催办 ↓ 结果散落在聊天记录、Excel、ERP 字段里

图（流程图）：BI 能让异常被看见，但后续处理离开系统，进入截图、群聊、人工判断和手动写回。

问题不是 BI 没价值。BI 非常有价值，它解决的是“看见”。

问题在于：

看见问题，不等于执行决策。

2. 断裂在哪里

BI 的典型断裂有三层：

有些 BI 工具支持写回、注释、协作和嵌入式操作，这一点不能一概否定。

但公开发布时要讲清楚边界：

关键不是“BI 能不能写一个字段”，而是它能不能把业务动作作为可治理、可审计、可回流的 Systems of Action 来处理。

大多数情况下，BI 仍然停在“信息层”。

3. 类比

BI 像汽车仪表盘。

它能告诉你油量低、水温高、车速异常。

但仪表盘本身不会：

• 自动规划维修；
• 调度拖车；
• 联系 4S 店；
• 改变发动机状态；
• 记录这次故障后续是否解决。

仪表盘重要，但它不是驾驶系统，也不是维修系统。

4. 这一断裂的本质

BI 的本质问题不是“不够智能”，而是：

它通常缺少对业务动作的原生建模。

它看到的是指标，而不是“可以被执行、被审批、被审计的 Action”。

这就是第一条断裂：

看到了 ≠ 做了。

三、断裂 #2：ERP / CRM / MES 能做，但看不全、想不深

1. 典型场景

同一家零售公司，仓库管理员在 SAP 或 WMS 中看到某商品库存偏低。

ERP / WMS 可以执行动作：

• 创建采购申请；
• 调整库存；
• 生成出入库单；
• 触发补货流程；
• 更新财务和库存记录。

这类系统是真正能“改变现实”的系统。

Palantir AIP 资料里把这类系统称为Systems of Action，也就是行动系统。

但行动系统有另一个问题：它通常只知道自己负责的那一段现实。

例如，WMS 看到库存，却未必看到：

• 最近 7 天销售趋势；
• 门店促销计划；
• 港口延误；
• 供应商风险；
• 客户订单优先级；
• 替代物料策略；
• 预测模型结果；
• 财务影响；
• 客户投诉风险。

于是系统能执行，但判断视野很窄。

2. 断裂在哪里

ERP / CRM / MES / WMS 的典型断裂如下：

这不是 ERP 的错。

ERP 的设计目标通常是让流程稳定、凭证正确、财务一致、权限严谨。它很适合承载标准化动作，却不一定适合承载跨系统、跨部门、实时变化的决策推演。

3. 类比

ERP 像手脚。

它能把动作做出来，而且做得稳定、可控、可记录。

但手脚不知道全局情况。

如果没有眼睛、地图、大脑和反馈，手脚可能非常勤奋地做错事。

4. 这一断裂的本质

行动系统的本质问题不是“不能行动”，而是：

行动系统往往缺少跨系统的业务语境和可组合逻辑。

它知道“怎么做”，但未必知道“为什么现在要这样做”。

所以第二条断裂是：

做得了 ≠ 想清楚了。

四、断裂 #3：数据仓库 / 数据湖 / ML 平台能存能算，但难以进入行动

原文里把第三个断裂写成“数据仓库只存不算”。这个方向需要稍微修正。

对公开 blog 来说，更准确的说法是：

现代数据仓库、数据湖、湖仓和 ML 平台并不是不能算；它们很能算。真正的问题是：算出来的东西很难自然进入业务动作。

Snowflake、Databricks、BigQuery、Redshift、SageMaker、Notebook、dbt、Airflow、Spark、Flink 都很强。它们能存、能算、能建模、能训练、能调度。

但它们通常仍然面临一个问题：

表、特征、模型、指标，不等于业务对象、业务判断和业务动作。

1. 典型场景

数据团队把全公司的数据接进湖仓，建了大量表：

fct_order_v3 dim_customer_clean dwd_inventory_daily ads_supply_risk_score ml_demand_forecast_output

数据科学家训练出一个需求预测模型，发现某类商品未来 5 天可能缺货。

问题来了：

• 哪个业务对象代表“这个风险”？
• 谁能看到这个风险？
• 风险对应哪个订单、哪个仓库、哪个门店、哪个供应商？
• 谁有权把预测结果变成补货申请？
• 这个动作写回 ERP、WMS 还是采购系统？
• 动作执行后，结果如何回到模型评估？

如果这些问题没有答案，模型再准，也只是停在数据团队的工作区。

这就是很多 AI / ML 项目卡在 Demo 或 Pilot 阶段的原因。

2. 断裂在哪里

数据平台的典型断裂如下：

AI/ML 运营资料里讲过一个关键问题：很多组织拥有模型和数据，但缺少把模型从开发沙箱推进到一线运营工具的框架。需要可信数据基础、用户和模型团队之间的反馈环、安全写回机制、共享安全和血缘框架。

这段话放到本节，就是第三条断裂的核心：

算得出 ≠ 用得上。

3. 类比

数据湖像一个巨大的原料仓库。

里面有钢材、木材、玻璃、螺丝、图纸、传感器、历史记录。

但仓库本身不是工厂。

你还需要：

• 知道每个原料对应什么产品；
• 知道生产规则；
• 知道谁能下生产指令；
• 知道成品要交给谁；
• 知道生产结果如何反馈。

否则，原料再多，也只是堆在仓库里。

4. 这一断裂的本质

数据平台的问题不是“不够强”，而是：

它的核心抽象通常是表、文件、特征、模型，而不是企业正在操作的真实业务对象和动作。

所以第三条断裂是：

存得下、算得出 ≠ 能进入业务闭环。

五、三大断裂合在一起：企业的“决策脊柱”断了

我们把三条断裂放在一起：

图：三大断裂合在一起，企业缺少一根贯穿业务对象、权限、动作、审计和反馈的“决策脊柱”。

可以画成这样：

图（流程图）：三大断裂不是三个孤立问题，而是共同指向“业务对象、权限、动作、审计、反馈没有统一”。

表面上企业系统很多。

本质上缺少一根“决策脊柱”：

把业务对象、数据、逻辑、动作、权限、审计、反馈连成同一套语言。

六、为什么“再加一个工具”通常不够？

很多企业遇到断裂后，第一反应是继续加工具。

这不是完全错误。很多工具确实能解决局部问题。

但如果目标是“决策闭环”，单点工具往往不够。

这些工具不是没用。

它们都很有用。

但它们大多解决的是“连接”，不是“共同理解”；解决的是“传输”，不是“决策”；解决的是“自动化局部动作”，不是“可治理的闭环”。

真正缺的是：

统一业务语义层 + 可治理动作层 + 决策反馈层。

这就是 Palantir 为什么把 Ontology 说成核心，而不是把自己简单定义为 BI、ETL、数据湖或 AI Agent。

七、Ontology 想补的不是“又一个中间层”，而是企业共同语言

如果只用一句话解释 Ontology 在这里的作用：

Ontology 让企业里的名词、动词和规则变成统一、可操作、可治理的软件对象。

在 Palantir 语境下：

所以，Ontology 不是一个“更高级的数据目录”。

数据目录回答：

哪张表在哪里？字段是什么意思？数据从哪里来？

Ontology 进一步回答：

这个业务对象是什么？它和哪些对象有关？能对它做什么动作？谁能做？做完以后结果如何回流？

这就是两者的差别。

八、用一个供应链中断案例串起来

假设一家医疗设备制造商，某个关键原材料供应商突然停产。

1. 只有 BI 的公司

BI 看板显示：

某物料库存低于安全线，相关产品未来两周有缺货风险。

但业务经理还要自己去查：

• 哪些工厂受影响？
• 哪些客户订单受影响？
• 替代供应商有哪些？
• 哪些订单优先级更高？
• 谁能批准临时采购？
• 调整排产会影响哪些交付？

BI 让问题被看见，但行动靠人肉协调。

2. 只有 ERP 的公司

ERP 能创建采购申请，也能更新库存。

但它未必自动知道：

• 替代物料质量风险；
• 客户订单收入风险；
• 物流延误；
• 产线切换成本；
• 模型预测的未来需求；
• 哪个方案整体影响最小。

ERP 能执行，但缺跨系统判断。

3. 只有数据湖 / ML 的公司

数据团队可以建模型：

未来 14 天 surgical mask 产线缺料概率 82%。

但如果模型输出不能变成：

• 具体受影响订单；
• 具体替代方案；
• 具体审批动作；
• 具体写回系统；
• 具体反馈指标；

那它仍然只是一个分析结果。

4. Palantir 式闭环想要的状态

理想状态是：

供应商停产事件 ↓ Ontology 识别受影响对象： 供应商、物料、工厂、产线、库存、订单、客户 ↓ 调用逻辑： 缺货风险模型、替代供应商规则、排产优化器、收入风险计算 ↓ 生成 Scenario： 方案 A 调货、方案 B 替代供应商、方案 C 调整客户优先级 ↓ 发起 Action： 采购申请、排产调整、客户通知、物流变更 ↓ 权限审批 + 写回 ERP / WMS / SCM ↓ 记录 Decision Lineage ↓ 实际结果回流： 缺货是否减少、成本是否上升、客户是否延期、模型是否准确

图（流程图）：供应链中断不是单点预测问题，而是从受影响对象识别、模型规则调用、方案生成、Action 发起、系统写回到结果回流的完整闭环。

图：供应链中断案例中，Ontology 闭环把看见问题、理解问题、执行动作和反馈学习串起来。

这才是“数据 → 逻辑 → 行动 → 反馈”的闭环。

一句话总结

BI 让问题被看见，ERP 让动作被执行，数据仓库和 ML 平台让数据被存储和计算；但企业真正缺的是把“看见、判断、行动、反馈”连成一个可治理闭环的共同语言。Palantir 把这个共同语言叫 Ontology。