如何繪製業務流程圖接上篇《業務流程圖繪製流程分享(一)》，本篇將對上篇中間的第四部分——如何繪製業務流程圖展開更多討論。

本來寫完上篇，我發現沒有太多必要單純討論這一部分內容，因為對於很多人來講，缺的不是具體的做法，而是做這件事情的意義以及目標性的明確。

一旦對這件事情的意義和目標有深刻認同，那自然會產生較大的動力去研究How這個層次的所需方法和技能。

時間管理也如此，很多時間管理技巧牛逼的人未必能夠把時間管理做到位，因為內心克服不了強大的拖延症，而克服拖延很多時候是一個心理問題而不是技巧問題……咳咳，這不是在說我自己嗎？業務流程圖的表達的6個關鍵問題話又扯遠了，扯扯扯回來啊。

那麼為何還專門狗尾續貂（恩，原文也不見得是貂，成語有限，暫時湊合吧），又來這麼一篇How的枯燥乏味的文章呢？因為在上篇文章後，Heidi 確實在郵件裡收到一些郵件，詢問業務流程圖的具體操作指南——這東西很好，這東西很有用，但是似乎上篇都是講的“真實的道理”，但是具體怎麼做呢？我應該注意什麼呢？……所以，乾脆也分享一下吧。

但在書寫過程中，我發現一個大難題在於收集整理出更生動易懂又典型的案例。

不能使用工作中的實際案例，但是短時間又難以找到合適的。

所以本人對這部分不太滿意。

也希望各位讀到本文的人，能夠提供更多案例分享。

—————————————————-分割線——————————————————————————-1. 業務流程圖的“烹飪三部曲”在繪製業務流程圖前，思考如何精美，如何交互，使用什麼工具，都不應該是重點。

真正重點的是將業務流程圖的關鍵要素給搜集一番。

請試圖回答清楚以下幾個問題，否則不要開始繪製流程圖：o整個流程的起始點是什麼？整個流程的終結點是什麼？o在整個流程中，涉及到的角色都是誰？o在整個流程中，都需要做什麼事情？（可是是一個會議，可以是一個任務）o這些會議和任務是可選還是必選的？o分別產出什麼文檔？這有點像一個頭腦風暴，能夠幫助你將所需用到的原材料獲取到，有了這些“米”和“水”，那就不愁去如何烹飪了。

在專案管理中，上個月，我們也試圖給去規範化一個資料產品的設計開發流程。

這是一個資料產品的專案，而我們都不是對此很有經驗的人。

所以我們召集到所有相關的角色，組織了一次頭腦風暴及卡片分類法的混合式應用。

o讓大家頭腦風暴出自己認為在專案裡必須的節點，如“需求調研”，“需求分析”，“kick off會議”，“PRD撰寫及確認”，“資料評估”，“技術架構”，“DEMO繪製”，“指標演算法定義”，等等。

o在頭腦風暴過程中，主持人將這些節點都寫到白板上，等沒有新的節點誕生後，大家一起對節點進行合併歸類。

之後呢？o將這些剩餘下來的真正有價值的節點，撰寫到即時貼上，開始進行排序。

在排序過程中，可以由一個人先主導，他會按照自己的理解，將各個節點放到按角色排布的泳道中，並設計好先後的順序。

在他進行的過程中，其他人不斷進行提問：“這項任務開始前，需要什麼樣的條件？”“這個任務是必須的嗎？”然後一起調整先後順序。

直到最終沒有人有任何重大的異議。

o之後拍照留念。

然後可整理成電子文檔，如project或者excel版本（使用excel做專案管理？）但是，業務流程圖和上述專案中的流程不太相同的是：專案中的各種活動節點有更寬泛的可配置性，任務A和任務B是否並行，還是串列，如果專案組成員達成共識，是可以調整，並且多做嘗試的。

所以可以用集思廣益的做法去頭腦風暴出一個暫定比較合理的流程。

而業務流程圖的梳理，有兩種:o一種是基於現實發生的業務流程如實反映。

這顯然不是你一個團隊能夠YY的結果。

更需要走到現實環境中，去調研，去梳理，去確認。

o另一種是基於流程優化的方案，當你已經掌握了目前的流程現實如何運作時，基於分析，討論，能夠判斷出流程中不合理的地方，給出一個更完善或者有更效率、成本更低的新的流程出來——或許你要求增加一個部門，或者你需要刪減一個環節，或者中間的若干步使用新開發的系統去取代。

總之，大多數時候，你要想做第二種流程圖，必然要先將第一種給梳理出來。

所以，第一種如實反映的流程圖是躲不過的。

既然如此，基於YY或者頭腦風暴是不現實的。

我們需要走到前線去，掌握現實中業務是如何運作的。

而且很多時候，越細節越好。

那怎麼做呢？基於有限的知識與經驗，我可以給如下建議：1. 調研——2.梳理呈現——3.評審確認三部曲，如圖所示：2. 調研——問正確的問題，多問問題，多問幾個人除了在本部分開始的那幾個問題要顧及到，其實調研過程解決的仍然是who，what，why，how，以及wher e的問題：誰，在什麼情況下，做了什麼事情，這個事情需要什麼前置條件，又輸出了什麼，這個事情在哪裡完成的？搞明白這幾個問題，我們的調研就可以圓滿完成了。

流程圖的表現，要回答這幾個問題：o Who——誰？部門，角色，崗位o What——什麼事情？o Where——在哪裡做的？在我梳理的業務流程圖上，where更多表示是文檔還是各種系統，用來表示資訊化的程度。

比如當我們梳理中發現，有一項登記，是用excel而不是業務系統來進行的，那麼在這裡的where就可以表示為：excel文檔。

o Document——那產生的這份文檔叫什麼名字？也寫出來，代表有檔的傳遞，而以後要進行資訊化的話，此份人肉文檔也是需要被消除而被系統取代的。

（相反，如果這項工作是在某個系統裡操作的，where就可以寫成“人事系統”，文檔可以繼續存在，即該系統中的表單名稱：“員工登記表單”）o Condition——條件。

在這種條件下，下一個活動還能夠繼續，即用邏輯連結線的方式來表示一項活動的輸入和輸出，指向某個活動的箭頭就表示此活動的前置輸入條件。

o Dicision——決策。

有些活動會產生一個條件判斷，根據不同的判斷結果從而走不同的分支流程。

比如輸入員工資訊的時候，可以根據員工之前是否就職過，選擇不同的流程，對於已經就職過的，選用之前的工號而不用生成新的工號。

舉個案例（如果不太恰當，請意會）。

假設你受命要調研兩家餐飲店的業務流程，目的是給他們提供性價比最高的點餐系統。

在調研中：1. 你首先可以要求精通業務流程的人給你系統講解一遍。

2. 調研具體操作的人，來驗證他給你講解的是否全面和偏差。

3. 實地觀察和記錄（花點時間走遍業務流程）三種方式相互結合使用。

第一種方法可以讓你首先建立一個系統觀，瞭解大體枝幹，但是很難切入到可能會出現問題的細節。

第二種方法太依賴於問題的品質以及問問題的場景。

有很多結論的不正確其實是因為問錯了人或者問問題的方法不對。

那麼就需要借助第三種，在觀察中再進行驗證。

比如，你現在找到了一個廚師：你主要負責做什麼菜系？熱菜。

那菜單都是誰給你的？我們的服務員。

她都怎麼提供給你？她負責客人點菜後，然後手寫一個單子，給我放到視窗上。

單子上都會寫什麼？桌號，菜名等那如何客人點的是冷菜呢？恩，有複印本，直接拿一份給冷菜間。

那你怎麼開始工作呢？從洗菜到切菜，一直烹飪都是一個人嗎？哦，不，我只負責烹飪。

當接到功能表後，首先我的助理會進行擇菜，刀工進行切菜，這樣如果有幾個菜就完全可以並行。

當你們做好後呢？放到窗口，按鈴，喊桌號和菜名，傳菜員就會傳菜。

……在這些問題中，就涉及到了“分單”，“切菜”，“擇菜”，”烹飪”，“傳菜”，“上菜”幾個活動，也涉及到了“服務員”，“廚師”，“助理”，“刀工”，“傳菜員”幾個角色。

幾個活動的次序也比較清楚了。

而另一家餐飲店的業務流程卻是不一樣的，你同樣抓住一個廚師進行詢問：要做什麼菜，功能表是哪裡來的？列印出來的。

所有菜都會在這裡列印嗎？哦，只有熱菜在這裡列印出來，冷菜、酒水就會在冷菜間和酒水間列印出來。

印表機是誰在操作的？沒人操作，它會自動列印不同的單子給我們。

……下面的問題，可能廚師就不瞭解了，要問點菜員了。

請問你是怎麼點菜的？拿設備啊，客人點菜就按幾下，確認就好了。

之後呢？之後就可以將功能表列印出來。

不同的菜系會在不同的烹飪間列印嗎？是的，我們可以分單打印。

是在這中心印表機裡完成分單。

然後，你可以繼續調研烹飪後的傳菜和上菜流程。

3. 梳理並呈現你的調研和觀察使你擁有了“烹飪”所需的原材料。

o角色：部門、崗位或人o活動：做了什麼事情o次序：做這些事情的次序如何o規則：什麼情況下到什麼事情還記得我們之前提過的流程圖要素嗎？回顧下：接下來的任務是不是很簡單，對，就像填空題一樣簡單。

將活動/事件按照一定的規則填到由部門和時間兩條維度決定的框框裡。

這個階段是paper work，你需要將調研階段收集到的原材料用更直觀明瞭的方式呈現出來。

從而能夠更好進行評審和確認。

也為以後的流程評審和優化做準備。

在剛開始，筆和紙的原始搭配仍然是最好的起步工具。

你可以暫時忽略掉美觀或者可複用的因素。

但是當你對要呈現的流程已經有足夠的信心時，就可以借助軟體工具了。

3.1 複雜流程的分解不可能將所有的活動都放到一張圖裡呈現。

“業務流程是有層次性的，這種層次體現在由上至下、由整體到部分、由宏觀到微觀、由抽象到具體的邏輯關係。

這樣一個層次關係符合人們的思維習慣，有利於企業業務模型的建立企業部門之間的層次關係表。

一般來說，我們可以先建立主要業務流程的總體運行過程（其中包括了整個企業的大的戰略），然後對其中的每項活動進行細化，落實到各個部門的業務過程，建立相對獨立的子業務流程以及為其服務的輔助業務流程。

”——引自《百度百科》業務流程詞條對於很多新人來講，業務最難的在於劃分業務流程圖的層次上。

首先，明確你要梳理的業務流程的範圍——用大的粗略的關鍵節點，講清楚這個業務流程範圍中的故事，就是頂層業務流程圖。

你的頂層業務流程圖是業務全域故事的簡單表達，但是請注意這裡的業務全域不見得是公司整體的業務全域，而是你界定好的業務範圍。

比如，下圖是餐廳的日常運作流程圖，若你界定的業務範圍是面向顧客的點餐和結帳流程，那麼這就是頂層業務流程圖。

但是若你界定的是整個餐廳的運作業務流程，那這顯然還是一個子集——並沒有包含餐廳的採購、供應商管理、一級庫存管理等工作。

其次，先從頂層的業務流程分解開始，由粗至細。

頂層業務流程圖的梳理原則：1. 界定範圍內的業務全域故事。

2. 包含該範圍內的關鍵節點。

並且，當被質疑說某某環節怎麼不存在時，自己要清楚它在下一層分解中應該被包含在那個關鍵節點中。

比如，贈送10周年優惠券，應該會在結帳節點分解中出現。

而列印分單，會在點菜節點中分解。

而準備兒童座椅應該是接待入座環節。

3. 頂層流程圖分解出來的關鍵節點未必都會細化分解下去，生成二級以及三級的流程圖。

這要看該節點涉及到的“活動”以及“角色”是否複雜。

再看一個案例，對傳統生產型企業的進銷存主業務流程進行分解。

橙色的代表被分解點，已經可以分解為四層。