起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何拆解復雜業務流程？
編輯導讀：對業務進行拆解能幫助產品經理更好地厘清各個模塊之間的關系，分清主次需求。當一個產品經理接到一個復雜且陌生的業務時，要怎么將它從頭拆解轉化成產品需求？本文主要講解該如何拆解，一起來看看~
產品的價值取決于用戶需求。需求是用戶當下遇到的問題，用戶為了解決問題會尋求解決方案。
企業與用戶的連接點就在于此。企業為用戶提供解決方案，而產品則是解決方案的載體。
無論C端還是B端產品，都是為了解決問題而存在。
產品經理的工作其實是給出一個符合當下最優的解決方案，解決方案的載體就是產品。
解決方案制定的過程中會不斷重復這三個步驟：發現問題，解決問題，驗證問題。
梳理解決方案就是弄清楚需要哪些人做哪些事，以及人和事、人和人、事和事之間的聯系。
這對應著系統的三個組成元素：角色、任務、規則。
角色對應需要哪些人，任務對應需要做哪些事，規則對應人和事、人和人、事和事之間的聯系。
有了以上的認知，就可以開始拆解業務。
01 定義關鍵角色
拆解業務首先要弄清楚哪些人會參與解決問題。
解決一個問題往往需要完成多個任務，每一個任務都會由一個或多個人參與。
找到那些執行相同任務的人，把他們定義為一個角色。
比如餐廳點餐，顧客負責點餐，服務員負責確認菜單，勤雜工負責準備食材，廚師負責做菜。這些角色各自的任務都不相同。
有一點需要特別說明，一個任務的參與人也可能是“系統”。比如服務員確認菜單后，通知廚師和勤雜工可以由系統替代。
02 識別關鍵業務節點
解決一個問題需要執行很多任務，但并非所有的任務都是關鍵業務節點。
關鍵任務節點有兩個特征：一是能夠推進業務往下進行，二是推動業務在不同角色間流轉。
比如廚師在做菜時會執行很多個操作。配菜、炒菜、調味、擺盤……但這些步驟都是“做菜”。雖然廚師做了很多事情，但在餐廳的業務流程里只有“做菜”是關鍵業務節點。
再比如后臺系統常見的錄入用戶信息。昵稱、性別、城市的填寫都是需要執行的任務，但完成其中單個信息的填寫并不能推動業務往下進行。在系統層面可以把這些任務抽象為一個關鍵業務節點——填寫用戶信息。
不同角色間的流轉，審批流程是很好的例子。比如在釘釘上提交一個采購工單，審批者需要對提交的金額和采購的物品進行核對，但這些不會在系統層面體現，只有“通過”或“拒絕”這類推動業務在不同角色間流轉的任務才會被定義為關鍵業務節點。
03 定義業務規則與業務流程
前面我們已經將業務的關鍵角色和關鍵業務節點梳理清楚，但這只是業務梳理的熱身運動。
接著還需要弄清楚人和人、事和事、人和事的聯系。
“聯系”體現在兩個方面：一是不同角色執行任務的順序，二是任務執行時需要遵循的規則。
業務梳理的最終產出物就是業務規則與業務流程。
依舊以餐廳點餐為例，做菜時鹽不能放太多、火候不能太過、分量不能太少，這些都是廚師在執行任務時需要遵循的規則。如果不遵循規則，最終的結果是業務停在做菜這個環節無法繼續往下推進。
同時做菜一定是在服務員確認好菜單后才會進行，這是任務執行的順序。假設先做菜后確認菜單，就會導致之前進行的任務變得無效以及任務的重復。
以上兩個例子說明了梳理清楚人與事的重要性，梳理有誤最終導致的結果就是業務的停滯與業務的周期變長。
04 如何拆解復雜業務流程？
現實世界的業務往往是極其復雜的。
業務的復雜度往往體現在以下幾個維度：
- 多關鍵角色、多關鍵任務節點
- 多業務分支流程
- 業務流程長
- 業務周期長
- 業務規則復雜
并不是同時具備以上特征才能算作復雜業務。有時只要具備一個或其中幾個就足以讓業務變得復雜。
拿我正在負責的業務系統為例，系統的角色并不復雜，參與核心業務流程的角色不超過10個。但因為行業的特殊性，用戶的成單周期在2~4周，服務用戶的周期在2年左右。同時，雖然角色不多，但用戶的分支業務流程很多。
因為過長的成單周期和服務周期，讓整個業務周期被拉長，從而讓業務變得復雜。同時每個角色的分支業務流程很多，進一步提升了業務的復雜度。
最后的結果是，我繪制的流程圖里的節點可以造一艘航空母艦。
那么面對如此復雜的業務，我們該從何下手呢？
1. 梳理單角色業務流程
業務復雜時，我們可以先梳理清楚單角色的業務流程。
比如梳理餐廳出餐業務，我們可以先梳理清楚服務員的業務流程，暫時擱置其它角色的業務流程。
如上圖所示，服務員在通知廚房做菜后，不用關心廚師是如何制作菜品的，只需要弄清楚服務員后面會在哪一個節點再次介入業務。
對于服務員而言，廚師做菜是一個“黑盒”，他只關心菜品什么時候制作完成，收到菜品制作完成后他就可以進行后續的任務。
同理，其它角色也可以按照這個邏輯進行梳理。當每個角色獨立的業務流程梳理完成后，再將它們串聯起來就組成了完整的業務流程。
2. 梳理單向業務流程
?一個角色可能會進行多個分支業務流。
這個時候，我們可以先梳理清楚可能存在的業務線，然后對每一條業務線進行單獨的梳理。
比如審批流里，審批的結果通常有通過和不通過。這時可以先梳理清楚通過后的業務流程，再回過頭去梳理不通過的業務流程。
當兩條業務線梳理清楚后再合并在一起就構成了完整的業務流程。
其背后的思維方式其實和梳理單角色業務流程一致——化繁為簡。
把復雜的業務拆解為單角色、單流程的業務進行梳理，這樣能夠更清晰地把握業務脈絡。
3. 梳理異常業務流程
除了主線的業務流程外，還有很多異常的業務流程。
比如餐廳就餐的主線業務流程是用戶點餐到用戶買單。但不可避免的情況是——退款。
這種獨立于主線業務流程外的業務稱之為異常業務。
針對異常業務，我們可以單獨拎出來進行梳理而不和主線業務流程產生交織。在設計業務時，要盡可能避免降低對主流程的影響。
05 那些需要留意的坑
1. 線上業務流程抽離
完整線下業務流程梳理后，在進行產品設計時，要從線下業務流程中抽離出完整的線上業務流程。
比如點餐系統。在系統層面，會刪除掉很多線下的環節。廚師做菜是線下的任務，執行時可以不必與系統進行交互，只需要完成做菜后在系統執行操作，通知到服務員取餐即可。
其次是線上業務流程會引入“系統”這一角色，很多原本在線下執行的任務都會有系統的參與。我們需要明確系統在整個業務流程中替代了哪些之前由線下角色執行的任務。
2. 了解真實的業務現狀
很多公司里面系統的需求方是業務負責人，而不是一線的業務人員，所以系統的設計是從管理者視角出發的。
這種情況很可能導致系統的設計并不符合真實使用者的需求。為了避免這種情況發生，產品經理在設計系統時一定要找一線業務人員進行調研。
另外一種情況是，系統上線后系統使用者可能并沒有按照設計者的預期使用系統，而是按照自己的理解來使用系統。所以在系統上線后產品經理一定要去看看系統真實的使用情況。
3. 系統的效率并不一定高于線下
系統的核心價值在于提升效率。如果引入系統后效率并沒有提升，甚至效率降低，這個時候就值得我們深思了。
比如服務行業里往往存在總部和線下門店兩個獨立的業務部門。線下門店有時會遇到極其特殊的情況，而這種情況通常需要即時處理，但又無法自己做決策。
如果走系統可能會因為業務流程的停滯導致線下的問題無法即時解決。
最快的方式就是一個電話打到總部，讓總部做出決策后即時處理。
系統只是一種解決方案，但不是唯一的解決方案。
4. 業務問題、系統問題傻傻分不清楚
- “你們系統設計的太爛了，根本滿足不了現在的業務需求！”
- “其它競品都有XXX功能，為什么我們不能加上去？”
- “這個地方經常會誤操作，能不能XXX這樣改進一下?。俊?/li>
諸如此類的話語，我相信大部分產品從業者都不陌生。業務方總是能從你不曾想到的角度提出問題。
不知道大家有沒有去探尋過背后深層次的原因？
我思考的結論是，業務人員會對系統形成依賴性。
有的業務人員認為什么問題都可以靠系統解決，更為夸張地是覺得任何問題都是因為系統不完善導致的。
產品經理的腦子一定要清醒，不要因為業務方的強勢而妥協。
比如運營部常常會說我需要一個XXX營銷功能，如果沒有這個功能，我們這個階段的指標就無法完成。
這樣的需求我聽到過N次，但當問到他們具體的運營目標、預期的ROI是多少時？絕大多數時候運營方都無法回答出來。
這就屬于典型的把業務問題甩給產品來解決。即便產品做了，后續依然會甩鍋到功能做得不夠好。
所以業務方提需求時，一定要先讓他們意識真正的問題是什么。
寫在最后
?很多人問過我比較擅長什么類型的產品，其實我并不覺得一定要局限在某一類產品。
兩年前我會想在某一個領域深挖，但現在思考更多的是產品背后的方法論。
產品的道是思維，產品的術是方法。不管什么類型的產品，只要掌握了道與術都應該能夠做好。
那些優秀的人一直在不斷突破自我的邊界并實現自我的價值。
#專欄作家#
東東方，微信公眾號：UnknownPM，人人都是產品經理專欄作家。關注互聯網新動態，致力于產品知識體系的構建，不定期分享產品心得。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
大佬以上的思維、方法論內容是有什么書籍推薦學習不？
非常有用，謝謝
大象UML 一本就夠了
已經在看了，多謝推薦~
每次看這種文章感覺很有東西，明天起來睡一覺估計就忘了。
寫的很棒，學到了