1. 架構應由粗到細，由上而下
2. 清楚易讀
3. 每一步驟的介面切割清楚，定義明白
4. 日後好管理
5. 防呆設計
而上周談了第一項，也就是SOP制定及思考時，我們應從抽象的架構開始，然後逐漸往下展細。 這意思是說，不需要勉強把所有的細節、判定、負責人員、甚至說明都要在一張圖上表達。 畢竟都放在一張圖上雖然很完整，但是相對東西多時將很嚇人，對於溝通或是概念傳遞這目的而言，反而未必有幫助。 很可能會讓第一次接觸的人在面對眼花撩亂的資訊時整個傻眼，更別說還能理解到底實際該怎麼做。 (很可能光要找到起點就要花大把個鐘頭了)
為求讓任何人都能簡單的閱讀，我反而會建議第一次做的時候，把整個SOP已3D結構的方式來製作；把這當成一本書的章節來寫。 一開始是大綱以及概略介紹，而每一個概略的流程如果還有細節則做一個標註(如參照的頁碼或是章節編號)，以便在後面的章節中做細部描述。 因此，每一個流程如有需要都可以往下展細；細部的說明(如input/ouput，以及流程內的procedure)都可以在另外的頁面查詢以便獲取更深入的了解。
這樣切割方式的好處在於，閱讀上可以非常簡單。
為求讓任何人都能簡單的閱讀，我反而會建議第一次做的時候，把整個SOP已3D結構的方式來製作；把這當成一本書的章節來寫。 一開始是大綱以及概略介紹，而每一個概略的流程如果還有細節則做一個標註(如參照的頁碼或是章節編號)，以便在後面的章節中做細部描述。 因此，每一個流程如有需要都可以往下展細；細部的說明(如input/ouput，以及流程內的procedure)都可以在另外的頁面查詢以便獲取更深入的了解。
這樣切割方式的好處在於，閱讀上可以非常簡單。
以上周提到的招待餐廳客人的主流程而言，如果我是新來的服務生，我可以順著這個主流程閱讀。 任何不懂的地方都可以往後翻到對應的章節取得細節資訊。 舉例來說，如果我順著看下來後，發現自己對點菜的部分不熟時，我可以往後翻到第2.2節來看細節。 看完後如果對飲料這流程又不太懂時，則可以再翻到2.5節來看細節。 如此我就可以既了解全貌，又可以在有需要時掌握細節，而不會被過度的資訊塞滿。
那如果以這樣的方式來做SOP的描述時，為求清楚易讀，我會建議最少包含這樣幾個章節 :
1. 背景說明
說明這流程是甚麼，為何存在、服務的對象可能是誰、期待的結果會是甚麼、如果這流程是為了支援特定目標、願景、策略、或是更大項工作的一部分時，也應在此描述那更巨大的東西為何。
2. 名詞的解釋
一些在流程手冊中所描述的名詞之定義。
這之所以重要，在於工作上溝通誤解的一個常見原因在於我們的用字用語未必所有人的解讀都一致。 舉例來說，飲料是甚麼？ 咖啡、茶、果汁或許是。 可是酒算嗎？ 湯算嗎？ 水算嗎？ 檸檬水可能是招待的，可是如果客人要沛綠雅呢？ 所以，定義是有所必要的。
3. 大綱
主要流程，以及說明每一主要流程的進入條件與離開條件。 (怎麼樣啟動帶位、怎麼樣確定帶位完成了) 此外流程跟其他流程或工作又有甚麼相互關係，在此應該做個簡單但清楚的說明。
4. 細部流程
每一子流程下的展細。 如點菜的細部流程：
這可能存在也可能不存在，完全仰賴實際複雜度而定。 複雜時甚至還可能再往下展細。
* 細部流程的說明
每一子流程的詳細說明，可能包含下列內容
- 另一個流程圖
- 條列式說明
- 細節名詞的說明
- 注意事項 (查檢表)
- 該流程所需要使用的表格
- 該流程所需要檢附的表單格式
此外，拆解下來的細節，如果可能會跨越多個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
而這樣的Data Flow Diagram定義好後，將可以跟既有流程相互串接。 我們將可以建立出軟體開發所需要的架構圖，在裡頭定義不同模組間所需要輸入或輸出的欄位以及名稱，這樣就可以更簡單的讓系統開發者了解實際的資料運作以及使用者需求。 也可以讓組織中的軟體開發、IT管理更緊密的與實際流程結合。
(Entity Relationship Diagram, 軟體模組間哪些資訊該被傳遞，背地裡這些欄位將會與個別流程聯結在一起)
起步總是困難的，但一但有一個版本後，後面的可能性將會是無限大。 對於組織的壯大而言，也是必須被踏出的第一步。 也因此，雖然會有些辛苦，但為了長期的組織精進而言，這恐怕真是很難避免的工作。
部分流程圖截取自http://www.visual-paradigm.com/
延伸閱讀
Bookmark:
Shorten Url
Recommend to Front page
關於大家一直詢問的課程
都怪我書看太少了...
是否可提供sop範本
您好,我們公司只是個小公司,但最近想幫公司寫個SOP,不知是否有簡單範本可以提供參考呢?? 謝謝
你好
那個 我可以那些流程圖嘛因為我不會用WORD製作耶 !
可是我要先交一分初稿給我們老師看 !!
不好意思 可以嘛 !?
聽不太懂
煩請撥空為我解惑,謝謝!
老師是韓國人
我们是用手畫這些event,method,還有就是有那些swim lanes
老師發還作業時,先告訴我們'I am broken heart!'(挺幽默的,師生互動還不錯)
作業都亂畫,邏輯能力太差了,問題是第一次畫要畫甚麼?
那時候白天上課,晚上上課,上完課去China Town報到吃宵夜,生活還真是充實
不過我就是喜歡公務員式的公司體系
資源充足,體制健全
也不要一竿子打翻一船人
效率就代表進步嗎
可以單一使用科學進步決定社會的進步嗎
現代人有許多憂鬱症
在亞馬遜河的土人大概不會有此問題
因為我最近上了一些文學批評的課
很自然就有一些想法
尤其我又是研究女性主義
老師其實是希望女性主義及種族主義已經很多人研究
其實可以研究馬克斯主義以預防資本主義的盲點
我只是覺得現代人也很辛苦
太多的消費造成各種的壓力
也許可以放慢腳步
學習Back to nature
人與人之間的疏離感是這20世紀以來很大的問題
因為每個人都不斷追求自我的成就
很容易隨波逐流追求名利很權利
這樣功利主義的社會
是不是大家的心靈空間都相當枯竭
人與人之間的諸多計較讓生命變得乏善可陳
我可以體會一位主管希望維持performance的重要性
不過將這一套要用到公務員的機關
大家想進就是可以過安穩的生活
不用受資本主義的荼毒
甚至用到婚姻都有些令人心痛
婚姻應該是要受到祝福
讓 一個人更為完全的環境
怎麼又被資本主義入侵了
如果愛情存在
那束縛就不存在
不是嗎?
又可以鼓勵大家結婚
也許是不錯的創新法令
內容是甚麼呢?
我看到有些離婚的原因是,無可甚 麼的差異
有些婚姻是不交談形同陌路,但是又因為小孩的緣故維持婚姻關係
這大概一年一簽也沒幫助了
內容是什麼好呢?
1.男方體重不能超過多少,女方體重不能超過多少
2.男方襪子沒有亂丟,女方化妝品沒有亂放
3.雙方愛情的比例不能少於多少%,如果是負數也要承認,婚姻不再續約
4.雙方外遇的次數不能超過1,基本上0才是可以忍受的範圍
以上各項關係如果符合合約精神,婚約自動續約,否則雙方應合意予以解約,不得有怨恨或報復的心理.
只是離婚的要件,法律有明文規定了.
也許我期末可以拿這問題作報告
婚前協議是不是有法律效力？
以上各項關係如果符合合約精神,婚約自動生效,否則雙方應合意予以解約,不得有怨恨或報復的心理.
不是比較能維持婚姻
離婚率就會降低嗎?
如果要落實法律
婚前協議已經略有所聞,
歐美ok.但在台灣似乎仍被視為違反善良習俗
有了這種協議雖然可能造成一些人結婚的意願降低
但是對恐婚症的人(現代人一般很晚婚,似乎找不到結婚的必要性)
可能覺得風險可以評估
也有停損點
錯誤婚姻不會意外造成人生的枷瑣或遺憾
如果協議可以看到婚姻的本質
也就會有鼓勵的作用了
這樣會忽略掉人性和家庭核心的價值觀...
婚姻制度也是有演進的狀況,
從中產階級崛起開始
主流已經是自由戀愛結婚囉~
在民主自由的國家
婚姻幾乎沒那麼多約束了
倒是印度燒妻還挺可怕的
這種狀況
父母就該保護女兒
不要將女兒往火堆送
不過我問我的印度朋友有關燒妻的習俗
我朋友告訴我
那只有在鄉下的village才有
法律是死的
人是活的
法律也會隨時代的改變而演進
所以我才會考慮到協議結婚這種可能性
這樣的個人化合約
就不會讓婚姻綁住個人的自由和成為任一方報復的手段
由於曾經上過專案管理的課，因緣際會下得知你的blog，分好幾次拜讀你的blog內容，目前一直在思考一個問題：創意型的線上遊戲設計企劃的專案工作，也能夠制定SOP嗎？這是我感到非常疑惑的地方，畢竟這種專案比較無法像是說一是一的機械化流程，例如某種新創意系統的規劃生成。那麼，對於此類型專案你對於SOP的制定有沒有什麼建議？
我現在從事的是藥品上市前後的臨床試驗產業
每一個案子的治療領域、合作醫師/醫院、試驗者需求人數以及時間長短都不一樣
所以是以專案的方式執行
公司滿滿的有很多SOP，但是與格主介紹的方式不同的地方是
比較著墨在不同角色之間的責任，以及歸屬關係
(例如專案的執行者、地區主管以及PM的角色跟責任為何)
每件事的因果關係並沒有格主舉的例子這麼明顯
SOP內容的例子如下：
譬如如何做平日的監測可能是一個SOP
如何結束在一家醫院的試驗是一個SOP
如何寫一篇報告，需要顧及哪些重點，需要多久內完成，由誰來review是一個SOP
如何交接工作是一個SOP
我的想法是，可以先從一些重複性很高的流程著手
這樣當一個人被指派某種角色時
可以從SOP來瞭解自己應該完成的任務跟角色
利用SOP來讓還抓不到頭緒的人有個範本，快速進入狀況
但是裡頭的東西是大方向而沒有寫死
這樣在應用到不同的案子上時，才不容易有不適用的狀況
SOP的應用
其實我自己的經驗來看，我覺得如果有一個很清楚的SOP很重要，
好的SOP不見得能帶你上天堂，不過很制式但「缺乏共識」的SOP
絕對會讓你很快就陣亡…哈。
我遇過那種sop訂了亂七八糟的專案…，
而且最遭的是，你明明知道這sop問題很多，
但卻還是得照著做…哈。
也遇過SOP設計得很好，很符合公司現況的，
哇嗚，真令人很感動，印象很深刻!~有什麼問題馬上就能解決，真好。
以我們公司而言，SOP只會訂出一個很大的方向
也就是提到一個任務應該做了哪些事才算是完成
但是絕對不會要求你要怎麼做
每個案子在撰寫計畫的時候可以自己定義作法
另外SOP會有對應的計畫範本
如果專案本身沒有太異於常態的
大概80%~90%的內容可以不用修正
直接加上專案獨特的資訊就可以使用
對與第一次接到撰寫計畫內容的初階主管滿有幫助的
畢竟熟知一件事情通常是怎麼運作的
跟要寫出一份計畫讓大家都遵行是截然兩件不同的事
最後就是SOP其實不是不能更動的東西
譬如說公司原本的歸檔方法是紙本，現今導入了電子系統
那原先的SOP必定要跟著修正
只是SOP一多也有缺點，幾十份的SOP
『理論上』關於自己的部分都要閱讀完畢
偏偏又不可能預留時間讓你上班時閱讀
結果記錄上每個人都看過了
實際上也是流於形式
這一點不知道有什麼比較好的處理方法
Comment Permissions: Allow commenting