绘制业务流程图.docxVIP

如何繪製業務流程圖 接上篇《業務流程圖繪製流程分享(一)》，本篇將對上篇中間的第四部分——如何繪製業務流程圖展開更多討論。本來寫完上篇，我發現沒有太多必要單純討論這一部分內容，因為對於很多人來講，缺的不是具體的做法，而是做這件事情的意義以及目標性的明確。一旦對這件事情的意義和目標有深刻認同，那自然會產生較大的動力去研究How這個層次的所需方法和技能。時間管理也如此，很多時間管理技巧牛逼的人未必能夠把時間管理做到位，因為內心克服不了強大的拖延症，而克服拖延很多時候是一個心理問題而不是技巧問題……咳咳，這不是在說我自己嗎？ 業務流程圖的表達的6個關鍵問題 話又扯遠了，扯扯扯回來啊。那麼為何還專門狗尾續貂（恩，原文也不見得是貂，成語有限，暫時湊合吧），又來這麼一篇How的枯燥乏味的文章呢？因為在上篇文章後，Heidi確實在郵件裡收到一些郵件，詢問業務流程圖的具體操作指南——這東西很好，這東西很有用，但是似乎上篇都是講的“真實的道理”，但是具體怎麼做呢？我應該注意什麼呢？…… 所以，乾脆也分享一下吧。但在書寫過程中，我發現一個大難題在於收集整理出更生動易懂又典型的案例。不能使用工作中的實際案例，但是短時間又難以找到合適的。所以本人對這部分不太滿意。也希望各位讀到本文的人，能夠提供更多案例分享。—————————————————-分割線——————————————————————————-1. 業務流程圖的“烹飪三部曲”在繪製業務流程圖前，思考如何精美，如何交互，使用什麼工具，都不應該是重點。真正重點的是將業務流程圖的關鍵要素給搜集一番。請試圖回答清楚以下幾個問題，否則不要開始繪製流程圖： 整個流程的起始點是什麼？整個流程的終結點是什麼？ 在整個流程中，涉及到的角色都是誰？ 在整個流程中，都需要做什麼事情？（可是是一個會議，可以是一個任務） 這些會議和任務是可選還是必選的？ 分別產出什麼文檔？ 這有點像一個頭腦風暴，能夠幫助你將所需用到的原材料獲取到，有了這些“米”和“水”，那就不愁去如何烹飪了。在專案管理中，上個月，我們也試圖給去規範化一個資料產品的設計開發流程。這是一個資料產品的專案，而我們都不是對此很有經驗的人。所以我們召集到所有相關的角色，組織了一次頭腦風暴及卡片分類法的混合式應用。 讓大家頭腦風暴出自己認為在專案裡必須的節點，如“需求調研”，“需求分析”，“kick off會議”，“PRD撰寫及確認”，“資料評估”，“技術架構”，“DEMO繪製”，“指標演算法定義”，等等。 在頭腦風暴過程中，主持人將這些節點都寫到白板上，等沒有新的節點誕生後，大家一起對節點進行合併歸類。之後呢？ 將這些剩餘下來的真正有價值的節點，撰寫到即時貼上，開始進行排序。在排序過程中，可以由一個人先主導，他會按照自己的理解，將各個節點放到按角色排布的泳道中，並設計好先後的順序。在他進行的過程中，其他人不斷進行提問：“這項任務開始前，需要什麼樣的條件？”“這個任務是必須的嗎？”然後一起調整先後順序。直到最終沒有人有任何重大的異議。 之後拍照留念。 然後可整理成電子文檔，如project或者excel版本（使用excel做專案管理？） 但是，業務流程圖和上述專案中的流程不太相同的是： 專案中的各種活動節點有更寬泛的可配置性，任務A和任務B是否並行，還是串列，如果專案組成員達成共識，是可以調整，並且多做嘗試的。所以可以用集思廣益的做法去頭腦風暴出一個暫定比較合理的流程。而業務流程圖的梳理，有兩種: 一種是基於現實發生的業務流程如實反映。這顯然不是你一個團隊能夠YY的結果。更需要走到現實環境中，去調研，去梳理，去確認。 另一種是基於流程優化的方案，當你已經掌握了目前的流程現實如何運作時，基於分析，討論，能夠判斷出流程中不合理的地方，給出一個更完善或者有更效率、成本更低的新的流程出來——或許你要求增加一個部門，或者你需要刪減一個環節，或者中間的若干步使用新開發的系統去取代。 總之，大多數時候，你要想做第二種流程圖，必然要先將第一種給梳理出來。所以，第一種如實反映的流程圖是躲不過的。既然如此，基於YY或者頭腦風暴是不現實的。我們需要走到前線去，掌握現實中業務是如何運作的。而且很多時候，越細節越好。那怎麼做呢？基於有限的知識與經驗，我可以給如下建議： 1. 調研——2.梳理呈現——3.評審確認三部曲，如圖所示： 2. 調研——問正確的問題，多問問題，多問幾個人除了在本部分開始的那幾個問題要顧及到，其實調研過程解決的仍然是who，what，why，how，以及where的問題：誰，在什麼情況下，做了什麼事情，這個事情需要什麼前置條件，又輸出了什麼，這個事情在哪裡完成的？搞明白這幾個問題，我們的調研就可以圓滿完成了。 流程圖的表現，要回答