Modeled SAP system permission management

Wang Lei, vice president of IDS Scheer China

When the SAP system was launched, permission management in the system often did not attract much attention. We are more concerned about whether the system can run smoothly, whether the data is accurate, and whether the financial account can be correct. In fact, in order to ensure that the system is quickly transferred, the permissions granted to many users are often magnified. A few months later, as the operation of the SAP system gradually became stable, the internal permission management issue of the system gradually became apparent. It is embodied in the following aspects: -There is no clear authorization principle and it cannot be used to explain exactly Why or why not. As the SAP system becomes smoother and smoother, users gradually feel the value of the system, so they will ask to activate more functions for themselves. For system permission management personnel, whether to activate or not to activate a large number of applications with more permissions does not seem to have a clear standard. Therefore, asking the department supervisor for approval becomes the most effective solution. Once approved by the relevant department supervisor, the IT department is activated. However, this only solves the problem of who is responsible in terms of management responsibilities, and does not solve the essential problem of permission management. That is, to activate a permission or not to activate a permission, it is up to a person to determine whether this person is necessary (whether this person is an applicant, permission administrator or department director ), it is determined by a certain management rule. From the perspective of standardization, scientific and refined management, it should be the latter; from the perspective of risk control, it should be the latter. As a matter of fact, as SAP is gradually adopted as a large integrated system, the processing and transmission efficiency of enterprise operation information has indeed been greatly improved. However, any transaction has two sides. In this case, if authorization fails, the risk of enterprise operation information is greatly increased. This risk mainly includes two aspects: First, it allows more employees who do not need to know the information to keep abreast of the information, greatly increasing the possibility of leaks; the second is to allow employees who do not need to operate or process the information to have these powers and increase the possibility of out-of-control management. Therefore, an SAP system permission management system based on business activities should be established for enterprises that have implemented the SAP system. What permissions an employee should possess depends on the roles and activities it takes in the enterprise business process system. "Business activity-driven" should be an important principle for judging whether an employee has certain power. "Business Activities" can be organized in the form of EXCEL tables. However, it turns out that such technical means are difficult to ensure the comprehensiveness and accuracy of "business activities, it is also difficult to maintain. Using Aris to establish a "business activity" Model Based on business processes is a more advanced technical means. -System permissions may be gradually magnified or even out of control The permission management in the SAP system is based on the concept of "role". A "role" is assigned a set of functions (t-code) that reflect power) and the authorization conditions (profile) that reflect the restrictions ). To give an extreme example, If you create a role for each employee in the SAP system and assign this role to only one employee, then, a permission change in a role will not affect others' permissions. However, general enterprises do not do this, because if there are more employees, the role System in the SAP system will be too complex. Furthermore, the difference between a role and another role may be very small, which leads to large data redundancy. The general practice is to establish a general role, composite role and a single role System in SAP to authorize users. That is to say, an SAP system role may be assigned to multiple users, changing the permissions of a role due to the needs of an individual may affect the permissions of other users corresponding to this role. That is, all users corresponding to this role will increase or decrease permissions at the same time. In view of this situation, when a user applies to add permissions, he or she should also inform the approver of his or her role in the SAP system and other users associated with this role, this allows the competent authority to determine whether to grant this permission to other associated users. In fact, few companies can do this. Generally, a user applies to activate a certain permission. After the Supervisor confirms the permission, the system administrator selects a role based on experience for the role corresponding to the user and adds this function directly. In this way, other users associated with this role will automatically activate this function. In general, adding permissions to users will not be complained by users. Over time, the permissions are gradually enlarged. To avoid the above situation, we need to have a set of modeled "process activity-driven" permission management system, through the characteristics of the association of various elements in the model, the above information is provided to the approver and permission maintenance personnel in an all-round, automatic, and accurate manner, rather than manually approving and adjusting the above permissions through the Excel table and system query. -The separation of duties system cannot be effectively established and executed The permission management of an enterprise not only determines who has the right to do what, but also reflects the inter-power constraints. For example, "referees" cannot be "athletes" at the same time, which is the most famous power constraint. In enterprise management, there are also many constraints that need to be considered in permission management. For example, in general, the person performing "customer credit management" cannot have the "customer order maintenance" function at the same time. Originally, credit management is a kind of control over sales orders. If you want to sign a contract with a customer with a poor credit grade, you may need to go through a series of strict evaluations and approvals as required. The advantage of the original information system is that information can be shared in a timely manner and automatically locked to prevent customers with poor credit grades from placing orders without approval. However, if a single employee is assigned the "customer credit management" and "customer order maintenance" features at the same time, then, the employee can change the credit of a customer from "poor" to "good" to avoid automatic locking of the system and place orders directly for the customer. Such authorization is a typical case that violates the "separation of duties" principle. There are many similar "separation of duties" principles. For example, the person who maintains the price list in the system should not have the permission to "sign customer orders" in SAP at the same time. Persons with the "inventory receiving and picking" Operation permissions should not have the "input inventory check result" operation function. Persons with the "input inventory result" function should not have the "accounting" function. Of course, these rules are sometimes not absolute. enterprises can adjust them according to their own circumstances. Some enterprises do not allow such authorization. That is to say, the thickness of "separation of duties" depends on the internal and external risk control needs of the enterprise, and there is no absolute standard. However, in any case, every enterprise should establish a "separation of duties" rule system, and then adjust it according to the development of its own management needs. In short, the "separation of duties" principle is an important principle for analyzing the rationality of System Authorization in addition to the "business activity-driven" principle. The establishment and effective implementation of such rules are the basis for establishing a risk control system and the embodiment of scientific and refined enterprise management. However, in most SAP system permission management, this "separation of duties" principle is designed based on Excel tables and maintained manually in the system. In theory, when an employee applies to increase a certain function, the system administrator should check whether the function applied for and activated by the employee violates the "separation of duties" principle. However, because an employee may correspond to several roles in the SAP system at the same time, the work of the system administrator has evolved to first identify all roles of an employee, list all functions corresponding to this role color, and then check whether there is any violation of the "separation of duties" principle between each function and the new function applied for activation, finally, report the inspection results to the approved supervisor for Decision-Making reference. If we make the problem more complex, the SAP system role corresponding to the employee who applies to activate this new function may be assigned to other employees at the same time, therefore, it is also necessary to consider whether other employees may have violated the "separation of duties" principle due to the addition of this new function. In this way, the work of the system administrator is complicated. In fact, such operations are very difficult to be executed effectively. Over time, the "separation of duties" principle only exists in the name of enterprise permission management. To avoid the above situation, we need to establish a set of modeled "Responsibility Separation System" based on the modeled "process activity-driven" permission management system ", these two system models are interrelated, and the authorization system models can be fully, automatically, and accurately verified, and relevant warning reports can be issued, this solves the operational problems arising from the implementation of the "separation of duties system. -The business blueprint and the actual system "two skins" are becoming more and more serious. The business flow blueprint drawn during SAP implementation is often different from the business flow that runs in the system after it is launched. This is like a house in the House when a house is designed, but when the house is built, the house suddenly finds two houses in it, what's even worse is that no one can tell why. For example, if you find that you need to modify the Blueprint process for system implementation based on the business blueprint, you will often directly modify the function in the system and grant the permissions of this function to relevant personnel, but it does not modify the business blueprint synchronously. In addition, when the SAP system is launched, enterprise management personnel will modify the process based on business changes. Such modifications are often carried out directly in the system, and no one will modify the original design draft. Over time, the real process in SAP has become a black box that cannot be clearly explained. This "black box" situation will have a great impact on system O & M management, enterprise internal control, risk management, and establishment and maintenance of the overall management system. In fact, the SAP system mainly consists of functions and data. To solve these problems, system permission management and data management are the key points. If the system permission management can be fully based on the "business activity-driven" and "separation of duties" models, and the "Data Management" process can also be effectively executed, this ensures the consistency between the business blueprint and the SAP system, so as to effectively avoid the "two skins" problem.

Http://www.ids-scheer.com.cn/newversion/IndexClassview.asp? Vpid = 48