Project Life Cycle: I love this

Implemantation of SAP security for a public sector organization: Part I

Summary:

This document presents the technical recommendations and improvement opportunities based on a review of the Large Public Sector Security Framework, the Organizational job role definition and requirements.  It is assumed that the organization will develop or contract knowledge security resource(s) to execute the recommendations.  Out of the list of thirteen (13) recommendations, recommendation 1, 2, 3, 5, 6, 9, 11, and 14 should be reviewed first. 

Recommendation 1: Three best practices should be documented in the security framework and be followed to optimize security role design. 

1.    The same transaction code should not appear in more than one core functional role.  This design principle minimizes transaction code redundancies.  It decreases risk of inconsistent access privileges for common transactions.  One adjustment to a role is automatically activated for all assigned users or positions.

2.    Core functional roles should contain a small set of related transactions in a sub business process area.  Core functional roles should be task orientated rather than job orientated.  This approach decreases turnaround time for design and build of roles.  Code changes at the role level involve less clean up because the roles are smaller.  Code adjustments occur less often because many functional design changes only require remapping of roles to position or users. 

3.    Within a functional role there should be no SOD (segregation of duties).  When the roles are combined and assigned to the users / positions, in some instances, SOD has to exist because the conflicting tasks cannot be separated. 

Attached are examples of core functional role design matrixes:

Role Design Matrix Template.xls

How to define functional roles example.xlsx

Recommendation 2: The Organization may consider the use of value activity groups (also referred to as organizational roles) to facilitate roll out of security roles globally. 

Value Activity Groups vs. Master and Derived roles

The Organization’s Security Framework discussed the use of “master” and “derived” roles for global roll out.  The approach of creating master (also referred as Template roles), and then derive the master roles into children roles with different organization attributes can meet the requirements.  However, one important goal of an organization in its security design is to minimize the number of roles in the system.  With this consideration, the use of Value Activity Group will add efficiency and ease maintenance. 

“Master” and “derived” roles approach is to first

1.            Create the master roles (also referred to as the core functional roles) which contain the transactions necessary to perform a process. The required authorization objects and values are developed, with the exception of the Organization Level values. Organization Levels include such values as Company Code, Cost centers, Purchasing Organization, etc.

2.            Then copies of this master role are “derived”. These derived roles contain not only the same transactions and authorization values as the master but also the Organization Level values.

The use of Value Activity Group approach is to first

1.    Create the master roles (also referred to as the core functional roles) which contain the transactions necessary to perform a process. The required authorization objects and values are developed, with the Organization Level fields deactivated or blank. 

2.    Create small value activity groups (also referred to as organizational roles) which contain only organizational authorization objects and fields, such as company code, purchasing groups, business areas and associated activity codes…etc.  These roles differ from the derived roles because they only contain a few applicable organizational objects and values.  They are “small” and easy to maintain.  In addition, derived roles are master role specific and are tied to a specific process or sub process areas.  But value activity groups are independent of any master roles or process areas and can be combined with any core functional roles and assigned to users or positions. 

For example, we would like to restrict five functional roles including Accounts Payable, Accounts Receivable, GL, Purchasing, and Sales roles based on business areas (for example, we have ten business areas).  If we use the master and derived role approach, we will need to first create five master roles for AP, AR, GL, Purchasing and Sales.  Then we will need to derive ten roles for AP, ten roles for AR, ten roles for GL, ten roles for purchasing and ten roles for Sales to restrict the master roles on the ten business areas.  The total number of roles in this case will be fifty-five roles including five master roles and ten derived roles for each of the five master roles. 

If we use value activity group approach, we still will have the five master roles (AP, AR, GL, Purchasing and Sales).  But we will only need 10 value activity group (also referred to as organization roles) each contain one of the ten business areas.  Then at the time of assignment, the appropriate value activity group contain a specific business area will be assigned to the users or positions in addition to the master roles.  In this case the total number of roles is only 15 as compared to the 55 roles in the master and derived role scenario.  

The more functionality and more organizational variations that are in scope, the more advantageous is it to use the value activity.  The benefits of using value activity group are:

1.    Significantly reduces the number of roles in the system

2.    Reduces the size of the roles themselves

3.    The approach is flexible and modular because the value activity groups (organizational roles) can be matched with many different master roles to create the necessary access mix.  These value activity groups are different flavors that can be added to different master roles. 

4.    Change or additions to the value activity groups can be done independent of the master roles with minimum impact on any other roles.  Therefore the implementation and maintenance effort is low with respect to any design change on the organizational attributes. 

Attached is an example of how to define value activity groups:

how to define value activity group.xlsx

Recommendation 3:   The Organization may consider the use of position based security for assignment of the security roles. 

Position Based Security vs. User Based Security:

Most of the Organizations currently uses user based security, which refers to the method of assigning security roles to a user ID. 

Position based security refers to the method of assigning security roles to an org unit, job or position instead of assigned them to a user ID.

At you organization, an HR org structure is available, which allows security to leverage and assign users to an org attributes.  Position based security reduces initial and ongoing administration effort.  Since roles are not tied to a user, rather it is tied to a position the user(s) occupied, once a role is assigned to a position under the org structure, any users occupy that position will get the access.  For example, if a user transfer from Position A to Position B, no role reassignment is necessary, because the roles are assigned to Position A and B, not to the user.  When this transfer happens, the user moves in HR org structure from A to B, and will automatically get authorization which is assigned to Position B and relinquish old authorization from Position A.

In addition, position based security is easier to use with Workflow functionality:

In general, Workflow uses the organizational structure to identify approving positions; the position itself, not the holder of the position, drives the approval

Position-based security is similar to the position-focused Workflow (chief positions); everything is centered on positions.

Here is how to assign security roles to an attributes along the organizational structure:

In PFCG, security team will assign roles via the org mgmt tab,

, choose the org attributes from the org structure to which the role will be assigned.  The role can be assigned to an org unit, a work center, a person, or a position. 

However, for contractors, temporary employees who are not on the HR organizational structure, user based security will have to be applied for this subset of users. 

Recommendation 4: To reduce number of roles in the system, The Organization may consider use of only virtual composite roles (job roles) rather than creating real composite roles (job roles) in the system. 

Composite roles are containers of one or more core functional roles.  Some disadvantages of creating actual composite roles in the system are:

1.    Increase number of roles in the system.

2.    Overtime, composite roles can lose its original definition when more single functional roles are added to the composite. 

3.    Composite roles can hide SOD (segregation of duties) issues because it is not transparent what actually are in the composites. 

Virtual composite roles refer to the approach of maintaining a document with job (composite) role to core functional role mapping.  But in the system, security administrator will directly assign those core functional roles to users or positions.  In this case, virtual composite role serve only as an out of system reference for assignment. 

Recommendation 5: It is very important to have good role naming convention from the start of the project.  The Organization may consider adding a section in its framework to discuss its security role naming convention.  The naming of the roles should be indicative of its functions and other attributes, such as organizational attributes.  An example of a naming convention document is attached:

naming convetion example.docx

 

Recommendation 6: It is important to have a user strategy in the security framework/strategy document. 

1.     User mapping: User/Position mapping is the process of keeping parallel documentation on assignment of roles to users (e.g. an Excel matrix, or using an application such as SAP GRC Role Expert).  User/Position mapping is a vital step in accurately determining user access to the SAP system, substantially decreasing the risk of inappropriate user access.

Below is an example:

The Process should be followed:

–     Functional team leads map users/position to the core functional roles necessary to perform day-to-day business tasks. 

–     User maps should be forwarded to the security team by the functional teams in order to set up the user IDs accurately

–     Segregation of duties analysis should be performed on a role and user level

2.    User ID source and naming convention: One step in the user mapping process is to determine the user ID source and naming convention.  One option for the organization to consider is to use network ID as SAP ID, making it easier for creating users and standardizing user naming across platform.  When applicable, SAP can pull users IDs and other user information such as address data from LDAP (Active Directory).  User ID and password policy should be defined in the security framework or strategy document.

3.    User provision:  The Organization should be starting the process of selecting and implementing user provisioning application. 

Recommendation 7:  The Organization may consider running SOD checks at different phases of its SAP implementation.  During role design phase, SOD check should be performed at transaction level against the core functional roles defined.  After the roles are built in the system, an SOD check should be performed on the roles in the Development box.  The organization may request its GRC vendor to connect to the development box and perform the check.  After unit testing, prior to the transport of the security roles to QA box, another check should be performed.  After the roles are tested during integration testing and modifications are made, The organization may request its GRC vendor to connect to the QA box and run another SOD check.  In the cutover plan there should be a step to perform an SOD check prior to transporting to production.  In production, the GRC application’s productive instance should be connected to the SAP productive instance upon go live and checks be performed continuously.

Recommendation 8:  Key security parameters should be reviewed and documented in the security strategy document and values approved for input in the system.  Attached below is an example of the selected parameters and settings:

PARAMETER	PRD	QA	DEV
login/failed_user_auto_unlock	0	1	1
login/fails_to_session_end	3	3	3
login/fails_to_user_lock	5	5	5
login/min_password_diff	3	0	0
login/min_password_digits	1	0	0
login/min_password_letters	1	1	1
login/min_password_lng	7	7	7
login/min_password_specials	0	0	0
login/no_automatic_user_sapstar	1	1	0
login/password_change_for_sso	0	0	0
login/password_change_waittime	1	1	0
login/password_expiration_time	60	90	90
login/password_history_size	10	5	5
login/password_max_idle_initial	3	6	6
login/system_client	Depends on SID	Depends on SID	Depends on SID
rdisp/gui_auto_logout	1,800	3,600	3,600
rdisp/max_wprun_time	600	600	600
rdisp/max_alt_modes	3	6	6

The elements of good change control procedures for supporting a complex commercial ERP environment

The factors should be taken into consideration when designing change control procedures and the potential areas of vulnerability, even after well-designed procedures have been put into place

The change control procedure is the key to a successful for any project let alone a complex ERP implementation that spans across countries and involves a suite of products. In my view, and in my practice, I’d consider the following are the key elements in addressing the change control management

• Updated Organizational Change Management Plan: The plan needs to be updated as we are moving over from the blueprinting phase to the realization phase. The realization phase consists of development and technical solutions, will definitely pose a threat to the agreed up on scope. Since this phase has a large scope for the scope creep, a careful amendments to the existing change control plan needs to be incorporated, with the participation of the technical team. In my view, This will involve three main components:

·         Stakeholder Review

·         Risk Mitigation plan review

·         Reviewing Stakeholders

• Sponsorship Engagement: As the realization phase gets traction, there will be a lot of issues that might end up in the following category:

·         Solution is available

·         One or More solutions are available

·         No Solution available: Vendor may provide a solution.

·         No Solution available and the vendor can’t provide a solution.

Since this process is going to go back and forth between the technical teams, business teams and the users (project group), time is of the key element. An SAP suite of solution which has an intensely integrated applications, demands that the issues are raised, discussed and mitigated in time to avoid project slip overs. And also as against the blueprinting phase, here the solutions are tangible and options have to be finalized. I’d think of the following factors are important in this section:

·         Targeted sponsorship report and updated action plans (BRA): This will keep the focus on the people who need to take decision and to facilitate the escalation process to gain visibility.

·         Leadership Coaching: To make faster and effective decision

·         Critical Conversation: Involving all functional streams related to the issues.

• Communication during Realization: As I said, time is the key element as we develop technical solutions and start closing the issues. Since the ultimate approval or suggestions for improvement belongs to the business, a proper communication plan needs to be established and maintained. In my experience, I’ve taken the following steps:

·         Key Messages during Realization: This needs to be done as a periodic process. The team as a project group allocated a specific time to discuss the issues, follow ups and the options available. An issue owner is identified to take the issue to the closure.

·         Optimized FAQ Database and Feedback Loops: In my experience, Most of the issues will have a similar path to the resolution. This process is very critical, so that the focus is on the issue as a whole as against ‘bits and pieces’ of information.

·         Updated Communication Plan: As the realization process unfolds, proper adjustment to be made to the communication plan (This is a part of the best practices of project management)

·         Maintaining the Communication Plan

• Organizational Alignment: This part in specific to the technical solution pertains to the job roles for the end users and how the business functions are mapped in the system as transactions and approval process. As an overall technical solution lead in my current project implementation I’ve spent a great deal of work in this cross application area and consider the following key steps:

·         Organizational Impact Review

·         Job Role Impact Assessment

·         Organizational Alignment Strategy Update

·         Assessing Job Role Impacts

•  Project Team Change Management: This pertains to all forms of project phase and I think the following are the key components and I strongly believe in this as I’m as good as my team.

·         Effective Project Teams

·         Maintaining Project Team Efficiency

The areas of vulnerability are the scope creep that happens as a part of the technical solution. This happens predominantly, if the person or the team does not have a clear understanding of the business process or the understanding of the SAP’s solution architecture. The focus on enhancements that are not supported by SAP, pose a great risk of non-compliance and will affect the future upgrades. This I call it as unnecessary customization lead in to huge development component. The rational for this ‘WILL’ happen in most cases is:

Customization and development of all sort of add-ons to make SAP pleasing seems to be gratifying activity for analysts, developers and sometimes even users. However, first they cost, second, when all pros and cons are considered they often become liabilities to the project and in longer-term to the organization. I insist they should not be done whenever they can be avoided but still it comes easy to justify doing them. We need to take them under effective project governance. I’ve devised a four step principle to avoid it:

·         Adapt before build. First adopt SAP standard functionality wherever possible. Convince users to adapt: check if process can be tweaked if cannot adopt SAP functionality. If process cannot be tweaked are there any workarounds?

·         For any type of request that is not part of standard SAP, analyze the requirements first. Is it really required? Can we use standard SAP data element (note if this is a SAP standard field consider future usage of that data element). Just because it may not be used now does not mean it will never be used.

·         For reports, check standard reports to see if most of the requirements can be satisfied

·         In case of screen simplification, we either simplify the existing screens or if the function is simple (e.g. infotype maintenance) we can build from scratch. But we cannot apply the same to other complex transaction (e.g. PO or Sales order entry). In summary we do not reproduce SAP functionality.

Further to that these were translated in the change control process as:

·         Before considering a custom solution the functional analysts develops a thorough understanding of the requirement and validates it; checks standard solution, proposes alternatives or workarounds if standard solution is not available.

·         In case it is a showstopper – a critical requirement, the functional analyst defines the requirements for custom solution. The custom solution has to be completely defined in terms of why it is needed, what are the consequences of not developing the custom solution, any business implications around this.

·         The definition of the custom solution needs to be submitted to technical team lead who can then decide whether to conduct technical feasibility and estimation of effort and impact on development. The technical lead may decide not to develop the custom solution based on the priorities and workload and specifics of a request – then it will be the end of the procedure.

·         The technical lead forwards the definition of the custom solution along with the feasibility, resource, and impact summary to Project Technical Manager, who is authorized to issue a final negative decision.  Project Technical Manager will communicate the decision to the technical and business lead.