任何一家有制度的公司,都會定義「標準作業程序」(Standard Operating Procedure,SOP)。對麥當勞和統一企業等以服務見長的大企業來說,SOP是重要資產、公司經營的Know-How,影響產品與服務品質,只要SOP完備,就可以快速展店。

甚至,日前警方查獲的詐騙集團也有SOP,該集團將詐騙手法詳細記載成為詐騙執行手冊。當詐騙集團也懂得藍海策略(詐騙手法推陳出新)、知道長尾效應(對準特定小眾族群進行詐騙也能獲利),並充分運用SOP時,或許也正代表我們社會相當進步,已經進入所謂的知識經濟的時代吧。

一般公司內部的運作,處處仰賴SOP。有的公司雖小,但SOP累積多年之後也是厚厚一大本。一般來說,SOP會告訴人員,要怎麼做一件工作、處理一件事情、調用公司的資源……等。

這一切,是不是讓熱愛程式的你有所聯想?

把公司看成一個電腦系統,有許多的資源(設備、材料、人員、執行緒、I/O),每個員工都是一個執行緒,櫃臺和倉儲是I/O,負責資料的進出,其中,SOP扮演程式的角色,以有效的方式協調、處理、運用這些資源,以達到特定的目的。

如果SOP是在公司內執行的程式,那麼,寫SOP其實就是寫程式,寫程式的方法自然也可以套用在SOP撰寫上。寫程式的經驗,對於寫SOP,其實是有幫助的。當你需要寫SOP,卻不知從何下手時,不妨往程式設計的方向來思考。

我認為SOP可以分成三大部分,第一部分是常規作業(Routine),第二部分是事件驅動(Event-Driven)作業,第三部分是例外處理(Exception Handling)。如果你了解程式設計,這三者該寫些什麼,你應該就會知道。

一個好的SOP應該具備哪些要素?從判斷程式的準則來看,應該是:執行效率高且耗費資源少、容易理解、支援跨平臺(在不同的分店一體適用)、方便修改維護。

既然SOP是一種程式,那麼,也可以採用不同的編程思維(Paradigm),例如物件導向、命令式、邏輯式、函數式。許多時候,用文字敘述的SOP,往往不夠清楚,如果能夠改用寫程式的方式來表達(不使用真正的編程語言,而是使用Pseudo Code),搭配註解,也會是不錯的方式。

除了可以套用程式設計思維,寫SOP時也可以套用軟體工程的作法。或許SOP比較適合採用敏捷(Agile)與反覆式(Iterative)的開發方式。因為SOP在執行之後才會發現缺失,就可以繼續進行修正補強。別忘了每次的改變,記得要做好版本控制。

UML(Unified Modeling Language,統一塑模語言)支援許多種圖,幾乎每一種圖都可以在SOP內派上用場。UML可以幫助SOP作者編寫SOP,也可以幫助讀者理解SOP。

和程式設計一樣,寫SOP不能光靠語言和邏輯,還需要特定專業領域的知識。

例如,寫3D繪圖的程式,必須先了解3D圖學的許多知識。對於SOP來說,專業領域可能是會計、稅務、法律……等。所以編寫SOP時,最好與了解該領域的人一同合作。

OO的封裝和繼承也可以套用在SOP,利用封裝將資源和動作集中在一起,利用繼承將某些方法進行擴充或修改(例如「同A作業,但步驟3更改如下」)。但是OO的多型似乎不可能用在SOP上,所以還是得大量使用switch/case的語法。

另外,邏輯式編程的作法似乎相當適合用在SOP,因為大部分的人都有足夠的邏輯能力,可以理解與判斷。使用邏輯編程可以讓SOP的編寫較簡潔。當一個資源許多人搶著用時,你就可以引進Concurrency編程的方法。

寫程式時,我們要多使用變數,而不是將資料寫死在程式碼中,寫SOP也是一樣,例如,你不應該在SOP內寫「把這份資料交給陳水扁」,而是應該寫「把這份資料交給總統」。畢竟,陳水扁總有下臺的一天。

有許多程式工具可以幫助我們檢查程式中的語法/語義錯誤、Dead Code,甚至Dead Lock、效能瓶頸。但是SOP卻沒有這樣的檢查工具,一切只能靠SOP編寫者的經驗。

所幸,人和程式不一樣,人是有彈性的,許多SOP的缺失可能會因為人的介入,能視情況應變而不會發生問題。但是,好的SOP並不能保證公司營運不會出問題,許多公共安全意外發生的原因,是檢修人員偷懶,沒有確實按照SOP規定的步驟進行維修所造成。

因此,雖然寫SOP與寫程式相似,但兩者終究不同,SOP的執行者是人,不是機器。所以寫SOP時,一定要充分考慮到人的因素,納入人的彈性,排除人的偷懶(或自作聰明),才會寫出真正實用的SOP。

作者簡介:
蔡學鏞-技術顧問
清華大學資訊工程碩士,曾任華碩集團軟體工程師、元智大學資訊系講師、美商歐萊禮出版社技術編輯、臺灣微軟特約專欄作家。

熱門新聞

Advertisement