產品經理方法論——流程與審批流的區別
好的流程之于公司運營,能夠降低運營成本,提升工作效率;而對于產品,則能高效地幫用戶解決問題。本文作者介紹了產品設計中常見的業務流程、產品流程和審批流,一起來看一下吧。
今天我們來說下產品經理方法論基礎篇之流程。
分類相對來說是靜態的,但事物是發展變化的,這個變化的過程通常是按時間的先后順序,一步一步演化,期間會出現一些里程碑式的節點。在產品設計中,我們把這個變化過程叫做流程。(當然流程也可以看成是一種分類,或者分類后的排序,但對于產品設計來說,流程設計的頻率和重要性又十分突出,所以很有必要單列出來說一下。)
好的流程之于公司運營,能夠降低運營成本,提升工作效率。好的流程之于產品,更符合用戶的行為習慣,簡單高效地幫用戶解決問題。
接下來我們分別介紹產品設計中常見的:業務流程、產品流程、審批流(流程引擎)。
一、業務流程
業務流程展示的是一個公司或者行業,業務如何運轉的流程。不同的行業,不同的公司,甚至不同的商品,在不同的時間(比如淡旺季、節假日)、空間(比如城市),具體運轉的流程又會有它們各自的特點。市場上對不同行業的產品經理的定義,主要指這個產品經理熟悉哪個行業的業務流程。
一般情況下產品經理基于對所在行業現有的業務流程的理解,去設計產品。有的時候也需要產品經理基于自己對行業現狀、問題、痛點的理解,去重新設計業務流程;有些大企業會請咨詢公司做業務流程的優化,然后引入IT系統將方案落地。
剛入行的產品經理,建議可以從商學四流(電子商務)開始,商學四流是一個基于商品流通行業流程的概括,也可以叫商品的進銷存,適用于電商,制造業,新零售,供應鏈等等。而且很多其他的行業,也可以基于商學四流來類比設計,因為所有的行業都是基于銷售商品和服務展開的,區別只在于,不同的商品和服務本身具有的特性,如是否是實物,是否需要采購等。
商學四流:
1)商流,商品的采購和銷售。
商品的采購過程(SRM):確定采購目標,選擇供貨方(競價,招投標等),簽訂購銷合同,商品檢驗和驗收,組織商品入庫和貨款結算;
商品的銷售過程(CRM):商品銷售的方式很多,傳統的分銷,直銷;互聯網的電商,直播帶貨等,不同商品,不同的銷售方式有不同的流程。這里簡單講下,大致可以分為:找到目標客戶產品推薦,簽訂銷售合同,交付商品,收款。
2)物流,是指商品流通,包括商品的存儲和運輸。
3)資金流,是指商品從生成領域向消費領域轉移的過程中產生的資金運動過程。主要包括資金籌集,資金使用,資金耗費,資金補償與積累分配等活動。比較重要的點我覺得就是收款,支持,賬戶與賬戶余額。
4)信息流,一切都是信息,都需要被記錄下來。信息是客觀世界中各種食物的變化和特征的反映(推薦香農的《信息論》)。商業信息流是指反映商流、物流歷史與顯示運動以及發展變化趨勢的各種信息,情報,資料的收集、處理和傳遞的過程。包括商流信息流、物流信息流、資金信息流。
二、產品流程
基于業務設計業務流程,基于業務流程設計產品。常見的產品流程:功能流程和頁面流程。
1)功能流程
產品經理基于對業務流程的理解,設計產品的功能,用戶按步驟操作完成業務。通常在設計功能流程的時候,我們都會從用戶的視角出發來設計,所以功能流程通常也叫用戶流程。
常見的用戶流程,比如登錄流程、注冊流程、注銷流程、支付流程、下單流程等。
如:用戶注冊流程。
C端產品大多數情況用戶都是單角色的,所以整個用戶流程都是某個用戶自己的操作流程。但是B端產品則都是多角色,多用戶參與的,所以B端產品的用戶流程大都是分角色流程,通常我們會用泳道圖。
2)頁面流程
在產品設計過程中,我們還會用到頁面流程。頁面流程就是把頁面之間的跳轉關系通過流程圖表示出來。是用戶流程的具化(頁面化)表現形式。在原型設計和制作培訓材料時經常會用到。
三、審批流與流程引擎
在設計B端產品時,不管是什么類型的業務、系統、功能模塊,基本都逃不開流程審批的功能。比較常見的如公司的OA系統。Office Automation,即辦公自動化,這類系統主要實現了審批流程的自動化。如報銷、借款、合同、事務申請、人事、權限申請、固定資產申請等流程。再比如電商系統中常見的退款流程,可能也需要商家(或者商家的財務人員)審批。
審批流是指對某項工作的審批活動的有序組合。簡單說就是一件事情,是否要執行,相關決策人可以在線審批的功能。審批流不等于業務流程,但屬于業務流程,若干審批流,在系統里面作為業務流程產品化的一部分,支撐業務流程有序運轉。
審批流是流程,更是功能。
又由于通常這些審批流會隨著業務變化、組織結構調整需要頻繁的修改;不同的系統和功能模塊都會需要審批功能;于是從技術實現以及方便維護的角度出發,就有了流程引擎。
流程引擎是一個可以對審批流進行創建,修改,刪除,查詢的服務。它本身就是一個獨立的系統。
在設計B端產品的審批功能時引入流程引擎,好處多多:
- 作為共享服務,公司內部開發的不同的業務系統,都可以復用該服務。
- 流程的維護很方便,尤其是對節點的增刪修改,基本都不需要開發介入。
- 新的流程,開發工作量也能大幅減少。
- 讓審批功能設計的規范化變得簡單,不至于一個系統,不同的產品經理設計出不同的風格。
當然并不是任何需要審批的系統都需要使用流程引擎,簡單的審批功能直接開發即可??梢愿鶕景l展的階段,信息化系統建設的復雜程度,適時引入流程引擎。
還有一個常見的叫表單引擎,它常會和流程引擎同時出現,只不過表單引擎不是必須的。因為表單引擎主要的作用是方便用戶自定義需要決策者審批的內容。
內容即數據,很多時候業務數據需要存在業務系統中的數據庫中,而如果使用表單引擎就需要額外處理自定義表單中字段和數據庫中字段的關系。當然,在業務系統中同樣也存在很多數據,是不需要存在數據庫中的,這些數據除了需要被審批,被記錄外,未被規劃其他的用處。
(技術上對于上面兩種處理方式應該還有更深入的解釋,我按我的理解先講這些。另外表單引擎還會涉及前端頁面的展示,比如兼容PC端和手機端展示的自適應表單,同樣的在開發的時候可以選擇使用表單引擎來生成頁面或者嵌入到業務功能的頁面中。)
現在流行的低代碼平臺,核心也是流程引擎+表單引擎。流程引擎是一個很專業的產品分類,感興趣的同學可以找更多的資料深入學習下。
本文由 @李海鵬 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
建議先多學一些流程管理專業的知識以后再結合自己的經驗去整理輸出方法論。
感謝建議,我理解您說的流程管理專業知識,指的就是業務流程吧?
bpm,bpmn
BPM,全稱Business Process Management(業務流程管理)
BPMN 通常指的是 Business Process Model and Notation (業務流程模型與符號)
BPM 已經是一種固化的方法或者工具。是狹義的。
作為產品經理,應該從第一性原理出發,先從理解更廣義的,底層的,原始的,業務過程。再考慮使用什么樣的方法、工具來解決問題,甚至重新構建世界。
審批流只有簽字同意操作,變化的是需要多少人簽字,需要誰簽字,但是沒有具體執行操作,比如審批流里同意支付不代表真的支付完成了。系統功能流程是包含系統執行操作的,功能流程里的支付貨款就是真的付款出去了。業務流程又加上了人工線下的活動,比如付款完成后開始打包、物流配送。
太淺了,不是這樣分的。bpm2.0也叫工作流,是包含人參與交互的;另一種是服務編排,與業務無關,是計算機處理的邏輯流程,沒有人參與的交互,兩者可以交叉使用。
哈,感謝評論。我個人的認知確實是有限的,還不能用一篇文章來窮盡關于流程的全部。我盡量試著從初級產品經理的日常工作,以及用戶視角(非技術視角)來介紹常見的流程與審批流。產品經理每天都在思考分類,但這個世界在社會和人的視角是挺難窮盡的,但是要嘗試窮盡(擴大認知邊界),然后在應用范圍內盡可能的減少分支,以便于理解和應用。
b端產品經理越來越卷,只會設計業務功能的產品經理沒有未來。b端現在低代碼,對產品的要求很高。c端都在大公司,其他的通常都是做一些沒有什么價值的垃圾東西出來。
每個人成長階段不同,需要了解的東西也不同,公司發展階段,定位,管理者認知,都決定產品經理的工作方向。b端本來就是搬磚的,c端就像以前的銷售一樣,平臺很重要。
道可道,非常道,名可名,非常名。