模型化的SAP系统权限管理

IDS Scheer中国副总裁 王磊

SAP系统刚上线时，系统内的权限管理往往并不引起重视。大家关注 更多的是系统能否顺畅运行、数据是否准确，财务帐是否能对得上等等。事实上，此时为了确保系统迅速转起来，给很多用户的权限往往是放大的。几个月后，随着 SAP系统的运行渐渐趋于平稳，系统内部的权限管理问题就慢慢突显出来了。具体表现在以下几个方面：

- 没有一个清晰的授权原则，不能确切的说明为何授权或为何不授权

随着SAP系统运行越来越顺畅，使用者渐渐感受到了系统所带来的价值，于是大家便会要求给自已开通更多的功能。对于系统权限管理人员来说，面对大量增加权 限的申请，究竟是开通还是不开通，似乎并不能找到一个清晰的标准。于是，请部门主管审批便成了一个最为有效的解决方案。只要相关的部门主管认可，IT部门 即予开通。然而，这仅仅是从管理职责上解决了谁负责的问题，并未解决权限管理的本质问题。即开通一个权限或不开通一个权限，是由某一个人来判断有无必要 （不管此人是申请者、权限管理员还是部门主管），还是由某一管理规则来决定。从规范化、科学化和精细化管理的角度来说，当然应该是后者；从风险控制的角度 来说，就更应该是后者了。

事实上，随着SAP这样大集成的系统逐渐被采用，企业运营信息的加工和传递效率确实被极大提高了。但是，任何事务都有两面性，在这种情况下，如果授权不 当，企业运营信息的风险也大大提高了。这种风险主要包括两个方面，一是让更多原本没有必要了解这些信息的员工可随时掌握这些信息，大大增加了泄密的可能 性；二是让原本没有必要操作或加工这些信息的员工拥有了这些权力，增加了管理的失控的可能。

因此，对于实施了SAP系统的企业来说，应建立一套基于业务活动的SAP系统权限管理体系。对于某一位员工来说，究竟应该拥有什么样的权限，取决于其在企 业业务流程体系内所承担的角色及从事的活动。“业务活动驱动”应是判断一个员工是否拥有某一权力的重要原则。“业务活动”的整理可以通过Excel 表的形式来实现，但是事实证明，这样的技术手段很难保证“业务活动”梳理的全面性和准确性，维护起来也较为困难。利用工ARIS建立一套基于业务流程的 “业务活动”模型，是一种较为先进的技术手段。

- 系统权限有被逐渐放大甚至失控的危险

SAP系统内的权限管理是以“角色”这一概念展开的，一个“角色”上分配了体现权力的一组功能（T-Code）及体现限制的授权条件 (Profile)。举一个极端的例子，如果在SAP系统中给每一位员工建立一个角色，并且此角色只分配给一个员工，那么某一角色内的某一个权限的变动也 就不会对他人的权限产生任何影响。但是，一般企业都不会这样做，因为如果员工数量一多，SAP系统中的角色体系就会过于庞杂。而且，一个角色与另一角色之 间的差异可能很小，这会导致数据的冗余变得很大。一般的做法是在SAP中建立一套通用角色、复合角色和单一角色所构成的角色体系来对用户进行授权。也就是 说，一个SAP系统角色可能会分配给多个用户，此时因为某个人的需求而改动某一角色内的权限就可能会影响到此角色所对应的其他用户的权限。即此角色所对应 的所有用户都会同时增大或减少权限。鉴于这种情况，某一用户申请增加权限时，还应告之审批者其在SAP系统中所对应的角色，以及此角色所关联的其他用户， 从而使得行使审批权的主管能够决定是否给这些相关联的其他用户同时增加此权限。事实上，很少有企业能做到这一点。通常的做法是，某用户申请开通某一权限， 主管确认后，系统管理员就在此用户对应的角色上凭经验选一个角色，直接加入此功能。这样，与此角色相关联的其他用户也就自动开通了此功能。一般来说，给用 户增加权限是不会被用户投诉的。久而久之，权限就被逐渐放大了。

要避免上述情况发生，需要有一套模型化的“流程活动驱动“的权限管理体系，通过模型内各要素相互关联的特点，将上述信息全面、自动、准确的提供给审批人员和权限维护人员，而不是靠人工通过Excel 表加系统查询的方式来进行上述权限审批和调整工作。

- 职责分离体系不能被有效建立和执行

企业的权限管理不仅仅是决定谁有权做什么，而且还应体现权力间的相互制约关系。比如“裁判员”同时不能做“运动员”是最为著名的权力制约关系。体现在企业 管理上，也有众多制约关系需要在权限管理中加以考虑。比如，一般来说，进行“客户信用管理”的人不能同时拥有“客户订单维护的”功能。本来，信用管理就是 对于销售订单的一种管控，如果要与信用等级较差的客户签订合同，按规定可能需要经过一系列较为严格的评估和审批。本来信息化系统的优势就是可以及时共享信 息并自动加以锁定，杜绝未经审批而直接给信用等级较差的客户下订单的情况。但是，如果给同一个员工同时授予“客户信用管理”和“客户订单维护”的功能，那 么此员工就可以直接将某一客户的信用从“较差”改为“良好”，从而避开系统的自动锁定而直接给此客户下单。这样的授权就是典型意义上违背了“职责分离”的 原则案例。

类似的“职责分离”原则是很多的，比如在系统内“维护价格清单”的人，不应同时拥有在SAP中“签订客户订单”的权限。有“库存出入库”操作权限的人，不 应拥有“录入盘点结果”的操作功能。“有录入盘点结果”功能的人，不应具有“会计核算”的功能，等等。当然，这些规则有时也不是绝对的，企业可以根据自身 的情况加以调整，有的企业不允许的，另一个企业可能就允许这样授权。也就是说，“职责分离”的粗细，取决于企业内外部风险管控的需要，并没有一个绝对的标 准。但是，不管怎样，每个企业都应建立一套“职责分离”的规则体系，然后根据自身管理需求的发展加以调整。

总之，“职责分离”原则是“业务活动驱动”之外，另一个分析系统授权是否合理的重要原则。这类规则的建立和有效执行，是建立风险控制体系的基础，也是一个 企业管理科学化和精细化的体现。但是，在大多数SAP系统的权限管理中，这套“职责分离”原则是基于Excel 表来设计，同时又靠人工在系统中加以维护的。理论上，某员工申请增加某一功能时，系统管理员应查明此员工申请开通的功能与其现有功能之间是否存在违背“职 责分离”原则的问题。但是，由于某员工在SAP系统中可能同时对应几个角色，因此系统管理员的工作就演变成先查明某员工目前所对应的所有角色，细列出此角 色对应的所有功能，然后再一一核对每一个功能与申请开通的新功能之间是否有违背“职责分离”原则的问题，最后将检查的结果通报给进行审批的主管，供其决策 参考。如果，我们将问题再说得复杂一点，申请开通此新功能的员工所对应的SAP系统角色可能同时赋于了其他员工，因此还要考虑其他员工是否可能因为同时增 加了此新功能，也存在违背“职责分离”原则的问题。这样一来，系统管理员的工作就显得很繁复了。事实上，这样的操作是很难被真正有效地执行的。久而久之， “职责分离”原则在企业的权限管理方面只是名义上存在而已了。

要避免上述情况发生，就需要在模型化的“流程活动驱动”的权限管理体系的基础上，再建立一套模型化的“职责分离体系”，这两套体系模型是相互关联的，并且能全面、自动、准确对授权体系模型进行核查，并出具相关的警示报告，从而解决“职责分离体系”落地的操作性问题。

- 业务蓝图与实际系统“两张皮”的现象愈来愈严重

SAP实施过程中所绘制的业务流程蓝图与实际上线后系统内运行的业务流程往往并不一致。这就好比在设计一间屋子时屋内有一间屋，但当屋子造完住户入住时却 突然发现里面有了两间屋了，更要命的是谁也讲不出为什么。比如，根据业务蓝图进行系统实现时，如果发现需要对蓝图流程进行修正，大家往往会直接在系统中修 改功能，并将此功能的权限赋于相关人员，但并不会同步修正业务蓝图。另外，当SAP系统上线后，企业的管理人员也会根据业务的变化来修改流程。这种修改也 往往直接在系统中进行，没有人会去修改当初的设计稿。久而久之，SAP中的真实流程就成了谁成讲不清楚的黑箱了。这种“黑箱”情况对于系统的运维管理、企 业的内控和风险管理及整体管理体系的建立和维护都会造成极大的影响。

事实上，SAP系统主要是由功能和数据两部分组成。要解决上述问题，系统权限管理和数据管理将是关键所在。如果能完全基于“业务活动驱动”和“职责分离” 这两大模型进行系统的权限管理，同时，“数据管理”流程也能被有效执行，那么就能确保业务蓝图与SAP系统的一致性，从而有效避免“两张皮”的问题。

 http://www.ids-scheer.com.cn/newversion/IndexClassview.asp?vpid=48