案例 | 作为产品经理，我是这样设计业务系统的

业务系统的本质需求是满足前台维护或工作需要，因此，严谨的业务流程实现和较少的操作步骤，是业务系统应该具备的基本特点。

完整的业务系统，应该涵盖如下内容：

由于业务系统本身是为满足用户的工作需要，因此用户管理、权限分配、工作流毫无疑问占据核心地位。

与前端产品不同，业务系统往往基于复杂的数据流和业务逻辑，这就要求产品经理提供详细完整的业务流程图和PRD。接下来作者就一些常见模块设计做简要说明，有纰漏之处还请各位大牛批评指正。

1.用户管理

平台的设计最终是为了服务于用户。

 1.1用户登录名

业务系统不同于社交APP和论坛，用户名往往是严肃准确的。而由于用户同名的几率太大，使用姓名作为登录名显然是不太合适的，常见的业务系统或后台登录名如下：

姓名（拼音）+编号：如zhangsan，zhangsan1；

1. 优点：用户名命名规则简单，完全避免了同名问题；
2. 缺点：命名需自动生成或由管理员负责，行政领导使用时可能不合适；

身份证号：

1. 优点：完全杜绝重复，用户名较严肃；
2. 缺点：若用户年龄群体较大，记忆和输入身份证号不利于提高用体验；

手机号码：

1. 优点：便于记忆；
2. 缺点：手机号更换较麻烦，不适用于较严肃的业务系统；

工号/单位内个人编号：

1. 优点：严肃、避免重复；
2. 缺点：记忆不便、适用范围较窄（不适用于无工号的单位）；

除此之外，其余能够标记用户唯一性的方式均可使用，但应严谨、严肃，不宜出现个性化因素，如昵称等。

 1.2用户来源

常见的业务系统用户往往来源于管理员主动添加。在用户较多且不便导入或其他使用者特殊需求情况下，可能存在用户自行注册的情况。

1. 由管理员添加：较常见。管理员添加用户并为用户关联权限信息，此时用户即可正常使用系统；
2. 用户自行注册：用户注册可能存在冒名顶替现象，需身份验证环节。验证审核与授权工作在交互上可同时完成。

 1.3用户安全

业务系统涉及到使用者业务流程、重要数据等，因此对安全要求较高，除常见的密码、验证码等方式之外，有可能借助其他加密方式，如UKEY、数字证书等。

2.权限管理

权限管理决定了哪些用户可以使用什么功能，完成什么操作，对什么数据进行操作，是业务系统中的重中之重。

 2.1功能权限

功能权限决定了用户能看到多少菜单，能访问哪个页面，能操作哪些按钮。业务系统的权限往往能够精确到页面中甚至弹窗中的按钮，而普通的内容后台则往往不需要多此一举。

常见的功能权限的控制主要有以下几类：

  2.1.1角色控制

角色是功能权限的集合。之所以放在第一个，是因为该方法是在业务系统中最常见的、操作简便的功能权限控制方式。

实际应用中，引入角色概念，建立某个角色，并关联若干功能点。此时将角色关联到用户下，即可赋予该用户不同角色权限的并集。

角色权限控制适用于使用者权限具有典型性、普遍性的状况，可以避免重复对具体功能权限进行重复操作，能极大提高管理员效率。因此，在部门、岗位划分明确的状况下一般使用该方式。

  2.1.2岗位控制

岗位控制的前提是存在明确组织结构管理，并通过相应的岗位与员工一一对应。岗位本质上与角色一样是功能权限的集合。

通常情况下，岗位管理属于人事管理范畴而非系统管理，因此通过岗位关联权限的做法，在系统内存在人事模块时，会混淆人事管理和系统管理的概念。

  2.1.3直接关联

对于单位内人员较少，人员分工较不明确的单位，也存在将人员直接关联功能权限的设计。该做法仅仅适用于较小范围内、不同人员权限差异较大的情况下使用。

  2.1.4跨单位功能权限

跨单位功能权限多用于存在较多分公司、事业部、分支机构、下属单位等情况的大型业务平台。不同单位的功能权限有所区别。

这就要求存在一个超越所有单位的超级管理员，对不同单位授权以作为单位的最大权限。各单位管理员基于单位权限对单位内用户进行权限分配。

常见的跨单位功能权限处理方式如下：

1. 引入单位角色概念：首先由超级管理员建立单位角色，将单位关联角色。此时，单位基于单位角色作为单位的最大权限，对用户进行详细的权限划分；
2. 使用单位类型区别单位的功能权限：与单位角色在授权方式上并无本质区别，但单位类型可能作为单位查询的统计口径之一，未必能够完全兼顾权限，灵活度较差；
3. 将单位直接关联功能权限：简单粗暴，灵活性较强，适用于单位较少的情况。

 2.2数据权限

数据权限决定了不同用户在同一页面上能够看到的数据的不同，能看哪些数据，不能看哪些数。在部门或不同单位职权划分明确、或者不同性质单位使用同一系统时，数据权限的区分至关重要。

数据权限与功能权限共同组成系统的权限控制，是业务系统不可或缺的一部分。

  2.2.1单位数据权限

同功能权限一样，数据权限首先要定义单位的最大数据权限：

通过单位类型限制：适用于存在多种类型单位的大型平台使用。不同类型的单位需要使用到的数据不同，因此使用单位类型进行限制是较合理的方式；

通过权限级别限制：适用于存在多级别单位的平台，通常与单位类型控制混合使用。例如县级行政单位使用本县所有数据，市级行政单位则使用本是区域内（市直单位、县区）的所有数据；

  2.2.2用户数据权限

单位数据权限确定之后，就要为不同用户分配权限，不同级别、不同部门、不同岗位的用户需要使用的数据往往是不同的。而对用户限制数据，通常与权限控制类似：

部门/岗位/角色控制：不同部门、岗位、角色分工不同，数据权限自然不同。例：业务部门1与业务部门2的数据权限均为由本部门人员产生的数据；

通过功能权限控制：该方式对数据权限的控制粗糙但简单。有页面功能权限的用户默认为看到该页面展现的所有数据（能否操作数据由按钮的功能权限控制）。适合分工较明确的场景下使用。

3.工作流管理

工作流是业务系统的灵魂所在，是实际业务流程在系统中的反映。根据实际业务中的不同需要，工作流存在自定义工作流和固定工作流两种状况。

而无论是自定义还是固定工作流，理清业务流程，绘制业务流程图是非常重要的，而在业务流程图中，泳道图是最为常用的（下图是某项目中的流程示意）。

 3.1自定义工作流

满足同一业务需求：常见的诸如请假、财务等OA流程等。此时自定义工作流主要定义发起人（发起角色）、工作流节点、工作流节点条件等内容。该情形主要适用于同一单位内部存在较多上下级流程的需求，拥有相应权限的用户可对不同流程节点的参与人员/角色进行定义；

自定义工作流适合不同使用单位下，相同业务流程有差异的情况，如系统中存在单位A和单位B，单位A的请假审核流程为员工—部门经理—总监—人事，而单位B的审核流程为员工—部门经理—人事；

自定义工作流的各个节点视情况可精确到岗位、角色、用户等；

 3.2固定工作流

固定工作流并非一成不变，其本质是通过控制功能权限和数据权限来控制工作流中的节点。该方式适用于平台内业务流程较稳定、较统一的情况。为详细阐述，下面举例说明：

例：假设系统中存在业务A，A业务流程如下：县级子公司——市级子公司——省级总公司部门A——省级供公司部门B。假定该业务流程非常稳定，则可将工作流固定，由不同区域的子公司甲和子公司乙发起的业务均使用该流程。

4.数据处理

数据处理是为管理人员提供决策支持、单位对外展示的重要依据。

 4.1数据可视化

数据可视化能够明确表达数据间变量和属性的关系，是数据分析中不可或缺的方式。应选用合适的统计图对有重要作用的数据进行分析（统计图在web中有很多可以直接拿来用的插件，可以减少前端的工作量，如E-Charts、Highcharts等）。

4 .2数据勾稽（逻辑）关系

数据勾稽关系常见于报表系统、财务系统等，适用于表达表格间不同行、列或多表格间的关系。

勾稽关系由需求决定，目标明确而单一。表达勾稽关系要求PM在PRD中明确表现出来，一般使用对表格中不同的行、列赋名，以公式的形式表示。

例：（以某功能PRD为例）

5.系统首页

业务系统的首页设计应遵循实用、简洁的原则。

常见的首页组成元素通常包括快捷方式、数据分析、待办事项、通知公告等，部分有个性化需求的首页往往可以对首页元素进行自定义。

自定义首页元素可分为后台自定义和用户自定义。为便于自定义元素的排版，自定义的各个元素大小应保持一致。

6.消息发送

业务系统中消息发送作为用户与用户、单位与单位之间交流的重要方式。

消息发送主要考虑到发送主体、接受范围、可见范围、附件上传、已读未读标记、消息记录等要素。

7.操作记录

操作记录用来记录用户的操作轨迹，即对用户的登录退出、数据变更、数据访问、操作内容（必要记录如财务等可详细到从A变更为B）、操作人、操作时间等。

记录用户的操作轨迹是出现问题后追责的重要依据，是业务系统和后台系统的标配。

8.交互案例

上面谈了一系列业务系统的简单设计逻辑，但最终还是要落实到原型上。该模块主要体现的是用户体验层级中的框架层。一些复杂业务流程的交互和页面布局往往比较复杂。笔者总结项目经验，对部分典型交互做简单解释。

 8.1审核流程状态

层级审核流程中，为用户标记出完整流程并指示用户当前所在流程的状态，能在很大程度上提高用户体验；

 8.2存在多层级数据

如按照行政区域进行划分的数据等，使用树的形式展现是较为清晰的模式，而若数据存在审核操作，则在树中以颜色的形式标示出审核状态，使数据状态一目了然；

 8.3复杂数据录入

复杂数据录入时用户往往因繁杂的录入框而手忙脚乱，因此，复杂数据录入时有必要为用户分门别类，以清爽、有序的方式展示给用户（举例说明）：

按类别将输入内容分门别类：

分步骤有序填写：

复杂表格内容在表格中直接填写：

 8.4硬件控制

硬件控制主要侧重于工控方面，清晰的控制按钮与状态反馈非常重要：

使用按钮操作硬件，尤其是硬件个数较多时，需要给用户清晰展示出按钮的作用；

用户通过网页或APP内的按钮控制某硬件设备，往往会存在“我是否成功操作”的疑问，因此需要在用户操作之后及时给予反馈。

 8.5数据展示

数据展示合理使用图表，对于提高数据直观性，明确表达数据之间的变量的关系具有重要作用。而对于既需要分析数据变量，又需要展示数据详情的需求，则可以使用图表+列表的形式展现。

9.总结

业务系统为满足业务需要而产生，产品目标明确单一。但分析深藏在业务需求表面的潜在核心需求同样非常重要。使用户操作形成完整的闭环，以较少的、符合用户习惯的操作实现业务需求，并有效控制开发成本的设计，就是合理的设计。

作者：张骞（微信号zhangqian9208），开创集团产品经理。一年产品工作经验，曾负责山东省数字粮库业务管理系统的交互设计和山东省粮食流通管理云平台产品设计。

关键字：产品经理, 业务系统, 产品设计, 权限

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！