绘制业务流程大纲纲要图.docxVIP

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