B端产品设计指南
2.业务需求梳理与需求分析
在做C端产品时，最重要的步骤是需求分析，也就是思考什么类型的用户在什么场景下遇到了什么问题。那么在做B端产品时，什么是B端产品的需求分析呢？
这个看似简单的问题并不那么好回答，很多人认为的B端需求就是帮助用户完成业务流程所需要做的事情。但这样的理解并不完整，笔者认为B端的需求包含三种：
业务需求：即解决企业运作过程中遇到的问题，业务需求同样是产品建设的目标；
用户需求：描述的是使用者需要完成什么任务，完成这个任务的过程中遇到的问题；值得注意的是，用户需求通常是零散且存在矛盾的，用户会从不同角度、不同层面提出需求，通常都是一句话需求，而且由于用户处于企业的不同层级，不同部门，难免会出现“盲人摸象”的现象，从而导致需求的片面性；
软件需求：是产品经理对业务需求、用户需求经过分析、提炼与整理后生成指导开发的需求，是需求分析最终的产物；
需求分析的主要目的是获得为系统开发提供指导的软件需求。在此之前，首先我们要做的事情是挖掘业
务需求与用户需求。主要任务是梳理清楚目标客户群体所有的业务类型，为不同的业务类型划分清晰的界限，并且梳理出每个业务类型中所有的业务需求与用户需求。这个过程同时也就是需求澄清的过程。
业务流程分析
业务流程分析就是针对每一项业务事件，分析业务活动的特点，并确定业务活动之间的关系。具体要做的事情是：
（1）记录这些业务活动需要接收哪些信息；
（2）记录这些业务活动将产生哪些数据（报表），并确定数据传输的路线；
（3）标识出这些业务活动是由哪些部门、岗位在负责；
一个企业的核心价值就是对外部客户的诉求进行处理，在为客户创造价值的同时，为企业创造价值。因此由业务事件触发的流程是分析需求时的核心线索。
在进行流程分析的时候有几个关键要点，一是理解流程的层次性，二是了解流程的类型，三是掌握以业务事件寻找流程的技巧。
一个企业的核心价值是对外部客户的诉求进行处理，在为客户创造价值的同时，为企业创造价值。因此由业务事件触发的流程是分析需求时的核心线索。
流程的层次性
流程有组织级、部门级与岗位级三个层次关系。
组织级：是指经过抽象、提炼后的业务事件，是指大方向的业务流向，例如一个产品可能包含生产、销售、售后服务等组织级的流程；
部门级：是指具体每个岗位负责什么活动，以及这些活动之间的关系。例如一个产品在生产阶段可能需要原材料部门和加工部门的配合。它是需求分析的主线索，也是流程分析的主要输出；
岗位级：是指每个业务活动具体的操作步骤，可能由某个岗位的一个人或多个人操作，属于需求细节。
如果我们现在设计一款专门给房产中介的CRM产品，那么在调研业务流程的时候，买卖二手房就是两个不同的组织级流程，买二手房房会涉及到看房、查档、签合同、公证、赎楼过户等等一系列的流程属于部门级流程，而在看房时，又涉及到买卖双方初步洽谈价格、付款方式、交房日期等事项确认等步骤，这种属于岗位级流程。
流程的类型
在一个企业中，根据业务流程的目标可以将其分成不同的类型，一般我们可以分为生产流程、管理流程以及支撑流程三类。生产流程是流程中最重要的部分，也是体现企业价值的业务环节，通常最容易识别；管理流程是对生产流程的管控，
通常是对流程效率与质量的监督控制；支持流程是对生产流程的补充，通常是对主流程起支撑作用的环节，非必须但容易忽略。
在这款房产中介的CRM产品中，看房、查档、签合同、赎楼过户这类环节都属于生产流程。在这个主流程以外，每一个环节都有相应的审核操作，这种流程属于管理流程。
流程分析的输出：跨职责流程图
其实从不同角度来看一个业务流的时候，可能会有很多不同的流程。流程会有大小之分，主流程中可能会有子流程等，因此流程分析是一项庞大的工程，仅仅通过文字讲流程描述清楚是很困难的，我们需要系统化地分析，因此可以借助“跨职责流程图”帮助我们梳理脉络。
跨职责流程图是商业分析的标准工具，它定义了一套标准的建模元素与分析方法，下图展示了房产中介卖房时的流程。
看到这张图，也许很多读者会很疑惑：这张图也太简单了吧。谈判议价以及办理过户手续都涉及许多业务性的判断，为什么在图中都不体现呢？
这是因为它们属于细节层次，在本阶段判断的原则是：不会影响其他泳道的流程，在这个阶段都不需要表现出来。在这个场景中，谈判议价虽然复杂，但是它的判断流程并不会对其他泳道产生影响，因此我们可以暂时不看。
角色与使用场景分析
不少读者会有这样的疑惑，我做B端的产品，把流程梳理完了就能知道需要设计什么功能点来描述需求了，为什么还要去分析角色与使用场景呢？对于一个B端产品来说，用户在使用的过程中应该是无差别的，我们硬是把这些用户分成不同的角色那不是多此一举吗？
确实，刚开始接触B端产品都会有相同的想法。
直到有一次，一位朋友给我描述他们的产品。
“我们这款产品是一个征收系统，给政府人员管理征收流程用的。这个产品包含填写测算表、选择安置房、选择赔偿标准、查看签订合约人数等等功能，填写测算表里又分为了...模块...”
当时确实是把我听懵逼了。随后我问了他两个问题。
（1）这个系统到底有谁在用？
（2）这个系统帮助这些人解决什么问题，怎么解决？
问完之后我马上意识到，这两个问题不就是典型的用例分析方法吗？

更多推荐

需求,流程,业务,分析,产品