编辑导语：对于一个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个维度来评估关键知识域的目标与现状：掌握度、扩散度、编码度，具体的评估标准如下：

掌握度：组织成员所掌握该知识的最高水平，分为四级：

1. 入门水平：对该知识域仅有初步的了解，掌握概念
2. 初级水平：有基本的知识，在指导下能应用知识
3. 专业水平: 能够独立执行和推进工作，具有相关专业资质与经验
4. 专家水平：在本知识领域内领先，具有行业影响力和领导力

扩散度：组织中应用该知识的大多数成员所掌握该知识的水平，分为四级：

1. 入门水平：对该知识域仅有初步的了解，掌握概念
2. 初级水平：有基本的知识，在指导下能应用知识
3. 专业水平: 能够独立执行和推进工作，具有相关专业资质与经验
4. 专家水平：在本知识领域内领先，具有行业影响力和领导力

编码度：该知识在组织内的显性化程度，分为四级：

1. 知识只存在于员工头脑中
2. 知识已被显性化，但未加归纳整理
3. 知识已形成了固定的方法、理论、框架体系
4. 知识成为最佳实践，能够给予员工最直接、最佳的指导

通过深度访谈、问卷调查得到了调研数据，进行统计分析后得到如下数据：

从表格中可以看出关键知识域的现状与目标的差距，这就是知识管理要解决的问题，也就是说要通过知识管理来缩短现状与目标的差距。

手机游戏开发是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. 内容运营

内容运营的重点在于内容的数量与质量、以及两者之间的平衡。

内容数量太少，就会缺乏人气。

内容质量太差，更是留不住用户。

追求数量，会牺牲质量；追求质量，会影响数量。所以还要控制数量与质量之间的平衡。

知识管理系统上线后，如果内容运营没做好，前期宣传推广工作做得再好也没用。

用户第一次登录知识库往往是因为好奇心驱动，看了之后发现内容很少或内容很差，就再也不想来了，知识管理系统就慢慢荒废了，成了“鬼城”。

所以知识管理系统上线后，先不急着做宣传推广工作，得先有一些内容。

如何做内容运营的“冷启动”呢？

1. 把散落在公司内部各处的优质内容进行梳理、归类，按主题存到知识库中；
2. 发动知识官（本身就是业务骨干）在知识库中贡献内容；
3. 邀请爱学习、爱分享的种子用户（比如公司的兼职讲师）来知识库贡献内容；
4. 由知识官团队对内容进行审核，控制内容的质量，不能追求数量而牺牲质量；
5. 内容逐渐增多后，按主题整理出知识地图，特别是与工作岗位直接相关的知识。比如“主程岗位知识地图”是主程序员必须掌握的知识；
6. 对优质内容进行宣传，给知识库带来人气；
7. 配合激励制度，鼓励更多人参与贡献优质内容。

3. 活动运营

定期组织活动可以提高知识库的活跃度。

知识管理系统中有配套的积分体系，在知识库中贡献知识可以获得积分，有了积分之后就可以参与知识库的活动，比如积分竞品、积分抽奖活动。

活动奖品并不贵，就是一些书、电子产品等，如图所示。

实践证明，这些东西很受研发人员的喜爱。

4. 数据分析

数据分析是产品运营阶段必做的事情。

在知识管理系统的运营中，也需要做数据埋点、采集数据、数据分析，并根据数据分析的结果持续迭代优化产品。

例如：

1. 根据搜索词频，推测用户的内容需求：比如，从后台搜索词频分析发现，“iOS开发”的搜索频率很高，说明用户关注这方面的内容，知识库运营团队就开始重点去挖掘、梳理这方面的内容。
2. 根据用户的阅读历史、收藏、点赞、评论行为来推荐内容。这个有点像今日头条、抖音的个性化推荐，但在实现过程中并不需要像今日头条、抖音那样用到大数据、AI技术，用简单的标签就可以实现预期的效果。
3. 根据收藏数、点赞数来推荐内容，运营团队会定期把收藏数、点赞数多的词条放到精华区、在工作群中推送。
4. 根据部门与岗位调整首页。知识库的内容与频道越来越多，根据用户的岗位、所在部门来调整知识库首页内容。

5. 运营成果

知识库运营一年后的数据，如图所示。

这数据与互联网产品动辄上亿的数据比较起来微不足道，但作为企业内部系统而已，这运营数据已经超出预定的目标，也超出领导的预期。

通过这些数据很难体现知识管理的价值，你看数据可能也没有直观的感觉，接下来再分享2个小案例。

案例1：

有个开发人员碰到一个技术问题（如下图），加班了3天时间终于解决，多么痛的领悟！

其他人在做类似的项目，也可能碰到同样的问题，是否也要花同样的时间来解决？

不！通过知识管理，可以提高解决共通问题的效率！如下图：

案例的启示——不重复发明轮子！通过知识管理帮助解决共通问题，减少重复投入。

案例2：

一名程序员4年前进入公司，成长得很快，做得很出色，晋升为主程序员，可惜后来离职了……

他给公司留下了什么？

4年来，他在公司的知识库中留下了51个经典案例！

这些案例是实际项目遇到的问题总结出来的经验教训，是百度搜索不到的。

这些案例被同事们学习次数超过2000次！

案例的启示——企业都很重视有形资产的管理，而员工的知识与经验是公司重要的无形资产，如果没有知识管理，就会造成资产流失。

前面提到，知识管理的推进过程是从点到面，先在研发部门做试点。试点期间，陆续有其他部门来取经，主动请求帮助他们开展知识管理、在知识管理系统上给他们开通权限与频道。

再后来，公司获得了亚洲最受尊敬的知识型组织(MAKE)奖，这是知识管理界的最高荣誉。

七、总结

本文介绍了从0到1做知识管理系统的整个过程。

做一个B端产品的3个步骤：业务调研分析、设计解决方案、方案实施与运营。

这3个步骤就像医生给病人看病一样，先望闻问切分析病因，再针对性开药方，病了先吃几天要再复查。

企业要开展知识管理，对企业来说也是一场转型与变革，需要从People、Process、Tools（简称“PPT”）这三个方面进行协同配合。

在设计解决方案时，除了产品方案还要有配套的业务方案。

本文也介绍了在企业开展知识管理的过程。

要在公司中实施知识管理，有哪些方面很重要呢？

1）老板重视知识管理

这是非常重要的一点，把它列在第一位。

知识管理不是一朝一夕就能见到成效的，老板如果不重视，不投入资源，知识管理很容易半途而废。

知识管理的难点在于很难量化知识管理的价值，比如：您会经常做笔记，您也认为做笔记对您的学习与成长有帮助，但具体有多大帮助？您的收入中有多少是做笔记帮你带来的？这是业界难题，所以，要推行知识管理，首先要有老板的认可与支持。

2）整体规划、分步实施、重点突破、小步快跑

• 整体规划：知识管理要与公司的业务战略结合，涉及到多个部门，要搭建相应的激励、考核、宣传制度，要建设知识官团队，要建设知识库，是个系统工程，所以要从整体上进行统一的规划。
• 分步实施：知识管理的推进，要由点到面，逐步推进，因为资源有限，贪多求全什么都做不好。
• 重点突破：先从需求最迫切的部门开始、先从公司的战略产品开始，这样容易见到成效，并积累经验，为推广到其他部门与业务打下基础。
• 小步快跑：遵循互联网的产品思维，快速迭代、快速试错，出现问题可以及时调整。

3）从你自己、从你带的团队开始做知识管理

只有大型研发团队才能做知识管理吗？其实每个人、每个团队都可以做知识管理。

对于只有几十人的研发团队，可以没有知识官团队、可以没有知识库平台、可以没有知识管理制度，但只要你有这个意识，就可以从你开始，定期总结你的心得与经验，分享给你的小伙伴们，逐渐影响你身边的人。

 

本文由 @张在旺 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议