【產品梳理篇】ToB產品生命周期的不同階段，產品經理的階段目標和關鍵任務（二）每個TOB生命周期階段都有著其應該對齊的目標及其關鍵任務，本文就產品方案設計階段的目標和關鍵任務展開分析，詳細介紹產品可執(zhí)行落地的全過程，希望帶給你一些啟發(fā)。上一篇分享了B端產品的“產品規(guī)劃與調研”階段的目標和關鍵任務，本篇將分享“產品方案設計”階段的目標與任務。這階段承接產品規(guī)劃，將整體規(guī)劃細化落地，形成可落地執(zhí)行的產品方案。在這個階段也是對產品經理基本能力的考驗，包括：需求轉化能力、復雜邏輯處理能力、文檔輸出能力等。一、產品方案設計目標：梳理業(yè)務流程，形成滿足需求且可落地的解決方案。關鍵任務：1.業(yè)務流程梳理：各模塊業(yè)務涉及哪些不同部門不同角色的人員，各人員需要負責哪些業(yè)務首先，需要明白什么是“業(yè)務流程”，與之相對應的是“系統(tǒng)流程”。業(yè)務流程：為達到特定的價值目標而由不同的人分別共同完成的一系列活動?；顒又g不僅有嚴格的先后順序限定，而且活動的內容、方式、責任等也都必須有明確的安排和界定（百度釋義）。簡而言之，業(yè)務流程的梳理就是了解完成某一特定業(yè)務，不同業(yè)務人員需要先后負責完成哪些“任務”。如：為了完成合同的審核，需要由銷售人員起草合同，提交后經銷售總監(jiān)對合同產品報價確認后，給到公司法務進行法務風險評估，再由高層領導進行審核確認。一個合同審核的業(yè)務流程，涉及了多個人員，包括：銷售、銷售總監(jiān)、法務、高層領導，每個角色的人員在合同審批的流程里面，有先后順序，也有各自需要確認的內容。對于業(yè)務流程，核心關注點在于“做什么”，即：不同角色的人員在流程的不同環(huán)節(jié)需要完成什么業(yè)務。系統(tǒng)流程：為完成特定的業(yè)務流程，不同人員需要在系統(tǒng)中完成一系列指定的操作，留存相關的數(shù)據(jù)。如：為了完成合同的審核，銷售人員需要在CRM系統(tǒng)中維護合同信息、合同產品報價；合同提交后，銷售總監(jiān)在CRM系統(tǒng)中對合同報價進行確認，報價有問題的在系統(tǒng)中進行修改；銷售總監(jiān)確認后，法務在CRM系統(tǒng)中進行確認，如有法務風險，則在系統(tǒng)中進行記錄；法務確認后，高層領導在OA系統(tǒng)中對合同進行審批。對于系統(tǒng)流程，核心關注點在于“怎么做”，即：不同角色的人員在哪個系統(tǒng)中需要完成什么操作。先有業(yè)務流程，再有系統(tǒng)流程，系統(tǒng)流程是將業(yè)務流程系統(tǒng)化的過程，這一過程也是將業(yè)務需求轉換成系統(tǒng)解決方案的過程。（1）如何梳理業(yè)務流程？①明確業(yè)務目標是什么確認業(yè)務目標，即：明確業(yè)務范圍，確定需要了解的業(yè)務流程是什么。對于業(yè)務流程的范圍，可以定義地很廣泛，也可以定義得很聚焦，比如：企業(yè)從生產到銷售到服務的過程可以定義為一個業(yè)務流程；但是拆分出來，產品的生產過程、訂單的下單流程也可以分別定義成一個業(yè)務流程。所以，當我們去梳理業(yè)務流程時，需要先明確流程的范圍，即流程的起點與終點。這個起點和終點是根據(jù)業(yè)務目標去確認的。如：當我們去探討“如何完成一份合同的制定與確認“，那么流程的起點就是合同的起草，流程的終點就是合同完成確認。②流程涉及哪些部門哪些角色的業(yè)務人員一個完整的業(yè)務流程中，需要涉及到哪些部門哪些角色的人員協(xié)同完成。以上面的合同審批為例，整個涉及到：銷售部的銷售員、銷售總監(jiān)；法務部的法務顧問；高層領導；注意：梳理涉及的業(yè)務人員時，需要盡量梳理出這些人員對應的職位或者職責（如：銷售業(yè)務員、銷售總監(jiān)），而非具體的人員（如：張三、李四）。因為具體的人員因調崗、辭職等原因，變化頻率時比較高的，但是職位或者職責是相對固定的。③梳理不同角色人員要完成哪些“任務”業(yè)務流程中，不同的人員需要完成哪些業(yè)務。以上面的合同審批為例：銷售員：合同信息錄入、合同提交審核銷售總監(jiān)：審核合同產品報價法務顧問：確認合同法務風險高層領導：合同審批④各“任務”之間的關系、規(guī)則明確各“任務”之前的先后、分支、判斷等關系，根據(jù)“任務”的順序與規(guī)則，將各人員的“任務”串連起來便是完整的業(yè)務流程。（2）“業(yè)務流程的梳理兩大原則”“有始有終”：根據(jù)業(yè)務目標確認業(yè)務流程范圍，保證業(yè)務流程可以閉環(huán)，不能中途戛然而止。以上文的合同審核為例，探討“如何完成一份合同的制定與確認“，那么該流程不能法務部確認完之后就終止。在這個環(huán)節(jié)，合同并沒有真正完成確認。當然，流程的終點需要匹配業(yè)務目標，如果是探討“如何完成合同的起草”，那么上述的流程在法務確認后終止卻也可以說通?！坝兴∩帷保簩τ诿枋鰳I(yè)務流程的顆粒度需要有所取舍，不可太過細致，也不可太過粗糙，應以“能夠清晰描述流程，指導業(yè)務順暢流轉”為原則。以上文的合同審核為例，“合同信息錄入”這一節(jié)點，并沒有細致地去描述錄入合同時需要錄入合同哪些信息、是否需要上傳電子合同等。描述業(yè)務流程的顆粒度，有時也需要結合查看人的需求。如果是管理層查看，可能并不關心太過流程細節(jié)，更關系流程的流轉和關鍵管控點；如果是執(zhí)行層查看，那么可能更關心細節(jié)，細致到如何能完成各個“任務”，如何完成工作直接影響到執(zhí)行層每日的工作量。（3）如何輸出業(yè)務流程圖？業(yè)務流程圖的輸出沒有固定的形式，可使用普通流程圖或者泳道圖或者其他圖示方式進行呈現(xiàn)。推薦使用泳道圖進行展示。泳道圖：泳道圖可使用Visio（本地軟件）、ProcessOn（在線平臺）進行繪制；泳道圖一般分為三個維度：職位維度、階段維度和任務維度。職位維度：通過部門/職位進行區(qū)分，不同部門不同角色得人各用一條泳道進行區(qū)分；如下圖中橫向排布的泳道。（不建議通過責任人進行區(qū)分，如：張三/李四。因為責任人可能因為職務變化、辭職等原因頻繁變化）階段維度：通過任務階段來區(qū)分，明確各階段需要處理的任務環(huán)節(jié)；如下圖中縱向排布的泳道。（非必要維度，可視個人繪制習慣而定）任務維度：不同部門/職位的業(yè)務人員在不同階段需要處理的任務；如下圖中的各流程節(jié)點。2.系統(tǒng)流程梳理：將業(yè)務流程轉換成系統(tǒng)流程，形成可執(zhí)行的、高效的、貼合需求的系統(tǒng)流程（1）如何梳理系統(tǒng)流程？①劃分系統(tǒng)邊界對于流程各環(huán)節(jié)，需要先劃分哪些“任務”需要在哪個系統(tǒng)中完成，明確各系統(tǒng)功能邊界。以上訴合同流程為例，可以將合同流程各環(huán)節(jié)劃分到不同業(yè)務系統(tǒng)，合同起草、合同報價確認、法務風險確認在CRM中完成；合同審核在OA系統(tǒng)中完成；合同產品生產、入庫出庫、物流運輸、物流簽收可在ERP系統(tǒng)中完成。系統(tǒng)邊界的劃分，需要匹配不同業(yè)務系統(tǒng)的定位以及當前產品的產品定位。如果是標準產品開發(fā)，則需要盡量減少對外部系統(tǒng)的依賴，盡量在本系統(tǒng)中完成業(yè)務流程的流轉。否則，當產品銷售時，如果高度依賴其他系統(tǒng)才能完成業(yè)務流程的運轉，那么就需要與其他系統(tǒng)打包銷售，這將降低產品的競爭力。當然，這也需要和公司產品策略相結合，如果產品策略是希望整合多套產品形成整體解決方案，那么各系統(tǒng)的邊界則需要根據(jù)不同產品的定位來劃分。如果是客戶定制化產品/項目開發(fā)，則需要根據(jù)客戶內部業(yè)務系統(tǒng)定位進行劃分。②明確各業(yè)務環(huán)節(jié)的系統(tǒng)管控點由于業(yè)務流轉的需要、管理的要求或者其他原因，對于業(yè)務流程中關鍵節(jié)點，業(yè)務上會有一些管控要求。如：合同錄入時，需要必須上傳合同附件，電子附件可以作為流程審批的依據(jù)，也可以在線上進行留存，方便后期查看。類似這部分業(yè)務管控要求，在系統(tǒng)流程設計時需要形成系統(tǒng)管控點。③確定各系統(tǒng)數(shù)據(jù)交互的觸發(fā)節(jié)點明確單據(jù)在各業(yè)務系統(tǒng)之間流轉的觸發(fā)節(jié)點，即：什么環(huán)節(jié)可以將數(shù)據(jù)同步推送至其他業(yè)務系統(tǒng)。如：CEO確認合同審批通過時，將合同同步至ERP系統(tǒng)進行生產。④明確各系統(tǒng)數(shù)據(jù)的回傳同步單據(jù)在其他業(yè)務系統(tǒng)流轉過程中，部分單據(jù)信息可能需要回傳同步至源系統(tǒng)。如：合同同步至OA系統(tǒng)審批后，審批結果（通過？拒絕）需要同步回傳至CRM系統(tǒng)中，銷售業(yè)務員可以及時了解合同審批情況；合同產品交付到ERP系統(tǒng)生產后，生產相關進度可能也需要同步回CRM系統(tǒng)中，對于銷售人員而言，可及時了解到合同交付情況。（2）如何輸出系統(tǒng)流程？系統(tǒng)流程同樣可以使用泳道圖進行輸出，下方為示例：與業(yè)務流程繪制的區(qū)別在于兩點：維度不同：業(yè)務流程的一般是職位維度、階段維度和任務維度；系統(tǒng)流程的維度一般是職位維度、系統(tǒng)維度和任務維度。即：系統(tǒng)流程描述了哪個職位的業(yè)務人員需要在什么系統(tǒng)完成哪些任務。顆粒度不同：系統(tǒng)流程會比較細致地某一流程在系統(tǒng)中如何完成，以達到指導業(yè)務用戶順暢完成業(yè)務的目的。業(yè)務流程對于較細致的流程管控點并不一定會進行描述，系統(tǒng)流程則會較為細致地描述流程管控點及相關處理方式。3.解決方案制定：結合產品目標、需求范圍、業(yè)務流程等，形成解決方案解決方案并非產品的PRD文檔，而是用于向客戶/用戶介紹產品、介紹方案的介紹性文檔，通常以PPT的方式呈現(xiàn)。標準產品研發(fā)的過程中，不一定會需要產出解決方案，而是使用PRD文檔描述需求與需求解決方案。對于客戶定制化項目/產品，多數(shù)情況下需要輸出項目解決方案，向客戶方業(yè)務人員（包括管理層、執(zhí)行層）介紹項目整體方案內容，約定產品需求與范圍。（1）如何編寫解決方案？①了解方案匯報場景及匯報對象不同的匯報場景匯報對象，解決方案的側重點不同。對客戶管理層匯報，會側重于講解業(yè)務管理方案、管理流程、項目價值等；對業(yè)務執(zhí)行層匯報，則會側重于講解系統(tǒng)流程、業(yè)務管控點等。所以，在編寫解決方案前，需要先了解匯報的場景及對象，以明確方案編寫的側重點。②方案需要呈現(xiàn)哪些內容（這里提供項目解決方案編寫的基本框架思路）項目概述：主要介紹項目背景、企業(yè)現(xiàn)狀，核對項目目標。項目概述篇是對整個項目定調的篇章，需要熟悉當前項目的背景、企業(yè)現(xiàn)狀、業(yè)務流程等。尤其需要關注企業(yè)高層領導對當前項目的看法與期待。高層領導對于當前項目未來能在企業(yè)的業(yè)務流程中扮演的角色和作用，是項目目標的核心提煉點，也是后續(xù)指導項目實施方向的關鍵因素。整體業(yè)務解決方案：介紹基于項目目標、企業(yè)現(xiàn)狀的整體業(yè)務管理方案。結合項目目標和當前企業(yè)現(xiàn)狀，對企業(yè)現(xiàn)有流程提出優(yōu)化管理方案。核心是介紹新的管理流程、管理方案，輸出整體業(yè)務規(guī)劃藍圖、產品架構等。詳細功能設計方案：按業(yè)務流程分模塊講解各業(yè)務板塊的流程、產品功能等。

根據(jù)各模塊的業(yè)務流程、系統(tǒng)流程講解模塊功能設計，可包括：業(yè)務痛點、業(yè)務流程、系統(tǒng)流程、字段模型、權限設計、業(yè)務管控點、核心功能等。對于整體業(yè)務解決方案和詳細功能設計方案的內容占比和編寫的細致顆粒度，需要根據(jù)匯報對象進行權衡。當匯報對象是高層領導、管理層時，核心在于整體業(yè)務解決方案的介紹，詳細功能介紹則介紹流程、管控點、核心功能即可，整體篇幅也應以業(yè)務解決方案為主。當匯報對象主要是執(zhí)行層時，整體業(yè)務解決方案的占比則可以適當減少，詳細功能設計可寫得更細致，可包括：系統(tǒng)流程、管控點、核心功能、字段模型、數(shù)據(jù)權限等。除了上訴的介紹內容外，項目解決方案還可能會添加：項目實施計劃、項目團隊、項目風險等。這些內容可視實際情況添加。4.產品版本劃分：劃定產品MVP版本，確定產品MVP版本需求及后續(xù)迭代路線MVP版本：最簡化可實行產品。MVP版本這個詞，在標準產品研發(fā)的過程中會聽到多，說得淺顯可理解一些，即是：通過較短的開發(fā)周期快速實現(xiàn)產品的基礎功能，能夠快速進入市場。隨后通過獲取市場反饋，不斷迭代優(yōu)化產品。對于客戶定制化項目/產品，很少會有MVP版本的概念，在項目立項時，就已經有基本明確的項目周期、需求范圍。即使會有分版本迭代上線的情況，劃分版本的依據(jù)更多的是根據(jù)客戶需求的緊急程度來做劃分。那么，標準產品研發(fā)如何進行MVP版本的劃分?①明確產品目標，清晰了解產品需求產品版本/迭代路線的規(guī)劃，需要基于產品目標和產品需求去進行劃分，對于各產品需求需要清晰了解需求背景、需求內容才能準確地定義清楚需求涉及范圍、需求優(yōu)先級。②確定產品最簡業(yè)務流程基于產品主流程進行簡化，在保證業(yè)務流程閉環(huán)的情況下，盡量減少業(yè)務流程環(huán)節(jié)，將一些非必須的周邊環(huán)節(jié)均可歸入迭代優(yōu)化版本。簡化業(yè)務流程基本原則（以產品規(guī)劃篇中講解的車企銷售線索管理為例）：沒有破壞產品目標的功能，不做；銷售線索管理模塊目標：與外部獲客渠道打通，實現(xiàn)線索從獲取-跟進-轉化的全過程管理。下面列舉幾個線索模塊的需求做示例：對接外部獲客渠道（如：易車網、懂車帝、抖音等）：線索獲取的核心功能，需要規(guī)劃進MVP版本。但可考慮優(yōu)先對接使用頻率最高的渠道或者使用EXCEL導入線索的方式暫時不做平臺對接。銷售線索查重：線索獲取核心功能，需要規(guī)劃進MVP版本。銷售線索價值評估：線索獲取的非核心功能，不影響產品目標，不做。線索分配功能：線索跟進的核心功能，需要規(guī)劃進MVP版本。能夠暫時使用人工替代的功能，考慮不做；根據(jù)線索相關信息自動分配銷售人員進行跟進，不做，可