It is often just a matter of time until companies that are live with R/3’s Personnel Administration and Organizational Management implement the remaining HR functionalities, such as the Training and Event Management component (PE). PE offers a wide range of functions for the planning and administration of employee training courses. It enables companies to manage and record the knowledge and skills of employees in one location. Once the training-and-event functionality is implemented, it makes sense to leverage the investment by employing the application everywhere in your organization where learning and employee skills need to be managed and traced.

When you are extending the use of PE across different divisions, locations, or even countries, you need to consider a number of factors. System security, data conversions, the event catalog structure (representing your courses in a hierarchical tree), billing, and correspondence are all affected when the module is rolled out at different locations.

If not enough preparation time is spent on your system extension project, you run the risk of ending up with an inefficient system, an inadequate course catalog, duplicate data, and above all, frustrated users.

While the PE component itself might be well documented, the following recommendations, which stem from my experience, aren’t. This article examines five challenges involved in a rollout, and the best practices for tackling them.

1. Best Practices for Changing the Business Event Catalog Structure

Your business event catalog represents your courses (business event types) and their respective sessions with dates (business events), all organized into logical course groupings (business event groups). This section clarifies how the design of the business event catalog needs to be carefully chosen, how it impacts ESS (Employee Self-Service) and why a naming convention is not only useful, but also indispensable.

Design

The first decision that you have to make is how you are going to reorganize the business event catalog. Courses and their respective dates are organized into logical hierarchical groupings. When multiple sites that all employ the business event catalog on a daily basis use PE, you need a design that is easy to use, logical, and coherent. Ask yourself the following questions:

• How many new training organizations will come into play and how is their training structured? 

• Do training courses cover different business lines, and if so, are there commonalities?

• Is training location-specific?

• Is training targeted to a certain audience within the organization? 

• Do you need to restrict access to portions of the catalog to specific user groups?

The purpose of these questions is to find out if you can simply build on to your existing business event catalog, or if you need to rethink its entire design. In a nutshell, three basic options (Figure 1) present themselves:

Figure 1

Business event catalog options

• If your training is site-specific, you may choose to place locations at the higher business-event group level: 

  USA
  California
  Los Angeles

  or

  Brazil
  Rio de Janeiro

• If your training is division-specific, targeted to a mobile audience that travels frequently, or if large portions of your training courses are online, you might want to place business lines at a higher level:

  Chemical
  Chemical Engineering

  or

  IT
  Desktop Applications

• If your training is decentralized and training-organization specific, with each site handling courses separately, you might place training departments at the higher level:

  Training Site Los Angeles
  Languages

  or

  Training Site San Francisco
  IT courses

Bear in mind that the design should be robust enough to allow training administrators to have all their courses organized in one place, logical for employees who access the catalog via ESS, and coherent so that courses are easy to find by drilling down to a particular node within the hierarchy.

Naming Convention

Every object within the training and events component has a name and an abbreviated 12-digit name. The abbreviated name is an effective and quick tool when searching for objects, such as business event types, rooms, and locations. The more users and sites, the greater the need for an efficient naming convention. Without a naming convention, you end up with thousands of objects, each with an abbreviation that makes sense only to the person who created the object.

It is helpful to include the object owner ID in the abbreviation. The object owner might be coded numerically or alphabetically and typically represents the training department or an individual user. This way, the owner of the business event, business event group, or business event type is clear to all other users. It makes sense to create naming standards for all types of courses. A beginners’ course in French might be coded 1000 or FRFBEG — it is essential that all users use the same code. A codification standard for all objects used within PE prevents duplicate entries. The naming convention should be well documented and followed by all users who have access to creating objects.

ESS

Allowing your employees to self-register for training courses via SAP’s ESS also affects the design of your naming convention and business event catalog. The standard SAP ESS functionality for PE does not actually display the training catalog to the user. Users can search for courses by name or location. This is why you need to be careful when naming business-event groups, business-event types, and locations. These names have to be searchable.

2. Best Practices for Catalog Access

Standard PE functionality enables all users to display the entire business-event catalog and to create business-event types, and events underneath any business-event group. This might not represent a problem for small PE implementations where all users are at one location or department; however, with manifold rollouts, you need to review who should have what type of access.

User Restrictions

When the user community becomes more complex, you might decide to restrict certain portions of the business event catalog to specific populations. Otherwise, you run the risk of allowing everybody to potentially change or delete a business event/type that belongs to a different training department. The design that places the training center at the highest level works best if you need to restrict access to a particular node of the catalog per training organization. Structural authorizations allow you to restrict access to specific plan versions, object types, object IDs, and the depth of the catalog. The depth restriction limits how far a user can “drill down” into the catalog. They are, however, often time-consuming to maintain and require frequent user profile updates. Structural authorizations might also slow down reporting.

An alternative to structural authorizations is the use of “views” that restrict what a user sees on his/her SAP screen. This switch, available in all versions, is activated under a person’s user-defined settings, which he/she can access from the business event menu or via Human Resources>Training and Events> User-Specific Settings. (See Figure 2.) Here users can enter the ID of the root object (event group or type) to be read when accessing the business event menu. Only the root object is read with all appending objects.

It is also advisable to compile a “system usage rules” document if you do not implement structural authorizations. This document should outline what administrators are allowed to do and what they should refrain from doing — for example, billing for a business event that belongs to a different training organization, increasing the capacity of someone else’s fully booked business event to place another candidate, or creating courses under a business event group that “does not belong to them.”

Figure 2

Changing user-defined settings

User Roles

The creation of certain object types, such as business-event groups, should be left to a “system owner” type role when PE is used at multiple locations with a multitude of users — otherwise the business event catalog design can be modified at will by any user and quickly becomes incoherent. The “system owner” role should have exclusive access to create or modify objects that affect the entire user community — such as business event groups, locations, and resource types — to avoid duplications.

It is important to distinguish this role from traditional training administrators who typically create courses or events, book attendees, and perform all the follow-up activities with full PE access — with the exception of the creation of business event groups, resource types, and locations. These last three transactions should ideally be assigned to a different user role, i.e., the “system owner” role. This prevents all other users from creating data at will, which can result in duplications and a malfunctioning system.

Log-on Language

When rolling out PE across different countries, you need to agree on a common log-on language. If a user creates an object while he is logged on in German (as the log-on language on the initial SAP access screen), then other users will not be able to see the object unless they log on in German, too. This means that unless you create an object in more than one language, users have to log on in the original language the object was created in to see it.

It is advisable to ask users to always log on in the primary language that you use to conduct business. This way, you have a common language across countries. This helps your production support help desk when receiving phone calls, and you have data consistency. 

In addition, if you have objects in more than one language, it is likely to cause problems in other areas such as workflow and ESS. These custom applications usually look for the first language they can find. You might end up having a user in the United States who receives a workflow email that contains the course name in German.

3. Best Practices for Data Conversion

In a rollout situation where multiple legacy systems will be converted into SAP PE, you need to plan ahead when it comes to data conversion. You might have to convert thousands of courses into SAP that all must fit into their logical place in the catalog hierarchy. Your courses will be converted into business event types, following the naming convention you have designed and assigned to the appropriate business event group. This can be done programmatically, while your individual sessions or business events have to be created manually. This is because events are all attached to a business event type or schedule and might require resources that have to be selected from a list. 

As far as other data is concerned, you might want to use the Computer Aided Test Tool (CATT) to load resource types, locations, or instructors. The more data you can load programmatically the better. In a large-scale implementation, it reduces human error and saves a lot of time. 

You also need to think about historical data. Do you want to load it into SAP so that you have one reporting system, or do you want to keep it in the legacy system? Once you have loaded the courses, it is not difficult to create a training history for employees by establishing a relationship between the business event type and the person.

4. Best Practices for Configuration and Transactions

Executing Transactions

Specific situations call for a number of processes and associated transactions in PE. For example, the “firmly book” transaction should be executed at a specific stage in the training cycle, and so should the “follow-up” action. Each organization has to decide when these transactions should be executed, especially if they serve as triggering activities for workflow, correspondence, or billing. If a large community uses these transactions at will or chooses not to use them at all, it negatively affects your reporting, and you do not get the most out of your system. Standards and common procedures ensure that training organizations across the globe follow the same set of rules on their shared system. 

Correspondence

Another area where you need to design a common template is correspondence. Whether you use SAPScript or Workflow, you need to create a standard letter (i.e., registration, booking confirmation, course cancellation) that is read and transmitted to the receiver. R/3 reads the language field of the enrolled student from his or her personnel infotype, and this is what determines the language in which he or she receives the correspondence. You can only have one template in each language for a specific scenario. Therefore, you need to involve your training managers across the organization in order to agree on the content of the message.

All forms correspond to specific transactions in R/3, and users need to understand how they work and which data needs to be in place. Here are three examples:

• The letter linked to notification abbreviation DELVORM (R/3- delivered form linked to a transaction) should be printed when a business event is canceled and attendees are pre-booked onto the business event type. This letter must be printed prior to canceling the event or there will be no output.

• The letter linked to notification abbreviation STOR should be printed when an attendee cancels his attendance and no resulting prebookings are made. Here a business event must exist with attendee bookings and you need to cancel the attendee from that business event for the letter to be triggered.

• The letter linked to notification abbreviation INSTDEL should be printed when a business event has been canceled and the instructor of the event needs to be informed. Here a resource type (instructor) needs to be specified at the business-event type level and an instructor needs to be selected at the business-event level.

As far as workflow is concerned, emails are sent out automatically and end up in the receiver’s inbox without any intervention from the training department. This means that users have to be aware of the consequences of certain transactions that have been designated as triggers.

5. Best Practices for Billing

One issue that arises with cost allocation in larger organizations is that PE does not allow billing across different controlling areas. The cost centers of the sender and the receiver have to reside within the same controlling area if you want to use the standard PE cost allocation functionality. In addition, you might have an R/3 HR system separate from your FI/CO system, which presents another challenge. In any case, you have to develop a custom solution to overcome this issue, which will involve some ALE (Application Link Enabling) if you have multiple R/3 systems. If your inter-company financial system is not on R/3, or only partially on it, then you need to develop an interface to your billing system if you are carrying out internal cost allocation.