【深度案例】如何从0到1做一个B端产品？

　　随着互联网流量红利的消失，互联网已进入下半场：从消费互联网到产业互联网。

　　国家的第十四个五年规划提出：要加快数字化发展，主要目标任务中有几个关键词：数字产业化、产业数字化转型、数字社会、数字政府、数字中国。

　　产业互联网、企业数字化一定离不开数字化产品、特别是B端产品。比如，医疗数字化就需要很多B端产品来落地、实现数字化，像电子病例、AI辅助诊断、远程医疗、传染病自动预警系统、婴儿防盗系统等等。

　　B端产品，也叫 To B(To Business)产品，即产品的购买者是企业或组织。B端产品主要用来帮助企业解决某类经营管理问题和业务问题，为企业提升效率、降低成本、保证品质和控制风险。

　　员工的知识经验是公司的宝贵资产，但这些资产散落在各个地方：员工的头脑、个人电脑、公司论坛、共享目录、网盘……

　　知识经验没有得到有效管理，就不能被有效利用，造成资源的浪费、无形资产的流失……

　　A公司也不例外。常有骨干被高薪挖走，造成经验的流失；团队中新人较多，难以快速上手，造成研发效率低下，多次错失市场良机，CEO为此很是苦恼。

　　CEO在EMBA班上听说了知识管理，觉得值得尝试，于是打算在公司开展知识管理，并计划开发一个知识管理系统供内部使用，如果效果好的话，再把它产品化对外销售。

　　作为产品经理，接到一个任务后不要马上开始动手执行，应该先梳理一下工作思路。

　　建议你先拿出一张白纸来，用思维导图参考下图的结构，梳理出你的工作思路，再继续看后面的内容会更有代入感。

　　业务调研分析：B端产品主要是为企业解决经营管理与业务问题，首先要做业务调研分析，了解业务现状、分析业务问题，从而设定项目目标。

　　设计解决方案：针对要解决的业务问题与项目目标设计解决方案，包括业务方案（设计配套的组织架构、流程、制度等）与产品方案（需要开发的IT系统）。

　　方案实施与运营：解决方案的落地实施、IT系统的开发上线，以及系统上线后的运营、持续迭代优化。

　　产品化与商业化：这个是非必须的步骤，根据企业需求，决定是否把应用于企业内部的项目做成产品并对外销售。

　　前面提到，B端产品主要是为企业解决经营管理与业务问题，所以产品经理在做B端产品时，首先要做业务调研分析，了解业务现状、分析业务问题，从而设定项目目标。

　　例如：IBM给某能源集团做咨询项目时，是按照下图所示的流程开展业务调研工作的。

　　在开展业务调研之前，如果产品经理没有该业务领域的经验，要先花时间做功课，提前熟悉业务领域，否则连访谈提纲、调查问卷都设计不好。

　　如何快速熟悉新的业务领域？重点是“快速”，企业是不可能等你学2年业务后再做产品。有以下几点建议：

　　补充行业知识：通过阅读书籍、网上资料获取基础知识，建立对行业的初步认知。

　　竞品分析：通过竞品分析，了解行业中的同类产品，对你要做的B端产品有个形象化的认识。

　　请教行业专家：通过请教行业专家，了解行业中的隐形知识、实践经验、常见的误区，并获取建议。

　　深入业务一线：自己到业务一线通过访谈、观察、轮岗体验等方式加深对业务的理解。

　　产品经理以前没有做过知识管理系统，知识管理对他来说也是新领域。所以决定先花时间熟悉一下知识管理，再制定下一步的调研计划。

　　阅读行业报告：找到了IBM给中国移动做过的知识管理咨询方案，对开展工作的思路有了启发。

　　竞品分析：分析了知识管理系统的相关产品，比如蓝凌、互动百科等，对知识管理系统有了形象化的认识，对知识管理领域的解决方案有了大概的了解。

　　请教行业专家：请教在蓝凌工作过的专家，了解开展知识管理工作的难点，得到了一些建议。

　　在B端项目中，调研对象可以按岗位层级分为3类：高管、中层干部、基层员工。

　　高管：调研战略层相关的内容，比如战略定位、战略目标、经营策略、管控模式等；还需要了解高管对项目的期望值与评价标准，高管是项目的重要评价者。

　　中层干部：调研战术层相关的内容，比如流程管理、组织架构、培训考核、绩效管理等内容。

　　基层员工：调研操作层相关的内容，比如日常任务、操作步骤、流程细节、业务规则等内容。

　　虽然全公司每个部门都需要做知识管理， 但产品经理打算先选择一个部门作为试点，在试点中总结经验教训，有效果后再逐步推广到其他部门，这样操作会更稳妥一些。

　　那选择哪个部门做试点呢？产品经理选择知识管理需求最迫切的部门——研发部。研发部人员流动频繁、有知识管理的痛点，这样找他们配合的时候会更容易，从他们开始做知识管理也更容易见到效果。

　　产品经理针对不同的访谈对象准备了不同的访谈提纲，研发总监的访谈提纲如图所示：

　　在访谈的过程中，控制节奏，根据访谈的效果迭代改进访谈提纲。同样，在实施问卷调查时，也是先小批量发放问卷，再根据问卷调查的效果迭代改进调查问卷。

　　乙方到甲方（与乙方不是同一个公司）公司做项目时（包括业务调研），建议双方共同组建联合项目组，最好请甲方领导担任项目的总负责人。采用双项目经理制，甲方、乙方各安排一个项目经理作为牵头的负责人。甲方派业务代表担任甲方项目经理。

　　接下来要对调研得到的数据进行整理分析，输出调研报告，生成初步方案，并向领导汇报。

　　B端产品大多应用于企业内部、涉及到多个部门，所以要通过调研得到企业的组织架构图，这有助于在业务调研阶段找到合适的调研对象、在需求分析阶段做干系人分析。

　　客户不希望新做的B端产品是一个独立的信息孤岛，所以还要考虑与企业现有系统的整合与协同。

　　知识管理需要与企业战略、核心业务相结合才有价值，所以要确定对企业战略、核心业务发展有影响的关键知识域。

　　从两个维度来确定关键知识域：目前影响度（对当前业务的影响度）、未来影响度（对未来业务、战略方向的影响度）。

　　把目前影响度、未来影响度都比较大的关键知识域，作为知识管理的重点。如图所示：

　　从3个维度来评估关键知识域的目标与现状：掌握度、扩散度、编码度，具体的评估标准如下：

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

　　手机游戏开发是A企业的战略方向，但掌握度、扩散度、编码度都需要提升，特别是掌握度，与目标有较大差距，需要尽快提升、缩小差距，否则就会影响企业战略目标的实现。

　　从图中可以看出，关键知识域的提升方案并不限于知识管理系统，例如：掌握度提升方案中，组建情报小组、建立创新机制都跟知识管理系统无关，但对提升组织的关键知识域的掌握度又有帮助。

　　所以，知识管理并不等于做个知识管理系统，这在后面的“设计解决方案”中会展开介绍。

　　通过业务调研，明确了要解决的业务问题、要达成的项目目标，接下来开始设计解决方案。

　　B端产品是为了解决企业经营管理问题，但B端产品只是帮助企业解决经营管理问题的手段之一。

　　B端产品也不是万能的灵丹妙药，很多企业的业务问题其实是模式问题、管理问题，靠软件产品是无法解决的。比如，企业的生产效率低下，可能是组织架构的问题，可能是激励制度的问题，也有可能是生产工具的问题。如果没有对症下药，手里拿着锤子看什么都像钉子，指望一套B端产品就能解决所有问题，最后的结局往往是一地鸡毛。

　　作为B端产品经理，不要把做产品、卖产品作为核心目标，应该把帮助企业解决问题、帮助客户成功作为核心目标。客户的问题如果没有得到解决，你的产品做得再好，客户也不会满意，会认为是你的产品的问题。

　　产品经理只有跳出产品的范畴，从业务的视角去思考、分析问题，帮助客户解决问题，帮助客户成功，这才是产品经理的真正价值所在。

　　有时候，企业要解决的问题是B端产品可以解决的，但只考虑B端产品是不够的，得从系统的角度来设计一套整体解决方案。

　　例如：有的公司花了很多钱买了一套昂贵的ERP，但是没有实施成功，原因不是ERP产品做得不好，而是其他原因。

　　这些导致ERP项目失败的原因都跟ERP产品无关，但项目失败了，甲方就会认为是ERP产品不好。

　　所以，ERP产品经理不能只考虑ERP产品本身，要从系统的角度设计一套整体解决方案。

　　前面在“制定知识管理初步方案”这一部分提到，要解决企业“人来人往”带来的问题，需要一套系统的解决方案：包括商业情报、人才培养机制、构建知识管理系统等。

　　业界有很多公司在做知识管理，他们也搭建了知识管理系统，有知识库，但上面内容很少，使用率极低，算是荒废了。

　　知识管理不是有了知识管理系统、知识库就可以，还需要专人专岗负责推进、有配套的制度与流程。

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

　　接下来分别来介绍应用方案设计（包括People、Process）与产品方案设计（包括Tools）。

　　要有专人负责推进知识管理，所以需要调整组织架构，新增知识管理运营团队、知识官团队，如图所示：

　　在岗位上设置了知识管理专员(负责知识库运营、宣传与推广)、知识管理工程师（负责知识库的开发与运维）。

　　②知识官团队：从一线业务部门中挑选业务骨干担任知识官，是个兼职的岗位，所以知识官团队是个虚拟组织。他们充当桥梁的作用，帮助收集业务部门的知识管理需求、推进创新方案与知识地图在业务部门的应用、知识库的内容审核等。

　　管理界有个格言：你想得到什么，就要考核什么。知识管理要跟绩效考核结合，在KPI中新增知识管理的考核项，把知识管理与员工的绩效工资、晋升相结合，激励员工对知识管理的参与热情。

　　具体做法：把知识管理的参与情况用知识贡献分进行衡量，并计入KPI中，如图所示：

　　对知识官也要有考核管理办法，知识官的考核与排名决定了他们能拿到多少知识官津贴。

　　物质激励：员工参与知识的沉淀、分享、学习都会获得积分，积分可以通过抽奖与竞拍来获得相应的奖品（我们总结出程序员比较喜欢的奖品是数码类产品以及技术书籍）。

　　精神激励：员工在知识库中发表高质量的内容，往往会收到很多好评，优秀内容会被管理员推荐到首页，并得到重点推广，这对员工的激励甚至超过物质激励。传统印象中大家可能会认为技术人员都很低调闷骚，但我们发现技术人员其实都很希望自己的技术与技能得到别人的肯定。

　　知识管理不是一个概念或虚无缥缈的理念，要通过知识管理系统/知识库来落地，实现知识的沉淀、传播、应用。

　　这也是企业知识库与百度、谷歌差异化的地方：企业知识库中沉淀的内容都是实际项目、实际产品开发过程中沉淀下来的具体、有效的实践经验与教训。

　　做类似项目的同事往往会经常碰到类似的问题，在企业知识库中可以最快找到他想要的东西。

　　处理一个复杂问题有个常用的策略：分解。把一个复杂的问题分而治之、化繁为简，变成几个小问题，这样解决起来就容易多了。

　　活动命名：要用“动词+名词”结构，如“提交词条”，不要写“工程师提交词条”或“提交”

　　业务流程图的边界适当外延，有助于了解业务全局、了解IT系统在全流程中的位置

　　“审核”不写岗位写意图，如：不要写“经理审核”、“财务部审核”，要写审核意图，如“审核词条内容是否合格”

　　主从活动只留一个：如“提交申请”、“接受申请”是成对的，只要写一个；“交费”与“收费”是成对的，只要写一个。要留哪一个，主要看流程图给谁看，例如：如果流程图是给用户看，就留“交费”，给收费员看，就留“收费”。

　　避免流程图太细：流程图中不要把每个操作步骤都画出来，只要不影响其他泳道的活动，可以先不用画出来。例如，下图就是太细的流程图。

　　通过业务流程派生出功能模块：先识别角色、再识别用例，然后再从用户视角检查是否有遗漏。如图所示：

　　例如，下图所示的知识管理业务流程图中，我们看看哪些角色不是知识管理系统的End User。

　　在知识管理系统的规划中，知识管理专员“统计积分”后，把积分数据用Excel发给HRBP来手动“计算绩效数据”，HRBP不需要与知识管理系统打交道。所以HRBP不是知识管理系统的End User。

　　然后对剩下的泳道进行角色化抽象，可以抽象出研发工程师、知识管理专员、知识官、研发经理这些角色，这些角色会跟知识管理系统打交道。

　　接下来对活动图中的每个活动进行判断，若需要系统支持就是用例，否则就忽略。

　　比如：“提交词条”、“修改词条”等活动需要在知识管理系统中完成、需要系统支持，我们把需要系统支持的活动圈出来。这些都是潜在的用例。如图所示：

　　对每个菱形进行判断，属于某个活动的、不需要系统支持的忽略，否则抽象为用例。

　　例如，“填写原因与改进建议”是一个步骤，在审核词条时一起完成，可以与用例“审核词条是否合格”合并。如图所示：

　　例如，对 开源的HDWiki 进行试用、拆解分析后，发现很多功能非常适合做知识库，如图所示：

　　为了加快开发进度、节约成本，产品经理经过调研决定：知识库部分基于开源的HDWiki做二次开发。

　　例如：在访谈知识官时，知识官提出这个诉求：在审核词条时，由于他们是兼职的，会碰到主业任务很忙时没空审核词条。针对这个诉求，系统可以提供“转移审核任务”的功能，把词条转给其他知识官来审核。如图所示：

　　通过对业务场景进行分析，可以发现一些通过用户访谈无法得到的细节需求。如图所示：

　　把知识管理系统分解成多个子系统、并梳理出功能模块之后，按照“整体规划、分步实施、持续迭代”的思路，把整体系统的实现分成几个阶段、并排好优先级。

　　这里再分享一个案例，IBM做的ERP咨询项目，也是按照“整体规划、分步实施、持续迭代”的思路。

　　在完成业务流程设计、功能模块设计、角色梳理、竞品分析之后，产品经理就可以开始做界面原型设计。

　　一般来说，产品经理先画低保真原型，跟干系人沟通确认后再画高保真原型。如果团队里有设计师，则可以由设计师来画高保真原型。

　　管理者需要通过报表来实现管理意图，所以做报表设计最重要的事情不是报表要展示哪些数据以及报表的形式外观，而是要明确管理者的管理意图。

　　其实，你真正关心的是今天冷不冷，要不要多穿衣服！这才是你的“管理意图”。

　　所以天气APP除了显示气温，还有“穿衣指数”，就是针对你的“管理意图”——该穿多少衣服。

　　我经常到各地出差，发现广州的8度与哈尔滨的8度是完全不同的感觉，而且从穿衣指数还无法判断出差该带多厚的衣服。我觉得天气APP应该有个“实时街景”功能，我看下当地街上的行人穿什么衣服，基本就可以判断要带什么衣服了。

　　B端产品的用户群是多种多样的，不同岗位、不同级别的用户能操作的功能、能看到的数据可能都有区别，这就需要通过权限管理进行控制。

　　数据权限一般通过组织架构树来控制，功能权限可以通过RBAC（Role-Based Access Control ）模型进行控制。

　　RBAC模型是基于角色的访问控制，将权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。如图所示：

　　RBAC模型是比较成熟的功能权限控制模型，知识管理系统的权限控制就是基于RBAC模型。

　　完成了前面这些工作后，产品方案设计的工作基本完成了，接下来要编写需求分析报告(PRD），把需求传递给开发团队。

　　C端产品的需求分析重点在用户上，先做用户研究、场景分析，找到痛点，给出解决方案。

　　B端产品的需求分析重点在客户上，除了常规的功能需求与非功能需求，还要做“价值需求”分析、从客户的视角阐述B端产品的价值。

　　具体体现在：目标分析（问题与机会描述、影响分析）、干系人分析、管理意图分析等。

　　报告的具体内容：微信公众号：张在旺， 文章：【案例】B端产品的需求分析报告

　　前面的业务调研分析、设计解决方案是为了“做正确的事情”，方案实施是为了“把事情做正确”、把解决方案落地执行。

　　整体规划：知识管理要与公司的业务战略结合，涉及到多个部门，要搭建相应的激励、考核、宣传制度，要建设知识官团队，要建设知识库，是个系统工程，所以要从整体上进行统一的规划。

　　分步实施：知识管理的推进，要由点到面，逐步推进，因为资源有限，贪多求全什么都做不好。

　　重点突破：先从需求最迫切的部门开始、先从公司的战略产品开始，这样容易见到成效，并积累经验，为推广到其他部门与业务打下基础。

　　小步快跑：遵循互联网的产品思维，快速迭代、快速试错，出现问题可以及时调整。

　　企业内部的B端产品运营，与C端产品运营、SaaS产品运营都有区别，具体区别如图所示：

　　新系统上线后，先小范围试运行，在知识库中准备一些优质内容，再逐步扩大宣传范围。

　　充分利用各种宣传渠道：公司大屏、工作群、内网、食堂，甚至公司的厕所门都是“兵家必争”的广告位。

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

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

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

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

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

　　根据搜索词频，推测用户的内容需求：比如，从后台搜索词频分析发现，“iOS开发”的搜索频率很高，说明用户关注这方面的内容，知识库运营团队就开始重点去挖掘、梳理这方面的内容。

　　根据用户的阅读历史、收藏、点赞、评论行为来推荐内容。这个有点像今日头条、抖音的个性化推荐，但在实现过程中并不需要像今日头条、抖音那样用到大数据、AI技术，用简单的标签就可以实现预期的效果。

　　根据收藏数、点赞数来推荐内容，运营团队会定期把收藏数、点赞数多的词条放到精华区、在工作群中推送。

　　根据部门与岗位调整首页。知识库的内容与频道越来越多，根据用户的岗位、所在部门来调整知识库首页内容。

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

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

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

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

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

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

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

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

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

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

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

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

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

　　整体规划：知识管理要与公司的业务战略结合，涉及到多个部门，要搭建相应的激励、考核、宣传制度，要建设知识官团队，要建设知识库，是个系统工程，所以要从整体上进行统一的规划。

　　分步实施：知识管理的推进，要由点到面，逐步推进，因为资源有限，贪多求全什么都做不好。

　　重点突破：先从需求最迫切的部门开始、先从公司的战略产品开始，这样容易见到成效，并积累经验，为推广到其他部门与业务打下基础。

　　小步快跑：遵循互联网的产品思维，快速迭代、快速试错，出现问题可以及时调整。

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

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

作者：admin

抖音运营 站点 QQ交谈