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

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

一、需求分析過程

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

1. 接收需求

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

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

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

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

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

1）干系人重識別

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

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

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

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

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

4）流程重新梳理

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

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

3. 方案設(shè)計(jì)

3.1 核心方案

3.1.1 核心流程

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

3.1.2 功能模塊思考

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

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

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

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

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

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

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

3）未來功能拓展方向

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

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

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

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

3.1.3 演進(jìn)藍(lán)圖

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

3.2 方案細(xì)節(jié)

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

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

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

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

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

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

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

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

[上線前待辦計(jì)劃]

[驗(yàn)收用例梳理&實(shí)際驗(yàn)收處理方式]

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

二、崗位價(jià)值思考

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

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

1. 識別

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

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

2. 設(shè)計(jì)

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

3. 敏捷

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

4. 總結(jié)

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