樣品版本設計方案——案例分享(四)
怎樣做好流程優化?這篇文章里,作者與我們分享了一個與“樣品版本”相關的流程分析,并對這一案例做了詳細拆解,一起來看看作者是怎么做的,或許會對同為產品運營的你有所幫助或啟發。
結合自己之前總結的B端產品運營方法和最近學習的《決勝B端》的知識框架,分享下近期的流程優化案例。
一、需求分析過程
本次主要分享與“樣品版本”相關的一個流程分析。
1. 接收需求
近半年內接收到的與“樣品版本”這個版塊強相關的需求有3個,分別是“1成品樣變更線上化“、“2品質卡審核線上化”、“3樣品優化即時入庫”,我先讓業務提供了自己預期的流程圖、以及背景目的。
對于1&2,業務的需求非常簡單就是樣品審核的動作線上化,減少線下溝通,方便分析。
而“樣品優化即時入庫”的業務無法直接提供流程和背景,于是我們和業務一起梳理。無法提供流程的原因,是因為業務直接收到倉庫的要求,業務并不進一步知道背景(沒錯,有時候業務只管執行,沒有人或者沒有空進一步battle不合理性)。
經溝通后,了解倉庫要求目前不可以同時留多個樣品在庫,否則倉庫質檢時不知道借哪個樣品來檢查,所以就導致了業務在樣品審核后不可以將正確樣品入倉,當訂單到倉后又借不到最新樣品導致可能退貨的矛盾問題。本質原因是由于系統上缺乏確定性的訂單和樣品的對應關系記錄。
2. 需求理解和引導
1)干系人重識別
重新識別干系人是因為提需求給你的人,未必能覆蓋核心角色和所有相關部門。通過重新梳理,我們發現實際干系人大大超過我們以為的范圍。
2)業務實踐調研
通過重新識別的干系人,我們到業務現場重新調研實際操作流程,并對于重新調研的結果,重新組織新的干系人共識會。上面提及的干系人過泛的問題,經過和業務部門溝通,重新指定新的統籌人來對接,譬如業務部門2有3個子部門原本共6個人需要調研,縮減到由1個主要人員先進行統一對接,再對內進行傳達。
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. 總結
以上三個價值點,決定了目前我所身處的產品運營崗位,比起業務運營要更理解業務運營要更能從宏觀視角識別問題、要更從系統落地的角度提供解決建議。比起產品經理,則要具備溝通和協調的能力,統籌引導業務流程統一,讓業務進展更合理,減少一些非必要和后續要重復開發的、復雜的功能。
本文由 @我叫更更 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!