To place the university in the proper position to enter the world of Office Automation, first, a campus wide freeze was placed on the spending of funds for office automation equipment and second a committee was struck to review the needs of the university and to suggest the most appropriate route to take owards the goal of Office Automation. The first task at hand was to belay the rumours of layoffs and position losses that would result because of automation.The committee was therefore staffed by members of the various parts of the university community, union employees, administration and academics. All people who would be affected by the changes being considered.. The committee's mandate was twofold: a) to introduce automated equipment to the clerical and administrative staff implementing new effecienies and increasing productivity while reducing the cost of the paper flow and b) introduce a new methodology of interdepartmental and inter-personal communication.
To do this the equipment and software selected must be capable of wordprocessing and maintaining a communication link through the university's administrative computer centre. The new systems would be centred in the administrative computing area and aimed at supporting the administration omponent of the university. The academic computing centre of the university was expected to follow suite and provide similar functions to their client base. Tenders were sent to the major players in the field at the time.However, the majority of those approached dropped out as their systems could only provide one-half of the solution. The company that was finally accepted was IBM (International Business Machine). Their solution was for the placement of IBM Displaywriters and printers as the standard clerical workstation and PROFS, a mainframe software package to be the communication medium. To support he administrative staff IBM 3270 type terminals would be used. The displaywriters would have 3270 emulation cards as the link to the IBM mainframe so they could use PROFS in their supporting role to administrators.. Since there were two distinct participants in the solution, clerical staff and administrative staff, two installation, training and support plans were needed. But first the question of line authority had to be established. Since this support unit was not in the clear realm of mainframe operations it was felt that they should not be part of or controlled by that group. Also since this was totally new technology being introduced as a direct result of a request from the President's it was felt that the direction and the intent would be bettered received if the operation had the direct support of the highest level of administration ie. the President. Therefore the Office Automation Support Group was aligned with the President's Office and key university personnel were seconded to act as managers of the group. This was to remain in place until 1989 when the group was placed under the direction of the Department of Administrative Systems. Being placed under the President's Office gave the group its right of existence and legitimacy empowering them to carry our the intentions of the administration.
Implementation of clerical support in Office Automation
The first of over 240 Displaywriters began to arrive in March of 1983. To prepare for this implementation it was necessary to have a training team and classroom in hand. A room was constructed on the 4th floor of the Biological Science building to house the training centre. Twelve workstations were installed, each from a different manufacturer. It was planned that each trainee would use each station over the three day training period and evaluate the furniture. From their evaluations a standard for office workstations was determined. The introduction of training staff this was a bigger problem. It had to be determined whether it was more cost efficient to have in-house trainers or to hire an outside training company. In-house was the choice because of the realization that there would also be a need for immediate close support. Who better to provide that support than someone on site and with a full knowledge of the workings of a university. This is especially critical from a knowledge and time factor when designing and implementing systems that are particular to a university setting. One must remember that the operation of a university is no different than that of a major corporation. A university has the very same types of operational departments that one would find in a major corporation plus the added problems due to a much wider range of subject areas, often handled in a foreign language. The first training period of six weeks was conducted by staff from IBM. Not only did they train the university clerical staff but also the new university trainers. Each class was three days long. Two days back-to-back with a third day about two weeks later. First day was basic concepts, machine operations and university standards to get the staff members used to working with a more complex piece of equipment. The third day was spent covering functions that maybe unique to the department of the trainee. This may cover such things as the use of sub/superscript, foreign languages and foot notes. While the staff member was in training an installation team removed the old equipment and replaced it with the new units.This was done to stop the staff from returning to the old because it may be easier. This was found to be true especially in the creation of labels andprinting of envelopes.
The myth that old staff can't learn new tricks was quickly dispelled as those coming through the training class prove to be able and quick learners. Some still tended to treat their new equipment as old typewriters and did not attempt new or innovated ways of doing things. However, many chose to challenge the technology and proved to be very capable of entering this brave new world. Another problem that arose was to do with the expectations of the administrators. Although warned to expect a slow down in productivity they expected and demanded the opposite. Many even held back work so it could be done on the new units with its better font capabilities. These individuals had to be revisited and re-educated.
After the initial six week period, the university assumed its full role as training and support provider to the newly initiated. The initial project consisted of the installation of 120 units. This number doubled within 18 months. The support staff drew from 1.5 to 2 FTE.
Implementation of the PROFS (AOSS) System
In conjunction with the introduction of the Displaywriters, a second team was involved with the implementation of the selected communication package. For those senior clerical staff members supporting senior administration, a communication card was installed in their unit. This card activated by a toggle key allowed the unit to emulate a 3270 type device. Each administrator had a 3278 terminal placed on his or her desk enabling them to attach to the IBM mainframe. The adding of new people to the system was determined by the President's Office. The first to be added were the senior executives of the university, followed the members of the senior advisory group and their secretaries. The implementation process for this group was determined by the Physical Plant and the ease of laying cable. To support the program each user had to be attached by coaxal cable to the mainframe. It would not come too pass for a number of years that standard telephone cable could be used. Having this type of control we were able to manage the growth pattern. allowing us to uniformly install the unit and train the individual. It was by policy that no user would be issued a userid without attending a training class. Most came along willingly, but several because of position and/or lack of time received one-on-one training in their office. For secretaries and clerical staff it was a full eight hour, divided between lecture and hands-on. For administrative types it was a three hour lecture and one hour of hands-on. It was felt that the secretary would become the first point of support and should be better trained to handle the problems. From an initial pilot project of seven people for a duration of three hours, the user group has spread across the campus and now totals over 1100.
FUNCTIONS
Mail
The mail function is the most heavily used, sending an average of 150,000 pieces of electronic mail each month. Of these approximately 35% are sent via distribution lists. An additional 16,000 per month are sent to users other than those on AOSS. Using INTERNET we can and do receive and send e-mail around the world. The problems encountered in the sending of mail had to be solved by resources other than IBM. As in most cases with IBM software, users are restricted by an imposed limitation of eight character fields, be it paragraph names, file names or e-mail addresses. As long as the sender wished to send mail to a BITNET site there was no problem. However, INTERNET addresses containing up to 256 characters could not be dealt using the current PROFS software and PROFS sites could not upgrade the original code since it was never delivered. IBM did however, build in exits that allowed users to attached extra code to perform in-house functions. By using these exits the remote mailing function was enhanced to allow delivery to and receiving from INTERNET sites. Mail that has been received may be, forwarded to a third-party(s), replied to or resent to another party. The user may either discard or store the note in an electronic filing system. Mail being sent maybe stored as well in the same filing system. In-house functions written to enhance the useability of the system included: the ability to search for notes containing a particular string, the ability to maintain the filing system, the ability to create nickname files and distribution lists. The university has its own listserv system where as many as 40 lists categorized by subject or user group may be addressed. The user community can subscribe to orunsubscribe from these lists as they wish.
Calender Each user is assigned their own personal calender. They decide who has access to their calendar and what level of access. The initial level across the user community is that each user may see another user's calendar, but only the time of the entries never the reason for the entry. An individual user may decide to give another user the capability to read and/or update his or her calendar.This of course is quite common between secretarial staff and administrators.As well there are public calendars that are viewable by all users such as the EVENTS calendar maintained by the Dept. of Public Affairs to present an index of the current events on campus.
Calendar is still not used as heavily as one would expect. There is and always will be the "Big Brother" aspect to deal with in regards to people being able to track one's activities. As well the calendar is not easily portable like the well used and liked pocket date books.
Reminders Each user has the capability to set reminders. These reminders come in two modes. One that pops up on the main screen at a prescribed date and time, and then disappears when the screen is cleared. The second is an in-house function written to provide the users with the capability of creating a "tickle" list.This tickle list appears on at sign on time and the items within the list willremain there until the user deletes them.
SRAD (search, Retrieve and Display) This function was introduced as the result of a request from the administration. They wanted to be able to store within a database the results, conclusions or minutes of various committees on campus. A number of solutions such as STAIRS were reviewed but none fitted the criteria. As a result SRAD was developed. It allows a user to store on a centralized database information that may be retrieved as the result of a contextual search. The document is displayed in DW370 format, an old mainframe wordprocessing software package. Selected documents may be downloaded to a PC for printing. These documents are presented in WordPerfect format.
Posts A posting of all the employment opportunities on campus. Positions are posted by job category. This list is maintained by Human Resources.
Maintenance A mail function that presents a template that when completed is mailed directly to University's maintenance department. This function has greatly enhanced the delivery of maintenance service on campus. The department has remained effective even though downsizing has reduced the level of clerical support.
Phone The university telephone directory is displayed on line. This directory is kept current by the Dept. of Communications and delivered to AOSS on a weekly basis. User can also maintain their own personal directory which is searched as well during the phone search function.
I listed just a few of the functions available to users of the AOSS system.What should be realized is that when IBM delivers the software it is a barebones package. The standard functions of mail, calendar, database and reminders is what is delivered. All of the rest of the functions are in-house or traded from other sites using PROFS. The in-house functions are there because a user saw a need and requested help. The rule of thumb when dealing with such requests is coverage. If the function could only be used by a few then chances were slim, if it could be used by a department or faculty then chances were better. However if the function could be justified as one that would enhance the effectiveness of the user community as a whole, the scarce resources would be made available to develop and implement.
Present and Future Since the introduction of Office Automation in 1983, the environment has changed and so have we. With the introduction of PCs in 1984, many of the 3270 type terminals have been replaced with personal computers. In 1990 all displaywriters were upgraded to IBM PS/2 model 55sx. After years of fighting with IBM, the decision was made to reset the standard for administrative units using wordprocessing software. It was decided to move to WordPerfect not only because they were the only company that had site licence agreements in place but we felt that the software being offered suited the current and future needs of the university. From then until now the Office Automation group has expanded its role on the campus. That is in the services provided. It has assumed the training role and in some cases the support role for a number of PC database and spreadsheet packages. The Office Automation group supports over 750 clients with a staff of 1.4 people and .8 contract people. These people supply the in-house training, handle help calls and do system analysis tasks as well. There is an expectation that in the near future Office Automation will support MicroSoft Word.
Lessons Learned
Throughtout the pre-implementation and implementation a number of lessons were learned. These lessons came either from site visits where others had preceeded before us or as the implementation proceeded. To list a some of them:
A) Staff that are affected by the change must be involved in the planning
B) Authority for the change must come from the highest levels of the organization
C) Training is a must.
D) On-going support must be in place and well advertized
E) Seek out and use natural leaders in each unit to supply local support.
Al Judson
Back to report list