程式的組織方式，一般是應用包含模組，模組包含類別，類別包含方法。這樣的組織方式，也可以在SOP中採用。訂定SOP組織的方式，先由上而下定義好之後，再「由下而上」（bottom-up）檢查有無漏失或者不好的地方。
之前發表的「寫SOP就是寫程式」一文，得到讀者相當不錯的反應。該文概略地提到SOP（StandardOperatingProcedure，標準作業程序）和程式設計的相似性，這一次的文章將繼續說明，如何在寫SOP的過程中，以程式為師。
整體的組織方式
程式的組織方式，一般是應用包含模組，模組包含類別，類別包含方法。這樣的組織方式，也可以在SOP中採用，而這種上下包含的關係，可以直接和公司的組織架構相對應。訂定SOP組織的方式，先由上而下定義好之後，再「由下而上」（bottom-up）檢查有無漏失或者不好的地方。
模組命名方式可以避開類似3.2.5這種傳統的編碼做法，改成「工程部／品保組」這樣的命名，「／」前面的名字（工程部）是位於組織上層者，後面的名字（品保組）是位於組織下層者。這樣的寫法類似於程式的名稱空間（namespace），只不過使用「/」取代「::」或「.」。
程式中模組包含類別，而SOP的類別可以是角色（role）或資源。例如「工程部／品保組」模組，可以包含「品保員」（角色）和「測試工具」（資源）。
不同的模組之間，都是獨立的。使用到其他模組內的事項，必須註明該模組為何者。
類別內的元素
類別內的事項分成三類：常態作業（routine）、事件驅動作業（event-driven）、例外處理（exceptionhandling）。常態作業，就是依照規律進行的例行事項；事件驅動作業，是指會因為特殊事件的發生，而進行的作業；例外處理，則是指一旦發生某種無法處理的狀況，要如何稍微補救。在進行常態作業和事件驅動作業時，遇到沒有描述的狀況，就會進入例外處理。
常態作業和事件驅動作業，何者的頻率高，並不一定，不同類別的取向可能完全不同。但可以肯定的是，例外處理事件發生機會很低，如果不是這樣，你應該將它改寫成常態作業或事件驅動。例如，天天被搶劫兩三次的便利商店，應該將「被搶劫時的處理方式」，由例外處理內的簡短說明，改放進事件驅動作業中，詳細載明處理步驟。
例外分成兩種：可挽救的與不可挽救的。可挽救的例外，可以依照指示進行處理；遇到不可挽救的例外，所做的處理不外乎是「打電話請教頂頭上司該怎麼辦」「按下警鈴」之類的消極舉動。
結構化內文編排
所謂的結構化（structured），簡而言之，就是少用GOTO，多多使用for、while之類的迴圈（loop）。
SOP中經常出現「回到第幾個步驟」之類的敘述。這樣的方式，其實都可以用迴圈的概念改寫得更好，再搭配內縮（indention）格式，更能夠一目瞭然。
除了迴圈可以內縮，在SOP中的條件式分支（if/else）也可以搭配內縮。有了內縮，即使套疊（nest）兩三層，也相當清楚。
謹慎地呼叫函式
不管是常態作業、事件驅動或例外處理，都可以被視為函式。對SOP來說，函式可以呼叫別的函式。
電腦有CallStack，可以記錄目前函式是由那個函式所呼叫的，而此函式又是被誰呼叫的……一直記錄到源頭的main函式。但人不是電腦，人的回溯能力很差，所以在寫SOP時，CallStack的大小最好以一個frame為上限。（frame是指每次呼叫一個函式之後，會記錄在CallStack內的一組資料記錄。執行完該函式之後，又會從CallStack中清除此frame。）
只要你在寫SOP時，有呼叫函式的習慣，很容易一不小心就會打破frame上限為1的限制。如果你決定要遵守frame上限為1的規定，你可以定義許多「絕無呼叫任何函式」的函式，而你只會呼叫這些函式，如此一來就萬無一失。
函式可不可以呼叫自己呢？這可是遞迴（recursion）！更是不適合人的腦袋執行，所以應嚴格禁止。
事件日誌的記錄
寫程式時，許多時候我們需要將動作記錄在日誌（log）內，供日後分析，找出行為模式、潛在的缺失或罪魁禍首。
這樣的技巧也可以用在SOP中，在適當的時間點，要求人員採取記錄的動作，例如：記錄每天某商品銷售一空的時間點、記錄送貨人員來的時間。特別強調：發生例外時，一定要記錄到事件日誌中。
通常「時間＋事件」是事件日誌記錄的重點。可以用來記錄的方式相當多：打卡鐘、公司內部系統、PDA……等等。
這篇文章的SOP編寫構想，都是來自於我寫程式的經驗。我相信各位也一定可以從自己的程式經驗中，找到改善SOP的撰寫技巧，寫出更好、更實用的SOP。
作者簡介：
蔡學鏞－技術顧問
清華大學資訊工程碩士，曾任華碩集團軟體工程師、元智大學資訊系講師、美商歐萊禮出版社技術編輯、臺灣微軟特約專欄作家。