Tools for a Successful Oracle Tutor Implementation

OAUG North America Fall 2002 Copyright © Perthos Consulting LLC 2002. Page 1

Tools for a Successful Oracle Tutor Implementation

Thomas A. Perkins Perthos Consulting LLC Background

Much has been written about the features and capabilities of Oracle Tutor, and its use as a platform for developing end user documentation and training materials. As a documentation tool, it is unparalleled for Oracle implementations, partly because of its integration with AIM 3.0 and Oracle Business Models (OBMs), but also because of the large volume of model documents available for core Oracle Applications. As an implementation tool, Tutor can be instrumental in a migration from a legacy system to Oracle Applications, an upgrade to a newer release of Oracle Applications, or as a stand-alone documentation method for procedure and process changes in something as formal as an ISO9000 quality system. As a document delivery tool, Tutor can be fully integrated within a company�s paper- or browser-based standards, making it fast and easy to update information when changes are required. Tutor practitioners have discovered that most aspects of Oracle Tutor are well understood after using the product and reading the Oracle-provided user manuals and help files. Some features, however, remain challenging, either because they are not intuitive to the Tutor practitioner, or because they involve various software incompatibilities. Other features can be �discovered� through trial and error, assuming the practitioner has the time and curiosity to pursue them. This paper will address many of these issues, and provide Tutor project leaders with additional tools to ensure a successful Tutor implementation � with fully-documented procedures, trained end users and satisfied clients as the final result. Overview

Many people-related and technology-related challenges face the Tutor project leader during an implementation. Everything from top management support to end user resistance and network infrastructure to software incompatibilities can derail even the most dedicated efforts. Potential problems will be identified and strategies for preventing them will be discussed in the first section, Challenges During an Implementation. A number of Tutor elements can be tailored for individual client requirements, and these are documented in the provided user manuals. This paper will describe several of the more advanced customizing options in the Advanced Installation section below, with recommendations based on multiple client implementations. In addition, Tutor can be extended beyond the documented capabilities. The Customizing and Extending Oracle Tutor section of this paper will illustrate several undocumented features which may help the project leader expand his or her imagination for future implementations. Like most implementation efforts, an effective Tutor project entails a series of activities to accomplish, many in sequence and many very early in the project. The Implementation Checklist section will list and describe the most important ones in a checklist format the project leader can use to prevent errors and further ensure a successful conclusion to the project. Assumptions

This paper was written for the Tutor practitioner or project leader with the following assumptions:

1. The practitioner is familiar with Oracle Tutor�s features, Microsoft Office products, and Adobe Systems products, including:

a. Documentation methodology for document content and format, integrated document relationship, document creation and maintenance, and distribution of published documents

b. Model documents for process documents and courseware


c. Author as a document editing tool d. Publisher as a compiling tool for user manuals, instructor and student guides, and a diagnostic tool

for document integrity e. Microsoft PowerPoint as a courseware preparation tool f. Adobe Acrobat as a document rendering and conversion tool

2. The practitioner is using Oracle Tutor 11.5.6 with patches current through February 15, 2002 Challenges During an Implementation

Introduction

Authors and researchers have recently highlighted what consultants already know � that people are the most critical factor in any business process change. Consultants know with certainty that conversions from legacy to Oracle systems, upgrades, or implementations of any nature always involve people. In many cases, those individuals are familiar with existing systems, comfortable with their way of accomplishing everyday job tasks, and often reluctant to embrace any changes which might disrupt the accepted work flow. At the same time, technology is often viewed as an �enabler�, not an �improver�.1 This may cause employees using computers in their day to day work to view system changes as nuisances rather than benefits. When project leaders or consultants begin to impose a rigorous documentation methodology on these individuals during a time of otherwise heavy work load, such as an Oracle implementation, additional resistance is sure to arise. Furthermore, it has been my experience that a combination of four or five software programs, such as Word, the Author template, PowerPoint and its corresponding template, Adobe Acrobat, Publisher, and several others, may lead to incompatibilities that further frustrate the end user. The first section of the paper will address several challenges related to people and technology, with a specific focus on ensuring a successful Tutor implementation. Human Factors

Of all the challenges facing the project leader, those involving people are usually the most significant. This section will enumerate the most common and propose various strategies designed to make the project successful. Top Management Support Each implementation experience includes a management team which may fully support the Tutor implementation, but more often than not, lacks a full understanding of Tutor�s role in the project. It is essential that all Tutor participants know that an executive sponsor not only supports their efforts, but is tracking their results. It is helpful if the executive sponsor also understands what Tutor is all about, and how it seamlessly fits in to � and actually strengthens � the rest of the Oracle implementation effort. It has been my experience that a short briefing regarding Tutor�s capabilities, followed by a statement at the Tutor Orientation meeting, is essential in alerting participants that their efforts in preparing process documents and courseware is a key element for the overall project�s success. A short list of activities for the executive sponsor is included in the Implementation Guide.2 In this document, Oracle uses the company president as the senior manager, and recommends that he3 confirm:

• The company�s financial investment in Tutor • The importance to the company�s future of having current practices clearly defined and distributed • Team work (it is important that all team members work with each other regularly)

1 Kai A. Simon, �Towards a Theoretical Framework for Business Process Engineering�, (Master�s Thesis, Department of Informatics, Göteborg University, 1994, Göteborg, Sweden), 58-59. 2 Emily Chorba, Implementation Guide for Oracle Tutor Release 11i (11.5.6) (Redwood City: Oracle Corporation, 2002), Ch. 2, Pg. 4. 3 Gender-specific words should be considered as non-gender-specific throughout this document.


• Progress (it is important that each document owner completes their work on all required documents by the assigned due dates)

At this point, the senior manager would introduce the Tutor project leader and the orientation session would continue, presumably with heightened attention and a renewed sense of urgency on the team members� part. Designated Torch-Bearer Likewise, each Tutor project needs an individual to lead the effort on a daily basis. This individual is generally a company employee, but may also be an outside consultant, depending on staffing availability. Either way, the torch-bearer, or project leader, must be accountable to project management for his part of the overall implementation effort, and should answer to the executive sponsor for the team work and progress points noted above. Without a single individual to move the project forward, and ensure that participants complete their assigned documents, the Tutor project is at risk of failure. The end result could be unfinished process documentation, incomplete courseware, and a host of unsatisfied department managers whose employees are untrained and not prepared to use the new Oracle software. One person must own the outcome of the Tutor project and see it through to its final conclusion. Identified Participants Oracle�s Implementation Guide recommends that each Tutor project include specific roles, such as a Tutor project leader, document owners, document controller, and document specialist.4 This advice is useful, even in a smaller project involving only a handful of people, where one person may fill several roles. At a minimum, however, each role should be covered by someone working on the Tutor project, and in many cases, each function is covered by outside consultants. The role most likely to be short-changed is the document owner role, primarily because the concept of a single owner can be poorly understood within project teams. Today�s organizations tend to follow collaborative decision-making styles more each year, and this has even permeated into the public sector, where shared ownership of decisions, as well as the documented outcome, is often actively promoted.5 However, a basic premise of any Oracle Tutor implementation is that each document should have a single owner, and this individual must have the authority to make decisions regarding the process flow identified in that document.6 There are several precautions here. First, document owners may be selected from the ranks of subject matter experts (SMEs), and this is an excellent idea, providing they have the time to invest on procedures and courseware. In all likelihood, they will already have a full-time assignment performing existing duties, and will have taken on implementation or upgrade responsibilities because of their advanced knowledge of process flows in their areas. As a result, they are likely to be extremely busy with the core implementation � making decisions about new process flows, helping with configuration and setup in the test instance of the new Oracle Applications, or attending endless workshops and meetings to determine inter-departmental process changes. They may not have the time or energy to devote toward procedure and courseware development, although they will have a great interest in the outcome. Second, document owners must know they have the authority and responsibility to make the final decisions regarding each process flow and its corresponding document. It is always helpful for a senior management official to grant this authority at the same time the project team is being assembled, so each person knows what is expected. This can be as formal as a written document, or as informal as a verbal direction at one of the project meetings. At a minimum, it should be reiterated by the executive sponsor at the Tutor Orientation meeting. Third, a document controller should be identified early in the project, and document owners should understand his role. The Tutor methodology assumes that most documents (except those unique to a single department, with little cross-departmental interface) will be centrally controlled and published.7 The document controller should begin to fill that role from the beginning of the project. While it may be necessary for the document controller to be an outside consultant at the early stages of the project, eventually this role must be assumed by a company employee. 4 Chorba, Ch. 1, Pg. 16. 5 Department of Energy Environmental Protection Agency. �Final Guidance on Improving Communication to Achieve Collaborative Decision-Making at Department of Energy Sites.� 16 June 1997 http://www.em.doe.gov/em75/cdmguide.html. 6 Chorba, Ch. 1, Pg. 13. 7 Ibid., Ch. 1, Pg. 15.


Therefore, one of the Tutor project leader�s first tasks should be to identify the SMEs who have been tentatively designated as document owners and determine if they will have the time and authority to accomplish their tasks. If the project leader discovers a shortfall in this area, he may suggest a realignment of client resources or the addition of outside consultants who can temporarily fill the gap. The biggest risk of bringing in consultants to fill the document owner roles, no matter how short term, is that SMEs may find it too easy to back away from the documentation process, resulting in a real lack of ownership in the documents, the Tutor methodology, and the knowledge transfer to end users when training is required. There is never an ideal solution to the resource issue. The Tutor project leader may find himself balancing the requirement of making progress on procedures and courseware against the lack of available time from company SMEs. In the final analysis, the Tutor project must move forward so that operating procedures and end user training are completed within the project�s time constraints. Training and Ongoing Support Each Tutor implementation requires several training sessions during the course of the project. The extent of training required, and the target audiences, will depend on the defined roles for each implementation effort. For example, if document owners will take an instrumental role in document editing, their training needs will be greater than if they merely have to communicate process flows to experienced document writers. (The latter approach is described in the Implementation Guide, where document owners perform editing on paper copies and document specialists convert them into standardized Tutor format.8) It is helpful to break up the training requirements for each Tutor implementation into individual steps:

1. List the Oracle Applications to be installed and identify corresponding owners. This will assist the Tutor project leader in determining the overall scope of process documentation and courseware required.

2. Prepare the executive sponsor for the Tutor Orientation meeting, where he will describe his support for the Tutor project. While not actually a �training� session, this is a critical education event nonetheless.

3. Conduct a Tutor Orientation meeting with document owners (and optionally, their supervisors). At this session, each document owner will become familiar with Tutor�s capabilities and learn how the Tutor methodology can help the overall project. They will also learn how they are expected to participate.

4. Conduct a Procedure Editing workshop with document owners. This is the first time document owners read the majority of Tutor�s model documents, so a few comments on vanilla implementations and standardized process flows may be helpful at this point. Depending on the document owners� involvement with other aspects of the implementation, the Tutor project leader may introduce OBM flow charts to assist with high-level process flows.

5. Train the document specialists in Author fundamentals. This follows the approach noted in the Implementation Guide, where document owners prepare hard-copy edited documents and document specialists do the majority of the typing.

6. Train the document controller in Publisher fundamentals. At this stage in the Tutor project, it is helpful to begin the document assembly knowledge transfer. The document controller will learn that publishing involves the generation of integrity reports, validation of distribution lists, development of instructor and student guides, and printing of desk manuals, among other activities, and all of these must be brought together into a unified whole at some point.

7. Train instructors for courseware editing. Many large companies employ training departments, and may allocate training specialists to assist with courseware development. In other cases, SMEs will be expected to create the courseware, and may even be expected to deliver the end user training. The Tutor project leader should determine � early in the implementation � who will be preparing and delivering end user training. In most cases, courseware editing can begin once the procedure editing has been through the first draft phase, since the process flows will be tentatively defined at that point.

It has been my experience that several of these training efforts require dedicated classroom time, while others are individualized. Since the biggest challenge will likely be the availability of client resources to prepare procedures

8 Ibid., Ch. 1, Pg. 18


and courseware, the project leader should be aware of training participation from the earliest stages of the project and encourage all team members to attend. The “RC” Factor While this paper is not intended to cover resistance to change (the �RC� Factor) in great detail, it is helpful for the Tutor project leader to remember that resistance to change is likely to be widespread throughout the organization. Some writers believe that resistance to change stems from workers� desire to do �right� rather than �wrong�, as perceived by them when change is imminent. In an online posting, Lefkoe asserts that

People do not resist change. People act consistently with their beliefs. They think what they do is appropriate, natural, "right." If you want them to do something inconsistent with their beliefs, they experience what you want them to do as inappropriate, unnatural, and "wrong." People don't resist change as such, they resist doing what they think is wrong.9

The Tutor project leader would do well to consider this. M.J. Arul, a distinguished lecturer on organizational change, while discussing change and resistance in the workplace, writes that �Change often engenders perceptions of ambiguity and insecurity, leading to feelings of anxiety and fear. These feelings underlie the numerous cases of resistance encountered in organisations when change is introduced.�10 Arul further identifies four factors leading to resistance, and proposes that resistance to change is likely to occur when:

• those who are affected by the change have not been involved in the planning of the change; • the nature of the change is not clearly explained; • the purpose of the change is not made clear to the people affected by the change; • the change disrupts, or threatens to disrupt, the established relationships with peers and/or superiors.11

But this is not all bad news! The project leader who keeps these points in mind, and knows how to deal with them, will stand a greater chance of succeeding with his Tutor implementation. Arul suggests several tactics which would help any implementation: Ensure that the change is necessary. Be clear about the objectives. Let those affected help in the planning. Make sure they understand the technical aspects of the change. Finally, ensure that social relationships are not radically altered.12 This is common sense for any change situation, but also common sense for a Tutor implementation. Once the human factors have been understood, if not mostly resolved, the project leader should be prepared to focus on the technical issues surrounding the Tutor implementation. Technical Issues

A number of technical challenges will face the Tutor project leader during the course of the implementation. While each project is different, many elements are likely to be universal from one to the next. This section will enumerate some of the most common, and often the most troublesome, to the Tutor project leader. Network Infrastructure Five basic issues surface almost immediately when conducting Tutor project initiation activities � space (server disk storage), speed (bandwidth), structure (directory location), security (file permissions), and safety (file integrity).

9 Lefkoe, Morty. �Resistance to Change L024640.� Online posting. 19 May 2000. Learning-Org Discussion Group. 21 March 2002. http://www.learning-org.com/00.05/0122.html. 10 Arul, M.J. �Change and Resistance.� Institute of Rural Management. Undated. http://members.tripod.com/~arulmj/resist.html. 11 Ibid. 12 Ibid.


Space The base install of 1,893 model documents requires 271 MB before any PowerPoint slides

are imported. If all slides were imported into EDU documents, then another 200 MB would be required. That only affects the Draft and Final folders. As a result, these folders would be expected to require no less than 471 MB, and even more for Final once the publishing process occurs (which adds .RTF files to the corresponding folders). Therefore, a recommended size for network storage is 2 GB, although it could be 1.5 GB if space is a major constraint.

Speed The project leader should consider that publishing against large groups of files in the LAN-based Draft folder will take a significant amount of time, due to the method in which Publisher accesses files � one at a time � for each document to be published using Word macros. Several recommendations should be observed: First, perform large publishing operations when network traffic is minimal. Second, ensure that bandwidth is not compromised by slow network interface cards or connection wiring (10 Mbps speed). Third, if the project leader wants to use a portable hub to add ports to his working area, use a 100 Mbps Fast Ethernet switch instead, which ensures a higher total throughput than a less expensive hub.13

Structure Install model documents at the highest level of a network drive whenever possible, as long as this location can be mapped to the Tutor defaults. Three configuration areas in Publisher assume that source and output files will be located at T:\Tutor11i… where T: is the mapped network drive. Moreover, the maximum path length is only 60 characters, which can be a problem if the Tutor files are located several levels deep on a network drive with highly descriptive folder names. See the Configuration Options, File Locations, and Understanding the HTML Options sections of the Publisher User Manual for recommended file locations.

Security The model document installation creates four folders under T:\Tutor11i\US � ORIG, Draft, Final, and APPSHTML. To protect the files under ORIG, the project leader can write-protect the files (but only after copying the contents to Draft, if that is done) and make the folder read-only to all users except himself and one or two others, such as the document controller. The same read-only access can be established for Final and APPSHTML, if desired by the project leader. At the same time, granting write access to the Draft folder will be essential, especially if the project leader wants to avoid a check-in/check-out system. It is easiest if the project leader can obtain full control of the T:\Tutor11i folder and all of its subdirectories, so that he can assign permissions on an individual or group basis. This, of course, assumes that network administrators will grant full control of the T:\Tutor11i folder to the project leader. One example of �read only� access is illustrated in Figure 1, and shows that the �Document Owners� group cannot change folder contents, but can view them without restriction.

Safety Network folders and files, once established for the Tutor environment, should not be moved by anyone, including network administrators.14 In addition, the project leader should ensure that all changed files are backed up daily, especially when document editing

13 Cisco Systems. �Fast Ethernet Hub or Ethernet Switch?�. 16 Nov. 1999. http://www.cisco.com/warp/public/779/smbiz/languide/p5.html. 14 I speak from painful experience, where LAN administrators, in their attempt to �clean up� unused files and gain disk space, deleted everything that hadn�t been accessed in the last 60 days. That wiped out the ORIG folder. In another case, one network administrator moved the entire \Tutor11i folder several levels down in the network structure, thus invalidating all network paths established in the Publisher configuration, and incidentally revealing that the path was only 60 characters long.


is in full swing. Finally, each document owner who is creating new documents or modifying model documents should be expected to maintain draft copies on the network rather than on workstations or notebook PCs.15

Document Owners’ PCs Thankfully, this is usually the most minor of the technical issues facing the project leader, especially when Tutor participants work for companies that lease notebook or workstation PCs. In those cases, the PCs tend to be changed out entirely every three years or so, and are replaced with more robust systems. This may apply more to hardware than software, however, since corporate IT managers typically resist upgrading operating systems or office suites as often as the vendors change them, but most users will have reasonable hardware. Even so, the Tutor project leader should ensure that document owners who will be editing model documents on their PCs can actually use the Author software. In most cases, it will run satisfactorily, while in other cases, certain features are not available due to insufficient RAM, inadequate CPU power, old operating systems, or outdated office suite software. It has been my observation that the most serious issues stem from the Publisher suite of software, including PowerPoint import and .PDF publishing with Adobe Acrobat, but most document owners won�t be using those combinations during the Tutor implementation. With this in mind, the project leader should verify the following items prior to launching document owners on the Author editing experience:16

1. Operating system version and language 2. Operating system service pack level (especially if NT 4.0 is being used) 3. Microsoft Office version and language 4. Microsoft Office service release level, if applicable 5. Antivirus software and currency of definition files 6. Browser platform and version 7. CPU speed 8. Amount of RAM 9. Hard disk space 10. Monitor capabilities 11. Mouse or other pointing device

Finally, during the installation of Author software on each document owner�s PC, the project leader should make the necessary changes to Word (and optionally, PowerPoint, Acrobat and Internet Explorer if the document owner will be using those programs) as detailed in the Setting Options section of the Implementation Guide.17 Failure to comply with all specified parameters may result in error messages, causing corrupt files, lost time, and frustrated users. If the project leader does not set one or more of the recommended parameters, Author should be tested thoroughly to ensure that all features work as expected. Dedicated Publisher PC Each implementation effort struggles to obtain adequate resources � both human and machine. Implementing Tutor is no exception. One of the most important pieces of equipment the Tutor project leader should obtain is a dedicated Publisher PC. Publishing large volumes of procedure or courseware documents is CPU-intensive and will consume 100% of a PC�s time during the processing effort. If a document controller wanted to publish 30 documents, for example, the Publisher program would execute a series of Word macros up to 30 times in succession. While this is occurring, no other program can be adequately executed on that PC. The same thing occurs while importing PowerPoint slides into EDU documents � the PC is 100% involved with the import process, a combination of macros in Word and PowerPoint. See Figure 2 for a screen shot of my CPU status during a small PowerPoint import process, using an older PC with 512 MB of RAM 15 A co-worker on an upgrade project had his notebook PC stolen while going through airport security, losing weeks of data in the process. Another colleague saw the only copy of project files disappear when his hard disk crashed a spectacular death. 16 Chorba, Ch. 5, Pg. 3 17 Chorba, Ch. 5, Pg. 6


and a 466 MHz processor. Note that the CPU is totally consumed, but memory usage is relatively minor � only half of available RAM in use. Batch HTML creation, reindexing, creating user manuals and student guides, and updating distribution sections are other CPU-intensive processes initiated by Publisher. Indeed, nearly every menu option in Publisher requires the full attention of the PC during its execution. The Tutor project leader should obtain the fastest PC available, even if it only has 256 MB in RAM. The CPU (combined with network access speeds as discussed earlier) will be one of the biggest determinants of publishing throughput during the course of the Tutor project. Software Versions Oracle Tutor runs in concert with other software packages, including Microsoft Word, Microsoft PowerPoint, and Adobe Acrobat. Many versions of these programs will work successfully with Tutor, and these are identified in the Tutor System Requirements section of the Implementation Guide.18 Some incompatibilities are also identified, such as Adobe Acrobat versions 4.05 or 5.0.5 and Word XP, but overall, Oracle suggests that most programs will work together harmoniously. It has been my experience that most program combinations will function as expected. However, instances of Adobe Acrobat 5.0.0 have caused both Word 97 and Adobe Distiller 5.0.0 to lock up repeatedly during student guide .PDF creation, and Oracle reports the same problem with Word XP. This is easily remedied by using the �Close Program� and �End Task� sequence on the Windows 98 platform, although I have not tested this with the XP software. The same problem did not occur when I tested .PDF creation using identical operating system, hardware and office suite combinations with Adobe Acrobat 4.05a. At this time, Oracle recommends using Adobe Acrobat 4.05 until the problem can be resolved.19 More important, the project leader should use the most current release of Oracle Tutor so that bug fixes and program updates are available. These can be downloaded from MetaLink�s Patch section as long as the project leader has a valid CSI number. Current patches are available by searching for �Tutor (pro)� as the product, �MS Windows 95/98/NT/2K Client� for the platform, and �All Product Patches� for the search limit. See Figure 3 for an illustration of all field names and values. At the time of this paper�s publication, 17 current Tutor patches were available on MetaLink. Testing There are several overall tactics available to the project leader to ensure reliable operation of the Tutor software suite and its related external components.

• Follow Oracle�s guidelines for minimum software configuration.20 • Set all program options as specified in the Implementation Guide.21 • Update each software element to its most recent service pack, service release or patch level.22 • Develop a standardized (but reasonably brief) test script for each PC installation.

Specific testing for Author should include features such as the following:

18 Ibid., Ch. 5, Pg. 3 19 Unfortunately, Adobe Acrobat 4.05 is not commercially available. Repeated calls to Adobe Systems and various resellers indicates that neither individual licenses nor site licenses for older versions can be sold. If the project leader does not already have a copy of version 4.05, then the �Close Program� and �End Task� sequence of ending the Word and Acrobat processes must still be used during .PDF creation. 20 Chorba, Ch. 5, Pg. 3 21 Ibid., Ch. 5, Pg. 6 22 In some instances, client requirements will prohibit the project leader from updating all features. On one occasion, a client resisted updating NT 4.0 to Service Pack 6a because of perceived incompatibilities with their Novell networking software. We were forced to use Service Pack 5 in that implementation, which worked just as well with Tutor, but limited the consultants� abilities to use Lotus Notes.


1. Ensure that the Author template loads in Word by observing the new menu options available only in Author.

2. Verify the Author template location under Tools > Options > File Locations. 3. Open the sample document PRO0002A.doc, which is installed in each user�s C:\Tutor11i\Author folder,

and test the following: 4. Verify that Author > Update Distribution works as expected. Delete one of the distribution elements, such

as Interior Custodian, and make sure it reappears after selecting Update Distribution. 5. Press the Renumber Tasks button. Verify that tasks are numbered correctly. Optionally, insert a new task

and verify that it is renumbered. 6. Press the Flow button. Verify that a flow chart has been created at the end of the procedure. Since this will

be the first time a flow chart has been created with the new Author template, the existing flow chart should change from monochrome to color.

7. Save the document and press the HTML button. Verify that HTML output completes with the �Finished converting PRO0002A.doc� message.

Specific testing for Publisher should include the following elements.

1. Open Publisher and verify drive mapping and file locations. (In general, model documents will be located on a network drive, and this should be mapped as a specific drive letter prior to the Publisher installation.) Select Tools > Configuration Options, Tools > File Locations, and Tools > HTML Options to verify that drive mapping has succeeded.

2. If a multi-user version of Publisher will be used, verify that more than one person can use it by running two or more Publisher sessions at the same time.

3. Run Index > Rebuild Master Index for a small group of files. Normally, this can be tested against a subset of procedures or reference documents (which you must publish prior to running this test on each user�s PC), even though it will build an incomplete master index. The purpose is to determine if Publisher will execute successive Word sessions.23

4. Run Tools > Create Tutor HTML files (Batch) to verify that Publisher can execute sequential Word sessions using this menu selection.

5. Run Curriculum > Update Distribution Sections across Documents to verify that it works successfully. Generally, this will require a small set of procedures already published and indexed. You are likely to see the message �Confirm Index,� with a listing of files that have changed since the last index was created. If so, rebuild the index and complete the distribution update. If the index has been completely built, you may see the message �Ready to update n document files� with n a number unique to your installation.

6. Run Reports > Create and Save to verify that they run sequentially. 7. Using the Author program, verify that the PowerPoint import routine executes properly by pressing the

Import PPT button. This should be performed against an EDU file from the Draft folder, and not a file from the ORIG folder, since the file is saved without warning when the PowerPoint import completes. (If the Tutor project leader has already made the files under ORIG �read only�, an error will result.)

8. Verify that Build PDF Student Guide works as expected by selecting the PDF button in a curriculum document. The Tutor project leader should prepare a sample �Student Guide Table of Contents� document in advance for this purpose.24

23 I found that Word 2000 was incompatible with NT 4.0 SP6a when using Publisher. Everything worked as expected until publishing began. Word would freeze after the first document had been indexed, and the second document would never be loaded. The message �Word File Status (DOC→RTF) 1 of n� never advanced beyond the first document and the computer indicated that Word was not responding. Oracle suggested using an earlier version of Word, and they were right; Word 97 and NT 4.0 are compatible, while the later version of Word is not. 24 A cautionary note here: If the PC has already had the full version of Adobe Acrobat 4.05 or 5.0.5 installed, a Create Adobe PDF button may be available on the Word toolbar. This should not be used to create Student Guides, and it is risky to use it while the Author template is open. I have observed numerous problems, requiring reinstallation of Author, when users have pressed the Create Adobe PDF button while using Author. The best solution is to disable this Adobe Acrobat feature in Word by selecting Tools > Templates and Add-Ins and deselecting PDFMaker.dot.


Summary

The preceding section has described many challenges that will face the Tutor practitioner on current or future Tutor implementations. Many of these, such as the human elements, will be more difficult to overcome than some of the technical ones. The primary reason for enumerating both of them is so that the Tutor practitioner is fully aware of them and can plan in advance for their resolution. The following section on customizing Oracle Tutor will give the project leader additional tools for satisfying client expectations.


Customizing and Extending Oracle Tutor

Introduction

Oracle Tutor�s Author template includes several built-in features that control output, format, color, and style variations. Most of these are fully documented in user manuals provided with the software. Other features are available but undocumented, and the project leader can experiment with them to determine their suitability for each client implementation. The first section below will discuss several advanced installation elements, while the second section will review additional features provided through the Author template and Word field variables. Advanced Installation

This section will describe features covered in Oracle�s user manuals, but not always understood by many project leaders. Although each of them is �native� to Tutor in some manner, the project leader should fully test all program functions after each change. In addition, it is essential that changes be documented, either in the source documents (such as the tutor.css file) or in supplemental files located in Tutor project directories. Modifying Existing Document Skeletons One of the first requests from clients in a Tutor project relates to the �look and feel� of the Tutor document skeletons. Most project leaders have had client representatives ask for changes to the wording and sequence of major document sections, font size and type style or line spacing. Many requests come from a desire to make Tutor documents look more like existing procedures, work instructions, or other standardized client templates. If possible, the client should consider adopting the vanilla Tutor format, since it has been fully tested with Author and Publisher functions. However, many changes can be accomplished by modifying document skeletons, and this is documented in Chapter 9, Customizing Author and Tutor Documents, of the Author User Manual.25 In short, the document skeleton is opened, modified, and saved under the same name. Of course, appropriate cautions for backups should be made prior to changing anything. For each new Tutor implementation, I will generally review each document skeleton with client representatives early in the project, and obtain their approval of the content and structure before initiation of document owner training and extensive document editing. If changes are required, they are documented in supplementary notes, appropriate backups are made prior to the changes, and Author and Publisher features are fully tested. As a general rule, modifications to existing document skeletons are relatively harmless, as long as key word segments (such as �This procedure covers� or �The Job Title is responsible for�) are never changed. Author and Publisher programs require precise wording in several areas, and the project leader must be aware of these prior to making changes to document skeletons. Creating New Document Skeletons Clients may request a new document type to follow existing templates, or consultants may decide to use a new skeleton for test scripts. This is nearly the same as modifying an existing document skeleton, except that it will be saved under a new name, rather than the same name. The skeleton may be named almost anything, but if the name is short enough, it will appear in its entirety in the Document Type window, since Author only displays the first 25 characters. An important warning is noted in the Author User Manual: �Note that although you can create any document type you wish, and Author will display it as a skeleton, Publisher will only index the Tutor document types (PRO, INS, REF, FOR, COD, EDU, CUR, NAV, LAB).�26 This should caution the project leader to always save draft documents with one of the 9 prefixes noted in order to have them included in the Publisher index, reports, user manuals, and HTML-based documents. This means that the project leader can create a Glossary document skeleton, 25 Mary R. Keane, User’s Guide for Oracle Tutor Author Release 11i (11.5.6) (Redwood City: Oracle Corporation, 2002), Ch. 9, Pg. 3. 26 Ibid., Ch. 9, Pg. 4.


use it for multiple draft documents, and save them as REF document types. They will properly be recognized by Publisher. Changing styles in the Author.dot file Oracle�s Author User Manual spends very little time on this subject, and for good reason � it is filled with risk. Every project leader should heed Oracle�s cautions on this point. The manual states, �It is recommended that you do NOT alter these styles. Much of the functionality and methodology is built around formatting and correct use of styles � it is possible that a change may inadvertently affect Tutor software.�27 Oracle further recommends that style changes for documents designated for company intranets be handled with changes to the style sheet, not the Author template. However, if the project leader is forced by client requirements to make changes in the Author template, it is a straightforward process. It follows the sequence one would take to make changes in Normal.dot, the most common Word template for the average user.

1. Open a document � new or existing � by clicking on the Author icon. This will load the Author template on the current document.

2. Verify that the Author template is loaded. Select Tools > Templates and Add-Ins from the Word menu. 3. This will open a dialog box entitled �Templates and Add-ins.� At the top the current template will be

identified, with the file location highlighted in blue. Even though the middle section indicates that the template is not loaded � because it is not checked � it is.

4. Close this box by selecting Cancel. 5. Select Format > Style from the Word menu. 6. This brings up a dialog box entitled �Style.� The left side of the box lists the styles in use, while the right

side of the box describes the currently selected style�s features. 7. For this example, assume that the client does not like Times New Roman for the Actor font, but wants Arial

instead. Select the Actor style on the left side of the box at the top of the list. The style attributes are displayed on the right side: �Body Text + Font: 16 pt, Bold, Centered, Keep with next, Keep lines together, Pattern: 20%.�

8. Select Modify near the bottom of the box. 9. Select Format > Font at the bottom of the next box. 10. Change the font to Arial at the upper left of the next box. The font will be previewed at the bottom, and it

will look like 16 point Arial. 11. Select OK. 12. Select Add to Template and OK in that order. 13. Select Close. (Selecting Apply will apply the revised style to the paragraph at your cursor position, which

may lead to undesirable results if you are not positioned on an Actor line.) 14. Scroll down through the document to see that the Actor font is now 16 point Arial against a 20% grey

background. 15. Exit the document. It is not necessary to save the document unless you made other changes to it. 16. Word will ask �Do you want to save the changes you made to Author.dot?� If you select No, then the

template will revert to the styles in existence prior to your changes. If you select Yes, then the template will be saved and all future documents opened with the revised template will adopt the style changes just made.

Most importantly, the project leader should backup the Author.dot template prior to making any changes, fully document the changes that were made (including the dates), test every feature imaginable, and provide revised copies to applicable users. In addition, the project leader should follow Oracle�s advice to �use the exact same style name,� or unpredictable results may occur.28 Modifying the Tutor.css style sheet The changes one can make to the Tutor style sheet, Tutor.css, are nearly limitless, and there is little harm in experimenting. Since the style sheet deals only with formatting the HTML output of Tutor files, changes here

27 Ibid., Ch. 9, Pg. 7. 28 Ibid.


should have no effect on publishing, document integrity, or anywhere except the displayed output in a browser window. While the possibilities for making changes are limited only by one�s imagination, in reality the client�s display preferences or intranet requirements will usually drive all modifications to the Tutor.css file. Many clients prefer to have internal documents formatted a certain way, perhaps with color standards, special footers, or positioning on the page, for consistent display on their intranet pages. If the project leader is not familiar with editing style sheets, help is available at the World Wide Web Consortium�s Cascading Style Sheet page (http://www.w3.org/Style/CSS/). More likely, the client�s Web development staff will assist the project leader by providing a copy of the approved .css file or making the changes in Tutor.css and returning a revised file for use by the Tutor project team. A recent client implementation resulted in several changes to Tutor.css, all of which were simple to make. For example, this client wanted a certain header font size and color for the Author Section Title style and Tutor.css Tableheader values such as �Procedures�, �Business Forms�, and �Reference Documents.� He also wanted to change the link colors so the user�s browser settings controlled them. As a result, the following changes were made to Tutor.css in the \Tutor11i\HTML folder: Section Title changes included a 12 point font in a bright red color. The original lines are commented out below, and the changed ones are immediately below the commented lines.

P.SECTIONTITLE { /* font-size: medium; */ font-size: 12pt; /* color:#336699; */ color:#e8112d; font-weight: bold; margin-left: 0.1in}

Tableheader changes were similar. The font color was changed to bright red, the centered headings were left-justified, and the font size was specified precisely, as above.

P.TABLEHEADER { font-weight: bold; * font-size: medium; */ font-size: 12pt; /* text-align: center; */ text-align: left; /* color:#336699; */ color:#e8112d;

Link colors were changed back to browser defaults by commenting out the following lines:

/* -------------------------------------------------------------------------------- */ /* Removed so that the end user's default browser settings will control link colors */ /* A:link {color:#663300} */ /* A:active {color:#336699} */ /* A:visited {color:#996633} */ /* -------------------------------------------------------------------------------- */

http://www.w3.org/Style/CSS/


Changes such as these can be tested immediately by modifying and saving Tutor.css and refreshing the browser window for your test documents. As before, the project leader should make appropriate backups prior to changing anything, and should test one � and only one � feature at a time while making those changes. Once the modifications have been firmed up, copies of the Tutor.css file should be provided to all Tutor participants who need it. Changing the Abbreviation Table Most clients will not think to ask the project leader for changes in the abbreviation table, but they may suggest some abbreviations in the flowcharts that aren�t already there. Since the seeded table only includes 50 values, several of them duplicates to handle upper and lower case requirements, there is a good possibility that the project leader will be making additions to this table. Thankfully, with recent Tutor releases, Oracle has provided an Author interface that improves the ease of managing this table and ensures greater accuracy with any changes. This section will provide several guidelines for managing the abbreviation table that are not included in the Customize the Flowchart Abbreviation Table section of the Author User Manual. The seeded table already lists several Oracle Applications, such as Accounts Payable, Accounts Receivable, and General Ledger. These are often department names, but for this example they should also be considered as module names. The Tutor project leader may want to expand the list so that it includes other modules.

• Review DOCREG.xls at project inception to determine which module abbreviations should be added to the table.

• Backup the master abbr.dat table on the Tutor project leader�s PC (or wherever the master document resides).

• Make changes through the Author interface or by using Notepad to edit the file directly. (Any ASCII editor can be used for editing, but Word should not be used.)

• Make table changes early in the project, so that all document owners doing procedure editing use the same values.

• Distribute changes to applicable users by providing a copy of abbr.dat to replace the seeded table. • Document any additions or changes in a supplementary document, since there is no provision for including

comment lines in the abbr.dat table. Additional Features

While the previous section covered documented features of Oracle Tutor, this section will describe additional undocumented capabilities available through Tutor or Word functions. These may be useful if client requirements impose an expectation of creativity on the project leader. As always, the project leader should fully test all program functions after each change. In addition, it is essential that changes be documented, either in the source documents or in supplemental files located in Tutor project directories. Displaying Standard Document Properties in Headers or Footers Oracle provides several customization options with headers and footers. As described in the Author User Manual, the project leader can specify content and some formatting in both, and control the appearance with style changes to font, spacing, and tab location.29 Moreover, any changes to the header or footer can be saved to the Author.dot template for re-use in other Tutor documents. This will facilitate a standardized appearance to Tutor procedures, support documents, courseware and user manuals.30 While the project leader is free to enter text of any kind in the three header lines or three footer lines available, there is little guidance in the Oracle documentation on how to use document property fields in these areas. For example,

29 Ibid., Ch. 9, Pg. 5. 30 The header and footer contents for HTML files are controlled through the header.txt and footer.txt files located in the \Tutor11i\Author\HeaderFooter directory.


the seeded values for footer fields include copyright information on line 1, document title and file name on line 2, and effectivity date, page numbers and revision number on line 3. See Figure 4 for an example of this. This can, of course, be rearranged to accommodate client copyright information or other text, but one must wonder what additional fields can be inserted here. Field names and format switches are suggested with the �filename� field contents � {filename \*upper} � which looks suspiciously like the formatting parameters for normal Word fields. Not surprisingly, it is. The curly braces are used by Author to separate text from fields, and the field switches are identical to those used for standard Word fields (Insert > Field > Options). For example, changing {filename \*upper} to {filename \*lower} changes the display of the field to all lower case, just as expected. Changing the switch to something unrecognized by Word results in the message �Error! Unknown switch argument,� also as one would expect. At first glance, these options appear to be limited to the five document properties applied to each document through the Author > Document Properties menu selection � document title, effective date, revision, site, and key words � and several others, such as file name or page number. However, other standard Word document properties may also be displayed in the header or footer areas of Tutor documents. In fact, nearly any document property listed under File > Properties can be displayed in the header or footer area of a Tutor document, although many of them are not very useful. Selecting the General, Summary, Statistics or Custom tabs of the File > Properties area reveals some that may be helpful in implementation efforts, especially if the client insists on precise information on document headers and footers. For example, one client wanted to display the original author�s name in the center field of the middle footer line. The Tutor project leader inserted {author} and the client was initially satisfied, until he decided he wanted it in title case. A formatting switch was applied so the text read {author \* caps} and the client was much happier. In another case, a client insisted on a copyright date that changed from one year to the next. This was solved by inserting the following text in the first footer line: Copyright © Client Name, {date \@ "yyyy"}. Internal Use Only. The field date kept the date current and the formatting switch \@ "yyyy" displayed only the year, suppressing display of the month and day. In a third case, a multinational client wanted to display a site name in the header section of each document, partly to ensure that documents specific to one site were easily identified by other users. The document controller inserted the field {site} in the first header line and instructed all users to make the same change. Individual documents included the values �North America,� �South America,� �Europe,� and �Asia� as applicable to their usage, and the correct site name appeared at the top of each document page. When the client wanted the site name to be displayed in 14 point Arial, the document controller changed the Header style to 14 point Arial, applied the Header style to that line, and the client was very pleased. These examples illustrate that dozens of standard Word fields, and several fields unique to Tutor, can be inserted in headers and footers of Tutor documents, and the display characteristics controlled through changes to the selected style. Earlier in this section, I stated that values in the File > Properties area can usually be displayed in headers and footers. Each Word document includes a section under the Custom tab of File > Properties where the document author can create new fields.31 Each of these can be displayed by Tutor if the appropriate field name is inserted in one of the header or footer fields of a Tutor document. For example, if a client wanted to include the value �Typist� in the footer of a document, the field {docproperty "Typist"} should be inserted at the desired location in the footer. However, the value must first be defined in the Custom tab of File > Properties first or it will display the message �Error! Bookmark not defined.� Field-specific formatting switches such as \* caps or \* upper can be used to control appearance, if desired.

31 A quick review of the fields already listed shows 27 default values, from �Checked by� to �Typist.� These are offered by Microsoft as suggestions for what can be done in this area of File > Properties and by no means prevent the user from defining new ones.


Including Graphics in Document Headers and Footers While the preceding features are beneficial, they generally deal with text-based information. On one occasion, I worked with a client who needed a company logo displayed at the top of each page. A review of the Oracle user manuals indicated that company logos and other graphics could easily be inserted in document skeletons, but this only printed the logo once � at the location specified in the skeleton.32 It did not provide the ability to display a logo at the top of each page. Using information gained from my experiences with Word fields described above, the field {includepicture} was identified as a possible solution. The text string {includepicture "c:\\Tutor11i\\html\\PerthosConsultingLLC.tif "} worked successfully (substituting the Perthos logo for the actual client logo, of course) and the client logo was printed at the top of each page. See Figures 5 and 6 for examples of this approach. Several points should be considered: First, the logo must already be located where indicated in the text string noted above. In this case, the graphics file was located on the local drive in the same location as HTML output files. Second, the field-specific switch \d was not used as part of the includepicture string, since it was preferable to permanently insert the graphics file into the document rather than link to it each time the document was opened. Third, the syntax for referring to the file name and location required double quotes and double backslashes as illustrated in the example above. This prevented Word or Author from thinking the backslash was a switch indicator. Finally, the graphics file must already be sized correctly so it would fit within the header area. In this case, the client preferred a logo approximately .33� in height, so the logo graphic was sized to meet this requirement. Any graphic file too large for the header area will not display correctly. Using Multiple Word Variables in Headers, Footers, and Document Skeletons Based on this experience, it became apparent that many standard Word variables or fields could be inserted at specific points in document skeletons, headers, or footers, if necessary to meet client requirements. While this paper does not suggest a great deal of experimentation in this area, it is helpful for project leaders to remember that such options exist in the event a client makes unusual requests. It is possible that a predefined Word field can be used, and it is certainly possible that a custom Word field (File > Properties > Custom) can be employed if no other solution can be found. As with many aspects of Oracle Tutor, this is limited only by the project leader�s imagination � or the client�s demands. As always, the project leader should test each aspect of Tutor thoroughly when using undocumented features such as the ones described here. Many aspects of Tutor depend on styles, phrases, or sequences, and may not function as expected if changes are made. Printing Manuals to File rather than Printers Any Tutor project leader can tell of his first time printing a desk manual, and having hundreds of pages coming out of a workgroup printer. Not only does this waste a large amount of paper, it tends to alienate his co-workers. Oddly, Oracle Publisher doesn’t have a built-in feature to save desk manuals or user manuals to disk. Instead, Publisher always sends them to the user�s default printer. Fortunately, there may be a workaround, although it is somewhat cumbersome. If the Tutor project leader has the Publisher software installed on his PC, then it is also possible he has the full version of Adobe Acrobat installed. During that installation, two additional printers are added to the list of defined printers for that workstation � Acrobat Distiller and Acrobat PDFWriter. In all likelihood, neither of them has been selected as the default printer, since the project leader is probably using a network printer for all his printing tasks. (How else did he send a ream of printouts to the shared printer?) The project leader should select the Acrobat PDFWriter as his default printer before initiating any large printing jobs through Publisher. Acrobat Distiller has more printing options, but the documents will end up under C:\Program Files\Adobe\Acrobat 4.0\PDF Output if version 4.05 is installed, and the documents will be awkwardly named

32 Ibid., Ch. 9, Pg. 3. Although the Author User Manual states that a user can add company logos to headers and footers, it refers the user to the section �Customizing Headers and Footers� 2 pages later, which is silent on the matter.


(example: Microsoft Word - REF0695Y.pdf). Instead, PDFWriter places the files under the appropriate \Tutor11i\MANUALS folder, but each successive manual printing job will overwrite the title page and table of contents from the one before, so the project leader must move them to safe folders at the completion of each print job. Either way, the documents must be assembled in Acrobat by appending them to one another until the entire document has been created.33 Summary

The first two sections of this white paper covered people and technical challenges as well as customization options possible with Oracle Tutor and Word. These tools can be useful to the Tutor project leader in coping with unusual client expectations or normal resistance to change from project participants, among other things. However, during the fast pace of most projects, individual elements or key steps may be overlooked until later in the project, resulting in time-consuming rework and disappointed project participants. The next section will list many of the most common implementation steps, sequenced in a start-to-finish manner.

33 Yes, it�s time-consuming and definitely not enjoyable, but it�s probably the easiest way to �print to file� through Publisher.


Implementation Check List

Introduction

Many implementation elements can be grouped logically from project startup to completion of training. Most of the important ones � from the perspective of the outside consultant � are listed below. 1. Consultant Infrastructure

Facility

• 24-hour access to facility obtained? • Company or client ID badge provided? • Office or cubicle provided? • Working conditions acceptable?

Tools

• Telephone installed? • Voice mail established? • E-mail established? • Client-owned PC provided? • LAN account established? • Multiple LAN logins possible? • Multiple LAN connections available? • Permission to use consultant PC on client

LAN? • Permissible to add portable hub or switch to

LAN? • Personal firewall permissible?

Other

• Scope of work understood? • Timetable agreed? • Consultant role defined? • Client manager identified? • Status reports required? • Status report format provided? • Expense parameters identified? • Consultant added to project e-mail

distribution? 2. Human Factors

Leadership

• Executive sponsor identified? • Executive sponsor briefed? • Project leader identified? • Document owners identified?

• Document specialist, controller, or publisher identified?

Document Writers

• Who will create or modify model documents (SMEs or consultants)?

• Who will create or modify courseware (SMEs or consultants)?

Trainers

• Who will deliver end user training prior to implementation?

• If SMEs will be trainers, what is plan for developing their training skills?

Other

• How will knowledge transfer be performed between consultant(s) and SMEs?

• Are job titles (EMPLTBL.DOC) identified? • Policy on location of draft or working

process documents and courseware files? 3. Technical Issues

Network

• Network space adequate? • Network speed adequate? • Do project leader and document controller

have Full Control status on Tutor folders? • Can Tutor documents be installed to

T:\Tutor11i, where T: is a mapped network drive?

• Has ORIG folder been set to �read only� status?

• Do all end users have �read only� access to ORIG folder?

• Do all end users have �write� permissions to Draft folder?

• DOCREG.XLS password protected for all but project leader and document controller?

• Are all Tutor documents backed up daily?

Tutor Software

• License � number of users identified? • License � is this number adequate? • Software on site? • Software current? • All relevant patches downloaded, reviewed

and deployed?


• DOCREG.XLS updated with relevant documents from applied patches?

• Each end user�s Author and Publisher (as applicable) programs work as expected?

• If passwords will be used to protect key files, are the passwords documented?

• Full version of Adobe Acrobat installed on the Publisher PC?

• If so, does it work as expected?

Other Software

• Operating system acceptable? • Word version acceptable? • Security patches and service packs applied? • Adobe Acrobat software license obtained? • Will Acrobat work with Word version on

site? • Screen capture software determined? • If so, is it available to all process document

and courseware writers?

Hardware

• Each end user PC platform adequate (OS, Word, etc.)?

• Training platform the same as the end user PC platform?

• Dedicated Publisher PC available?

HTML-Related

• Will modifications to the tutor.css file be required to conform to company intranet requirements?

• Will Oracle Applications On-Line Help be used?

• Does Publisher have full permissions to publish HTML files to intranet location?

4. Customizations

Advanced Installation

• Will any changes to Author.dot be made? • Will language-specific model documents or

courseware be required? • Will language-specific .rul tables be

required? • Will language-specific document skeletons

be required? • Will there be any changes to the

abbreviation tables? • Have default �Document Properties� been

identified and rolled out to all end users?

• Have default headers and footers been identified and rolled out to all end users?

• Are these changes, if any, applied to each end user�s PC during software installation?

• Has a company style guide been consulted for any unique requirements?

Additional Features

• Is there a requirement for unique display of standard fields in headers or footers?

• Is there a requirement for graphics in headers or footers?

• Will other Word variables be required in documents?

• Is there specific copyright wording for document or HTML-based footers?

5. Client Deliverables

User Manuals

• Have the model process documents been reviewed for suitability to this implementation?

• Will printed user manuals be required? • Does the client have a print shop available? • If so, can the print shop produce adequate

student guides? • If not, how will manuals be printed?

HTML-Based Documents

• Will there be intranet delivery of user manuals?

Courseware

• Have the model courseware documents been reviewed for suitability to this implementation?

• Will printed student guides be required? • Does the client have a print shop available? • If so, can the print shop produce adequate

student guides? • If not, how will manuals be printed?

Other Documents

• Has the �Key Events� document been modified to include any unique client or company requirements for this implementation?

• Has the �Software Installation� document been reviewed and modified for this implementation�s unique PC platforms?


6. Training Environment

Facility

• Is a classroom setting available for Tutor user training?

• Will each participant have his or her own PC?

• Is an overhead projector available? • Does it work? • Does it work with the trainer�s PC?

Hardware

• Are the PCs in the classroom adequate for training?

• Is the software installed on the PCs? • Can the instructor �slave� the PCs or will

each user have full control of his or her PC? • Can the instructor limit internet or e-mail

access during class sessions?

Tutor Users

• Have all document owners been identified? • Have all courseware owners been identified? • Has Tutor training courseware been created

or modified for this company? • Are student guides printed and available for

Tutor user training?

Courseware Recipients

• Have courseware recipients been identified? • Are company-specific PowerPoint templates

required for delivery of training?


The Final Word

The suggestions in this paper merely scratch the surface regarding Oracle Tutor�s capabilities. Each implementation will bring unique challenges � and each project team will develop new solutions to those challenges. As the product matures and new features are added, Tutor practitioners will discover new applications for each feature, or develop workarounds for elements that still don�t meet their needs. While this is occurring, the practitioner can use the concepts introduced here to make sure each Tutor implementation is more assured of success, and that clients are ultimately satisfied with the outcomes.


Appendix 1: Tables and Figures

Figure 1

In this example, members of the Document Owners group are unable to modify, write, or otherwise control files or folders in the ORIG folder and its subfolders.


Figure 2

This screen shot of the author�s CPU performance demonstrates that his CPU is 100% consumed with the PowerPoint import process, while memory usage (217436) is approximately half of available physical memory (523696).


Figure 3

Current patches are available by searching for �Tutor (pro)� as the product, �MS Windows 95/98/NT/2K Client� for the platform, and �All Product Patches� for the search limit. At the time this search was executed, 17 patches for Tutor were listed, including many for new foreign language model documents.


Figure 4

Seeded values for footer fields include copyright information on line 1, document title and file name on line 2, and effectivity date, page numbers and revision number on line 3. Note that header fields are blank and the Header style is assigned to each line. The user should realize that the Header style is undefined � and unused � in both Normal.dot and Author.dot, and can be modified without great risk by the Tutor user.


Figure 5

The author�s default header and footer values are illustrated in this screen shot. Part of the {includepicture} is visible in the upper left field of Header Row 1. The full value is {includepicture "c:\\Tutor11i\\html\\PerthosConsultingLLC.tif "}. In addition, the date format is illustrated in the right field of Footer Row 1, where only the year should be displayed following the copyright notice. In this example, all other fields remain identical to seeded Oracle values.

Figure 6

The resulting header includes the Perthos logo in the upper left corner as specified by the value {includepicture "c:\\Tutor11i\\html\\PerthosConsultingLLC.tif "} in Header Row 1. The logo graphic will appear on all pages using this method.