动态发布网站和静态发布网站,国内做网站建设最好的公司是,win7 asp网站发布,wordpress 随机数IDS Scheer中国副总裁 王磊 SAP系统刚上线时#xff0c;系统内的权限管理往往并不引起重视。大家关注 更多的是系统能否顺畅运行、数据是否准确#xff0c;财务帐是否能对得上等等。事实上#xff0c;此时为了确保系统迅速转起来#xff0c;给很多用户的权限往往是放大的。… 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?vpid48 转载于:https://www.cnblogs.com/JackSun/archive/2011/11/14/2248975.html