前陣子我寫了一篇關於 Windows、MIS、IT 工作到底要不要建立 SOP 的文章。
原本只是整理自己對於 IT 工作標準化的一些想法，後來剛好跟朋友聊天，又聊到這個問題。
沒想到朋友直接分享了一套他自己的實務經驗。
聽完之後，我突然覺得：
欸，這個觀念其實比「所有事情都寫成 SOP」更實際。
因為 IT 工作有一個很麻煩的地方：
有些事情真的可以標準化，但有些事情，真的不能寫死。
一、SOP 不是越詳細越厲害
很多人一想到 SOP，腦袋裡可能會浮現這種東西：
第一步：滑鼠移到左下角。
第二步：點開始。
第三步：輸入某某指令。
第四步：按 Enter。
第五步：看到畫面 A。
第六步：如果沒有畫面 A，請聯絡 MIS。
看到這裡，新人可能很感動。
因為他終於知道滑鼠應該往哪裡移。
但是 IT 工作真的全部都能這樣寫嗎？
答案其實是否定的。
例如使用者反映：
「我的電腦不能上網。」
這句話看起來很簡單。
但是 MIS 聽到這句話，腦袋可能已經開始跑流程：
電腦有沒有網路？
網路線有沒有插？
Wi-Fi 有沒有連？
IP 有沒有拿到？
DNS 有沒有問題？
只有這台不能上網，還是整個部門都不能上網？
交換器有沒有異常？
Firewall 有沒有異常？
是不是使用者自己把網路設定改掉？
甚至有時候最後發現：
網路完全沒問題，是使用者把網路線拔去接自己的小風扇。
這種東西你要怎麼寫成一份三百頁 SOP？
二、每個人的工作方法，本來就可能不一樣
朋友跟我分享的一個觀念，我覺得很值得記下來：
有些工作不適合制定成非常細的標準程序。
因為每個人的工作經驗不同，處理問題的方法也可能不同。
只要最後：
問題有解決
資料沒有遺失
權限沒有亂開
資安沒有出事
系統沒有被搞掛
重要紀錄有留下
那麼「處理方法不完全一樣」，未必就是錯。
這其實很像修車。
同一台車發不動，A 師傅可能先檢查電瓶。
B 師傅可能先聽啟動馬達聲音。
C 師傅可能先問車主：
「你昨天是不是忘記加油？」
最後三個人都可能找到問題。
所以 SOP 真正應該規範的，不一定是：
「你一定要按照我的手順操作。」
而比較應該是：
「哪些事情一定不能漏、哪些風險一定不能碰、最後要達到什麼結果。」
這兩者差很多。
三、新人第一件事情：先不要急著改革公司
這可能是很多新人最容易踩到的坑。
新人剛進公司。
看到某個流程。
心裡想：
「這也太老派了吧？」
「為什麼不自動化？」
「這個用 PowerShell 五分鐘就可以完成。」
「我們以前公司都不是這樣做。」
然後開始準備拯救公司。
結果第一個禮拜就把大家嚇出一身冷汗。
其實站在資深同仁的角度，我覺得比較合理的做法是：
新人先遵循目前公司的做法。
不是因為現在的方法一定最好。
而是因為：
你還不熟悉整個環境。
你可能還不知道：
為什麼這台 Server 不能動？
為什麼這個帳號不能直接刪？
為什麼這個 Firewall 規則看起來很奇怪？
為什麼這台老電腦還沒有換掉？
為什麼某個流程明明可以自動化，大家卻還是人工處理？
IT 系統裡面有很多「歷史的眼淚」。
有些設定不是工程師不會改。
而是以前改過一次，然後全公司一起停電……呃，不對，是一起停機。
所以新人最重要的第一課不是：
「我要怎麼改進公司？」
而是：
「我先搞懂公司現在到底是怎麼運作的。」
四、先學會，再改善
我很喜歡朋友提出的這個概念：
先照目前的方法做，等熟悉之後，再提出改善方案。
這其實是一個很成熟的工作方式。
第一階段：
學習。
先了解現行流程、系統架構、權限、設備、使用者習慣以及公司的規定。
第二階段：
熟悉。
開始可以獨立處理問題，知道什麼事情可以自己做，什麼事情一定要確認。
第三階段：
改善。
這時候你才開始問：
能不能更快？
能不能更安全？
能不能減少人工？
能不能自動化？
能不能留下更完整的紀錄？
能不能降低新人犯錯的機率？
這時候提出來的改善方案，通常會比第一天進公司就喊：
「你們這個流程不對。」
更容易被接受。
因為你已經知道自己在改什麼。
五、真正值得 SOP 的，是「大範圍＋高風險」工作
朋友另外提到一個我覺得非常實用的方法：
不要什麼都寫成細節 SOP，而是先整理大範圍、常用、重要的教學主題。
例如 MIS 可以安排新人教育：
Windows 與電腦維護
Windows 基本操作
常見故障排除
軟體安裝
印表機問題
使用者端基本檢查
AD 與帳號
AD 帳號建立
密碼重設
群組權限
帳號停用
離職帳號處理
網路
IP、DNS、DHCP 基本概念
Switch 基本觀念
VLAN
Wi-Fi
常見網路故障判斷
資安
密碼政策
權限管理
可疑郵件
惡意程式
資安事件通報
Server／NAS／備份
基本操作
備份概念
還原流程
權限管理
異常事件處理
緊急事件
Server 異常
網路中斷
Firewall 異常
大量使用者無法登入
資安事件
這些東西先建立一個大地圖。
新人至少知道：
「公司 IT 有哪些東西。」
而不是每天遇到問題才問：
「這個是什麼？」
六、教學最好留下「我有教過」的紀錄
這裡朋友又提到一個很實務的做法：
上課、筆記、簽名。
有人可能看到「簽名」兩個字，就覺得：
「是不是在抓戰犯？」
其實不一定。
如果設計得好，簽名真正的用途應該是：
確認教育訓練已經完成。
例如今天教新人：
「AD 帳號建立與權限管理。」
可以留下：
教學日期
教學主題
教學內容
教學人員
受訓人員
新人筆記
是否有疑問
確認日期
最後再請新人簽名。
這代表的是：
「這個主題我已經接受過說明。」
而不是：
「以後出事全部算你的。」
當然，紀錄也不能取代實際能力。
簽名不代表新人已經變成 IT 大神。
只能代表：
「這堂課，我有教。」
七、簽名以前，最重要的是多問一句
我覺得這可能是整個方法裡最重要的一個細節：
簽名前，再問一次：
「還有沒有什麼問題？」
而且不要只是形式上問。
可以再進一步問：
「如果今天使用者突然不能上網，你知道第一步要檢查什麼嗎？」
或者：
「如果這個帳號離職，你知道哪些地方要處理嗎？」
因為新人有時候不是不問。
而是：
他根本不知道自己哪裡不懂。
這就是教育訓練最麻煩的地方。
老師講：
「大家有沒有問題？」
新人：
「沒有。」
老師：
「確定？」
新人：
「確定。」
隔天：
「老師，這個要怎麼做？」
老師：
「……你昨天不是說沒問題？」
新人：
「我昨天不知道這個也算問題。」
這就是職場教育的經典場景。
八、所以我會把 SOP 分成三種
如果要把這整套觀念整理成一個簡單的方法，我會把 IT 文件分成三層。
第一層：一定要標準化
例如：
資安規範
帳號權限
備份
還原
離職流程
重大異常通報
資料處理
高風險設備操作
這些事情最好不要：
「每個人有自己的玩法。」
因為這種地方玩出差異，可能不是創意，而是事故。
第二層：提供參考流程
例如：
Windows 故障排除
網路問題
印表機
軟體異常
使用者端問題
可以提供：
常見檢查方向＋案例＋注意事項。
但不一定要求每個人百分之百照同一個順序。
因為現場問題千奇百怪。
第三層：保留專業判斷
例如：
複雜網路問題
Server 異常
系統架構問題
效能問題
特殊設備問題
這些工作可以讓資深人員依照經驗判斷。
新人則先觀察、學習。
等經驗累積到一定程度，再提出自己的方法。
這樣比較容易形成：
制度＋經驗＋改善。
而不是：
一份 SOP 打天下。
九、最好的新人，不一定是最會背 SOP 的人
IT 工作做到最後，我覺得真正重要的能力，其實不是：
「你背得出多少 SOP。」
而是：
「你遇到 SOP 沒寫到的問題時，知道怎麼辦。」
因為現實世界不會照著你的文件發生。
使用者不會說：
「您好，我目前遇到 SOP 第 17-2-3 節所描述之標準故障。」
他只會說：
「MIS！電腦壞掉了！」
然後人就消失。
剩下你跟那台電腦四目相交。
所以新人教育真正的目標，應該是讓新人慢慢從：
「照著做」
進步到：
「看得懂」
再進步到：
「會判斷」
最後變成：
「能改善。」
十、SOP 的目的不是限制人，而是降低風險
回頭看我跟朋友聊完之後的想法，我反而覺得：
SOP 跟自由發揮根本不是互相衝突的。
真正好的 SOP，應該把「不能出錯的事情」固定下來。
把「需要經驗判斷的事情」留下空間。
新人先學會公司現有的方法。
資深同仁則把重要的經驗傳承下去。
等新人熟悉環境之後，再鼓勵他提出：
「有沒有更好的方法？」
這樣才會形成真正的改善循環。
教學 → 實作 → 熟悉 → 發現問題 → 提出改善 → 再標準化。
這才是 IT 部門比較健康的成長方式。
結語：新人不是來背 SOP，資深同仁也不是來守著 SOP
我現在反而覺得：
SOP 最好的用途，不是把每個人的手腳綁起來。
而是讓新人至少有一張地圖。
你可以告訴他：
「這裡是公司的網路。」
「這裡是 AD。」
「這裡是 Server。」
「這裡是備份。」
「這裡不能亂碰。」
「這裡出了問題要先通報。」
「這些事情一定要留下紀錄。」
先讓新人知道整座城市長什麼樣子。
至於以後他要走哪一條路、哪條路比較快、哪條路比較安全，等他熟悉環境之後，自然會開始有自己的想法。
而資深同仁真正重要的角色，也不是每天站在旁邊說：
「不行！以前就是這樣做！」
而是可以告訴新人：
「你先把現在的方法學會，等你真的搞懂整個環境之後，如果你有更好的方法，我們可以一起討論。」
這句話，我覺得比一本厚厚的 SOP 更有價值。
因為真正好的 IT 團隊，不是永遠靠著同一套 SOP 活著。
而是：
新人學會現在的方法，資深留下經驗，大家一起把下一版的方法做得更好。
畢竟 IT 最可怕的事情，從來不是 SOP 不夠厚。
而是：
只有一個人知道怎麼修，其他人只能站在旁邊祈禱。
那不是 SOP。
那叫做——
「人肉單點故障（SPOF）」！
