SAP 系统刚上线时,您关注较多的可能是系统能否顺畅运行、数据是否准确,财务帐是否能对得上等等,对于系统内的权限管理问题,可能您关注得并不多。事实上,随着SAP这样大集成系统的上线运行,企业运营信息的储存、加工和传递效率被极大地提高了。但是,任何事务都是有两面性的,实时性和集成性增加的同时也会加大企业运营的风险。这种风险主要体现在两个方面,一是如果授权不当,员工获取企业运营信息的深度和广度可能会远远超过其工作所需的范围,这会大大增加泄密的可能性;二是一旦授权不当,让原本没有必要操作或加工这些信息的员工拥有了这些权力,就会大大增加管理失控的风险性。
因此,我们建议您关注一下SAP系统的权限管理问题,因为这绝对不是一个IT问题,而是一个跨部门、跨流程的重要的企业管理问题。在认真分析了您企业的SAP权限管理体系后,如果您发现存在如下问题,那么您的企业可能就需要实施一套SAP权限管理的解决方案了。
没有一套清晰且明确的授权规则
随着SAP系统运行越来越顺畅,使用者渐渐感受到了系统所带来的价值,于是大家便会要求给自已开通各种功能并增加相应的权限。而对于IT部门的系统权限管理人员来说,面对大量的申请,似乎并不能找到一个清晰且明确的标准。于是,请部门主管审批便成了一个最为有效的解决方案。只要相关的部门主管认可,IT部门即予开通。然而,这仅仅是从管理职责上解决了谁负责的问题,并未解决权限管理的本质问题。即给某员工开通一个权限或不开通一个权限,是由某一个人来判断,还是由一套规则来决定。无论是从规范化、科学化和精细化管理的角度来说,还是从风险控制的角度来说,授权体系的管理肯定是上述两者的结合,光有前者是远远不够的。
对于实施了SAP系统的企业来说,应先建立一套基于业务活动的SAP系统权限管理规则。对于某一位员工来说,究竟应该拥有什么样的权限,首先应取决于其在企业业务流程中所承担的角色及从事的活动。“业务活动驱动”应是判断一个员工是否拥有某一权力及对此权力应有怎样的限制条件的重要规则。基于上述规则,再辅之以人工的授权审批流程,才是一套科学的权限管理体系。
其实,即使先从“授权审批流程”的角度来建立权限管理体系,最终也还是需要建立一套“规则”与之相适应。比如,如果将权限的审批权交给各部门的主管,那么随之而来的问题就是部门主管“审批”的权限有多大?是否一个部门内的员工申请开通任何一个权限,只要部门主管同意即可?比如,某采购部门的员工要求开通一个与财务相关的权限,只否只要采购部门的主管同意即可?答案当然是否定的。于是便需要事先进行一系列的“授权规则”的定义。比如,定义某些权限,所有员工都可以拥有;某些权限,只要是某部门的员工都可以拥有;某些权限,只要是某岗位的员工都可以拥有;这样就省去了大部分的审批工作。对于除上述规则之外的需求,则需要事先定义哪些权限由哪个部门主管进行审批,哪些权限需要跨部门进行审批,等等。上述步骤完成后,就会发现最终还是建立了一套由“业务活动驱动”的授权体系,因为要完成上述工作,首先还是要搞清楚具体的员工、岗位和部门所从事的活动。
用户权限有被逐渐放大甚至失控的危险
SAP系统内的权限管理是以“角色”这一概念展开的,一个“角色”上分配了体现权力的一组功能 (T-Code) 及体现限制的授权条件 (profile)。举一个极端的例子,如果在SAP系统中给每一位员工建立一个角色,并且此角色只分配给一个员工,那么某一角色内的某一个权限的变动也就不会对他人的权限产生任何影响。但是,一般企业都不会这样做,因为如果员工数量一多,SAP系统中的角色体系就会过于庞杂。而且,一个角色与另一角色之间的差异可能很小,这会导致数据的冗余变得很大。一般的做法是在SAP中建立一套通用角色、复合角色和单一角色所构成的角色体系来进行授权。也就是说,一个SAP系统角色可能会分配给多个SAP用户,此时因为某个人的需求而改动某一角色内的权限就可能会影响到此角色所对应的其他人的权限。即此角色所对应的所有用户都会同时增大或减少权限。鉴于这种情况,某一用户申请增加权限时,还应告之审批者其在SAP系统中所对应的角色,以及此角色所关联的其他用户,从而使得行使审批权的主管能够决定是否给这些相关联的其他用户同时增加此权限。事实上,很少有企业能做到这一点。通常的做法是,某用户申请开通某一权限,主管确认后,系统管理员就在此用户对应的角色上凭经验选一个角色,直接加入此功能。这样,与此角色相关联的其他用户也就自动开通了此功能。一般来说,给用户增加权限是不会被投诉的。久而久之,权限就被逐渐放大了。
曾经有个企业在SAP系统运行半年后,对系统内的用户权限进行内控检查时就发现某用户的操作权限可以删除另外一个用户的凭证;一家分公司的用户可以看见多家分公司的往来单位和帐目;员工在填报报销申请时,甚至可以看到公司领导的报销明细。
要避免上述情况发生,需要有一套模型化的“流程活动驱动”的权限管理体系,能细致地定义各类权限,实现权限管理的精细化。同时,这套模型应能全面、自动、准确的检查这些精细化的授权是否真正被执行,即通过“工具和机制”而不是仅仅靠“人”来保证授权的科学。
职责分离体系不能被有效建立和执行
企业的权限管理不仅仅是决定谁有权做什么,而且还体现了权力间的相互制约关系。比如“裁判员”同时不能做“运动员”是最为著名的权力制约关系。体现在企业管理上,也有众多制约关系需要在权限管理中加以考虑。举个例子,进行“客户信用管理”的人应该不能同时拥有“客户订单维护的”功能。本来,信用管理就是对于销售订单的一种管控,如果要同信用等级较弱的客户签订合同,按规定可能需要经过一系列较为严格的评估和审批。ERP系统的优势就是可以及时共享信息并自动加以锁定,杜绝未经审批而直接给信用等级较差的客户下单的情况。但是,如果给同一个人“客户信用管理”和“客户订单维护”的功能,那么此人就可以直接将某一客户的信用从“较差”改为“良好”,从而避开系统的自动锁定而直接给此客户下单。这样的授权就是典型意义上违背了“职责分离”原则的情况。
类似的“职责分离”原则是很多的,比如在系统内“维护价格清单”的人,不应同时拥有在SAP中“签订客户订单”的权限。有“库存出入库”操作权限的人,不应同时拥有“录入盘点结果”的操作功能。“有录入盘点结果”功能的人,不应同时具有“会计核算”的操作功能,等等。当然,这些规则有时也不是绝对的,企业可以根据自身的情况加以调整,有的企业不允许的,另一个企业可能就允许这样授权。也就是说,“职责分离”的粗细,取决于企业内外部风险管控的需要,并没有一个绝对的标准。但是,不管怎样,每个企业都应建立一套“职责分离”的规则体系,然后根据自身管理需求的发展加以调整。
总之,“职责分离”的规则是“业务活动驱动”之外,另一个分析系统授权是否合理的重要规则。这类规则的建立和有效执行,是建立风险控制体系的基础,也是一个企业管理科学化和精细化的体现。
但是,在大多数SAP系统的权限管理中,这套“职责分离”原则是基于Excel 表来设计,同时又靠人工在系统中加以维护的。理论上,某员工申请增加某一功能时,系统管理员应查明此员工申请开通的功能与其现有功能之间是否存在违背“职责分离”原则的问题。但是,由于某员工在SAP系统中可能同时对应几个角色,因此系统管理员的工作就演变成先查明某员工目前所对应的所有角色,细列出此角色对应的所有功能,然后再一一核对每一个功能与申请开通的新功能之间是否有违背“职责分离”原则的问题,最后将检查的结果通报给进行审批的主管,供其决策参考。如果,我们将问题再说得复杂一点,申请开通此新功能的员工所对应的SAP系统角色可能同时赋于了其他员工,因此还要考虑其他员工是否可以同时增加此新功能,是否也存在违背“职责分离”原则的问题。这样一来,系统管理员的工作就显得很繁复了。事实上,这样的操作是很难被真正有效地执行的。久而久之,“职责分离”原则在系统的权限管理方面只是名义上存在而已了。
要避免上述情况发生,在模型化的“流程活动驱动”的权限管理体系的基础上,还需要建立一套模型化的“职责分离体系”,这套模型体系应能全面、自动、准确地对授权体系模型进行检查,并出具相关的警示报告,从而解决“职责分离体系”的“落地”问题。
业务蓝图与实际系统“两张皮”的现象愈来愈严重
SAP实施过程中所绘制的业务流程蓝图与实际上线后系统内运行的业务流程往往并不一致。这就好比在设计一间屋子时屋内有一间屋,但当屋子造完住户入住时却突然发现里面有了两间屋了,更要命的是谁也讲不出为什么。比如,根据业务蓝图进行系统实现时,如果发现需要对蓝图流程进行修正,大家往往会直接在系统中修改功能,并将此功能的权限赋于相关人员,但并不会同步修正业务蓝图。另外,当ERP系统上线后,企业的管理人员也会根据业务的变化来修改流程。这种修改也往往直接在系统中进行,没有人会去修改当初的设计稿。久而久之,ERP中的真实流程就成了谁也讲不清楚的“黑箱”了。这种“黑箱”情况对于系统的运维管理、企业的内控和风险管理及企业整体管理体系的建立和维护都会造成极大的问题。 事实上,ERP系统主要是由功能加数据两部分组成。要解决上述问题,系统权限管理和主数据管理将是关键所在。如果能完全基于“业务活动驱动”和“职责分离”这两大原则进行系统的权限管理,同时,“主数据管理”的流程也能被有效执行,那么就能确保业务蓝图中的流程与SAP系统中流程的一致性,从而有效避免“两张皮”的问题。
针对上述四个方面的问题, ARIS及在SAP项目实施过程中积累的大量经验,研发了一套SAP权限管理解决方案,此方案可以帮助您的企业有效地解决上述权限管理的相关问题,并为进而建立流程管理平台打下坚实基础。