Proximity 部署首月可以建立甚麼

部署的第一個月，應該令業務問題變得更具體。

這不代表每次部署都遵循相同的四星期次序，或達到相同的技術里程碑。工作流程集中、資料乾淨而權限簡單，可以很快進入早期實際運作。涉及多個系統、身份不一致、敏感紀錄或正式保安要求的流程，則可能把首月較多時間用於建立基礎。

有用的問題不是「30 日內保證完成甚麼？」，而是「機構在投入下一階段前，應該理解、測試和決定甚麼？」

從一項業務成果開始

第一個月由成果開始，而不是由一張 AI 功能清單開始。

例如：

• 減少回答訂單狀態問題所需的人手協調；
• 提高履約準確度；
• 縮短供應商資格審查；
• 減少準備項目變更決定所需的時間；
• 改善不同物業或服務團隊之間的延續性；
• 令管理報告更貼近當前狀態，並連回來源。

成果會界定哪部分營運納入範圍、哪些使用者需要參與，以及哪些指標重要。它也避免探索工作變成無止境地連接所有系統。

有用的基準可以包括準備時間、重複輸入資料、內部狀態查詢、例外持續時間、修正率、可避免的重做，或因欠缺證據而延誤的決定。首月應令這些指標足夠可信，以便之後判斷價值。

理解工作現在如何進行

營運範圍需要透過觀察來理解，不能只依賴理想化流程圖。

這包括了解：

• 工作從哪裏開始；
• 哪些系統、檔案、訊息和會議提供證據；
• 人如何判斷當前狀態；
• 哪些例外引起人手協調；
• 每項決定由誰負責；
• 哪些事情需要審批；
• 哪些習慣令工作即使在正式系統不足時仍然可以運作；
• 使用者在哪裏修正、重新解讀或繞過現有資料。

這個階段經常會改變原來的工作說明。要求建立儀表板，背後可能其實是產品身份問題。要求自動回覆客戶，可能要先核對訂單、庫存和履約狀態。要求改善報告，可能揭示團隊對「已批准變更」根本沒有共通定義。

這是有用的進展，因為一項廣泛的技術要求已經變成可測試的營運問題。

審核資料、存取權和權威性

自動化工作流程之前，需要先理解獲准使用的來源資料。

審核範圍包括：

• 哪些來源納入範圍；
• 每項事實由哪個系統或角色擁有；
• 身份衝突和重複紀錄；
• 欠缺、過時或輸入方式不一致的資料；
• 用語和狀態差異；
• 來源時間戳和資料沿革；
• 權限和用途邊界；
• 保留、匯出、撤銷和刪除要求；
• 哪些行動仍然需要人手審批。

這項工作不是拖慢實施。它決定之後的介面究竟呈現可靠的當前視圖，還是只替未解決的資料問題加上整潔外觀。

不同部署的保安和存取工作也可以有很大差異。NIST SP 800-53 提供既定的控制類別，涵蓋存取控制、審計、身份識別、系統完整性和風險評估等範疇。小型內部原型可能只需要其中有限部分。受監管或企業級正式應用則可能需要正式保安審查、資料處理協議、詳細控制對應，以及多個團隊提供的證據（NIST SP 800-53^{2NIST SP 800-53 Rev. 5, Security and Privacy Controls}）。

設計相互連接的營運模型

理解相關來源之後，第一個模型便可以定義支援成果所需的實體、關係、狀態和用語。

以 OEM 或 ODM 訂單狀態工作流程為例，模型可以連接客戶訂單、訂單項目、產品版本、工單、工序、品質狀態、出貨、承諾和負責人。供應商審查則可以連接要求、供應商、場地、報價、樣辦、資格、付款事件、物流事件、問題和決定。

本體模型設計應顯示：

• 哪些身份需要核對；
• 狀態如何推導；
• 哪個來源繼續具權威性；
• 如何保留可見的衝突；
• 哪些事件會令當前視圖過時；
• 哪個角色負責處理例外；
• 模型準備支援哪些決定或行動。

首月可能只產生部分連接模型，而不是完整的正式本體模型。目的是測試這些關係能否充分解釋營運，並支援有用審閱。

準備程度許可時測試早期工作流程

早期工作流程應使用真實材料和真實審閱情境。

視乎成果，它可以是：

• 連回來源的訂單狀態視圖；
• 產品或庫存差異佇列；
• 顯示證據缺口的供應商審閱資料包；
• 連接版本、審批和負責人的項目變更視圖；
• 連回當前項目紀錄的管理摘要；
• 供特定角色審閱例外的介面。

判斷原型的標準，不是 AI 看來是否令人驚艷，而是使用者能否更快、更可靠地回答實際問題。

他們能否把狀態追溯到來源？視圖是揭示衝突，還是把衝突藏起來？它有沒有使用工作本身的語言？它是否出現在需要作決定的流程位置？使用者能否修正身份、狀態或關係？行動邊界是否清楚？

有些部署不會在首月到達這個階段。如果資料存取需要長時間審批、整合需要供應商參與，或來源狀態尚未可靠，原型可以先使用受控資料匯出或具代表性的紀錄，同時界定正式應用路徑。

這並不等於聲稱即時整合已經完成。

在設計定型前讓使用者參與

使用者驗收測試不只是在推出前設置的最後關卡。

營運人員、審閱者和決策負責人需要在用語、狀態、例外和介面仍然容易修改時測試工作流程。標準情況顯示基本路徑是否運作，邊緣情況則揭示模型是否符合現實。

回饋應區分幾類問題：

• 來源太遲或錯誤；
• 身份對應錯誤；
• 本體模型無法表達該情況；
• 介面隱藏了必要情境；
• 工作流程在不合適的時點要求審閱；
• 權限邊界不清楚；
• 未有理解使用者的工作習慣。

這項分類很重要，因為不同問題需要不同處理方法。培訓不能修正錯誤對應，新增欄位不能解決決策權不清，自動化做得更好也不能修正沒有團隊負責的資料。

首月可能產生的成果

一個有用的首月，可以建立以下成果的組合：

• 已定義的業務成果和基準；
• 當前工作流程和決策負責人的地圖；
• 獲准來源和權限清單；
• 資料品質和核對評估；
• 初步業務本體模型；
• 早期工作流程或原型；
• 來自真實使用者和邊緣情況的回饋；
• 保安和管治工作清單；
• 已界定範圍的試點或正式實施計劃；
• 下一階段的成功準則。

實際組合取決於準備程度。

基礎已經穩固

如果來源容易存取、身份穩定、權限清楚，而且工作流程邊界明確，首月可以集中建立連接模型、介面和早期測試。

資料需要大量處理

如果產品、客戶、供應商、資產或項目身份在不同系統之間出現衝突，審核和核對工作可能佔去大部分時間。有價值的成果是可靠地說明需要修正甚麼，而不是在有爭議的狀態上倉促建立自動化。

管治情況複雜

敏感、受監管或涉及多方的工作，可能需要更多時間處理保安審查、法律協議、權限設計和審批測試。即使原型在技術上很直接，這些控制仍會影響正式應用時間。

甚麼決定正式應用的路徑

試點和正式應用的時間取決於多項因素：

ISO/IEC 42001 把 AI 管理視為一套持續運作的制度，涵蓋責任、目標、控制、評估和改善。相比把推出視為一次性技術完成，這種模型更適合部署工作（ISO/IEC 42001^{3ISO/IEC 42001 AI management systems}）。

NIST 的 AI 風險管理框架同樣按照使用生命週期和情境，組織管治、對應、量度和風險管理工作（NIST AI RMF^{1NIST AI Risk Management Framework}）。

首月是一個決策點

首月結束時，機構應該更有能力決定下一步。

以下事情應變得更清楚：

• 成果是否有足夠價值繼續推進；
• 現有資料能否支持成果；
• 需要改變哪些來源和流程；
• 本體模型能否解釋工作；
• 使用者如何回應早期工作流程；
• 還有哪些保安和管治工作；
• 試點或正式應用應如何界定範圍。

這比承諾每間機構在同一天收到同一交付成果更有用。首月為部署計劃建立證據，不能取代達到可靠正式應用所需的工作。

資料來源

1. NIST AI Risk Management Framework
2. NIST SP 800-53 Rev. 5, Security and Privacy Controls
3. ISO/IEC 42001 AI management systems