怎樣做好流程優化？這篇文章里，作者與我們分享了一個與“樣品版本”相關的流程分析，并對這一案例做了詳細拆解，一起來看看作者是怎么做的，或許會對同為產品運營的你有所幫助或啟發。

結合自己之前總結的B端產品運營方法和最近學習的《決勝B端》的知識框架，分享下近期的流程優化案例。

一、需求分析過程

本次主要分享與“樣品版本”相關的一個流程分析。

1. 接收需求

近半年內接收到的與“樣品版本”這個版塊強相關的需求有3個，分別是“1成品樣變更線上化“、“2品質卡審核線上化”、“3樣品優化即時入庫”，我先讓業務提供了自己預期的流程圖、以及背景目的。

對于1&2，業務的需求非常簡單就是樣品審核的動作線上化，減少線下溝通，方便分析。

而“樣品優化即時入庫”的業務無法直接提供流程和背景，于是我們和業務一起梳理。無法提供流程的原因，是因為業務直接收到倉庫的要求，業務并不進一步知道背景（沒錯，有時候業務只管執行，沒有人或者沒有空進一步battle不合理性）。

經溝通后，了解倉庫要求目前不可以同時留多個樣品在庫，否則倉庫質檢時不知道借哪個樣品來檢查，所以就導致了業務在樣品審核后不可以將正確樣品入倉，當訂單到倉后又借不到最新樣品導致可能退貨的矛盾問題。本質原因是由于系統上缺乏確定性的訂單和樣品的對應關系記錄。

2. 需求理解和引導

1）干系人重識別

重新識別干系人是因為提需求給你的人，未必能覆蓋核心角色和所有相關部門。通過重新梳理，我們發現實際干系人大大超過我們以為的范圍。

2）業務實踐調研

通過重新識別的干系人，我們到業務現場重新調研實際操作流程，并對于重新調研的結果，重新組織新的干系人共識會。上面提及的干系人過泛的問題，經過和業務部門溝通，重新指定新的統籌人來對接，譬如業務部門2有3個子部門原本共6個人需要調研，縮減到由1個主要人員先進行統一對接，再對內進行傳達。

3）業務目的確認

在干系人共識會上，我們重新與業務確認了需求要解決的目的。

4）流程重新梳理

同時，在干系人共識會上，也重新跟業務共識所有識別到的需求范圍，及其系統流程。我們識別到幾個重要點與業務重新確認。

1. 需求會分階段實現，因為功能之間有因果關系。
2. 存在業務未提供的需求內容，需要拓展需求范圍，開發時間會增加。
3. 最終功能實現未必按照業務最初設想（比如成品樣業務是提供兩套流程，但我們基于開發相似性可能會合并）。
4. 有些內容更適合線下操作，線上不加入該流程（例如占比過少的實驗室檢測流程）。

3. 方案設計

3.1 核心方案

3.1.1 核心流程

實際操作中，是針對2.4進行刪繁就簡&狀態機梳理。本次案例說明為方便陳述已經刪繁就簡，基本內容同2.4，不再贅述。

3.1.2 功能模塊思考

在這里我們遇到了三個模塊合并方案問題，因為如果所有流程都按照最小顆粒度去做流程，會存在很多模塊耦合，需要考慮按照什么維度去合并?？梢允崂淼姆较蛴?個，分別為“成品樣泛變更、首次審核、品質卡審核”。

于是我們從“未來延展性”出發，再細分三個角度思考哪些模塊最終應該合并。

1）當前流程是否相同：經過分析發現，Q1不同、Q2&Q3則當前流程相同。

2）功能定位、主導方分析

Q1成品樣泛變更：目的是審核非正常變更樣品，業務上會盡量避免（因為丟失、或者不得不替換），主導方是“審核部”；成品樣優化的定位，是對好賣但品質問題商品進行迭代，業務上“盡量多，且由最源頭廠商發起”，主導方是對銷量負責的“業務部2”。

Q2首次審核：定位都是新樣品審核，只是審核類型不同，但主導方都是“審核部”。

Q3品質卡審核：首次審核和變更審核定位不同，一個是新樣品，一個要替換的樣品，主導方都是“審核部”。雖然在業務溝通中審核部一直希望Q3兩個版塊進行融合，但是基于Q2的結論，還是讓步于將Q2的兩個樣品審核優先融合，否則未來改造問題比較多。經溝通后也同意，因為理論上品質卡變更要減少，并非常規流程。

3）未來功能拓展方向

Q1：基于功能定位考慮，可預想Q1兩個模塊未來的數據來源、展現形式會呈現比較大的差別。成品樣變更會更傾向于“發起限制、流程合規”，而成品樣優化會更傾向“鼓勵發起、發起后效果比照”。

Q2：不會有太大變化，都只是正常商品發起流程，能走完即可。

Q3：品質卡變更會與“成品樣變更”流程更融合，因為都是合規操作。而品質卡新卡審核也會跟成品樣首次審核更容易，確保能走完即可。兩者走向明顯不同。

最終結論：基于以上三點綜合分析，決定只將Q2兩個功能融合，其它兩個則進行區分。

3.1.3 演進藍圖

在本流程中，主要跟業務共識如何分階段實現功能、每個階段大概多久、功能模塊業務是否認可。

3.2 方案細節

在《決勝B端》一書中，方案細節涉及到以下幾個內容“業務數據建模/流程和角色/界面設計/報表設計/數據埋點/權限設計/文檔編寫與管理/UML和常用圖表”。本案例中由于F1&F2的上述細節都比較簡單，不展開說明，只針對F3中爭議比較大的“ER圖”方案進行分享。

經過梳理，發現“F3：各種商品資料對應落到樣品版本+更過程商品資料記錄”，需要處理的數據關系有如下。

進一步梳理數據關系：

其中難點在于處理“SKU、Yn&yn、Zn”的關系，經過分析進一步發現其中不明確的主要是“當SKU同時要參考Y和y（成品樣+品質卡）時，商品資料如何處理”，我們提出多個方案和產品業務討論，看哪個方案既能解決業務問題，又盡量簡化產品模型。

在實踐中很難有完美又簡單的方案，也沒有統一標準答案，有的只有不斷的溝通和協調，不能試圖找一個永遠不變的方案，有可能方案做了半年一年要重構，要做好這樣的準備，因為業務一直在變。

最終我們的方案打破了以上的預設框架，把品質樣版本廢除，直接劃入生產資料中。

4排期、5上線、6復盤

這個環節要提供的分享方法不多，只分享一下實際操作中上線前的運營計劃、驗收用例、業務問題反饋跟進表格，屬于常規運營。

[上線前待辦計劃]

[驗收用例梳理&實際驗收處理方式]

[上線后業務問題登記&處理反饋]

二、崗位價值思考

由于公司架構原因，我司有單獨的產品經理、產品運營（我這個崗位）、業務運營。在這個流程里，我也不斷思考，我和其它崗位的區別是什么，獨特的價值是什么？

我總結了一下三個點，不是行業通用區別，只基于我司崗位要求和職責做分析，僅供參考~

1. 識別

業務運營負責梳理自己理想的業務流程，而我們則要根據業務的理想，識別清楚業務真實的目的、要解決什么問題、業務提供的流程是否真的能快速解決業務問題？會否只考慮自己部門的操作而影響了其它配合部門的便捷性，是否會降低整體操作流程的順暢度（例如需求2會加入目前影響不大的必要流程）。

甚至有的時候，業務都不一定知道自己要解決什么根本問題（例如需求3），不能提出解決方案，只是提供了某個問題點。

2. 設計

識別出問題后，我們要幫助業務規劃和設計切實落地的方案流程，達到業務需要的結果。在這個流程中，我們識別出版本關系這個需求，這個是業務不會提供的，因為他們能看到表面問題，不一定能知道內在設置有什么關鍵卡點。我們對于流程的設置區別于產品經理在于，產品要集中全力設計功能模塊和如何快速實現，而我們產品運營角色則要統籌業務方的訴求和矛盾。

3. 敏捷

有了方案，我們還要幫業務規劃節奏、要快速解決主要矛盾、要跟產品開發要資源，要一起快速解決業務問題。在本次案例中，業務最迫切 需求是線上化，于是我們也先幫業務解決線上化的流程，同時梳理復雜的版本資料邏輯，這樣多個方案可以并行，盡量提高上線效率。而產品經理則根據我們提供的流程，尋找技術上快速實現的方法，我們的敏捷在于業務模塊節奏，產品經理敏捷在于技術實現

4. 總結

以上三個價值點，決定了目前我所身處的產品運營崗位，比起業務運營要更理解業務運營要更能從宏觀視角識別問題、要更從系統落地的角度提供解決建議。比起產品經理，則要具備溝通和協調的能力，統籌引導業務流程統一，讓業務進展更合理，減少一些非必要和后續要重復開發的、復雜的功能。