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

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

一、需求分析過程

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

1. 接收需求

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

做了8年产品经理后，我是这么看产品经理的

我个人是从非常初级的产品经理做起，再到负责一个大产品的项目管理，现在有幸跳出了日常基础的工作更多的去看产品的PMF，product strategy...

查看详情 >

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

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

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

2. 需求理解和引導(dǎo)

1）干系人重識別

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

2）業(yè)務(wù)實踐調(diào)研

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

3）業(yè)務(wù)目的確認

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

4）流程重新梳理

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

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

3. 方案設(shè)計

3.1 核心方案

3.1.1 核心流程

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

3.1.2 功能模塊思考

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

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

1）當前流程是否相同：經(jīng)過分析發(fā)現(xiàn)，Q1不同、Q2&Q3則當前流程相同。

2）功能定位、主導(dǎo)方分析

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

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

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

3）未來功能拓展方向

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

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

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

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

3.1.3 演進藍圖

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

3.2 方案細節(jié)

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

經(jīng)過梳理，發(fā)現(xiàn)“F3：各種商品資料對應(yīng)落到樣品版本+更過程商品資料記錄”，需要處理的數(shù)據(jù)關(guān)系有如下。

進一步梳理數(shù)據(jù)關(guān)系：

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

在實踐中很難有完美又簡單的方案，也沒有統(tǒng)一標準答案，有的只有不斷的溝通和協(xié)調(diào)，不能試圖找一個永遠不變的方案，有可能方案做了半年一年要重構(gòu)，要做好這樣的準備，因為業(yè)務(wù)一直在變。

最終我們的方案打破了以上的預(yù)設(shè)框架，把品質(zhì)樣版本廢除，直接劃入生產(chǎn)資料中。

4排期、5上線、6復(fù)盤

這個環(huán)節(jié)要提供的分享方法不多，只分享一下實際操作中上線前的運營計劃、驗收用例、業(yè)務(wù)問題反饋跟進表格，屬于常規(guī)運營。

[上線前待辦計劃]

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

[上線后業(yè)務(wù)問題登記&處理反饋]

二、崗位價值思考

由于公司架構(gòu)原因，我司有單獨的產(chǎn)品經(jīng)理、產(chǎn)品運營（我這個崗位）、業(yè)務(wù)運營。在這個流程里，我也不斷思考，我和其它崗位的區(qū)別是什么，獨特的價值是什么？

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

1. 識別

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

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

2. 設(shè)計

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

3. 敏捷

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

4. 總結(jié)

以上三個價值點，決定了目前我所身處的產(chǎn)品運營崗位，比起業(yè)務(wù)運營要更理解業(yè)務(wù)運營要更能從宏觀視角識別問題、要更從系統(tǒng)落地的角度提供解決建議。比起產(chǎn)品經(jīng)理，則要具備溝通和協(xié)調(diào)的能力，統(tǒng)籌引導(dǎo)業(yè)務(wù)流程統(tǒng)一，讓業(yè)務(wù)進展更合理，減少一些非必要和后續(xù)要重復(fù)開發(fā)的、復(fù)雜的功能。