編輯導語：對於一個B端產品，你有想過從哪些方面入手去做嗎？這篇文章作者詳細介紹瞭如何從0到1做一個B端產品，推薦想要了解B端產品製作的童鞋閱讀。
隨著網際網路流量紅利的消失，網際網路已進入下半場：從消費網際網路到產業網際網路。
面向To B業務的產業網際網路，成為資本追逐的熱點。
國家的第十四個五年規劃提出：要加快數字化發展，主要目標任務中有幾個關鍵詞：數字產業化、產業數字化轉型、數字社會、數字政府、數字中國。
國家的目標就是我們的目標，對我們來說就是前進的方向與發展機會。
產業網際網路、企業數字化一定離不開數字化產品、特別是B端產品。比如，醫療數字化就需要很多B端產品來落地、實現數字化，像電子病例、AI輔助診斷、遠端醫療、傳染病自動預警系統、嬰兒防盜系統等等。
B端產品，也叫 To B（To Business）產品，即產品的購買者是企業或組織。B端產品主要用來幫助企業解決某類經營管理問題和業務問題，為企業提升效率、降低成本、保證品質和控制風險。
B端產品是近幾年的熱點，對產品經理來說是個機會。
本文將結合實戰案例，與你分享從0到1做一個B端產品的整個過程。
一、專案背景
A上市公司有數千人的產品研發團隊，主要開發遊戲與企業應用軟體。
大型研發團隊都會面臨一個問題：“人來人往”：
“人來”——新人加入團隊時，如何讓新人快速成長、快速融入產品團隊？
“人往”——技術骨幹離開團隊時，如何減少損失、規避風險？
員工的知識經驗是公司的寶貴資產，但這些資產散落在各個地方：員工的頭腦、個人電腦、公司論壇、共享目錄、網盤……
知識經驗沒有得到有效管理，就不能被有效利用，造成資源的浪費、無形資產的流失……
A公司也不例外。常有骨幹被高薪挖走，造成經驗的流失；團隊中新人較多，難以快速上手，造成研發效率低下，多次錯失市場良機，CEO為此很是苦惱。
CEO在EMBA班上聽說了知識管理，覺得值得嘗試，於是打算在公司開展知識管理，並計劃開發一個知識管理系統供內部使用，如果效果好的話，再把它產品化對外銷售。
CEO任命產品經理老王為負責人，把這個想法交給他來落實……
二、梳理工作思路
作為產品經理，接到一個任務後不要馬上開始動手執行，應該先梳理一下工作思路。
試想一下：如果請你來負責這個專案，你會怎麼做？
建議你先拿出一張白紙來，用思維導圖參考下圖的結構，梳理出你的工作思路，再繼續看後面的內容會更有代入感。
梳理工作思路之後，你會得到類似下圖的思維導圖。
這張圖是B端產品的典型研發流程，包括如下幾個關鍵步驟：
業務調研分析：B端產品主要是為企業解決經營管理與業務問題，首先要做業務調研分析，瞭解業務現狀、分析業務問題，從而設定專案目標。
設計解決方案：針對要解決的業務問題與專案目標設計解決方案，包括業務方案（設計配套的組織架構、流程、制度等）與產品方案（需要開發的IT系統）。
方案實施與運營：解決方案的落地實施、IT系統的開發上線，以及系統上線後的運營、持續迭代最佳化。
產品化與商業化：這個是非必須的步驟，根據企業需求，決定是否把應用於企業內部的專案做成產品並對外銷售。
接下來就按照上圖的流程，逐步介紹從0到1做知識管理系統的全過程。
三、業務調研分析
前面提到，B端產品主要是為企業解決經營管理與業務問題，所以產品經理在做B端產品時，首先要做業務調研分析，瞭解業務現狀、分析業務問題，從而設定專案目標。
不懂業務的產品經理就會變成傳話筒，很容易被替代，而且也不可能做好產品。
如下是業務調研流程：
例如：IBM給某能源集團做諮詢專案時，是按照下圖所示的流程開展業務調研工作的。
接下來將結合案例講解業務調研流程的要點。
1。 明確調研目標
在開展業務調研之前，如果產品經理沒有該業務領域的經驗，要先花時間做功課，提前熟悉業務領域，否則連訪談提綱、調查問卷都設計不好。
如何快速熟悉新的業務領域？重點是“快速”，企業是不可能等你學2年業務後再做產品。有以下幾點建議：
補充行業知識：透過閱讀書籍、網上資料獲取基礎知識，建立對行業的初步認知。
閱讀行業報告：透過行業報告對行業有個框架性的認識。
競品分析：透過競品分析，瞭解行業中的同類產品，對你要做的B端產品有個形象化的認識。
請教行業專家：透過請教行業專家，瞭解行業中的隱形知識、實踐經驗、常見的誤區，並獲取建議。
深入業務一線：自己到業務一線透過訪談、觀察、輪崗體驗等方式加深對業務的理解。
產品經理以前沒有做過知識管理系統，知識管理對他來說也是新領域。所以決定先花時間熟悉一下知識管理，再製定下一步的調研計劃。
從以下幾個方面快速熟悉知識管理領域：
補充行業知識：去找了知識管理相關的書籍快速掃盲
閱讀行業報告：找到了IBM給中國移動做過的知識管理諮詢方案，對開展工作的思路有了啟發。
競品分析：分析了知識管理系統的相關產品，比如藍凌、互動百科等，對知識管理系統有了形象化的認識，對知識管理領域的解決方案有了大概的瞭解。
請教行業專家：請教在藍凌工作過的專家，瞭解開展知識管理工作的難點，得到了一些建議。
做了以上功課後，明確了業務調研目標：
調研業務需求
設計初步的方案
2。 選擇調研物件
在B端專案中，調研物件可以按崗位層級分為3類：高管、中層幹部、基層員工。
根據要調研的內容來選擇不同的調研物件，如下圖所示。
高管：調研戰略層相關的內容，比如戰略定位、戰略目標、經營策略、管控模式等；還需要了解高管對專案的期望值與評價標準，高管是專案的重要評價者。
中層幹部：調研戰術層相關的內容，比如流程管理、組織架構、培訓考核、績效管理等內容。
基層員工：調研操作層相關的內容，比如日常任務、操作步驟、流程細節、業務規則等內容。
選擇切入點
雖然全公司每個部門都需要做知識管理， 但產品經理打算先選擇一個部門作為試點，在試點中總結經驗教訓，有效果後再逐步推廣到其他部門，這樣操作會更穩妥一些。
那選擇哪個部門做試點呢？產品經理選擇知識管理需求最迫切的部門——研發部。研發部人員流動頻繁、有知識管理的痛點，這樣找他們配合的時候會更容易，從他們開始做知識管理也更容易見到效果。
選擇調研物件
產品經理按照上述的三個層級以及切入點選擇如下調研物件：
高管：CEO/CTO
中層：研發部門總監
基層：主程/程式設計師
3。 選擇調研方法
產品經理選擇了深度訪談、問卷調查的方法開展業務調研。
產品經理針對不同的訪談物件準備了不同的訪談提綱，研發總監的訪談提綱如圖所示：
產品經理設計了調查問卷，來覆蓋更多的調研物件，如圖所示。
4。 執行調研計劃
做完業務調研的準備工作後，開始預約調研物件。
自上而下：
按照自上而下的原則，從高管到中層再到基層員工的順序開始調研。
控制節奏：
在訪談的過程中，控制節奏，根據訪談的效果迭代改進訪談提綱。同樣，在實施問卷調查時，也是先小批次發放問卷，再根據問卷調查的效果迭代改進調查問卷。
雙專案經理制：
乙方到甲方（與乙方不是同一個公司）公司做專案時（包括業務調研），建議雙方共同組建聯合專案組，最好請甲方領導擔任專案的總負責人。採用雙專案經理制，甲方、乙方各安排一個專案經理作為牽頭的負責人。甲方派業務代表擔任甲方專案經理。
組織架構如圖所示：
這種專案組織架構有如下好處：
獲得甲方的重視與資源支援
甲方專案經理全程參與專案
作為雙方溝通的介面人，加強雙方溝通
協助推進專案進展：在調研階段可以幫助破冰、找人、協調資源，為調研物件提供心理支援，使調研物件更容易配合調研
作為業務代表，可提供業務知識的指導
5。 總結歸納輸出
接下來要對調研得到的資料進行整理分析，輸出調研報告，生成初步方案，並向領導彙報。
（1）企業現狀
組織架構
B端產品大多應用於企業內部、涉及到多個部門，所以要透過調研得到企業的組織架構圖，這有助於在業務調研階段找到合適的調研物件、在需求分析階段做干係人分析。
A企業的組織架構圖（部分）如圖所示：
現有IT系統
客戶不希望新做的B端產品是一個獨立的資訊孤島，所以還要考慮與企業現有系統的整合與協同。
經過調研得知A企業的現有IT系統如下：
自研企業資訊門戶EIP
自研ERP
自研IM系統
企業郵箱
各部門內部使用的工具
（2） 確定關鍵知識域
知識管理首先要搞清楚要管理哪些知識。
知識管理需要與企業戰略、核心業務相結合才有價值，所以要確定對企業戰略、核心業務發展有影響的關鍵知識域。
從兩個維度來確定關鍵知識域：目前影響度（對當前業務的影響度）、未來影響度（對未來業務、戰略方向的影響度）。
透過深度訪談、問卷調查得到了調研資料，進行統計分析後得到如下資料：
把目前影響度、未來影響度都比較大的關鍵知識域，作為知識管理的重點。如圖所示：
（3）分析關鍵知識域的目標與現狀
從3個維度來評估關鍵知識域的目標與現狀：掌握度、擴散度、編碼度，具體的評估標準如下：
掌握度：組織成員所掌握該知識的最高水平，分為四級：
入門水平：對該知識域僅有初步的瞭解，掌握概念
初級水平：有基本的知識，在指導下能應用知識
專業水平： 能夠獨立執行和推進工作，具有相關專業資質與經驗
專家水平：在本知識領域內領先，具有行業影響力和領導力
擴散度：組織中應用該知識的大多數成員所掌握該知識的水平，分為四級：
入門水平：對該知識域僅有初步的瞭解，掌握概念
初級水平：有基本的知識，在指導下能應用知識
專業水平： 能夠獨立執行和推進工作，具有相關專業資質與經驗
專家水平：在本知識領域內領先，具有行業影響力和領導力
編碼度：該知識在組織內的顯性化程度，分為四級：
知識只存在於員工頭腦中
知識已被顯性化，但未加歸納整理
知識已形成了固定的方法、理論、框架體系
知識成為最佳實踐，能夠給予員工最直接、最佳的指導
透過深度訪談、問卷調查得到了調研資料，進行統計分析後得到如下資料：
從表格中可以看出關鍵知識域的現狀與目標的差距，這就是知識管理要解決的問題，也就是說要透過知識管理來縮短現狀與目標的差距。
手機遊戲開發是A企業的戰略方向，但掌握度、擴散度、編碼度都需要提升，特別是掌握度，與目標有較大差距，需要儘快提升、縮小差距，否則就會影響企業戰略目標的實現。
（4）制定知識管理初步方案
根據關鍵知識域的目標與現狀，制定關鍵知識域的提升方案，如圖所示：
從圖中可以看出，關鍵知識域的提升方案並不限於知識管理系統，例如：掌握度提升方案中，組建情報小組、建立創新機制都跟知識管理系統無關，但對提升組織的關鍵知識域的掌握度又有幫助。
所以，知識管理並不等於做個知識管理系統，這在後面的“設計解決方案”中會展開介紹。
有了關鍵知識域的提升方案後，再製定落地的行動計劃，如圖所示：
四、設計解決方案
透過業務調研，明確了要解決的業務問題、要達成的專案目標，接下來開始設計解決方案。
B端產品不是企業的萬能藥。
B端產品是為了解決企業經營管理問題，但B端產品只是幫助企業解決經營管理問題的手段之一。
B端產品也不是萬能的靈丹妙藥，很多企業的業務問題其實是模式問題、管理問題，靠軟體產品是無法解決的。比如，企業的生產效率低下，可能是組織架構的問題，可能是激勵制度的問題，也有可能是生產工具的問題。如果沒有對症下藥，手裡拿著錘子看什麼都像釘子，指望一套B端產品就能解決所有問題，最後的結局往往是一地雞毛。
作為B端產品經理，不要把做產品、賣產品作為核心目標，應該把幫助企業解決問題、幫助客戶成功作為核心目標。客戶的問題如果沒有得到解決，你的產品做得再好，客戶也不會滿意，會認為是你的產品的問題。
產品經理只有跳出產品的範疇，從業務的視角去思考、分析問題，幫助客戶解決問題，幫助客戶成功，這才是產品經理的真正價值所在。
整體解決方案：
有時候，企業要解決的問題是B端產品可以解決的，但只考慮B端產品是不夠的，得從系統的角度來設計一套整體解決方案。
例如：有的公司花了很多錢買了一套昂貴的ERP，但是沒有實施成功，原因不是ERP產品做得不好，而是其他原因。
ERP實施成功的阻礙因素是多種多樣的，常見的原因如圖所示：
這些導致ERP專案失敗的原因都跟ERP產品無關，但專案失敗了，甲方就會認為是ERP產品不好。
所以，ERP產品經理不能只考慮ERP產品本身，要從系統的角度設計一套整體解決方案。
注意：
設計解決方案時不能只設計產品方案，還要設計配套的業務方案！
前面在“制定知識管理初步方案”這一部分提到，要解決企業“人來人往”帶來的問題，需要一套系統的解決方案：包括商業情報、人才培養機制、構建知識管理系統等。
業界有很多公司在做知識管理，他們也搭建了知識管理系統，有知識庫，但上面內容很少，使用率極低，算是荒廢了。
知識管理不是有了知識管理系統、知識庫就可以，還需要專人專崗負責推進、有配套的制度與流程。
B端產品只是解決客戶問題的解決方案的一部分。
企業轉型變革的3個要素
企業做知識管理是一場轉型變革。企業轉型變革有3個要素，如下圖所示：
People：與人有關的因素，包括組織架構調整、人員技能提升、文化宣傳等
Process：與流程有關的因素，包括流程最佳化、制度變化
Tools：透過工具、軟體來固化流程、提升效率
企業要開展知識管理，對企業來說也是一場轉型與變革，需要從People、Process、Tools（簡稱“PPT”）這三個方面進行協同配合。
接下來分別來介紹應用方案設計（包括People、Process）與產品方案設計（包括Tools）。
1。 應用方案設計
（1）People
要有專人負責推進知識管理，所以需要調整組織架構，新增知識管理運營團隊、知識官團隊，如圖所示：
知識管理運營團隊
在崗位上設定了知識管理專員（負責知識庫運營、宣傳與推廣）、知識管理工程師（負責知識庫的開發與運維）。
知識官團隊：從一線業務部門中挑選業務骨幹擔任知識官，是個兼職的崗位，所以知識官團隊是個虛擬組織。他們充當橋樑的作用，幫助收集業務部門的知識管理需求、推進創新方案與知識地圖在業務部門的應用、知識庫的內容稽核等。
（2）Process
需要有配套的管理制度與流程。
1）配套的流程，包括如下幾點：
知識庫內容稽核流程
創新評審流程
創新應用流程
2）配套的制度，包括績效管理制度、激勵機制。
績效管理制度：
管理界有個格言：你想得到什麼，就要考核什麼。知識管理要跟績效考核結合，在KPI中新增知識管理的考核項，把知識管理與員工的績效工資、晉升相結合，激勵員工對知識管理的參與熱情。
具體做法：把知識管理的參與情況用知識貢獻分進行衡量，並計入KPI中，如圖所示：
對知識官也要有考核管理辦法，知識官的考核與排名決定了他們能拿到多少知識官津貼。
知識官的考核內容及標準（部分）如圖所示：
激勵機制：
從兩個層面考慮激勵機制的設計：
物質激勵
：員工參與知識的沉澱、分享、學習都會獲得積分，積分可以透過抽獎與競拍來獲得相應的獎品（我們總結出程式設計師比較喜歡的獎品是數碼類產品以及技術書籍）。
精神激勵
：員工在知識庫中發表高質量的內容，往往會收到很多好評，優秀內容會被管理員推薦到首頁，並得到重點推廣，這對員工的激勵甚至超過物質激勵。傳統印象中大家可能會認為技術人員都很低調悶騷，但我們發現技術人員其實都很希望自己的技術與技能得到別人的肯定。
具體的激勵機制設計，如圖所示：
2。 產品方案設計
知識管理不是一個概念或虛無縹緲的理念，要透過知識管理系統/知識庫來落地，實現知識的沉澱、傳播、應用。
接下來介紹知識管理系統的產品方案設計。
（1）產品定位
知識管理要與專案及產品結合才會有人主動去應用，才能體現價值。
這也是企業知識庫與百度、谷歌差異化的地方：企業知識庫中沉澱的內容都是實際專案、實際產品開發過程中沉澱下來的具體、有效的實踐經驗與教訓。
做類似專案的同事往往會經常碰到類似的問題，在企業知識庫中可以最快找到他想要的東西。
所以，產品經理對企業知識庫的定位是“離你最近的知識庫”。
（2）應用架構設計
處理一個複雜問題有個常用的策略：分解。把一個複雜的問題分而治之、化繁為簡，變成幾個小問題，這樣解決起來就容易多了。
知識管理系統可以分解為幾個子系統：
知識庫：以 詞條（文章）的形式對團隊的知識經驗進行沉澱。這是核心子系統， 作為主門戶，整合其他子系統。
企業微博：以微博的形式作為企業內部的交流社群。
問答系統：以問答的形式作為知識經驗交流社群。
E-Learning ：線上影片課程的管理。
子系統之間的關係如圖所示：
B端產品要考慮與企業現有系統的整合與協同。
經過調研與討論，知識管理系統要跟如下現有系統進行整合：
與賬號系統對接，實現單點登入
與現有IM產品整合，實現訊息通知
與企業資訊門戶EIP對接，增加知識庫的廣告位與連結
與ERP系統對接，實現知識管理績效資料的同步
（3）梳理業務流程
用UML的活動圖梳理出知識管理的業務流程（部分），如圖所示：
畫業務流程圖的注意事項：
分工應平級：泳道的角色全部用崗位名稱或全部用部門名稱，不要混用
活動命名：要用“動詞+名詞”結構，如“提交詞條”，不要寫“工程師提交詞條”或“提交”
業務流程圖的邊界適當外延，有助於瞭解業務全域性、瞭解IT系統在全流程中的位置
業務流程從服務請求者開始畫起
“稽核”不寫崗位寫意圖，如：不要寫“經理稽核”、“財務部稽核”，要寫稽核意圖，如“稽核詞條內容是否合格”
主從活動只留一個：如“提交申請”、“接受申請”是成對的，只要寫一個；“交費”與“收費”是成對的，只要寫一個。要留哪一個，主要看流程圖給誰看，例如：如果流程圖是給使用者看，就留“交費”，給收費員看，就留“收費”。
避免流程圖太細：流程圖中不要把每個操作步驟都畫出來，只要不影響其他泳道的活動，可以先不用畫出來。例如，下圖就是太細的流程圖。
圖：反面案例——畫得太細的流程圖
（4）功能模組設計
在做了應用架構設計、梳理出業務流程之後，再來做功能模組設計。
如何知道系統需要哪些功能模組？
接下來介紹四種方法：
業務流程派生法
競品拆解法
干係人分析
場景分析法
業務流程派生法
透過業務流程派生出功能模組：先識別角色、再識別用例，然後再從使用者視角檢查是否有遺漏。如圖所示：
a）識別角色
例如，下圖所示的知識管理業務流程圖中，我們看看哪些角色不是知識管理系統的End User。
在知識管理系統的規劃中，知識管理專員“統計積分”後，把積分資料用Excel發給HRBP來手動“計算績效資料”，HRBP不需要與知識管理系統打交道。所以HRBP不是知識管理系統的End User。
我們把HRBP的泳道遮蔽掉，包括泳道內的活動與菱形，如下圖所示。
然後對剩下的泳道進行角色化抽象，可以抽象出研發工程師、知識管理專員、知識官、研發經理這些角色，這些角色會跟知識管理系統打交道。
b）識別用例
接下來對活動圖中的每個活動進行判斷，若需要系統支援就是用例，否則就忽略。
比如：“提交詞條”、“修改詞條”等活動需要在知識管理系統中完成、需要系統支援，我們把需要系統支援的活動圈出來。這些都是潛在的用例。如圖所示：
對每個菱形進行判斷，屬於某個活動的、不需要系統支援的忽略，否則抽象為用例。
例如，“填寫原因與改進建議”是一個步驟，在稽核詞條時一起完成，可以與用例“稽核詞條是否合格”合併。如圖所示：
透過上述的業務流程派生法，可以得到如下用例圖：
c）從使用者視角檢查是否有功能遺漏
業務人員：從他們的工作任務、日常活動來檢查功能遺漏，少了某些功能會影響他們的工作任務。
管理者：往往需要各種報表、分析來完成管理工作
運營人員：往往需要設定、稽核、統計、分配等功能
維護人員：經常需要配置、維護、升級、遷移、監控、排錯、備份、恢復等功能
競品拆解法
可以透過競品分析，從競品中獲得啟發，借鑑競品的亮點功能。如圖所示：
例如，對 開源的HDWiki 進行試用、拆解分析後，發現很多功能非常適合做知識庫，如圖所示：
為了加快開發進度、節約成本，產品經理經過調研決定：知識庫部分基於開源的HDWiki做二次開發。
干係人分析
第三種方法是透過干係人分析得到功能模組。
例如：在訪談知識官時，知識官提出這個訴求：在稽核詞條時，由於他們是兼職的，會碰到主業任務很忙時沒空稽核詞條。針對這個訴求，系統可以提供“轉移稽核任務”的功能，把詞條轉給其他知識官來稽核。如圖所示：
場景分析法
透過對業務場景進行分析，可以發現一些透過使用者訪談無法得到的細節需求。如圖所示：
（5）規劃演進藍圖
把知識管理系統分解成多個子系統、並梳理出功能模組之後，按照“整體規劃、分步實施、持續迭代”的思路，把整體系統的實現分成幾個階段、並排好優先順序。
先用思維導圖梳理，如圖所示：
給領導彙報方案的話，可以用演進藍圖，如圖所示：
這裡再分享一個案例，IBM做的ERP諮詢專案，也是按照“整體規劃、分步實施、持續迭代”的思路。
下圖是整體規劃的藍圖，如圖所示：
然後把整體規劃的藍圖，分成幾期來分步實施，如圖所示：
（6）介面設計
在完成業務流程設計、功能模組設計、角色梳理、競品分析之後，產品經理就可以開始做介面原型設計。
一圖抵千言，透過介面原型可以很好地幫助產品經理傳遞需求與設計思路。
一般來說，產品經理先畫低保真原型，跟干係人溝通確認後再畫高保真原型。如果團隊裡有設計師，則可以由設計師來畫高保真原型。
原型工具：
低保真原型的常用工具：紙筆、Balsamiq Mockups等。
高保真原型的常用工具：Axure、墨刀等。
介面設計建議：
儘量借鑑成熟產品的設計（國民級產品、同行標杆）
繪製介面原型時多用現成的模板、元件、素材來提高製作原型的效率
儘量利用標準控制元件與常見的互動方式，不要為了炫技而發明沒有價值的新互動方式。
不要高估使用者的電腦操作水平，儘量簡單、易學、易用
按照這個順序：有>易用>好看，先有功能，再考慮易用，最後才是好看。
知識庫介面原型：建立詞條的介面原型，如圖所示：
編輯詞條的介面原型，如圖所示：
（7）報表設計
B端產品基本上都離不開報表。
管理者需要透過報表來實現管理意圖，所以做報表設計最重要的事情不是報表要展示哪些資料以及報表的形式外觀，而是要明確管理者的管理意圖。
比如，你會經常開啟天氣APP看溫度。但你真正關心的是溫度這個資料嗎？
其實，你真正關心的是今天冷不冷，要不要多穿衣服！這才是你的“管理意圖”。
所以天氣APP除了顯示氣溫，還有“穿衣指數”，就是針對你的“管理意圖”——該穿多少衣服。
但我覺得顯示氣溫、穿衣指數還不夠。
我經常到各地出差，發現廣州的8度與哈爾濱的8度是完全不同的感覺，而且從穿衣指數還無法判斷出差該帶多厚的衣服。我覺得天氣APP應該有個“實時街景”功能，我看下當地街上的行人穿什麼衣服，基本就可以判斷要帶什麼衣服了。
所以，報表設計的第一步是“明確管理意圖”。
報表設計與應用的流程如圖所示：
接下來逐步介紹知識管理系統的報表設計。
1）明確管理意圖，把管理者的管理意圖羅列出來進行分析，並判斷優先順序。
2）根據管理意圖確定指標、需要哪些報表。
3）確定報表的外觀、顯示形式。
（8）許可權管理
B端產品的使用者群是多種多樣的，不同崗位、不同級別的使用者能操作的功能、能看到的資料可能都有區別，這就需要透過許可權管理進行控制。
許可權管理分為資料許可權、功能許可權。
資料許可權一般透過組織架構樹來控制，功能許可權可以透過RBAC（Role-Based Access Control ）模型進行控制。
RBAC模型是基於角色的訪問控制，將許可權與角色相關聯，使用者透過成為適當角色的成員而得到這些角色的許可權。如圖所示：
RBAC模型是比較成熟的功能許可權控制模型，知識管理系統的許可權控制就是基於RBAC模型。
如圖所示，對不同的使用者組（相當於角色）可以設定不同的頁面瀏覽許可權。
把知識管理系統的使用者放到不同的使用者組就可以實現不同的許可權控制。
（9）文件編寫
完成了前面這些工作後，產品方案設計的工作基本完成了，接下來要編寫需求分析報告（PRD），把需求傳遞給開發團隊。
C端產品與B端產品有很多區別，其中一點區別是：
C端產品的關鍵：讓使用者爽
B端產品的關鍵：讓客戶贏
正因為有這個區別，所以C端產品的需求分析側重點與B端產品也有區別。
C端產品的需求分析重點在使用者上，先做使用者研究、場景分析，找到痛點，給出解決方案。
如圖所示：
B端產品的需求分析重點在客戶上，除了常規的功能需求與非功能需求，還要做“價值需求”分析、從客戶的視角闡述B端產品的價值。
具體體現在：目標分析（問題與機會描述、影響分析）、干係人分析、管理意圖分析等。
如圖所示：
知識管理系統的需求分析報告的目錄結構，如圖所示：
報告的具體內容：微信公眾號：張在旺， 文章：【案例】B端產品的需求分析報告
五、方案實施
前面的業務調研分析、設計解決方案是為了“做正確的事情”，方案實施是為了“把事情做正確”、把解決方案落地執行。
1。 專案管理
專案管理是關於“把事情做正確”的一套方法論，如圖所示：
專案管理口訣：
凡是工作，必有目標。
凡是目標，必有計劃。
凡是計劃，必有落實。
凡是落實，必有檢查。
凡是檢查，必有結果。
凡是結果，必有責任。
凡是責任，必有獎罰。
2。 專案管理工具
產品經理透過禪道進行知識管理系統的專案管理、需求管理。
禪道的需求管理介面如圖所示：
禪道的提軟體需求介面，如圖所示：
3。 推進過程
知識管理在組織中的推進過程：整體規劃、分步實施、重點突破、小步快跑。
整體規劃：知識管理要與公司的業務戰略結合，涉及到多個部門，要搭建相應的激勵、考核、宣傳制度，要建設知識官團隊，要建設知識庫，是個系統工程，所以要從整體上進行統一的規劃。
分步實施：知識管理的推進，要由點到面，逐步推進，因為資源有限，貪多求全什麼都做不好。
重點突破：先從需求最迫切的部門開始、先從公司的戰略產品開始，這樣容易見到成效，並積累經驗，為推廣到其他部門與業務打下基礎。
小步快跑：遵循網際網路的產品思維，快速迭代、快速試錯，出現問題可以及時調整。
六、運營迭代
知識管理系統上線後，就進入運營迭代階段。
企業內部的B端產品運營，與C端產品運營、SaaS產品運營都有區別，具體區別如圖所示：
接下來介紹知識管理系統的運營。
1。 宣傳推廣
新系統上線後，先小範圍試執行，在知識庫中準備一些優質內容，再逐步擴大宣傳範圍。
充分利用各種宣傳渠道：公司大屏、工作群、內網、食堂，甚至公司的廁所門都是“兵家必爭”的廣告位。
充分發動以下角色幫助宣傳推廣工作：
運營專員：工作職責中包括宣傳推廣
知識官：充當知識管理部門與業務部門的橋樑
種子使用者：第一批愛學習、愛分享的熱心使用者
2。 內容運營
內容運營的重點在於內容的數量與質量、以及兩者之間的平衡。
內容數量太少，就會缺乏人氣。
內容質量太差，更是留不住使用者。
追求數量，會犧牲質量；追求質量，會影響數量。所以還要控制數量與質量之間的平衡。
知識管理系統上線後，如果內容運營沒做好，前期宣傳推廣工作做得再好也沒用。
使用者第一次登入知識庫往往是因為好奇心驅動，看了之後發現內容很少或內容很差，就再也不想來了，知識管理系統就慢慢荒廢了，成了“鬼城”。
所以知識管理系統上線後，先不急著做宣傳推廣工作，得先有一些內容。
如何做內容運營的“冷啟動”呢？
把散落在公司內部各處的優質內容進行梳理、歸類，按主題存到知識庫中；
發動知識官（本身就是業務骨幹）在知識庫中貢獻內容；
邀請愛學習、愛分享的種子使用者（比如公司的兼職講師）來知識庫貢獻內容；
由知識官團隊對內容進行稽核，控制內容的質量，不能追求數量而犧牲質量；
內容逐漸增多後，按主題整理出知識地圖，特別是與工作崗位直接相關的知識。比如“主程崗位知識地圖”是主程式設計師必須掌握的知識；
對優質內容進行宣傳，給知識庫帶來人氣；
配合激勵制度，鼓勵更多人參與貢獻優質內容。
3。 活動運營
定期組織活動可以提高知識庫的活躍度。
知識管理系統中有配套的積分體系，在知識庫中貢獻知識可以獲得積分，有了積分之後就可以參與知識庫的活動，比如積分競品、積分抽獎活動。
活動獎品並不貴，就是一些書、電子產品等，如圖所示。
實踐證明，這些東西很受研發人員的喜愛。
4。 資料分析
資料分析是產品運營階段必做的事情。
在知識管理系統的運營中，也需要做資料埋點、採集資料、資料分析，並根據資料分析的結果持續迭代最佳化產品。
例如：
根據搜尋詞頻，推測使用者的內容需求：比如，從後臺搜尋詞頻分析發現，“iOS開發”的搜尋頻率很高，說明使用者關注這方面的內容，知識庫運營團隊就開始重點去挖掘、梳理這方面的內容。
根據使用者的閱讀歷史、收藏、點贊、評論行為來推薦內容。這個有點像今日頭條、抖音的個性化推薦，但在實現過程中並不需要像今日頭條、抖音那樣用到大資料、AI技術，用簡單的標籤就可以實現預期的效果。
根據收藏數、點贊數來推薦內容，運營團隊會定期把收藏數、點贊數多的詞條放到精華區、在工作群中推送。
根據部門與崗位調整首頁。知識庫的內容與頻道越來越多，根據使用者的崗位、所在部門來調整知識庫首頁內容。
5。 運營成果
知識庫運營一年後的資料，如圖所示。
這資料與網際網路產品動輒上億的資料比較起來微不足道，但作為企業內部系統而已，這運營資料已經超出預定的目標，也超出領導的預期。
透過這些資料很難體現知識管理的價值，你看資料可能也沒有直觀的感覺，接下來再分享2個小案例。
案例1：
有個開發人員碰到一個技術問題（如下圖），加班了3天時間終於解決，多麼痛的領悟！
其他人在做類似的專案，也可能碰到同樣的問題，是否也要花同樣的時間來解決？
不！透過知識管理，可以提高解決共通問題的效率！如下圖：
案例的啟示——不重複發明輪子！透過知識管理幫助解決共通問題，減少重複投入。
案例2：
一名程式設計師4年前進入公司，成長得很快，做得很出色，晉升為主程式設計師，可惜後來離職了……
他給公司留下了什麼？
4年來，他在公司的知識庫中留下了51個經典案例！
這些案例是實際專案遇到的問題總結出來的經驗教訓，是百度搜索不到的。
這些案例被同事們學習次數超過2000次！
案例的啟示——企業都很重視有形資產的管理，而員工的知識與經驗是公司重要的無形資產，如果沒有知識管理，就會造成資產流失。
前面提到，知識管理的推進過程是從點到面，先在研發部門做試點。試點期間，陸續有其他部門來取經，主動請求幫助他們開展知識管理、在知識管理系統上給他們開通許可權與頻道。
再後來，公司獲得了亞洲最受尊敬的知識型組織（MAKE）獎，這是知識管理界的最高榮譽。
七、總結
本文介紹了從0到1做知識管理系統的整個過程。
做一個B端產品的3個步驟：業務調研分析、設計解決方案、方案實施與運營。
這3個步驟就像醫生給病人看病一樣，先望聞問切分析病因，再針對性開藥方，病了先吃幾天要再複查。
企業要開展知識管理，對企業來說也是一場轉型與變革，需要從People、Process、Tools（簡稱“PPT”）這三個方面進行協同配合。
在設計解決方案時，除了產品方案還要有配套的業務方案。
本文也介紹了在企業開展知識管理的過程。
要在公司中實施知識管理，有哪些方面很重要呢？
1）老闆重視知識管理
這是非常重要的一點，把它列在第一位。
知識管理不是一朝一夕就能見到成效的，老闆如果不重視，不投入資源，知識管理很容易半途而廢。
知識管理的難點在於很難量化知識管理的價值，比如：您會經常做筆記，您也認為做筆記對您的學習與成長有幫助，但具體有多大幫助？您的收入中有多少是做筆記幫你帶來的？這是業界難題，所以，要推行知識管理，首先要有老闆的認可與支援。
2）整體規劃、分步實施、重點突破、小步快跑
整體規劃：知識管理要與公司的業務戰略結合，涉及到多個部門，要搭建相應的激勵、考核、宣傳制度，要建設知識官團隊，要建設知識庫，是個系統工程，所以要從整體上進行統一的規劃。
分步實施：知識管理的推進，要由點到面，逐步推進，因為資源有限，貪多求全什麼都做不好。
重點突破：先從需求最迫切的部門開始、先從公司的戰略產品開始，這樣容易見到成效，並積累經驗，為推廣到其他部門與業務打下基礎。
小步快跑：遵循網際網路的產品思維，快速迭代、快速試錯，出現問題可以及時調整。
3）從你自己、從你帶的團隊開始做知識管理
只有大型研發團隊才能做知識管理嗎？其實每個人、每個團隊都可以做知識管理。
對於只有幾十人的研發團隊，可以沒有知識官團隊、可以沒有知識庫平臺、可以沒有知識管理制度，但只要你有這個意識，就可以從你開始，定期總結你的心得與經驗，分享給你的小夥伴們，逐漸影響你身邊的人。
本文由 @張在旺 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議