最近在梳理一个 SAP S/4HANA 系统的权限设计时，我又一次碰到一个很典型的问题。业务顾问说某个采购员登录系统后看不到对应菜单，Basis 同事看了 SU01 以后发现用户确实有角色，开发同事又在调试里看到 AUTHORITY-CHECK 返回 sy-subrc 等于 4。几个人围着同一个问题转了半天，表面看是一个权限报错，往深处看，其实是用户主数据、角色菜单、授权对象、授权字段、Profile Generator 和应用程序里的授权检查没有被放在同一张图里理解。
SAP ABAP 平台的用户与角色管理，核心目标并不复杂，就是管理 ABAP 系统里的 user、role 和 authorization。真正容易出问题的地方，是很多团队把它当成一个纯 Basis 操作，认为 SU01 里塞几个角色就结束了。实际项目里，角色既影响用户登录以后能看到什么菜单，也决定用户在某个事务、报表、OData 服务、RAP 行为、RFC 函数或后台程序里能执行哪些动作。菜单只是门牌号，授权才是门锁和钥匙，两者经常一起出现，但不能混为一谈。
角色不是给某一个人设计的，而是给一类工作设计的
在 ABAP 系统里，role 的设计对象不是某个具体用户，而是一个抽象的用户群体。这个说法在项目里特别重要。一个采购员、一个销售订单专员、一个财务过账人员、一个主数据维护人员，他们每天处理的业务对象不同，操作范围不同，数据责任也不同。权限设计如果直接围绕个人来做，很快就会变成不可维护的泥潭。
更合理的做法，是围绕岗位、业务流程和组织边界来设计角色。比如采购部门里可以有采购申请创建人员、采购订单审批人员、供应商主数据维护人员、采购分析报表查看人员。这些角色背后对应的是职责，而不是张三李四。等角色设计稳
