蓦然回首，从事产品经理差不多一年光景，期间曾作为产品负责人完成了两个业务平台的整体规划工作。因此总结两个项目的经验，希望能起到抛砖的作用。
业务系统的本质需求是满足前台维护或工作需要，因此，严谨的业务流程实现和较少的操作步骤，是业务系统应该具备的基本特点。
完整的业务系统，应该涵盖如下内容：
由于业务系统本身是为满足用户的工作需要，因此用户管理、权限分配、工作流毫无疑问占据核心地位。
与前端产品不同，业务系统往往基于复杂的数据流和业务逻辑，这就要求产品经理提供详细完整的业务流程图和PRD。接下来作者就一些常见模块设计做简要说明，有纰漏之处还请各位大牛批评指正。
1.用户管理
平台的设计最终是为了服务于用户。
1.1用户登录名
业务系统不同于社交APP和论坛，用户名往往是严肃准确的。而由于用户同名的几率太大，使用姓名作为登录名显然是不太合适的，常见的业务系统或后台登录名如下：
姓名（拼音）+编号：如zhangsan，zhangsan1；
优点：用户名命名规则简单，完全避免了同名问题；
缺点：命名需自动生成或由管理员负责，行政领导使用时可能不合适；
身份证号：
优点：完全杜绝重复，用户名较严肃；
缺点：若用户年龄群体较大，记忆和输入身份证号不利于提高用体验；
手机号码：
优点：便于记忆；
缺点：手机号更换较麻烦，不适用于较严肃的业务系统；
工号/单位内个人编号：
优点：严肃、避免重复；
缺点：记忆不便、适用范围较窄（不适用于无工号的单位）；
除此之外，其余能够标记用户唯一性的方式均可使用，但应严谨、严肃，不宜出现个性化因素，如昵称等。
1.2用户来源
常见的业务系统用户往往来源于管理员主动添加。在用户较多且不便导入或其他使用者特殊需求情况下，可能存在用户自行注册的情况。
由管理员添加：较常见。管理员添加用户并为用户关联权限信息，此时用户即可正常使用系统；
用户自行注册：用户注册可能存在冒名顶替现象，需身份验证环节。验证审核与授权工作在交互上可同时完成。
1.3用户安全
业务系统涉及到使用者业务流程、重要数据等，因此对安全要求较高，除常见的密码、验证码等方式之外，有可能借助其他加密方式，如UKEY、数字证书等。
2.权限管理
权限管理决定了哪些用户可以使用什么功能，完成什么操作，对什么数据进行操作，是业务系统中的重中之重。
2.1功能权限
功能权限决定了用户能看到多少菜单，能访问哪个页面，能操作哪些按钮。业务系统的权限往往能够精确到页面中甚至弹窗中的按钮，而普通的内容后台则往往不需要多此一举。
常见的功能权限的控制主要有以下几类：
2.1.1角色控制
角色是功能权限的集合。之所以放在第一个，是因为该方法是在业务系统中最常见的、操作简便的功能权限控制方式。
实际应用中，引入角色概念，建立某个角色，并关联若干功能点。此时将角色关联到用户下，即可赋予该用户不同角色权限的并集。
角色权限控制适用于使用者权限具有典型性、普遍性的状况，可以避免重复对具体功能权限进行重复操作，能极大提高管理员效率。因此，在部门、岗位划分明确的状况下一般使用该方式。
2.1.2岗位控制
岗位控制的前提是存在明确组织结构管理，并通过相应的岗位与员工一一对应。岗位本质上与角色一样是功能权限的集合。
通常情况下，岗位管理属于人事管理范畴而非系统管理，因此通过岗位关联权限的做法，在系统内存在人事模块时，会混淆人事管理和系统管理的概念。
2.1.3直接关联
对于单位内人员较少，人员分工较不明确的单位，也存在将人员直接关联功能权限的设计。该做法仅仅适用于较小范围内、不同人员权限差异较大的情况下使用。
跨单位功能权限多用于存在较多分公司、事业部、分支机构、下属单位等情况的大型业务平台。不同单位的功能权限有所区别。
这就要求存在一个超越所有单位的超级管理员，对不同单位授权以作为单位的最大权限。各单位管理员基于单位权限对单位内用户进行权限分配。
引入单位角色概念：首先由超级管理员建立单位角色，将单位关联角色。此时，单位基于单位角色作为单位的最大权限，对用户进行详细的权限划分；
使用单位类型区别单位的功能权限：与单位角色在授权方式上并无本质区别，但单位类型可能作为单位查询的统计口径之一，未必能够完全兼顾权限，灵活度较差；
将单位直接关联功能权限：简单粗暴，灵活性较强，适用于单位较少的情况。
2.2数据权限
数据权限决定了不同用户在同一页面上能够看到的数据的不同，能看哪些数据，不能看哪些数。在部门或不同单位职权划分明确、或者不同性质单位使用同一系统时，数据权限的区分至关重要。
数据权限与功能权限共同组成系统的权限控制，是业务系统不可或缺的一部分。
通过单位类型限制：适用于存在多种类型单位的大型平台使用。不同类型的单位需要使用到的数据不同，因此使用单位类型进行限制是较合理的方式；
通过权限级别限制：适用于存在多级别单位的平台，通常与单位类型控制混合使用。例如县级行政单位使用本县所有数据，市级行政单位则使用本是区域内（市直单位、县区）的所有数据；
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.总结
业务系统为满足业务需要而产生，产品目标明确单一。但分析深藏在业务需求表面的潜在核心需求同样非常重要。使用户操作形成完整的闭环，以较少的、符合用户习惯的操作实现业务需求，并有效控制开发成本的设计，就是合理的设计。
