B端系统设计是一个“系统活动”。 相比强调直接价值传递、优化单点体验的C端产品，才有可能做出好产品。 B端产品注重系统建设和流程稳健。 而严格的逻辑规则是系统运行的基石，其次是产品外观和体验。
但一些刚入行的产品经理，或者是从C向B转型的产品经理，在处理需求时习惯性先画原型。 你所看到的就是你所想到的。 但这样做往往会带来流程短缺、逻辑不封闭等问题。 尤其是对于复杂的业务模块，更需要系统化的系统设计思想。
在此，结合我多年的B端系统设计经验，我认为无论B端系统设计多么复杂，都离不开这12个字：管理流程、构建模型、描述状态，并绘制交互作用。
一、管理流程 1、业务流程
B端系统设计的出发点是梳理业务流程。 坐下来和业务方一起，明确和理顺具体业务场景下的业务流程。
从具体的执行思路来看，业务流程可以从角色、动作、约束、效果四个方面进行梳理：
(1)角色：人的角色或系统的角色。 流程涉及哪些人（系统）、涉及哪些环节？ 角色是流程中最基本的元素。 有了角色，才能有明确的分工和有机的协作。
(2) Action：流程中角色需要完成的业务动作。 例如，营业员完成一次线索录入、快递小哥投递包裹，即该角色根据业务需求完成具体的业务指令。
(3)约束：特定业务场景和状态下产生的规则限制。 例如，获得销售线索后，系统录入需要在当天完成贴图笔刷，比如快递员需要在3小时内完成包裹投递。 同一角色完成同一动作，在不同的约束下可能会产生不同的效果。 例如，快递员在规定时间内送达或超时送达，超时送达将触发扣费等额外处罚措施。
(4)效果：角色完成动作后的效果。 代表下一步的动作，是流向下一个环节还是流程结束。 这里需要注意的一点是，产品经理要跟风向业务方询问几个“下一步做什么”，防止业务流程出现短缺，一步步要求将流程节点串起来，直到达到End状态。
2、系统流程
系统流程是业务流程中需要系统支持的部分，是代码实现的主要参考。 系统流程屏蔽了业务流程中纯离线操作部分，保留了业务流程中的人机交互、系统与系统交互、系统与物联网设备交互部分。
三、主要流程
划分主进程和其他进程的目的是为了设定事物的优先级。 首先确定下来的一定是业务的核心主流程，这往往是业务心目中的完美路径。
有时业务方只会考虑主要流程才提出需求。 作为产品经理，你需要帮助填补业务方尚未考虑清楚的空白。 这包括异常流程、逆向流程和分支流程。
4.异常进程
当运营商或系统未能按最初预期运行时，系统或业务采取的响应措施。 如果快递员仍然联系不上收件人怎么办？ 包裹应该按原路线退回还是保留在原地点？ 原路退回产生的运费是否由寄件人承担？ 一系列异常场景及解决方案。
5、逆向过程
正向流程因某种原因无法继续执行，导致反向流程、事件回滚/实物回到原路径/资源释放等。例如快递场景中，收件人拒绝收件包裹，于是快递公司将包裹反向退回给寄件人。 这是实体物流的逆过程。 可能有一次逆向过程、二次逆向过程、甚至更多等等。
6. 分支流程
在特定条件下触发的子场景流程。 如果用户在电商平台购买手机，选择以旧换新服务，那么在配送过程中，快递会触发第三方手机回收商上门回收手机，从而导致手机被回收。回收手机的分支流程。 该分支流程是主流程的一部分，并且在订单满足以旧换新条件时专门触发。
2. 建立模型
B端系统的业务建模就像盖房子一样。 在开始施工之前，必须打好基础，包括确定房屋的主体结构（主数据）和关键材料（业务文件）。 上层的稳定性完全取决于地基是否牢固。 因此，业务建模是B端系统设计中非常重要的一个环节。
1、主数据
主数据是能够满足跨部门业务协作需求、反映核心业务实体状态属性的基础信息。 在业务流程中，主数据属于底层基础信息元素，是构建上层业务活动的基础。 与业务活动产生的业务单据相比，主数据具有更稳定的属性、更高的准确性要求、唯一标识。 如CRM中的客户信息、电商中的产品信息、员工信息、协同办公中的组织信息等。
主数据建模是对组织中“人、财务、物”的抽象设计。 主数据系统设计时需要考虑父子对象关系、访问权限设计、数据仓库同步方式等问题。
2. 商业文件
业务文档是业务活动中的过程产品和结果产品，它存储和记录业务的持久性信息和状态信息。 例如，用户在电商平台购买商品，就会生成该商品的订单。 用户付款后，会生成入库出库单。 出库发货完成后，会生成各个环节的运输订单等。
从业务角度来看，业务文档是业务流程中的核心产品，是促进和管理业务正确执行的关键文档。 深入业务场景，细化业务文档，驱动业务流程。
从技术角度来看，业务文档是数据库表设计的关键参考对象。 梳理好文档的关键属性以及文档之间的关系，将使系统方案在技术实施过程中更加顺利。
3. 中风状况
B端产品的好坏，并不体现在产品的外观华丽上。 重要的是业务逻辑的完美实现，而业务逻辑最重要的组成部分就是业务对象的状态流。 业务状态流驱动业务行为发生，驱动业务行为发生。 它还促进业务对象状态转移。
可以说，业务规则最终执行的准确性与状态机的设计密切相关。
1.状态机生命周期
在B端系统设计中，业务对象实例是有生命周期的。 设计业务对象的状态机就像规划他或她的生活一样。 在其生命周期中，业务对象由人或系统激活（初始状态）。 随着用户的行为操作和系统规则推动它经过几个状态节点（中间状态），业务对象也会被多次调用、修改和更新，直到完成一个业务流程的职责，或主动或被动地去离线（终端状态）。
2. 状态机的组成
当前状态：指当前状态。
条件：也称为“事件”，当满足条件时，将触发动作或执行状态转换。
次要状态：满足条件后要转移到的新状态。 “次要状态”是相对于“当前状态”而言的。 一旦“次要状态”被激活，它就会转变为新的“当前状态”。
初始状态：指初始状态，如“待付款”。 一般来说用户角色权限表设计，只有一个初始状态。
最终状态：指状态机的结束状态，例如“已取消”和“已完成”。 可能有多个最终状态。
3.状态机设计原理：MECE
我们从业务对象的角度构建状态转移的全生命周期。 这样做的初衷是为了防止状态遗漏，导致业务不闭环。 所谓MECE的意思是“相互独立且完全详尽”。 对于状态机设计来说，在枚举状态时，不能做到不重叠、不遗漏。 这样做的目的是保证程序实现明确，能够覆盖所有业务场景，使系统能够准确运行。
4.绘制交互
对于B端系统来说，业务流程、业务对象建模、状态流程确定后，解决方案就成功了80%。 我们将完成产品剩余的交互功能，解决方案就完成了。
执行方面，根据业务需求和产品调性用户角色权限表设计，输出产品需求文档和原型图。
交互设计主要包括人机交互和系统间交互，而B端系统的设计比什么都更实用。
1、人机交互
B端系统的人机交互注重信息清晰、页面简洁、操作方便、即用型。
(1)便捷性：便捷的操作体验可以让用户身心愉悦。 便捷的理想情况是业务人员用完即走，在最短的时间内完成规定的业务动作。 多种按键操作（合并多个操作步骤）、智能记忆、自动填表等便捷的产品设计。
(2)简化：简化分为交互的简化和流程的简化。 交互的简化是指消除对用户不必要的信息干扰，使信息元素以直接、无争议的方式呈现给用户。 可以参考John Maeda的《Simplicity First》，里面介绍了一些实用的设计方法和工具； 流程简化是指剔除重复流程，合并相似流程，避免业务流程和产品运营层面的浪费，比如分散审批流程等。流程需要根据实际业务场景进行梳理。 删除前请注意彻底穷举。 ，避免遗漏。
（3）愚钝：想用户之所想，通过数据收集、分类、标签等提前预测用户下一步行为，并提供参考信息辅助决策，代替用户做信息收集、整理、判断，如智能调度、智能客服等；
2. 系统间交互
系统之间的交互包括系统之间的接口调用、执行顺序等，这部分设计方案往往用时序图表达得更清楚，强调接口的调用关系和依赖关系，研发也更容易理解。
需要注意的是，除了主流程之外程序开发，前期梳理一些异常和限值处理逻辑，会大大减少接口联调的时间。 否则可能会出现“写代码”→“联调”→“发现错误”的情况。 →“改代码”→“重新联调”→“再改代码”的困境严重影响施工进度。
写在最后
无论做什么，都应该深入本质，抽象出规律，因势而变。
面对事业、职场、生活的变化，我们依然能够从容应对。
一技之长，无惧人生坎坷！
