B端系统设计，黄金12字

B端系统设计是一项全面的任务，与C端产品不同，它更注重整体系统构建。对于C端产品，我们强调价值传递和单点用户体验的优化，而在B端，我们需要建立坚实的体系，严格的流程和逻辑规则是系统顺利运行的基础，产品外观和用户体验相对次要。然而，一些新手产品经理或从C端转向B端的产品经理在处理需求时可能会习惯性地首先绘制原型图，跃进到具体设计，但这样做通常会导致流程不完善、逻辑不清晰等问题，特别是对于复杂的业务模块，更需要系统性的系统设计思路。基于我多年的B端系统设计经验，我认为无论多复杂的B端系统设计，都可以概括为以下12个关键步骤：理清流程，建立模型，梳理状态，绘制交互。这些步骤将有助于确保系统的完整性和高效性，为B端用户提供出色的体验。

理清流程

业务流

B端系统设计的第一步，通常是从梳理业务流程入手。这意味着坐下来，与业务方一同深入了解具体的业务场景，然后逐一梳理清晰的业务流程。

在具体执行中，可以采用以下四个方面的方法来梳理业务流程：

角色：首先要明确在流程中涉及到哪些人或系统的角色。了解谁参与了流程，以及他们在流程中扮演的具体角色，这是流程中最基本的元素。只有了解角色，才能明确任务分工，使各个角色可以协同工作。

动作：接下来是确定流程中各个角色需要执行的具体动作。例如，销售人员录入潜在客户信息，快递员配送包裹。这些动作是角色按照业务需求完成的具体任务。

约束：在具体的业务场景和状态下，会有一些规则和限制。例如，在获取销售线索后，要在当天完成系统录入，或者快递员需要在规定时间内完成派送。不同的角色在不同的约束下可能会产生不同的效果，例如快递员如果超时交付可能会受到额外的罚款等惩罚。

效果：最后，要考虑角色完成动作后会导致什么结果。这代表着下一步是将任务传递给下一个角色，还是结束了整个流程。在这一步中，产品经理需要不断追问业务方的“然后呢”，防止业务流程有短缺，直至达到最终的结束状态。

系统流程

系统流程是业务流程中需要计算机系统支持的那一部分，它是开发代码的主要指南。系统流程主要涵盖了那些需要计算机系统处理的任务，它们包括人与机器的互动、不同系统之间的通信，以及与物联网设备的互动。

主流程

划分主流程和其他次要流程的目的在于明确事情的优先级。首要任务是确定业务的核心主流程，通常是业务中最理想的路径。

有时候，业务部门可能仅仅关注主流程，然后提出需求。在这种情况下，产品经理需要帮助填补业务方尚未考虑的空白，包括异常情况、逆向操作和分支流程等。

异常流程

异常流程是在操作者或系统未按照原计划执行时，系统或业务采取的应对措施。举例来说，如果快递员无法联系到收件人，应该选择是将包裹退回还是暂时保留，如果选择退回，那么由发件人承担运费等一系列异常情况和相应解决方案都属于异常流程。

逆向流程

逆向流程是正常流程由于某种原因无法继续执行而需要执行的反向操作。它可能涉及到事件的回滚、物品的退回、资源的释放等等。例如，当收件人拒绝接收包裹，快递公司将包裹退回给发件人，这是一个逆向流程，可能包括一次逆向流程、二次逆向流程等等。

分支流程

分支流程是在特定条件下触发的子场景流程。比如，当用户在电子商务平台购买手机，并选择了以旧换新服务，那么在配送流程中可能会触发第三方手机回收商上门回收旧手机，这就是一个分支流程，它是主流程的一部分，只在特定条件下触发。

建立模型

B端系统的业务建模就像建造一座房子一样。在动工前，必须先打好坚实的地基。这个地基包括确定房屋的主要结构（主数据）和必需的材料（业务文件）等。就像一栋楼房的稳固与否，取决于地基是否扎实。因此，业务建模在B端系统设计中扮演着非常重要的角色。地基牢固了，整座楼房才能稳固。同样，业务建模的质量决定了B端系统的可靠性和成功程度。

主数据

主数据就像组织的基石，它包含了跨不同部门协作所需的关键信息，同时也反映了核心业务实体的状态和属性。主数据在业务流程中扮演着底层支持的角色，就像建筑物的地基一样，是上层业务活动的基础。与由业务活动产生的业务单据相比，主数据更加稳定、准确，需要唯一标识。举例来说，CRM系统中的客户信息、电子商务中的商品信息、协同办公中的员工信息以及组织信息都属于主数据。

对主数据的建模就像在组织中设计“人、财、物、事”的抽象化图纸。在设计主数据系统时，需要考虑父子关系、访问权限、以及数据仓库的同步方式等各种问题，以确保主数据系统能够有效支持各项业务活动。

业务单据

业务单据是业务活动的产物，记录和存储了业务的持久信息和状态信息。举例来说，当用户在电子商务平台购买商品时，会生成商品订单；用户付款后，会产生出库单；出库完成后，将生成各种运输单据等等。

从业务角度看，业务单据是业务流程中的核心产物，是推动和管理正确执行业务的重要凭证。它深入了解业务场景，提炼业务单据，推动业务流程的进行。

从技术角度看，业务单据是库表设计的关键参考对象。需要清晰梳理单据的关键属性和单据之间的关联关系，以确保系统实施过程中能够更顺畅地完成技术方案。这样可以确保系统方案在技术层面的顺利实现。

梳理状态

B端产品的好坏不在于外观的华丽，而在于它能否完美地实现业务逻辑。而业务逻辑的核心部分是业务对象的状态如何变化，这个状态的变化会推动业务行为的发生，而业务行为的发生又会影响业务对象的状态。

可以这样说，业务规则的准确实现与状态机的设计密切相关。状态机是一种工具，帮助我们明确业务对象可以处于哪些状态，以及它们如何在不同状态之间切换。这个设计的质量直接关系到最终产品的性能和效果。

状态机生命周期

在B端系统设计中，我们可以把一个业务对象的生命周期看作是它的整个生命旅程。就好比你规划自己的一生一样。业务对象在生命周期中会经历不同的状态，这些状态可能由人或系统来触发。从开始（起始态）到在用户的操作和系统规则的驱动下，业务对象会逐渐经历一系列状态变化（中间态）。它可能会被不断调用、修改、更新，直到完成一次业务流程的任务，然后它可能主动结束或被动结束（终结态）。

状态机构成要素

现态：这是指业务对象当前所处的状态。

条件：也称为“事件”，当某个条件被满足时，会触发一个动作或状态的迁移。

次态：条件满足后，业务对象需要迁移到的新状态。一旦次态被激活，它就成为新的现态。

起始态：这是指生命周期中的初始状态，通常只有一个，比如“待付款”。

终结态：表示状态机的结束状态，可以有多个，比如“已取消”和“已完成”。

状态机设计原则：MECE

从业务对象的角度来看，我们构建状态流转的整个生命周期，这是为了防止状态遗漏，从而导致业务中断。MECE意味着“相互独立，完全穷尽”，在状态机设计中，这意味着在列举状态时，它们不应该重叠，也不应该遗漏。这样做的目的是确保程序实现没有二义性，能够覆盖所有可能的业务情景，以确保系统能够准确、无误地运行。

绘制交互

对于B端系统而言，一旦我们明确了业务流程、业务对象模型和状态变化，项目的成功程度已经达到了80%。剩下的20%任务就是确保产品的用户界面和功能完善无缺，这时候方案基本完成了。

在具体执行中，我们需要根据业务需求和产品的特点，制定产品需求文档和原型图。

交互设计是重要的一部分，它包括了用户和系统之间的互动方式，尤其在B端系统设计中，实用性至关重要。这意味着我们要确保系统的使用对用户来说是方便和高效的，同时系统之间的协作也要顺畅。这是方案中的最后一步，但同样重要。

B端系统的用户界面设计要追求信息清晰、页面简单、操作方便、即用即走。

便捷化：用户体验的便捷性能够让用户感到愉快。理想的便捷设计是使业务人员能够在最短的时间内完成必要的操作，这包括使用一键操作、智能记忆功能、以及自动填写表单等。

简单化：简单性有两个方面，一是交互的简化，即排除不必要的信息干扰，确保信息以清晰、直接的方式呈现给用户；二是流程的简化，去掉重复的流程，合并相似的流程，以避免浪费时间和资源，例如将审批流程简化。在流程简化时，需要先全面列举，再逐一删除，以防漏掉必要的步骤。

智能化：系统可以预测用户的下一步行为，并提供相关信息以辅助决策，从而简化用户的操作。例如，智能调度系统可以帮助分配任务，智能客服可以自动回答用户问题。

系统间交互

系统间交互包括了系统之间的接口调用和执行顺序。这部分设计可以使用时序图来清晰表示接口之间的调用关系和依赖关系，这有助于开发人员更好地理解系统间的交互。

在设计系统间交互时，除了主要流程，还需要提前考虑一些异常情况和极限情况的处理逻辑。这样做可以大大减少接口联调阶段的时间，避免在联调过程中频繁修改代码，从而影响工程进度。

写在最后

我们做任何事情，都应该挖掘本质，抽离规律，以不变应万变。

在面对业务的变化、职场的变化、人生的变化，仍能从容应对。

一技傍身，不惧人生风雨！