B端产品从业务诊断到形成方案
一、B端产品的市场分析与业务调研
1. 分析市场并细分客户群体
任何商业行为的核心都可以用一句话描述，即：给谁用，提供什么价值，解决什么问题。
商业的起点，首先要分析市场，确定目标客群，从而针对目标客群的痛点设计产品解决方案。
前期的市场分析步骤以及目标分析点如下：
注意：
在现实中，B端产品切入的方式不止这一种，有的企业甚至并没有严格遵循以上步骤做市场分析，而仅仅是在某个行业深耕久了，对行业比较了解或者摸索到了该领域还存在潜力，进而选择了自己熟悉的赛道去做探索；或者机缘巧合工作过程中接到了一个大客户订单，通过和客户的项目制合作，完成了对该业务领域的学习和认知，进而深耕于该领域。
2. 针对选定的目标做市场调研
第一节已经分析完如何选定目标市场或目标客户，接下来我们从客户的内部视角，探讨具体的业务问题调研和分析。
尤其是商业软件产品，在启动设计阶段，不可能凭空基于对业务的假想完成设计，更不可能针对一个有代表性的标杆客户进行充分调研，透彻理解业务，并刻画出MVP版本。
1）业务调研的五个环节
2）业务调研的三个阶段（初期-中期-后期）
3）业务调研的目的
B端产品面向企业用户，产品目标是更好的支持业务运转。所以调研目标是分析业务现状和业务问题，为方案设计提供支撑，最终解决企业的业务问题，提升运转效率。
C端产品直接面向终端用户，而且一般承载着公司的商业目的（可能是变现，也可能是获取更多流量等）。所以调研目标是获取真实有效的用户体验的用户需求和体验感受，以便后面结合用户的需求，痛点设计解决方案最终实现商业诉求。
3. 业务分析的三层架构
在企业开展新业务时，首先要结合自身的战略地位、组织发展阶段，思考业务目标和当前情况，从而推导出基本的管控模式，再进一步设计组织结构与绩效激励体系，基于这些顶层设计，最后才是业务开展的具体流程体系。
B端业务分析框架：
二、B端产品的整体方案设计
1. 通过精益画布构建商业模式
产品不是凭空想出来的，尤其是业务型B端产品，设计这类产品最怕拿个榔头（产品）找钉子（客户），这样多半会失败，而应该是先找到钉子，然后去拿榔头钉钉子。
精益画布中给出了商业模式构建的九个关键要素，这九个关键要素可以帮助我们把商业运作的关键问题都想清楚，如图示：
2. 使用PMF（product/Market Fit）进一步对初期市场进行验证
PMF将新产品市场评估为四个阶段：
- 概念阶段：提出了早期的产品创意想法和产品概念。
- 原型阶段：将产品的外观实现出来，可以让潜在客户试用并提出感受。
- MVP阶段：定义产品的最小可行性版本并实现。
- PMF阶段：将MVP版本投入市场，检验市场接受度（需要从留存率，页面访问深度，跳出率等多个指标判断产品是否契合了市场达成PMF）
尽管业务型B端软件比较厚重，但在商业层面的运作上，一定要始终秉承“尊重市场，尊重客户，找准定位，快速迭代”的理念。
3. 确定核心业务流程
现在让我们回到产品设计本身，我们要梳理核心业务流程，定义问题边界，并确定产品定位。
从核心业务流程切入产品设计，是开展整个设计工作非常好的起点。核心业务流程代表业务的主干脉络，需要思考业务的各个参与方和涉及的系统。
只有定义清楚业务边界，才能定义产品边界。很多时候我们发现产品的定位模糊混乱，这是因为设计时对产品要解决的业务问题的边界和场景定义得就不清晰。
在核心业务流程绘制过程中，只需要绘制关键场景和节点，不用陷入细节流程。
4. 明确产品定位
产品定位是产品设计的指导思想和灵魂，梳理了核心业务流程和业务场景后，我们对客户的问题、痛点有了明确的范围界定，接下来我们从宏观和执行两个层面来探讨产品定位。
1）宏观层面的产品定位
宏观层面来讲，产品定位是指对于一个选定的目标市场，企业如何设计产品来承载价值主张来解决目标客户的痛点和诉求。用一句话来概括就是：产品的目标客户是谁？解决了他的什么问题？为他提供了什么价值？这也是精益画布中1、2、3点描述的要素。
针对企业自研自用系统，也需要明确宏观层面的产品定位，但自研系统不存在目标客户群体的概念，因为服务的目标客户就是自己公司的业务方。
2）执行层面的产品定位
任何一套复杂的软件产品，都不太可能只靠一套独立系统来运作， 而会由若干子系统来协同运作，支撑业务。
在B端产品设计中，我们要逐步分解、细化产品设计，在确定了产品整体定位后，下一步我们要思考应该设计几套子系统来匹配不同的业务场景，支撑业务运作，这也是执行层面的产品定位问题，我们要说清楚，产品由几套子系统组成，每套子系统的目标用户是谁，解决他们的什么问题。
划分子系统时，可以通过目标用户与场景进行子系统的定义和拆分。拆分的目的是让系统从业务层面上边界更加清晰，易于理解和使用，这也会传导到技术实现上，让系统底层的设计逻辑更加严谨、完备，在高粒度层面做到松耦合、高内聚。
另外，产品经理也要认识到，多套子系统的定义只是在应用层面上的划分，在技术实现上很可能是一套统一的底层加多套前端的表皮而已。
5. 梳理应用架构
所谓应用架构，是公司所有软件系统的整体结构和布局，任何公司的应用架构都不是随意设计的，都有复杂的设计思想蕴含在其中。
1）自研软件系统的应用架构
在设计一套新的系统时，要考虑如何和公司现有的系统架构融合，不同系统的模块之间如何衔接。这项工作复杂度较高，不仅需要有丰富的架构经验，而且需要深刻理解业务特点和可能的演进方向，还要熟悉本公司的系统架构，这样才能快速的提炼出相关问题。
如果公司已经发展了多年，软件体系结构已经相对成熟，这就意味着在设计一套新的系统或产品时，完全可以复用现有的部分系统或模块，从而快速实现，提高系统建设效率，减少重复开发，更重要的是可以保证整体系统架构合理。
举例，支持分销系统的公司整体应用架构图如下：
2）商业化软件平台的应用架构
首先，任何一个商业化软件产品，在实施过程中都要考虑和甲方已有架构的融合问题，如果产品经理不懂应用架构的常识，在软件的集成能力设计，模块的通信设计上就会出问题。这不单纯是技术问题，还是一个业务问题，甚至是商业问题。
其次，乙方厂商如果有多产品线协同，同样需要考虑应用架构的体系设计问题。一方面，产品矩阵背后需要有一体化的架构设计思考，另一方面，为提升公司研发效率需要避免重复造轮子等问题。
所以不论是甲方企业背后的应用架构，还是乙方产品体系的应用架构，没有本质的区别，因为软件工程和管理应用系统从底层到上层的设计思路都是相通的。
6. 定义场景与功能模块
从场景到功能模块，有三种经典的模块抽象思路，分别是基于业务领域抽象模块，基于业务场景抽象模块，基于业务对象抽象模块。
1）基于业务领域抽象模块
最常见的模块划分方式是基于业务领域的，业务领域是一个很宽泛的概念，可能包括业务部门、业务单元、业务主体等。业务领域作为模块划分依据，让模块之间体现了更强的内部聚合性及松耦合性。
如下图所示展示了典型的系统功能模块设计，体现了基于业务领域划分模块的特点：
基于业务场景抽象模块和基于业务领域抽象模块的区别之处是后者的内聚属性更强，和技术架构的模块设计比较贴合；而前者更多从用户体验和业务逻辑出发来做模块划分，在场景菜单下可能会融合多个模块的功能。
2）基于业务场景抽象模块
有时候通过业务场景来定义菜单反而逻辑更清晰，更容易理解。例如，在某些流程属性比较重的业务系统中，通过业务场景划分模块也能较好的做到功能模块解耦合的抽象归类。如下图的菜单设计，一级菜单学员管理，课程管理，直播管理，助学管理等模块，都是典型的教学场景。
3）基于业务对象抽象模块
还有一种比较少见的模块抽象思路，即基于业务对象抽象模块，也就是将业务开展中的对象（人、事、物都有可能）定义成模块。
如图所示，在该人员管理系统中，用户，角色，部门，岗位都是关键业务对象，在关键业务对象背后其实也影射了场景。
以上分享了三种划分模块的思路，在实践中，往往会将几种思路融合在一起，没有绝对的原则和方法论。企业的运作管理体系已经发展多年并非常成熟，对应的管理软件建设也十分成熟；任何形态的管理软件系统，B端产品，在模块划分和抽象设计中都要尽量参考同类业务软件系统的设计思路，这是前人重要的总结沉淀，蕴含着对业务的深刻理解和洞察，切勿自己发明创造，浪费时间。
7. 规划演进蓝图
通过绘制系统的功能模块图，我们可以明确业务和系统的规划脉络。将能想到的功能集合都列出来，这是一个做加法的过程。但是我们不可能一次实现全部功能，而要根据业务优先级，拆分成几期来完成，所以接下来需要做减法：确认产品的功能规划与实现节奏，就是常说的演进蓝图（roadmap）。
对于一个新系统，我们一般分几期来实现：
- 一期项目聚焦解决最基本的业务流程线上化问题及核心痛点，也就是支撑业务能闭环运行的最小功能集合，其中有一个原则可以参考：凡是可以手动处理和解决的问题，暂时都不做系统支撑。
- 二期项目聚焦于解决部分特殊业务刚需的诉求。
- 三期项目聚焦风险控制，并强化运营功能。
随着设计的深入，以及业务的开展、变化、功能模块可能需要修正和调整，但只要业务的本质模式没有变化，功能模块就不应该出现结构性的改动。功能模块图和演进蓝图代表的是概要性方案，指明了整体的产品方向，是后续细化设计的指引和准则。
8. 数字技术赋能业务
单独从业务效能优化的角度来讲，数字技术赋能业务可以总结为五个阶段，这五个阶段循序渐进，逐步推演，对业务进行全面优化和赋能。
这五个阶段分别是流程化，线上化，自动化，数据化，智能化，如下图：
三、B端产品的细节方案设计
B端产品的细节方案设计，通过对整体方案中总结出的业务场景，逐个进行深入分析，包括业务数据建模、页面流转设计、界面设计、权限设计等，再对关键场景的各个击破中梳理出系统全貌的细节。这些工作流程和任务都是产品经理的必修课，即便没有经历从0到1的设计过程，也会在日常的迭代过程中经常接触。
1. 业务数据建模
业务数据建模也叫实体关系，指将业务的核心数据对象特征进行提炼，归纳并设计对应的底层数据模型的过程。
B端产品进行细节设计的常见流程是，首先梳理业务流程，接下来提炼背后的数据模型，然后基于流程和数据模型确定页面流转图，再着手进行每个页面的具体设计同时提前规划好系统用户角色，最后完成权限设计。
为什么数据建模这么重要呢?这是因为软件系统的核心本质上是对现实世界的对象和规则的抽象与管理。软件系统设计的难点恰恰在于合理地总结客观世界的对象和关系，并实现最基本的数据模型设计。只有总结并设计出正确的数据模型之后，才能思路清晰地完成功能模块和交互操作的设计
实际上，业务数据建模是数据库设计中最重要的部分，会影响数据库表结构的设计，体现了设计者对业务本质的理解和认知。很多产品经理常常忽略业务数据建模只关注功能界面设计，最终陷人混乱的逻辑中。一定要在设计细节方案初期就进行业务数据建模。
针对数据建模可总结为三个步骤：找到实体、梳理关系、确定关键属性，如下图所示：
参考：不同实体关系实例图
2. 流程和角色
接下来，我们开始设计分销客户管理场景下业务的流程和角色。流程合理、角色清晰是系统正确设计的前提和保障，流程确定后，再绘制页面流转图，最终完成页面细节设计。
通过跨职能分系统流程图，可以清晰的看出谁（操作角色）在哪儿（哪个系统）做什么（完成什么工作）。
角色在业务开展初期已经存在，但是在系统设计过程中，需要结合业务流程进一步梳理，并修正完善，以保证各角色的工作内容是明确并固定的，各角色之间尽量避免职责交叉，这样才能保证团队成员分工明确，共同协作，达成业务目标。
主业务流程图示例图如下：
3. 绘制页面流转图
对于系统设计来讲，业务流程图依然属于比较粗粒度的概要性设计，如何将它与软件产品的页面设计对应起来，绘制页面流转图是一个很好的衔接方式。
页面流转图描述的是，用户完成某项工作需要访问的页面及页面跳转顺序。绘制页面流转围可以帮助设计人员审视、思考系统中的页面设计方案，包括系统中总共需要哪些页面，哪些页面可以重复使用，哪些页面需要定制化开发。
一般来讲、我们绘制页面流转图时，都是针对某个单一角色绘制某个特定场景下的页面访问和跳转逻辑，从用户的视角来梳理一遍所有相关页面，每到一个新页面时都要思考:需要新做一个页面，还是可以复用原有页面? 最终整理出系统涉及的所有页面的初稿。
页面流转实例图如下：
4. 提炼汇总页面功能清单
不同的场景有可能会涉及相同的页面，因此非常有必要统一整理不同场景涉及的所有页面。有时，在页面清单的梳理中就可以将关键功能点也整理出来。
页面功能清单示例图：
5. 界面设计
我们已经完成了功能模块设计、演进蓝图设计、业务数据建模、业务流程梳理、页面流转梳理，功能清单等一系列环节，已经细化到每个操作需要访问哪个页面、总共有哪些页面、现在需要为每个页面设计具体的交互功能以及具体呈现，即进行界面设计。
虽然在整个界面设计之前的流程很长，但在此梳理期间，我们对整个业务形态已经了然于心，对整个项目和产品的掌控力越来越强。此时再去做界面设计，已经是水到渠成之事。
界面设计流程：
注：
本篇文章只挑选了部分业务场景作为例子进行讲解，并没有覆盖整个系统所有的细节功能设计。在实践中，我们在细节方案设计阶段，要挑选优先级和重要程度比较高的业务场景，进行进一步的业务调研，梳理每个场景背后的业务流程，完成功能设计，最终汇集得到完整的产品方案。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！