本人2001年至今一直从事basis工作，曾经是erphome-basis版主之一，管理过多个500人以上的sap系统N年。

自创BASIS终极授权の内部顾问参数文件的产生：https://github.com/basis100/SAPauthor

其中包括在10万个事务代码中，把BASIS的几个TC和SPRO按分段剔除出来，帮助快速准确完成关键用户的参数授权程序:

https://blog.csdn.net/ot512csdn/article/details/103185533

 

关于运维阶段出现大量修改权限需求的若干问题：

一、建设阶段，建设和运维，ERP项目基本会分为的2大的阶段。项目启动至上线正式运行为建设阶段，这个阶段一般是由乙方实施公司主导完成。外部顾问会全权参与用户权限的设定。SAP系统中的权限会被外部顾问设计成用户名---角色（岗位）---事务代码。 这个阶段外部顾问会根据公司部门，岗位把事务代码按组分好，最后加给用户。因为系统是新建，用户-角色-事务代码关系也是新建，用户还未大量完整的使用权限，项目就结束了，对于外部顾问，不会有什么问题。

二、运维阶段，ERP系统正真运维阶段，是内部顾问和业务部门用户全部完整的参与阶段，这个时候之前的设计就可能遇到问题：

1、 减少事务代码的时候，出现问题：

一个角色，包含三个事务代码A、B、C，之前付给了5个用户，这5个用户都有A、B、C三个事务代码。某天，业务部门提出有一个用户，她改变了工作事务，她只需要一个事务代码，请basis拿掉其它两个不需要的事务代码，这个做法只有把用户的原来角色去掉，新建一个角色（只包含一个事务代码），加给这个用户，这时候新的角色（岗位）产生了，内部顾问需要记录这个角色，并且清楚这个角色的使用范围。 但是这样的需求会有很多，角色因为事务代码偏差开始大量增加，而出现一个用户使用多个角色需要变更再涉及到后面的权限对象，就很难理清了。所以有人说脏活累活属于basis.

 

2、表现为业务部门需求提出后，内部顾问是否改变原需求：

在增加事务代码上，内部顾问很可能改变原需求。某日，一个用户提出她需要MIGO这个事务代码，需求送递到MM内部顾问一看，如果给这个用户所拥有的角色只增加MIGO，这个角色又可能被其它用户所共用的，其它用户就也会有MIGO，这是不行的。MM内部顾问就很可能在已经有的角色中寻找，他发现了一个库管员的角色，里面包含有MIGO，他就会让basis把这个库管员角色加个这个用户。但是，这个库管员角色可能包含不止一个MIGO，它可能还包含MB51，用户没有提这样的需求，但她有了MB51。当然MM的地盘一定是MM内部顾问做主，但是这同原来用户的提出的需求并不一致，这个弊端说轻一点是不够严谨，说重一点权限审计的时候可能过不了，再重一点如果用户用她没有申请的权限做了出格的事情，追查责任的时候都会有。

出于上面的困扰，我在一个系统中曾使用过基于用户的权限设计，就是一个人一个角色, 角色不按岗位来而按人头来，其实就是弱化角色这一层，让整个权限只有用户和事物代码。这样的模型就同业务部门用户脑子里的一致了，他们按用户--事务代码来提权限，没问题。 但这样消除了共用角色，basis的工作量又会加大，不过权限清单拖出来的报表绝对是清晰的,和需求一致的。

 

3、问题的本质：

内部顾问基于之前的角色（岗位）来管理SAP权限，而业务部门用户压根不知道有角色这个东西，他们只知道用户名和事务代码，他们提出的需求，都是用户-事务代码这两块，他们的脑子里就只有用户和事务代码表，所以因为信息不对称，就会出现矛盾。

 

 

SAP权限管理的一个审计痛处：没有带数据的流程管理 （2017.7.10续）

SAP系统内权限的变更，来源于外部的变更申请，OA系统内的一次工作流程或纸质的签字文档，这个文档一般包含，业务用户提出申请、业务部门领导签字、ERP内部顾问、ERP项目经理签字。但是这个文档中，没有出现完整的事务代码，比如某天，给某五个用户加了若干事务代码这样的数据。

用户管理员按流程要求，在SAP系统中实施变更，但具体内容（事务代码）可能并没有完全包含在流程中，这种变更是很多的，日积月累后，可能堆了一大箱子，如果是OA流程可能走了成百上千个。某天，审计来了，他想看一个用户的系统内变更，系统外申请凭证，还有这个对应情况（权限管理员有没有乱做）。我认为他的要求是合理的，但是权限管理员可能要累死，他要在之前做过的全部申请中找出该用户的OA流程或纸质申请，而这仅仅是一个用户。

 

问题的本质：SAP有十万个事务代码，需要在线系统包含这些数据，并做到流程中去，这样后续才可用查询。

 

我想到一个解决办法：在SAP系统里面开发一个事务代码，ZSU01（每一次权限管理员在系统维护完用户权限后），把“外部变更号“，“SAP用户名”，“变更日期“保存到SAP系统里。输入变更号，带出用户名，选择用户名，保存。 做好用一点，对权限管理员增加不了多少工作量。但是这样以来，审计要的系统内外的对应关系就很方便的找出了。整个授权过程也是清晰透明可追逆了。

这个想法源于PP模块的BOM变更号管理，SAP呀，为什么对BASIS模块不使用这么好的功能。 这么多SAP的企业，有多少把这个系统内外权限管理做得很清楚的？

 

怎样更清楚的管理SAP用户权限？（2018.6.2续）

基于我的最佳实践，如果按出我的方法，SAP的权限管理其实能够管理得很好，也很轻松：

1、简化系统复杂度：一个用户只有一个角色（还可以在加一个基本角色）。

2、简化维护人员结构：业务用户（提出需求）---> 内部顾问（按模块负责权限维护工作），不要再把BASIS放在中间。

3、严格按照流程：业务用户--业务部门领导--内部顾问--ERP项目经理。

4、BASIS管理内部顾问用户和开发用户。

 

以上4点，第1和第2点尤为重要，

第1点，一个用户只给他一个角色，角色的名字可以同用户同名。不这样做，只会造成事务代码和权限对象大量重复。

第2点，不要再让BASIS来维护用户的权限，如果多了basis这一层，会让内部顾问丢掉对SAP系统内授权情况的掌握。

试想一个MM内部顾问，他一定对物料和采购的业务人员是熟悉和了解的，他再掌握SAP系统内的授权内容，

他自己可以很清晰的比较出权限是否同实际一致。而一般一个企业一个模块用户在100个以内，这100个又正好在

人大脑的处理范围内。所以内部顾问全程参与管理，一定能把SAP系统权限管理得清清楚楚。

 

----------截图时间2021.6.7------------------------------