Despite Oracle (and Global Knowledge before it) espousing the single-source document-creation capabilities of UPK, the primary use of UPK is for the creation of simulations for use in training. And for this, it can work very well—if the developer is willing to put in the effort.
Simulations are captured in the application for which the training is being developed. This means that the simulations have the "look and feel" of the actual system. When these simulations are executed, the trainee gets the impression that they are interacting with a real system, whereas in reality, they are working within the safe confines of a training tool.
An example of a UPK simulation screen is shown in the following screenshot:
You will notice in this example that the simulation is played back in full screen, with the UPK-provided information overlaid on top if it. This information comprises a red rectangle indicating the area of the screen with which the user needs to interact, and a "bubble" that provides the user with instructions. The user types the specified information into the field indicated, just as they would with the actual system. Instead of interacting with SAP, they are in fact looking at a static screenprint and interacting with some clever JavaScript code that provides the "look and feel" of the system.
It is this actual "look and feel" that provides the greatest argument for using UPK.
It is a generally accepted fact in learning theory that most people (certainly in the sphere of adult learning) learn more effectively by doing (practicing). In many large corporations, this practice has traditionally been achieved through the use of a training system (or a dedicated part of the 'development' system) in which trainees can carry out predefined training exercises.
However, there are a number of problems with this approach:
Additional capital costs: A separate system needs to be provided to avoid having trainees interfere with the actual system. This can be costly both in terms of the capital cost of the hardware, and the need for ongoing maintenance.
Additional administrative burden: Trainees need to be able to access the training system, which may require the set up of training user IDs and passwords, which need to be reset before and after every training conduct.
Significant data set up: Data needs to be set up in the training system. If you are running a training course for ten people, then you need to create ten sets of data—one for each trainee. Additionally, any values that the trainees need to enter must be maintained separately (typically on data sheets) and provided to the trainees so that they can carry out the exercise.
Ongoing data refreshes: Data in the training system is consumed by its use during training, which means that it will need to be set up again for the next class. For large, database-driven applications, this is achieved by performing a system refresh, or a restore from a backup. This, again, can be expensive and can take time.
Possibility of system instability: If training is carried out in a development environment, then there is always a danger that the developers will change something that prevents the training exercises from working the way they originally did. Nothing destroys user confidence in a new system than it "not working" during training.
UPK solves these problems by capturing what is effectively a snapshot of the application, using a single set of data. This recording is external to the application, which means that once it has been captured the system is no longer required. Trainees do not need to log onto the system, and it does not matter if the developers change anything—or even crash the system. Additionally, any information that the trainee requires regarding data values is built directly into the simulation, so there is no need for separate data sheets.
More importantly, because UPK generates a single, stand-alone simulation, every trainee can carry out the same simulation, at the same time, and see the same result. Furthermore, a trainee can carry out a single simulation multiple times and see
exactly the same result every time. This is important, as it means that the trainee can return to a simulation after the course conduct (for example, when they are back in the office, performing the task for real) and see exactly what they saw during training, as a refresher.
Given this, UPK simulations are increasingly being seen as a good choice for providing exercises for classroom-based training. The classroom conduct still takes place, but instead of the instructor asking trainees to log on to the training system to carry out an exercise, they now ask the trainees to run a UPK exercise.
The fact that UPK simulations are self-contained, and do not rely on a system or instructor being available, means that they are well-suited to providing self-paced training (what used to be called computer-based training, before that term went out of vogue).
By placing all of the UPK output on a central server, or in a Learning Management System(LMS) , users can access the training simulations on their own, and receive training at their own desks at a time that suits them best.
However, it is important to understand that UPK does not instantly replace the need for a trainer. Yes, they can replace trainers, but doing so takes a significant amount of time. In a classroom environment, the trainer is there to explain an exercise, point out interesting information, and provide additional business-specific information. They add context to the mechanics of the key-strokes and mouse-clicks captured in the recording.
If the trainer is not present to provide this information, then it needs to be provided to the trainee through some other medium. Thankfully—as we shall see in this book—UPK works very well as this medium. But the information still needs to be entered into UPK so that the trainee has access to it.