A lead HR functional employee is key to the success of a self-services implementation. In this article, I’ll outline the HR functional expert’s role in the project, starting with the preparation phase of the project. The preparation phase includes building a team, configuring the system, and identifying needed business packages. Ideally, the functional employee should work closely with an experienced self-services expert and become the functional self-services expert for the company.

The article is specific to ESS/MSS on SAP NetWeaver Portal 7.0 and SAP ERP Central Component (ECC) 6.0. It refers to business packages for ESS (SAP ERP 6.0) 1.0/1.2 and business packages for MSS (SAP ERP 6.0) 1.0. If you are not acquainted with self-services terminology, see the sidebar, “Essential ESS/MSS Concepts.”

Assembling Necessary Skills

The first step is to set up the self-services implementation team. A self-services implementation requires various skills, often both internal and external, based on the in-house technical skills available. Refer to Table 1 for details about the necessary skills and resources.

Team Roles

This section describes how each of these resources fits into the overall self-services implementation. The Basis resources are commonly divided into three roles: Portal system administrator, SAP NetWeaver Development Infrastructure (NWDI) administrator, and SAP ERP administrator.

Portal system administrator: This person is responsible for installing, performance tuning, and performing various portal system administration activities. He or she is also responsible for maintaining the connectivity between the different systems in the landscape and the portal availability in general.

NWDI administrator: This person installs NWDI, performs NWDI post-installation activities, and maintains the NWDI system for Java development, version management, and transport. The traditional Change and Transport System (CTS) is used for R/3 migration, whereas you use NWDI for Java code migration.

SAP ERP administrator: This person works directly with your SAP ERP system to ensure a smooth implementation and addresses any SAP-related issues that you may encounter.

The security resources need to have a clear understanding of how the portal roles and ERP authorizations work together to give the right access levels to users. The security resources are usually divided into three roles: Portal security, NWDI security, and SAP ERP security.

Portal security: This person maintains security roles and authorizations on the portals.

NWDI security: This person must provide the necessary access to developers who might be required to modify or enhance the self-services applications.

ERP security: This person needs to work closely with the lead HR resource to understand HR authorization objects and structural authorizations involved in the HR security setup to configure the ESS/MSS roles and authorizations properly in your ERP system.

The following other self-services-specific resources are also required to prepare for and implement ESS and MSS for your organization:

ABAP resource: An ABAP resource might be required to write ABAP code to implement Business Add-Ins (BAdIs) to enhance self-services applications, write function modules, create SAP queries for MSS reports, and develop or maintain Smart Forms or HR forms for time statements and total compensation statements, for example.

The major chunk of an ABAPer’s development time would be spent implementing BAdIs. SAP provides various BAdIs for enhancing each self-service. For example, you can use BAdIs to limit the subtypes that are visible on the ESS personal information application.

Let’s assume that an organization has two subgroups of employees, external and internal. You want external employees to be able to view and maintain “Main Bank” and “Other Bank” information in the bank ESS application. The internal employees should be able to maintain “Main Bank,” “Other Bank,” and “Travel and Expenses Bank.” ESS configuration does not allow subtype configuration at the employee subgroup level. In this scenario, you implement the BAdI HRXSS_PER_SUBTYPE. You code the subtype availability logic based on the requirement.

Workflow/UWL resource: The requirement for the workflow and UWL resource depends on whether or not workflow-related applications are implemented in the project. Some of the workflow-related applications are time sheet approval, clock-in/out corrections approval, training course approval, travel request approval, and personnel change requests. Corresponding configuration of UWL on the portal is required for the execution of these work items.

Portal resource: The portal content administration and developer perform the portal- related content administration and development activities. The portal developer resource is required to have working knowledge of Web Dynpro for Java to enhance and modify the self-services applications. Self-services applications are built on a framework called Floor Plan Manager. Knowledge about this framework goes a long way towards maintaining the applications properly.

Self-services functional resource: This role is the heart of the entire implementation and is responsible for configuration of the self-service in the ERP system along with coordinating the entire implementation. He or she is responsible for configuring the required self-services, coordinating with the security team for implementing the right authorizations and providing functional specifications for the ABAP, portal, and workflow resource to enhance or develop new and existing self-services applications. Because the technical resources are not expected to have HR functional knowledge, the self-services functional resource would be responsible for writing the test cases and would be active in the testing phases.

Tips for Team Composition

An organization generally is assumed to have the following skill sets in-house:

• Basis administrator
• ERP security resource
• ABAPer
• Lead HR functional resource
• Workflow resource

The portal administration and security specialist help the in-house administrator get up to speed with the portal technology. This would be a one-time requirement assuming that the company implementing self-services does not have any previous SAP portal installed and working.

This external self-service functional resource helps the in-house lead HR resource to understand the implementation configuration and methodologies. The in-house HR resource must ensure that the external functional and portal resource configures, customizes, and develops self-services applications with the company’s current and future requirements in mind. In-house HR resources should ensure that any enhancements to the standard applications do not work negatively on the future requirements.

Setting Up Future Requirements for the System

Here is an example of how to plan for future requirements:

• Current requirement: Manager of personnel area XXXX can see the general information of the employee, but he should not be able to view the date of birth of an employee.
• Future requirement: Manager of personnel area YYYY can see the general information of the employee and should also be able to view the date of birth of an employee.
  • Wrong way: Disable the date of birth field on the application blindly
  • Right way: The developer should be made aware of this requirement and to code this logic based on the personnel area. Proper test cases, if required, should be prepared by the lead HR functionalist to ensure that the future requirements are not hindered by the current implementation.

The Technical Landscape

A self-services implementation requires the following system landscape: SAP ERP. SAP NetWeaver Application Server with integrated Internet Transaction Server (ITS).

Portals. SAP NetWeaver Portal along with the following components:

• ADS installed
• UWL installed and configured
• IGS enabled

NWDI. NWDI is required for developing and enhancing the application, maintaining version management, concurrency control, and Java code (Web Dynpro for Java) migration. Concurrency control defines a controlled way of allowing multiple users to simultaneously access the same resource.

Business Packages to Implement

Business packages are predefined content for performing business operations. It is important to decide on the business packages that are required for the implementation, depending on your landscape and functional requirements. SAP Note 1007341 helps you understand the landscape possibilities for the various business packages to be implemented.

In my example, I assume that your organization wants to implement self-services on the SAP NetWeaver 2004s landscape (7.0 with ECC 6.0). You need to deploy the following four business packages to successfully implement self- services in this architecture:

1. Business Package for Manager Self-Service (SAP ERP) 1.0
2. Business Package for Employee Self-Service (SAP ERP) 1.0/1.2
3. Business Package for Common Parts
4. Business Package for Self-Service Administrator (SAP ERP)

Significance of Business Packages

1. Business Package for MSS (SAP ERP) 1.0 contains all the services relevant to MSS. These services are geared toward enabling a manager to perform their duties easily. Refer to Web site https://service.sap.com/mss for further descriptions.

2. Business Package for ESS (SAP ERP) contains all the services relevant to ESS. These services enable employees to access and update their data in the system. Refer to https://service.sap.com/ess for detailed descriptions of the various services offered in this business package.

3. Business Package for Common Parts contains applications used by other business packages. Business Package for MSS uses many objects that are provided by Business Package for Common Parts. Two of the most often used ones are Launchpad, which launches MSS reports, and Internal Service Request (ISR)-based services. To successfully run the Launchpad service and the Common Parts-based portal objects, the administrator needs to assign the manager to both the MSS and common parts roles.

4. Business Package for Self-Service Administrator. Most of the self-services applications are built on a Web Dynpro framework called Floor Plan Manager (FPM). This is a content administrator-related Business Package that helps the portal content administrator to tune the self-services applications according to company-specific requirements. This is not an end-user based Business Package.

For example, the standard ESS Leave Request Application shows the team calendar to employees. Employees can see if anyone else is taking leave and can decide whether to take the leave on a particular day or not. If your company policy does not want an employee to look at other employees’ leave applications and leave dates, the portal content administrator could use the Business Package for Self-Service Administrator to remove the team calendar application from the leave request application.

Two business packages that are not mandatory but that you may want, based on your implementation scope, are Business Package for Project Self-Service (helps the project lead and the team members to perform their day-to-day project- related tasks) and Business Package for HR administrator. This business package for HR administrator provides you with user interfaces to perform human resources activities in HR Personnel Administration-Administrative Services (PA-AS). Using the Business Package, the HR administrator can process employee records, initiate hiring, and run various employee reports.