Palantir Study 32｜BA 如何交付本体项目并证明业务价值

本体项目上线汇报会上团队展示了 38 个 Object Type、126 条 Link、24 个 Function 和 17 个 Workshop Module。管理者听完只问了一句“供应中断现在处理得更好了吗”对象数量证明团队做了很多工作却无法证明用户作出了更好的决定。页面访问量也无法说明 Action 是否安全执行。BA 的最终责任仍是把资源交付带回业务结果谁的哪次决定发生了变化行动怎样进入现实系统组织又如何从结果中继续学习。本体项目不是“建一套本体”Palantir 的 Use case lifecycle 将 use case 定义为由专门团队在有限时间内为一组用户交付新能力的工作它不是“接入某个源系统”或“应用某种机器学习技术”而要直接面对价值主张——谁的工作会改善怎样衡量成功。Palantir Use case lifecyclePalantir 对 operational application 的定义也把具体决策过程和数据写回放在中心它与只读报表的区别是用户能够采取行动并捕获决定。PalantirWhat is an operational application?本体项目交付的不是语义图而是可运行、可采用、可度量的决策闭环。上一篇讨论 FDE 如何贴近真实用户从一个最小闭环获得证据。BA 要把这个闭环变成项目契约并决定何时继续试点、扩大范围、产品化或者停止。四个词先说清角色、系统和工具不能混层名词本文定义类型与位置不等于BA把 Outcome、Decision、Action、证据和跨角色约束变成可验收契约并维护接缝的人实施角色不是 Palantir 组件所有专业工作的 Owner业务结果 / Outcome目标用户工作或组织运营的可衡量变化带范围、基线、Owner、时间窗和约束Use case 价值层上线、对象数或单项 KPIOntology连接 Data、Logic、Action、Security表达并执行企业决定的运营系统Palantir 核心系统ER 图、主数据或一个应用Outcome Scorecard把结果、行动、采用、治理指标接到基线、Owner 和处置动作的 BA 资产本系列实施模板Palantir 官方固定产品它们在最小架构中的关系是BA 位于产品架构之外负责把业务责任与平台构件连起来Outcome Scorecard 位于项目治理层消费运行证据。它们都不是 Ontology 的下级组件。一条端到端实施路径下面不是瀑布阶段。团队会在业务、模型、数据和应用之间反复验证但每一步都要产生可评审的交付物。一、定义 Outcome 与基线恒川工业的 Outcome 可以表达为缩短SD-260808-01从确认中断到批准方案的时间降低HC-SO-260801受影响程度同时不增加越权、重复或无法对账的写回。BA 要先定义指标口径、范围、基线来源与观测窗口。没有历史基线时不编造目标百分比先设计怎样采集决策耗时、订单影响、人工覆盖和写回结果。交付物Outcome Statement、基线计划、约束与待验证假设。二、锁定 Decision、用户和决策时刻把“优化供应链”缩小为一个可观察决定Supply Planner 在排产冻结前比较调拨、催交、替代料和改序Manager 决定是否批准AP-2048的 520 EA 调拨。明确 Trigger、Decision owner、Deadline、Options、Criteria 与错误后果。不同决定应拆开建模。交付物决策场景卡、Stakeholder Map、当前决策旅程。三、定义 Action Contract从目标决定继续追问选择之后要改变什么状态“批准重新分配”需要 Target、Parameters、Submission Criteria、Permission、Edits、Side effects、Failure、Audit 与 Outcome。Action 一旦明确页面、Function、数据和写回才有共同的验收中心。交付物Action Contract、状态机、权限与异常场景。四、反推最小 Ontology slice根据 Action 所需上下文定义 Object Set再反推 Object、Property、Link、身份和生命周期。这里只建关闭当前闭环所需的切片。对象是否进入范围要由 Decision 和 Action 证明不靠“以后可能有用”。Palantir 最佳实践强调建模现实而不是复制系统谨慎选择 Property并以增量改进代替 big-bang。Palantir Ontology best practices交付物Ontology 全景画布、对象卡、Link 定义表、身份与生命周期决策表。五、建立数据与 Logic 证据链把每个关键 Property 追溯到 Dataset、Stream、Pipeline、Model 或用户 Action。明确来源字段、转换、更新时效、质量规则、权限和失败处理。再为每段 Logic 分配责任事实进 Property简单关系派生可评估 Derived Property确定性运营逻辑进 Function预测或优化进 Model批量转换留在 Pipeline。交付物对象—属性—数据源映射表、决策逻辑分配表、数据质量测试集。六、设计应用、Security 与 Writeback围绕真实决策旅程设计 Inbox、Object View、分析证据和 Action而不是堆页面。用户进入应用后应立即看到自己需要处理的 Object Set并在同一语境中理解影响、比较方案和执行操作。同时定义谁能看、算、提交、批准和执行每类状态由哪个 System of Record 负责并发、幂等、重试、补偿、对账与审计怎样实现。交付物Inbox 闭环画布、AI 行动边界画布、Writeback 决策矩阵、端到端权限矩阵。七、把最小闭环送入生产工程最小闭环通过业务验证后用 Global Branching 隔离和评审变更用 AIP Evals 检查 Agent 行为用 Observability 监控数据、Function、Action 与 Writeback再用 Foundry DevOps 区分可复用 Product、环境配置和本地连接。这一步承接 FDE 的 Pilot—Scale—Productize试点先证明一个用户范围内能安全运行扩展前证明语义、容量、权限和支持体系产品化前再证明版本、依赖、安装、升级和回滚。交付物Change Proposal、Agent Evaluation Set、闭环可观测地图、环境差异矩阵、发布与回滚计划。八、用真实决策做 UAT 与上线签核传统 UAT 常验证页面能否打开、按钮能否点击。本体项目还要验证决策闭环。至少覆盖正常方案、数据迟到、身份冲突、权限不足、模型失败、并发修改、重复提交、外部系统部分成功、人工覆盖、Agent 越权请求和补偿处理。验收证据不仅是截图还包括 Action Log、对象状态、外部业务单号、失败队列和 Outcome 数据。交付物决策 UAT 场景、运行手册、上线准备度与回退条件。九、采用、观测与增量扩展上线不是闭环完成。团队要观察用户是否在真实 Trigger 后进入应用Object Set 是否可信Action 是否被采用人工为何覆盖失败是否得到处理。新用例先复用已有 Object、Function 与 Action重复成为稳定模式后再抽象。Pilot、Scale、Productize 的每道门都由证据决定不以“已经投入很多”为继续理由。交付物Outcome Scorecard、采用与质量看板、变更记录、下一迭代 backlog。BA 不是所有内容的 Owner而是接缝的 Owner本体项目跨越业务、数据、应用、AI、安全和源系统。BA 独自定义一切会成为瓶颈只写需求又会让接缝无人负责。BA 最重要的职责是让每个边界有明确决定权和可交接证据。RACI 用A最终负责、R执行、C会签、I知会。它不消灭专业判断只把决定权和交接证据显式化。决定/交付Business OwnerBAOntology LeadData/Logic LeadApp/AI LeadSecurity/SoR OwnerOutcome 与业务政策ARCCICDecision / Action 契约ARRCCC对象身份与语义CRA/RCIC数据、Logic、模型证据CCCA/RCI应用、Agent、用户旅程CRCCA/RC权限、Writeback、审计CRCCCA/RUAT、上线、OutcomeARCCCCBA 的R是把业务语义、边界和签核证据变成契约不是替技术 Owner 实现。典型谈判包括Business Owner 定义价值取舍Ontology Lead 决定可演进结构Data Lead 为来源、时效和运行负责App/AI Lead 为体验、模型和工具边界负责Security/SoR Owner 决定谁能改变现实。没有源系统 Owner 签核的 Writeback不能因演示调用成功就视为生产完成。用四类指标证明价值单一业务 KPI 不足以解释本体为何成功或失败应同时观察四类指标。一、业务结果指标最终改变了什么这些是滞后指标例如高优先级订单延期影响、加急采购成本、库存浪费、处置周期和服务水平。指标要考虑外部因素。延期减少可能来自需求下降未必来自 Ontology可用同类事件对比和过程证据增强解释但不应过度声称因果。二、决策与行动指标闭环是否真的更好这些指标观察 Trigger 到响应、批准、Action、Writeback 和补偿的过程。它们能解释业务结果变化也能发现系统只是“看得见”却没有“做得成”。三、本体采用指标能力是否进入真实工作不要只看月活。应观察符合条件的中断有多少通过目标应用处理用户是否使用共享 Object Set 与 Action以及 Agent 建议被采纳、修改和拒绝的原因。采用指标必须与 Trigger 和任务分母相连。十个用户每天登录没有完成一次目标 Action不代表应用被采用。四、质量与治理指标价值能否持续包括身份异常、关键 Property 新鲜度、Link 完整率、失败 Pipeline、权限异常、长期 Pending 写回和核心定义漂移。质量指标要与业务风险相连。Material 描述缺失可能只影响显示替代认证缺失则应阻断批准两者不应使用同一严重度。指标之间要能读成一条故事Scorecard 应能解释Inbox 覆盖如何影响响应Function 与 Action 如何影响批准周期Writeback 如何影响最终订单结果。若结果没有改善团队可以沿链条定位事件遗漏、数据过期、用户未采用、方案覆盖、Action 失败还是外部条件变化。这比把所有功劳或问题归给“本体”更有行动价值。BA 工作台一项目交付清单下面是恒川工业的发布签核样例按两组拆分。价值、决策与模型交付域必备交付物签核人通过条件Outcome指标口径与基线计划业务 Owner有范围、基线、约束和观测方式Decision场景卡与用户旅程Decision ownerTrigger、Deadline、Options 清楚ActionAction Contract业务Ontology系统 Owner权限、编辑、失败、审计可测试Ontology对象卡、Link、身份表DomainOntology Lead支撑目标上下文无无主定义Data/Logic映射表与逻辑分配表DataModel Lead来源、时效、版本、降级明确应用、运行与价值签核交付域必备交付物签核人通过条件ApplicationInbox 闭环画布用户代表App Builder可完成端到端任务Security/Writeback权限与写回矩阵Security系统 Owner最小权限、对账、补偿完整EngineeringBranch、Eval、监控与回滚包PlatformUse Case Lead变更可评审异常可发现版本可回退UAT/Operations决策 UAT 与运行手册Use Case Lead正常、异常、越权和接管场景通过Adoption/ValueScorecard业务 OwnerBA分母、采集、Owner、复查周期明确BA 工作台二上线准备度上线准备度不是“功能做完”的同义词。它要求业务闭环在有人使用、数据迟到、权限受限和外部系统失败时仍可管理。准备域BA 必须拿到的证据未通过时的决定价值与责任Outcome、范围、Decision owner、支持 Owner 均签核不扩大用户范围数据与身份关键 Property 有时效阈值对象冲突进入处理队列降级为只读或人工核验Action 与安全权限、幂等、对账、补偿、人工接管经过演练禁止生产写回Agent 与 Logic关键规则、工具调用和拒绝路径有 Eval 证据Agent 只建议不执行发布与运行Branch 评审、监控、告警、值守、回滚责任明确保留旧版本并停止发布采用与价值培训、UAT、任务分母和 Scorecard 采集已经就绪继续受控 Pilot这张表的价值是把“还担心什么”变成可验证条件。每项必须有 Owner、证据链接、签核时间和失效后的动作不能只写红黄绿状态。BA 工作台三Outcome Scorecard下面不填写虚构收益数字只展示可执行口径。结果与行动指标口径基线/目标Owner频率高优先级订单影响中断导致延期或降级的高优订单数/量待历史回算后签核客户交付负责人周/月中断处置周期Confirmed 至方案 Approved 的中位时长待建立基线供应链经理周Action 完成率Executed / 已批准方案目标由业务签核计划负责人日/周写回异常率Failed 或 Partially Failed / 写回请求数按系统分层集成 Owner日采用与治理指标口径预警条件Owner处理动作闭环覆盖率通过目标应用完成的中断 / 符合范围的中断连续下降Use Case Lead访谈未使用原因人工覆盖率人工修改模型建议 / 建议总数按原因异常上升Model业务 Owner复核规则与模型关键数据新鲜度在决策 SLA 内更新的关键 Property 比例低于签核阈值Data Lead阻断自动 Action 或降级身份异常率未解析/冲突对象 / 新增对象超出容忍范围MDM/Data Owner进入解析队列核心定义漂移未经影响评估的核心变更数任一发生Ontology Lead回滚并补评审空白 Scorecard 至少保留指标、业务含义、分子分母、数据来源、基线、目标、Owner、频率、分层维度、预警条件和处理动作。完成标准不是每项都有漂亮数字而是每个指标都能被稳定采集、有人解释、触发明确行动并能与目标 Decision 和 Outcome 连起来。价值不是上线时证明一次而是在运营中持续证明Palantir 将 Ontology 描述为面向决定的运营层Data、Logic、Action 与 Security 被连接起来人和 Agent 的决定及其结果能够进入共同的 decision lineage。PalantirWhy create an Ontology?这意味着价值证明也不是项目结项 PPT。每次 Trigger、建议、人工覆盖、Action、写回与 Outcome 都产生新的运营证据帮助团队改进对象定义、Logic、应用和治理。回看整个系列BA 的交付物已经发生迁移PRD 升级为 Action Contract 与 Outcome流程图升级为对象状态、Trigger 与 AutomationER 图和字段字典升级为 Object、Link、Property 与数据证据链规则和 UAT 升级为 Function、Model、Criteria、Eval 与闭环验证。本体项目的成败最终不由模型有多大决定而由一条具体业务句子是否成立正确的人或 Agent在正确时刻基于可信上下文作出可解释的决定通过受控 Action 改变现实并让结果进入后续学习。如果这句话能够被运行、被观察、被改进Ontology 才真正成为企业的运营层。最后收束从看懂平台到经营决策系统这套系列走过四段路先从恒川工业的缺料处置体验闭环再用 Object、Property、Link、Action 和 Writeback 拆开 Ontology继而把数据、Logic、应用、AIP 与 Agent 接入生产最后用变更、可观测性、DevOps、FDE 和 Outcome 把能力变成组织的长期资产。BA 可以从一个现实决定开始写清 Outcome、Trigger、Options、Action、Evidence、Owner 和失败后的接管方式再与用户跑通一个可核验的小闭环。对象、数据、应用和 AI 的范围都应由这个闭环反推。这也是 32 篇共同回答的问题Palantir Ontology 的价值不是让企业拥有更多技术名词而是让业务决定成为可建模、可执行、可治理、可度量和可持续改进的运营能力。【声明】本文基于 Palantir 公开资料及作者的业务分析与实施研究整理与 Palantir Technologies 无官方关联不构成官方产品说明。端到端实施路径、角色边界、四类指标、交付清单、上线准备度与 Outcome Scorecard 是本系列面向 BA 的实施归纳。