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