編輯導語：產品經理在日常工作中，經常會用到流程圖，流程圖也分很多種類型和作用，但流程圖梳理起來並不簡單，其中最多見的是業務類流程圖；本文詳細介紹了流程圖的分類以及業務流程圖的處理辦法。
我們產品在梳理較為複雜的業務流程的時候可能涉及到多個組織部門，業務場景、系統交互等等，梳理起來十分困難。
光是如何佈局都比較頭疼，最後終於把業務的千絲萬縷梳理清晰了，才發現業務流程圖十分龐大複雜。
在和領導彙報同時交流的時候，ppt和word裏面都塞不下；最後用着最小的字體，將整體流程講解完成發現大家也是很難理解。
這裏説明了我們日常流程圖存在三個問題：
針對上述的問題，建議產品能夠明確對應的流程圖的作用與區分。
01常見的流程圖：
- 業務交互流程圖
- 系統交互流程圖
- 頁面交互流程圖
- 時序圖
- 數據交互圖等
其中：
面向業務：業務交互流程圖
用於標識業務流轉規則，需要有事項的明確開始和結束節點，需要明確的職責劃分與對應的輸入輸出標準。整體保證流程或者事項能夠通過業務流轉與解決。
面向產品：系統交互流程圖
當某個功能涉及多個子系統的時候，需要從業務規則中抽象出需要的功能點，並將這些功能點依據產品定位進行區分，確定系統職責。這個時候可以初步設計可能需要的接口或者大致的交互機制與主鍵（沒有必要定死幾個接口和所有字段，這個接口更像是業務屬性的接口）。
面向交互：頁面交互流程圖
用於表述用户操作的細節，這個時候需要將用户場景理解清晰，用户操作需要用到哪些頁面，這些頁面之間的跳轉返回邏輯是什麼，有哪些校驗條件。這裏更加偏重用户體驗，可以交給我們的交互同學協助完成。
面向開發：時序圖
梳理時序圖可以幫助開發梳理邏輯，也可以自己驗證設計的邏輯是否閉環，很多異常場景可以在梳理時序圖的時候自我反省出來。
面向開發：數據交互圖
當項目涉及多個產品的時候，需要單獨整理數據詞典、接口清單、與數據交互圖。
數據交互圖在設計的時候有助於全局觀審視系統設計。可以避免後端系統系統需要的字段，前端系統沒有下傳的問題。
這個舉一個例子：
數據流為：A–B–C 如果C系統需要某個字段是A系統產生的，但是B系統不需要，可能B系統在梳理的時候就會忽略，導致C系統重要字段缺失。如果梳理清晰數據交互圖就可以避免類似的問題。
有了以上的對於流程的圖劃分，我們就可以“看人下菜”，即提高的溝通的效率，也讓對方容易理解。而不是拿一張流程圖和所有人講，結果大家都不清晰。並且上述流程圖的輸出排序也建議按照上述排序進行輸出。
02 如果某個流程圖過於複雜怎麼辦?
這個多見於業務流程圖，因為業務流程可粗可細，如果業務糾結於一些細節，光是一個小的場景，就可能會有多個複雜的邏輯，並且需要展示流程全貌，這個時候你的業務流程圖就是巨型的，及時你僅僅繪製業務層面的內容，其體量也很大，這個時候如何處理？
建議大家可以從幾個層級來細分：
- 部門層級：在瞭解業務的組織架構於職責之後，通過部門的維護進行業務場景梳理，比如銷售部門，財務部門，行政部門。以這個維度進行業務場景的劃分，重點在於瞭解業務主線於全貌，和整體流程的職責劃分。
- 崗位層級：在上述基礎上將部門所負責的模塊拆分到崗位。這個時候可以明確流程處理邏輯，已經可以通過崗位流程圖瞭解到事項處理的條件與要求。並且明確責任到崗位，明確每一個崗位輸入和輸出的標準產物。
- 操作層級：針對某個崗位的具體操作進行梳理，在明確輸入與輸出條件的基礎上，明確每一步執行的動作。雖然不能達到操作手冊的細度，但是要求可以將對應的畫面在腦海中勾勒出來的程度。
- 場景層級：如果這塊業務十分複雜，可以將其分為幾個場景來明確步驟，比如依據地點進行劃分，依據處理事項的具體類型進行劃分。
（小技巧：對於一些特殊場景可以單獨抽出來，不要影響主線流程的理解；對於分支場景也可以僅僅在主線流程裏面一筆帶過，單獨一個頁面進行整理。）
本文由 @離譜 發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議