甚麼是 operating intelligence？

在這篇文章，我們把 operating intelligence 作為一個工作用語，指在機構運作時，把機構變得可理解的工作。這不是 Proximity 專有的詞；它接近既有的 operational intelligence 和 real-time business intelligence，只是我們把它較窄地應用於專業和知識工作。

意思是要知道哪些工作正在進行、甚麼已經改變、甚麼被阻塞、現時立場由哪些證據支持、作出過哪些承諾，以及下一步哪裏需要人作判斷。它不只是報表，也不只是自動化。它是讓人、系統，以至將來的 agents 能夠充分理解工作狀態，並負責任地行動的即時背景。

這很重要，因為大部分機構已經有很多軟件，但機構本身仍然很難被讀懂。重要背景散落在文件、收件箱、日曆、會議、財務工具、任務板、個案系統、試算表和人的記憶裏。每個系統都可能保存有用紀錄，但機構的營運狀態其實活在這些紀錄之間。

Operating Intelligence 的工作定義

Operating intelligence，在這裏指對工作如何流經一個機構的當前、結構化理解。

它與 operational intelligence 有關；後者常用於 IT、製造、物流、安全和服務營運，描述對事件、系統和表現的即時可見度。較早的 real-time business intelligence 文獻也有類似方向：Azvine、Cui、Nauck 和 Majeed^{7B. Azvine et al., Real Time Business Intelligence for the Adaptive Enterprise} 把 real-time BI 描述為在事件發生時分析商業營運資訊。Complex event processing 也是這個脈絡一部分；David Luckham 的 event processing 工作幫助建立機構如何從營運數據流中偵測有意義事件。

Proximity 的用法較窄，也較貼近實務。在專業和知識工作中，最重要的營運訊號往往不是機器事件，而是承諾、例外、批准、證據、交接、期限、關係和決定。

會議中作出的客戶承諾是營運數據。Matter file 中缺少一份文件、未解決的批准、與預算決定相連的供應商續約、改變跟進計劃的個案筆記，或者依賴判斷而不只是任務狀態的項目進度，也都是營運數據。

Operating intelligence 是把這些訊號轉化成可用現實模型的一層。它把工作紀錄連接到對工作的行動。

由紀錄到營運模型

大部分機構軟件擅長儲存紀錄。CRM 儲存帳戶和聯絡人。文件系統儲存檔案。財務系統儲存交易。項目工具儲存任務。個案系統儲存 matters。日曆儲存承諾。

但紀錄不等於營運模型。

營運模型解釋這些紀錄如何互相關連。它說明一份文件屬於哪個 matter、支持哪個決定、誰擁有下一步、適用哪條批准邊界、上次審閱後有甚麼改變，以及哪些行動可以安全地準備。

這就是 operating intelligence 和再加一個 dashboard 的分別。Dashboard 摘要資訊。Operating intelligence 維持背景。它關心工作、證據、人、節奏、資源和邊界之間的關係。

IBM 把 business intelligence 描述為收集、管理和分析機構數據，以支援策略和營運的流程。這仍然有用。Business intelligence 經常解釋發生過甚麼，以及表現趨勢如何。Operating intelligence 更關心現在甚麼是真實，以及下一步甚麼需要注意。

Digital Twins 作為實務結構

我們認為達成 operating intelligence 的實務方法，是建立 digital twins。

Digital twin 是某個真實事物的活模型。IBM 定義 digital twin 為實體物件或系統的虛擬表示，透過即時數據反映其對應實體的行為、表現和狀況。重點不在於模型是 digital，而在於模型持續連接正在改變的現實。

歷史上，這個模式來自工程和航天。IBM 把實務脈絡追溯到 NASA 在 1960 年代的太空船複本和 Apollo 13 救援工作，再到 Michael Grieves 在 2002 年的產品生命週期管理框架，以及 John Vickers 在 2010 年 NASA roadmap 使用「digital twin」一詞。Grieves 和 Vickers 後來把 digital twin 描述為透過連接實體產品、虛擬產品和兩者之間的數據連接，減低複雜系統中不可預測行為的方法。這概念最初是為了在直接實驗太危險、太慢或不可能時，理解複雜系統。

同一模式也適用於機構。專業服務團隊、客戶組合、照護路徑、財務營運、項目環境或法律 matter，同樣是複雜系統。它們有狀態，會隨時間改變，並依賴證據、人、工具、承諾和限制。

對專業工作來說，twin 不是 3D 模型，而是某個營運範圍的結構化模型。

它可以包括：

• 工作：matters、項目、個案、客戶、任務、交付物和期限。
• 證據：文件、筆記、決定、批准、來源材料和審計軌跡。
• 人：負責人、審閱者、客戶、合作夥伴、供應商和交接點。
• 節奏：每週審閱、每月匯報、續約週期、升級路徑和重複承諾。
• 資源：工具、訂閱、預算、供應商、存取權和支出。
• 邊界：權限、數據規則、批准要求和 human-in-the-loop 控制。

Digital model、digital shadow 和 digital twin 的分別在這裏有用。Kritzinger、Karner、Traar、Henjes 和 Sihn 在 2018 年製造業綜述中按數據整合分類：digital model 是人手更新；digital shadow 從實體系統自動接收數據；digital twin 則在實體和數碼兩邊有更互惠的流動。Thelen 等作者在 2022 年綜述亦作出相近區分，分別討論 physical-to-virtual 和 virtual-to-physical 數據流。

對 operating intelligence 來說，這個進程重要。機構的靜態地圖有幫助，但有限。接收即時數據的 shadow 更好。當模型可以支援經審閱的行動回到機構時，twin 會更有用。

Agents 需要機構可讀性

現在建立 operating intelligence 的最強理由，是 AI。

大型語言模型和 agents 越來越有能力，但能力不等於對機構有用。Agent 不能可靠地協助自己不理解的工作。它需要取得機構當前狀態：工作、證據、權限、負責人、定義、工具和審閱邊界，才知道某個行動是否適當。

在人類機構中，很多背景是隱含的。人知道去哪裏找、問誰、哪份文件有權威、甚麼語氣可接受，以及甚麼決定需要批准。Agents 不會自動繼承這些默會知識。機構要變得可被它們讀懂。

這種可讀性需要一條 pipeline：ingestion、processing、storage，然後是 retrieval and tools。每一層都在把分散的營運材料轉化為可用狀態。

Ingestion

Ingestion 是輸入層。它透過 API、webhooks、文件匯入、資料庫同步、電郵和日曆 connectors、會議逐字稿、表格、人手更新和批量上載，把營運材料帶入系統。

重點不是無差別收集一切，而是讓重要承諾、決定、證據和狀態改變，從實際工作發生的地方進入：文件、電郵、日曆、會議、財務工具、個案系統、任務板和資料庫。

Processing

Processing 是詮釋層。它把原始輸入轉成結構化營運資訊，包括解析內容、抽取欄位、解析身份、匹配紀錄、套用權限、偵測重複，以及連結相關物件。

原始紀錄要被清理、結構化、去重、加上權限、連結和標準化，成為穩定概念：matter、client、owner、approval、source、deadline、renewal、risk、task、review 和 outcome。

Storage

Storage 是已處理營運狀態的 system of record。它令機構當前狀態持久、可查詢、有權限控制和可審計，讓人和 agents 日後可回到同一組事實。

這可以包括 relational databases、search indexes、document stores、knowledge graphs、vector stores、audit logs 和 operational records。

這裏的難點不只是「放在哪裏」。專業工作還需要知道一個事實何時被加入、由哪個來源支持、是否仍然有效、誰有權查看，以及後來是否被取代或修正。若 storage 只保存抽象摘要而失去來源、版本和審計軌跡，AI 之後再使用這些資料時就會缺少問責基礎。

Retrieval and tools

Retrieval and tools 是行動層。Retrieval 讓人和 agents 找到正確背景；tools 讓它們透過受控介面建立、更新、分派、批准或審閱工作。

這可以包括搜尋、retrieval APIs、編輯器、queues、review surfaces、workflow controls 和受控寫入路徑。沒有 tools，AI 仍然只是文字介面。有了 tools，它才可以參與機構的營運系統。

Operating intelligence 是令這一切成為可能的基建。它令機構不只對人可讀，也對能夠閱讀、搜尋、推理、準備和在界限內行動的軟件可讀。

這一層亦決定 AI 是只會「講」，還是能夠負責任地參與工作。Retrieval 要能按權限、來源權威和時間返回材料；tools 要能限制可寫欄位、要求批准、記錄變更，並在不確定時拒絕操作。否則，系統即使知道很多背景，也仍然不能安全地把背景轉成行動。

為甚麼 SaaS 和自動化未夠

SaaS 給團隊應用程式。自動化把工作推過預先定義步驟。Operating intelligence 維持跨應用理解工作和決定下一步所需的背景。

傳統 SaaS 通常圍繞一個類別建立：CRM、項目管理、文件管理、財務、HR、個案管理、analytics、支援或 procurement。這些類別有用，但真實工作經常跨越它們。

一個客戶承諾可能在會議開始，延伸到電郵，依賴一份文件，影響預算，需要審閱，並在另一個系統產生跟進工作。沒有單一 SaaS 類別擁有整條鏈。

Operating intelligence 的角色，就是保存這條鏈的意義，而不是把每個環節拆回各自系統。當 agent 要準備更新時，它不應只找到最新電郵，也要知道該電郵連到哪個承諾、哪份文件、哪個預算影響和哪個審閱要求。這種跨系統關係，才是專業工作真正的營運狀態。

自動化有另一個限制。IBM 把 workflow automation 描述為用軟件執行原本由人手完成的全部或部分流程。當流程穩定而決定明顯時，這很有用：發提醒、複製文件、開 ticket、更新狀態或分派批准。

但專業工作經常有歧義。難點不是觸發行動，而是知道行動是否適當。

Operating intelligence 給自動化背景、限制和審閱點。它幫助系統知道何時行動、何時準備建議，以及何時停下來讓人判斷。

所以 operating intelligence 和 automation 的關係不是互相取代。Automation 負責可預測步驟；operating intelligence 負責解釋這些步驟何時適用、何時不適用，以及例外應該走哪條路。沒有這層解釋，自動化只會把固定規則套到變動情境上。

實務上是甚麼樣子

法律服務

Operating intelligence 可以連接 matters、證據缺口、客戶承諾、草擬狀態、合夥人審閱、存檔日期和批准邊界。Agent 便可以帶着來源背景準備客戶更新或 matter summary，而不是只靠 prompt 生成。

Finance-led teams

它可以連接訂閱、供應商、預算、負責人、使用量、續約日期和批准歷史。Agent 可以識別續約風險或準備 spend review，因為資源已經連到它支援的工作。

照護機構

它可以連接跟進節奏、敏感客戶背景、從業員筆記、交接狀態和治理邊界。Agent 可以協助準備審閱材料，而不會把敏感行動視為自動獲批。

Built environment work

它可以連接項目狀態、工地證據、圖則、客戶決定、承建商跟進、風險項目和批准流程。Agent 可以搜尋相關紀錄、準備下一步 brief，並送交審閱。

這些例子的模式相同：機構變得更可讀，因此更能用 AI 支援。

Operating Intelligence 的論點

Operating intelligence 的理由不是每個機構都需要更複雜系統。有些團隊夠小、夠穩定或夠封閉，現有 SaaS 工具和輕量報表已經足夠。

理由是，複雜工作現在需要更明確的營運層。當 AI 和 agents 成為工作一部分，隱含的人類背景會成為瓶頸。如果機構不能被軟件讀懂，agents 要麼停留在表面，要麼在沒有足夠 grounding 的情況下行動。

這個營運層不必一開始就宏大。很多團隊可以由一個高價值流程開始，例如客戶更新、續約審閱、matter review、供應商支出檢查或項目風險匯報。重點是把該流程中本來散落的工作、證據、負責人、期限和批准邊界連起來，形成一個可以被查詢、審閱和更新的狀態。

Operating intelligence 亦不是要取代現有 SaaS。CRM 仍然可以管理客戶，DMS 仍然可以管理文件，財務系統仍然可以管理交易；但營運層需要知道哪份文件支持哪個承諾、哪個交易影響哪個預算決定、哪個任務阻塞哪個客戶更新。沒有這層關係，團隊只會得到更多孤立系統。

對管理層而言，這種可讀性亦改變了 AI 採用的風險討論。問題不再只是「我們可否開一個 AI 工具給員工用」，而是「哪些工作狀態可以安全暴露給系統、哪些工具可以被系統呼叫、哪些行動必須留下審計紀錄、哪些決定必須由人批准」。這令 AI adoption 由一次 launch event 變成一個營運設計工程。

Operating intelligence 亦需要處理時間。很多紀錄單獨看是正確的，但放在當前時間已經不再足夠：合約版本可能被取代、會議承諾可能已完成、風險可能已升級、預算可能已重分配。活的營運模型要知道事件次序、最近變更、下一個期限和審閱節奏，否則 AI 只會把歷史片段當成現況。

另一個關鍵是 authority。並非所有資料都有同等地位。已簽署合約、內部草稿、會議筆記、CRM comment、財務系統數字和 Slack 訊息，可能都與同一件工作有關，但它們支持行動的程度不同。Operating intelligence 要保存這種權威差異，讓系統能說明某個結論是由正式紀錄支持，還是只是來自未確認筆記。

這亦令 digital twin 不只是資料同步。真正有用的 twin 會反映機構如何運作：誰有權批准、哪些流程有例外、哪些來源優先、哪些行動可逆、哪些決定需要雙重審閱。沒有這些營運邏輯，twin 只是更漂亮的資料庫。有了這些邏輯，它才成為人和 agents 可以共同使用的工作模型。

Operating intelligence 是把 grounding 變成真實的方法。Digital twins 提供結構。Ingestion、processing、storage、retrieval 和受控互動工具提供機制。人手審閱和批准邊界提供治理。

結果不是為自動化而自動化，而是一個更易理解的機構：人和 agents 都能看到正在發生甚麼、理解甚麼重要，並帶着正確背景行動。

建立 operating intelligence 時，第一步通常是選定一個營運範圍，而不是試圖一次過建立全公司大腦。範圍可以是一個客戶組合、一類 matter、一個續約流程、一組供應商，或一條照護／交付路徑。範圍越清楚，越容易定義哪些紀錄重要、哪些角色有權限、哪些來源具權威，以及哪些行動要審閱。

第二步是把工作狀態變成穩定物件。團隊需要決定甚麼是 client、matter、owner、source、deadline、approval、risk、task 和 outcome，並讓這些概念可以跨工具連接。這一步往往比模型選型更重要，因為 AI 只有在物件和關係清楚時，才知道自己正在協助哪一段工作。

第三步是建立受控互動。Operating intelligence 不是只讀系統；它最終要支援準備、分派、審閱和寫回。但寫回必須有邊界：哪些欄位可改、哪些需要批准、哪些動作只可建議、哪些必須留下審計紀錄。這些設計決定，才是把 live context 轉化為可靠 AI 工作流的關鍵。

這樣做的好處，是每一次 AI 協助都會強化營運模型，而不是產生一次性答案。工作越被使用，狀態越清楚；狀態越清楚，下一次協助越可靠。相反，如果每次 AI 使用都只是在 prompt 裏臨時拼湊背景，機構不會累積營運記憶。

這正是 operating intelligence 與一般報表或單點自動化的分別。它不是只回答「發生過甚麼」，而是維持一個可被人和 agents 使用的當前工作狀態：甚麼正在發生、甚麼已改變、甚麼需要判斷，以及哪些行動仍要留在人手控制之內。

當這個狀態能被查詢、被審閱、被更新，AI 才不只是從零生成文字，而是可以在機構已知的工作現實中準備下一步。這就是 operating intelligence 對 professional work 的實際價值。

它令下一步行動有背景、有邊界，也有可追溯的根據。

這是可問責 AI 的前提。

也是營運可讀性的核心。

資料來源

1. IBM: What is a digital twin?
2. IBM: What is business intelligence?
3. IBM: What is workflow automation?
4. Michael Grieves and John Vickers, Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems
5. Werner Kritzinger et al., Digital Twin in manufacturing: A categorical literature review and classification
6. Adam Thelen et al., A Comprehensive Review of Digital Twin, Part 1
7. B. Azvine et al., Real Time Business Intelligence for the Adaptive Enterprise
8. David Luckham, The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems