Payroll | Time | OM & PA | Portal | Payroll Fixes | Career Tips | SuccessFactors |
#1
|
|||
|
|||
Global Implementation
When implementing the Training & Events module on a global scale across different countries, there are a number of factors to consider. System security, data conversions, the event catalog structure, billing and correspondence are all areas affected when the module is being rolled in different countries. While there is not one given strategy, organizations have to make certain decisions and will face a number of challenges. This article takes a closer look at these challenges and how to deal with them.
The Business Event Catalog structure The very first decision that you will have to make is how you are going to organize the business event catalog. This catalog contains all of your courses (business event types) and their respective dates (business events) organized into logical hierarchical groupings (business event groups). This set-up is necessary in order to carry out day-to-day activities such as booking attendees for business events. When implementing T&E at multiple sites who are all going to access the business event catalog on a daily basis, you have to very carefully choose a design that it is easy to use, logical and coherent. |
Payroll | Time | OM & PA | Portal | Payroll Fixes | Career Tips | SuccessFactors |
#2
|
|||
|
|||
Ask yourself the following questions:
|
Payroll | Time | OM & PA | Portal | Payroll Fixes | Career Tips | SuccessFactors |
#3
|
|||
|
|||
You need to answer each one of these questions because it will affect the design of your event catalog. If training is very decentralized and site specific, you may choose to place countries and sites at the higher business event group levels. For example:
|
Payroll | Time | OM & PA | Portal | Payroll Fixes | Career Tips | SuccessFactors |
#4
|
|||
|
|||
Catalog Access
Your catalog design should allow for structural authorizations if you need to restrict access to certain portions of the catalog to specific populations. You might want to prevent training administrators from France to create courses under a business event group that belongs to a training organization in the United States. Structural authorizations allow to restrict access to specific plan versions, object types and object ID's. You can also restrict the display depth. For example you might allow a user to see the business event group "Languages > French" but prevent him from accessing "Italian". If you need to implement structural authorizations, your catalog design should be very decentralized so that specific user groups are granted access to a specific hierarchical node. You want to keep this as simple as possible. You have to consider that should you add a new business event group that is not linked to a business event group your user currently has access to, then his/her authorization profile needs to be updated if they need to access this new business event group. Structural authorizations are the most effective way of preventing access to certain portions of the catalog but they are often time consuming to maintain and slow down reporting - especially of your business event catalog is very large. An alternative to structural authorizations is the usage of "views", a system usage guide and a naming convention, which we will cover later on. Administrators can restrict access by manipulating their administrative settings and choose to display only that portion of the catalog that they are using to manage their courses. This prevents users from accidentally creating courses under the wrong business event group and displays only a fraction of the catalog - the one that they work with. This little switch is activated under a person's user defined settings, which he/she can access from the business event menu. 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 will be read with all appending objects. It also is 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 carry out billing for a business event that belongs to a different training organization, increasing the capacity of someone else's fully booked business event in order to place another candidate, creating courses under a business event group that "does not belong to them" etc. Again, the design of the business event catalog should help here - each training organization should logically own a portion of the event catalog. This 'system usage rules" document should be distributed and explained during training. |
Payroll | Time | OM & PA | Portal | Payroll Fixes | Career Tips | SuccessFactors |
#5
|
|||
|
|||
Naming Convention
When rolling out T&E on a global basis, you need to put in place a naming convention for the abbreviated name of object types. Whenever you search for an object, you can use this naming convention to restrict the output. The naming convention will allow distinguishing between similar object types and indicating who the owner is. For example you might have multiple business event types that have a similar name but they are all distinct courses offered by different training departments. The naming convention will allow you to choose the appropriate course and prevent confusion. Without a naming convention, you will end up with thousands of objects, each with a different or sometimes identical abbreviation that only makes sense to the person who created the object - and this person will most likely forget the abbreviated name they choose. There are 12 digits in the abbreviated name of business event groups, types, resource types, locations, instructors and other objects you might use within T&E. It is up to you how you want to design this convention but one good idea would be to include the training organization name or code or the object owner ID in the abbreviation. If you have a multitude of separate training departments, you can give each of them a code or a name and include this in the abbreviation of a course. This way it will be clear to all users as to who owns the course. The same applies to all other objects. You might choose to include the country abbreviation as well. As far as business event groups and business event types are concerned, you might also want to come up with some sort of logical course grouping. For example, a "French Advanced Course" offered by a Training department in San Francisco might be abbreviated as following: USLAFRAD1000 whereby the first 2 digits represent the country (US), digits 3 and 4 represent the type of course (LAnguages), digits 5 to 8 represent the course (FRench ADvanced) and the four last digits might represent the training department in San Francisco coded as '1000'.This naming convention should also be used for other object types such as rooms, locations and other resource types - otherwise you will end up with very similar resources without being able to distinguish them. Again, this convention should be carefully documented and explained during training. |
Latest News in SAP HCM OM & PA Forum |
|
|