在整个ToB服务生命周期中，我们都期望能获得可靠、安全的知识、信息和数据，从而提升服务质量，提高满意度，降低服务成本。
进入知识经济时代之后，信息技术不断提升，社会信息化程度越来越高。在这种大环境下，对To B产品而言，赢得竞争的胜利和客户的满意度，就必须构筑属于自己的、有竞争力的知识体系。
不知道你是否经历过这种局面：客户隔三岔五要资料，资料捧过去手还没焐热就开始索要方案、要试用产品、要响应需求、要定制化功能……问题频发，需求不断，竞争对手虎视眈眈，客户的决策迟迟未定。
成日埋没在客户源源不断的需求之中，无法衡量团队的投入产出比，也不清楚如何去评估客户的价值。
坦白说，我经历过这种鸡飞狗跳的日子，客户决定要什么也许是一瞬间的事，但对于项目交付团队来说就不那么好捱了：
客户来了，一个炸弹丢进来，我军于动乱中紧急动员，磕磕绊绊挤点料出来，危机暂时缓解，下一枚炮弹又投过来了，大坑明晃晃地砸在眼前……周而复始。
我开始怀疑：究竟是哪里出错了？
痛定思痛，本文正是基于多次从坑里滚进去又爬出来的经历给的一些关于To B产品服务的思考。
to B领域博大精深，在此按下不表，我仅从服务与知识管理两个层面给出单薄的分享。
有一点可以确定：在整个ToB服务生命周期中，我们都期望能获得可靠、安全的知识、信息和数据，从而提升服务质量，提高满意度，降低服务成本。
进入知识经济时代之后，信息技术不断提升，社会信息化程度越来越高。在这种大环境下，对To B产品而言，若想顺应时势高效、健康且可持续地服务市场，赢得竞争的胜利和客户的满意度，就必须构筑属于自己的、有竞争力的知识体系。
过去，我们讲到企业的资产管理，通常都会从“人、财、物、机器”等方面入手，但很少会考虑到知识体系的布局。即使有企业把知识作为资产来管理，也通常停留在专利和发明上。那么，究竟什么是知识管理呢？
关于知识管理的定义非常多，至今还没有一个统一的说法。
美国德尔福集团创始人之一卡尔・费拉保罗给出的一个定义是这样的：
知识管理就是运用集体的智慧提高应变能力和创新能力，是为企业实现显性知识和隐性知识共享提供的新途径。
这里面包含三重含义：
1. 个人知识集体化，把个人脑中的知识变成集体的公共知识；
2. 隐性知识显性化，把个人或集体长期积累的优秀经验总结、规范、标准化成一个模式，该模式是流动的、可复制的；
3. 建立共享知识系统，个人或集体通过系统的知识共享平台，让每个人的能力都通过共享得到放大。
华夏基石的董事长彭剑锋针对知识的经营也提出了一些洞见：
知识的经营，就是要建立企业的知识管理体系。现在人才的流动性越来越强，人会走，但知识会留下来，知识和知识产权是企业最大的财富。
知识管理在对外服务客户和对内形成企业文化上都如此重要，那么作为初涉To B服务市场的我们，该如何打造产品有竞争力的知识管理体系呢？
下面我想从三方面分享下我对知识管理的理解：
在负责对外交付工作中，我和商务、渠道、架构师、合作伙伴和客户都在频繁地接触，常有的情况是这样的：
“我要给客户介绍产品，有没有产品宣讲材料？”
“合作伙伴培训，有教材没？”
“要给客户制定方案，有部署架构文档么？”
“客户要招标了，产品控标参数呢？”
“准备拟合同了，合同报价模板呢？”
……
来自各方的文档需求应接不暇，我不得不怀疑，是不是对于To B业务而言，知识即文档？
每逢提及知识管理，首当其冲想到的就是文档的交付。
你可能要开始掰手指头枚举：产品文档、技术文档、部署文档、运维手册、测试报告、解决方案、竞品分析文档、市场调研报告、招标引导材料、投标方案、项目计划书……
的确，一开始我们的思路都是这样的，站在产品自身的角度，我们冥思苦想，客户到底想要什么，他想看到什么。
然而，在实际交付的过程中我们发现，很多时候，我们连知识的交付对象是哪些角色都不清楚，更别提交付物了。
是客户吗？客户的决策层？客户的执行层？客户的服务商？还是客户的用户？
不够，我们要服务和交付的对象至少包括：
客户&客户的服务商
公司合作伙伴（渠道商、服务合作伙伴、ISV）
架构师团队
公司内销售上下游
公司内其他业务团队
不同业务面向的群体都大同小异。但从广义层面上来看，上述的这些交付对象都属于我们的“客户”。
那么，锁定这些“客户”群体，我们要交付什么？
回过头来，产品文档、技术文档、部署文档、运维手册、解决方案、竞品分析文档、市场调研报告……够了吧？
不是覆盖面的问题，是思路上有问题。请摆脱传统的To C产品思维，站在“客户”的立场去思考，我想要什么？我想看到什么？
1）for 客户&客户的服务商
以政府客户为例，从前我们也许是以政府价值为导向去提供服务，但站在政府的角度，摸底政府的决策链，他们在思考什么？
如今的政府管理正是顾客导向，如何为自己的顾客服务是他们最忧心的命题。
而政府的顾客，一是指产品和服务的最终使用者（即对外公众），二是指产品和服务供给过程中的参与者（即对内公务员）。
它好比一座倒过来的金字塔，将塔尖指向顾客那里——一竿子插到底，政府关注的焦点对准顾客的需要，以顾客为导向，以顾客的满意度作为政府运行最大的使命和考量。
基于这样的背景，政府跟你接洽，他不得不深谋远虑：
请证明你的产品和技术实力，说服我；
纸面上的介绍不够，我要全方位体验下；
产品OK，但我要的是一套方案，不是一款产品；
方案通过，请做好方案包装便于我向上汇报；
不够，我需要相关测评证书的辅助；
汇报完毕，内部准备立项申请预算，烦请协助我提供项目可行性研究报告；
立项通过，我需要公开招标；
项目计划书呢，该签合同了；
我要内部大面积推广，公务员培训少不了。
……
以上对客户决策链的揣摩并非空谈，这都是源自我们对客户销售漏斗的盘点，每到一个销售阶段，几乎可以提前预判到客户想要什么，我们能提早做什么准备。而这些准备，都源自于我们对知识的管理。
证明产品和技术实力，产品技术白皮书丢过去；想快捷体验，我给你分配装修好的样板房体验帐号，一个月时间你考虑清楚。
你要方案？好啊，结合你的业务需求、服务商的实力和产品自身的标准能力，你来评估下；要证书？专利证书、软著证书、等保三级测评证书、压测报告……都准备好了；要招投标，产品控标参数按版本更新好了，标准的投标技术方案也候着呢；要运营推广，没问题，用户和管理员的操作手册都有……
2）for 公司合作伙伴
作为公司的合作伙伴，在此以服务合作伙伴为例，他们又在想什么？
——利益。
毋庸置疑，服务商通过与本公司达成良性合作可以最大化地获得商机和利益。一方面通过参与项目的服务和交付赢得长期收益，一方面也想借此机会向客户兜售自己的产品，获取客户机会。
那么，服务商的心路历程又是怎样的？
我想和你达成合作，商务模式、报价方面如何？
我司人员的考核、认证、定级方式是？
我要尽快上手，赢得贵司对我交付能力上的认可。
在项目交付过程中，我与贵公司之间的合作方式是？
……
在我们剩下半条命的时候，我们把另外半条命交给合作伙伴，以此形成一个生态圈。与合作伙伴的背靠背合作才能促进双方的共生共赢。在近一年的交付工作中，我组织过不下6次的合作伙伴培训，合作伙伴对上述问题尤为关注。
商务模式不清楚，请先阅读下合作伙伴服务协议；人员考核认证不了解？培训组织起来，定级面试搞起来；想快速上手，丢给你一捧《合作伙伴养成记》，内含产品的来龙去脉、常见问题、运维和开发的文档说明；交付过程如何背靠背，请阅读产品服务目录……
3）for 销售上下游
目前我们在对外服务的过程中，会与公司内多方销售打交道。商务兴致勃勃地牵线客户过来，我们如何从容应对呢？
首先，你要有料。
站在商务角度，他有自己的KPI压力，他想拿单，这点我们都能理解；那么，我们可以提供什么料给他呢？
客户领导对你们非常感兴趣！有没有宣讲材料我丢一份过去？
客户说想详细了解产品技术能力，能约架构师面谈么？
现在客户在几家厂商中选型，我们有没有竞品对比材料？
客户提了一堆需求和问题，有人可以帮忙解答下吗？
客户打算招标了，给点儿控标建议？
打算签合同了，项目计划书给下？
……
平心而论，商务确实对产品的理解可能不深，我们更多时候要去储备FAQ知识库，辅助商务过滤客户提过来的难题。在明确好客户商机后，架构师会与商务一同负责跟进客户。
以此类推，对于其他交付对象，我们需要根据他们的关注点，去看到底需要管理什么知识。
如果非要给知识做一个类型上的定义，那么知识可以是一份通用文档、一叠参考资料、一栋精打细作的产品体验样板房、一次组织有序的培训……
在对外服务的过程中，知识可以是各种各样的，只要能沉淀下来的，可被人重复使用，降低服务成本的都是一种知识。
之前我们在与一位资深的咨询顾问聊到知识管理时，他提到的一个知识转化的概念——“DIKW”，即数据、信息、知识和智慧。在《Knowledge Management in Theory and Practice (MIT Press)》一书里，作者KimizDalkir针对DIKW一一做了解读。
在现今的大数据时代，我们每天接收到不计其数的碎片化数据，这些数据是离散的，无法在我们脑中成体系，几乎是过目即忘。但当你有目的性地捕获数据时，你总有能力去对这些数据进行分析、综合，并进一步转化为信息，这是第一步。
而信息又是什么？
——它来自于为数据提供上下文，它通常存储在半结构化的内容中，便于查询、重用，使得错误不再重复，并不会重复工作。将信息结构化地进行组织，便形成了知识。
知识，它是由个人的隐性经验、洞察力和判断组成的。它并非是基于目前提供的服务，而是从以往服务的经验，对最近和预期服务的认识去做的收集。
而智慧呢？它赋予了物质的终极洞察力，具有应用和情景意识，提供强烈的意识判断。
从数据到信息，再到知识转化为智慧，形成一个闭环，这个闭环最终的方向都是指引我们达成企业战略，实现个人目标。
听起来像一碗鸡汤，还是那种用廉价鸡精冲出来的鸡汤。
可其实，知识管理的最终目标就是让组织将他们的集体知识融入到每一个交付物中，作为他们、他们的合作伙伴和他们的客户创造价值的终极方式。
那么，对于To B产品而言，在打入企业市场时，简单地组织团队成员写几篇文档就OK吗？这就是To B产品的知识结构吗？
前面我们提到，知识管理是为企业实现显性知识和隐性知识共享提供的新途径。注意，隐性知识，是高度个性化且难于格式化的知识；显性知识则是用文字和数字表达出来，容易以硬数据的形式交流和共享的知识。
图片源自Microsoft，已授权
文档只是隐性知识转化为显性知识的最常见的形式之一。
除此之外，我们会将服务管理体系流程规范化、表单化；我们会针对软件自身的特性搭建样板房，将本软件的产品技术能力显性表达，供客户在一定时间周期内免费体验，便于客户快速地了解本软件。这都是一种知识转化。
在此以政府客户为例，我们从客户&客户的顾客角度去看到底要把哪些隐性知识用文档表达出来。
譬如：
从管理层角度，他需要产品技术白皮书，产品宣讲材料，产品解决方案；
从中层员工的角度，他需要整体运营运维手册，用户操作指引，开发集成方案等偏实操性的内容；
从基层员工的角度，他关心如何使用，有什么功能，我能做些什么。
以我之前负责的私有化产品为例，我们支持企业定制化名称和logo，但在logo的设计和尺寸适配上往往漏洞百出，客户频繁返工，开发打包客户端的时候叫苦不迭。
一方面，开发和设计同学清楚什么样的LOGO合规；一方面，客户也自认为他理解这一套规则。
这就造成了信息不对称，两边的成本投入都很大。解决的方式很简单，把我们想传达给客户的规范机制通过流程表达出来，我们制定LOGO在各终端的物料规范，圆角、透明度、尺寸、色彩精度、不可侵犯区域、易错点……一一列举出来，每个位置的LOGO均给出对应的示例图。若客户有一定的设计基础，我们还提供sketch文件，供客户直接套用尺寸模板。
好了，客户按我们拟定的标准顺利交付LOGO资源包，可以了吗？不够，我们还进一步提供LOGO的审核标准，便于架构师在拿到客户的反馈后根据审核规则快速检索到其中的坑，尽早暴露出来，再交由客户改进。最终确认完毕后再反馈给产品研发团队。
同样，在其他流程方面，譬如客户立项报备、客户端打包、POC部署、客户需求和问题响应等方面，为达到与各方交付对象的信息对称，我们都一一对这类知识转化为通俗易上手的流程。
顾名思义，样板房是购房者装修效果的参照实例。
以企业IM为例：若客户自行申请注册体验，那么初始化的数据都是空的，客户需要导入组织架构和人员信息，对接应用及接口能力，在管理后台做相关的配置之后，才能真正达到有效的体验。
因此，在采购本产品前，我们会引导客户去体验已功能已装修完毕的样板房。根据客户的性质，模拟不同类型的客户对应的样板房，分配有限的帐号，在一定时间周期内让客户进行体验，到期后便回收帐号。
通过这种方式，我们将产品的隐形能力通过可视化的方式传达给客户，打破客户对产品一知半解的懵懂状态。
明白了知识管理的重要性，明确了知识的交付对象和交付物之外，就要开始动工了。
据我的观察以及多次的血泪教训，不得不承认，其实大多数人都是疏于转化知识的。“不就是写个文档吗？”苦力活，不讨好，没什么绩效可言，对我的工作有什么帮助？有这时间我能打几千行代码，有这时间我能写好几个需求文档，有这时间我设计稿都出来了……拜托，什么都能做，就是不要让我写文档。
以上腹诽也许有夸大成分，但我相信是很多人的心声。可作为交付团队，我们完全理解。
我们过往的经验是：交付团队会承担较多的责任在知识体系的统筹搭建和管理上，制定计划、贯彻执行、严格审阅、形成标准，并根据产品的版本迭代持续地更新资料，补充修正。
Plan→Do→Check→Act，按W．Edwards．Deming的PDCA循环开展知识管理：计划，选择和分析问题；执行，贯彻解决方案；检查，改变的结果；行动，解决方案的标准化和反思学习。这是一个不断重复的循环，知识管理来自于持续不断的、增加的戴明环的运转。
我们会按交付对象对应的知识交付形成团队小组，根据交付对象的优先级对知识进行梳理、审核、改进，对于未解决的问题留待下一个PDCA循环里更新。确保先把面铺开，再按优先级逐个攻克问题。
很多时候，我们过多地苛求知识管理者的职责，而忽视了他的权益。
以文档编写者为例：他将对产品和技术的隐性知识转化为客户可理解并接收的显性资料，这本身是件投入产出比很高的事。
但由于文档编写者鲜少是文档的交付者，他无法直接获取到客户的反馈，也就因此无从得到激励，或可改进的建议。
彼得·德鲁克也曾说过：
知识必须不断地被改进、挑战和提升，否则就会消失。
在重视知识诞生的同时，知识的存取、分享、使用和反馈都需要同步。
对贡献知识的人而言，他明白了自己输出知识的价值和不足；
对获取知识的人而言，他有责任对知识给出评价和反馈；
知识在传播和使用的过程中，达到大和谐。
前文虽然提到知识管理，我们给它包装了一个稍显酷炫的外壳，但其实身在其中的人都知道这差事有多苦。
不仅如此，其实在To B产品对外服务本身都是苦涩的。一方面领导要自上而下打气、鼓励并倡导团队成员主动或被动地进行知识管理，把老底儿掀出来，让客户大开眼界；一方面作为交付团队，最贴近客户、商务、架构师和合作伙伴的这群人，你们需要把难得的甜头分享给团队成员，哪怕这糖里含着玻璃渣儿。
很荣幸参与了公司内多款产品的对外交付工作，我目睹了旧产品在对外停止服务半年后，有存量客户求助时我们依然保有充盈的知识库，无需耗费人力即可满足客户需求。
在目前服务的产品中，我们正持续改善知识管理体系，开始按不同交付对象提供不同的知识，一方面促进新人速成，一方面在应对客户刁难时在某种程度上也会游刃有余，毕竟料已不在心中，在身上了。
同时，知识产权的申请，我们可以看到团队内申请的专利络绎不绝——自2016到现在，我个人申请过25项专利。
目前全球范围内出现巨大的网络通信潮流，全世界的人们都被有形或无形地联结在一起，知识信息不断地在全球流动。知识管理，不仅是对外服务客户、或是构建企业人才文化的一种手段。
站在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.
看看如何榨干B2B市场总监的营销经验的？SaaS平台的营销策略
B2BGrowing，首个专注B2B营销增长的媒体，探究B2B增长的道与术，分享B2B增长相关的案例玩法、工具、干货资讯。更多精彩，关注B2BGrowing公众号，ID：B2BGrowing，领取福利！
扫一扫在手机上阅读本文章