Just like any IT project, a good plan goes a long way in ensuring a smooth and timely system onboarding. Before starting the onboarding itself, it is important to understand the overall SAP landscape of the organization. The SailPoint engineers should coordinate with SAP technical team to understand the landscape before starting any onboarding activities. 

SAP technical team

The SAP technical team consists of many different roles. Typical roles are as follows:

1. Functional consultants – they are usually SMEs of their respective modules such as procurement, sales, financial accounting, human resources, manufacturing, etc. They are usually responsible for SAP functional configuration and unlikely to be involved in the SailPoint project.
2. ABAP team/ developers – they are usually involved in enhancing or developing new programs in SAP. They will usually be required to assist with creating add on SAP Functional Modules (see below).
3. Security team – they are usually responsible for managing user access in SAP. They will be required to assist with providing the service account for integration (together with the required permission). They will also be involved in a requirements workshop to explain the current user access management (including SoD) in SAP.
4. BASIS team – they are the team managing the technical aspects of SAP landscape including change transport (e.g., moving add-on functional module from SAP DEV to QA to PRD system). They will be required to explain the SAP landscape, provide SAP technical information (system number, host, client number, etc) , opening ports for communication between Sailpoint and SAP systems, and transporting roles & Functional Modules required for the integration. 

It is important that the right teams are involved in the SAP system onboarding planning.

SAP landscape

The SAP landscape is complex and consists of multiple layers of information, such as:

1. Various SAP systems used by organizations (ERP, BW, Fiori, Solution Manager, GRC Access Control, etc)
2. If Fiori is used, whether central hub or embedded deployment
3. Environments of these SAP systems (e.g., DEV, Training, QA, Production, Pre-Production, etc)
4. System and Client details
5. Network details including network segregation, IP addresses, ports, etc

Note: SAP systems can be broadly grouped into systems, which are NetWeaver ABAP-based (this includes ECC, S/4 HANA, CRM, SRM, etc) and those which are not NetWeaver ABAP-based.  The integration requirements for these two groups are very different. 

It is important to understand which SAP systems are in scope and which client in those SAP systems needs to be managed by SailPoint. SailPoint treats each System-Client combination as one source in SailPoint since SAP users are managed at Client level.

It is also important to understand if any non-PRD systems need to be managed by SailPoint. 

Planning

SailPoint team work together with SAP team to prepare a list of SIDs and Client Numbers to be onboarded and also understand their exact purpose in the overall landscape.

In the event that user access is managed through a tool such as SAP GRC Access Control, CUA, IdM or a third-party tool, it is important to understand that integration.  For example, it is possible that SAP GRC Access Control is used to manage access to only a few SAP systems and not all.

One of the prerequisites for integration of SAP ERP is an add-on Functional Module. Functional Modules are procedures that are defined in special ABAP programs (often referred as Function Groups). Function Modules allow external programs to encapsulate and reuse global functions in the SAP System. 

They are managed in a central function library. The SAP System contains several predefined Function Modules that can be called from any ABAP program. Function Modules also play an important role in interaction between SAP systems and SailPoint. Traditionally, most third-party tools use the Functional Module RFC_READ_TABLE. 

However, SailPoint’s ABAP Integration is designed to replace the functionality of SAP’s RFC_READ_TABLE to securely access the information in the SAP system required for deeper governance. This integration needs to be deployed on the SAP system for querying the tables. SAP team needs to ensure this prerequisite in SAP systems that need to be onboarded into SailPoint. This often requires change management approvals and can be time consuming. 

Therefore, the SAP team needs to be provided this prerequisite as early as possible. 

Once the scope is clear, the team should start the onboarding process by preparing a system onboarding questionnaire to collect: 

1. Technical integration information such as system details and service accounts
2. Usual stuff like user naming convention, mandatory fields in user master record, mapping fields in user master record with Identity attributes, birthright access/ access matrix, SoD requirements, etc
3. Understanding the required actions for leaver (lock, expire, remove roles, etc)
4. Secure Network Connection (SNC) requirements, if any
5. If Fiori is used, any dependencies between Fiori and SAP ERP roles

A good planning goes a long way in ensuring a timely onboarding and also ensures right stakeholders are involved. 

In the next blogs in this series, Hexadius will share the following:

1. Things to consider for onboarding SuccessFactors as an Authoritative Source during SailPoint deployment
2. Do’s and Don’ts of SailPoint deployment for organizations using SAP GRC Access Controls 
3. Best practices for SAP SoD management at tcode and authorization level using SailPoint
4. Clearing confusion regarding SAP IdM and SAP Cloud Identity Services (i.e., IAS and IPS) for Sailpoint deployments
5. Managing non-Production SAP systems using SailPoint

Please subscribe to receive notifications about these upcoming blogs!