不知道你是否經歷過這種局面：客戶隔三岔五要資料，資料捧過去手還沒焐熱就開始索要方案、要試用產品、要響應需求、要定制化功能……問題頻發，需求不斷，競爭對手虎視眈眈，客戶的決策遲遲未定。成日埋沒在客戶源源不斷的需求之中，無法衡量團隊的投入產出比，也不清楚如何去評估客戶的價值。

坦白說，我經歷過這種雞飛狗跳的日子，客戶決定要什么也許是一瞬間的事，但對于項目交付團隊來說就不那么好捱了。客戶來了，一個炸彈丟進來，我軍于動亂中緊急動員，磕磕絆絆擠點料出來，危機暫時緩解，下一枚炮彈又投過來了，大坑明晃晃地砸在眼前……周而復始。我開始懷疑，究竟是哪里出錯了？痛定思痛，本文正是基于多次從坑里滾進去又爬出來的經歷給的一些關于To B產品服務的思考。

上篇文我提過服務管理體系在To B產品業務中貫穿始末，是對外交付和項目支持的有力推手。to B領域博大精深，在此按下不表，我僅從服務與知識管理兩個層面給出單薄的分享。有一點可以確定，在整個ToB服務生命周期中我們都期望能獲得可靠、安全的知識、信息和數據，從而提升服務質量，提高滿意度，降低服務成本。

進入知識經濟時代之后，信息技術不斷提升，社會信息化程度越來越高。在這種大環境下，對To B產品而言，若想順應時勢高效、健康且可持續地服務市場，贏得競爭的勝利和客戶的滿意度，就必須構筑屬于自己的、有競爭力的知識體系。

過去，我們講到企業的資產管理，通常都會從“人、財、物、機器“等方面入手，但很少會考慮到知識體系的布局。即使有企業把知識作為資產來管理，也通常停留在專利和發明上。究竟什么是知識管理呢？

關于知識管理的定義非常多，至今還沒有一個統一的說法。美國德爾福集團創始人之一卡爾?費拉保羅給出的一個定義是這樣的：

知識管理就是運用集體的智慧提高應變能力和創新能力，是為企業實現顯性知識和隱性知識共享提供的新途徑。

這里面包含三重含義：

• 個人知識集體化，把個人腦中的知識變成集體的公共知識；

• 隱性知識顯性化，把個人或集體長期積累的優秀經驗總結、規范、標準化成一個模式，該模式是流動的、可復制的；

• 建立共享知識系統，個人或集體通過系統的知識共享平臺，讓每個人的能力都通過共享得到放大。

華夏基石的董事長彭劍鋒針對知識的經營也提出了一些洞見：

知識的經營，就是要建立企業的知識管理體系。現在人才的流動性越來越強，人會走，但知識會留下來，知識和知識產權是企業最大的財富。

知識管理在對外服務客戶和對內形成企業文化上都如此重要，那么作為初涉To B服務市場的我們，該如何打造產品有競爭力的知識管理體系呢？下面我想從三方面分享下我對知識管理的理解。

01

知識的交付對象

在負責對外交付工作中，我和商務、渠道、架構師、合作伙伴和客戶都在頻繁地接觸，常有的情況是這樣的：“我要給客戶介紹產品，有沒有產品宣講材料？”“合作伙伴培訓，有教材沒？”“要給客戶制定方案，有部署架構文檔么？”“客戶要招標了，產品控標參數呢？”“準備擬合同了，合同報價模板呢？”……

來自各方的文檔需求應接不暇，我不得不懷疑，是不是對于To B業務而言，知識即文檔？

每逢提及知識管理，首當其沖想到的就是文檔的交付。你可能要開始掰手指頭枚舉：產品文檔、技術文檔、部署文檔、運維手冊、測試報告、解決方案、競品分析文檔、市場調研報告、招標引導材料、投標方案、項目計劃書……的確，一開始我們的思路都是這樣的，站在產品自身的角度，我們冥思苦想，客戶到底想要什么，他想看到什么。

然而，在實際交付的過程中我們發現，很多時候，我們連知識的交付對象是哪些角色都不清楚，更別提交付物了。

1、交付對象到底是？

是客戶嗎？客戶的決策層？客戶的執行層？客戶的服務商？還是客戶的用戶？不夠。在這里我想先介紹下服務交付工作的整體價值，協助我們理解這個事。

從交付線的價值中我們可以提煉，為達成這個目標，我們要服務和交付的對象至少包括：

• 客戶&客戶的服務商

• 騰訊合作伙伴（渠道商、服務合作伙伴、ISV）

• 架構師團隊

• 公司內銷售上下游

• 公司內其他業務團隊

不同業務面向的群體都大同小異。但從廣義層面上來看，上述的這些交付對象都屬于我們的“客戶”。那么，鎖定這些“客戶”群體，我們要交付什么？

?

2、交付物有哪些？

回過頭來，產品文檔、技術文檔、部署文檔、運維手冊、解決方案、競品分析文檔、市場調研報告……夠了吧？

不是覆蓋面的問題，是思路上有問題。請擺脫傳統的To C產品思維，站在“客戶”的立場去思考，我想要什么？我想看到什么？

1）for 客戶&客戶的服務商

以政府客戶為例，從前我們也許是以政府價值為導向去提供服務，但站在政府的角度，摸底政府的決策鏈，他們在思考什么？

如今的政府管理正是顧客導向，如何為自己的顧客服務是他們最憂心的命題。而政府的顧客，一是指產品和服務的最終使用者（即對外公眾），二是指產品和服務供給過程中的參與者（即對內公務員）。它好比一座倒過來的金字塔，將塔尖指向顧客那里——一竿子插到底，政府關注的焦點對準顧客的需要，以顧客為導向，以顧客的滿意度作為政府運行最大的使命和考量。

• 基于這樣的背景，政府跟你接洽，他不得不深謀遠慮——

• 請證明你的產品和技術實力，說服我；

• 紙面上的介紹不夠，我要全方位體驗下；

• 產品OK，但我要的是一套方案，不是一款產品；

• 方案通過，請做好方案包裝便于我向上匯報；

• 不夠，我需要相關測評證書的輔助；

• 匯報完畢，內部準備立項申請預算，煩請協助我提供項目可行性研究報告；

• 立項通過，我需要公開招標；

• 項目計劃書呢，該簽合同了；

• 我要內部大面積推廣，公務員培訓少不了。

• ……

以上對客戶決策鏈的揣摩并非空談，這都是源自我們對客戶銷售漏斗的盤點，每到一個銷售階段，幾乎可以提前預判到客戶想要什么，我們能提早做什么準備。而這些準備，都源自于我們對知識的管理。

證明產品和技術實力，產品技術白皮書丟過去；想快捷體驗，我給你分配裝修好的樣板房體驗帳號，一個月時間你考慮清楚；你要方案？好啊，結合你的業務需求、服務商的實力和產品自身的標準能力，你來評估下；要證書？專利證書、軟著證書、等保三級測評證書、壓測報告……都準備好了；要招投標，產品控標參數按版本更新好了，標準的投標技術方案也候著呢；要運營推廣，沒問題，用戶和管理員的操作手冊都有……

?

2）for 騰訊合作伙伴

作為騰訊的合作伙伴，在此以服務合作伙伴為例，他們又在想什么？

利益。

毋庸置疑，服務商通過與騰訊達成良性合作可以最大化地獲得商機和利益。一方面通過參與項目的服務和交付贏得長期收益，一方面也想借此機會向客戶兜售自己的產品，獲取客戶機會。那么，服務商的心路歷程又是怎樣的？

• 我想和你達成合作，商務模式、報價方面如何？

• 我司人員的考核、認證、定級方式是？

• 我要盡快上手，贏得騰訊對我交付能力上的認可；

• 在項目交付過程中，我與騰訊之間的合作方式是？

• ……

在我們剩下半條命的時候，我們把另外半條命交給合作伙伴，以此形成一個生態圈。與合作伙伴的背靠背合作才能促進雙方的共生共贏。在近一年的交付工作中，我組織過不下6次的合作伙伴培訓，合作伙伴對上述問題尤為關注。

商務模式不清楚，請先閱讀下合作伙伴服務協議；人員考核認證不了解？培訓組織起來，定級面試搞起來；想快速上手，丟給你一捧《合作伙伴養成記》，內含產品的來龍去脈、常見問題、運維和開發的文檔說明；交付過程如何背靠背，請閱讀產品服務目錄……

?

3）for 銷售上下游

目前我們在對外服務的過程中，會與公司內多方銷售打交道。商務興致勃勃地牽線客戶過來，我們如何從容應對呢？

首先你要有料。站在商務角度，他有自己的kpi壓力，他想拿單，這點我們都能理解。那么我們可以提供什么料給他呢？

• 客戶領導對你們非常感興趣！有沒有宣講材料我丟一份過去？

• 客戶說想詳細了解產品技術能力，能約架構師面談么？

• 現在客戶在幾家廠商中選型，我們有沒有競品對比材料？

• 客戶提了一堆需求和問題，有人可以幫忙解答下嗎？

• 客戶打算招標了，給點兒控標建議？

• 打算簽合同了，項目計劃書給下？

• ……

平心而論，商務確實對產品的理解可能不深，我們更多時候要去儲備FAQ知識庫，輔助商務過濾客戶提過來的難題。在明確好客戶商機后，架構師會與商務一同負責跟進客戶。

以此類推，對于其他交付對象，我們需要根據他們的關注點去看到底需要管理什么知識。如果非要給知識做一個類型上的定義，那么知識可以是一份通用文檔、一疊參考資料、一棟精打細作的產品體驗樣板房、一次組織有序的培訓……在對外服務的過程中，知識可以是各種各樣的，只要能沉淀下來的，可被人重復使用，降低服務成本的都是一種知識。

?

02

知識的轉化

之前我們在與一位資深的微軟咨詢專家聊到知識管理時，他提到的一個知識轉化的概念——“DIKW”，即數據、信息、知識和智慧。

在《Knowledge Management in Theory and Practice (MIT Press)》一書里，作者KimizDalkir針對DIKW一一做了解讀。

在現今的大數據時代，我們每天接收到不計其數的碎片化數據，這些數據是離散的，無法在我們腦中成體系，幾乎是過目即忘。但當你有目的性地捕獲數據時，你總有能力去對這些數據進行分析、綜合，并進一步轉化為信息，這是第一步。

而信息又是什么？它來自于為數據提供上下文，它通常存儲在半結構化的內容中，便于查詢、重用，使得錯誤不再重復，并不會重復工作。將信息結構化地進行組織，便形成了知識。

知識，它是由個人的隱性經驗、洞察力和判斷組成的。它并非是基于目前提供的服務，而是從以往服務的經驗，對最近和預期服務的認識去做的收集。

而智慧呢，它賦予了物質的終極洞察力，具有應用和情景意識，提供強烈的意識判斷。

從數據到信息，再到知識轉化為智慧，形成一個閉環，這個閉環最終的方向都是指引我們達成企業戰略，實現個人目標。

聽起來像一碗雞湯，還是那種用廉價雞精沖出來的雞湯。可其實知識管理的最終目標就是讓組織將他們的集體知識融入到每一個交付物中，作為他們、他們的合作伙伴和他們的客戶創造價值的終極方式。

那么，對于To B產品而言，在打入企業市場時，簡單地組織團隊成員寫幾篇文檔就OK嗎？這就是To B產品的知識結構嗎？

前面我們提到，知識管理是為企業實現顯性知識和隱性知識共享提供的新途徑。注意，隱性知識，是高度個性化且難于格式化的知識；顯性知識則是用文字和數字表達出來，容易以硬數據的形式交流和共享的知識。

圖片源自Microsoft，已授權

文檔只是隱性知識轉化為顯性知識的最常見的形式之一，除此之外，我們會將服務管理體系流程規范化、表單化；我們會針對軟件自身的特性搭建樣板房，將本軟件的產品技術能力顯性表達，供客戶在一定時間周期內免費體驗，便于客戶快速地了解本軟件。這都是一種知識轉化。

1）隱性知識用文檔表達

在此以政府客戶為例，對于本地部署的產品而言，我們從客戶&客戶的顧客角度去看到底要把哪些隱性知識用文檔表達出來。

2）隱性服務用流程表達

以我之前負責的私有化產品為例，我們支持企業定制化名稱和logo，但在logo的設計和尺寸適配上往往漏洞百出，客戶頻繁返工，開發打包客戶端的時候叫苦不迭。

一方面，開發和設計同學清楚什么樣的LOGO合規；一方面，客戶也自認為他理解這一套規則。這就造成了信息不對稱，兩邊的成本投入都很大。解決的方式很簡單，把我們想傳達給客戶的規范機制通過流程表達出來，我們制定LOGO在各終端的物料規范，圓角、透明度、尺寸、色彩精度、不可侵犯區域、易錯點……一一列舉出來，每個位置的LOGO均給出對應的示例圖。若客戶有一定的設計基礎，我們還提供sketch文件，供客戶直接套用尺寸模板。

好了，客戶按我們擬定的標準順利交付LOGO資源包，可以了嗎？不夠，我們還進一步提供LOGO的審核標準，便于架構師在拿到客戶的反饋后根據審核規則快速檢索到其中的坑，盡早暴露出來，再交由客戶改進。最終確認完畢后再反饋給產品研發團隊。

同樣，在其他流程方面，譬如客戶立項報備、客戶端打包、POC部署、客戶需求和問題響應等方面，為達到與各方交付對象的信息對稱，我們都一一對這類知識轉化為通俗易上手的流程。

?

3）隱性能力用樣板房表達

顧名思義，樣板房是購房者裝修效果的參照實例。對于政務微信而言，若客戶自行申請注冊體驗，那么初始化的數據都是空的，客戶需要導入組織架構和人員信息，對接應用及接口能力，在管理后臺做相關的配置之后，才能真正達到有效的體驗。因此，在采購本產品前，我們會引導客戶去體驗已功能已裝修完畢的樣板房。根據客戶的性質，模擬不同類型的客戶對應的樣板房，分配有限的帳號，在一定時間周期內讓客戶進行體驗，到期后便回收帳號。

通過這種方式，我們將產品的隱形能力通過可視化的方式傳達給客戶，打破客戶對產品一知半解的懵懂狀態。

?

03

知識的反饋

明白了知識管理的重要性，明確了知識的交付對象和交付物之外，就要開始動工了。

據我的觀察以及多次的血淚教訓，不得不承認，其實大多數人都是疏于轉化知識的。“不就是寫個文檔嗎？”苦力活，不討好，沒什么績效可言，對我的工作有什么幫助？有這時間我能打幾千行代碼，有這時間我能寫好幾個需求文檔，有這時間我設計稿都出來了……拜托，什么都能做，就是不要讓我寫文檔。

以上腹誹也許有夸大成分，但我相信是很多人的心聲。可作為交付團隊，我們完全理解。

1、確保知識管理可持續改進

我們過往的經驗是，交付團隊會承擔較多的責任在知識體系的統籌搭建和管理上，制定計劃、貫徹執行、嚴格審閱、形成標準，并根據產品的版本迭代持續地更新資料，補充修正。

Plan→Do→Check→Act，按W．Edwards．Deming的PDCA循環開展知識管理：計劃，選擇和分析問題；執行，貫徹解決方案；檢查，改變的結果；行動，解決方案的標準化和反思學習。這是一個不斷重復的循環，知識管理來自于持續不斷的、增加的戴明環的運轉。

我們會按交付對象對應的知識交付形成團隊小組，根據交付對象的優先級對知識進行梳理、審核、改進，對于未解決的問題留待下一個PDCA循環里更新。確保先把面鋪開，再按優先級逐個攻克問題。

?

2、知識管理需要正向激勵

很多時候，我們過多地苛求知識管理者的職責，而忽視了他的權益。以文檔編寫者為例，他將對產品和技術的隱性知識轉化為客戶可理解并接收的顯性資料，這本身是件投入產出比很高的事。但由于文檔編寫者鮮少是文檔的交付者，他無法直接獲取到客戶的反饋，也就因此無從得到激勵，或可改進的建議。

彼得·德魯克也曾說過，

知識必須不斷地被改進、挑戰和提升，否則就會消失。

在重視知識誕生的同時，知識的存取、分享、使用和反饋都需要同步。對貢獻知識的人而言，他明白了自己輸出知識的價值和不足；對獲取知識的人而言，他有責任對知識給出評價和反饋。知識在傳播和使用的過程中，達到大和諧。

?

3、知識管理的影響需要傳播

前文雖然提到知識管理，我們給它包裝了一個稍顯酷炫的外殼，但其實身在其中的人都知道這差事有多苦。不僅如此，其實在To B產品對外服務本身都是苦澀的。一方面領導要自上而下打氣、鼓勵并倡導團隊成員主動或被動地進行知識管理，把老底兒掀出來，讓客戶大開眼界；一方面作為交付團隊，最貼近客戶、商務、架構師和合作伙伴的這群人，你們需要把難得的甜頭分享給團隊成員，哪怕這糖里含著玻璃渣兒。

很榮幸參與了騰訊內三款產品的對外交付工作，我目睹了舊產品在對外停止服務半年后，有存量客戶求助時我們依然保有充盈的知識庫，無需耗費人力即可滿足客戶需求；在目前服務的產品中，我們正持續改善知識管理體系，開始按不同交付對象提供不同的知識，一方面促進新人速成，一方面在應對客戶刁難時在某種程度上也會游刃有余，畢竟料已不在心中，在身上了。同時，知識產權的申請，我們可以看到團隊內申請的專利絡繹不絕，自2016到現在，我個人申請過25項專利，團隊共計有60項左右的國家專利已完成立項。

?

04

總結

目前全球范圍內出現巨大的網絡通信潮流，全世界的人們都被有形或無形地聯結在一起，知識信息不斷地在全球流動。知識管理，不僅是對外服務客戶、或是構建企業人才文化的一種手段。

站在To B服務的視角，有意識地開始去構筑屬于本產品的有競爭力的知識管理體系，對現有的工作流程和交付手段進行再造，順應時勢高效、健康且可持續地服務市場，去贏得競爭的勝利和客戶的滿意度；站在自我成長的角度，每天面對網絡上五花八門排山倒海的碎片化信息，究竟你能吸收多少，能將這些零散的信息轉化成顯性知識嗎？

回到最開始的問題，與其抱著一種與客戶對峙的態度被動地應付，不如主動出擊，理清服務脈絡，冷靜下來思索下，是否可以從知識管理上著手去突破，繼而殺出一條血路？捕獲“客戶”的關鍵信息，組織知識資源，創建知識地圖，識別未被滿足的缺口，對知識體系進行再造，讓團隊從重復的交付活動中解放出來。

我們創造知識，而知識讓我們走得更遠。

?

參考文獻

JamesA.Fitzsimmons，Mona J. Fitzsimmons.服務管理運作、戰略與信息技術[M].機械工業出版社，2017年：159.

KimizDalkir.Knowledge Management in Theory and Practice[M].?MIT Press,2017年：47.

彼得·德魯克.21世紀的管理挑戰[M].機械工業出版社，2009年

伍建喬.構筑企業的知識競爭力[J].《廣東科技》，2010，21：68-68.

↘好文推薦：

騰訊工作心得：原型該畫到什么程度？

開發到底喜歡看怎樣的需求文檔？

產品經理學PMP，有必要嗎？

點個“在看”吧

總結

以上是生活随笔為你收集整理的To B路上，除了服务管理，还要知识管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。