SAPexperts/HR
Key Concept
SAP E-Recruiting sources and manages talent within and from outside your organization through enabling a talent relationship management (TRM) strategy. TRM combines an aggressive recruiting policy with Web-based recruiting tools. A sound TRM strategy focuses on the goals of a company and integrates software to complement those goals.
SAP E-Recruiting offers significant functionality not offered in the R/3 Recruitment module. It offers the possibility to engage candidates outside the context of a traditional application process and enables more proactive sourcing. SAP E-Recruiting manages your potential workforce of internal employees and external candidates sourced through your organization’s career page. See Figure 1 for an overview of its capabilities.
Figure 1
Overview of the capabilities in SAP E-Recruiting Release 3.0
Planning for and implementing an SAP E-Recruiting project differs from other HR projects such as a benefits and payroll implementations. You should consider several factors while planning an SAP E-Recruiting project. We will clarify misconceptions about what SAP E-Recruiting Release 3.0 is and is not and show you the skills needed to prepare for your implementation. We’ll also provide options for your system landscape and security, explain what approach works best for your situation, and describe how SAP E-Recruiting works with SAP HR. In Part 2 of this series, we’ll reveal how to avoid major implementation pitfalls.
Note
SAP E-Recruiting 3.0 became available to all customers in February 2005. It works with SAP HR releases from 4.0B. The mySAP ERP 2005 release of SAP E-Recruiting, also known as SAP E-Recruiting 6.0, will be available to Ramp-Up customers in October 2005. It can work with any SAP HR release up to 4.0, although deployment and integration options vary. This article focuses on SAP E-Recruiting Release 3.0.
Points to Clarify
The standard R/3 Recruitment functionality is not the basis for the new SAP E-Recruiting component. Many people think if you implemented the former recruiting module, SAP E-Recruiting must be an extension or a similar implementation, requiring the same effort and skills to implement. Such is not the case. The SAP E-Recruiting module has a brand new design, geared to Internet-based TRM. It is separate from the core module with new objects, data structures, and feature functionality.
Treat your SAP E-Recruiting implementation as a conversion from R/3 Recruitment rather than as an upgrade, because its data structures are different with new objects and new features. The existing R/3 Recruitment functionality does not have the requisition concept, and is driven by vacancies. It also doesn’t separate candidates (people who are interested in working for you) from applicants (people who have applied for jobs). With the introduction of a new data model in SAP E-Recruiting and the use of a talent pool, it’s now possible to do proactive TRM without having an open vacancy before recruiters start interacting with potential future employees.
SAP E-Recruiting differs from your existing Internet-enabled R/3 Recruitment functionality. The nuance is an important consideration when interviewing implementation resources. You need to distinguish if your consulting resources have implemented SAP E-Recruiting or Web-enabled R/3 Recruitment to appropriately plan for the extra time needed to become familiar with the new product. Release 2.0 of SAP E-Recruiting was released to Ramp-Up customers in the summer of 2003, but Release 3.0 was the first widely popular release in North America. The first North American customers went live on Release 3.0 in 2005. Those dates can help you distinguish if any consulting resources that you engage have or have not implemented the new product.
It is possible to confuse SAP E-Recruiting with the existing Employee Self-Service (ESS) or Manager Self- Service (MSS) scenarios for recruiting. The MSS Recruitment functionality exists for SAP E-Recruiting 3.0 when used with mySAP ERP 2004 or later. This workset uses the new SAP E-Recruiting module’s functionality. MSS’s core documentation (prior to mySAP ERP 2004) refers to the existing core R/3 Recruitment functionality, so be careful not to confuse the MSS features of the two modules.
Note
Keep in mind that all recruiting implementations are different and have many varied processes to support. Two companies in the same industry and region can have very different processes, as well as having different owners of those processors. For instance, the involvement of line of business managers can vary from very little to managing much of the recruitment process.
Tip!
If you are converting from R/3 Recruitment to SAP E-Recruiting, you may want to send email to existing applicants asking them to register at your new career site so that they can manage their careers. This enables recruiters to have up-to-date information and can serve as the foundation for your talent pool data. In addition, you will only register current, active candidates.
Note
Text Retrieval and EXtraction (TREX) is the search engine used by SAP E-Recruiting to search attachments such as resumes. It is critical that someone with Basis and TREX knowledge is involved in the project.
Implementation Methodology
You need to approach blueprinting and deciding which functionality should be available to which users slightly differently with SAP E-Recruiting as compared to R/3. When implementing R/3, a common practice is to look at the Easy Access menu and determine which transactions are needed and who should be authorized to use them.
Since SAP E-Recruiting is Web-based, end users use no R/3 transactions. The SAPGUI is still needed for IMG configuration, workflow configuration, Application Link Enabling (ALE) setup, etc. While SAP E-Recruiting currently does not have a toolset to assist in project scoping and implementation, Solution Manager content will be delivered with the mySAP ERP 2005 release of SAP E-Recruiting.
The best approach to mapping processes to functionality is to use the available documentation. Particularly useful documents include the process overview documents, the SAP Tutors (offline user interaction simulations), and Functions in Detail documents. These are available as an Online Knowledge Product (OKP) at https://service.sap.com/okp. The HR316 SAP E-Recruiting training class also covers these processes. The report RCF_GENERATE_URLS is also useful to generate a list of entry- point URLs into the system.
Implementation Skills
An SAP E-Recruiting project requires additional technical resources, but also requires working with groups of your organization that you may not have worked with before. The recruiting business process owners, someone with SAP E- Recruiting functional experience, and someone with SAP E-Recruiting Basis experience should be heavily involved in the project. Consider these points:
- It pays to engage SAP E-Recruiting functional and Basis expertise at the beginning of the project, even if you plan to staff the project from your own resources. This gets your resources up to speed, which is beneficial at the important early stages.
- SAP E-Recruiting configuration works through the IMG just like other SAP components. An outside resource can, however, help with best practices, map the solution to your business requirements, and offer experience from other projects.
Specific Basis knowledge is required in the area of TREX, installation of the Web Application Server (Web AS) 6.40, and security (e.g., setting up the HTTP-protocol).
If functional and Basis SAP E-Recruiting resources are not possible for the duration of the project, a minimalist approach is to engage a Basis resource for the basic installation of SAP E-Recruiting and TREX and to do some knowledge transfer with your Basis team. Bring in the functional SAP E-Recruiting resource with an overlap of at least a couple of days so that together the resources can get the basic system up and running. The functional resource can then assist with project preparation, blueprinting, and knowledge transfer for a few weeks.
Table 1 shows a suggested list of technical skills that are helpful with an SAP E-Recruiting project. Sometimes it is hard to determine what a functional consultant is expected to do and what belongs in the realm of Basis expertise. Functional consultants on SAP E-Recruiting projects are typically able to perform some tasks such as changing SmartForms, and may have knowledge in the areas of ALE, standard workflows, and maybe even some Basis areas. Often, functional consultants pick up such knowledge on other SAP E-Recruiting projects, but you cannot assume this.
| Basis security |
Enable HTTPs, advise on security landscape |
Spot consulting for HTTP, ongoing for security landscape |
| Basis administration |
Set up Web AS HTTP services, SMTP server, etc. |
Mostly at the beginning of the project |
| Basis, TREX, SAP Knowledge Provider (KPro) |
Enable searching within SAP E-Recruiting. KPro is the document repository tool used to distribute and manage data. |
Initial setup and ongoing monitoring/ troubleshooting |
| ALE |
Transfer data from HR to SAP E-Recruiting |
When data transfer is set up and during initial discussions |
| WorkflowSmartForms |
To activate standard workflows, set up any custom workflows |
Ongoing throughout implementation |
| SmartForms |
To send correspondence, display overview pages |
Ongoing throughout implementation |
| ABAP, Business Server Pages (BSPs) |
Any modifications to the standard solution |
During any custom development phase |
| SAP E-Recruiting Personnel Development (PD) objects, infotypes |
Needed for custom workflow, any modifications |
During any custom development phase |
|
| Table 1 |
Ideal technical skill set for an SAP E-Recruiting implementation |
System Landscape and Security
Potential employees apply for jobs and interact with SAP E-Recruiting through your organization’s public-facing Web site. Deployment of solutions that face the public bring with them the challenges (and opportunities) of offering a great user experience, while not comprising the security of your systems. Hackers visiting your career site looking for IT jobs should not be able to hack into your payroll system.
To bring real benefits, you should integrate SAP E-Recruiting with internal systems such as HR and SAP Business Information Warehouse (BW) to synchronize data across systems. Your security landscape depends on many factors, including your organization’s overall security policies and your budget. We will base our comments on security approaches that we’ve observed in SAP E-Recruiting implementations, but we don’t purport to be security experts. Options for deployment that can serve as a framework for a discussion with your security team follow. You may need aspects of any of these examples or an entirely different approach to meet your needs.
Single Instance
If you have implemented or plan to implement mySAP ERP 2004 or 2005, then you have the option of deploying SAP E-Recruiting on the same instance as HR and other ERP modules. If you are on an earlier release, this isn’t currently an option, but should be considered when looking at future plans to upgrade.
SAP E-Recruiting is an add-on component that can be deployed in three ways:
- On a standalone Web AS 6.40
- Separate from HR on an SAP ERP Central Component (ECC) instance
- On the same ECC instance as HR
A single-instance deployment means that SAP E-Recruiting and ERP reside on the same productive instance. You could also deploy SAP E-Recruiting on an ECC 5.0 system in a standalone environment, but the rest of ERP is not used productively. You could then take advantage of Organizational Management (OM) infotypes that only exist as part of the ECC.
Weigh Deployment Options
Deciding whether to deploy SAP E-Recruiting on a separate instance from HR or not is easy if you are on an HR release earlier than mySAP ERP 2004; for these releases, you must use a separate instance. If you have implemented mySAP ERP 2004 or will implement it in a time frame that matches your SAP E-Recruiting implementation schedule, then you have a choice.
The benefits of deploying on the same instance include cost and ease of integration. It’s more cost effective to maintain one server, and reuse of HR data is a lot simpler if both solutions are already on the same instance. If you are planning on making customer enhancements and need data from HR, then a single deployment will make things simpler. One instance reduces setup and maintenance of integration (ALE and RFC calls between systems).
The considerations for the one-instance setup are security, system maintenance, and managing usage bandwidth and data volume. Security must increase if there is a firewall between SAP E-Recruiting and HR. However, your security team can advise on whether deployment on the same instance can occur in a way that is acceptable to your corporate security policy.
System maintenance can be an issue for the following reasons:
- Acceptable times for maintenance downtime may be different for the internal-facing HR and employee users and for the external candidates. The different needs of candidates have to be taken into consideration when scheduling downtime.
- Although SAP E-Recruiting Service Packs differ from ERP Service Packs, SAP NetWeaver Service Packs may need to be installed to fix SAP E-Recruiting issues. Retro-testing would also have to occur for the rest of ERP. The same could be true for SAP NetWeaver Service Packs that are installed to fix non-SAP E-Recruiting ERP issues.
- Candidates typically surf for jobs outside of office hours and create peak usage times that are different from those normally experienced with internal-facing applications.
- Consider how many candidates will register when looking at sizing. In addition to the number of profiles in the system, you also need to consider that all the IDs of external applicants who register in SAP E-Recruiting are stored in the same security tables as maintained via transaction SU01. Therefore, employee IDs as well as SAP E- Recruiting external IDs stored in the same table may present a problem for some implementations depending upon the volume of external candidate registrations.
Security Zone Approaches
If you decide to go with separate instances, another question to ask would be whether SAP E-Recruiting and HR should be in separate security zones or not. The separate security zone approach involves implementing SAP E-Recruiting in a separate security zone from HR, separated by a firewall using a proxy server. Figure 2 shows that SAP E- Recruiting is accessible from the Internet within the demilitarized zone (DMZ), and Figure 3 shows the single security zone approach.
Figure 2
SAP E-Recruiting via the separate security zone approach
In this scenario, communication between HR and SAP E-Recruiting is done via ALE and remote function calls (RFCs) through a proxy server. SAPGUI is only needed for working in the IMG and some utility reports. An Apache server filters and directs traffic, and can hide all of the SAP E-Recruiting URL parameters from external users. Secure Socket Layer (SSL) and the secure HTTPS protocol should be used for communication of any personal information. See SAP note 711701 for information on security guidelines.
An example of very high security with consequential restrictions on integration might include (a variation on the second security zone approach):
- Only allow “push” communication from HR to SAP E-Recruiting
- Only allow communication via ALE, so that the proxy ports only need to be opened at certain times of the day
The single security zone approach involves having HR and SAP E-Recruiting on integrated separate instances in the same security zone. This is a much simpler landscape, without proxy servers separating SAP E-Recruiting and HR. One fewer security zone makes for a simpler landscape, and costs less. However, an extra layer of security is, of course, more secure.
Tip!
Set SAP E-Recruiting number ranges for OM objects as external, since HR is the “system of record” for OM objects.
SAP E-Recruiting and SAP HR
As you saw in the system landscape section, SAP E-Recruiting can be deployed in three different ways: same instance as ERP, standalone on top of an ECC, and standalone on top of Web AS 6.40. How you deploy SAP E-Recruiting affects how it works with HR.
The architecture of the SAP E-Recruiting system is similar to HR OM and PD data objects. Some of these objects such as Organizational Unit are available in a pure Web AS deployment of SAP E-Recruiting because they are part of the Application Basis Layer (ABA). Other objects or infotypes, such as vacant position information are delivered within the ECC, and you need to have SAP E-Recruiting sit on an ECC instance in order to leverage them. Implementing in an ECC environment allows you to use additional features such as filtering on vacant positions when assigning a position to a requisition.
In a standalone environment without ECC, you can use most of the same PD and OM transactions in SAP E- Recruiting system to maintain the organizational structure and qualifications catalog such as PP01 and OOQM. You can use transaction PPSS to view structures and SE38 to invoke PD reports. Various OM reports such as existing organizational units (report RHXEXI00), organizational structure with persons (RHXSTR02), and structure display/maintenance (RHSTRU00) are available in SAP E- Recruiting to help you manage your organization structure.
For testing and data load purposes, you can also use PP02 or PP01 to manually enter OM data. If your implementation is totally standalone with no integration to an ERP system, you can manually maintain your organization structures or load it with utilities or load programs. Data load products such as WinRunner and other tools are available from third-party vendors. For example, various custom programs have been developed over the years by third- party business partners to load organizational structures and you could use them with little or no tweaking to load the organization structure for SAP E-Recruiting. Alternative “open” or lower-cost utilities include SAP’s best practices package, which contains Business Configuration (BC) Sets that use SAP’s delivered Computer Aided Test Tool (CATT). Alternatively, you can create custom CATT test procedures to import data with CATT.
If you implement E-Recruiting in a standalone landscape with ALE integration to R/3, you can synchronize your organization structure, qualifications catalog, proficiency scales, and employees. Furthermore, with the qualifications catalog, you can designate a specific branch or branches you want to sync so you don’t have to make the whole R/3 qualifications catalog open to SAP E-Recruiting and the candidates, possibly divulging privileged information. If you want consistency in qualifications catalogs, you can simply make only some qualifications visible to SAP E-Recruiting users.
When implementing a standalone system to HR using ALE, the employees are converted to Business Partners via a business application interface (BAPI). During the conversion, the system converts the Person (object type P) into a Business Partner (object type BP), consequently drops the PERNR, and SAP E-Recruiting assigns a BP object ID. BP objects also define the SAP E-Recruiting hierarchy structure (companies and branches).
Note
You need to maintain a separate number range for BP objects in SAP E-Recruiting and BP objects for systems that feed into BW such as Supplier Relationship Management (SRM) or Customer Relationship Management (CRM). This can cause major problems if you have overlapping number ranges from different systems in BW. Note that for the ALE of employee information, you can always use the provided Business Add-In (BAdI) to only bring certain groups to SAP E-Recruiting (e.g., exclude certain employee groups), or to change the data that is brought over. This would be needed, if for example you have retirees that are still being paid, but you don’t want them as internal candidates.
If you have mySAP ERP 2004, data extractors are available to pull data from HR based on organizational unit, job, and position. These data extractors are used to display HR information such as current position holder in SAP E-Recruiting using an RFC call. You can either use the predelivered extractors or add your own. Although these extractors are used to display HR information on the requisition, they could be used for other purposes, such as custom work-flows that need HR data for requisition approvals, or including HR information in recruiting correspondence.
Another issue to be aware of is data transfer to HR, which happens when SAP E-Recruiting pushes new-hire data to HR via an RFC. The data is then stored in a holding area. PA48 is an HR transaction used to finish “pulling” data from SAP E-Recruiting via this holding area and start the hiring process for a candidate.
When using mySAP ERP 2005 for both HR and SAP E-Recruiting, this transaction is replaced by integration with the new Personnel Administrator role, using the SAP Exchange Infrastructure (XI) and industry-standard HR-XML.
Next time, we’ll share some useful tips for planning an SAP E-Recruiting project. If your project is global, don’t miss our third article about special considerations for an international SAP E-Recruiting project.
Mark Ingram
Mark Ingram is a recruiting technology consultant and entrepreneur with a focus on SAP systems. Mark was the product manager at SAP for E-Recruiting before consulting. You may follow him on Twitter @ingramtalent, or read his blog at https://blog.ingramtalent.com.
You may contact the author at mark@ingramtalent.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
Mitch Burton
Mitch Burton is an independent consultant with nine years of HCM consulting experience at SAP America. Specializing in E-Recruiting for the past year and a half, he has been engaged in several projects, was a Ramp-Up coach, instructed SAP E-Recruiting classes for customers and consultants, presented workshops, and helped scope SAP E-Recruiting projects.
You may contact the author at mitch@trmtechnology.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
