上周提到，在製作標準化的流程時(也就是SOP)，我個人建議把握下列幾個原則：

1. 架構應由粗到細，由上而下
2. 清楚易讀
3. 每一步驟的介面切割清楚，定義明白
4. 日後好管理
5. 防呆設計

而上周談了第一項，也就是SOP制定及思考時，我們應從抽象的架構開始，然後逐漸往下展細。 這意思是說，不需要勉強把所有的細節、判定、負責人員、甚至說明都要在一張圖上表達。 畢竟都放在一張圖上雖然很完整，但是相對東西多時將很嚇人，對於溝通或是概念傳遞這目的而言，反而未必有幫助。 很可能會讓第一次接觸的人在面對眼花撩亂的資訊時整個傻眼，更別說還能理解到底實際該怎麼做。 (很可能光要找到起點就要花大把個鐘頭了)

為求讓任何人都能簡單的閱讀，我反而會建議第一次做的時候，把整個SOP已3D結構的方式來製作；把這當成一本書的章節來寫。 一開始是大綱以及概略介紹，而每一個概略的流程如果還有細節則做一個標註(如參照的頁碼或是章節編號)，以便在後面的章節中做細部描述。 因此，每一個流程如有需要都可以往下展細；細部的說明(如input/ouput，以及流程內的procedure)都可以在另外的頁面查詢以便獲取更深入的了解。

 

這樣切割方式的好處在於，閱讀上可以非常簡單。

以上周提到的招待餐廳客人的主流程而言，如果我是新來的服務生，我可以順著這個主流程閱讀。 任何不懂的地方都可以往後翻到對應的章節取得細節資訊。 舉例來說，如果我順著看下來後，發現自己對點菜的部分不熟時，我可以往後翻到第2.2節來看細節。 看完後如果對飲料這流程又不太懂時，則可以再翻到2.5節來看細節。 如此我就可以既了解全貌，又可以在有需要時掌握細節，而不會被過度的資訊塞滿。

那如果以這樣的方式來做SOP的描述時，為求清楚易讀，我會建議最少包含這樣幾個章節 :

1. 背景說明

說明這流程是甚麼，為何存在、服務的對象可能是誰、期待的結果會是甚麼、如果這流程是為了支援特定目標、願景、策略、或是更大項工作的一部分時，也應在此描述那更巨大的東西為何。

2. 名詞的解釋

一些在流程手冊中所描述的名詞之定義。

這之所以重要，在於工作上溝通誤解的一個常見原因在於我們的用字用語未必所有人的解讀都一致。 舉例來說，飲料是甚麼？ 咖啡、茶、果汁或許是。 可是酒算嗎？ 湯算嗎？ 水算嗎？ 檸檬水可能是招待的，可是如果客人要沛綠雅呢？ 所以，定義是有所必要的。

3. 大綱

主要流程，以及說明每一主要流程的進入條件與離開條件。 (怎麼樣啟動帶位、怎麼樣確定帶位完成了) 此外流程跟其他流程或工作又有甚麼相互關係，在此應該做個簡單但清楚的說明。

4. 細部流程

每一子流程下的展細。 如點菜的細部流程：
 

這可能存在也可能不存在，完全仰賴實際複雜度而定。 複雜時甚至還可能再往下展細。

1. 細部流程的說明

每一子流程的詳細說明，可能包含下列內容 ：

1. 另一個流程圖
2. 條列式說明
3. 細節名詞的說明
4. 注意事項 (查檢表)
5. 該流程所需要使用的表格
6. 該流程所需要檢附的表單格式

此外，拆解下來的細節，如果可能會跨越多個Interface Party時，亦可以透過所謂Swim lane 的方式來展現。 Swim lane顧名思義就是游泳池的水道，在流程圖的繪製中，每條水道用來代表一個不同的Interface party。 因此我們可以把流程放在不同水道中，以代表工作在不同單位中傳遞的情形。

 

所以，若能透過這樣的架構，那就可以很清楚的呈現所有的資訊。 就算只是新人，也可以快速且簡單的掌握他應該要知道的資訊。

只是要這樣做時，有幾點必須在設計時要仔細考慮，也就是我在文章開頭處所寫的3，4，以及5這三點。

每一步驟的介面切割清楚，定義明白

當組織開始龐大後，一個主流程很可能不會只是一個人做，而是需要多人合作以順序完成。 這時可能一小組的人在負責主流程下的某單一工作，如一組人負責帶位、一組人負責點菜。

也因此，制定流程時，我們該把工作的Interface(介面)預先規劃並花些時間來思考：以求每一工作的「切斷點」可以很明確的被定義，而不會跟前後工作牽扯不清。 不會有某人認為他的部分似乎做完了，但是後面接手的人卻以為那應該是之前就做好了的，而只有客戶很無辜的覺得沒有被好好照顧而到處抱怨。

拿「帶位」來舉例吧，是定義「告訴客人坐哪裡」，就算是工作結束？ 還是應該要「等確定客人坐定了」，才算工作結束？ 如果帶位、點餐、上菜整串都是一個人做，那切斷點怎麼定似乎都沒差。 但如果帶位與點餐可能是不同人做的時候呢？ 一但定義不明確，中間可能就會有服務上的潛在問題。 比方說我告訴客人去坐角落的位置，可是點餐的人知道了嗎？ 客人會不會誤會了結果坐錯位置？ 同時會不會有別組帶位的人也指派這位置？ 或是客人會不會不聽話自己跑去坐別處？ 只要有任何一項發生，而後續點餐的人又沒找到他們，很可能客人坐定了好久都沒人來點餐？ 這時候不就糟糕了？

所以工作的Interface必須要仔細思考，不能認為目前都是同一個人做所以隨便訂一訂就好，因為就算都是一個人做，也可能哪天他必須在某件工作結束後請別人代勞(或請假)，他也得知道怎麼切斷、怎麼延續，後面接手的人也該知道他得怎麼接手，得期待甚麼東西前面會做好。 而長期而言，定義清楚後，人員多面向的技能訓練也可能降低，這樣就算只是工讀生，只要當下能充分知道自己的部分該注意甚麼、該產出甚麼，也可以做的似模似樣。

日後好管理

另一個必須被思考的，則是日後管理上的便利性。 也因此，SOP訂定要從日後管理容易、降低人員衝突、以及提高工作成功率為出發點。 不要訂出不切實際，或是過份理想的流程。 如果人員根本日後無法配合，或是實際工作根本就不是照著這樣的步驟做，那花時間製作這種SOP只是浪費時間罷了。

再來，流程的訂定、或是拆解的方式，也涉及會計的攤列容易度。 如間接成本如何攤入，是要走怎麼樣的會計制度(如Job Order，或是ABC)，需不需要評估特別的成本動因(合理的攤列基準，如是用人力多寡來分攤、還是出貨數量、還是機器開動時間等)，這對於工作的切割方式、或是切割多細也都有影響。

此外，切割後日後是否能很容易掌握人員的產出？ 是否方便定義進度？ 是否能收集到管理上有意義的數據？ 還是日後管理上反而變得更模糊、更無法掌握全貌? 這些也都是在定義SOP時應該要思考的一些重點。

防呆設計

最後一個絕對必須要考慮的，則是流程間的防呆設計

SOP訂定的一個目的也在於檢視目前的作法並避免錯誤。畢竟一些工作很可能會在不注意下遺漏或是發生錯誤，所以定義SOP時也要不斷的思考該怎麼設計才能避免掉這類錯誤。 比方說ATM提款時，很多人會領到錢後就忘記把金融卡拿回來。 所以或許有人注意到，現在所有ATM的操作流程，一定都是先出金融卡、等確定使用者拿到卡「後」，才會開始吐鈔。 這樣設計的原因在於，既然是去提款很少人會忘記取錢。所以等確定你把卡片拿了後，機器才進行你最關注的那個動作 ─ 也就是吐鈔；若是先吐鈔，有人會開心的拿了鈔票然後就走人了，完全沒注意自己金融卡根本沒拿走。

日常流程設計也該如此思考，如果某些工作很容易忘記、疏忽、或是做錯，那有沒有甚麼方式可以改變來避免錯誤呢？ 比方說提供一個查驗表？ 調整施做順序？ 改良表單？ 或是從分散做改成集中做？ 或是集中做改成分散做？ 甚至可能還要實驗一下才知道怎麼最好。

舉例來說，點菜後假設有餐點與飲料，一種流程設計方式是把單子送到廚房，等菜做好了再把菜單拿到飲料吧台去準備餐後飲料。 但這可能有幾個地方會出錯，比方說廚房忙的時候，可能會把客人單子的順序弄混，以至於送到前面的吧檯時，早到的客人的單子其實被放到後面去了，以至於客人等很久都沒飲料喝。 也可能廚房根本把單子弄掉了或忘了送，以至於客人一輩子也等不到他的飲料。

那可能怎麼解決呢？

比方說，請服務生寫兩張單子？ 但服務生可能寫錯，可能懶的寫、可能錯把飲料單送到廚房、把餐點單送到吧檯？ 那或許把點菜單改成三聯的？ 所有的Orders都寫在同一張單子上，但是資料會複寫到後面，所以紅單就到廚房、藍單就到吧檯，這樣就算工讀生很笨發生錯誤率也多少可以再降低。 其他還可以思考，或許是不是改變動線、或根本不要分吧檯與廚房？ 或是透過電腦化來分類？ 逐步思考下，效率就可能不斷的提升，事情也才有可能越做越好。

該用甚麼工具

SOP的呈現方式可以用手來繪製、也可以用任何軟體工具。 我個人覺得，在第一次製作時，工具或是格式並不是最重要的部分，做事的方法與概念能正確傳遞給既有以及未來的成員才是最關鍵的。所以格式上只需要統一、能清楚傳達想要傳達的概念，其實也就足夠了。 如果第一次製作時對於相關流程建置概念或是塑模語言不熟悉時，不用特別勉強去學。 無論用Office軟體也好、甚至用Illustration這類繪圖工具也好其實都OK。 重點僅在於「不要畫死了」，日後還能調整其實就好。 (意思是說不要用小畫家做成純粹的圖檔，日後若根本沒辦法修改，那就尷尬了)

當然，一個最容易取得，又簡單好學的工具是Microsoft的Visio。 這是Microsoft Office系列中的一員，是個用來繪製向量圖的簡單工具。 除了流程以外，也可以做如組織圖、架構圖、資料庫架構、或是電路邏輯圖等。 那如果只是一般的流程圖，可以使用「基本流程圖」這樣的底圖來繪製，如果需要展現跨越Interface Party的關係，則可以使用「交互功能流程圖」這樣的範本來繪製。 繪製好後，再剪貼到Word之中，就可以簡單的完成第一次的流程規劃手冊了。

 
Visio的基本流程圖、以及交互功能流程圖的圖示

踏出第一步之後呢？

長期而言，當組織開始龐大，流程開始會越來越多。 可是這些流程是否還有存在的必要？ 這可能難以確定。 此外，流程的施做是需要很多支援與協助，舉例來說IT的支援、軟體的支援、人員的支援、管理的支援。 可是這些東西跟流程間的存在與互制關係為何？ 當組織一大後，將可能無法掌握。

這時候可以考量的是透過企業架構(Enterprise Architecture)的概念，把公司裡頭的所有流程、程序、架構、方向全部串接在一起。

從最早的策略訂定，連結到中短期目標、連結到組織圖、支持這些目標的產品線，以及達成這些產品線的流程，進而分析支持這些流程所需要的Input/Output、人員、職能、IT設備、軟體架構等。 最後把所有這些事情透過一個資料庫串接在一起。 這樣無論是流程分析、人力規劃、流程改善、商業方向轉換、或是軟體開發、硬體架構建置都可以由此來做更深入的規劃。 只是這東西就很複雜了，因為需要有專人操作流程建置軟體、尤其必須熟悉不同的塑模語言(如BPMN、UML、或是其他架構圖)，所以算是更高階的流程規劃之做法。

 
以BPMN (Business Process Modeling Notation)繪製的流程圖

但這樣做的好處在於，所有流程將能透過電腦的協助相互串接在一起。 可以做各類商業決策上的分析、或是軟體系統開發建置上的輔助。 舉例來說，你可以把公司特定產品線的流程架構建置起來，所有細部流程將可以跟上層的主流程聯結，或對應到組織的目標與願景確認工作本身是真的有所需要。 而若需要細緻時，則可以一層一層Drill Down的向下追蹤。

主流程，以及下面的細部流程架構

 

 
包含了Swim Lane的流程圖

以軟體開發為例，我們雖然定義了流程圖，但每個流程可能還有不同的訊息需要被交互傳遞與確認。 比方客戶要訂東西，可能是他自己上網輸入、可能是我們的人員幫他 Key-in。 可是Key-in到哪裡？ 需要他Key-in哪些資料(比方說姓名、地址、產品名稱、單價、總價、信用卡資料)。 這些資料又會怎麼被在不同流程中需求與傳遞？ 可能哪些軟體系統需要這些資訊(如訂單系統、出貨系統、地址系統、收費系統)，這些資訊系統需要的東西都相同嗎？ 如果要整合的話那甚麼東西會被共用呢？ 這可能需要另外的圖形來定義。

而這樣的Data Flow Diagram定義好後，將可以跟既有流程相互串接。 我們將可以建立出軟體開發所需要的架構圖，在裡頭定義不同模組間所需要輸入或輸出的欄位以及名稱，這樣就可以更簡單的讓系統開發者了解實際的資料運作以及使用者需求。 也可以讓組織中的軟體開發、IT管理更緊密的與實際流程結合。

起步總是困難的，但一但有一個版本後，後面的可能性將會是無限大。 對於組織的壯大而言，也是必須被踏出的第一步。 也因此，雖然會有些辛苦，但為了長期的組織精進而言，這恐怕真是很難避免的工作。

部分流程圖截取自http://www.visual-paradigm.com/

本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。