Scenario

How can an organization integrate a Web-based self-service site for employee benefits with other applications that need this information? Employee benefits information is likely to be managed by a personnel or human resources (HR) department. Much of the information collected by HR needs to be maintained according to privacy conditions that severely limit access to this information by other employees. A subset of the information submitted by an employee during the benefits enrollment period needs to be transferred into other financial applications such as payroll and benefits administration. To further narrow this discussion, we will focus on the employee benefits enrollment process.

The typical process in many large organizations for handling employee benefits is a manual paper-based process. Employees submit a signed paper form during the open enrollment period to indicate the selections they wish to make for benefits in the following period (typically a year). This paper form is routed first to the personnel or human resources department where this information is checked and may be entered into an HR application. The benefits enrollment form includes the list of benefits to be subscribed (choice of medical plan, for example) plus other private information needed for benefits administration (names of spouse, dependents, and life insurance beneficiaries, for example). Then a subset of this form lacking the private employee information is sent to the Payroll department to be entered into payroll and other financial applications by a data entry clerk.

Existing manual process for handling employee benefits enrollment

This is a common scenario in many organizations where paper-based forms and manual data entry are part of the process for business applications. The challenge is to automate this process as simply and inexpensively as possible. Companies have made large investments in existing custom and packaged business applications. These software applications (payroll, for example) manage critical business information and processes that are essential for the operation of the company. Employees will express extreme displeasure if a payroll check is not issued on time. As a result, it would be far too costly to replace these existing software applications such as payroll and benefits administration in the near term. Integrating applications (payroll and benefits administration with human resources, for example) using online forms filled out and submitted by the employee can provide a low-cost way to automate this manual process without making costly changes to existing applications. The automation of the manual process can reduce errors, increase productivity, and enhance employee satisfaction.

Integrating employee self-service with packaged applications

One of the approaches to automate this process is to use a self-service Web site for the employee to fill out and submit forms. The information collected from these electronic forms can then be integrated with HR, payroll, and benefits administration applications using interfaces exposed by these applications.

To adequately understand this business problem and the solutions that will be proposed in this chapter, it is important to review a number of related topics, including the specific custom or packaged applications involved, the interfaces that these applications expose, the interactions in question, and some of the different models possible for integration based on APIs.

In order to better focus our discussion and illustrate a conceptual solution, we will assume that the HR department uses a custom application for human resources management. We will assume that data from this human resources application is stored in a relational database management systems (RDBMS) on Windows 2000, UNIX, or as data files on an IBM AS/400 minicomputer or IBM-compatible mainframe system. Since the focus of this chapter will be more on integration with a packaged application used for the payroll system, we will assume for simplicity that the HR data is stored in SQL Server 2000 on Windows 2000. The HR data could as easily have been stored in Microsoft Access on Windows or one of the popular RDBMS systems on UNIX.

For this scenario, we will assume that payroll and other financial applications use a packaged application, SAP R/3 software. The SAP R/3 package was chosen since it represents the most popular enterprise resource planning (ERP) suite with almost one third of total worldwide sales for ERP software. Most of our focus in this chapter will be on using the interfaces exposed by the SAP software for application integration.

SAP R/3 consists of some core components including an application server runtime and repository for business data plus a large suite of application modules that companies can use to handle business needs. Some of application modules available in SAP R/3 suite include applications for Financials, Material Management, Environment Health and Safety, Sales and Distribution, Fixed Asset Management, Quality Management, Plant Maintenance, Customer Relationship Management, Investment Management, and Human Resources. Companies can purchase and customize specific modules from the SAP R/3 suite to meet their business needs. The application module used for payroll in SAP R/3 is located under Human Resources. The specific component to be used for illustration is the PY-US module (U.S. Payroll) in the Payroll (PY) module under Human Resources. Benefits are handled as part of the Personnel Administration (PA) module under Human Resources. The specific component in SAP R/3 of interest in this scenario is the Benefits Administration (PA-BN) component under Personnel Administration.

SAP R/3 uses a relational database management system to store data used by the SAP applications. SAP can be used with a number of different RDBMS systems as the data store. A popular configuration for SAP R/3 is installation of the SAP applications on Windows 2000 Server using SQL Server 2000 as the database. SAP R/3 can also be installed on UNIX systems and configured to use any of the popular RDBMS systems (Oracle, Sybase, Informix, or IBM DB2, for example).

Data integration with SAP is not a viable option. The SAP R/3 database schema is far too complex to support an integration scenario using data sources. A typical SAP R/3 installation can use several thousand data tables within the SAP database. A complete installation of the SAP R/3 suite uses almost 23,000 data tables with cryptic names unrelated to the components they support. Furthermore, SAP R/3 operates as a sophisticated transaction processing system and application server that would preclude direct access to the data files without jeopardizing the transactional integrity and proper operation of the SAP packaged applications.

Fortunately, SAP R/3 does support a variety of well-defined interfaces that can be used for application integration. The scenario discussed here will be based on integration with the SAP R/3 system using these exposed interfaces over the network using TCP/IP. Consequently, the scenario discussed in this chapter is applicable whether SAP is deployed and installed on Windows 2000 or UNIX systems (Sun Solaris, AIX, HP-UX, for example). The choice of RDBMS used by SAP is also not a factor, since all access to the SAP application logic and data will be through public interfaces exposed by the SAP software. This is one of the advantages of basing integration on interfaces and APIs compared with data integration. Of course, data integration might well be a less costly and a less difficult approach if it were a viable option for integrating with SAP R/3.

Previous  Next