谁该看到什么：定制业务系统中的用户角色与权限

一套新的业务系统周一上线。到了周三，一名初级技术员打开了完整的客户名单，成本价被当着客户的面在柜台报了出来，而报价单上的折扣是谁改的，没有人说得清，因为大家共用同一个“管理员”账号。这一切都不需要黑客，只是因为系统的访问权限从来没有人决定过。

本指南写给打算定制业务系统的老板和经理，也写给已经有系统、却怀疑“太多人能做太多事”的人。它说明谁应该能查看、新建、修改、批准、删除和导出什么，开发前要先决定什么，怎样写进需求文件并测试，以及员工入职、调岗和离职时怎样保持正确。内容是一般性指引，不构成法律意见，也不介绍任何供应商的产品。

为什么“谁能看到什么”是业务决定，而不是技术决定

开发者几乎可以实现您提出的任何权限规则，但他无从知道您的业务需要哪些规则：技术员该不该看到客户的完整地址，分店经理能不能给折扣，会计能不能导出每一张发票。这些问题关乎信任、金钱和习惯。

如果您不回答，结果通常是两个极端之一：人人什么都能做，因为这样开发最快；或者权限卡得太死，员工为了把工作做完只好共用密码。最省钱的决定时机是在纸上，在任何一个界面出现之前。

老板、经理、员工：各个角色通常需要什么

大多数小企业可以从三四个角色开始，只有职责确实不同时才增加。角色是一组挂在职位上的权限，而不是挂在某个人身上；新员工入职时，直接分配角色，而不是另订一套规则。

为什么“最小权限”胜过“人人都是管理员”

最小权限的意思是：每个人只获得工作所需的权限，真正有需要时再加。给所有人管理员权限在第一天看起来省事，因为没有人会被挡住。代价是后来才来的。

• 无心之失会变大。能删除客户记录的人，迟早会删错一条。
• 敏感信息会外流。成本价、利润率、员工薪资和客户电话，最容易随人离开，无论是无意还是有意。
• 责任无从追查。如果人人都能改价格，“是谁改的？”就没有答案。
• 一个密码泄露就全盘失守。账号权力越大，损失越大；拥有管理员权限的离职员工，风险也远高于只有窄权限的人。

最小权限并不是不信任。这和商店把钱箱与保险柜钥匙交给不同的人是一个道理。好员工也因此受到保护，因为谁碰过什么一清二楚。

每类记录都要决定的六个动作

“能进入系统”这个说法太粗了。对每一类记录（客户、报价单、发票、工单、库存、员工档案），分别决定谁可以做下面每一件事：

• 查看。打开并阅读。可以限定为只看自己的记录、本分店的记录，或全部。
• 新建。添加一条新记录。
• 修改。更改已有记录，通常按阶段限制：草稿时可自由修改，批准后锁定。
• 批准。给出最后的同意：折扣、退款、采购、请假。
• 删除。移除记录。作废或归档并写明原因，通常比彻底删除更安全。
• 导出。下载名单或报表。这是最常被遗忘的权限，因为导出的表格会完全脱离系统及其控制。

开发开始之前要决定什么

这些决定现在花一个下午，事后却可能变成一次变更请求。请带着草稿参加第一次沟通；第一次沟通前要准备什么说明了它在流程中的位置。

1. 列出角色。按职位而不是按人命名，用最少的数量反映真正不同的职责。
2. 列出记录。客户、报价单、发票、付款、工单、库存、供应商、员工档案、报表。
3. 填好六个动作，针对每个角色和每类记录。一页表格就够了。
4. 确定范围。全部可见，只限本分店或本部门，还是只限自己创建或被指派的记录？
5. 标出敏感字段。成本价、利润率、员工薪资和客户联系方式，往往需要比所在记录更严格的规则。
6. 制定批准规则。谁批准折扣、退款、贷项通知单或价格变动，额度多少，负责人不在时由谁代批？
7. 指定管理员。谁能添加用户和更改角色，后备人选是谁？
8. 规定离职规则。谁负责取消离职员工的权限，最迟什么时候？

小型服务企业的角色与权限示例

下面是为一家小型维修与保养公司虚构的权限表。它只用来展示格式，并不是对您业务的建议；每个格子都需要您按实际调整。

留意其中的规律：涉及钱的动作被拆成“准备”和“批准”，由不同的人完成；技术员只看到工单所需的内容；会计可以读取和导出，但不能改动运营数据；只有一个角色能管理用户。真实的表格还应写明第二位管理员，下文会谈到。

范围、敏感字段与批准

分店和部门范围。角色只是规则的一半，另一半是它能管多远。分店经理可能只看本店的销售和库存，总部则看全部；销售团队可能只看分配给自己的客户。请为每个角色写明，因为“经理”在单店和多分店公司里含义不同。多个门店的情形可参考多门店管理。

金额、成本和联系方式字段。字段级规则让一个人能打开记录，却看不到其中某些字段。常见的有：成本价和利润率、薪资和奖金、银行资料，以及客户的电话和地址。问一句“哪些字段一旦被带走会让我们吃亏？”，名单很快就出来了。

折扣与退款。用明确的数字定下额度：例如员工不能给任何折扣，经理可以在您定的额度内给，更高的需要老板批准。同样重要的是，任何人都不能批准自己提出的申请；同一个人既发起又批准退款，是最典型的漏洞。报价如何变成发票，可参考报价单转发票自动化。

把它写进需求文件

只存在于谈话中的权限规则，会被遗忘或引起争执。在需求文件中写一个简短的章节，才能被开发、测试和约束：

• 角色清单，每个角色一句话说明，并附上权限表。
• 范围规则用句子写明：“分店经理只能看到所属分店等于自己分店的记录。”
• 字段与批准规则：哪些字段对哪些角色隐藏、批准额度，以及任何人不得批准自己的申请。
• 管理规则：管理员人数、用户如何添加和移除，以及新增角色需要什么。
• 变更条款：以后新增角色属于需报价的变更，所以要先知道费用。这条界线怎么划，请看缺陷与变更请求。

还要确认哪些东西您自己能改。有的系统允许管理员在界面上修改角色，有的每次调整都要找开发者。比较两份定制软件报价之前先问清楚，因为答案会影响未来多年的运行成本。

在用户验收测试中检验角色

大多数验收测试检查人们“能做”某些事。权限测试检查的是人们“不能做”另一些事，这一部分很容易被跳过。请把它放进用户验收测试计划：

1. 每个角色建一个测试用户并逐格检查：凡是标着“无”的格子，都试着去做，确认系统拒绝。
2. 试试“后门”。粘贴一个受限页面的链接，搜索不该看到的客户，打开报表，再试试导出按钮。
3. 测试范围。以分店经理身份登录，确认在搜索或报表中找不到其他分店的记录。
4. 测试批准额度：略低于、恰好等于和高于门槛，并确认没有人能批准自己的申请。
5. 测试生命周期。停用一个用户并确认他无法登录；更改角色并确认新权限生效。
6. 按权限表记录结果，在支付尾款之前补上漏洞。

共用账号，为什么要避免

整个前台共用一个账号很诱人，因为省去了建账号的麻烦。但这样您无法分辨谁做了什么，要移除一个人就必须给所有人改密码，也无法给不同的人不同的权限。每次有人离职都得改密码，而实际上常常被省略。

让每个人有自己的账号，忘记密码就用正规的重置流程解决，而不是共用。如果柜台终端确实需要共用账号，请只限于不敏感的功能，知道密码的人一离职就更换密码，并记下谁持有。系统之外同样适用这条规则：主机方面可参考cPanel 账号安全。

管理员账号：几个，谁来持有

管理员能添加用户、更改角色，往往还能看到一切，所以这是您最有价值的账号。小公司适合三个习惯：

• 管理员要少，但不能只有一个。如果唯一的管理员请假、生病或已离职，没有人能添加新员工或修复被锁的账号。设两位具名管理员，通常是老板加一位可信赖的资深员工，就能避免这种“老板一人把关”的瓶颈。
• 管理员账号与日常工作分开。每位管理员另有一个普通账号用于日常事务。
• 默认不要把管理员权限给开发者。开发方在项目期间和后续支持时可能需要权限，但应当具名、有限、有时限，并以书面约定。系统最终由谁掌控，请看源代码与系统所有权。

请记下谁是管理员、恢复资料存放在哪里，以及紧急时谁可以顶替其中一位。

员工入职、调岗或离职时

权限会慢慢跑偏。有人代班同事的假期，却一直保留额外权限；升职增加了权限，却没人去掉旧的；离职的人被遗忘。围绕这三个时点建立一套小流程。

• 入职：分配标准角色，并记录由谁批准。
• 调岗：替换角色而不是叠加，免得旧权限越积越多。
• 离职：在最后一天或之前取消权限，而不是几周之后。
• 每个季度，复查用户名单：每个人是否仍在公司，每个角色是否仍与职责相符？

系统方面的简短离职清单：

1. 在最后工作日停用账号；如果是不愉快的离开，则更早。停用而不是删除，这样历史记录仍然对应名字。
2. 把他手上未完成的工单、报价单和审批转给指定的人。
3. 更换他知道的共用密码，并把他从共用邮箱中移除。
4. 取消他对关联工具的权限，例如电邮、文件存储和消息群组。
5. 收回他持有的设备和导出文件，并记录日期和经手人。

同样的整理也适用于系统之外。如果离职员工用过数字名片，请看员工离职后数字名片该怎么处理。

权限过松或过紧的迹象

太紧同样有代价：做不成事的人会发明变通办法，例如用电子表格、截图或借用账号，这往往比您想防范的风险更糟。

该问开发者的问题

• 角色是怎么设置的：写死在代码里，还是管理员可以在界面上编辑？
• 权限能否按动作（包括导出）设置，而不只是按页面？
• 能否按分店、部门或“只看自己的记录”限制访问，成本、薪资之类的字段能否隐藏？
• 能否设置批准额度，系统能否阻止一个人批准自己的申请？
• 用户如何添加、停用和移除，停用后是否保留其历史记录？
• 不通过开发者，能否自行创建第二位管理员？
• 上线后开发者自己会保留哪些权限，又如何记录？

含糊的回答本身就是信息：做过权限规则的开发者，回答又快又直白。

补充一点：审计记录与备份

角色决定谁被允许操作。另外两项相关的保障，即谁在何时做了什么的记录，以及经过测试、能挽回失误的备份，值得另写一篇指南。目前，请先把这两项列入您要问开发者的问题清单。

验收签字前的检查清单

• 角色按职位命名，需求文件里附有六个动作的权限表。
• 每个角色的范围已写明，敏感字段在需要处已隐藏。
• 批准额度已写下来，且不得自批。
• 没有共用账号；两位具名管理员，各自另有日常账号。
• 权限表中每个“无”都在验收中测试过。
• 有入职、调岗和离职流程，定好季度复查日期，并记录开发者自己的权限。

常见错误

• 开发完成后才决定角色。事后补加权限比提前规划更贵。
• 忘了导出。受限的名单，一旦有人能下载就不再受限。
• 只测试人们能做什么。漏洞恰恰藏在标着“无”的格子里。
• 删除离职员工的账号。历史记录会失去名字；应当停用。
• 让老板成为唯一的管理员。这会造成瓶颈。

Gotka Technologies 的角色

Gotka 的应用与系统开发服务可开发手机应用、网络应用和业务系统，网络应用和仪表板起价 RM8,000，业务系统和系统对接起价 RM12,000，手机应用起价 RM15,000（均为参考起价），待需求明确后以书面报价为准。本指南属一般性建议，并不介绍 Gotka 系统的任何角色、权限或安全功能，因此请要求任何供应商（包括 Gotka）把他们将要实现的访问规则写成书面。面向客户的一面，请看服务型企业的客户门户；各角色在报表里看到什么，请看业务仪表板与报表；员工记录请看考勤、请假与报销；如果要迁入旧记录，请看数据迁移。欢迎通过联系页面与我们团队联系。

本指南中的关键术语

• 角色：挂在职位上的一组权限，例如经理或技术员。
• 权限：某个角色可以做的具体事情，例如查看、新建、修改、批准、删除或导出。
• 最小权限：每个人只获得工作所需的权限。
• 管理员：可以添加用户和更改角色、往往能看到一切的账号。
• 范围：角色覆盖的广度，例如全部记录、一家分店或仅限自己的记录。
• 字段级权限：对能打开记录的角色隐藏成本价之类的字段。
• 职责分离：一个人准备，另一个人批准。