起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端業務調研與落地
與C端的產品不同，B端的業務調研復雜得多，而且是更重業務。如果是個普通水平的產品，怎么做好B端的業務調研呢？
一、B端業務調研與C端需求調研區別
業務調研或需求調研在產品經理工作中是較為核心的一環，并且能夠在整個產品的工作流中起到承上啟下的作用，B端產品由于與C端產品有有著本質的區別。
- B端產品重業務，相應的B端用戶大部分為公司內部或者外部合作方的實際一線的業務人員，所以相對產品經理他們在所在業務領域較為更專業，能夠從業務的目標、業務模式以及業務細節各個方面有更高和更深的認知。
- C端產品重需求，由于實際產品中C端用戶的體量是龐大的，且C端用戶的需求呈現多樣化與個性化，且C端用戶不像B端用戶那樣對自身有全面和深層的了解，這就導致了C端產品在對產品經理的能力要求上也高于B端產品經理。
你如果是個普通水平的產品，那你或許更適合去做一些B端方面業務的產品經理，因為C端對產品經理能力上要求地更加高階與抽象。
C端產品經理不僅能夠抽象總結歸納出海量用戶中核心關鍵的需求，找出當前產品業務中所遇到的各類問題，并且還要求你對需求和業務有足夠的敏感度，能夠靠自己的天賦或者能力發現業務或需求解決的核心點。
且由于不像B端那樣有專業人士給你提供業務細節和專業認知或者標準化的業務工作作業流程，那在實際工作中就要求C端產品經理能夠自己靠自己的經驗和積累去設計商業模式，產品模式，能夠有靠自己去決策業務和設計出一套針對當前階段最優的業務解決方案的業務抽象建模能力。
另外說個題外話，C端產品在能力方面也比B端產品要求更加全面，包括數據導向能力、精細化運營能力、各類營銷模式的設計即trick的設計能力，這要求你能夠有自己的一套數據分析的底層能力，包括掌握數據埋點的方法、各類數據模型能力、利用方法和模型解決問題的能力以及建立合理的數據指標體系指導牽引業務團隊更好工作的能力，精細化運營包括用戶畫像、用戶分群、用戶觸達、用戶轉化和全生命周期運營用戶的能力，防流失、提留存。trick包括砍價、拼團以及當下垂直電商產品中的眾籌、鑒定、拍賣、寄賣、求購、回收等等。
B端在業務調研中以業務為導向，這就對產品經理的需求分析能力的要求有所降低，因為我可能不像C端產品經理那樣既要懂商業，能夠去架構自身產品一整套的商業模型與業務模式，并且還能夠通過行業分析、競品分析以及數據分析各個維度對自己產品進行準確定位。
作為B端的產品經理，只要能夠更好的理解業務，掌握正確的調研業務的方法，結合業務方對自己的業務的專業認知，分析總結出核心關鍵的業務提升點，比如更智能化自動化的一體化解決方案，業務流程的標準化，員工工作作業流程的標準化，業務效率的提升點、風險控制的關鍵解決方案就能夠足以做好B端產品的業務調研。
但是由于產品經理不獨立自主地抽象和總結業務，不去設計商業模式與業務模式，常常會導致產品經理即使在某個B端產品的行業領域內深耕許多年，仍然只是做著跟以前一樣的工作，這就導致B端產品更容易淪為工具人，即變成分析業務產出方案的工具，思考問題的維度與高度都有所欠缺，并且B端不注重商業模式和數據，一般的B端產品經理也很難在公司為公司產生多么大的業績，導致B端領域沒有什么出名的產品經理，這也佐證了普通人適合做B端這個觀念，它并不要求你有C端產品那樣的需求敏感度，商業的敏銳洞察以及獨立抽象業務搭建業務架構的能力，但它也沒辦法讓你能夠在產品經理領域做到一個天花板級別的程度。
既然已經知道B端產品基于自身的業務特性，以業務驅動而非產品需求驅動，我們怎么去跟專業的業務團隊去協作，知道和了解業務并設計出滿足專業團隊的業務方案呢，首先就是要了解整個業務大的宏觀方面，從全鏈路業務流程著手去認知到自身業務布局板塊、業務特性、業務關鍵路徑。
二、B端業務調研流程
在B端業務調研之前，產品經理必須自身對相關業務有一定的基礎認知能力。由于每個行業下的業務和產品差異是巨大的導致在拿到新的業務調研工作前，產品經理并不一定有比較完備的準備，有可能在你剛加入公司就被趕鴨子上架去跟客戶溝通需求了，但是實際工作中即使沒有完全的前期準備，我們也是要把跟客戶的每一次溝通都當做是業務調研的過程，不斷積累業務知識直至成為業務領域的專家，我們不需要實際做業務，但一定要對業務方傳達自己是懂業務的，證明自身在業務方面的專業度。
以宏觀了解B端產品的業務初步情況為起點，以最終產出調研報告為終點，我們可以以結果為導向去做B端業務調研。為了能夠總結和輸出一個結構化的調研報告，用于向領導層匯報，驗證自己的業務認知和指導自己做業務落地及產品決策，并將業務需求拆解成指導開發團隊開發實施系統的業務需求清單，我們可以將業務調研氛圍以下幾個步驟：
1. 調研前的準備
在業務調研前產品經理要做好提前的準備工作以明確調研的主要方向，規避調研可能遇到的誤區或防止踩坑。
大多數情況下，業務方的工作產品經理是沒有干過的，那么在準備階段我們可以利用自身的分析能力以及相應材料建立初步的業務認知。
比如通過行業報告了解B端業務的宏觀背景、業務結構、涉及上下游產業等、通過公司財報了解業務的商業模式和業務宏觀數據，通過過往的一些資料文檔了解業務的主要流程和業務涉及的具體內容等，這樣可以提幫助我們建立系統化、體系化、結構化的認知。
但這樣做的不足之處是由于沒有實際進行調研的實操，導致自身認知不夠全面，具體的業務細節不能做到很好的銜接，相應細節點難免有遺漏之處。
前期調研要明確的核心點包括業務角色確定、業務現狀了解、業務場景認知。
業務角色是從宏觀方面劃分業務方的層級、一般有高管層、經營層（管理層）、決策層、他們在公司里分別做著不同的工作，相應崗位下的角色對業務的目標、關注點、業務產品能夠達到的預期也有所不同。
業務現狀，通過了解業務現狀，能夠讓產品經理與業務人員做到同頻，不僅能夠讓業務人員對產品經理的專業度上有認可，知道你產品經理是懂業務的，還能讓你有前期初步的規劃，能夠在調研時直奔主題明確重點，提高調研的效率和效果。
業務場景，產品經理通過對業務場景有一個大概的認知之后，就能夠對業務全局的規劃有一個宏觀的把控，知道業務目前遇到的問題關鍵點在什么地方，能夠了解客戶群體和畫像、了解產品或業務的渠道、知道當前業務的模式和當前業務系統對業務方工作是否有提升，能夠分析出當前業務需要解決的問題一個大致方向以及要優化整個業務價值鏈的哪些環節。
2. 明確調研目標
明確調研目標是在拿到業務需求之后首先要確定的事情，不能直接上手去做，要對整個調研的目的進行聚焦，花更少的時間解決更重要的問題。這樣才能保證不浪費自己的精力、節省業務方的時間、更有效的完成業務調研。
然后通過了解業務方的核心痛點分析問題背后的原因，因為在實際工作中我們并不是總能解決問題，而是更多地去解決問題出現的原因，這樣就釜底抽薪從根本上杜絕了問題的產生，達到業務方的預期，通過更優的解決方案實現其業務目標。
3. 選取調研對象
調研對象就是調研信息來源方，掌握不同信息來源于不同的角色，就能因地制宜地將業務拆分和架構。通常公司的崗位職級就決定了業務調研的不同層級。在公司里業務方分為戰略層、管理層、執行層
- 戰略層：公司高管，VP、總監
- 管理層：公司決策經營的具體管理者，主要各個部門的經理、主管。
- 執行層：一線員工，各個崗位的基層人員。包括客服、銷售、運營、設計師等角色。
針對各個層級最好選取2個典型用戶，選取的時候既要選優秀的，也要有普通的，這樣才能既有代表性，相應結論能夠代表公司絕大部分現狀，也具有一定的普適性，不會造成重復調研和時間的浪費。
4. 準備調研提綱
調研提綱依據選取的調研對象的不同，我們可以粗略根據高管、中層管理和執行者分別給出3份不同的提綱。那么針對提綱的內容，涵蓋“問事實”、“問期望”、“問影響”、“問原因”四個方面
5. 調研訪談規劃
訪談的規劃可以高到低進行調研，這樣從頂層和全局到不斷向下拆解，能夠一個全局和完整的思路，也能避免陷入細節無法解決核心矛盾，排除掉業務方可能提供的一些干擾信息。
需要注意的是在調研規劃階段階段先要產出調研的提綱提升調研訪談的效果和效率。提前進行訪談時間的安排尤其是針對公司高層的訪談，由于其時間安排比較滿工作忙碌，在進行調研前的邀約階段一定要多次確認訪談時間。
6. 業務調研具體實施
調研實施階段，就是按照前期的調研計劃去進行分角色的調研。需要注意訪談中的一些注意事項。
1）重點圍繞訪談大綱
2）及時針對業務關鍵問題進行補充和追問
3）注意積累過重訪談技巧
4）及時將關鍵內容總結落在文字上
5）保持與訪談對象的聯絡
6）及時備份錄音、并將內容整理到調研報告中
7. 總結調研報告
業務調研目標的明確
針對前期對業務現狀的理解總結出業務背景的概況，抽象總結出業務問題可以通過搭建什么系統或改進業務/工作方式來解決業務問題。完成業務方需求的總結和整理
業務調研方式選擇
針對不同層級調研的對象的深度訪談，明確當前業務發展的方向、現狀、痛點、收集與歸納總結成核心業務需求。
業務調研報告落地
明確核心客戶定位，思考產品給客戶提供的獨特價值，產品服務的需求歸納，協調資源與構建能力來搭建產品，付費模式以及業務標準化或者業務拓新方面的考慮。
三、B端權限業務調研case
了解了B端業務調研的意義和具體的操作的流程。我們通過一個權限體系方案的搭建來實戰性地分析一個B端的業務需求的調研如何拆解與落地。
1. 調研前的準備
公司業務現狀了解：公司原有CRM系統由于涉及的業務量較少并沒有針對各個部門搭建一整套的權限設計方案。隨著使用系統的部門和客戶數量的激增，導致現有的權限不再能滿足各類用戶的使用需求。
2. 明確調研目標
先通過調研確定權限分配的核心問題，提供更加完善的權限體系解決權限隔離、權限互斥、權限配置和等級劃分的問題。發現權限設置背后的各類問題并解決其產生的原因。針對核心業務問題分析整理出業務需求清單，提供產品側權限體系優化的解決方案。
3. 選取調研對象
選擇掌握信息的調研對象。選擇公司戰略層即公司高管人員來調研，由于部門組織架構比較復雜且涉及部門較多，所以針對戰略層典型用戶的選取，僅選取公司高管中對組織架構非常了解的運營VP來對公司各個部門涉及的權限進行總結，提高業務調研訪談的效率，節省調研不同部門人員的時間。
針對中層管理側的調研，選取權限問題頻發且業務在整個公司中較為關鍵的銷售部與SCRM部門來進行專項調研，能夠代表公司絕大多數部門的權限使用現狀，選取兩名管理層人員，1名為銷售經理、1名為運營經理，得出比較普適性的調研結論。
考慮到執行層即一線員工的業務調研情況，社群運營選2人，分別選取業績比較優異的一名社群運營和業績做的一般的一名社群運營?；鶎愉N售員選2人，分別選取業績比較優異的一名銷售和業績做的較差的一名社銷售人員。
4. 準備調研提綱
選擇調研對象之后，分別為公司高層、中層管理、執行層的的人員提供3份業務調研提綱。提綱包括內容分別為：面向對象、調研目的、調研問題、問題類型。
- 公司高層：調研高層主要從公司高層期望權限實現的目標著手，權限優化能夠節省員工多少成本、提高員工操作效率的方面有什么想法，針對分公司分部要不要做行權限隔離和數據隔離等。針對不同部門要不要做權限隔離和互斥，部門下的權限需不需要分級處理。同時對不同部門的業務進行業務需求調研，以確定不同部門具有的權限是哪些方面。
- 中層管理：調研中層管理時同樣也要對之前高層的調研的內容和核心關鍵環節進行再次闡述，從而承接戰略側，確保權限設計的方向理念是與戰略側是保持一致的。針對具體的權限操作方面，調研中層管理認為當前權限的劃分是否符合管理的預期，比如審核權限是否步驟足夠多能夠防止風險的出現，不同部門的權限互斥情況表現在哪里，過往是否存在權限分級不明確導致權限的越級使用，是否權限沒有互斥導致審批和財務等風險，當前的權限操作記錄是否存在日志存檔。權限使用的使用文檔是否具備。
- 執行者：調研銷售和運營人員平時是怎么使用權限功能的，是否對權限功能一些特殊敏感的操作比較了解，比如刪除角色等數據、導出公司機密數據等敏感操作使用規范是否了解。當前在權限操作過程中不滿意的點或者有問題的點有哪些，如果問題不解決影響業務工作哪些方面，你認為權限優化改善方面應該怎么做，如果按照你的方案建議改善優化之后你能夠得到哪些業務降本增效的業務收益等。
5. 調研訪談規劃
先從公司高層運營VP進行戰略側的調研，抓主要矛盾解決核心問題。再自上而下調研銷售經理與運營經理，看高層與中層業務目標認知是否一致，如果不一致，深挖其中的原因并給出相應的問題解決的思路，再針對銷售和運營人員進行調研，從中梳理出具體的權限操作的需求清單，指導后續權限體系方案的產品設計，優化解決當前權限存在的核心問題。
6. 業務調研具體實施
確定訪談時間，制定業務調研的問題提綱，提前將提綱發送給業務調研方各個人員。
調研訪談的邀約，針對高管運營VP進行多次時間確認，確保其有時間來進行參與調研，高管訪談主要為宏觀和方向性的方面，壓縮其調研時間。
圍繞訪談大綱對各個角色進行訪談調研，對關鍵問題及時補充與追問，將涉及到的關鍵問題記錄并將訪談的內容錄音，訪談之后整理記錄到調研報告之中。
7. 總結調研報告
通過業務調研，總結出權限體系目前有以下問題：
- 公司現有組織架構沒有按不同部門的權限拆分和細化
- 存在部分崗位的權限配置混亂的情況，由于部分資金相關的權限沒有考慮到權限互斥的設計，涉及財務費用審批相關的權限被濫用情況有出現。
- 不同銷售人員和銷售崗位之間的權限分配不合理導致數據泄露以及銷售人員執行側的操作與高層管理方所制定的戰略方針不一致。
- 權限的等級設置不合理，導致存在部分銷售人員攜帶公司機密數據跑路和挖公司客戶資源的現象。
1）定位核心用戶
公司內部各部門的同事，包括查看公司業績和做關鍵業務審批的公司高層，管理員工工作流程的各部分管理層，通過系統完成各類操作的執行層人員。
2）業務優化點確定
權限按部門進行合理細分并隔離，各司其職提高工作效率。
權限互斥方面優化，防止權限濫用。
針對審批、審核以及公司機密數據方面建立完善的申請與多級審批體系。
權限分級設置，管理員角色可針對本部門、下屬進行權限復用繼承和進行權限組分級設計。
提供權限操作的詳細使用手冊。
四、B端權限體系需求設計
采用統一模型RBAC3對權限進行設計。
提供角色分層，角色分級與繼承關系，避免出現下級比上級權限大的情況。提供互斥約束，包括各種限制定義角色間的互斥關系，一個員工不會同時操作互斥的功能。
設計成豎形結構。為方便展示將組織架構、部門和員工放在同一頁面，各業務線按照自身所負責的業務分配不同的頁面進行權限操作。
1. 功能權限
從模塊、頁面、菜單（一二三級菜單）、按鈕（多個按鈕）四個層級，建立一整套的給系統權限體系用于勾選（支持多選與取消勾選），設置不同的角色，給角色賦予權限，將用戶與角色關聯，用戶所關聯的角色就能擁有該角色下所有的權限。
2. 數據權限
擁有功能權限下的頁面權限的前提下才具備該頁面下數據權限。數據權限除了超級管理員和分部（區域）管理員擁有默認其對應的所有數據權限之外，支持按照組織架構數分配數據權限。
系統組織結構分為：總公司、分部（區域）、縣市、部門四級架構。
數據權限生效范圍分為：本人、本人以及下屬，本部門，本部門以及其下屬，全部數據權限支持共享（快速配置賬號并復用）：支持賬號、部門、角色間復用共享
1）管理員角色：設置超級管理員角色、分部（區域）管理員角色。
超管默認擁有系統所有模塊、頁面、功能按鈕以及數據增刪改查的所有權限。
分部管理員默認擁有系統某一分部（區域）所有模塊、頁面、功能按鈕以及數據增刪改查的所有權限。
2）權限初始化：默認角色。
系統所有用戶在新建時均默認分配一個通用的“默認角色”，該角色由管理員配置基本的員工權限功能，主要為儀表盤（系統首頁）和我的工作臺兩個部分。
3）權限操作日志
不同用戶在不同時間進行了數據修改和刪除、導出等相應敏感操作，針對功能權限和數據權限兩個方面操作日志記錄，該模塊與系統操作日志打通。
4）權限管理：
包括組織結構設置和各業務線權限的個性化分配管理，對應的管理員角色對權限進行創建和對不同角色分配權限，權限設置包括功能權限與數據權限兩個方面。
五、原型設計
組織架構：
權限管理：
模塊權限：
數據權限：
本文由 @關山大道產品企劃師 原創發布于人人都是產品經理。未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論，等你發揮！
