SAP E-Recruiting allows you to standardize your global talent management strategy while still meeting local needs. We will show you what to consider when planning for a global SAP E-Recruiting implementation.

We’ll use the example of company X, which has 20 business units in eight countries. You’ll see how it uses SAP E-Recruiting to comply with local regulations — from protecting data privacy to data retention practices — and how it adapted SAP E- Recruiting to meet its varied business needs. We’ll start with four compliance practices.

1. Data Privacy

Having a global pool of talent registered in a single talent warehouse brings advantages to company X, such as visibility of talent in one global system as well as the cost savings from one consolidated system. However, different countries as well as different regions have varying privacy laws for candidate information. Some countries’ privacy laws conflict with other countries’ laws, and some regional laws (such as the European Union) have overarching laws that may supersede those of individual countries. Therefore, ensuring that your applicants’ data is kept confidential is a sensitive area that requires consultation with privacy law experts such as your company’s data privacy officer.

At company X, if candidates wish to register in the global talent pool they are required to sign acceptance of a data privacy statement. Company X’s data privacy statement incorporates the local agreements where the company operates as well as its corporate privacy policy. Some companies use a global privacy agreement that incorporates both national and regional agreements. A candidate may also apply for a job without wishing to be considered for other jobs. In this case, only those people working on the related job requisition are able to see the person’s information. Who has access to the requisition is based upon who is assigned to the support team of the requisition for which the applicant applies. As with any legal area, it’s essential to seek professional advice on any aspect of data privacy.

2. US EEO Guidelines

Companies hiring persons for positions in the US are obligated to make every effort to collect data from their applicants regarding their gender and racial/ethnic background to help ensure the company is practicing fair employment practices and complying with Affirmative Action and Equal Employment Opportunity Commission (EEOC) guidelines. Companies use the gender and racial/ ethnic background data collected on applicants in different ways:

• To proactively self-audit their hiring practices to ensure they are considering a diverse applicant pool for their selection processes
• As input for affirmative action plans
• To prove they are practicing fair selection and hiring practices if they are audited by the Office of Federal Contract Compliance Programs (OFCCP) or EEOC
• As input for compliance reports, such as the EEOC’s EEO-1 Report (Equal Employment Opportunity Employer Information Report) and the OFCCP’s EO Survey (Equal Opportunity Survey of Federal Contractor Establishments)

SAP E-Recruiting uses questionnaires to gather information about applicants. You can define the questions asked during the online application process (or the questions completed by a recruiter) by country, business unit, and job, for example. There are two types of questionnaires: job-specific and EEO-specific. Job-specific questionnaires allow you to rank candidates based on questions to which they have responded, such as “How many years of sales experience do you have?” or on hiring manager (interviewer) feedback.

EEO questionnaires are different; you can’t use them for ranking, but you can report against them using either the predelivered EEO reports for the US or customer reports. Authorizations control who can see EEO data. EEO- related information needs to be kept separate from the person’s application data because strict rules govern who can view this data (i.e., an applicant’s ethnicity or gender should not be known by those making hiring decisions). Although EEO is specific to the US, other countries sometimes need to collect similar information on applicants and can take advantage of the EEO- specific questionnaire type to collect data on applicants.

3. Filter Applicant Information

Whenever possible, a global pool of talent should be comparable using the same information. Recruiters must judge a candidate in Germany and a candidate in the US by the same criteria if they are applying for the same job. However, laws restrict what information can be asked of and recorded on a candidate. Two pieces of information that can be asked in Germany, but not in the US, are date of birth and gender. Both candidates are in the same database and have the same fields.

Company X uses filters, or contexts, to ensure that candidates in Germany are asked their date of birth and gender while at the same time, US candidates are not asked for this information. Recruiters in the US should never see a candidate’s date of birth or gender. However, an applicant may register in Germany (and therefore specify this information) and then apply for a US-based job. Company X therefore defined an additional filter, or context, so that the date of birth and gender fields are always hidden from US recruiters. Examples of context names are USCAND and DECAND. For the USCAND context, date of birth, for example, can have the attribute “Hidden” so it is not visible on the screen.

Contexts can drive another aspect of the user interface: container sequences. We’ll cover container sequences later in the “Identify information needs” section. Field attributes define whether a field is required, optional, hidden, visible, or invisible for a particular context.

SAP E-Recruiting derives the context from a parameter within the URL that is used to access the SAP E- Recruiting system. The context is retained throughout the user session. An example of a context at the end of a URL for company X would be rcfCONTEXT=USCAND.

Company X took a pragmatic approach to creating contexts for different regions. The project team followed this process:

• Look at the global list of possible candidate fields. Some of these fields may not exist in standard SAP E-Recruiting, but you can add them without any coding. You do this by creating customer tables using the predefined customer include name. These are always named CI_Pxxxx where xxxx is the number of the SAP E-Recruiting infotype (e.g., CI_P5106 for the candidate desired employment infotype). The additional fields will automatically appear at the bottom of pages that use that infotype.
• From this global list, identify countries or regions that need the same fields and create groupings that will be the basis for contexts. Group countries whenever possible, because each new context adds complexity. Note that you shouldn’t just consider whether fields should be visible for a particular context, but also whether they should be optional or required.
• Configure the fields for the contexts. The default attributes for most fields are visible and optional, so you only have to configure the exceptions.

4. Data Retention

In addition to the technical needs of purging data from the system that is no longer relevant, the laws on candidate data retention vary in different countries. In the US, you must keep application information for a specific period of time (two years in some states, or longer if a claim is filed). In Europe, the focus is on deleting the application information after a specific amount of time. In Germany, for instance, applications have to be purged after four months unless candidates give permission to keep them longer.

The data purging concerns are more relevant for applicants who have not signed the data privacy statement. Candidates who have registered in the talent pool have agreed to a data privacy statement, allowing company X to keep their records longer (which is the whole point of maintaining a talent warehouse). Candidates also have the option of deleting their profile information at any time.

The mySAP ERP 2005 release of SAP E-Recruiting offers functionality in the area of application retention and data purging. You can define business rules for a particular country and region based on the months since an applicant applied for a job. You can base the rules on the retention period (more relevant for the US) and expiration period (more relevant for Europe). Candidates that have agreed to be stored in the talent warehouse and have their details considered for other jobs are not deleted.

Company X also implemented these five best business practices.

1. Standardize business processes. Like any implementation, the fewer variations on a business process, the better. The flexibility of SAP E-Recruiting is a double-edged sword in that there aren’t technical restrictions on supporting any number of different business processes. Maintaining many processes adds to implementation time and ongoing support costs, however. With this in mind, the project team at company X separated business needs from wants.

Different recruiting processes are necessary for different types of recruiting because executives are not hired the same way as recent graduates, and engineers are hired differently than sales people. If company X had only five different processes (e.g., for executives, graduates, sales, engineers, and hourly) and had variations for each of its 20 business units, it would have 100 different processes to support.

Faced with such a time-consuming scenario, company X tried to standardize the processes for its business units as much as possible. The project team developed a generic process that most business units could use, with a few exceptions where absolutely necessary — for example, collective bargaining agreements from unions.

Now we’ll describe what company X considered when looking at its business needs in terms of process flow and information.

2. Blueprint process flow. Recruiting is a task-driven, time-critical process reflected in how SAP E-Recruiting works. Action items, called tasks or activities in SAP E-Recruiting, derive accountability by assigning a responsible person, due dates, and completion dates. Examples of activities are an interview, offer, and acceptance of offer.

Company X blueprinted its recruiting processes, consolidating them across business units, and categorized them according to which phase of the recruiting process they relate (such as prescreening, screening, and offer). During the realization phase, it’s vital to think about whether and when an activity should be automatically generated by the system or created manually by the user in SAP E-Recruiting. An example of an automatically generated activity is an interview invitation email to the applicant that is triggered when a recruiter creates the interview activity. You can use workflow to apply business rules to the creation of activities and approvals for your different business units.

SAP E-Recruiting enables the creation of process templates (Figure 1) that guide a user, such as a recruiter, when performing activities. An example of a process template that company X uses is “North American Sales Manager.” It contains all of the activities that must be performed when recruiting for sales positions in North America. For prescreening, for example, it contains all the documents relevant for that activity (correspondence and questionnaires). It also contains all the questions that need to be asked during the online application process. You can define as many different process templates as you like. Remember, however, as with creating contexts, it is best to create only the process templates you really need to avoid unnecessarily complicating your business processes.

Figure 1

Process template for a US sales manager position

3. Identify information needs. We already discussed which fields are needed for different countries, and how contexts can drive them. Contexts can also drive the information stored on the requisition. If you have very different information needs for your hourly and salaried recruiting, then it is possible to show different fields based on the context. For instance, you could add a lot of information regarding shift availability for hourly workers that wouldn’t be used for salaried employees. This adds to the complexity of your implementation, however, so assess whether you really need different views.

The project team at company X also examined which pages of information are necessary, both for the businesses and the prospective employee. For example, the team decided that an applicant just out of college should be presented all pages of an application, whereas executives should only be asked to submit a resume and contact information. To accomplish this, they configured context-specific container sequences for their contexts USGRAD and USEXEC.

Container sequences are the navigation tabs along the top of a page that guide a user through a process, such as entering profile information or creating a requisition. An example of the steps included in an Application Wizard is shown in Figure 2. Container sequences can define which tabs appear in which order for a specific context (e.g., USGRAD) through the use of IMG configuration. Container sequences can also be useful for including customer pages in the process. You can achieve this by referencing customer business server pages (BSPs) in the container sequence configuration.

Figure 2

Use container sequences to configure the Application Wizard

4. Tailor Web pages to local culture and focus. Many of the interactions between company X and potential employees occur through SAP E-Recruiting. External candidates register their information and search for jobs on the company’s external career site, and existing employees use company X’s intranet. Both external candidates and internal employees access SAP E-Recruiting functionality through links on company X’s Web site. Like all SAP E-Recruiting links, you can generate these links using report RCF_GENERATE_URLS. This creates links for activities such as job searching and candidate registration.

Company X’s project team developed country-specific career pages to attract local talent for the eight countries in which the company operates. See Figure 3 for an example of another company’s career page.

Figure 3

Example of a career page used to access SAP E-Recruiting

It is also possible in SAP E-Recruiting to create specific SAP E-Recruiting start pages (the first thing the user sees after logging on, with links to the applications they need) for different business units or types of recruiting (Figure 4). For example, you could include college recruiting pages or specific pages aimed at a particular subset of talent such as engineers.

Figure 4

SAP E-Recruiting standard-delivered candidate start page

SAP E-Recruiting allows you to both drive the start page, context, and other UI parameters by embedding parameters in the URL behind hyperlinks such as “Login” or “Register” (Figure 5). These URL parameters can tailor the content for your target audience (Figure 6).

Figure 5

URL parameters

Figure 6

Alternate SAP E-Recruiting start page

Contexts helped company X to easily configure local pages. The project team determined that one of the most important parameters is language. Because company X’s Web sites have multiple languages, the project team configured the logon page with pictures of flags to change the logon language of the Web site.

In addition to the UI, SAP E-Recruiting can support different languages for correspondence. It may be the case that you only want to support the UI in a couple of languages, but want to offer much broader language support for correspondence. Company-specific correspondence (driven by the branch defined on the requisition) can also be used for different logos or wording. When candidates register, they can specify in which language they’d like to receive correspondence, regardless of which language they select to log on. You can create as many document variations as you need, but keep in mind that minimizing the number of document variations simplifies the process.

5. Plan your rollout. Company X followed these best practices to ensure a smooth rollout:

• Involve the owners of your existing career pages early on. SAP E-Recruiting should not be implemented in isolation and then integrated into your Web site as an afterthought. The webmasters have insights into end-user expectations such as which browsers need to be supported.
• Brand SAP E-Recruiting the way you do the rest of your site. Take advantage of SAP E-Recruiting’s flexible user interface. Users don’t expect to see an application when they apply for a job; they expect to have the same surfing experience. Use the same Cascading Style Sheet (CSS) for SAP E-Recruiting as you do for the rest of your site, and reuse some of your branding images within SAP E-Recruiting.
• SAP E-Recruiting has flexible text fields on many pages (Online Text Repository [OTR] texts). You can change them to match your business processes and company terminology with transaction SOTR_EDIT. All SAP E-Recruiting ITR texts begin with alias PAOC_RCF (e.g., PAOC_RCF_UI for UI texts).
• It is imperative to test SAP E-Recruiting within the context of your internal and external career pages before go-live. Engage employees as well as external candidates to give feedback on the candidate experience before go- live, preferably for all regions and languages. It’s better to get negative feedback from a small number of testers before go-live than potential employees after go-live.

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.