每個TOB生命週期階段都有著其應該對齊的目標及其關鍵任務，本文就產品方案設計階段的目標和關鍵任務展開分析，詳細介紹產品可執行落地的全過程，希望帶給你一些啟發。

上一篇分享了B端產品的“產品規劃與調研”階段的目標和關鍵任務，本篇將分享“產品方案設計”階段的目標與任務。這階段承接產品規劃，將整體規劃細化落地，形成可落地執行的產品方案。在這個階段也是對產品經理基本能力的考驗，包括：需求轉化能力、複雜邏輯處理能力、文件輸出能力等。

一、產品方案設計

目標：梳理業務流程，形成滿足需求且可落地的解決方案。

關鍵任務：

1。 業務流程梳理：各模組業務涉及哪些不同部門不同角色的人員，各人員需要負責哪些業務

首先，需要明白什麼是 “業務流程”，與之相對應的是 “系統流程”。

業務流程： 為達到特定的價值目標而由不同的人分別共同完成的一系列活動。活動之間不僅有嚴格的先後順序限定，而且活動的內容、方式、責任等也都必須有明確的安排和界定（百度釋義）。簡而言之，業務流程的梳理就是了解完成某一特定業務，不同業務人員需要先後負責完成哪些“任務”。

如：為了完成合同的稽核，需要由銷售人員起草合同，提交後經銷售總監對合同產品報價確認後，給到公司法務進行法務風險評估，再由高層領導進行稽核確認。一個合同稽核的業務流程，涉及了多個人員，包括：銷售、銷售總監、法務、高層領導，每個角色的人員在合同審批的流程裡面，有先後順序，也有各自需要確認的內容。

對於業務流程，核心關注點在於“做什麼”，即：不同角色的人員在流程的不同環節需要完成什麼業務。

系統流程：為完成特定的業務流程，不同人員需要在系統中完成一系列指定的操作，留存相關的資料。

如：為了完成合同的稽核，銷售人員需要在CRM系統中維護合同資訊、合同產品報價；合同提交後，銷售總監在CRM系統中對合同報價進行確認，報價有問題的在系統中進行修改；銷售總監確認後，法務在CRM系統中進行確認，如有法務風險，則在系統中進行記錄；法務確認後，高層領導在OA系統中對合同進行審批。

對於系統流程，核心關注點在於“怎麼做”，即：不同角色的人員在哪個系統中需要完成什麼操作。

先有業務流程，再有系統流程，系統流程是將業務流程系統化的過程，這一過程也是將業務需求轉換成系統解決方案的過程。

（1）如何梳理業務流程？

①明確業務目標是什麼

確認業務目標，即：明確業務範圍，確定需要了解的業務流程是什麼。

對於業務流程的範圍，可以定義地很廣泛，也可以定義得很聚焦，比如：企業從生產到銷售到服務的過程可以定義為一個業務流程；但是拆分出來，產品的生產過程、訂單的下單流程也可以分別定義成一個業務流程。

所以，當我們去梳理業務流程時，需要先明確流程的範圍，即流程的起點與終點。這個起點和終點是根據業務目標去確認的。如：當我們去探討“如何完成一份合同的制定與確認“，那麼流程的起點就是合同的起草，流程的終點就是合同完成確認。

②流程涉及哪些部門哪些角色的業務人員

一個完整的業務流程中，需要涉及到哪些部門哪些角色的人員協同完成。以上面的合同審批為例，整個涉及到：銷售部的銷售員、銷售總監；法務部的法務顧問；高層領導；

注意：梳理涉及的業務人員時，需要儘量梳理出這些人員對應的職位或者職責（如：銷售業務員、銷售總監），而非具體的人員（如：張三、李四）。因為具體的人員因調崗、辭職等原因，變化頻率時比較高的，但是職位或者職責是相對固定的。

③梳理不同角色人員要完成哪些“任務”

業務流程中，不同的人員需要完成哪些業務。以上面的合同審批為例：

銷售員：合同資訊錄入、合同提交稽核

銷售總監：稽核合同產品報價

法務顧問：確認合同法務風險

高層領導：合同審批

④各“任務”之間的關係、規則

明確各“任務”之前的先後、分支、判斷等關係，根據“任務”的順序與規則，將各人員的“任務”串連起來便是完整的業務流程。

（2）“業務流程的梳理兩大原則”

“有始有終”：根據業務目標確認業務流程範圍，保證業務流程可以閉環，不能中途戛然而止。

以上文的合同稽核為例，探討“如何完成一份合同的制定與確認“，那麼該流程不能法務部確認完之後就終止。在這個環節，合同並沒有真正完成確認。

當然，流程的終點需要匹配業務目標，如果是探討“如何完成合同的起草”，那麼上述的流程在法務確認後終止卻也可以說通。

“有所取捨”：對於描述業務流程的顆粒度需要有所取捨，不可太過細緻，也不可太過粗糙，應以“能夠清晰描述流程，指導業務順暢流轉”為原則。

以上文的合同稽核為例，“合同資訊錄入”這一節點，並沒有細緻地去描述錄入合同時需要錄入合同哪些資訊、是否需要上傳電子合同等。

描述業務流程的顆粒度，有時也需要結合檢視人的需求。如果是管理層檢視，可能並不關心太過流程細節，更關係流程的流轉和關鍵管控點；如果是執行層檢視，那麼可能更關心細節，細緻到如何能完成各個“任務”，如何完成工作直接影響到執行層每日的工作量。

（3）如何輸出業務流程圖？

業務流程圖的輸出沒有固定的形式，可使用普通流程圖或者泳道圖或者其他圖示方式進行呈現。推薦使用泳道圖進行展示。泳道圖：泳道圖可使用Visio（本地軟體）、ProcessOn（線上平臺）進行繪製；

泳道圖一般分為三個維度：職位維度、階段維度和任務維度。

職位維度：透過部門/職位進行區分，不同部門不同角色得人各用一條泳道進行區分；如下圖中橫向排布的泳道。（不建議透過責任人進行區分，如：張三/李四。因為責任人可能因為職務變化、辭職等原因頻繁變化）

階段維度：透過任務階段來區分，明確各階段需要處理的任務環節；如下圖中縱向排布的泳道。（非必要維度，可視個人繪製習慣而定）

任務維度：不同部門/職位的業務人員在不同階段需要處理的任務；如下圖中的各流程節點。

2。 系統流程梳理：將業務流程轉換成系統流程，形成可執行的、高效的、貼合需求的系統流程

（1）如何梳理系統流程？

①劃分系統邊界

對於流程各環節，需要先劃分哪些“任務”需要在哪個系統中完成，明確各系統功能邊界。

以上訴合同流程為例，可以將合同流程各環節劃分到不同業務系統，合同起草、合同報價確認、法務風險確認在CRM中完成；合同稽核在OA系統中完成；合同產品生產、入庫出庫、物流運輸、物流簽收可在ERP系統中完成。

系統邊界的劃分，需要匹配不同業務系統的定位以及當前產品的產品定位。

如果是標準產品開發，則需要儘量減少對外部系統的依賴，儘量在本系統中完成業務流程的流轉。否則，當產品銷售時，如果高度依賴其他系統才能完成業務流程的運轉，那麼就需要與其他系統打包銷售，這將降低產品的競爭力。當然，這也需要和公司產品策略相結合，如果產品策略是希望整合多套產品形成整體解決方案，那麼各系統的邊界則需要根據不同產品的定位來劃分。

如果是客戶定製化產品/專案開發，則需要根據客戶內部業務系統定位進行劃分。

②明確各業務環節的系統管控點

由於業務流轉的需要、管理的要求或者其他原因，對於業務流程中關鍵節點，業務上會有一些管控要求。

如：合同錄入時，需要必須上傳合同附件，電子附件可以作為流程審批的依據，也可以在線上進行留存，方便後期檢視。類似這部分業務管控要求，在系統流程設計時需要形成系統管控點。

③確定各系統資料互動的觸發節點

明確單據在各業務系統之間流轉的觸發節點，即：什麼環節可以將資料同步推送至其他業務系統。

如：CEO確認合同審批透過時，將合同同步至ERP系統進行生產。

④明確各系統資料的回傳同步

單據在其他業務系統流轉過程中，部分單據資訊可能需要回傳同步至源系統。

如：合同同步至OA系統審批後，審批結果（透過？拒絕）需要同步回傳至CRM系統中，銷售業務員可以及時瞭解合同審批情況；合同產品交付到ERP系統生產後，生產相關進度可能也需要同步回CRM系統中，對於銷售人員而言，可及時瞭解到合同交付情況。

（2）如何輸出系統流程？

系統流程同樣可以使用泳道圖進行輸出，下方為示例：

與業務流程繪製的區別在於兩點：

維度不同：

業務流程的一般是職位維度、階段維度和任務維度；系統流程的維度一般是職位維度、系統維度和任務維度。

即：系統流程描述了哪個職位的業務人員需要在什麼系統完成哪些任務。

顆粒度不同：

系統流程會比較細緻地某一流程在系統中如何完成，以達到指導業務使用者順暢完成業務的目的。業務流程對於較細緻的流程管控點並不一定會進行描述，系統流程則會較為細緻地描述流程管控點及相關處理方式。

3. 解決方案制定：結合產品目標、需求範圍、業務流程等，形成解決方案

解決方案並非產品的PRD文件，而是用於向客戶/使用者介紹產品、介紹方案的介紹性文件，通常以PPT的方式呈現。

標準產品研發的過程中，不一定會需要產出解決方案，而是使用PRD文件描述需求與需求解決方案。

對於客戶定製化專案/產品，多數情況下需要輸出專案解決方案，向客戶方業務人員（包括管理層、執行層）介紹專案整體方案內容，約定產品需求與範圍。

（1）如何編寫解決方案？

①瞭解方案彙報場景及彙報物件

不同的彙報場景彙報物件，解決方案的側重點不同。對客戶管理層彙報，會側重於講解業務管理方案、管理流程、專案價值等；對業務執行層彙報，則會側重於講解系統流程、業務管控點等。

所以，在編寫解決方案前，需要先了解彙報的場景及物件，以明確方案編寫的側重點。

②方案需要呈現哪些內容（這裡提供專案解決方案編寫的基本框架思路）

專案概述：主要介紹專案背景、企業現狀，核對專案目標。

專案概述篇是對整個專案定調的篇章，需要熟悉當前專案的背景、企業現狀、業務流程等。

尤其需要關注企業高層領導對當前專案的看法與期待。高層領導對於當前專案未來能在企業的業務流程中扮演的角色和作用，是專案目標的核心提煉點，也是後續指導專案實施方向的關鍵因素。

整體業務解決方案：介紹基於專案目標、企業現狀的整體業務管理方案。

結合專案目標和當前企業現狀，對企業現有流程提出最佳化管理方案。核心是介紹新的管理流程、管理方案，輸出整體業務規劃藍圖、產品架構等。

詳細功能設計方案：按業務流程分模組講解各業務板塊的流程、產品功能等。 根據各模組的業務流程、系統流程講解模組功能設計，可包括：業務痛點、業務流程、系統流程、欄位模型、許可權設計、業務管控點、核心功能等。

對於整體業務解決方案和詳細功能設計方案的內容佔比和編寫的細緻顆粒度，需要根據彙報物件進行權衡。

當彙報物件是高層領導、管理層時，核心在於整體業務解決方案的介紹，詳細功能介紹則介紹流程、管控點、核心功能即可，整體篇幅也應以業務解決方案為主。

當彙報物件主要是執行層時，整體業務解決方案的佔比則可以適當減少，詳細功能設計可寫得更細緻，可包括：系統流程、管控點、核心功能、欄位模型、資料許可權等。

除了上訴的介紹內容外，專案解決方案還可能會新增：專案實施計劃、專案團隊、專案風險等。這些內容可視實際情況新增。

4。 產品版本劃分：劃定產品MVP版本，確定產品MVP版本需求及後續迭代路線

MVP版本：最簡化可實行產品。MVP版本這個詞，在標準產品研發的過程中會聽到多，說得淺顯可理解一些，即是：透過較短的開發週期快速實現產品的基礎功能，能夠快速進入市場。隨後透過獲取市場反饋，不斷迭代最佳化產品。

對於客戶定製化專案/產品，很少會有MVP版本的概念，在專案立項時，就已經有基本明確的專案週期、需求範圍。即使會有分版本迭代上線的情況，劃分版本的依據更多的是根據客戶需求的緊急程度來做劃分。

那麼，標準產品研發如何進行MVP版本的劃分？

①明確產品目標，清晰瞭解產品需求

產品版本/迭代路線的規劃，需要基於產品目標和產品需求去進行劃分，對於各產品需求需要清晰瞭解需求背景、需求內容才能準確地定義清楚需求涉及範圍、需求優先順序。

②確定產品最簡業務流程

基於產品主流程進行簡化，在保證業務流程閉環的情況下，儘量減少業務流程環節，將一些非必須的周邊環節均可歸入迭代最佳化版本。

簡化業務流程基本原則（以產品規劃篇中講解的車企銷售線索管理為例）：

沒有破壞產品目標的功能，不做；

銷售線索管理模組目標：與外部獲客渠道打通，實現線索從獲取-跟進-轉化的全過程管理。

下面列舉幾個線索模組的需求做示例：

對接外部獲客渠道（如：易車網、懂車帝、抖音等）：線索獲取的核心功能，需要規劃進MVP版本。但可考慮優先對接使用頻率最高的渠道或者使用EXCEL匯入線索的方式暫時不做平臺對接。

銷售線索查重：線索獲取核心功能，需要規劃進MVP版本。

銷售線索價值評估：線索獲取的非核心功能，不影響產品目標，不做。

線索分配功能：線索跟進的核心功能，需要規劃進MVP版本。

能夠暫時使用人工替代的功能，考慮不做；

根據線索相關資訊自動分配銷售人員進行跟進，不做，可由人工對線索進行分配。

銷售線索一鍵轉化成商機，可透過人工新建商機與線索關聯進行實現，但是整體流程體驗極差，需要規劃進MVP版本。

客戶定製化需求（適用客戶範圍比較小）的功能，不做；

線索分配時，需要根據銷售人員（客服人員）當天是否上班進行分配，不做。

支援自定義配置的功能，考慮先用固定配置的方式實現。

線索可根據使用者自定義設定的欄位進行查重，不做。先按行業通用的預設規則（如：手機號碼）進行查重。

線索轉換成商機時，可自定義配置商機的基礎資訊欄位從線索的基礎資訊中獲取，不做；按固定的幾個欄位預設賦值進行實現。

③根據最簡業務流程形成MVP版本需求範圍

本文由 @阿熊 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。