產品經理方法論——流程與審批流的區別

好的流程之於公司運營，能夠降低運營成本，提升工作效率；而對於產品，則能高效地幫使用者解決問題。本文作者介紹了產品設計中常見的業務流程、產品流程和審批流，一起來看一下吧。

今天我們來說下產品經理方法論基礎篇之流程。

分類相對來說是靜態的，但事物是發展變化的，這個變化的過程通常是按時間的先後順序，一步一步演化，期間會出現一些里程碑式的節點。在產品設計中，我們把這個變化過程叫做流程。（當然流程也可以看成是一種分類，或者分類後的排序，但對於產品設計來說，流程設計的頻率和重要性又十分突出，所以很有必要單列出來說一下。）

好的流程之於公司運營，能夠降低運營成本，提升工作效率。好的流程之於產品，更符合使用者的行為習慣，簡單高效地幫使用者解決問題。

接下來我們分別介紹產品設計中常見的：業務流程、產品流程、審批流（流程引擎）。

一、業務流程

業務流程展示的是一個公司或者行業，業務如何運轉的流程。不同的行業，不同的公司，甚至不同的商品，在不同的時間（比如淡旺季、節假日）、空間（比如城市），具體運轉的流程又會有它們各自的特點。市場上對不同行業的產品經理的定義，主要指這個產品經理熟悉哪個行業的業務流程。

一般情況下產品經理基於對所在行業現有的業務流程的理解，去設計產品。有的時候也需要產品經理基於自己對行業現狀、問題、痛點的理解，去重新設計業務流程；有些大企業會請諮詢公司做業務流程的最佳化，然後引入IT系統將方案落地。

剛入行的產品經理，建議可以從商學四流（電子商務）開始，商學四流是一個基於商品流通行業流程的概括，也可以叫商品的進銷存，適用於電商，製造業，新零售，供應鏈等等。而且很多其他的行業，也可以基於商學四流來類比設計，因為所有的行業都是基於銷售商品和服務展開的，區別只在於，不同的商品和服務本身具有的特性，如是否是實物，是否需要採購等。

商學四流：

1）商流，商品的採購和銷售。

商品的採購過程（SRM）：確定採購目標，選擇供貨方（競價，招投標等），簽訂購銷合同，商品檢驗和驗收，組織商品入庫和貨款結算；

商品的銷售過程（CRM）：商品銷售的方式很多，傳統的分銷，直銷；網際網路的電商，直播帶貨等，不同商品，不同的銷售方式有不同的流程。這裡簡單講下，大致可以分為：找到目標客戶產品推薦，簽訂銷售合同，交付商品，收款。

2）物流，是指商品流通，包括商品的儲存和運輸。

3）資金流，是指商品從生成領域向消費領域轉移的過程中產生的資金運動過程。主要包括資金籌集，資金使用，資金耗費，資金補償與積累分配等活動。比較重要的點我覺得就是收款，支援，賬戶與賬戶餘額。

4）資訊流，一切都是資訊，都需要被記錄下來。資訊是客觀世界中各種食物的變化和特徵的反映（推薦夏農的《資訊理論》）。商業資訊流是指反映商流、物流歷史與顯示運動以及發展變化趨勢的各種資訊，情報，資料的收集、處理和傳遞的過程。包括商流資訊流、物流資訊流、資金資訊流。

二、產品流程

基於業務設計業務流程，基於業務流程設計產品。常見的產品流程：功能流程和頁面流程。

1）功能流程

產品經理基於對業務流程的理解，設計產品的功能，使用者按步驟操作完成業務。通常在設計功能流程的時候，我們都會從使用者的視角出發來設計，所以功能流程通常也叫使用者流程。

常見的使用者流程，比如登入流程、註冊流程、登出流程、支付流程、下單流程等。

如：使用者註冊流程。

C端產品大多數情況使用者都是單角色的，所以整個使用者流程都是某個使用者自己的操作流程。但是B端產品則都是多角色，多使用者參與的，所以B端產品的使用者流程大都是分角色流程，通常我們會用泳道圖。

2）頁面流程

在產品設計過程中，我們還會用到頁面流程。頁面流程就是把頁面之間的跳轉關係透過流程圖表示出來。是使用者流程的具化（頁面化）表現形式。在原型設計和製作培訓材料時經常會用到。

三、審批流與流程引擎

在設計B端產品時，不管是什麼型別的業務、系統、功能模組，基本都逃不開流程審批的功能。比較常見的如公司的OA系統。Office Automation，即辦公自動化，這類系統主要實現了審批流程的自動化。如報銷、借款、合同、事務申請、人事、許可權申請、固定資產申請等流程。再比如電商系統中常見的退款流程，可能也需要商家（或者商家的財務人員）審批。

審批流是指對某項工作的審批活動的有序組合。簡單說就是一件事情，是否要執行，相關決策人可以線上審批的功能。審批流不等於業務流程，但屬於業務流程，若干審批流，在系統裡面作為業務流程產品化的一部分，支撐業務流程有序運轉。

審批流是流程，更

是功能。

又由於通常這些審批流會隨著業務變化、組織結構調整需要頻繁的修改；不同的系統和功能模組都會需要審批功能；於是從技術實現以及方便維護的角度出發，就有了流程引擎。

流程引擎是一個可以對審批流進行建立，修改，刪除，查詢的服務。

它本身就是一個獨立的系統。

在設計B端產品的審批功能時引入流程引擎，好處多多：

作為共享服務，公司內部開發的不同的業務系統，都可以複用該服務。

流程的維護很方便，尤其是對節點的增刪修改，基本都不需要開發介入。

新的流程，開發工作量也能大幅減少。

讓審批功能設計的規範化變得簡單，不至於一個系統，不同的產品經理設計出不同的風格。

當然並不是任何需要審批的系統都需要使用流程引擎，簡單的審批功能直接開發即可。可以根據公司發展的階段，資訊化系統建設的複雜程度，適時引入流程引擎。

還有一個常見的叫表單引擎，它常會和流程引擎同時出現，只不過表單引擎不是必須的。因為表單引擎主要的作用是方便使用者自定義需要決策者審批的內容。

內容即資料，很多時候業務資料需要存在業務系統中的資料庫中，而如果使用表單引擎就需要額外處理自定義表單中欄位和資料庫中欄位的關係。當然，在業務系統中同樣也存在很多資料，是不需要存在資料庫中的，這些資料除了需要被審批，被記錄外，未被規劃其他的用處。

（技術上對於上面兩種處理方式應該還有更深入的解釋，我按我的理解先講這些。另外表單引擎還會涉及前端頁面的展示，比如相容PC端和手機端展示的自適應表單，同樣的在開發的時候可以選擇使用表單引擎來生成頁面或者嵌入到業務功能的頁面中。）

現在流行的低程式碼平臺，核心也是流程引擎+表單引擎。流程引擎是一個很專業的產品分類，感興趣的同學可以找更多的資料深入學習下。

本文由 @李海鵬 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。