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

案例 | 作为产品经理，我是这样设计业务系统的 蓦然回首，从事产品经理差不多一年光景，期间曾作为产品负责人完成了两个业务平台的整 体规划工作。因此总结两个项目的经验，希望能起到抛砖的作用。 业务系统的本质需求是满足前台维护或工作需要，因此，严谨的业务流程实现和较少的操作步骤， 是业务系统应该具备的基本特点。 完整的业务系统，应该涵盖如下内容： 由于业务系统本身是为满足用户的工作需要，因此用户管理、权限分配、工作流毫无疑问占据核心 地位。 与前端产品不同，业务系统往往基于复杂的数据流和业务逻辑，这就要求产品经理提供详细完整的 业务流程图和 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.1.4跨单位功能权限 跨单位功能权限多用于存在较多分公司、事业部、分支机构、下属单位等情况的大型业务平台。不 同单位的功能权限有所区别。 这就要求存在一个超越所有单位的超级管理员，对不同单位授权以作为单位的最大权限。各单位管 理员基于单位权限对单位内用户进行权限分配。 常见的跨单位功能权限处理方式如下： 2.2 数据权限 数据权限决定了不同用户在同一页面上能够看到的数据的不同，能看哪些数据，不能看哪些数。在 部门或不同单位职权划分明确、或者不同性质单位使用同一系统时，数据权限的区分至关重要。 数据权限与功能权限共同组成系统的权限控制，是业务系统不可或缺的一部分。 2.2.1单位数据权限 同功能权限一样，数据权限首先要定义单位的最大数据权限： 通过单位类型限制：适用于存在多种类型单位的大型平台使用。不同类型的单位需要使用到的数据 不同，因此使用单位类型进行限制是较合理的方式； 通过权限级别限制：适用于存在多级别单位的平台，通常与单位类型控制混合使用。例如县级行政 单位使用本县所有数据，市级行政单位则使用本是区域内（市直单位、县区）的所有数据； 2.2.2用户数据权限 单位数据权限确定之后，就要为不同用户分配权限，不同级别、不同部门、不同岗位的用户需要使 用的数据往往是不同的。而对用户限制数据，通常与权限控制类似： 部门 / 岗位/ 角色控制：不同部门、岗位