流程系列四之 如何撰寫真正有用的SOP

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

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

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

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

 

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

餐廳主SOP

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

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

1. 背景說明

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

2. 名詞的解釋

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

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

3. 大綱

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

4. 細部流程

每一子流程下的展細。 如點菜的細部流程:
細項SOP 

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

1. 細部流程的說明

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

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

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

Swim Lane 

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

只是要這樣做時,有幾點必須在設計時要仔細考慮,也就是我在文章開頭處所寫的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之中,就可以簡單的完成第一次的流程規劃手冊了。

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


踏出第一步之後呢?

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

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

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

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

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


工作流程
主流程,以及下面的細部流程架構

 

 2007
包含了Swim Lane的流程圖


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

 
2008 
另外建立的Data Flow Diagram


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

2009 
(Entity Relationship Diagram, 軟體模組間哪些資訊該被傳遞,背地裡這些欄位將會與個別流程聯結在一起)


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


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

 
 
若有轉貼需求,請來信討論。 轉貼時禁止修改內容及標題、須保持所有連結、禁止商業使用,並且必須註明原文標題、連結、及作者訊息。
覺得這篇文章好嗎? 請分享給您的朋友
歡迎「讚」一下我們的粉絲專頁,接收最新文章!
張國洋 Joe Chang

現為識博管理顧問執行長,也在台灣百大上市櫃公司擔任管理講師與專案顧問。歷年客戶包含工研院、台積電、廣達、富智康、光寶集團、台灣大哥大、遠傳電信、中鼎工程、建國工程、台橡公司、大同公司、三陽工業、TVBS、特力屋集團、城邦集團、誠品集團等。 為了對抗雙魚座的感性,一直在努力強化理性思維與邏輯思考。 相信邏輯發展能解構任何事物,並讓我們找到合宜的人生策略與方向。

Joe G+ ICON Joe LInkin ICON

21 則讀友回應

  1. Larry 2013-12-23 18:28:03 第 21 則

    很棒,特别是举的几个例子

  2. jujahau 2012-05-09 14:27:07 第 19 則

    是的,我想就如同J大您所說的,依定義來說流程管理在專案管理之上。
    當初接觸的SOA提供的概念,主要目的是讓軟體業者能進行敏捷式開發、透過重用有效降低工程師的開發工時。
    概念上他會將流程與元件/功能進行拆解,從最上層的Domain到最底層的Function一個一個的拆出來,但在拆解期間會發現顆粒度的問題,到底是要拆細一點或是拆粗一點,這一邊就有點像是流程(Domain)與專案(Function或者是Component)之間的關係,不過在串接的時候(有時在拆解時就會發生)經常會發生類似瞎子摸象的窘境,導致之後不斷的調整,哀~拆解/串接真的是一件相當不容易的事情,哈~BJ大大有出版這類問題solution的課程嗎?對了,IBM文件其實是叫做SOMA..SOA則是一個概念。

  3. jujahau 2012-05-09 10:28:34 第 18 則

    看著這篇,忽然想到研究所接觸IBM所制定的SOA相關文件,原來裡面的內容從專案管理的角度出發。
    想當初,接觸到stakeholder這個字,根本不知道是啥意思,查字典"賭金保管人"那是啥東西,就卡卡卡住了!直到出了社會,接觸了BJ大大們,才豁然開朗,原來是"利益關係人"....當初研究SOA時,其實應該先深入了解專案管理(不過,當初上學校內專案管理的課程也沒提到相關名詞阿..囧)

    • Joe Chang 2012-05-09 12:05:28

      就學理定義而言,流程管理其實在專案管理之上
      畢竟公司除了專案以外還是有其他一般維運的事情
      而好的企業流程必須把兩者完整串接起來

  4. Kevin Lai 2009-11-01 14:44:56 第 17 則

    很好奇的是,有人會針對一項專案訂出一個SOP嗎?

    以我們公司而言,SOP只會訂出一個很大的方向
    也就是提到一個任務應該做了哪些事才算是完成
    但是絕對不會要求你要怎麼做
    每個案子在撰寫計畫的時候可以自己定義作法

    另外SOP會有對應的計畫範本
    如果專案本身沒有太異於常態的
    大概80%~90%的內容可以不用修正
    直接加上專案獨特的資訊就可以使用
    對與第一次接到撰寫計畫內容的初階主管滿有幫助的
    畢竟熟知一件事情通常是怎麼運作的
    跟要寫出一份計畫讓大家都遵行是截然兩件不同的事

    最後就是SOP其實不是不能更動的東西
    譬如說公司原本的歸檔方法是紙本,現今導入了電子系統
    那原先的SOP必定要跟著修正

    只是SOP一多也有缺點,幾十份的SOP
    『理論上』關於自己的部分都要閱讀完畢
    偏偏又不可能預留時間讓你上班時閱讀
    結果記錄上每個人都看過了
    實際上也是流於形式
    這一點不知道有什麼比較好的處理方法

    • Joe Chang 2009-11-02 22:22:10

      如果那專案夠大,那步驟夠重要,其實並無不可。
      (甚至成立一間獨立的公司來接案都可能,定個SOP更不算甚麼)


      但大部分的時候,實務的做法確實如您所說
      常常只會定義較大方向的架構
      而案子則根據自身需要,由PM或是負責人細定做法


      至於SOP落實的部分嗎
      我自己偏見以為,還是稽核這件事情最有用....