登录

当国内软件都在学Palantir,真正的天花板在哪里?


速读:越来越多的软件公司开始讲业务对象、知识图谱、Ontology和智能体,也都希望把分散在ERP、MES、PLM、供应链和质量系统里的数据连接起来,帮助企业做跨域分析和智能决策。 Palantir真正值得学习的地方,是它没有把数据平台停留在报表和分析层,而是进一步把客户、产品、设备、订单、批次等数据组织成业务对象,让这些对象进入应用和企业运营。 我可以统一业务口径; 这些内容,本质上是企业对自身业务的理解。 它让行业看到,企业软件的终点不是“把数据管起来”,而是“让数据参与行动”。
2026年09月09日 16:06

过去几年, “中国版 Palantir ”逐渐成为国内数据智能市场一个很有吸引力的标签。

越来越多的软件公司开始讲业务对象、知识图谱、 Ontology 和 智能体 ,也都希望把分散在 ERP、MES、PLM、供应链和质量系统里的数据连接起来,帮助企业做跨域分析和智能决策。

这个方向本身没有错。

Palantir 真正值得学习的地方,是它没有把数据平台停留在报表和分析层,而是进一步把客户、产品、设备、订单、批次等数据组织成业务对象,让这些对象进入应用和企业运营。

它让行业看到,企业软件的终点不是“把数据管起来”,而是“让数据参与行动”。

但我认为, 国内软件公司如果只是复制 Palantir 的产品概念、页面形态和重度服务模式,很快就会遇到自己的天花板。

因为当越来越多厂商都开始讲 Ontology ,“有没有”已经不再重要。

真正需要回答的是:

这套能力究竟能不能形成长期的产品壁垒?

Ontology 正在成为标配,概念本身不再稀缺

几年前,把企业数据组织成产品、客户、订单和设备等业务对象,确实是一项很有辨识度的能力。

但今天, 主流数据平台、BI 工具和 AI 平台都在增加语义层、业务对象和企业上下文能力。

未来,几乎每个平台都会告诉客户:

我可以统一业务口径;

我可以定义对象和关系;

我可以让 智能体 理解企业数据。

这意味着,单纯拥有 Ontology 已经很难成为护城河。

就像今天没有厂商会把“支持数据库连接”作为核心竞争力一样,未来“支持业务语义”也会逐渐成为基础配置。

真正的差异, 不在于能不能画出几类业务对象,而在于这套业务认知能不能随着企业使用不断扩大。

当客户从一个质量场景扩展到供应链、生产、设备和售后时,平台是越来越容易使用,还是越来越依赖定制开发?

这才决定了产品的上限。

第一个天花板:把平台做成了项目工具

国内很多 数据智能平台 都有很强的项目交付能力。

顾问进入客户现场,帮助梳理业务、整理数据、定义对象,再完成一个可展示、可验收的应用。

在企业数据基础薄弱、业务口径混乱的阶段,这种服务很有价值。

但项目交付能力不等于平台能力。

第一个场景可以依靠最优秀的顾问、架构师和业务专家集中投入完成。

真正的考验,是第二个、第五个和第十个场景。

如果每增加一个业务域,都要重新调研、重新梳理、重新开发,那么客户买到的并不是一个可以不断复用的平台,而是一系列持续发生的项目。

从供应商角度看,项目越多,服务收入越高。

但从客户角度看,成本并没有因为平台投入而下降。

甚至可能出现一种情况:

平台使用得越深,企业对供应商的依赖越强。

这就是很多“Palantir 模式”软件最容易遇到的天花板。

它们可能是一门不错的专业服务生意,却很难成为真正可规模化的软件生意。

第二个天花板:客户的知识留在了谁手里

建设 Ontology,客户投入的不只是软件费用。

业务部门要解释真实流程,技术团队要梳理数据来源,不同部门还要共同确认什么是产品、什么是批次、什么是风险,以及这些对象之间到底是什么关系。

这些内容,本质上是企业对自身业务的理解。

所以企业必须问一个问题:

三年以后,这些知识是变成了企业自己的资产,还是只存在于供应商的平台和顾问经验里?

很多项目验收以后,应用可以继续运行,但客户并不真正理解背后的模型。

业务发生变化,仍然要找原来的顾问;

增加一个工厂,仍然要重新购买服务;

更换平台,过去形成的对象、关系和规则也很难继续复用。

这意味着 企业投入形成的知识,没有真正沉淀在企业内部。

当然,任何企业级平台都会形成一定依赖。

问题不是能不能做到完全没有依赖,而是客户能否清楚地保留最核心的业务认知,并逐步掌握维护和扩展能力。

平台的竞争力,不应该来自客户无法离开。

而应该来自客户即使拥有选择权,仍然愿意继续使用。

第三个天花板:只复制了 Palantir 的外形没有复制它的产品逻辑

国内很多公司学习 Palantir 时,最容易复制的是外在形态:

建设统一数据平台;

定义一层业务对象;

由顾问团队交付应用;

再围绕新场景继续扩展。

但 Palantir 真正强大的地方,并不是它使用了 Ontology 这个词。

而是 Ontology 在它的产品体系中并不是一个展示功能,而是连接数据、应用、权限和行动的核心机制。

如果国内平台只是给原来的数据中台增加一层业务名称,再由项目团队完成每一个场景,那么它复制的只是 Palantir 的表面。

这种模式在第一个场景中可能看不出问题。

但随着业务关系越来越复杂、场景越来越多,企业会逐渐发现:

平台上的对象越来越多,但真正可复用的能力并没有同步增加;

项目数量越来越多,但每个项目仍然需要大量人工;

数据看起来已经打通,但跨部门问题仍然要依靠人去解释和协调。

最终, Ontology 变成了一种新的界面和销售语言,而不是企业可以持续运营的基础能力。

主题:企业|产品|业务对象|客户|平台|真正