業務流程圖的“烹飪三部曲”
在畫業務流程圖之前，思考如何精致、如何交互、用什麽工具應該不是重點。
真正的要點是收集業務流程圖的關鍵要素。請盡量回答清楚以下問題，否則不要開始畫流程圖:
整個過程的起點是什麽？整個過程的終點是什麽？
整個過程中涉及的角色有哪些？
整個過程需要做什麽？(但這是會議，可以是任務)
這些會議和任務是可選的還是強制性的？
分別制作哪些文件？
這有點像頭腦風暴，可以幫妳得到妳需要的原材料。有了這些“米”和“水”，就不用擔心怎麽做飯了。
在項目管理方面，上個月，我們還嘗試將壹個數據產品的設計和開發過程標準化。
這是壹個數據產品項目，我們都不是很有經驗。所以我們集合了所有相關的角色，組織了壹個頭腦風暴和卡片分類的混合應用。
讓大家對項目中自己認為有必要的節點進行頭腦風暴，比如需求調查、需求分析、啟動會、PRD撰寫和確認、數據評估、技術架構、DEMO繪制、指標算法定義等等。
在頭腦風暴的過程中，主持人把這些節點都寫在了白板上，沒有新的節點誕生後，大家合並歸類在壹起。那之後呢。
把這些剩下的真正有價值的節點寫在便利貼上，開始整理。在排序的過程中，可以有壹個人先打頭陣，他會根據自己的理解，把每個節點放到按角色排列的泳道裏，設計好順序。在他前進的過程中，別人不斷提問:“這個任務開始前需要什麽條件？”“這個任務有必要嗎？”然後壹起調整順序。直到最後，也沒有人有什麽大的異議。
然後拍照留念。
然後可以整理成電子文檔，比如project或者excel版本(用excel做項目管理？)?
但是，業務流程圖與上述項目中的流程不同:
項目中的各種主動節點具有更廣泛的可配置性。任務A和任務B是並行還是串行，在項目組成員達成* * *理解的情況下，可以進行更多的調整和嘗試。所以我們可以通過頭腦風暴來頭腦風暴壹個試探性的合理的流程。梳理業務流程圖有兩種方法:
壹種是基於實際業務流程。這顯然不是妳的團隊能夠YY的結果。更需要去真實的環境中，去調查，去整理，去確認。
另壹種是基於過程優化的方案。當妳掌握了目前的流程實際上是如何運作的，基於分析和討論，妳就可以判斷流程中不合理的地方，給出壹個更完善或者更高效、成本更低的新流程——也許妳需要增加壹個部門，或者妳需要刪除壹個環節，或者用壹個新開發的系統來代替壹些中間步驟。
總之，很多時候，要做第二個流程圖，必須先把第壹個梳理好。所以第壹個真正反映的流程圖是不可避免的。在這種情況下，基於YY或頭腦風暴是不現實的。我們需要去第壹線，了解商業在現實中是如何運作的。而且很多時候，細節越多越好。
那怎麽做呢？基於有限的知識和經驗，我可以給出以下建議:
調查-2。整理演示文稿-3。回顧並確認三部曲，如圖所示:
？
2.研究——問正確的問題，問更多的問題，問更多的人。
除了這部分開頭的問題，研究過程還解決了誰、什麽、為什麽、如何、在哪裏的問題:誰做了什麽，在什麽情況下，這個東西需要什麽前提條件，輸出了什麽，這個東西在哪裏完成？如果我們理解了這些問題，我們的研究就能順利完成。
流程圖的性能應該回答這些問題:
誰誰。部門、角色、職位
這是什麽？
在哪-在哪做的？在我梳理的業務流程圖上，哪裏更多的是壹個文件或者各種制度，用來表示信息化程度。比如當我們發現壹個註冊是用excel而不是業務系統做的，那麽這裏的where可以表示為:excel文檔。
文檔-生成的這個文檔的名稱是什麽？也寫了，代表文件的傳遞，而如果以後要進行信息傳遞，這種人肉文件也需要被系統淘汰和替代。(相反，如果這個工作是在某個系統中操作的，在哪裏可以寫成“人事系統”並且文檔可以繼續存在，也就是這個系統中表單的名稱:“員工登記表”)
條件-條件。在這種條件下，下壹個活動可以繼續，即壹個活動的輸入和輸出用邏輯鏈接線表示，指向壹個活動的箭頭表示這個活動的預輸入條件。
決策。有些活動會產生壹個條件判斷，根據不同的判斷結果采取不同的分支流程。例如，在輸入員工信息時，您可以根據該員工以前是否被雇用來選擇不同的流程。對於已經就業的，可以選擇以前的工號，不生成新的工號。
舉個例子(不合適請諒解)。假設妳奉命調查兩家餐廳的業務流程，以便為他們提供最具性價比的點餐系統。
在調查中:
1.可以先請精通業務流程的人給妳講解壹下系統。
2.調查具體操作者，驗證他給妳的解釋是否全面，是否有偏差。
3.現場觀察和記錄(花壹些時間瀏覽業務流程)
這三種方法相互結合使用。第壹種方法可以讓妳先建立壹個系統的觀點，了解大體的分支，但是很難切入可能會出問題的細節。第二種方法太依賴問題的質量和提問的場景。很多不正確的結論，其實都是因為問錯了人，或者問錯了問題。那麽妳需要用第三種方法在觀察中驗證。
比如妳現在找了壹個廚師:
主要負責什麽菜系？
熱菜。
誰給妳的菜單？
我們的服務員。
她是怎麽提供給妳的？
她照顧客人點餐後，手寫壹份清單，放在櫥窗上給我看。
清單上會有什麽？
桌號，菜名等。
那客人怎麽點了涼菜？
嗯，有副本。直接拿壹個去冷藏室。
那妳怎麽開始工作？從洗菜到切菜，妳壹直壹個人做飯嗎？
哦，不，我只負責做飯。收到菜單後，我的助理會先選菜，刀工來切，這樣如果有幾個菜，就可以平行了。
妳完成後呢？
放在窗口，按鈴，喊桌號和菜名，送菜員就會把菜送過來。
……
在這些問題中，涉及到分菜、切菜、選菜、烹飪、傳菜、上菜等幾項活動，以及服務員、廚師、助手、刀工、傳菜員等角色。幾個活動的順序也比較明確。
另壹家餐廳的業務流程就不壹樣了。妳也可以找壹個廚師問:
妳想做什麽？菜單從何而來？
打印出來。
所有的菜都印在這裏嗎？
哦，這裏只印熱菜，涼菜和飲料會印在涼菜間和飲料間。
誰在操作這臺打印機？
沒人操作，它會自動給我們打印不同的清單。
.....以下幾個問題廚師可能不太懂，只好問點餐人員了。
妳怎麽點菜？
帶上設備。按幾下就可以下單確認了。
那之後呢。
之後，妳就可以打印出菜單了。
不同的菜系會在不同的烹飪室打印嗎？
是的，我們可以分開打印。訂單就是在這臺中央打印機中被分割的。
然後，妳可以繼續調查食物烹飪後的傳遞和上菜過程。
梳理並呈現
妳的研究和觀察給了妳烹飪所需的原料。
角色:部門、崗位或人員
活動:妳做了什麽？
順序:做這些事情的順序是什麽？
規則:什麽時候會發生？
還記得我們之前提到的流程圖元素嗎？回顧過去:
下壹個任務是不是很簡單？是的，就像填空壹樣簡單。將活動/事件按照壹定的規則填入由部門和時間確定的框架中。
這個階段是紙面工作，妳需要把調研階段收集到的原始資料用更直觀、更清晰的方式呈現出來。以便更好地評估和確認。它還為將來的流程審查和優化做準備。
剛開始的時候，紙和筆的原始組合仍然是最好的啟動工具。可以暫時忽略美觀或者可重復使用的因素。但是當妳對要呈現的過程有足夠的信心時，妳就可以使用軟件工具了。
3.1復雜過程的分解
不可能在壹張圖中呈現所有的活動。
“業務流程是分層次的，這個層次體現在從上到下、從整體到部分、從宏觀到微觀、從抽象到具體的邏輯關系中。這樣的層級關系符合人的思維習慣，有利於企業商業模式的建立？企業部門之間的層級關系表。壹般來說，我們可以先建立主要業務流程(包括整個企業的大戰略)的整體運作流程，然後細化每項活動並落實到各部門的業務流程中，建立相對獨立的子業務流程和為其服務的輔助業務流程。”
——引自百度百科業務流程詞條
對於很多新人來說，做生意最難的就是劃分業務流程圖的層次。
首先明確妳要梳理的業務流程的範圍——用大粗關鍵節點在這個業務流程範圍內講故事，這就是頂層的業務流程圖。妳的頂層業務流程圖是整體業務故事的簡單表達，但請註意，這裏的整體業務不壹定是公司的整體業務，而是妳所定義的業務範圍。比如下圖是餐廳的日常運營流程圖。如果妳的業務範圍是面向客戶的點餐和結賬流程，那麽這就是頂層業務流程圖。但如果定義整個餐廳的業務流程，顯然是壹個子集——不包括餐廳采購、供應商管理、壹級庫存管理等等。
其次，從頂層業務流程分解入手，由粗到細。頂層業務流程圖的梳理原則:
1.定義範圍內的整體業務故事。
2.包括該範圍內的關鍵節點。而且，當被質疑為什麽某個環節不存在的時候，妳要知道，在下壹次分解中，它應該包含在那個關鍵節點裏。比如贈送10周年優惠券要出現在結賬節點分解中。打印訂單將在訂貨節點分解。兒童座椅的準備工作應該是接待和就座。
3.從頂層流程圖中分解出來的關鍵節點可能不會全部被細化分解生成第二層和第三層流程圖。要看節點涉及的“活動”和“角色”是否復雜。
再看壹個案例來分解傳統生產企業的進銷存主要業務流程。橙色代表分解點，可以分解成四層。當我們分解到第四層，發現下壹步涉及的活動和角色很少，就不需要再分解了，而是可以直接把第四層的關鍵節點作為第三層業務流程的“活動”，而不是子流程圖。
當然，這取決於妳梳理業務流程的目標。如果只是想分析優化“打樣”環節，可以繼續分解。
這壹步的工作將幫助妳建立壹個清晰的流程目錄結構，如下圖所示，是從壹個新完成的流程梳理項目中提取的目錄結構部分。可以看出，整個地圖是頂層的關鍵節點。作為老板，看這壹層可能就夠了。下面將對頂層做更詳細的拆解。
“H3。“示例身份驗證”只是頂級業務流程圖中的壹項活動，但在這壹級別的細化中，它將包括詳細的子活動1級參與者。
3.2流程圖的常用圖表
我壹般用前兩行活動，判斷，邏輯關系行，開始和結束，第二行子流程和文件/表格。如果妳不是符號控，我建議這些就夠了。
其中“子流程”圖標可以幫助妳將流程分解得到的子流程串聯起來。例如，當“A流程”涉及到需要進壹步分解的“A1.1”流程時，可以用子流程符號來表示“A流程”中的“A1.1”。那麽妳的讀者就會明白，要進壹步理解“A1.1”，妳應該參考另壹個流程圖。
流程圖的常見結構:
讓我給妳看壹些案例:
基本上包含大部分圖表的流程圖:
只使用了幾個簡單的帶插圖的流程圖(在臺灣省人的文檔中稱之為程序圖——但這裏的程序不是計算機程序，而是壹個過程，只反映任務之間的處理流程，所以使用極其簡單的符號也就不足為奇了):
以上兩個流程圖案例，從符號的復雜程度來看，壹個是完整流程圖，壹個是基本流程圖，但從表現形式來看，都屬於“泳道”。這也是我們最常用的表達形式。泳道圖可以很好地反映流程中各部門或角色的職責以及上下遊的合作關系。而且流程圖本身的標準也容易掌握，更容易達到* * *的理解。
3.3車道地圖的要點
2大維度:壹般會把車道圖的橫向維度作為部門或者崗位維度，但也有例外，比如上面案例中的橫向車道。縱向維度是階段維度——時間從上到下發展。如果泳道圖比較復雜，可以在階段維度做壹些劃分，比如“采購”、“生產”、“銷售”、“分銷”。
活動循環:活動就像壹個遊泳運動員，在不同的泳道遊泳執行任務。
在上面的軟件推薦部分，我推薦了smartdraw工具，它還附帶了泳道圖的模板，方便大家更快上手:
3.4 Do vs Donnot業務流程圖註意事項！
防禦命令(Defense Order)
1.讓利益相關者參與進來，而不是關起門來。
業務流程圖包含了妳的圖表上每個參與角色的代表，並及時與他們確認事情的原始流程，禁止自己YY。
2.適當的層次分解，不要把壹切都攤在壹張圖上。
如上圖。
3.逐步深入，先抓樹枝。
不要抓胡子眉毛。
4.這個過程必須有始有終。
不交付流程圖，讓讀者再問妳壹遍:流程的起點是什麽？用代表開始和結束的清晰符號完成第壹步和最後壹步。
數字，數字，數字
這是壹種優化措施，讓溝通更有效率。當妳有壹個編號系統時，它相當於給妳的流程圖壹個唯壹的標識號。這比中文名字更有效。比如當我們完成了業務流程圖，負責審核優化業務流程規則的部門可以在郵件中明確傳達:H5.1流程優化，大家會更清楚是什麽意思。
多諾
1.YY申請的鏈接不是現實中的鏈接。
2.所有的鏈接都試圖放在壹張圖片上。
3.從頭進入細節，胡子眉毛壹起抓。
4.很難說出這個過程的起點和終點。
4.審查和後續行動
驗證自己是否做到了以上do，避免Donnot的做法是什麽？
非常好辦，及時跟妳復習。把所有利益相關者召集到壹起，向他們展示妳整理出來的結果。
這樣會發現壹些有趣的東西，除了判斷妳的流程圖是否符合現實，還會判斷目前的業務流程是否符合理想。不同部門、不同崗位的代表會在這次評審中確認現狀，也會互相發表意見，甚至爭吵，這是流程優化的好機會。暫時不看。
打字很辛苦，希望LZ能喜歡並采納！