绘制业务流程图.docx

绘制业务流程图.docx

《绘制业务流程图.docx》由会员分享，可在线阅读，更多相关《绘制业务流程图.docx（17页珍藏版）》请在冰豆网上搜索。

绘制业务流程图

如何繪製業務流程圖

接上篇《業務流程圖繪製流程分享

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

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

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

時間管理也如此，很多時間管理技巧牛逼的人未必能夠把時間管理做到位，因為內心克服不了強大的拖延症，而克服拖延很多時候是一個心理問題而不是技巧問題……咳咳，這不是在說我自己嗎？

業務流程圖的表達的6個關鍵問題

話又扯遠了，扯扯扯回來啊。

那麼為何還專門狗尾續貂（恩，原文也不見得是貂，成語有限，暫時湊合吧），又來這麼一篇How的枯燥乏味的文章呢？

因為在上篇文章後，Heidi確實在郵件裡收到一些郵件，詢問業務流程圖的具體操作指南——這東西很好，這東西很有用，但是似乎上篇都是講的“真實的道理”，但是具體怎麼做呢？

我應該注意什麼呢？

……

所以，乾脆也分享一下吧。

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

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

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

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

—————————————————-分割線——————————————————————————-

1.業務流程圖的“烹飪三部曲”

在繪製業務流程圖前，思考如何精美，如何交互，使用什麼工具，都不應該是重點。

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

請試圖回答清楚以下幾個問題，否則不要開始繪製流程圖：

o整個流程的起始點是什麼？

整個流程的終結點是什麼？

o在整個流程中，涉及到的角色都是誰？

o在整個流程中，都需要做什麼事情？

（可是是一個會議，可以是一個任務）

o這些會議和任務是可選還是必選的？

o分別產出什麼文檔？

這有點像一個頭腦風暴，能夠幫助你將所需用到的原材料獲取到，有了這些“米”和“水”，那就不愁去如何烹飪了。

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

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

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

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

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

之後呢？

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

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

在他進行的過程中，其他人不斷進行提問：

“這項任務開始前，需要什麼樣的條件？

”“這個任務是必須的嗎？

”然後一起調整先後順序。

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

o之後拍照留念。

然後可整理成電子文檔，如project或者excel版本（使用excel做專案管理？

）

但是，業務流程圖和上述專案中的流程不太相同的是：

專案中的各種活動節點有更寬泛的可配置性，任務A和任務B是否並行，還是串列，如果專案組成員達成共識，是可以調整，並且多做嘗試的。

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

而業務流程圖的梳理，有兩種:

o一種是基於現實發生的業務流程如實反映。

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

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

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

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

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

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

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

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

那怎麼做呢？

基於有限的知識與經驗，我可以給如下建議：

1.調研——2.梳理呈現——3.評審確認三部曲，如圖所示：

2.調研——問正確的問題，多問問題，多問幾個人

除了在本部分開始的那幾個問題要顧及到，其實調研過程解決的仍然是who，what，why，how，以及where的問題：

誰，在什麼情況下，做了什麼事情，這個事情需要什麼前置條件，又輸出了什麼，這個事情在哪裡完成的？

搞明白這幾個問題，我們的調研就可以圓滿完成了。

流程圖的表現，要回答這幾個問題：

oWho——誰？

部門，角色，崗位

oWhat——什麼事情？

oWhere——在哪裡做的？

在我梳理的業務流程圖上，where更多表示是文檔還是各種系統，用來表示資訊化的程度。

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

excel文檔。

oDocument——那產生的這份文檔叫什麼名字？

也寫出來，代表有檔的傳遞，而以後要進行資訊化的話，此份人肉文檔也是需要被消除而被系統取代的。

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

“員工登記表單”）

oCondition——條件。

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

oDicision——決策。

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

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

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

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

在調研中：

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

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

3.實地觀察和記錄（花點時間走遍業務流程）

三種方式相互結合使用。

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

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

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

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

比如，你現在找到了一個廚師：

你主要負責做什麼菜系？

熱菜。

那菜單都是誰給你的？

我們的服務員。

她都怎麼提供給你？

她負責客人點菜後，然後手寫一個單子，給我放到視窗上。

單子上都會寫什麼？

桌號，菜名等

那如何客人點的是冷菜呢？

恩，有複印本，直接拿一份給冷菜間。

那你怎麼開始工作呢？

從洗菜到切菜，一直烹飪都是一個人嗎？

哦，不，我只負責烹飪。

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

當你們做好後呢？

放到窗口，按鈴，喊桌號和菜名，傳菜員就會傳菜。

……

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

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

而另一家餐飲店的業務流程卻是不一樣的，你同樣抓住一個廚師進行詢問：

要做什麼菜，功能表是哪裡來的？

列印出來的。

所有菜都會在這裡列印嗎？

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

印表機是誰在操作的？

沒人操作，它會自動列印不同的單子給我們。

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

請問你是怎麼點菜的？

拿設備啊，客人點菜就按幾下，確認就好了。

之後呢？

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

不同的菜系會在不同的烹飪間列印嗎？

是的，我們可以分單打印。

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

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

3.梳理並呈現

你的調研和觀察使你擁有了“烹飪”所需的原材料。

o角色：

部門、崗位或人

o活動：

做了什麼事情

o次序：

做這些事情的次序如何

o規則：

什麼情況下到什麼事情

還記得我們之前提過的流程圖要素嗎？

回顧下：

接下來的任務是不是很簡單，對，就像填空題一樣簡單。

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

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

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

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

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

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

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

3.1複雜流程的分解

不可能將所有的活動都放到一張圖裡呈現。

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

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

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

”

——引自《XX百科》業務流程詞條

對於很多新人來講，業務最難的在於劃分業務流程圖的層次上。

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

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

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

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

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

頂層業務流程圖的梳理原則：

1.界定範圍內的業務全域故事。

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

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

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

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

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

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

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

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

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

當我們分解到第四層，發現再往下去涉及到的活動和角色都已經很少時，就不必再分解了，而是可以將第四層的關鍵節點直接作為第三層業務流程的“活動”，而不是子流程圖。

當然，這是依賴於你梳理業務流程的目標。

如果你偏偏是要對“打樣”環節進行剖析優化，則還可以繼續分解下去。

這一步的工作會幫你建立出清晰的流程目錄結構，如下圖所示是摘選於剛完成的一個流程梳理的專案中的目錄結構部分。

可以看到全圖即是頂層關鍵節點，作為老大，可能只要看這一層就夠了。

下面則會對頂層做更多細化拆解。

“H3.樣品認證”在頂層業務流程圖中，僅僅是一個“活動”，而在自己細化的這一個層次中，則會包含詳細的子活動一級參與者。

3.2流程圖的常用圖示

我常用的就是前兩行的“活動”，“判斷”，“邏輯關係線”，“起始與終止”，以及第二行的“子流程”，和“檔/表單”。

如果你不是符號控，我建議這幾個就足夠了。

其中，“子流程”此圖示就是可以説明你將流程分解得到的子流程能夠串聯起來，比如，當在”A流程”中涉及到進一步需要分解的”A1.1流程”時，就可以在”A流程”中用子流程符號代表“A1.1”。

然後你的讀者就會明白要想進一步瞭解”A1.1″應該參考另外一個流程圖。

流程圖的常用結構：

給大家看一些案例：

基本上包含大多數圖示的流程圖：

文檔地址：

只用到少數幾個圖示畫的簡單流程圖（臺灣人的文檔中稱為程式圖——不過這裡的程式不是指電腦程式，而是process，僅僅是體現任務之間的處理流程，所以使用極簡單的符號也不為怪了）：

以上兩個流程圖案例，從符號的複雜程度上來講，一個是完整流程圖，一個是基本流程圖，但是從表現形式來講，都屬於“泳道圖”——Swimlane。

這也是我們最常用的一種表現形式了。

泳道圖能夠很好體現部門或者角色在流程中的職責以及上下游的協作關係。

且流程圖本身的標準容易掌握，達成共識也就更加容易。

3.3泳道圖精要

o2大維度：

一般泳道圖的橫向會作為部門或崗位維，當然也有例外，如上述案例中就是橫的泳道。

而縱向則做為階段維——時間是從上到下發展的。

如果複雜的泳道圖，在任務分解上可以在階段維裡做一些劃分，比如“採購”，“生產”，“銷售”，”配送”等。

o活動流轉：

活動就像一個游泳員一樣，遊到不同的泳道中去執行任務。

在上文中的軟體推薦部分，我推薦過smartdraw工具，此工具還附帶了泳道圖的範本，大家比較更快能夠上手：

3.4DovsDonnot業務流程圖的注意事項！

DO

1.讓涉眾參與，不要閉門造車

業務流程圖包含了你圖上的各個參與角色代表，與他們適時確認事情的原本流程，禁止自己YY。

2.恰當的層次分解，不要將所有都鋪到一張圖上

如上所示。

3.逐漸深入，先抓枝幹

切忌鬍子眉毛一把抓。

4.流程一定有開始和結束

切忌交付出來的流程圖，讓讀者還來問你：

流程的開始點是什麼？

用清晰的代表開始和結束的符號來完成第一步和最後一步。

5.編號，編號，編號

這是讓溝通效率更高的優化措施。

當你有了編號系統，相當於對你的流程圖都賦予了唯一識別身份證號。

這比中文名稱更有效。

比如當我們完成了業務流程圖後，負責業務流程規則審核和優化的部門能夠清楚在郵件裡傳達：

H5.1流程優化，大家就更明確指的是什麼。

DONNOT

1.自己YY應用的環節而不是現實中的環節

2.所有的環節都試圖放到一張圖上

3.一開始就陷入細節，鬍子眉毛一起抓

4.流程很難讓人分清楚從哪裡開始，到哪裡結束

4.評審及後續行動

驗證你是否做到了以上的DO，以及規避了Donnot的做法是什麼？

很好辦，及時與各位進行評審。

將各個涉眾都叫到一起，給他們看你梳理出來的成果。

這會發現一些有意思的事情，除了評審你的流程圖是否符合現實外，也會評審目前的業務流程是否符合理想。

不同的部門和崗位的代表會在這個評審中，確認當前，也會相互提出意見，甚至吵起來，這不失於做流程優化的一個很好的契機。

暫且不表了。

參考文檔：

SWIMLANE（orCROSS-FUNCTIONAL）DIAGRAMS：

MBALIB關於泳道流程圖的詞條：

來源：