Global Implementation of Training & Events

Global Implementation of Training & Events 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. Ask yourself the following questions: How is our organization structured? What are our different business lines? What type of training is being offered by different departments / business lines? Is training site or country specific? Is training targeted to a certain audience within the organization? Is training business line specific? Is training decentralized or centralized? Are training courses shared across business lines? Do we need to restrict Training administrator's access to portions of the catalog? 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: USA Texas Houston Brazil Rio de Janeiro If the training is targeted to a global, mobile audience who travel frequently or are on expatriate assignments and if you have the same type of training across countries or within a business line, you might want to place business lines at a higher level: For example: Chemicals Chemical Engineering IT Desktop Applications If you have very specific decentralized training organizations who handle their training separately from one another, you might choose to place these training organizations at the higher levels. This design works well if you need to restrict access to a particular node of the catalog per training organization, which will prevent (in the example below), the Paris people from accessing the San Francisco node. For example: Training Site Paris Languages Training Site San Francisco IT courses Bear in mind that the design should be flexible enough to allow to additional rollouts, robust enough to allow training administrators to have all of their courses organized in one place, logical for employees who will access the catalog via employee self service and coherent so that courses are easy to find by drilling down a particular node within the hierarchy. You will find yourself playing with different designs until you come up with one that makes sense for your organization. It is always a good idea to get input from training organizations and employees as well as business line managers. 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. 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. User roles Especially if you have an open architecture where users can access the entire catalog, you need to carefully evaluate what user roles must be established. It is highly recommended to leave the creation of certain object types to a "System Owner" type role. This role will have the exclusive access to create or modify objects that will affect the entire user community. An example would be the creation of business event groups. Once you have your business event catalog in place, you do not want any user to be able to add, change. move or delete business event groups - because this will affect the "world". Hence, you should create a specific role that has the privilege of creating business event groups. You should assign this role to someone within production support or to the system owner, someone with a global view and perspective. If you allow all administrators to create their own business event groups, you will end up with an incoherent catalog, each portion only making sense to a specific training organization - but not to the rest of the user community. The "System owner role" should also have the exclusive access to creating resource types and locations - again, users often do not pay attention and create locations twice or more times in the system, even though the object already existed. They might do the same with resource types. Resource types have a multitude of relationships, which are prerequisites in order to use the resource reservation feature. Duplicate resource types will prevent you from using resource reservations properly. The same applies to duplicate location entries. Next you will have the traditional training administrator role - typically these users create courses, events, book attendees and perform all the follow-up activities; they will have full T&E access - with the exception of the creation of business event groups, resource types and locations. You might also have a third role that will only perform booking activities - if you are a very large organization and have clerks that book attendees to events without actually creating events or performing any resource reservations etc, you might need this role. ESS If you choose to implement ESS in order to allow your employees to self-register for training courses via SAP's web enabled user interface, this will again impact the design of your naming convention and also of your business event catalog. The standard SAP ESS functionality for T&E 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 again when naming business event groups, business event types (courses) and locations - these names have to be searchable. Alternatively, if you choose to enhance the existing ESS solution by displaying the business event catalog, bear in mind that the hierarchy you have chosen has to make sense to the students who are searching for courses. This emphasizes again the need to carefully plan the structure of your catalog, given the fact that it will be used by a very large number of employees who might self-register and an extensive administrator user group who will use it for course management. Data Conversion In a global rollout situation where multiple legacy systems will be converted into SAP T&E, 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. It is very likely that you will encounter duplicate courses: courses that have similar names but are in fact the same course. At this point it would be good to identify these courses to avoid populating SAP with duplicate or triple entries. It is beneficial to bring business lines and training departments together as much as possible in order to try to centralize the management of certain types of training. You also need to identify courses that are owned by a certain training department but offered by others and who is responsible for which processes in the training cycle. Before you can convert any course data however, your training catalog has to be in place first. Only then can you load business event types into SAP. As far as other data are concerned, you might want to use a CATT to load resource types, locations, instructors etc. The more data you can load programmatically, the better. In a large-scale implementation, it reduces human errors and will save you a lot of time. You also need to think about historical data - do you want to load them into SAP so that you have one reporting system or do you want to keep them in the legacy system? Once you have loaded the courses, it is not a difficult task to create training history for employees. Log-on Language Global organizations operate in multiple countries with multiple languages. The issue associated with this is that if a user creates an object while he is logged on with for example German as the log-on language, then other users will not be able to see the object unless they log on in German too. It is advisable to ask users to always log on in English - this way, you will have a common language across countries, it will help production support when receiving phone calls and you will have data consistency. You could ask users to always remember to create objects in both English and their native language but it is likely that they will forget. In addition, if you have objects in more than one language, it is likely to cause you problems in other areas such as workflow and ESS. These custom applications usually look for the first language they can find and so you might end up having a user in the United States who receives a workflow email that contains the course name in German. The same issues arise with ESS. It is recommended to agree on the use of English as the log-on language to simplify things. This will also prevent you from having to translate all training materials into different languages and finding instructors that are both proficient in the language and in SAP T&E. Common Configuration and transactions There are a number of processes and associated transactions in T&E that should be used in specific situations. 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 user community uses these transactions at will or chooses not to use them at all, it will negatively affect your reporting and you will not get the most out of your T&E system. Standards and common procedures will need to be implemented to make sure that training organizations across the globe use their shared system following the same set of rules. It often is difficult to implement such rules and not all users will be happy but this re-engineering is necessary. There are a number of "switches" you can set in configuration to determine the system's triggering activities, messages or output but there only is one "switch" that once implemented, will be valid for the entire user community. The global rollout team will have to communicate this to the users when they are getting ready to go live. With multiple sites, you should opt for a phased rollout rather than a "big bang" go-live for all. It is a good idea to send a team to one or a few selected sites at the time prior and until after go-live to help with outstanding data conversions or training questions. The lessons learnt at each site will reduce errors and issues at the next site and give you a chance to fix problems in between go-lives. You might want to keep your most challenging site until the end. Correspondence and Workflow Another area where you will have to design a common template is correspondence. Whether you use SAPScript or Workflow, you need to create one letter (Registration, Booking Confirmation, Course cancellation etc…) in each language needed. This template will then be read and transmitted to the student. This means that all English speaking students will receive the same exact message across the globe, each French speaking student will receive the same message etc. SAP 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 received the correspondence. You can only have one template in each language for a specific scenario and so you will need to involve your training managers across the organization to agree on the content of the message. Whereas SAPScript correspondence can be altered by the training administrator, workflow emails are sent out automatically and will end up in the receiver's inbox without any intervention from the training department. Workflow needs a trigger (time, transaction etc) and training administrators need to understand the implications of certain T&E transactions that are used by workflow to issue emails. If you choose to implement workflow to lighten the workload of administrators, decide as to when emails should be sent, what the content should be and who should receive them (Student, supervisor, administrator). Workflow is very flexible but the triggering activities have to be chosen carefully. Billing One issue that arises with cost allocation in global organizations is that T&E does not allow to bill across different controlling areas. The cost center of the sender and the receiver have to reside within the same controlling area if you want to use the standard T&E cost allocation functionality. In addition, you might have a separate SAP HR system from your FI/CO SAP system, which presents another challenge. In any case, you will have to develop a custom solution to overcome this issue, which will involve some ALE if you have multiple SAP systems. If your inter-company financial system is not on SAP or only partially, then you will need to develop an interface to your billing system - if you are carrying out internal cost allocation. Reporting While T&E has a number of standard reports that are very useful when it comes to extract training data, it does not provide a lot of information on the students and their organizational assignment. In addition, there is not much statistical reporting. In a global rollout you will gather many different requests for custom reports but many of these requests are going to be similar in nature. You will have to consolidate the information requirements before submitting a custom design document to the developers. Most reporting deficiencies can be solved by simply granting your users access to ABAP query, which allows combining training data with personal data. Depending on how large your organization is, it would be almost an impossible task to ask each training site to submit their current reports in order to identify the gaps in regards to SAP. The better solution is to send out an outline of all standard SAP reports and what they can do to a chosen user community and let them identify possible needs for enhancement. User acceptance testing Once you reach the point where you have loaded all legacy data, finished configuration and tested all functionality, you will need to involve a selected group of individuals who will test the system. In a global rollout it might be a difficult task to select your user acceptance group. What is essential though is that these users have to be trained beforehand, ideally they should have taken part in the implementation but because of geographical distances, this is often difficult. Ideally the group should be composed of both administrators and managers because you need the approval of both. And once their approval obtained, you are ready to go live!