初创公司借鉴
Palantir Ontology
的落地方法
不要复制 Palantir 的平台全貌，只复制它最有用的产品结构——用一层共享业务对象模型，把分散数据映射为对象、属性、关系；把高价值业务动作做成可写回、可审计、可控权限的 Action；再用轻量应用或 Agent 消费这层模型。
执行摘要
对 2–50 人初创团队，不要复制 Palantir 平台全貌；只复制它最有用的产品结构：用一层共享业务对象模型，把分散数据映射成对象、属性、关系，再把高价值业务动作做成可写回、可审计、可控权限的 Action，最后用轻量应用或 Agent 消费这层模型。
Palantir 官方把 Ontology 定义为组织的 operational layer；其 object type 类比 dataset schema，object 类比 row，action type 则是一组变更与副作用的定义。Microsoft Fabric 也开始把 ontology 定义为 teams、agents、workflows 共用的受治理业务模型——这已是产品设计范式，不再只是 Palantir 专属叙事。
真正价值来自现场抽象 + 产品化，而不是术语本身。别把 ontology 当神秘技术卖，否则很快滑向"高价集成 + 重服务 + 强锁定"。创业公司应反过来：只卖"更快决策 + 更少返工 + 可追责执行"。
适合进入的行业与切入点
行业筛选方法
| 步骤 | 做法 | 优先级 |
|---|---|---|
| 先找痛点 | 优先找"异常成本高、决策慢、返工多"的流程，而非纯报表需求 | 高 |
| 再看数据 | 是否至少有 3 个来源系统、2 类异构数据、1 个主责系统可写回 | 高 |
| 再看治理 | 是否有权限分层、审批、审计或合规压力 | 高 |
| 再看商业 | 是否有明确预算 owner、单客户 ACV 足够覆盖实施 | 高 |
| 最后看扩展 | 同一模型/Action 能否复制到下 5–10 个客户 | 中 |
行业评分矩阵与优先级
| 行业 | 复杂度 | 数据碎片 | 权限/合规 | 可写回价值 | ACV 潜力 | 销售周期 | 综合 | 结论 |
|---|---|---|---|---|---|---|---|---|
| 制造 | 5 | 5 | 3 | 5 | 4 | 3 | 高 | 最优先，先做质量/排产/备件 |
| 物流 | 4 | 5 | 3 | 5 | 4 | 3 | 高 | 很适合，先做异常处置/ETA/改派 |
| 医疗 | 5 | 5 | 5 | 4 | 4 | 2 | 中高 | 适合，但先做运营协同，少碰诊疗核心 |
制造与物流之所以优先，是因为 Industry 4.0 与 supply chain 平台化的价值大，但大量企业仍陷在 pilot purgatory，且 visibility、interoperability、stakeholder buy-in 都是硬问题——这正适合"对象层 + Action + 审计"的 read-write 产品。医疗同样高度碎片化且治理要求高，但互操作、政策、标准、资金、法律与培训要求更重，早期团队应优先切运营环节。
三个行业的具体切口
| 行业 | 推荐切口 | 核心对象 | 高价值 Action | 不建议首战 |
|---|---|---|---|---|
| 制造 | 质量偏差处置 | 工单、设备、批次、缺陷、责任人 | 关单、停机、复检、派工 | 全厂数字孪生 |
| 物流 | 异常运单协同 | 运单、车队、司机、节点、客户投诉 | 改派、改 ETA、索赔、升级 | 全链路控制塔 |
| 医疗 | 床位/转诊协调 | 病人、床位、科室、订单、授权 | 转诊、排床、升级审批 | 直接临床决策支持 |
需求发现与隐性需求挖掘
现场调研与 FDE 式流程
| 步骤 | 做法 | 优先级 |
|---|---|---|
| 跟班观察 | 跟 1 个一线角色完整跑 0.5–1 天，不先讲产品 | 高 |
| 画决策链 | 记录"对象 → 决策 → Action → 写回系统 → 审批人" | 高 |
| 抓异常样本 | 只看例外：延误、缺料、错单、违规、返工 | 高 |
| 快速原型 | 5 天做出单流程原型，先实现 1 个写回 Action | 高 |
| 复盘量化 | 用"时间、损失、错误率、审批时长"回算 ROI | 中 |
Palantir 在 S-1 中强调，FDE 通过与用户并肩工作，帮助客户识别新 use case、现代化数据架构，并把现场经验反哺平台。对初创团队，这意味着：售前不是讲故事，是做现场抽样 + 原型验证。
访谈脚本模板
| 题目 | 目的 | 证据 |
|---|---|---|
| "你今天最怕哪类异常？" | 找高损失例外 | 最近 3 个案例 |
| "发生后，你先看哪 3 个系统/群/表？" | 找数据碎片点 | 系统截图 / Excel |
| "最终谁拍板？谁背锅？" | 找决策 owner | 角色名单 |
| "结果要写回哪里？" | 锁定 Action | ERP / TMS / EHR / API |
| "什么情况必须留痕/审批？" | 锁定审计需求 | SOP / 政策 |
| "若 30 秒给你可信建议，你会接受到哪一步？" | 找 Agent 边界 | 建议 / 确认 / 自动执行 |
顾问：上一单延误，真正卡在哪？
运营主管：不是看不到，是要去 TMS、司机群、客户邮件里拼。
顾问：最后谁决定改派？
运营主管：值班经理，但他要确认 SLA 和赔付风险。
顾问：决定后写回哪里？
运营主管：TMS 改 ETA，CRM 发通知，财务留赔付备注。
顾问：这就是首个 Action。
发现隐性需求的方法
隐性需求通常藏在四类地方：例外流程、权限断点、审计盲点、AI 触发点。若同一角色要跨 3 个以上系统解释一次情况、拉一次审批、再手工写回，通常就已具备 Agent/Action 化价值。Palantir 与 Microsoft 都把 ontology 放在 teams、agents、workflows 共享的业务上下文层，本质就是为这种"跨系统、跨流程、跨角色"决策提供统一语义与执行边界。
组织决策链、定价与获客
关键角色沟通矩阵
| 角色 | 关心什么 | 阻力 | 说服点 | ROI 口径 |
|---|---|---|---|---|
| CEO / CXO | 速度、现金、风险 | 怕变成大项目 | 先做单流程，8 周见结果 | 人力节省、损失降低 |
| BU Head | KPI、跨部门扯皮 | 怕 IT 拖慢 | 先围绕 1 个 KPI 建 | 周转、OTIF、停机率 |
| IT / Data | 接入、主数据、维护 | 怕新孤岛 | API / 导出 / 可迁出 | 少定制、少工单 |
| 合规 / 安全 | 权限、留痕、审计 | 怕越权 | 最小权限 + 全链路 log | 审计准备时间 |
| 采购 | 价格、风险、可比性 | 怕不透明服务费 | 固定范围 POC + SLA | TCO |
| End users | 操作负担 | 怕多一步 | 从"看板"变"少点几次" | 单单处理时长 |
定价模式与示例
| 模式 | 适用场景 | 优点 | 风险 | 示例公式 |
|---|---|---|---|---|
| SaaS 订阅 | 场景稳定、多人协作 | 预算清晰 | 与真实价值脱钩 | 年费 = 平台费 |
| 按用户 | 管理层/知识工较多 | 简单 | 一线高频操作不匹配 | 年费 = seat × price |
| 按对象 / Action | 异常驱动、事件驱动 | 与价值更对齐 | 计量复杂 | 平台费 + 包含量 + overage |
| 项目 + SLA | 数据乱、需重实施 | 便于签首单 | 服务占比高 | 启动费 + 年维护 |
| 成功分成 | 节省可归因 | 易破局 | 数据归因难 | 基础费 + 节省分成 |
| 平台费 + FDE 服务 | 早期最稳 | 兼顾落地与扩张 | 容易被当外包 | 年平台费 + 实施包 |
SaaS 世界对 usage-based pricing 的采用持续上升，但多数公司采用 hybrid，不是纯用量。对 ontology-style 产品，建议默认 "平台费 + 包含 Action + 超量计费 + 首次实施包"。
定价敏感度表
| 情景 | 平台费 | 包含 Action/月 | 超量单价 | 实施费 | 年收入 |
|---|---|---|---|---|---|
| 保守 | 60k | 5,000 | 0.20 | 25k | 85k + overage |
| 基准 | 90k | 10,000 | 0.15 | 35k | 125k + overage |
| 激进 | 150k | 20,000 | 0.10 | 50k | 200k + overage |
高价值需求渠道与开拓脚本
| 渠道 | 优先级 | 为什么有效 | 开拓脚本 |
|---|---|---|---|
| 行业顾问 / 前高管 | 高 | 知道真实异常流程 | "我们只看一个高损失例外流程，想请你帮我们找最痛 3 个场景。" |
| SI / 实施商 | 高 | 手里有 ERP/SCM/CRM 项目 | "你们交付后最常被客户抱怨的手工协同环节是什么？" |
| 现有数据平台生态 | 中高 | 客户已有数据但无 Action | "你们有看板；我们补可写回与审计闭环。" |
| 合规 / 审计事件 | 高 | 预算更明确 | "最近 audit 暴露哪条责任链留痕最差？" |
| 公开招标 | 中 | 线索大 | "先以小 POC 资格项进入，不先铺大平台。" |
市场材料、Demo 与 POC 设计
一页价值主张模板
| 模块 | 填写方式 |
|---|---|
| 客户角色 | "面向 ___ 负责人 / 一线 ___" |
| 现状问题 | "今天要在 ___、___、___ 之间手工拼信息，平均 ___ 分钟/单" |
| 我们做什么 | "把 ___、___、___ 统一成对象层，并把 ___ 变成可审计 Action" |
| 直接收益 | "处理时长 -__%，异常升级时间 -__%，审计准备时间 -__%" |
| 为什么现在 | "新增 ___ 监管 / SLA / 扩厂 / 多点运营" |
| 为什么不是 BI | "不是只看见，而是能改派 / 审批 / 写回 / 留痕" |
| 风险控制 | "API 写回、RBAC、审批门槛、全链路日志、可导出模型" |
Demo 流程
| 顺序 | Demo 画面 |
|---|---|
| 开场 | 一个异常对象主页：状态、责任人、风险 |
| 追因 | 自动拉出关联对象与时间线 |
| 决策 | 给出建议方案与影响范围 |
| 执行 | 点击 Action，触发审批 / 写回 / 通知 |
| 闭环 | 展示审计记录与 KPI 改善 |
POC Checklist 模板
| 项目 | 目标值 |
|---|---|
| POC 周期 | 6–8 周 |
| 流程范围 | 只做 1 条高价值流程 |
| 数据源 | 2–3 个，必须有 1 个可写回 |
| 用户 | 1 个 owner + 3–8 个一线用户 |
| 成功指标 | 时长、错误率、审批 SLA、采纳率 |
| 交付物 | 对象模型、Action、权限规则、审计日志、ROI 复盘 |
| go/no-go 条件 | 指标达成 + owner 愿意扩展预算 |
初期产品与交付准备
Ontology-lite MVP 示例 · 物流异常处置
- Objects
- Shipment、Route、Vehicle、Customer、Exception
- Properties
- ETA、delay_reason、priority、claim_risk、owner
- Links
- Shipment → Vehicle；Shipment → Customer；Shipment → Exception
- Actions
- Reassign Route、Update ETA、Escalate Claim、Close Exception
Palantir 官方文档把 object type/object 直接类比 dataset/row——这意味着创业公司不必先上复杂图数据库，可先用关系型存储 + 明确 ID、关系表、Action 服务层来实现 ontology-lite。Palantir 自己也强调对象层是映射真实业务实体到实际数据与应用，而不是停在抽象模型。
数据接入、权限与审计的最小实现
| 模块 | 最小要求 |
|---|---|
| 数据接入 | ERP / TMS / MES / CRM 各 1；CSV / 邮件 / 工单至少 1 |
| 身份权限 | SSO + RBAC + 行级过滤 |
| Action 审批 | 至少支持两级：建议、确认 |
| 审计 | 记录 who / when / before / after / reason / request-id |
| 变更治理 | 每周对象模型评审 + 变更日志 |
NIST 将 audit log 定义为系统活动的时间序记录，并要求控制访问、记录特权使用；Palantir 也把 object、link、action 的细粒度权限作为 ontology 的核心能力。创业团队最少也要把最小权限、审批、审计时间线做出来，否则只是"有语义的 CRUD"。
团队、节奏与互操作策略
关键角色与招聘顺序
| 角色 | 先后 |
|---|---|
| Founder / PM-FDE 混合型 | 必须最先有 |
| Full-stack + Data Engineer | 必须最先有 |
| 售前 / 解决方案顾问 | 第三人起补 |
| 安全 / 平台工程 | 第一个大客户后补 |
| 行业 BD | 找到 repeatable wedge 后补 |
推荐技术栈
Postgres / warehouse + dbt + Airbyte / Fivetran 类接入 + Temporal / 工作流引擎 + React 前端 + OPA / Casbin 权限 + OpenAPI / Webhook 写回。
可迁出策略
对象模型用 YAML/JSON 导出；主键不依赖供应商 ID；Action 通过标准 API；日志落标准表；客户可导出对象、关系、事件与规则。医疗等高治理行业还应优先采用开放标准与开放式集成，而不是封闭模型。
风险与反对意见
| 反对点 | 客观回应 | 缓解策略 |
|---|---|---|
| "这不就是 semantic layer?" | 一半对。差别在可写回 Action、权限、审计、应用/Agent grounding | 首单必须证明 1 个 write-back 闭环 |
| "会不会变成重服务外包?" | 会，若每单都重做模型 | 只卖 1 个 wedge；连接器、Action、模板产品化 |
| "数据质量太烂" | 常态，不是阻断项 | 先做异常流程，不先做全域主数据 |
| "锁定风险高" | 真实存在 | 导出模型、开放 API、标准日志 |
| "AI 不可信" | 先把 AI 放在建议层，不直接自动执行 | 建议 → 人审 → Action；高风险加审批 |
| "组织没人维护 ontology" | 这是最常见失败点 | 每个对象模型必须有业务 owner |
| "术语会被当 buzzword" | 批评成立 | 对外不用 ontology，改说"对象层 + Action 闭环" |
Palantir 自己的最佳实践也在提醒别走错：避免 system silos、kitchen sink、god object、action sprawl；设计应迭代推进。批评文献中"不要卖哲学词、不要把重服务伪装成神秘技术"这点值得当约束条件。
开放问题与限制
当前最稳的共识仍是：先卖一个可审计的高价值 Action，不先卖整套 ontology 宇宙。
参考来源
- palantir.com/docs/foundry/ontology/overview/
- SEC · Palantir S-1 (2020)
- McKinsey · Capturing the True Value of Industry 4.0
- palantir.com/docs/foundry/ontology/why-ontology/
- OpenView · State of Usage-Based Pricing
- McKinsey · Tech-Enabled Transformations
- palantir.com/docs/foundry/object-link-types/object-types-overview/
- palantir.com/docs/foundry/object-permissioning/overview/
- IADB · Interoperability in Digital Health
- palantir.com/docs/foundry/ontology/ontology-best-practices-and-anti-patterns/