本體項(xiàng)目上線匯報(bào)會(huì)上團(tuán)隊(duì)展示了 38 個(gè) Object Type、126 條 Link、24 個(gè) Function 和 17 個(gè) Workshop Module。管理者聽完只問(wèn)了一句“供應(yīng)中斷現(xiàn)在處理得更好了嗎”對(duì)象數(shù)量證明團(tuán)隊(duì)做了很多工作卻無(wú)法證明用戶作出了更好的決定。頁(yè)面訪問(wèn)量也無(wú)法說(shuō)明 Action 是否安全執(zhí)行。BA 的最終責(zé)任仍是把資源交付帶回業(yè)務(wù)結(jié)果誰(shuí)的哪次決定發(fā)生了變化行動(dòng)怎樣進(jìn)入現(xiàn)實(shí)系統(tǒng)組織又如何從結(jié)果中繼續(xù)學(xué)習(xí)。本體項(xiàng)目不是“建一套本體”Palantir 的 Use case lifecycle 將 use case 定義為由專門團(tuán)隊(duì)在有限時(shí)間內(nèi)為一組用戶交付新能力的工作它不是“接入某個(gè)源系統(tǒng)”或“應(yīng)用某種機(jī)器學(xué)習(xí)技術(shù)”而要直接面對(duì)價(jià)值主張——誰(shuí)的工作會(huì)改善怎樣衡量成功。Palantir Use case lifecyclePalantir 對(duì) operational application 的定義也把具體決策過(guò)程和數(shù)據(jù)寫回放在中心它與只讀報(bào)表的區(qū)別是用戶能夠采取行動(dòng)并捕獲決定。PalantirWhat is an operational application?本體項(xiàng)目交付的不是語(yǔ)義圖而是可運(yùn)行、可采用、可度量的決策閉環(huán)。上一篇討論 FDE 如何貼近真實(shí)用戶從一個(gè)最小閉環(huán)獲得證據(jù)。BA 要把這個(gè)閉環(huán)變成項(xiàng)目契約并決定何時(shí)繼續(xù)試點(diǎn)、擴(kuò)大范圍、產(chǎn)品化或者停止。四個(gè)詞先說(shuō)清角色、系統(tǒng)和工具不能混層名詞本文定義類型與位置不等于BA把 Outcome、Decision、Action、證據(jù)和跨角色約束變成可驗(yàn)收契約并維護(hù)接縫的人實(shí)施角色不是 Palantir 組件所有專業(yè)工作的 Owner業(yè)務(wù)結(jié)果 / Outcome目標(biāo)用戶工作或組織運(yùn)營(yíng)的可衡量變化帶范圍、基線、Owner、時(shí)間窗和約束Use case 價(jià)值層上線、對(duì)象數(shù)或單項(xiàng) KPIOntology連接 Data、Logic、Action、Security表達(dá)并執(zhí)行企業(yè)決定的運(yùn)營(yíng)系統(tǒng)Palantir 核心系統(tǒng)ER 圖、主數(shù)據(jù)或一個(gè)應(yīng)用Outcome Scorecard把結(jié)果、行動(dòng)、采用、治理指標(biāo)接到基線、Owner 和處置動(dòng)作的 BA 資產(chǎn)本系列實(shí)施模板Palantir 官方固定產(chǎn)品它們?cè)谧钚〖軜?gòu)中的關(guān)系是BA 位于產(chǎn)品架構(gòu)之外負(fù)責(zé)把業(yè)務(wù)責(zé)任與平臺(tái)構(gòu)件連起來(lái)Outcome Scorecard 位于項(xiàng)目治理層消費(fèi)運(yùn)行證據(jù)。它們都不是 Ontology 的下級(jí)組件。一條端到端實(shí)施路徑下面不是瀑布階段。團(tuán)隊(duì)會(huì)在業(yè)務(wù)、模型、數(shù)據(jù)和應(yīng)用之間反復(fù)驗(yàn)證但每一步都要產(chǎn)生可評(píng)審的交付物。一、定義 Outcome 與基線恒川工業(yè)的 Outcome 可以表達(dá)為縮短SD-260808-01從確認(rèn)中斷到批準(zhǔn)方案的時(shí)間降低HC-SO-260801受影響程度同時(shí)不增加越權(quán)、重復(fù)或無(wú)法對(duì)賬的寫回。BA 要先定義指標(biāo)口徑、范圍、基線來(lái)源與觀測(cè)窗口。沒有歷史基線時(shí)不編造目標(biāo)百分比先設(shè)計(jì)怎樣采集決策耗時(shí)、訂單影響、人工覆蓋和寫回結(jié)果。交付物Outcome Statement、基線計(jì)劃、約束與待驗(yàn)證假設(shè)。二、鎖定 Decision、用戶和決策時(shí)刻把“優(yōu)化供應(yīng)鏈”縮小為一個(gè)可觀察決定Supply Planner 在排產(chǎn)凍結(jié)前比較調(diào)撥、催交、替代料和改序Manager 決定是否批準(zhǔn)AP-2048的 520 EA 調(diào)撥。明確 Trigger、Decision owner、Deadline、Options、Criteria 與錯(cuò)誤后果。不同決定應(yīng)拆開建模。交付物決策場(chǎng)景卡、Stakeholder Map、當(dāng)前決策旅程。三、定義 Action Contract從目標(biāo)決定繼續(xù)追問(wèn)選擇之后要改變什么狀態(tài)“批準(zhǔn)重新分配”需要 Target、Parameters、Submission Criteria、Permission、Edits、Side effects、Failure、Audit 與 Outcome。Action 一旦明確頁(yè)面、Function、數(shù)據(jù)和寫回才有共同的驗(yàn)收中心。交付物Action Contract、狀態(tài)機(jī)、權(quán)限與異常場(chǎng)景。四、反推最小 Ontology slice根據(jù) Action 所需上下文定義 Object Set再反推 Object、Property、Link、身份和生命周期。這里只建關(guān)閉當(dāng)前閉環(huán)所需的切片。對(duì)象是否進(jìn)入范圍要由 Decision 和 Action 證明不靠“以后可能有用”。Palantir 最佳實(shí)踐強(qiáng)調(diào)建?，F(xiàn)實(shí)而不是復(fù)制系統(tǒng)謹(jǐn)慎選擇 Property并以增量改進(jìn)代替 big-bang。Palantir Ontology best practices交付物Ontology 全景畫布、對(duì)象卡、Link 定義表、身份與生命周期決策表。五、建立數(shù)據(jù)與 Logic 證據(jù)鏈把每個(gè)關(guān)鍵 Property 追溯到 Dataset、Stream、Pipeline、Model 或用戶 Action。明確來(lái)源字段、轉(zhuǎn)換、更新時(shí)效、質(zhì)量規(guī)則、權(quán)限和失敗處理。再為每段 Logic 分配責(zé)任事實(shí)進(jìn) Property簡(jiǎn)單關(guān)系派生可評(píng)估 Derived Property確定性運(yùn)營(yíng)邏輯進(jìn) Function預(yù)測(cè)或優(yōu)化進(jìn) Model批量轉(zhuǎn)換留在 Pipeline。交付物對(duì)象—屬性—數(shù)據(jù)源映射表、決策邏輯分配表、數(shù)據(jù)質(zhì)量測(cè)試集。六、設(shè)計(jì)應(yīng)用、Security 與 Writeback圍繞真實(shí)決策旅程設(shè)計(jì) Inbox、Object View、分析證據(jù)和 Action而不是堆頁(yè)面。用戶進(jìn)入應(yīng)用后應(yīng)立即看到自己需要處理的 Object Set并在同一語(yǔ)境中理解影響、比較方案和執(zhí)行操作。同時(shí)定義誰(shuí)能看、算、提交、批準(zhǔn)和執(zhí)行每類狀態(tài)由哪個(gè) System of Record 負(fù)責(zé)并發(fā)、冪等、重試、補(bǔ)償、對(duì)賬與審計(jì)怎樣實(shí)現(xiàn)。交付物Inbox 閉環(huán)畫布、AI 行動(dòng)邊界畫布、Writeback 決策矩陣、端到端權(quán)限矩陣。七、把最小閉環(huán)送入生產(chǎn)工程最小閉環(huán)通過(guò)業(yè)務(wù)驗(yàn)證后用 Global Branching 隔離和評(píng)審變更用 AIP Evals 檢查 Agent 行為用 Observability 監(jiān)控?cái)?shù)據(jù)、Function、Action 與 Writeback再用 Foundry DevOps 區(qū)分可復(fù)用 Product、環(huán)境配置和本地連接。這一步承接 FDE 的 Pilot—Scale—Productize試點(diǎn)先證明一個(gè)用戶范圍內(nèi)能安全運(yùn)行擴(kuò)展前證明語(yǔ)義、容量、權(quán)限和支持體系產(chǎn)品化前再證明版本、依賴、安裝、升級(jí)和回滾。交付物Change Proposal、Agent Evaluation Set、閉環(huán)可觀測(cè)地圖、環(huán)境差異矩陣、發(fā)布與回滾計(jì)劃。八、用真實(shí)決策做 UAT 與上線簽核傳統(tǒng) UAT 常驗(yàn)證頁(yè)面能否打開、按鈕能否點(diǎn)擊。本體項(xiàng)目還要驗(yàn)證決策閉環(huán)。至少覆蓋正常方案、數(shù)據(jù)遲到、身份沖突、權(quán)限不足、模型失敗、并發(fā)修改、重復(fù)提交、外部系統(tǒng)部分成功、人工覆蓋、Agent 越權(quán)請(qǐng)求和補(bǔ)償處理。驗(yàn)收證據(jù)不僅是截圖還包括 Action Log、對(duì)象狀態(tài)、外部業(yè)務(wù)單號(hào)、失敗隊(duì)列和 Outcome 數(shù)據(jù)。交付物決策 UAT 場(chǎng)景、運(yùn)行手冊(cè)、上線準(zhǔn)備度與回退條件。九、采用、觀測(cè)與增量擴(kuò)展上線不是閉環(huán)完成。團(tuán)隊(duì)要觀察用戶是否在真實(shí) Trigger 后進(jìn)入應(yīng)用Object Set 是否可信Action 是否被采用人工為何覆蓋失敗是否得到處理。新用例先復(fù)用已有 Object、Function 與 Action重復(fù)成為穩(wěn)定模式后再抽象。Pilot、Scale、Productize 的每道門都由證據(jù)決定不以“已經(jīng)投入很多”為繼續(xù)理由。交付物Outcome Scorecard、采用與質(zhì)量看板、變更記錄、下一迭代 backlog。BA 不是所有內(nèi)容的 Owner而是接縫的 Owner本體項(xiàng)目跨越業(yè)務(wù)、數(shù)據(jù)、應(yīng)用、AI、安全和源系統(tǒng)。BA 獨(dú)自定義一切會(huì)成為瓶頸只寫需求又會(huì)讓接縫無(wú)人負(fù)責(zé)。BA 最重要的職責(zé)是讓每個(gè)邊界有明確決定權(quán)和可交接證據(jù)。RACI 用A最終負(fù)責(zé)、R執(zhí)行、C會(huì)簽、I知會(huì)。它不消滅專業(yè)判斷只把決定權(quán)和交接證據(jù)顯式化。決定/交付Business OwnerBAOntology LeadData/Logic LeadApp/AI LeadSecurity/SoR OwnerOutcome 與業(yè)務(wù)政策ARCCICDecision / Action 契約ARRCCC對(duì)象身份與語(yǔ)義CRA/RCIC數(shù)據(jù)、Logic、模型證據(jù)CCCA/RCI應(yīng)用、Agent、用戶旅程CRCCA/RC權(quán)限、Writeback、審計(jì)CRCCCA/RUAT、上線、OutcomeARCCCCBA 的R是把業(yè)務(wù)語(yǔ)義、邊界和簽核證據(jù)變成契約不是替技術(shù) Owner 實(shí)現(xiàn)。典型談判包括Business Owner 定義價(jià)值取舍Ontology Lead 決定可演進(jìn)結(jié)構(gòu)Data Lead 為來(lái)源、時(shí)效和運(yùn)行負(fù)責(zé)App/AI Lead 為體驗(yàn)、模型和工具邊界負(fù)責(zé)Security/SoR Owner 決定誰(shuí)能改變現(xiàn)實(shí)。沒有源系統(tǒng) Owner 簽核的 Writeback不能因演示調(diào)用成功就視為生產(chǎn)完成。用四類指標(biāo)證明價(jià)值單一業(yè)務(wù) KPI 不足以解釋本體為何成功或失敗應(yīng)同時(shí)觀察四類指標(biāo)。一、業(yè)務(wù)結(jié)果指標(biāo)最終改變了什么這些是滯后指標(biāo)例如高優(yōu)先級(jí)訂單延期影響、加急采購(gòu)成本、庫(kù)存浪費(fèi)、處置周期和服務(wù)水平。指標(biāo)要考慮外部因素。延期減少可能來(lái)自需求下降未必來(lái)自 Ontology可用同類事件對(duì)比和過(guò)程證據(jù)增強(qiáng)解釋但不應(yīng)過(guò)度聲稱因果。二、決策與行動(dòng)指標(biāo)閉環(huán)是否真的更好這些指標(biāo)觀察 Trigger 到響應(yīng)、批準(zhǔn)、Action、Writeback 和補(bǔ)償?shù)倪^(guò)程。它們能解釋業(yè)務(wù)結(jié)果變化也能發(fā)現(xiàn)系統(tǒng)只是“看得見”卻沒有“做得成”。三、本體采用指標(biāo)能力是否進(jìn)入真實(shí)工作不要只看月活。應(yīng)觀察符合條件的中斷有多少通過(guò)目標(biāo)應(yīng)用處理用戶是否使用共享 Object Set 與 Action以及 Agent 建議被采納、修改和拒絕的原因。采用指標(biāo)必須與 Trigger 和任務(wù)分母相連。十個(gè)用戶每天登錄沒有完成一次目標(biāo) Action不代表應(yīng)用被采用。四、質(zhì)量與治理指標(biāo)價(jià)值能否持續(xù)包括身份異常、關(guān)鍵 Property 新鮮度、Link 完整率、失敗 Pipeline、權(quán)限異常、長(zhǎng)期 Pending 寫回和核心定義漂移。質(zhì)量指標(biāo)要與業(yè)務(wù)風(fēng)險(xiǎn)相連。Material 描述缺失可能只影響顯示替代認(rèn)證缺失則應(yīng)阻斷批準(zhǔn)兩者不應(yīng)使用同一嚴(yán)重度。指標(biāo)之間要能讀成一條故事Scorecard 應(yīng)能解釋Inbox 覆蓋如何影響響應(yīng)Function 與 Action 如何影響批準(zhǔn)周期Writeback 如何影響最終訂單結(jié)果。若結(jié)果沒有改善團(tuán)隊(duì)可以沿鏈條定位事件遺漏、數(shù)據(jù)過(guò)期、用戶未采用、方案覆蓋、Action 失敗還是外部條件變化。這比把所有功勞或問(wèn)題歸給“本體”更有行動(dòng)價(jià)值。BA 工作臺(tái)一項(xiàng)目交付清單下面是恒川工業(yè)的發(fā)布簽核樣例按兩組拆分。價(jià)值、決策與模型交付域必備交付物簽核人通過(guò)條件Outcome指標(biāo)口徑與基線計(jì)劃業(yè)務(wù) Owner有范圍、基線、約束和觀測(cè)方式Decision場(chǎng)景卡與用戶旅程Decision ownerTrigger、Deadline、Options 清楚ActionAction Contract業(yè)務(wù)Ontology系統(tǒng) Owner權(quán)限、編輯、失敗、審計(jì)可測(cè)試Ontology對(duì)象卡、Link、身份表DomainOntology Lead支撐目標(biāo)上下文無(wú)無(wú)主定義Data/Logic映射表與邏輯分配表DataModel Lead來(lái)源、時(shí)效、版本、降級(jí)明確應(yīng)用、運(yùn)行與價(jià)值簽核交付域必備交付物簽核人通過(guò)條件ApplicationInbox 閉環(huán)畫布用戶代表App Builder可完成端到端任務(wù)Security/Writeback權(quán)限與寫回矩陣Security系統(tǒng) Owner最小權(quán)限、對(duì)賬、補(bǔ)償完整EngineeringBranch、Eval、監(jiān)控與回滾包PlatformUse Case Lead變更可評(píng)審異?？砂l(fā)現(xiàn)版本可回退UAT/Operations決策 UAT 與運(yùn)行手冊(cè)Use Case Lead正常、異常、越權(quán)和接管場(chǎng)景通過(guò)Adoption/ValueScorecard業(yè)務(wù) OwnerBA分母、采集、Owner、復(fù)查周期明確BA 工作臺(tái)二上線準(zhǔn)備度上線準(zhǔn)備度不是“功能做完”的同義詞。它要求業(yè)務(wù)閉環(huán)在有人使用、數(shù)據(jù)遲到、權(quán)限受限和外部系統(tǒng)失敗時(shí)仍可管理。準(zhǔn)備域BA 必須拿到的證據(jù)未通過(guò)時(shí)的決定價(jià)值與責(zé)任Outcome、范圍、Decision owner、支持 Owner 均簽核不擴(kuò)大用戶范圍數(shù)據(jù)與身份關(guān)鍵 Property 有時(shí)效閾值對(duì)象沖突進(jìn)入處理隊(duì)列降級(jí)為只讀或人工核驗(yàn)Action 與安全權(quán)限、冪等、對(duì)賬、補(bǔ)償、人工接管經(jīng)過(guò)演練禁止生產(chǎn)寫回Agent 與 Logic關(guān)鍵規(guī)則、工具調(diào)用和拒絕路徑有 Eval 證據(jù)Agent 只建議不執(zhí)行發(fā)布與運(yùn)行Branch 評(píng)審、監(jiān)控、告警、值守、回滾責(zé)任明確保留舊版本并停止發(fā)布采用與價(jià)值培訓(xùn)、UAT、任務(wù)分母和 Scorecard 采集已經(jīng)就緒繼續(xù)受控 Pilot這張表的價(jià)值是把“還擔(dān)心什么”變成可驗(yàn)證條件。每項(xiàng)必須有 Owner、證據(jù)鏈接、簽核時(shí)間和失效后的動(dòng)作不能只寫紅黃綠狀態(tài)。BA 工作臺(tái)三Outcome Scorecard下面不填寫虛構(gòu)收益數(shù)字只展示可執(zhí)行口徑。結(jié)果與行動(dòng)指標(biāo)口徑基線/目標(biāo)Owner頻率高優(yōu)先級(jí)訂單影響中斷導(dǎo)致延期或降級(jí)的高優(yōu)訂單數(shù)/量待歷史回算后簽核客戶交付負(fù)責(zé)人周/月中斷處置周期Confirmed 至方案 Approved 的中位時(shí)長(zhǎng)待建立基線供應(yīng)鏈經(jīng)理周Action 完成率Executed / 已批準(zhǔn)方案目標(biāo)由業(yè)務(wù)簽核計(jì)劃負(fù)責(zé)人日/周寫回異常率Failed 或 Partially Failed / 寫回請(qǐng)求數(shù)按系統(tǒng)分層集成 Owner日采用與治理指標(biāo)口徑預(yù)警條件Owner處理動(dòng)作閉環(huán)覆蓋率通過(guò)目標(biāo)應(yīng)用完成的中斷 / 符合范圍的中斷連續(xù)下降Use Case Lead訪談未使用原因人工覆蓋率人工修改模型建議 / 建議總數(shù)按原因異常上升Model業(yè)務(wù) Owner復(fù)核規(guī)則與模型關(guān)鍵數(shù)據(jù)新鮮度在決策 SLA 內(nèi)更新的關(guān)鍵 Property 比例低于簽核閾值Data Lead阻斷自動(dòng) Action 或降級(jí)身份異常率未解析/沖突對(duì)象 / 新增對(duì)象超出容忍范圍MDM/Data Owner進(jìn)入解析隊(duì)列核心定義漂移未經(jīng)影響評(píng)估的核心變更數(shù)任一發(fā)生Ontology Lead回滾并補(bǔ)評(píng)審空白 Scorecard 至少保留指標(biāo)、業(yè)務(wù)含義、分子分母、數(shù)據(jù)來(lái)源、基線、目標(biāo)、Owner、頻率、分層維度、預(yù)警條件和處理動(dòng)作。完成標(biāo)準(zhǔn)不是每項(xiàng)都有漂亮數(shù)字而是每個(gè)指標(biāo)都能被穩(wěn)定采集、有人解釋、觸發(fā)明確行動(dòng)并能與目標(biāo) Decision 和 Outcome 連起來(lái)。價(jià)值不是上線時(shí)證明一次而是在運(yùn)營(yíng)中持續(xù)證明Palantir 將 Ontology 描述為面向決定的運(yùn)營(yíng)層Data、Logic、Action 與 Security 被連接起來(lái)人和 Agent 的決定及其結(jié)果能夠進(jìn)入共同的 decision lineage。PalantirWhy create an Ontology?這意味著價(jià)值證明也不是項(xiàng)目結(jié)項(xiàng) PPT。每次 Trigger、建議、人工覆蓋、Action、寫回與 Outcome 都產(chǎn)生新的運(yùn)營(yíng)證據(jù)幫助團(tuán)隊(duì)改進(jìn)對(duì)象定義、Logic、應(yīng)用和治理?；乜凑麄€(gè)系列BA 的交付物已經(jīng)發(fā)生遷移PRD 升級(jí)為 Action Contract 與 Outcome流程圖升級(jí)為對(duì)象狀態(tài)、Trigger 與 AutomationER 圖和字段字典升級(jí)為 Object、Link、Property 與數(shù)據(jù)證據(jù)鏈規(guī)則和 UAT 升級(jí)為 Function、Model、Criteria、Eval 與閉環(huán)驗(yàn)證。本體項(xiàng)目的成敗最終不由模型有多大決定而由一條具體業(yè)務(wù)句子是否成立正確的人或 Agent在正確時(shí)刻基于可信上下文作出可解釋的決定通過(guò)受控 Action 改變現(xiàn)實(shí)并讓結(jié)果進(jìn)入后續(xù)學(xué)習(xí)。如果這句話能夠被運(yùn)行、被觀察、被改進(jìn)Ontology 才真正成為企業(yè)的運(yùn)營(yíng)層。最后收束從看懂平臺(tái)到經(jīng)營(yíng)決策系統(tǒng)這套系列走過(guò)四段路先從恒川工業(yè)的缺料處置體驗(yàn)閉環(huán)再用 Object、Property、Link、Action 和 Writeback 拆開 Ontology繼而把數(shù)據(jù)、Logic、應(yīng)用、AIP 與 Agent 接入生產(chǎn)最后用變更、可觀測(cè)性、DevOps、FDE 和 Outcome 把能力變成組織的長(zhǎng)期資產(chǎn)。BA 可以從一個(gè)現(xiàn)實(shí)決定開始寫清 Outcome、Trigger、Options、Action、Evidence、Owner 和失敗后的接管方式再與用戶跑通一個(gè)可核驗(yàn)的小閉環(huán)。對(duì)象、數(shù)據(jù)、應(yīng)用和 AI 的范圍都應(yīng)由這個(gè)閉環(huán)反推。這也是 32 篇共同回答的問(wèn)題Palantir Ontology 的價(jià)值不是讓企業(yè)擁有更多技術(shù)名詞而是讓業(yè)務(wù)決定成為可建模、可執(zhí)行、可治理、可度量和可持續(xù)改進(jìn)的運(yùn)營(yíng)能力。【聲明】本文基于 Palantir 公開資料及作者的業(yè)務(wù)分析與實(shí)施研究整理與 Palantir Technologies 無(wú)官方關(guān)聯(lián)不構(gòu)成官方產(chǎn)品說(shuō)明。端到端實(shí)施路徑、角色邊界、四類指標(biāo)、交付清單、上線準(zhǔn)備度與 Outcome Scorecard 是本系列面向 BA 的實(shí)施歸納。