前 言
任何多用户的系统不可避免的涉及到权限问题，系统的使用者越多、使用者本身的社会属性或分工越复杂，权限问题也就越复杂，SAP系统就是典型的一个多用户、多任务的系统。SAP作为一款企业管理软件，在企业管理领域取得了巨大的成功，这主要是因为SAP把先进的管理思想融入到软件产品内，以及软件本身具有的先进的设计架构，可以配置的业务模式，几乎无所不在的管理内容等，当然同它完善的权限管理功能也是分不开的。但是，我们几乎可以在所有使用了SAP管理软件的企业中找到这样一个共同的现象：在上线之后随着公司业务的不断重组、用户工作岗位的频繁变动、岗位职责的扩大与组合等都需要相应的对相应用户的SAP权限作出调整，这时候权限申请人员的疑问就出来了，这个用户本身有哪些权限？这个权限用户可以申请吗？申请这个权限同以前的权限有没有冲突的地方了？，申请这个权限需要得到哪些人员的审批？等等。
本文不是一个从技术角度来阐述SAP权限管理的文章，而是从制度、从管理、从方案的角度来解决SAP项目在上线后全面的权限管理问题的解决方案。
二、SAP权限实现的原理
上图列出了SAP权限管理用到的几个关键的概念。直观的说，权限就是“某人能干某事”和“某人不能干某事”的控制 。在SAP系统中，用事务码（也称交易代码、或者TCODE、或者Transaction Code）表示一个用户能干的事情。比如MM01这个TCODE是用来维护物料数据的、MIGO是用来收货的、CS01是用来维护BOM的等。
用SU01新建一个ID时，默认的权限是空白，即这个新建的ID不能做任何事情，不能使用任何事务代码。这样只需要为相应的ID赋上相应的TCODE，即可实现“某人能干某事”了，其补集，则是“某人不能干的某些事”。
但是我们不能直接在SU01里面给某个ID赋上TCODE，要通过ROLE中转一下。即：一堆TCODE组成了一个ROLE，然后把这个ROLE分给某个ID，然后这个ID就得到一堆TCODE了。
上面这些，仅仅是SAP权限控制的初级概念，要理解SAP权限控制的全部，必须还要明白下面的概念。
1、角色（ROLE）、复合角色
上面讲了，角色，即ROLE，是一堆TCODE的集合，当然还包含有TCODE必备的“权限对象”、“权限字段”、“允许的操作”及“允许的值”等。我们使用PFCG来维护角色。一个复合角色可以包含多个单个的角色。
具体请看下面的概念。
2、权限对象（Authorization Object）、权限字段（Authorization Field）、允许的操作（Activity）、允许的值（Field Value）
上文粗略说了构成ROLE的是若干TCODE。其实，在ROLE和TCODE之间，还有一个中间概念“权限对象”：角色包含了若干权限对象，在透明表AGR_1250中有存储二者之间的关系；
权限对象包含了若干权限字段、允许的操作和允许的值，在透明表AGR_1251中体现了ROLE/Object/Field/Value之间的关系；
有一个特殊的权限对象用来包含了若干事务码。这个权限对象叫“S_TCODE”，该权限对象的权限字段叫“TCD”，该字段允许的值（Field Value）存放的就是事务代码；
有一种特殊的权限字段用来表示可以针对该权限对象做哪些操作，是允许创建、修改、显示、删除或者其他呢。该权限字段叫“ACTVT”，该字段允许的值（Field Value）存放的就是允许操作的代码，01代表创建、02代表修改、03代表显示等；
SAP的权限控制是控制到字段级的，换句话说，其权限控制机制可以检查你是否有权限维护某张透明表的某一个字段。
SAP系统自带了若干权限对象、默认控制了若干权限字段（对应到透明表的某些字段）。可以用事务码SU20来查看系统有哪些权限字段，用SU21来查看系统有哪些默认的权限对象。
于是我们知道了事务代码与权限对象的区别。从权限控制的范畴来看，事务代码属于一种特殊的权限对象；一个事务代码在执行过程中，为了判断某个ID是否有权限执行此事务代码，还可能检查其他若干普通的权限对象。使用SU22来查看某个事务代码包含了哪些权限对象。在透明表USOBX中，存放了事务码与权限对象的对应关系。
3、自定义权限对象
上文所说的系统自带权限对象与权限字段仅能满足有限的需要，其权限审核的逻辑也是系统硬编码了的，我们能做的只是是否启用某项权限对象的检查（使用SU22）。如果需要自定义，通过SU20、SU21定义即可。三、如何有效的进行权限管理
从上图我们可以看到，在整个SAP的实施过程中，用户与权限管理是开始在项目实施的第三阶段即系统实现阶段，之后在上线前准备、上线及上线支持阶段权限管理也是贯穿始终的，权限管理是实施过程中非常重要的一环。权限管理的重要性大家基本上都能够认识到了，那么如何才能在实施阶段就为整个项目的权限管理打下一个良好的基础呢？，简而言之我这里总结了一个口诀如下:
一个《岗位说明书》
一个事务代码清单
一个申请流程
一个不要
二方面的培训
三个权限表格
一个权限一致性检查平台
2.1、一个《岗位说明书》
一个《岗位说明书》是指每个业务部门必须提供出该部门下面不同岗位的具体描述的文件，这个文件大部分的企业应当都是已经具备的，对于有一些企业没有这个文件的我们一定要求整理出来，这个文件是太重要了，系统内用户的权限设置的基础就是这个岗位说明书，同时各个角色的设置也需要参照这个岗位说明书。2.2、一个事务代码清单
所属模块 业务 事务代码 事务代码描述 审批责任人MM 主数据 MM01 创建物料 张锋
MM02 更改物料 张锋
MM03 显示物料 张锋
MM06 删除物料 张锋
ME11 创建信息记录 李林
ME12 更改信息记录 李林
ME13 显示信息记录 李林
ME15 删除信息记录 李林
采购 ME21N 创建采购订单 王斌
ME22N 更改采购订单 王斌
ME23N 显示采购订单 王斌
ME51N 创建采购申请 王斌
ME52N 更改采购申请 王斌
ME53N 显示采购申请 王斌
ME57 分配并处理采购申请 王斌
ME58 分配的采购订单 王斌
ME59N 采购订单自动生成 王斌
这个清单用户记录公司目前用到的最新的事务代码清单，它除了列出事务代码的范围之外，还有每一个事务代码的审批责任人，通过这样的设置在上线后用户/角色需要增加新的事务代码时就能够知道需要经过谁的审批，这样就解决了在前言所提到的“申请这个权限需要得到哪些人员的审批？”的问题。
这个清单是一个动态的清单，在项目的实施期间一般都能够保持对这个清单的实时更新，但是在项目上线之后往往就会忽视了对它的更新，日积月累之后再回过头去看这个清单我们会发现已经与系统内实际的清单相差甚远了，那这个清单也就失去了它应有的意义了。
专人负责，实时更新。
这个是对这个清单维护的基本要求，一个准确的公司目前用到的事务代码清单对于后续的培训、申请、审批工作是至关重要的。
2.3、一个申请流程
公 司 申请部门 申请人 联系电话申请日期 部门审批 系统配置者 配置日期
权限明细表
用 户 岗位名称 系统用户名 角 色 事务代码 功能描述 权限字段值 权限所有者审批
备 注
VF23 发票清单 显示
上面是一个权限申请的示例表格，各个公司的格式及申请流程可能不尽一样，但是权限的审批流程基本内容应当是都需要保留的。
（1）、权限的申请流程必须形成一个闭环，由用户填写申请表格开始经过审批到最后在系统内维护完毕，通知到申请者结束。
（2）、权限的申请必须要得到该权限的负责人审批，如果是事务代码的申请，需要得到该事务码负责人的审批；如果是角色的申请，需要得到该角色负责人的审批。
（3）、不仅仅是新增权限需要审批，更改、删除权限也需要审批。
（4）、BASIS人员在系统内的一切权限操作以此文件为依据，这些申请文件需要妥善保存，因为IT稽核的时候会用到。
2.4、一个不要
用户的权限分配尽可能的通过分配角色去达到，反对为每一个用户的维护添加/维护TCODE，这种方式在用户少的时候可能比较方便，但是在用户多了及多年的运行之后弊处多多。2.5、二个培训
我们上面提到的事务代码清单，权限申请流程中，关键用户与权限审批者的角色是相当重要的，他们必须对这个事务代码、SAP权限角色的内容及作用非常清楚，这样最终用户在提需求的时候，关键用户才会知道需要申请哪些角色与事务，权限审批人也才知道用户能不能申请这个权限。各业务范围的关键用户及权限审批人员需要对该表的内容熟练掌握，这样才能保证权限的申请及审批与业务需求真正步调一致，所以对业务关键用户及权限审批人员的培训至关重要
通过这二方面人员的有效培训我们可以解决前言提出的“这个权限用户可以申请吗？”的问题。
2.6、三个权限表格
2.6.1、单一角色维护表格
序号 角色 角色描述 事务码 事务码描述 权限对象控制 角色负责人1 ZSP_CN30_MM_DISPVNDR 供应商查询 XK03 Display vendor
2 ZSP_CN30_MM_VENDOR_STD 供应商维护 XK01 集中创建 Account group <> C1EM or C2EM
XK02 更改供应商
XK03 显示供应商
MK03 显示采购数据
XK05 冻结供应商
XK06 删除标记供应商
XK07 更改帐户组
MK05 冻结采购数据
MK06 删除标记采购数据
BD14 分发供应商
请注意每个单一角色都是有一个负责人的，这个负责人对这个角色全面负责，包括角色内容的增减、用户对角色权限申请的审批等。
2.6.2、复合角色表
序号 复合角色编号 复合角色描述 单个角色序号 单个角色比编号1 ZCP_CN30_MM_GENREPNOPRICE_PUR MM general display without price(PUR) 20 ZSP_CN30_MM_PUR_GEN_REP_NO_PRI
2 ZCP_CN30_MM_GENREPNOPRICE_IM MM general display without price(IM) 60 ZSP_CN30_MM_IM_GENERAL_REP
64 ZSP_CN30_MM_IM_YPSTKLIST_NO_PR
71 ZSP_CN30_MM_READTX
3 ZCP_CN30_MM_GENREPWIPRICE_PUR MM general display with price(PUR) 21 ZSP_CN30_MM_PUR_GEN_REP_WI_PRICE
78 ZSP_CN30_MM_PR_CONVERTSTATUS
一个复合角色可以包括多个单独的角色，这样可以通过分配一个复合角色给用户而达到与分配多个单独的角色给用户的效果。
2.6.3、岗位表
序号 部门 岗位描述 分配的角色 用户部门 用户1 All 显示带价格的采购订单信息 ZCP_CN30_MM_GENREPNOPRICE_PUR 采购 ZHUANGXX
后勤1 SUNWM
后勤2 YINGHY
2 All 显示不带价格的采购订单信息 ZCP_CN30_MM_GENREPNOPRICE_IM 质量 WANGP
通过岗位表内建立起用户与角色之间的关系。
2.7、用户权限一致性检查平台
这个平台是本文的重点所在，通过它可以解决前言所说的“这个权限用户可以申请吗？申请这个权限同以前的权限有没有冲突的地方了？”等问题。这个平台把企业在日常作业中的一些规范、控制点与具体的角色、事务代码等联系起来，在用户申请权限的时候可以通过这个平台检查有没有一致性错误提示，没有的话就可以申请。
如：采购部门定价的就不能有开订单的权限，创建采购订单的人员就不能收货等。
下面是举例的一些检查规则：
TCODE TCODE 描述
F22 MB1A 输入客户发票/发货
F-22 VF11 输入客户发票/取消发票
F-27 MB1A 输入客户信贷通知/发货
F-27 VF11 输入客户信贷通知/取消发票
F110 F-41 自动付款信息/输入供应商贷项通知
F110 F-42 自动付款信息/输入结转过账
F110 F-43 自动付款信息/输入供应商发票
F110 FB01 自动付款信息/记账凭证
F110 FB50 自动付款信息/输入总帐科目凭证
F110 FB60 自动付款信息/输入供应商发票
F110 FB65 自动付款信息/输入供应商贷项通知
F110 MB01 自动付款信息/对采购订单收货
F110 MB0A 自动付款信息/对采购订单收货
F110 MIGO 自动付款信息/对外部采购的收货
一致性检查库的建立也可以通过2种方式达成：
1、 在SAP系统外建立一致性检查库，当有新的请求的时候手工与一致性库的内容对比，合格则在系统内维护，不合格则退回用户。这种方式实现起来简单，不用额外的开发及成本投入。
2、 在SAP系统内建立起一致性检查库，当申请的时候系统自动从用户权限表内找出用户已经拥有的权限，然后再从一致性检查表内取出检查规则，根据检查规则检查是否合格。
这种方式实现了功能权限检查与SAP原有的权限内容的无缝对接，在维护用户权限的时候自动控制住一致性。
这个平台是一个逐步完善的过程，可以随着企业业务的不断规范而不断完善，每个企业可以拥有自己独有的一致性检查规则。
四、结 语
SAP权限的重要性是毋庸置疑的，但是在项目实施过程中，项目经理往往都不太重视权限，主要的原因是在上线期间以及上线后的短期内负面效果往往体现不出来，突发的权限问题也可以立即处理掉。这样做的后果也是很严重的，可能在一段时间之后SAP系统的权限管理者会忽然发现在不知不觉中权限管理已经变成了无序的状态，各种流程也变成了一种形式。前人栽树、后人乘凉。
在项目的实施过程中投入一点关注，就会为以后系统的健康使用撑起一大片绿荫。
当然，在对于已经上线的企业，从现在开始改善也是为时不晚。
如果本文能够引起大家的共鸣，甚至还能有稍微的那么点启示，那么我将会感到万分的荣幸。 标签：SAP,事务,权限,角色,MM,用户,转载 From： https://www.cnblogs.com/DevilCisco/p/17143121.html