為財務和採購團隊而設的續約控制系統

想像一間有 180 名員工的專業服務公司，內部有一個 15 人財務和採購團隊。

公司使用數十個 SaaS 工具、數據供應商、承包商平台、訂閱服務和專門供應商。續約通知來自電郵、供應商平台、日曆提醒、合約文件夾、公司卡月結單，以及預算負責人的記憶。財務想更早看見續約。採購想要更乾淨的證據。部門主管想減少行政工作。管理層希望控制成本，但不想拖慢業務。

風險不只是超支。更大的風險，是承諾沒有被管理。一個工具可能昂貴但不可或缺。另一個可能便宜但帶來風險。某個供應商對一個團隊來說可能少用，對另一個團隊卻非常關鍵。一次看似例行的續約，在考慮法律、資訊保安或客戶交付背景後，可能並不例行。

這是一個適合讓 Proximity 充當續約控制基礎設施的場景。

目標不是自動化支出決定。目標是準備更好的續約審閱，讓財務、採購、預算負責人和管理層在更清楚的背景下作決定。

工作流程

這個工作流程，是每月供應商續約審閱。

團隊需要看到：

• 未來 30、60 和 90 日內有哪些續約到期。
• 哪份合約、發票或供應商通知確認該續約。
• 內部由誰負責該供應商。
• 哪個團隊使用它，以及用途是甚麼。
• 目前支出和過往趨勢如何。
• 是否有資訊保安、法律、客戶或交付依賴。
• 續約、取消或重新談判前需要哪些批核。

大多數財務系統都能顯示支出。這並不足夠。續約判斷依賴支出，也依賴背景。

Proximity 會圍繞經批准的紀錄連接續約流程，而不是取代財務系統。它會為審閱節奏建立一個共享的營運視圖。

這個視圖要把「付款」和「承諾」分開。財務可能在月結單上看到一筆款項，但續約風險往往早在付款前已經形成：自動續約通知期可能即將過去，取消窗口可能只剩幾日，某個部門可能仍依賴該工具交付客戶工作，或資訊保安審閱仍未完成。只看支出報表，團隊很容易在已經太遲時才發現問題。

在專業服務公司中，供應商亦可能橫跨本地、區內和國際平台。某些工具由公司卡付款，某些由採購合約管理，某些由部門主管直接續約。Proximity 的作用，是把這些分散線索整理成可審閱狀態，而不是把所有決定推向自動批准。

Proximity 會建立甚麼模型

在這個部署中，Proximity 會以「續約」作為核心工作對象。

經批准來源可能包括：

• 合約和訂單表格。
• 發票和公司卡交易。
• 採購紀錄。
• 供應商負責人清單。
• 可取得的使用量匯出。
• 預算紀錄。
• 資訊保安或法律審閱筆記。
• 電郵通知和日曆日期。
• 過往批核決定。

系統會把這些來源結構化成審閱背景：

• 供應商、產品、負責人、部門和業務用途。
• 續約日期、通知期、自動續約條款和取消窗口。
• 目前支出、過往支出和預算連結。
• 可取得的使用證據。
• 所需審閱人：財務、採購、法律、資訊保安、預算負責人或管理層。
• 已知風險、欠缺文件和未解問題。

COSO 將內部控制界定為支援營運、匯報和合規的一套系統。GAO Green Book 同樣把內部控制視為協助管理層達成目標的流程。放在財務營運 AI 裏，實際教訓很直接：在軟件能安全加速工作之前，控制環境本身必須可見。

Proximity 透過令續約狀態變得清晰，支援這個環境。

以「續約」作為核心工作對象，可以避免系統只停留在文件摘要。續約不是單一合約，也不是單一發票；它包括通知期、負責人、使用情況、預算、風險、批核和商業理由。某個供應商可能有正式合約但沒有使用證據；另一個可能有高使用量但缺少最新資訊保安審閱；第三個可能支出不高，但涉及客戶資料或交付依賴。這些差異必須在審閱包內可見。

系統亦應標明信心水平。自動續約日期若來自已簽署合約，可信度較高；若只是從供應商電郵推斷，就應標示為需要確認。預算負責人若來自最新採購紀錄，與來自舊 spreadsheet 的可靠程度不同。這些細節是控制基礎設施的一部分。

系統會準備甚麼

每月審閱之前，Proximity 可以為每個供應商準備續約包。

續約包可能包括：

• 合約摘要和來源連結。
• 續約時間線和通知窗口。
• 支出趨勢和預算負責人。
• 使用或採用證據。
• 未解問題。
• 所需批核路徑。
• 過往決定和理由。
• 給供應商或內部負責人的草擬問題。

系統亦可以維持一個審閱佇列：

• 可交預算負責人審閱。
• 欠合約。
• 欠使用證據。
• 需要法律審閱。
• 需要資訊保安審閱。
• 需要管理層批核。
• 取消窗口接近。

這個佇列不會決定結果。它協助團隊看見甚麼需要專業注意。

IBM 將工作流程自動化描述為使用軟件執行已定義流程步驟。在這個 Proximity 設計裏，重要工作流程不是「自動續約」。而是「把續約準備好，讓人可以負責任地作決定」。

審閱包可以令會議更有秩序。財務可以先看支出和預算影響；採購可以看合約條款和談判空間；資訊保安可以看資料和系統風險；法律可以看責任、續約和取消條款；預算負責人可以解釋業務用途。系統的工作，是把同一項續約拆成這些可審閱面向，而不是把它壓成一個「續約／不續約」按鈕。

審閱佇列亦可以幫助團隊提早行動。例如，取消窗口接近的供應商應先被浮現；欠缺合約的項目應先補齊來源；需要多個審閱人的續約應有較長準備時間。這些都是控制工作，不是最終商業判斷。

甚麼仍然由人負責

支出判斷仍然由人負責。

Proximity 不得批准續約、取消供應商、談判條款、更改銀行資料、批准付款、改動分類帳，或決定某個供應商是否值得保留。這些都是專業和組織決定。

人仍然負責：

• 預算判斷。
• 商業判斷。
• 風險接受。
• 供應商談判。
• 批核決定。
• 最終財務紀錄。
• 對外溝通。
• 任何令公司承擔金錢責任的行動。

系統可以準備證據和路由審閱。它不能擁有決定。

這條界線應該在產品中清楚可見。續約包應標示為「供審閱準備」。批核控制應屬於具名的人。審計歷史應顯示誰審閱、批准、改動或拒絕了某項行動。NIST SP 800-53 的存取控制和審計系列是有用背景，因為財務工作流程需要清楚的權限和問責軌跡。

因此，Proximity 不應直接連到會改變正式財務紀錄或付款狀態的動作，除非那些動作仍受既有控制和人手批核約束。它可以準備問題給供應商、整理內部審閱材料、提醒負責人和顯示缺口；但開支承諾、付款、取消通知和合約談判都應由具名人士按公司政策完成。

試點形態

一個有力的試點，可以集中於超過某個門檻的軟件續約，例如每年超過 10,000 的供應商，或需要多於一位審閱人的續約。

第一階段會梳理續約來源和批核規則。第二階段會為一小組供應商建立審閱包。第三階段會在每月續約會議中，以 Proximity 作為營運介面進行測試。

成功應以準備質素衡量，而不是以自動化數量衡量。

有用的訊號包括：

• 更多續約能在通知窗口前被識別。
• 較少欠缺合約或負責人。
• 更快組裝審閱證據。
• 批核路線更清楚。
• 更容易看見未使用、重複或高風險供應商。
• 財務和預算負責人表示臨急決定減少。

試點亦應檢查團隊是否在續約前更早看到「不可決定」的原因。很多續約延誤不是因為沒有人想決定，而是因為欠合約、欠使用數據、欠安全審閱、欠預算確認或欠清楚業務用途。如果 Proximity 能在會議前把這些缺口列出，月度審閱就會由追資料變成真正的控制和判斷。

試點門檻也要清楚。太低會把團隊淹沒在細小訂閱中，太高則可能錯過高風險但低金額的工具。實際做法可以先選擇年度支出超過某金額、涉及客戶資料，或需要多部門批核的供應商。這樣的範圍足以測試控制價值，也不會令系統一開始變成一般開支分類工具。

團隊還應檢查例外處理。某些續約可能因客戶交付、合約限制或緊急營運需要而不能按標準時間表處理。系統應保留例外理由、批准人和後續補救，而不是把所有偏離流程的情況都視為錯誤。

這令財務控制既可審計，也能容納真實業務情況。若例外後沒有留下原因和負責人，下一次續約又會重複同樣混亂；若例外被記錄清楚，團隊便能分辨哪些是真正特殊情況，哪些是流程需要改善。

換言之，試點要證明的不是系統能自動處理多少續約，而是它能否讓每次續約在到期前進入正確的人手審閱，並保留足夠證據讓財務、採購和預算負責人共同作決定。

這樣，控制才是加速工作的基礎，而不是被自動化繞過的障礙。

每一項續約都應有清楚來源、負責人、審閱路徑和決定紀錄；這些才是財務團隊可以信任的營運基礎。