前兩周提到，我們談到流程規劃時可以大略的分成「一般性的產業」，或是「專案導向的產業」來做思考。 因為在面對這兩類產業中，我們對於流程的定義很可能會有些不同。 在前者，我們應定義「產品導向的流程」(怎麼做)以及「管理支援流程」(碰到特殊事件該怎麼辦)；而對於後者，我們則增加了「專案管理的流程」(專案進行中我們怎麼管，以及可能會動用到哪些流程)。
那在接下來的兩周，我們或許先來談談一般性流程的製作原則；這議題談完後，則再來談談專案性質產業流程的製作與管理。
一般性的商業活動，大多重複性高。 也因為重複性高，才有制定成標準作業程序(SOP, standard operation procedure)的意義。 如果有些程序(如專案性質重的)定下來後每次做法可能差異都很大，那表示這些做法無法標準化，那就沒有勉強制定的意義了(但也還有解決的方式，這我們留著之後探討)。 而一間組織之所以會考慮花時間制定這類的東西，主要的目的並不是找員工麻煩，而在於若能透過流程的標準化，將可以達到「一致的溝通」、並促成「經驗傳承」、以及開啟「持續改善」的可能性。
很多組織小的時候，大家工作多靠默契。 畢竟一開始會一起工作的夥伴不是多年的朋友，就是對那領域有興趣的專才組合在一起的團體。 大家都熟知這領域的東西，所以你跟我說甚麼東西搞定了，我大概就知道後面該怎麼接手。 但是當組織開始成長、人數多了、距離遠了，將會有各式各樣的人出現。 這些人可能年長、可能年幼、可能資深、可能資淺、可能有熱情沒技術、也可能有技術沒熱情只是想找個工作混口飯吃，所以組織開始有各式各樣的人員出沒。 一些平常老手覺得顯而易見、簡單莫名的東西，但是對於從沒做過的新人來說，他就是真的不懂。
在這樣的情況下，一個方法是當有新人來時就都派人把所有新人該知道的狀況解說一遍。 但是當組織大時，事情可是複雜得要命。 有些東西解說者可能忘記，或有些東西可能並無法簡單的講清楚。 到最後，主管可能很累。 因為有人會動不動得來請示：「我要報價給客戶，該怎麼做？」
「A客戶說要試用版，我可以給他嗎？」
「B客戶剛剛打電話來說為何我們不給他試用版？ 我該怎麼回答？」
既然如此，最簡單的方式就是把能規則化、能標準化的東西事先定義清楚，甚至落實於文字或圖形。 這樣雖然不能避免還是會有模糊地帶，但最少新人有個學習的出發點，一些明明很簡單的事情也就可以自己找出資料，一些可以自己判斷的事情他也就有個判讀的依據與範圍。
其次，流程標準化後，也便於大家溝通。 當下次有人跟我說：「Joe，你去看看進度如何時」，我會很清楚知道「進度」是甚麼意思。 收到這樣的指令我該做甚麼，我該取得哪些數據、從哪裡取得、跟誰取得、而我該做哪些計算、怎麼交付成果給命令我的人或下游的工作夥伴。 換句話說，我將更清楚的知道甚麼是「被期待」的產出，甚麼是自己真正該去做的工作，大家也有更一致的語言。
當然，讓資深的人員像母雞帶小雞的在工作中帶領新人也是個方式。 但這種口耳相傳的做法有個缺點，也就是當時間一拉長時，後面的老師搞不好自己學的也是錯的。 如小時候玩的傳聲遊戲(排一直線，每個人在後面那個人的耳邊小聲說話)，會隨著傳遞的次數呈現極大的變異，最後聽到的那個人可能理解的東西跟原本初始的東西已經天差地遠了。 那與其等到時候出了問題才來檢討，還不如一開始就把正確的做法清楚定義，並白紙黑字的描述下來。 比方說麥當勞麥香魚之所以好吃，並不是因為炸的人技術多好，而是麥當勞在流程上已經預先排除所有可能造成麥香魚不好吃的因素。 讓就算是工讀生只要照著步驟做也能做出OK的麥香魚。 唯有這樣，經驗才能傳承，才能據此展店或是快速的席捲市場。
那當這些東西都有了後，成員在技術精進後(或是有甚麼技術突破後)，可能發現有些步驟有個更有效率的做法。 那這時候，大家也有個討論的基礎。 大家都照著原來設想的步驟做過後，就可以來談說某個步驟是不是要調整調整，讓工作可以更有效率、杜絕一些浪費、甚至可以加些防呆的設計。 長久下來，大家手上就會有套非常棒的程序讓工作可以最有效率的完成。
好，那如果要訂這樣的東西那該怎麼做呢?
我個人會建議應把握最重要的一個原則是：架構應由粗到細，由上而下。
如果某天你要從台北到紐約去開會。 當在規劃行程時，恐怕你不會直接寫說：
1. 我先出大門
2. 再搭電梯下樓
3. 走20米右轉
4. 敦化南路直走到忠孝東路
5. …
…
88. …
89. 轉到4G登機門
90. 上飛機
91. 找座位
92. ……
我想很少人可以一下子切入細節，然後用這樣的方式做出完整行程規劃的。
大部分的人，很可能是先做大方向的規劃，比方說：
- 台北到香港
- 香港轉機到舊金山
- 舊金山到紐約
然後才來細想：
1. 台北到香港的行程中又包含：
- 公司到火車站的行程
- 火車站到客運總站的行程
- 中正機場內的行程 (通關、上機)
2. 香港轉機到舊金山的行程則包含：
- 香港機場轉機路線
3. 舊金山到紐約則應該要：
- 舊金山機場轉機路線
- 甘迺迪機場出境路線
- 機場開車到目的地的地圖
像我們看地圖一樣，先看大的輪廓
慢慢放大
再放大，最終才會看到街道，看到巷弄，看到更細微之處
規劃行程時我們會這麼做，那流程規劃時其實也是一樣的道理。
假設我是一間餐廳的老闆，那我若想把自己的商業環境標準化時。 第一步，我會先試著列出公司最主要的常態性工作(如開店、打烊、清掃、採買、庫存、用餐)，以及觸發性的事件(客訴、火警、鬧場)。 這裡看營運環境的大小不同，可能有人在此就會先碰到問題了。 一個問題是大家不知道到底有哪些流程，另一個則是當可能該制定的流程列出一堆後，無法決定到底哪些該被描述與紀錄。
前面這問題，我建議的做法是透過腦力激盪(Brainstorming)，可能根據產品線、可能根據部門、或可能根據營運項目列出在白板上。 然後再來取捨到底哪些是必須要被完整定義的主要的流程，哪些則可能不是日常營運會常態碰到，但是萬一事件發生時，必須要知道如何處理的特殊事件。
至於到底哪些流程是必須要被描述，則通常是根據組織的願景來做策略考量，並跟相關對應的流程產生連結。 這意思是說，組織的產品線也好、做的事情也好、日常的營運工作也好，應該是要能跟組織中長期的目標能對應。 舉例來說，今天如果我餐廳的願景是要提供一個大家能享用高級中華料理的地方，那西式調酒、或是刀叉擺放的流程與規則我就不應該花時間去思考與制定，因為那將是浪費時間。
而當確定哪些東西是要開始規劃細部流程時，接下來就可以讓該工作相關的同仁一起來討論，並請熟悉的人員來各自描繪他現在的做法。 (這稱為As is)
如果很簡單，那做事的人可以直接開始繪製；但如果大家看法有所分歧時，也可以透過下面這個工具：
沒錯！ 這東西叫做便利貼。 便利貼在此的用法可以是這樣：大家可以先把完成工作或是產品的步驟寫下來。 如有必要，也可以把完成該步驟的特殊需求(如input/output)、或是所需的職能寫在上面。 然後因為便利貼有黏性，我們可以把這些步驟貼在牆上討論，並在小組間討論實際上是怎麼樣順序施做的。 而便利貼的好處在於，當大家有歧見時，可以撕起來調整順序；而等大家都有共識時，才將其述諸文字。
這方式有個名字，叫做Storyboarding。 是的，這就像做動畫的分鏡腳本一樣。 只是動畫的分鏡腳本是把劇情一格一格的展現出來，但做流程時，我們是把工作的步驟，以格子繪製，或是以便利貼的方式順序列出讓大家一目了然的知道到底工作的順序步驟為何。
Storyboarding 單純畫在白板上的描繪紀錄
那訴諸文字又該怎麼做呢?
假設，我把客人到達餐廳後，點餐到離開的流程定義清楚後。
我可能先畫成如下圖的形式：
只是，定義成這樣難道就結束了嗎？
很可能沒有。因為帶位也好、點菜也好可能都還有它的複雜性。 可是如果把這些複雜的結構都一次畫上來，整個架構可能太複雜了。 對於日後閱讀的人而言，可能會很可怕。 這裡我個人覺得不錯的方式是將細節另外分頁處理。 從上圖的格子中，可能有人注意到，出菜的下面有個3這樣的數字，這裡我是用來表示一個章節的參照。 大家可以把這流程圖以前面敘述的地圖來想像。 上張圖是很粗的流程，而更細的流程將可由此繼續放大展開。 意思是說，如果我把這流程其中的一部分放大了來看：
點菜下面其實還可以再藏個更細的小流程圖。 所以當我們再繼續放大後，可能類似下圖：
所以每個章節我會描述每個主要工作是甚麼意思，需要甚麼Input、又可能產生甚麼Output。若還有甚麼更細的流程該被描繪的話，也可以在此章節中細述。舉例來說，上面這張圖很可能就會是我在流程手冊的章節3內容。 事實上，就算到了這地步，每一格子也可能還有更細的細節，所以我們還可以視需要再繼續對每個項目展細。 而這展細的動作可以是更細的流程(也就繼續放大)；也可能僅是要點式的提醒與說明。 所以對「介紹菜色」這工作而言，可能已經夠清楚了，僅需要放些注意事項在「3.2」的子章節中即可，如：
點菜時應注意
1. 保持微笑
2. 先從最貴的主餐開始推薦
3. 問客人是否要喝酒
4. 問客人是否吃素
5. 保持氣氛熱烈
6. 不要隨便定義客人的關係
當這樣的東西定義完備後，每次新人到來時，訓練時就可以簡單的把這流程圖給他看，並照流程圖以及注意事項的內容來做職前訓練。 如此，他就可以知道在招呼一個客人時應該有哪些主要的步驟、有哪些注意事項、而且每次新人學到的都將是一致的東西。
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
