(請執行更新 install.sh --update)取得本文的範例表單+流程，重點會放在表單的設計

前兩篇把表單設計器與流程規劃師的操作走過一遍，這篇用一個實際案例把兩者接起來：ISP 機房設備維護。廠商要進機房做年度維護，從申請、主管核准、現場核對人員、ISP 進出登記、維護作業，到最後保存證據結案，整個過程要環環相扣，後一段不能繞過前一段。

做法是一張表單、四個區段、一個流程。表單上四個區段分別給申請人、現場員工、陪同員工、結案負責人填；流程走到哪一關，那一關的人在簽核畫面上只看得到該填的區段，前面已經填好的區段變成唯讀，還沒輪到的區段根本不會出現。本篇只講「不同階段怎麼看到不同內容」這一件事，流程本身的細節帶過。

先來個情境

符合 ISO 27001，不代表風險就不會發生

從一場機房維護事件，談 Process、Workflow 與新一代自動化管理

企業導入 ISO 27001 時，經常將管理制度落實為各種表單、申請、簽核與紀錄。只要表單齊全、主管核准、紀錄完整，似乎就代表作業符合規範。

但我們不妨思考一個問題：

一件作業即使完全符合稽核要求，是否就代表風險已受到充分控制？

答案顯然是否定的。

一、一場看似平常的機房維護

某企業接獲設備廠商通知，將派遣一名工程師前往 ISP 機房，進行年度設備維護與韌體更新。

公司員工確認通知屬實後，依內部規定填寫外出申請單、設備維護申請單，經主管核准後安排作業。

維護當天，熟悉的工程師卻帶來一名見習學徒。

員工考量雙方長期合作，而且學徒由資深工程師陪同，認為沒有必要為增加一名見習人員中斷維護，於是允許兩人一同進入。

依 ISP 當時的進出管理制度，只由公司員工登記身分，並以一人帶領兩名廠商人員的方式進入機房。

維護順利完成，員工返回公司後填寫設備維護紀錄，卻沒有記載臨時增加的第三人。

一個月後，警方突然聯絡公司。

原來當天那名學徒在機房內，擅自拿走其他廠商遺留的 USB 隨身碟。失主透過監視錄影追查，最終循線找到公司員工。

更麻煩的是，當公司向維護廠商查證時，雙方對第三人的身分及歸屬產生爭議，廠商甚至否認該人員與公司的關係。

此時，公司發現一個問題：

表單、主管簽核、維護紀錄全部存在，但這些文件無法完整重建當天實際發生的事情。

原本看似合規的維護工作，突然暴露出人員身分、授權及證據追溯上的缺口。

二、如果當天三人都有登記，是否就萬無一失？

假設我們改變情境。

員工當天堅持所有進出機房的人員，都必須依 ISP 規定完成個別身分登記。

維護結束後，員工也如實填寫第三人的身分、參與情況，並寄信通知廠商：

「本次維護臨時增加一名見習人員，請往後事先通知，以利人員管理。」

廠商回信確認，員工將往來郵件附於維護紀錄，再由負責人完成結案確認。

在公司制度允許現場人員於既定風險及授權範圍內處理臨時變更的前提下，這套做法可以構成合理的受控作業。

而且不一定需要主管再次簽核。

但是，假設學徒依然偷走 USB 呢？

即使整個作業符合既定程序、證據完整，犯罪事件仍然可能發生。

ISO 27001 的目的從來不是保證所有事件都不會發生，而是要求組織建立適當的風險管理及控制機制。

反過來說，發生事件也不代表先前所有控制必然失效。

真正重要的是，企業能否證明當時的決策具有適當授權、風險受到合理管理，以及事件發生後能否迅速還原事實、追查責任並持續改善。

三、問題不在表單，而是我們把表單當成管理流程

傳統企業的作業管理，通常圍繞幾張表單：

• 外出申請表
• 設備維護申請表
• 機房進出紀錄表
• 維護結果紀錄表

每張表單可能都有自己的簽核路線。

表單的目的原本是蒐集資料、取得授權與保存證據，但久而久之，企業容易將「完成表單簽核」誤認為「完成管理控制」。

這兩者並不相同。

例如員工依規定取得核准，到了機房卻發生臨時增加人員的情況。

系統應該如何處理？

若要求任何變動都重新送主管核准，實際作業將因無數小變化而頻繁中斷。

但若完全交由員工自由決定，又容易產生授權不明、紀錄遺漏與責任不清的問題。

因此，企業需要的不是持續增加表單，而是重新設計管理過程及其執行機制。

四、從 Process 到 Workflow：重新理解管理架構

可以用四個層次建立管理模型：

Process → Sub-Process → Workflow → Task

以機房維護為例：

這是一套適合自動化管理平台的架構約定，而不是 ISO 27001 強制規定的階層。

特別需要理解 Process 與 Workflow 的區別。

Process 關注的是「要產生什麼成果？」

Workflow 關注的是「工作如何被執行、協調與流轉？」

而 Stage（階段）則用來描述：

「目前進展到哪個階段？」

例如機房維護的 Process，可以區分申請、執行、結案等 Stage；每個 Stage 可以包含不同的工作活動與 Workflow。

必要時，複雜的工作可以再拆成 Sub-Process，而各 Sub-Process 也能具有自己的控制目標及執行流程。

這些概念並非完全互斥。以 BPMN 為例，Process 本身就可以包含活動、條件、分支及執行順序，也能使用 Sub-Process 建立巢狀結構。

因此，Process 與 Workflow 是兩個不同的管理視角，不是所有標準都一致定義的固定父子關係。

五、讓 Workflow 管理作業，而不是讓表單決定作業

重新設計後，機房維護可以採用以下管理原則：

事前核准 → 現場授權裁量 → 如實記錄 → 例外分級處理 → 事後結案

正常情況下，員工提出維護申請，主管核准後執行。

如果現場臨時增加一名見習人員，系統不必要求重新啟動整個申請流程。

員工只需依據事先定義的授權邊界，判斷是否允許第三人參與。

例如確認身分、確保符合 ISP 進出規定、限制見習人員活動範圍，並留下實際人員紀錄。

若未超出授權及風險邊界，就由員工直接完成現場處理。

若涉及未經授權操作、身分無法確認或其他較高風險情況，再啟動主管審核或其他控制措施。

這裡的主管審核，只是 Workflow 中的一種節點。

表單同樣如此。

表單應該只是 Workflow 的一個 Node，而不是整個 Workflow 本身。

除了表單節點，Workflow 還可以具備條件判斷、資料庫查詢、系統 API、通知、驗證、稽核及自動化操作等節點。

如此才能讓系統依照實際業務需求決定工作如何進行，而不是讓業務遷就既有表單設計。

六、自動化控制不只是減少人工簽核

更值得重視的是，當管理系統不再只是表單簽核平台，許多原本依靠人員記憶及內部稽核抽樣才能發現的問題，就有機會轉為持續性的機械化控制。

例如：

1. 自動交叉比對

比對維護申請、實際進出名單及維護紀錄，發現人員數量或身分不一致時產生提醒。

若 ISP 提供可合法取得的電子進出紀錄，便可透過介面進行自動比對；若沒有，仍可由人員登錄或附加佐證資料。

2. 自動偵測異常

例如同一廠商經常臨時增加未申報人員、設備維護紀錄長期延遲、某些員工的案件反覆出現例外，或特定時段出現不尋常的機房進出活動。

這些不一定構成違規，卻可以作為風險監控及內部稽核的線索。

3. 自動追蹤證據

系統可以保存各節點的執行時間、操作人員、核准決策、資料異動、流程版本及例外原因。

原始紀錄應保留必要的修改歷程，避免事後覆寫造成證據失真。

4. 自動分級與通知

低風險變動由授權員工自行處理；達到預先設定條件時才通知主管，必要時啟動資訊安全事件處理 Process。

這讓主管不必被大量低風險事項打擾，卻仍能掌握真正需要關注的問題。

5. 支援內部稽核

內部稽核人員不再只能依靠人工抽查表單，而可以查詢例外比例、異常趨勢、未完成的改善措施與控制執行紀錄。

但自動化偵測仍需要可靠資料與適當規則，不能將系統沒有發出警報直接等同於沒有風險。

七、管理制度也應該可以快速修改，而且修改本身要受控

傳統表單系統另一個問題，是企業每次調整管理規定，都可能需要重新製作表單、修改簽核路線、發布新版 SOP，再通知各部門配合。

而真正的自動化管理平台，應該讓企業能在內部討論後，直接調整 Process 的控制原則與 Workflow 的執行邏輯。

例如公司經過風險評估，認為所有進出 ISP 機房的人員都應留下個別身分紀錄。

管理者只需要在進出控制的相關 Workflow 中增加必要的檢查條件、提醒或驗證節點。

不必重新設計整個機房維護 Process，更不必新增一套繁瑣的表單。

但這種修改不能毫無限制。

系統應保存流程版本、修改原因、核准紀錄、生效時間，以及案件執行時所使用的版本，必要時還應經過測試及權責核准。

這使企業能夠快速改善作業，同時維持變更控制與證據追溯。

這也符合 ISO/IEC 27001:2022 第 8.1 條重視作業準則、執行控制、變更管理及必要紀錄證據的方向。

八、合稽不該是管理的終點

回到最初的機房維護案例。

企業即使做到事前核准、完整登記、據實記錄與事後確認，仍然無法保證第三人不會做出違法行為。

但是，良好的管理系統至少應讓企業知道：

誰在什麼時間進入、當時經過何種授權、執行了哪些工作、發生什麼變動，以及後續由誰負責處理。

更進一步，企業應該在風險訊號出現時就獲得提醒，而不必等警方一個月後聯絡，才開始重新拼湊當天發生的事情。

合稽證明的是組織在特定準則及證據下符合要求，不等於所有風險都已消失。

表單證明有人填寫，不必然證明風險受到有效控制。

主管簽核證明有人核准，不必然證明後續實際執行完全符合預期。

因此，我們需要的不只是把紙本表單電子化，而是讓管理制度、作業流程、執行證據與持續監控整合成一個可調整、可驗證、可追溯的自動化系統。

好的管理制度不應該要求員工預測所有可能發生的例外，也不應該讓主管成為所有小事的唯一決策者。

它應該讓員工在合理授權下靈活處理日常工作，讓高風險事項受到適當限制，讓管理者能快速調整控制措施，也讓稽核人員更早發現不正常的情況。

ISO 27001 不應只是讓企業證明「我們有照規定做」，更應該成為企業持續回答「我們的控制是否真的有效」的管理工具。

而從傳統表單簽核，走向以 Process 為核心、由 Workflow Engine 執行、各種控制 Node 協同運作的管理架構，正是值得企業思考的方向。

情境End

接下來落實上面的流程圖(請直接執行更新 install.sh --update)取得本文的範例表單+流程，重點會放在表單的設計

一、三個機制各管一件事

三件事缺一不可。只有條件顯示，簽核者看得到區段卻改不了；只有欄位權限，還沒輪到的區段會整段攤在畫面上；沒有 stage 欄位，前兩者都沒有判斷依據。

二、表單：一個隱藏欄位加四個 panel

表單的結構是：

條件寫在 panel 上，不是寫在每個欄位上。在表單設計器點 panel 的編輯鈕，切到「條件」分頁，上半部「簡單」只能做「某欄位等於某值」，做不出「S2 以後都顯示」；要往下捲到「Advanced Conditions」，在 JavaScript 那格寫：

show = ['S2', 'S3', 'S4'].indexOf(data.stage) >= 0;

data 是整張表單目前的值，show 要被指定成布林值。第三區段寫 ['S3', 'S4']，第四區段寫 ['S4']。第一區段不寫條件。

（圖01：panel 的「條件」分頁，Advanced Conditions 裡的 JavaScript）

一件要知道的事：form.io 預設會在元件被條件隱藏時清掉它底下的值。本例不受影響，因為區段只會往後解鎖，被隱藏的永遠是還沒填的區段；如果你的流程會把 stage 改回前面的值，已填的區段會被藏起來，這時要在 JSON 裡給 panel 加 clearOnHide: false（panel 的編輯視窗沒有這個選項，要從「結構」看 JSON 或用匯入改）。

三、流程：在關卡之間推進階段

流程是直線的：主管核准 → 進入階段 S2 → 現場核對與進出登記 → 進入階段 S3 → 維護作業完成確認 → 進入階段 S4 → 負責人結案確認 → 結案。分支只有補件迴圈、臨時人員升級主管、三個「停止進入或取消維護」的出口。

這張流程系統設計圖就是上面那張傳統流程圖的真實可用版，不難，因為這次的重點是「表單在不同關卡依檔案給不同的人唯讀指定權位，可修改指定欄位」的教學，完全的行政表單沒有太多自動化node

（圖02：流程全圖。主線上三個「進入階段」節點是 OpFieldWrite）

「進入階段 S2」這種節點是 OpFieldWrite，設定只有兩格：目標欄位選「階段」（就是 stage），寫入內容填 S2。它在主管核准之後、現場員工收到簽核任務之前執行，所以現場員工開簽核畫面時 stage 已經是 S2，第二區段就顯示出來了。

（圖03：OpFieldWrite 的設定面板，目標欄位「階段」、寫入內容 S2）

接著是簽核節點。點開「現場核對與進出登記」這個 FormAdapter，第三個分頁「欄位權限設定」列出表單全部 22 個欄位，每個欄位對「簽核者」與「閱讀者」各有一個下拉：唯讀、可修改、隱藏。這一關只把第二區段的五個欄位設成「可修改」，其餘維持唯讀。

（圖04：現場核對關卡的欄位權限設定，只有第二區段是「可修改」）

四個簽核關卡各自只開放自己那個區段。主管核准那一關什麼都不開放，純粹看與決定。

四、各階段的人看到什麼

申請人在表單中心填單，畫面上只有第一區段。第二到第四區段因為 stage 是 S1，條件不成立，整段不渲染。

（圖05：填單頁，只有「一、維護申請」）

現場員工開簽核畫面，右上角的標記從「唯讀」變成「部分欄位可編輯」。第一區段是申請人填好的內容，欄位反灰；往下捲是第二區段，欄位可以輸入；再往下就沒有了，第三、第四區段不會出現。

（圖06：現場員工的簽核畫面，第一區段唯讀）

（圖07：同一個畫面往下捲，第二區段可填，後面沒有第三、第四區段）

到結案那一關，stage 是 S4，四個區段全部顯示，前三個唯讀、第四個可填。負責人在同一張單上看完整個過程再結案，不必翻別的單。

五、伺服器端擋住什麼

前端把欄位設成唯讀只是方便，真正的防線在簽核送出時：

• 送出的欄位值如果不在這一關的「可修改」清單裡，伺服器拒絕整筆簽核，回 403 與「欄位 vendor_name 不允許修改」這類訊息。本例驗證時故意在第二關連同 vendor_name 一起送，就是被這樣擋下來的。
• 每個被接受的修改各留一筆欄位異動紀錄：欄位、舊值、新值、誰、何時。結案時這張單的 12 個欄位異動分別記在現場員工與結案負責人名下，申請區段沒有任何異動紀錄。
• 填單時的必填驗證，伺服器會跳過有條件顯示的 panel 底下的欄位，所以第二到第四區段的欄位可以設必填，不會在送單時被擋。

這就是「環環相扣」實際落地的樣子：後一段的人改不了前一段的內容，改了會留痕，而且每一段都在同一張單上。

六、兩個會踩到的地方

• stage 要用「隱藏」（Hidden）元件。它不會出現在填單畫面，伺服器的必填驗證也會跳過它；它的值只由流程改，四個簽核關卡的欄位權限都讓它維持唯讀。
• 被條件隱藏的 panel 在簽核畫面上會留下一條約 2px 的細線（form.io 給隱藏元件保留的外框）。不影響功能，看得見而已。

本例的表單與流程可以用安裝包裡的腳本一次佈建：scripts/examples/provision_isp_maintenance_demo.py --apply，預設建在示範企業 DemoSOC，角色用 DEPT_MANAGER、SECURITY_STAFF、SOC_SUPERVISOR 三個出廠角色。

七、其他方式

其實這種一張表單多個樣貌的方式未必能適應每個企業的風格，非常多企業的思維還是習慣用「單」為主體而非workflow甚至Process，這實在可惜，也就是要完成一項任務依20~30年前老闆那時的習慣所建立的，要填寫許多表單，過程再幾張，結束再報告幾張，過一陣子補上幾張遺漏的。而行政體系如財務就得每個月公告要結單囉～想盡辦法讓當月的單當月結束，這真的很累。不過，還是有辦法，最簡單的就是開發多張表單，共用一個最單純的逐層上報，最後依業務類別給最終蓋章的單位，大概就是手寫改打字化，蓋章改電簽化的老企業日常。對BeakPlatform來說實在大才小用了。