绘制业务流程图

如何繪製業務流程圖

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

本來寫完上篇，我發現沒有太多必要單純討論這一部分內容，因為對於很多人來講，缺的不是具體的做法，而是做這件事情的意義以及目標性的明確。一旦對這件事情的意義和目標有深刻認同，那自然會產生較大的動力去研究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——決策。有些活動會產生一個條件判斷，根據不同的判斷結果從而走不同的分支流程。比如輸入員工資訊的時候，可以根據員工之前是否就職過，選擇不同的流程，對於已經就職過的，選用之前的工號而不用生成新的工號。