甚麼是營運智能？
營運智能的實用定義：透過共通業務本體模型連接具權威性的業務資料，讓人和軟件理解當前工作、使用合適介面採取行動，並按已定義的業務成果持續改善。
重點摘要
- 營運智能，是對業務如何運作以及工作如何影響既定業務成果，建立一套相互連接而且反映當前狀態的理解。
- 它先審核、清理及核對獲准來源的資料，再以業務本體模型連接實體、狀態、用語和關係，同時保留原有權威系統。
- 介面、自動化、培訓和改進應配合工作流程與使用者的工作視角，而不是迫使所有團隊使用同一個通用介面。
營運智能，是對一間企業目前如何運作，建立一套相互連接而且反映當前狀態的理解。
它回答的是實際問題：現在發生甚麼？有甚麼改變？哪個來源支持目前的判斷？不同系統在哪裏出現分歧？下一個決定由誰負責？甚麼行動合適，哪些事情仍然需要人的判斷？
這並不是再加一個儀表板，也不是把所有紀錄複製到新資料庫。工作由一個業務成果開始，再把影響該成果的資料、關係、決定和營運習慣整理清楚，讓人和軟件可以負責任地使用。
從業務成果開始
一間機構即使連接大量資料，也可能創造不了多少價值。
有用的起點，是一個清楚的營運成果，例如減少處理訂單時的人手協調、提高履約準確度、縮短供應商審查時間、控制項目變更、改善服務延續性，或減少準備管理決定所需的時間。
這個成果會界定範圍。
如果目標是提供更可靠的訂單更新，相關資料可能包括客戶訂單、產品版本、生產事件、品質暫停、出貨狀態和承諾日期。如果目標是加快供應商資格審查，範圍可能包括要求、報價、認證、樣辦、付款紀錄、物流事件和審批責任。
系統不需要公司內每一項紀錄。它需要能夠解釋成果的證據和關係，包括證據不完整或互相矛盾的情況。
這也令價值可以量度。實施前可以先建立基準，包括重組狀態所花的時間、重複輸入資料、可避免的例外、延誤的審批、修正率或未能履行的承諾。技術之後必須改善營運中可觀察的一部分，而不是只製造抽象的 AI 活動。
自動化之前，先審核、清理和核對資料
第一項技術工作不是自動化，而是理解來源資料。
獲准的系統和紀錄需要按以下方面審核：
- 身份：兩項紀錄是否指向同一客戶、產品、供應商、資產、訂單或項目；
- 權威性：哪個系統或角色擁有某項事實；
- 新鮮度：紀錄最後更新時間，以及該更新速度是否足以支持決定；
- 完整性：欠缺哪些欄位、事件或關係；
- 一致性：用語、單位、狀態和定義在哪裏不同；
- 權限：誰可以為甚麼目的存取來源；
- 資料沿革：數值來自哪裏，以及經過甚麼轉換。
清理資料不代表強迫每個來源儲存同一數值。兩個系統可能基於正當原因出現分歧。CRM 可以保存對客戶的承諾，ERP 則保存計劃生產日期。品質系統可能暫停某批物料，庫存系統卻仍然按實物數量計算。核對資料應揭示其中的關係和矛盾，而不是靜靜選擇最方便的答案。
原有系統繼續對其擁有的紀錄保持權威。連接後的視圖會保存來源識別碼、時間戳、權限、對應規則和資料沿革，讓審閱者明白目前狀態為何如此呈現。
W3C 的 PROV 框架把資料沿革描述為關於產生資料或事物時所涉及的實體、活動和人員的資訊。這個概念在此很有用，因為相互連接的營運事實不只需要一個數值，也需要可追溯的歷史（W3C PROV2）。
四個技術層支援營運模型
實施可以從四個技術層理解。它們解釋系統如何組成，但不取代以上由業務成果帶動的次序。
- 資料匯入： 獲批准的訊號由文件、訊息、會議、表格、日曆、營運系統、數據庫及使用者更新進入系統，並附有來源、時間、負責人及權限。
- 處理： 原始材料會被清理、去重、標準化、設定權限、連接及核對，變成機構實際使用的概念。
- 持久狀態： 產生的紀錄和關係保存在數據庫、索引、文件儲存、知識圖譜、工作流程日誌及審計紀錄內，並可供查詢和修正。
- 受控介面： 人和代理透過行動及權限清楚的工具，搜尋、審閱、編輯、分派、批准及寫回資料。
只有檢索而沒有受控工具，系統只是一名顧問；工具若沒有受治理的狀態，行動便會快過理解。營運智能同時需要兩者：一個可持續保存的工作狀態，以及有清楚邊界的使用方式。
本體模型建立共通的營運語言
理解相關資料之後，業務本體模型便可以提供相互連接的地圖。
本體模型描述某個營運範圍內重要的實體、關係、狀態和用語。它可以連接客戶訂單、訂單項目、產品版本、工單、工序、品質狀態、出貨、承諾和負責人。在物業工作中，它可以連接項目、文件、版本、變更、審批、指示、確認和下游承諾。
W3C 的 Web Ontology Language 用於以機器可讀形式表達類別、屬性、關係和語意（W3C OWL1）。業務本體模型把相同的基本概念應用到機構自己的營運語言。
這就是「相互連接的單一事實來源」在實務上的意思。它並不是聲稱一個資料庫已取代所有紀錄系統，而是令機構對當前紀錄如何相連、應採用哪個定義，以及哪些地方仍然不確定，有一套共通而且連回來源的解釋。
只有在較簡單的方法不足時，本體模型才有存在價值。
如果團隊只需要改善命名或文件控制，應先處理這些問題。如果兩個穩定系統只需交換少量而且定義清楚的欄位，針對性的整合可能已經足夠。如果問題只是難以找到獲准紀錄，搜尋和建立索引也可能解決問題。
當多個系統以不同方式描述同一項營運工作、相關狀態取決於跨系統關係，或重複出現的例外顯示單一固定資料結構無法解釋工作時，本體模型才變得有價值。
介面應配合使用者的工作視角
相互連接的模型並不等同使用者介面。
不同角色會從不同責任理解營運狀況。銷售人員需要可靠的客戶狀態和簡潔解釋。規劃人員需要看見限制和次序。品質專員需要證據和放行權限。管理人員需要例外、責任歸屬和業務影響。
向所有人顯示同一份紀錄並不會帶來協調，只會把解讀工作重新交給使用者。
營運介面因此應反映：
- 使用者希望影響的業務成果；
- 該角色熟悉的實體和語言；
- 作出決定所需的證據；
- 在該營運情境下可採取的行動；
- 審批和升級處理的邊界；
- 值得注意的例外。
這就是自動化和介面設計要在資料及本體模型工作之後進行的原因。當步驟已有清楚定義並可觀察時，工作流程自動化才有用。IBM 把它描述為以軟件執行部分或全部流程（IBM 工作流程自動化5）。營運智能提供所需情境，讓團隊判斷目前真正處於哪個流程狀態，以及下一步是否合適。
有些工作可以自動化，有些可以先準備供人審閱，有些應升級處理。另一些仍然由人負責，因為其後果取決於專業、商業、技術或關係判斷。
培訓是營運系統的一部分
技術上正確的系統，如果人不理解或不信任，仍然可以失敗。
新介面和自動化會改變員工解讀資料、修正錯誤、交接工作和作出決定的方法。因此，採用新系統需要溝通、練習和回饋，就像新同事入職一樣。
團隊需要學懂：
- 每個連接狀態代表甚麼；
- 哪個來源繼續具權威性；
- 不確定性和衝突如何顯示；
- 如何修正錯誤身份或關係；
- 哪些行動需要審批；
- 回饋如何改善之後的結果。
培訓應使用真實工作，包括邊緣情況。標準情況證明主要路徑可以運作，例外則揭示本體模型、來源時間、介面和權限模型是否配合實際營運。
重複修正不只是使用者錯誤。它可能顯示來源記錄得太遲、本體模型不完整、定義已改變，或工作流程已不再符合業務運作方式。持續改進會把這些修正轉化成更好的對應規則、控制、介面和培訓。
NIST 的 AI 風險管理框架把風險管理視為管治、對應、量度和管理的持續循環。這種生命週期觀點很重要，因為營運智能不會在第一個介面推出時就完成（NIST AI RMF3）。
營運智能與商業智能的分別
商業智能和營運智能有重疊之處，但回答不同問題。
IBM 把商業智能描述為收集、管理和分析機構資料，以支援策略和營運決定的流程（IBM 商業智能4）。商業智能通常最擅長報告已發生的事情、比較表現和顯示趨勢。
營運智能則集中於推動工作所需、相互連接的當前狀態：
| 問題 | 一般重點 |
|---|---|
| 發生過甚麼，表現如何？ | 商業智能 |
| 哪個紀錄保存在職能系統內？ | 紀錄系統 |
| 下一個應執行哪項重複步驟？ | 工作流程自動化 |
| 現在甚麼屬實、來源在哪裏分歧、誰需要作決定？ | 營運智能 |
這些類別可以互相配合。管理視圖可以結合商業智能指標、具權威性的紀錄、工作流程事件和業務本體模型，同時解釋表現和背後的即時例外。
敏感資料最需要清楚邊界
相互連接的視圖並不代表任何人都可以存取所有資料。
資料能否在不同來源和介面之間流動，取決於用途、權限和對象。以職業治療為例，治療師的私人工作筆記與供機構使用的摘要有不同目的。私人筆記不會自動進入較廣泛的連接視圖。任何轉移到機構摘要的內容，都需要有已定義的目的、存取邊界，以及由負責的治療師審閱。
相同原則亦適用於其他工作。工廠主管不需要看到所有商業細節，維修團隊不需要知道住客的會員紀錄，供應商審閱者可能需要資格證據，卻不需要存取無關的財務紀錄。
單一連接視圖會按權限和角色顯示內容。連接的作用，是令相關關係更清楚，而不是抹去保密要求、來源擁有權或專業責任。
營運智能的核心論點
當零散情境的成本已變得重要，營運智能便有價值。
次序很直接：
1. 定義業務成果及量度價值的方法。 2. 審核、清理和核對理解成果所需的獲准資料。 3. 建立本體模型，連接相關實體、關係、狀態和用語，同時保留權威來源。 4. 按工作流程、使用者、權限和營運環境設計介面及自動化。 5. 用真實工作培訓，從修正中學習，並隨營運變化持續改進系統。
結果不是整間公司的完美模型，而是一個更容易理解的營運範圍。它連接得恰到好處，讓人看見目前狀態，讓軟件準備有用工作，也讓需要負責的人少做一些人手重組，便能推動決定。
資料來源
/ 開始
從一個業務成果開始，再逐步擴展。
先選定一個明確的檢視週期、工作流程或團隊，找出更完整的營運脈絡可立即提升前期準備和專業判斷質素的地方。