很多时候，业务系统建设好坏决定了企业的核心竞争力。作为产品经理，如何建设好业务系统这种OLTP类产品？本文从梳理业务流程、参与业务调研和设计业务系统三个步骤，教大家如何做好业务系统建设。

很多人都说设计B端产品最重要的是搞清楚公司的业务逻辑，只要搞清楚公司业务是怎么运作的，就能设计出满足业务需求的产品。

B端产品（业务系统）和C端产品搭建的出发点和侧重点完全不同，C端产品偏重用户体验强调个人感性，通过持续的数据分析而不断优化，即使是同一个按钮不同的摆放位置都要经过精心设计和论证，它的服务对象是个人群体；而B端产品（业务系统）偏重业务流程、模块化，强调抽象和结构性，讲究整体的规划和体系设计，它的服务对象是组织或职能类用户群。

常见的业务系统包括ERP（EnterpriseResource Planning），CRM（CustomerRelationship Management），SRM（Supplier Relationship Management），OA（Office Automation），HRM（Human ResourceManagement）等等。

因为绝大多数互联网公司都有独特的业务模式，所以很多时候类似于CRM、ERP、SRM这类系统都自主研发，OA、HRM这类系统由于业务模型区别不大，多数都会采购标准软件,不过有些互联网巨头出于数据安全等因素考量也会自主研发OA、HRM。

习惯上ERP、CRM、SRM这类系统被称为业务系统，OA、HRM这类系统被称为公司内部协同软件，但两类系统之间也并没有非常清晰的界定。

如果从软件学的角度来看，所有软件系统分为两类，第一类是能够实时产生业务数据的系统，叫做OLTP（Online Transaction Processing）系统，第二类是对数据进行加工、处理、探查、挖掘、展现的系统，叫做OLAP（Online Analytical Processing）系统。

很显然，业务系统属于OLTP的范畴。

当企业发展到一定阶段，业务系统对企业的高效管理运转具备不可替代的核心作用。例如，当一家公司只有几个销售人员时，客户资料用Excel即可以满足管理需求，但当销售人员发展到上千人时，必须通过一套CRM系统进行管理。

总体来讲，业务系统对企业具有四点价值：提升管控能力、控制经营风险、降低运营成本、提升公司业绩。

很多时候，业务系统建设好坏决定了企业的核心竞争力。

一、梳理业务流程

B端产品（业务系统）的设计起点是从梳理业务流程开始。需要产品经理坐下来和业务方一起在具体的业务场景下将一条条业务流程挑明理顺。具体执行思路上，可以从角色、动作、约束、效果四方面去梳理业务流程：

1. 角色：人的角色或者系统角色。都有哪些人、系统参与到流程中来，参与了哪些流程中环节，角色是流程中最基本的元素，有了角色才有明确分工，才能有机协作使流程流转起来；
2. 动作：流程中需要角色完成的业务动作。如外卖小哥去配送一个外卖订单，即角色按照业务要求去完成具体的业务指令；
3. 约束：在具体的业务场景和状态下产生的业务规则限制。如外卖小哥需在半小时内完成外卖订单派送。同一个角色完成同一个动作，在不同的约束下可能产生不同的效果，如外卖小哥在规定时间内派送和超时送达，超时送达会额外触发扣款等惩罚措施。
4. 效果：角色完成动作后的效果。决定着下一步的动作是流转到业务流程的下一环节还是流程结束。这里注意一点是产品经理要顺藤摸瓜多问业务方几个“然后呢”，防止业务流程有短缺，通过一步步思考追问将所有流程节点串起来，直至达到流程结束状态。

角色与使用场景分析：

用户故事由参与者和用例组成，梳理用户故事的关键点在于发现使用系统的用户并梳理这些用户是如何使用系统的，从各个业务事件处理的过程中得到用例。

参与者是指在业务系统之外，这个业务流程中与业务系统进行有意义交互的任何事物。参与者不仅可以由人来承担，也可以是其他系统或者是硬件设备。

用例是指用户在业务系统中执行的一系列动作，通常用“动词+名词”的方式表达。值得注意的是，用例是有目标的，它能够为参与者带来有意义的结果，例如“填写搜索外卖条件”显然对于参与者来说没有任何意义，就不是一个合适的用例。另外用例是对一组使用场景的抽象。用例与场景之间的关系像是计算机概念中类与对象之间的关系。

一个场景是一个具体的行为，一个用例是对一类相关行为的抽象。用例分析的意义在于帮助产品经理在短时间内从结构、整体上了解业务构成。用例是比较高层次的业务抽象，更容易被人们理解和接受。

二、参与业务调研

设计业务系统之前，必须透彻理解业务现状与业务目标，考虑如何结合当前业务系统或者其他系统改造、优化当前业务流程和业务模式。此阶段可以由一个高级产品经理带领几个初级产品经理共同去完成，最好邀请技术负责人一起参与，有利于技术人员提前理解业务，为技术选型和技术方案设计提前做好准备。此外技术人员具备更好的抽象能力，深入理解业务，可以让技术负责人协助产品经理共同完成整体方案设计和细节方案设计。和C端场景一样B端场景中的用户需求也像是一个冰山，有很大一部分信息是埋藏在海平面之下，这就对需求调研工作带来很大的困扰。

用户主要的需求分为三种：

1. 意识到的需求：这是在海平面以上的需求，通常是一些困扰用户的问题，或者是用户自己能想到的所需功能。大部分产品经理在调研过程中获取到的都是这一类用户需求；
2. 无意识的需求：它是用户在实际工作场景中“没有意识到是问题”的问题，这种问题需要产品经理对业务有一定的理解才能够发现。如果对这些场景能做到“感同身受”的话，相信在产品规划的过程中能够设计出更合理、高效的方案；
3. 进一步的需求：调研的用户毕竟不是技术专家，只是普通的业务人员，因此他们没有办法对其工作提出产生变革的解决方案。因此需要产品经理在对发现的问题充分理解前提下，选择合适的实现方式以创造出用户未曾想到的产品功能；

实际上B端产品的需求获取并不难，难的是与用户交流沟通的过程。因为我们的用户仅仅作为一个业务系统使用者，他只是站在自身使用产品的视角，想让自己的工作方便一些或是在利益分配上对自己更有利，很难站在业务系统规划的角度考虑全面整体的东西。

遇到这种情况，最有效的应对策略是需求分析首先从流程入手搞清楚业务活动在平时是如何开展的，再逐步过渡到当前业务活动存在什么样的障碍，遇到什么困难等等。在这个过程中多问几个为什么，多思考用户诉求背后代表的心理状态与利益冲突。

在这一阶段我们主要做的工作是收集针对业务活动的问题点、需求点。这时候我们获取到的是原始的用户需求。

实际上在业务流程分析、角色与使用场景分析、以及获取用户需求都是伴随着用户调研进行的。用户调研是一个有计划、循序渐进的过程。调研之前最好对业务能有大体的认知，安排好访谈的对象，提前准备好问题，让访谈更加高效。

具体来说，在针对不同的访谈对象时，访谈的要点也不尽相同，具体的要点参考以下表格：

除了用户访谈和问卷调查以外，有机会到业务工作中实际现场观摩也是一种很好的需求获取手段，有助于产品经理对业务场景建立更加感性的认识。在对关键任务理解不清晰、很多东西用文字没办法表述时，现场观摩都是一种很好的直接方式。

三、设计业务系统

完成业务调研后，进入业务系统整体方案设计环节。

该环节需要由经验丰富的产品经理以及公司的架构师一起探讨完成，因为方案涉及到和公司现有应用架构融合，还需要经过产品委员会或架构组的评审和确认。

设计业务系统需要做到明确以下几点：

1. 业务系统定位：设计业务系统常见的问题是为了图省事把所有业务单元的功能糅合到一个系统中实现，造成管理的混乱尤其是系统维护的混乱。一般来讲系统的抽象要结合实际业务完成，独立的业务职能单元要有各自独立的系统来配合使用。如果业务部门之间边界模糊，权责界定不清，也会导致系统之间存在模糊性。清晰的系统定位并划清边界，可以让彼此具备足够的独立性，是系统灵活性和可扩展性的基本前提；
2. 业务系统架构设计：此外公司经过多年发展，系统架构体系已经非常完备，大量公共组建和模块可以复用（如流程引擎），这样就减轻了新平台/业务系统的实现成本和难度，只需要聚焦自己业务特殊独立的地方，其他公共组建和模块复用已有系统即可；
3. 业务系统功能抽象：基于对业务的分析，可以抽象并绘制完整的系统功能蓝图。功能模块图是对业务诉求系统化设计的进一步高度抽象。模块的设计，要体现出同一个业务职能单元中不同业务场景和操作的集合，模块也代表了系统中的一二级导航菜单的设计。常见的问题是设计人员对模块设计的随意和混乱，以及后来新增功能的随意摆放，会造成用户使用系统时产生困惑，同时还会导致开发人员编码设计的混乱。功能模块图，代表了设计师对业务和系统本质的理解和提炼，包含了对业务、系统未来发展的展望。我们常说业务系统建设要有规划和节奏，实际上功能模块图就是一幅远景规划蓝图，是系统的骨架，决定了系统的整体结构，结合业务需求，每一个具体功能的实现，都是在对骨架不断地填充血肉，让他更真实，更立体，更丰富。随着业务的开展，变化，功能模块图可能会有新的规划和调整，但如果业务单元的本质和模式没有变化，功能模块图不应该出现结构性的调整和改动；
4. 业务系统演进蓝图：在绘制了系统的功能模块图体现了业务和系统规划的脉络之后，就需要我们开始研究这套“体系”大概需要几期（项目工期）实现，每期实现的侧重点是什么，也就是常说的产品演进蓝图（Roadmap）。

做B端产品（业务系统）注重对“业务”的理解，要求产品经理具有系统性的逻辑思维，富有理性地对企业业务进行全面梳理与诊断，给出合理有效的解决方案。

在规划产品原型的过程中，产品的信息架构设计是重要一环，其中菜单结构设计、CRUD原则与RBAC模型的应用，可以帮助我们设计出更合理、高效的产品形态。

1、菜单结构设计：常见的菜单结构设计有两种，以“人/物”为主线，或以“事”为主线。大部分的通用型B端产品由于各行各业的垂直差异性，无法做到统一的流程管理，而产品需要满足尽可能多的行业，因此只能以“人/物”为主线划分菜单结构。例如将CRM系统划分为线索、客户、联系人、公海、商机、合同等等，都是以“人/物”作为划分的标准。这种划分方式在一定程度上来说是有缺陷的，因为在实际的业务流程中，物与物之间的传递有可能交错，例如在房产交易、确权、归档的几个环节中都涉及到合同的流转，而这种菜单结构没有充分体现这种流转的特点，同时不同岗位的职责权限也有可能交错在一起。而专注于垂直行业的B端产品则往往以业务流程的职责划分为菜单划分的标准，也就是以“事”为主线的设计方式。这种设计方式的好处是可以有效的避免重复和混乱的现象，对整个系统的架构都是非常清晰明了的；

2、CRUD原则：在互联网，各类互联网书籍都提到过CRUD原则，也就是将新增、删除、查询与修改等操作合并成一个管理页面。例如一个订单管理页，包含了新增订单、删除订单、查询订单以及修改订单信息等不同的操作。但是在很多情况下，一个ERP系统中，录入订单是由业务员录入的，后续由销售人员更新订单的信息。当发现退款时，由财务或售后人员撤销订单。由此可见这些所谓的“管理”操作往往不是由同一个角色完成的，如果合并在同一个管理页面会产生很多职责权限混乱的问题。好在现在越来越多的产品也意识到这个问题，在菜单设计上尽量避免使用“某某管理”这样的字眼，而是根据业务场景，更灵活地划分菜单的范围。上面这段话的意思，难道说CRUD原则是错的？其实并非如此，只是CRUD原则对于系统创造的东西才适用，例如管理系统用户、管理数据字典、管理权限这类的东西就适用该原则。对系统用户的增删改查，通常都是由管理员（同一种用户角色）操作的，这个时候我们把这些操作都放在同一个界面就是合理的场景；

3、RBAC权限模型：B端产品的权限设计通常都是适用RBAC权限模型，也就是每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素等资源的访问与操作权限。建立一个“用户——角色——权限”之间的对应关系。用户与角色，角色与权限都是多对多关系，即一个用户可以对应多个角色，一个角色可以分配给多个用户，一个角色具有多个权限。当用户比较多时，可引入用户组，既对用户分组，将角色与用户组进行关联。设置用户组还有一个好处，当这个部门/组织的权限发生变动时，只需要调整这个用户组对应的角色权限即可，不需要调整每个用户和角色对应的关系。

任何一个完整的B端产品（业务系统）都离不开基础数据模块、策略与配置模块、业务处理模块、辅助工具和统计报表功能这5个要素，就像盖房子的地基、地平、主体、门窗和屋顶一样，缺一不可。

1. 基础数据模块：在业务发生前已经定义好，用于标识某个业务或主体的静态数据，比如采购系统里的商品和供应商数据、财务系统里的会计目录等，基础数据模块是业务基础；
2. 策略与配置模块：为指导业务开展而提前设定好的业务规则，包含参数、配置项、系统逻辑等，比如采购的审核策略、仓库的入库策略、商品的上架策略等，策略与配置模块为业务开展提供前置保障；
3. 业务处理模块：执行并记录业务发生的过程，是完成业务最核心最常用的功能，一般以单据的形式记录，包含业务发生的过程和数据、单据状态流转、操作页面等，比如采购系统里的采购订单、仓储系统中的入库和出库管理流程、财务系统的核算流程等；
4. 辅助工具：为了辅助达成业务目标，为降本增效、容错防呆而添加的软硬件功能，比如常用的批量处理、导入导出功能，以及OCR识别对比功能等，辅助工具为业务提供更加高效的功能；
5. 统计报表：用于统计和查询业务数据的看板、报表等，便于更好的呈现业务的全貌，发现业务的问题，从数据视角宏观呈现业务开展的过程和质量。

直到这里相信你已经对如何应对B端产品（业务系统）设计有一个清晰的思路了。后面还会根据自己的实际工作经历，持续分享B端产品经理成长之旅相关内容，感兴趣的朋友欢迎加关注评论交流，大家一起携手共进。

本文由 @Zero0304 原创发布于人人都是产品经理。未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。