这篇文章想和大家探讨 B 端产品应该如何规划。
很多人都说，做 B 端产品最重要的是搞清楚业务逻辑。只要搞清楚业务是怎么运作的，就能做出满足业务需求的产品。
但是 B 端产品所处复杂的业务需求环境，如同茂密的森林一样，产品经理一不小心就会迷失在业务细节中，做出一款停留在业务表面的产品。导致这种情况的根本原因在于：一个行业花费了几年甚至几十年时间建立起来的业务流程与规范，我们很难用一两个星期完全消化。
面对这样一个错综复杂的场景，产品经理最好的做法是循序渐进，从最粗略的业务目标开始，然后分析业务流程，到各职位的工作内容，最后才是数据、报表的细节。
正如盖尔定律所言，一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行，无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。
这个由粗到细的过程，就像我们在考察一座古遗址时，首先在外围绕一圈，通过无人机鸟瞰整个建筑的全貌，对整体轮廓有一个大致的了解。再进入到建筑物内部，将主通道走一遍，将内部结构搞清楚，最后再细致研究每一个区域。
产品背景分析
知己知彼，方能百战不殆。
无论是设计 C 端产品还是 B 端产品，首先我们都要对「使用者」进行深入的分析。C 端产品直接看用户特征，为用户做画像做分群。B 端产品则需要剖析企业的经营过程，再去看不同使用者的需要。
第一阶段的任务是对产品所服务的业务领域有一个概括性的了解。我们可以从行业背景、业务目标与诉求、组织架构、岗位划分等方面开展研究。虽然第一层次并不足以让人了解业务具体运转的逻辑，但是通过业务架构描绘出的一幅业务全景，对于进一步了解需求帮助巨大，这样就不会迷失在茂密的需求森林中。
1. 目标客群分析
每个产品都有特定的用户群体，B 端产品也不例外。背景分析的第一步，首先我们要搞清楚，产品到底是卖给谁?
做C端产品时，我们习惯用「用户故事」帮助我们定义用户类型。做 B 端产品，同样可以用一个「企业故事」帮助我们理清目标群体的需要。
「目标客群是一家____公司，没有我们产品之前，他们是这样工作的：____，当前的工作方式出现了____的问题，因此想要借助我们的产品解决____需要，期望达到____的效果。」
假设我们现在要做一款针对二三线城市房产中介的 CRM 产品，企业故事可以这样写：
- 产品的目标客户是二三线城市、中小型的房产中介公司，没有我们的产品之前，他们主要是采用市面上常见的 CRM 工具实现客户管理。但是目前使用的工具没有针对房产中介的流程做适应，导致流程不规范，有些环节在线上、有些环节在线下进行，数据监管不到位，业务员管理混乱等问题，因此想要借助我们的产品规范流程，以达到提升业务质量、提高标准化效率的目的。
通过这个企业故事，我们可以定位到产品针对什么行业、什么规模的企业，然后明确这类公司的核心诉求，将来在做功能与设计的时候可以围绕着这个核心诉求展开，也是产品不断更新迭代的方向。
2. 业务目标分析
短短一个企业故事，对我们后续的需求分析有很大的帮助。接下来我们还要做一道选择题帮助我们理解产品的定位。
我们的产品对企业的重要性如何?
- 生存需要：这个产品关系到公司的生存问题;
- 核心发展需要：这个产品有利于公司提高核心生产力与竞争力;
- 次要发展需要：这个产品对公司的生产或发展不产生重大影响，但有利于公司解决一些具体的问题，帮助公司改善非核心领域的工作，或改善核心领域的工作;
- 锦上添花需要：有这个产品更好，没有也没太大关系，可以有其他替代解决方案。
任何一个 B 端产品，一定是在某个特定的阶段满足企业的某种价值。如果我们的产品直接影响企业的核心业务流程，对企业的生产与销售有很大的帮助，那么这类产品比较受企业的欢迎，在企业经营的全阶段都比较受欢迎，例如各类业务流程系统、部分垂直行业的 ERP、CRM 等。如果我们的产品是改善企业经营管理类型的，只有当企业成长到一定规模，出现管理需求时才比较受欢迎，例如常见的 CMS、OA、HRM 等。
这个问题相信不难回答，但是能够帮助我们准确理解产品自身的定位，很多时候对产品的定位越清晰，越容易站在客户的角度考虑，理解客户的想法。
战略分析让我们对产品做到「心中有数」，接下来的需求分析是我们产品设计的重点。
业务分类，需求梳理
在做 C 端产品时，最重要的步骤是需求分析，也就是思考什么类型的用户在什么场景下遇到了什么问题。那么在做 B 端产品时，什么是 B 端产品的需求分析呢?
这个看似简单的问题并不那么好回答，很多人认为的 B 端需求就是帮助用户完成业务流程所需要做的事情。但这样的理解并不完整，笔者认为 B 端的需求包含三种：
- 业务需求：即解决企业运作过程中遇到的问题，业务需求同样是产品建设的目标。
- 用户需求：描述的是使用者需要完成什么任务，完成这个任务的过程中遇到的问题;值得注意的是，用户需求通常是零散且存在矛盾的，用户会从不同角度、不同层面提出需求，通常都是一句话需求，而且由于用户处于企业的不同层级，不同部门，难免会出现「盲人摸象」的现象，从而导致需求的片面性。
- 软件需求：是产品经理对业务需求、用户需求，经过分析、提炼与整理后生成指导开发的需求，是需求分析最终的产物。
需求分析的主要目的是获得为系统开发提供指导的软件需求。在此之前，首先我们要做的事情是挖掘业务需求与用户需求。主要任务是梳理清楚目标客户群体所有的业务类型，为不同的业务类型划分清晰的界限，并且梳理出每个业务类型中所有的业务需求与用户需求。这个过程同时也是需求澄清的过程。
1. 业务流程分析
业务流程分析就是针对每一项业务事件，分析业务活动的特点，并确定业务活动之间的关系。具体要做的事情是：
- 记录这些业务活动需要接收哪些信息;
- 记录这些业务活动将产生哪些数据(报表)，并确定数据传输的路线;
- 标识出这些业务活动是由哪些部门、岗位在负责。
一个企业的核心价值就是对外部客户的诉求进行处理，在为客户创造价值的同时，为企业创造价值。因此由业务事件触发的流程是分析需求时的核心线索。
在进行流程分析的时候有几个关键要点，一是理解流程的层次性，二是了解流程的类型，三是掌握以业务事件寻找流程的技巧。
流程的层次性
流程有组织级、部门级与岗位级三个层次关系。
- 组织级：是指经过抽象、提炼后的业务事件，是指大方向的业务流向，例如一个产品可能包含生产、销售、售后服务等组织级的流程;
- 部门级：是指具体每个岗位负责什么活动，以及这些活动之间的关系。例如一个产品在生产阶段可能需要原材料部门和加工部门的配合。它是需求分析的主线索，也是流程分析的主要输出;
- 岗位级：是指每个业务活动具体的操作步骤，可能由某个岗位的一个人或多个人操作，属于需求细节。
如果我们现在设计一款专门给房产中介的 CRM 产品，那么在调研业务流程的时候，买卖二手房就是两个不同的组织级流程。买二手房会涉及到看房、查档、签合同、公证、赎楼过户等等一系列的流程，属于部门级流程。而在看房时，又涉及到买卖双方初步洽谈价格、付款方式、交房日期等事项确认等步骤，这种属于岗位级流程。
流程的类型
在一个企业中，根据业务流程的目标可以将其分成不同的类型，一般我们可以分为生产流程、管理流程以及支撑流程三类。
- 生产流程是流程中最重要的部分，也是体现企业价值的业务环节，通常最容易识别;
- 管理流程是对生产流程的管控，通常是对流程效率与质量的监督控制;
- 支持流程是对生产流程的补充，通常是对主流程起支撑作用的环节，非必须但容易忽略。
在这款房产中介的 CRM 产品中，看房、查档、签合同、赎楼过户这类环节都属于生产流程。在这个主流程以外，每一个环节都有相应的审核操作，这种流程属于管理流程。
流程分析的输出：跨职责流程图
其实从不同角度来看一个业务流的时候，可能会有很多不同的流程。流程会有大小之分，主流程中可能会有子流程等，因此流程分析是一项庞大的工程，仅仅通过文字将流程描述清楚是很困难的，我们需要系统化地分析，因此可以借助「跨职责流程图」帮助我们梳理脉络。
跨职责流程图是商业分析的标准工具，它定义了一套标准的建模元素与分析方法，下图展示了房产中介卖房时的流程。
看到这张图，也许很多读者会很疑惑：这张图也太简单了吧。谈判议价以及办理过户手续都涉及许多业务性的判断，为什么在图中都不体现呢?
这是因为它们属于细节层次，在本阶段判断的原则是：不会影响其他泳道的流程，在这个阶段都不需要表现出来。在这个场景中，谈判议价虽然复杂，但是它的判断流程并不会对其他泳道产生影响，因此我们可以暂时不看。
2. 角色与使用场景分析
不少读者会有这样的疑惑，我做 B 端的产品，把流程梳理完了就能知道需要设计什么功能点来描述需求了，为什么还要去分析角色与使用场景呢?对于一个 B 端产品来说，用户在使用的过程中应该是无差别的，我们硬是把这些用户分成不同的角色那不是多此一举吗?
确实，我刚开始接触 B 端产品时也是相同的想法。直到有一次，一位朋友给我描述他们的产品。
「我们这款产品是一个征收系统，给政府人员管理征收流程用的。这个产品包含填写测算表、选择安置房、选择赔偿标准、查看签订合约人数等等功能，填写测算表里又分为了某某模块……」
当时确实是把我听懵了。随后我问了他两个问题：
- 这个系统到底有谁在用?
- 这个系统帮助这些人解决什么问题，怎么解决?
问完之后我马上意识到，这两个问题不就是典型的用例分析方法吗?
用户故事是指某种类型的用户为了完成某特定目标所执行的一系列操作。在描述层面我们可以暂时忽略业务目标，因此一条用户故事包含两个元素。
参与者
参与者是指在系统之外，这个流程中与系统进行有意义交互的任何事物。参与者不仅可以由人来承担，也可以是其他系统或者是硬件设备。
例如在看房的过程中，业务员从后台系统调取房屋的平面图以及详细信息，这时候后台系统就是其中一个参与者。如果我们的新房还没有装修好，用 VR 眼镜让客户看到装修后的效果时，VR 眼镜也是流程中的参与者。参与者是一种角色，而不是一个特定的人，在某些场景中甚至一个人能够充当多个角色。
做什么事情(用例)
用例是指用户在系统中执行的一系列动作，通常用「动词+名词」的方式表达。值得注意的是，用例是有目标的，它能够为参与者带来有意义的结果，例如「填写搜索房屋条件」显然对于参与者来说没有任何意义，就不是一个合适的用例。
另外用例是对一组使用场景的抽象。用例与场景之间的关系像是计算机概念中，类与对象之间的关系。一个场景是一个具体的行为，一个用例是对一类相关行为的抽象。
例如我们在系统上找房源的时候，可能会遇到很多场景：使用搜索框直接搜索心仪房源、根据筛选条件挑选房源、根据推荐的新盘挑选房源、拉取两三个房源对比后挑选等等，不管有多少种情况，只要是在做挑选房源这件事，那么这些场景在系统中，都可以概括为一个「挑选房源」的用例。
在传统的结构化分析与设计方法中，对事物的分析视角都是站在解决方案层面思考的，即这个系统需要有什么，从系统的角度出发做功能规划。这样做出来的产品，常常有用户抱怨太难用，很难理解系统的意思，也不知道从哪里去找需要的功能。
而以「用户故事」驱动的需求分析方法，是一种更侧重于「从用户的角度出发，将系统当做一个黑盒子」的视角，这种方法能够有效解决上述问题。
从另外一个角度来说，用户故事的关键点在于发现使用系统的用户，了解并梳理这些用户如何使用系统，从而达到「以人为本」的需求分析。
B 端产品怎么找用例?又如何把用例找「全」呢?这是一个经常困扰产品经理的问题。
实际上，我们可以从针对各个业务事件处理过程的流程图中得到用例。正如前文所述，流程图是我们与企业中层管理人员沟通后得到的产物。只要有针对各个业务事件处理过程的流程图，我们就可以从中导出相应的用例。
跨职能流程图对应的不同岗位是可能产生用例的参与者，再加上他们所负责的事情，就是完整的业务用例。也就是我们的客户完成一项业务需要做的所有事情。但是我们做一款产品，很多时候不能满足客户的所有业务环节，只能挑选与我们产品相匹配的核心场景的业务链条深入分析。
因此，对于我们来说，本阶段挑选的业务用例实际上就是系统用例。而系统用例的判断要点在于该用例「是否属于系统范围」，以及他们所做的这个事情能否产生业务价值，只要满足这两个条件的所有用例都必须记录下来。这样一来，我们就能够得到完整的系统用例。
有的读者可能会问：用例分析要分析到什么地步才能结束?
笔者的建议是不要追求完美，只要感觉已经把客户的业务都弄清楚就可以考虑结束，而不必等到事无巨细的每件事都梳理完整。
面对一个陌生的领域，一个经历了多年发展变化的业务流程，要在短时间内弄清楚的确是一个不小的挑战。用例分析的意义在于帮助产品经理在短时间内从结构、整体上了解业务构成。用例是比较高层次的业务抽象，更容易被人们理解和接受。所以进行这一项工作，只需要感觉到业务的整体信息已经可以掌握，就可以考虑停止更广泛的用例获取。以现有的用例作为基线，进行接下来的工作。产品不断迭代的前提就是建立在用例不断优化、不断调整的过程中。
获取用户需求
在客户调研的时候，经常看到产品经理傻里傻气地问客户：你对这个产品有什么需求或者有想法吗?但不管用户怎么回答，似乎都很难让我们满意。客户提不出需求，你会觉得我们的客户对这事好像也没那么上心。更多的时候是客户提的需求都是不痛不痒，或者你感觉极具个性化，让你感觉做也不是，不做也不是。
和 C 端场景一样，B 端场景中的用户需求也像是一个冰山，有很大一部分信息是埋藏在海平面之下，这就对需求调研工作带来很大的困扰。主要的需求分为三种：
- 意识到的需求：这是在海平面以上的需求，通常是一些困扰用户的问题，或者是用户自己能想到的功能。大部分产品经理在调研过程中获取到的都是这一类需求;
- 无意识的需求：它是用户在实际工作场景中「没有意识到是问题」的问题，这种问题需要产品经理对业务有一定的理解才能够发现。如果对这些场景能做到「感同身受」的话，相信在产品规划的过程中能够设计出更合理、高效的方案;
- 进一步的需求：调研的用户毕竟不是技术专家，只是普通的业务人员，因此他们没有办法对其工作提出产生变革的解决方案。因此需要产品经理对问题充分理解的前提下，选择合适的实现方式以创造出用户未想到的功能。
在设计这款针对房产中介的 CRM 产品时，业务员反馈他们在客户选房的时候，需要将不同房源的信息发送给客户。于是产品经理听完后，在房源列表中，每一条房源的操作按钮区域增加了一个分享按钮。
满心欢喜地给到业务员时，业务员说这功能不实用，因为没办法把多个房源的信息合并在一起发给客户。但是产品经理认为，你可以一条一条发给客户呀，所以产品的设计还是能满足业务需要的，但业务员希望得到的是多个房源信息合并后，摘出关键信息发给客户比对，而不仅仅是展示每个房源的信息。
这个场景就是只发现意识到的需求，而没有深究以及进一步分析的结果。
实际上 B 端产品的需求获取并不难，难的是与用户交流沟通的过程。因为我们的用户仅仅作为一个使用者，他只是站在自身使用的视角，想让自己的工作方便一些或是在利益分配上对自己更有利，很难站在系统规划的角度考虑全面整体的东西。
遇到这种情况，最有效的应对策略是需求分析从流程入手，搞清楚业务活动在平时是如何开展的，再逐步过渡到存在什么样的障碍，有什么困难等等。在这个过程中，多问几个为什么，多思考客户诉求背后代表的心理状态与利益冲突。
所以这一阶段，我们主要做的工作是收集针对业务活动的问题点、需求点。这时候我们获取到的是原始的用户需求。
实际上，在整个业务分类、需求梳理的大环节中，业务流程分析、角色与使用场景分析，以及获取用户需求都是伴随着用户调研进行的。用户调研是一个有计划、循序渐进的过程。具体来说，在针对不同的访谈对象时，访谈的要点也不尽相同，具体的要点参考以下表格：
除了用户访谈和问卷调查以外，有机会到业务工作中实际现场观摩也是一种很好的需求获取手段，有助于产品经理对业务场景建立更加感性的认识。在对关键任务理解不清晰、很多东西用文字没办法表述时，现场观摩都是一种很好的方式。
到了这一步，我们已经收集到足够多的业务信息，供我们进行后续的需求分析工作了。
1. 确定需求细节
完善用例
本阶段的任务是对用例的细节进行填充。上一阶段的用户故事已经说明业务怎么执行，但缺少表达如何「实现」的机制。例如房产交易后对合同归档，有一部分合同可以由业务员直接归档，有一部分则需要经过部门经理审核后才能归档。另外归档需要什么前置条件，归档后会引发这项业务发生什么样的变化，这些都是本阶段需要考虑的问题。
因此在完善用例阶段，我们需要做的事情主要有：
- 将用例与需求相对应;
- 表述用例的事件流;
- 补充用例的前置条件与后置条件;
- 确定用例的规则与约束条件。
- 用例与需求相对应
以用例作为需求的最小单位，是按照业务流的角度将需求分类管理的方法。在这个阶段，首先我们要做的事情是将用户调研阶段获取到的用户原始需求，整理到相应的用例中，以此建立用户原始需求与软件需求(用例)之间的映射。
在具体操作时，我们可以用以下表格管理需求追踪。前三列描述了用户原始需求的编号、描述与提出者，接下来两列则是相应的用例编号及用例名称。这些用户的原始需求来源于用户调研、用户提供的需求说明以及在使用系统过程中获得的反馈。
有这样一张表，我们对用户的需求管理更显得张弛有度，同时也更容易发现需求冲突的地方。
表述事件流
对于用例而言，最常见的事件流包括 3 种：
- 基本事件流：是对用例的预期路径的描述。是大部分时间遇到的场景，也是符合用户预期与业务初衷的核心路径;
- 拓展事件流：也称为分支事件流，主要用来描述用户的不同选择以及对异常情况的表示;
- 子事件流：用于对事件流中多次重复的部分进行概括，类似代码中的「循环结构」。
在买房这个例子中，按预定路线双方完成交易就是基本事件流，双方对价钱的商议过程就是子事件流，而买卖双方的交易过程穿插着比较多的交易情况，属于拓展事件流。
补充前置条件与后置条件
所谓前置条件是指在用例启动时，参与者与系统应处于什么状态。这个状态是系统能够检测并且是有意义的。而后置条件是指在用例结束时，系统应处于什么状态。同样这个状态也是系统能检测到并且有意义的。通过以下例子加深理解：
- 客户有购房意向：这不是一个前置条件，因为这是系统无法检测的;
- 客户登录系统查看房源图片：这也不是一个好的前置条件，虽然系统可以检测，但是这个事情所表现出来的意义不大，对我们来说没有帮助;
- 审核通过，完成合同：这是一个好的后置条件，系统可以检测并且事件对流程有影响。
一般来说，前置条件通常是一种状态，后置条件可能是一种状态，也可能是一种后续行为。并非所有的用例都存在前置条件与后置条件。
规则与设计约束
规则是在实现阶段应该考虑的东西，而约束是对技术手段起限制作用的各种条件。在这个阶段补充规则与设计约束是我们对用例整理的最后一件事情。
从需求的角度来看，用例涉及的规则大致可以分为：业务规则与数据规则两类。
- 业务规则：它是指和业务逻辑、业务流程相关的规则。例如业务系统中，一个业务员接触了买方之后，系统不会把这个客户再分给别的业务员;业务员释放了某个客户之后，其他业务员可以联系这个客户等等;
- 数据规则：它是和业务属性相关的规则。例如业务员给客户发送的营销短信最大长度是 200 个汉字;业务员的当月有效业绩是当月已付款的所有订单的总金额合计等等。
而用例的约束则比较简单，通常指的是性能指标等非功能要求，或是软硬件、用户使用环境以及技术选择的限制。这些限制也并非每个用例都会有，但关键业务活动的设计约束要充分考虑，才不会发生因规划产生的设计缺陷。
2. 需求整理与分析
需求分析是需求工程中最重要的活动之一。需求分析并不是在分析系统如何实现用户的需求，而是选择一种业务导向的指引将零散的需求串联起来，形成一个体系完整、内容清晰的框架，为下一阶段的产品设计工作做准备。
在这个阶段，我们要做两件事情：整理需求并消除需求间的矛盾。
整理需求
将用户需求转化成系统需求后，我们要根据业务流向，整理每一个环节，每一种类型的需求。如下图所示：
这种结构是以业务流程为整理的主线索，也就是按「事」的角度进行分解。这种方法对于工作流系统以及信息管理系统来说都是非常适用的方法。
首先将我们的产品划分成不同的业务板块，在这个层面看哪些系统需求是针对业务事件，确保业务流程正常进行的;哪些系统需求是针对报表的要求，确保流转过程中的数据传递。
接下来再往更细颗粒的维度整理，梳理哪些系统需求是支持业务步骤的，基于这些业务步骤需要设计什么样的功能点。这样一来所有的系统需求都按照清晰的脉络，层层递进展现在我们面前。
消除需求间的矛盾
以上整理需求的方式，是按照业务流程进行整理的。在这个分析过程中，因为我们的需求来自不同的部门不同的岗位，难免会发现有些需求是互相矛盾、互相冲突的。因此我们在整理后的列表中需要将这些矛盾的需求全部圈出来，然后快速地找到相关人员，通过进一步的沟通协调来消除矛盾的需求。
很多时候，需求冲突的真正原因是使用者与管理者之间的冲突。作为使用者，他的核心诉求是方便高效、省事，最好还能在某些方面获得一定的利益;作为管理者，他的诉求是流程规范、过程可追踪，杜绝损害公司利益的事情发生。
例如中介公司的业务员，经常需要带客户去楼盘看房，他们自然希望在考勤方面能够更弹性，有一些自由度。但是作为管理人员，他们也没有办法盯着业务员时刻在做什么，只能通过一些定位打卡等手段管理业务员，不让他偷懒。
从这个例子可以看出来，不同角色由于岗位不同，核心诉求也不一样。在发生冲突的时候，笔者的建议是以企业的生产经营为核心，首先确保经营活动的规范化、流程化进行，在这个基础上增加为普通使用者考虑的易用性设计与情感化设计，让他们感受到产品不单单是一个反感排斥的工作系统，而是真正帮助他们提高工作效率的产品。
完成这一步后，才算是将整个产品的系统需求全部整理出来。以后每次迭代就是在业务需求与用户需求的基础上，创建新的系统需求，不断完善、丰富产品。
系统建设
终于，我们进入到系统建设环节，真正开始设计一款产品的形状了。在这之前，我们先探讨一个问题：B 端产品和 C 端产品在产品设计上有什么差异性?
笔者认为，绝大多数 C 端产品的设计逻辑会把用户体验与效率放在首位。追求极致的简单好用与高效。在整个产品设计上比较侧重用户的感受，精心打磨页面与交互，尽量少让用户做选择，保持产品的易用性与流畅性，都是做 C 端产品设计的不二法门。
但是做 B 端产品时，所有的产品设计都是为「流程」服务的。体验和效率未必是设计的重心。很简单的一个例子就能明白，企业买一款中介 CRM 产品，不是为了让业务员更轻松，做业务的时候更「省事」，而是为了将整个卖房的流程管理起来，做标准化的经营，为经营决策提供更准确科学的决策。B 端产品更多是通过计算机技术实现企业的信息化管理，对企业流程进行优化升级，从而达到降本增效的目的。
由此可以看出来，做 C 端产品更注重对「人」的理解，要求产品经理具备同理心，感知用户的能力。而做 B 端产品更注重对「业务」的理解，要求产品经理具有系统性的逻辑思维，富有理性地对企业业务进行全面梳理与诊断，给出合理有效的解决方案。
在规划产品原型的过程中，产品的信息架构设计是重要一环，其中菜单结构设计、CRUD 原则与 RBAC 模型的应用，可以帮助我们设计出更合理、高效的产品形态。
1. 菜单结构设计
常见的菜单结构设计有两种，以「人/物」为主线，或以「事」为主线。
大部分的通用型 B 端产品由于各行各业的垂直差异性，无法做到统一的流程管理，而产品需要满足尽可能多的行业，因此只能以「物」为主线划分菜单结构。例如将 CRM 系统划分为线索、客户、联系人、公海、商机、合同等等，都是以「人/物」作为划分的标准。
这种划分方式在一定程度上来说是有缺陷的，因为在实际的业务流程中，物与物之间的传递有可能交错，例如在房产交易、确权、归档的几个环节中都涉及到合同的流转，而这种菜单结构没有充分体现这种流转的特点，同时不同岗位的职责权限也有可能交错在一起。
而专注于垂直行业的 B 端产品则往往以业务流程的职责划分为菜单划分的标准，也就是以「事」为主线的设计方式。这种设计方式的好处是可以有效的避免重复和混乱的现象，对整个系统的架构都是非常清晰明了的。
CRUD原则
在互联网，各类互联网书籍都提到过 CRUD 原则，也就是将新增、删除、查询与修改等操作合并成一个管理页面。例如一个订单管理页，包含了新增订单、删除订单、查询以及修改订单信息等不同的操作。
但是在很多情况下，一个 ERP 系统中，录入订单是由业务员录入的，后续由销售人员更新订单的信息。当发现退款时，由财务或售后人员撤销订单。由此可见这些所谓的「管理」操作往往不是由同一个角色完成的，如果合并在同一个管理页面会产生很多职责权限混乱的问题。好在现在越来越多的产品也意识到这个问题，在菜单设计上尽量避免使用「某某管理」这样的字眼，而是根据业务场景，更灵活地划分菜单的范围。
上面这段话的意思，难道是说 CRUD 原则是错的?其实并非如此，只是 CRUD 原则对于系统创造的东西才适用，例如管理系统用户、管理数据字典、管理权限这类的东西就适用该原则。对系统用户的增删改查，通常都是由管理员操作的，这个时候我们把这些操作都放在同一个界面就是合理的场景。
RBAC权限模型
B 端产品的权限设计通常都是适用 RBAC 模型，也就是每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素等资源的访问与操作权限。建立一个「用户 – 角色 – 权限」之间的对应关系。
此时，用户与角色，角色与权限都是多对多关系，即一个用户可以对应多个角色，一个角色可以分配给多个用户，一个角色具有多个权限。当用户比较多时，可引入用户组，既对用户分组，将角色与用户组进行关联。
比如某个销售部门的员工在系统中是一个用户组，当新的销售员加入时，只需要设置他所在的用户组，就会将这个部门关联的权限赋予这位销售员。设置用户组还有一个好处，当这个部门的权限发生变动时，只需要调整这个用户组对应的角色权限即可，不需要调整每个用户和角色对应的关系。
以上三点是我们在做系统建设时最关键的核心设计点，相信经过以上的思考之后，结合上一阶段整理的系统需求列表，在我们的脑海里已经有大致的产品解决方案了。接下来的我们可以开始画原型、画界面，将文字性的想法通过形象化的方式展现出来。因原型的设计不是本文重点，在此不再赘述。
到这里，相信你已经对 B 端产品设计的全流程有一个清晰的思路了。韧哥在《产品经理必懂的技术那点事儿》一书中曾写道：
产品经理必须习惯与孤独为伴，这种孤独不是没有朋友的孤单感，而是指思考和决策的过程并不会有人给你明晰的指引，只能靠自己的独立思考和理解给产品赋予生命力，做出关键决策。
本文当然也不是一个教你如何做一款成功的 B 端产品指南，而是希望在你做 B 端产品时，能够提供一些设计的思路帮助你少犯错，沿着正确的方向思考问题。产品路上并不孤独，愿你我共勉。
