Global Implementation

[welcomewiki]

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.

Similar Threads:

• I have lost lakhs due to the global melt down Vineet Raina
• Aastha TV will bring you 450 hours of global LIVE telecast

[welcomewiki]

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?

[welcomewiki]

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.

[welcomewiki]

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.

[welcomewiki]

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.