Top 50 things that should be considered while implementing SAP (Part-5)

SAP is one of the most well-designed software when it comes to implementation. It is designed so that thousands of functionalities have been incorporated as per business scenarios. These functionalities can be activated by functional consultants while mapping processes in SAP. Different team members such as Basis (Infrastructure team), Functional Consultant, and technical consultant helps in implementing the end solution as the scope of work.

?When you are done with the scope of work and processes to be mapped in SAP, you can initiate the groundwork for implementing Hana Servers. This activity needs to be included in the initial scope of the project. The same can be outsourced to a different team as well. This team will help establish the SAP environment, create users and relevant roles, and assign them as per their responsibility.?

?Activity is started when SAP Hana servers are received in the data center. Then, the Basis consultant does installation work and server readiness. Server readiness is done as per the landscape finalized after the discussion. However, some points should be kept in mind so that you can reduce risks at the later stages during the system audit and compliance.

?Please refer to my earlier articles in this series to check other points that have already been covered. I will cover the following topics in this article.

?1.????Setting up of Security Parameters (Servers, Operating System & Database Level)

2.????Understanding the Scope of Customization and timelines

?1.????Setting up of Security Parameters (Servers, Operating System & Database Level Settings)

There are a few basic settings that should be kept in mind when you configure the SAP environment. We use a different set of user ids while configuring the SAP environment. The installation program creates some user ids. These are system IDs used for connecting the application layer database when installation is done.

?

Audit trails should be activated when a system is configured, and its password should be changed immediately by the System Administrators from their default passwords. Password complexities and length of the passwords should also be set as per applicable IT SOPs/Policies. Generally, password complexity is defined as the use of capital/small letters, numbers and special characters, etc. The password length should be kept at 6-8 characters to enhance security in the system. These controls are easy to maintain at the time of SAP installation.

?These controls are required at all levels – Operating systems, Application Servers, & Database Levels. System User IDs shall be converted into the System Users category. SAP generates SAP*, DDIC and TMSADM etc. These User IDs should be changed to System User IDs.

?These should be recorded and documented by taking screenshots of the configurations. These parameters play an important role from a compliance perspective and are recommended to be changed by Auditors. These controls are mapped and tested while preparing Internal Financial Control (IFC) for Audit.

?Users should be given restricted access as per the requirements. Full access can be granted during the implementation phase. We should avoid giving access to the SAP_ALL role, which is considered a critical role from an Audit point of view.

?The login parameters such as user lock (3 to 5), minimum length of the password, special characters & digits/letters to be used, expiry time, and password history should be maintained, and their documentation should be done correctly. Standing access to security administrative functions is not assigned to any user account in the production environment. Once these parameters are established, no changes should be made. It is advisable to make a Fire Fighter User ID where accessive rights should be granted. This should be kept disabled, and the same should be activated after getting the HOD?permission. Whenever this user ID should be used, Relevant Logs (Transaction SM20) should be reviewed by IT Head to ensure that the access being provided is not being misused. This will help you in attaining compliance.

?A proper process for User Creation, Modification, and Deactivation should be designed to remain compliant and reduce SAP licensing post-go-live. Direct changes in tables and configurations should not be permitted. Wherever possible, all changes should be moved from DEV, QAS to PRD route after taking confirmation from the users.

?Remote access accounts on SAP should be kept in a locked state. The access shall be enabled for SAP vendors on a need basis for software maintenance/ issue resolution. This account should be accessible via a secured connector, which should be initiated by the change manager and informed to IT Head. ?

?Access to change the program should be given to restricted team members using Fire Fighter. No immediate changes and debug authorizations should be assigned in the PRD environment.

?Global system change (SE06) and cross-client system settings (SCC4) should not be allowed to change to programs and configurations. These should be assigned after proper approval from Head IT. These should not be assigned to consultants other than SAP Basis. The Backup Plan should be activated per business requirements, and the same should be scheduled in the SAP environment. The frequency and number of media should be decided based on the available resources in the organization.?

?The below given IT SOPs/Policies should be prepared for better management of the SAP environment:

-?????????SAP User ID creation, modification, and deletion

-?????????SAP Access Management

-?????????SAP Change Management

-?????????Password Policy

-?????????Periodic Reviews

-?????????SAP Backup Procedure

?Periodic reviews should be done for System changes, Client direct changes, ghost ID after employee exit, change controls moved in a particular period & roles and authorizations, etc.

?2.????Understanding the Scope of Customization and timelines

When the server setup is released for functional and technical consultants after completing the above-given controls, actual configurations/customizations can be initiated in SAP. The design document should be ready by this time to commence actual work. It is crucial to understand various business processes that need to be configured in the SAP environment. Therefore, proper design documents should be created keeping in view different modules that will be used to map all activities.

?All relevant configurations should be done to map steps defined in the business process. As far as possible, the standard approach described in SAP should be used to avoid the irrelevant scope of effort while doing configurations. In addition, the Business processes should be mapped so that all MIS reporting requirements should be met using standard MIS reports.

?While migrating from a legacy application, people compare MIS reports from the legacy system. The project sponsor should check standard reports with the consultants and accept the change from the SAP system. This will help in reducing development efforts drastically. When a customized report is designed in the SAP environment, the chances of errors are high and need proper validation. This effort can be reduced if the business can use standard validated reports. MIS reports formats should be evaluated after 2-3 months of implementation when there is a significant gap in obtaining the information. This will help end-users to understand the system in a better way, and very few reports will be developed.

?Project scope and timelines document should be designed to map each business process. Unit and Integration testing plays an integral part after the completion of the configurations.

?The scope of Customization needs to be identified well before the implementation. Forms such as Purchase Order Layout (Domestic, Import, Subcontracting, Service, Third Party, Stock Transfer, etc.) Invoice Layout (Normal, Credit, Debit, Return, Scrap, etc.), Different Labels (Quarantine, Approved, Rejected, etc.), Goods Issue Layout for Process Order, etc., need to be identified. These are mandatory customizations and are show stoppers also. These development objects and their timelines need to be planned along with the Technical team. All parameters, values and printing alignment should be checked properly for all business processes. This is a time-consuming activity, and development should be initiated at the earliest. All layouts should be finalized at the time of the To-Be design phase.

?The scope of integration should not be added along with the SAP implementation. The interface should be developed after go-live. Any such licenses should be held till the Go-Live. You need additional licenses for Process Orchestration (PO) or Hana Cloud Integration (HCI), or Cloud platform integration (CPI). These licenses should be activated when SAP is stabilized and all basic modules start working correctly. You can plan to purchase these licenses when the final negotiation is done, but activation should be kept on hold till the project go-live. Due to any reason, if the project gets delayed, then you lose a good amount of license fees if these are activated and purchased along with the SAP licenses. Integration projects such as Biometric Attendance System, HDFC Bank Integration, Integration with other applications such as BPC, CRM, SRM, LIMS, QAMS or DMS, etc., should be considered in Phase 2.

?The scope of Phase 2 should be discussed separately for better management of the SAP implementation. Project timelines of Configurations and Customizations should be designed so that resource allocation and some additional buffer should always be considered.

?I will cover other aspects of implementation in detail in my next article. Feel free to suggest if I missed out on anything.