CAUSE/EFFECT

Copyright 1998 CAUSE. From CAUSE/EFFECT Volume 21, Number 1, 1998, pp. 42-44. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its date appear, and notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To disseminate otherwise, or to republish, requires written permission. For further information, contact Jim Roche at CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301 USA; 303-939-0308; e-mail: [email protected]

Putting the Web to Work: Streamlining Work Flow via an Institutional Intranet

by Perry Brunelli and Lynn Gunn

The Medical College of Wisconsin (MCW) is one of several institutions of the Milwaukee Regional Medical Center (MRMC). MCW faculty and staff often have offices within separate institutions on the MRMC, which include Froedtert Memorial Lutheran Hospital, Children's Hospital of Wisconsin, and Curative Rehabilitation Center. Providing information services and network support to MCW faculty who reside in disparate institutions is a challenge both for users, who often are unsure about what paperwork to complete for a given request and where to send it, and for Information Services staff, who must work closely with their cross-institutional counterparts to coordinate wiring, port activations, software installations, and the like. MCW Information Technology Systems has created a Web-based instance of a common work-order form that uses e-mail triggers to keep concerned parties notified as work requests flow through its system.

The Medical College of Wisconsin Department of Information Technology Systems (ITS) is responsible for campus network support, LAN administration, UNIX system administration, a network help desk, and desktop support. Despite the many technological hurdles we cross each day, our biggest challenge isn't with technology itself. Rather, our greatest difficulty is dealing with a dynamic environment in which users want service as quickly as possible, network jurisdiction crosses institutional boundaries, and the rules for doing one's job can change from one building to the next.

MCW faculty members typically wear numerous hats. Many clinical faculty members have offices both in the college facility proper and in a hospital or clinic. The former areas are directly controlled by the college, while a hospital or clinic site is the bailiwick of the member institution. Given that the various institutions in which MCW faculty reside have their own Information Services (IS) staff with their own policies and procedures for service requests, a simple work-order request isn't always a straightforward proposition.

MCW ITS has historically coordinated work requests via a form called the Facilities Service Order (FSO). The form was initially deployed by the facilities department, which ably provides carpentry, moving, and other such services to the campus. Additional service departments, including IS, quickly found the form a convenient tool for submitting non-facilities requests for two reasons. First, each department has copies of the form, eliminating the need to create a new form for users, and second, the FSO contains a lengthy work-order description field that is useful for detailing network as well as facilities requests. Typical ITS work requests include connecting a workstation to the campus network, configuring a workstation for LAN services, and installing MCW-supported software.

Work orders submitted to ITS via an FSO are assigned to an ITS staff person. That staff person will then visit the site, determine what the job requires, (wiring, port activation, software installation, or network card, for instance) and coordinate with other service departments and contractors to pull the job together. Again, the job location will determine who is involved in software installation, wiring, and port activation, with MCW having direct control over MCW-owned premises. If the site is in another institution, ITS would submit additional paperwork, as appropriate, to request these services.

The problem faced with the FSO is one inherent in all paper-based work flow: delays while paper changes hands. Figure 1 describes the paper flow involved in a typical FSO request.

Figure 1: Paper flow of a typical FSO request
Description Estimated Time
User fills out FSO ans sends to ITS via Campus mail. 1 day
FSO reaches IS; paper copy is placed in manager's mailbox; order is entered into FSO database by hand. 1 day
Manager assigns job to ITS staff; they estimate job 1 day
If fee is involved, form is sent back to department for authorization. FSO authorized and returned to IS. 2-3 days
If wiring is involved, internal, cross-institutional or external wiring contractor is contacted to perform the work. .5 days
Wiring is completed. Activate jack and configure workstation. .5 days
Notify user of job completion. .25 days
Total 8.75-11.75 days

Phase I

In Phase I of our project we addressed the paper-based work-flow problem by making the FSO available as a Web page. To enhance user comfort levels with the page, the Web version of the FSO was made to look very much like the paper version. Our initial objective was simple: to receive feedback from user departments regarding this new method of submitting work orders. In addition to receiving critical and constructive comments on the page, Phase I helped pave the way for buy-in, as our users helped develop the page.

Phase II

After meeting with department representatives and reviewing comments on the page, we implemented changes and worked toward Phase II of the project: making the FSO page do much more than its paper counterpart ever could.

The first enhancement was to eliminate the need for data entry by writing electronic FSO submissions directly to a database. A second, more dramatic, enhancement was the e-mail trigger, which provides for instant e-mail notification when jobs are submitted, assigned, or authorized. For example, when a user submits an electronic FSO, the ITS manager immediately receives e-mail notification of the new job. A separate section of the page allows the manager to assign jobs to an ITS staffer. When the assignment is made, the ITS staffer also receives e-mail notification. The trigger concept was propagated throughout the administrative sections of the page. When wiring is assigned, e-mail notification (including internal, cross-institutional, and private) is sent to wiring contractors. When a job is estimated, e-mail is sent to department administrators requesting authorization of charges. Upon job completion, our department administrator receives e-mail notification that billing is required.

Each of these e-mail trigger recipients has a section of the FSO page. When wiring contractors complete a job, they can update their section of the page, which generates e-mail back to the staff member assigned to perform the work, notifying the staffer that the wiring is complete. The same is true for department administrators, who can authorize charges online and automatically e-mail ITS staffers a notice to that affect.

Additional features

Users who submit work requests can check on the status of their jobs through a special, password-protected section of the page. The "check status" page allows users to easily check on where a job is within the work-flow process. Comments on the "check status" page are derived from staff members, wiring contractors, and management, and are required to be updated whenever a job screen is updated.

Improved work flow

By initiating e-mail triggers at each critical point in the job process, we have eliminated 65 percent of the delays involved in processing a typical work-order request. Just as importantly, if a job is held up for wiring, authorization, or another reason, users have instant, online access to the reason why the job is detained.

Technically speaking

The FSO Web page is written in HTML; Cold Fusion 2.0 provides links to a Microsoft Access 2.0 database. Both Cold Fusion and the Access database reside on an NT 4.0 server. Demonstration versions of the FSO Web pages are available at:

The opening section of this page allows one to enter an e-mail address. If you choose to provide it, you will receive the results of the various e-mail triggers as you walk through the page.

Why it works

An important design tenet of this project was "hands off the user desktop." Our goal was to avoid installation of additional software on a user desktop; no custom applications or plug-ins were installed. The only requirement for access to the page was that users have Netscape Navigator or Internet Explorer -- these applications are commonly available across campus.

Unlike some large corporations where IS solutions are standardized and desktop resources are rolled over frequently, MCW is a diverse workstation environment. Our desktop resources range from 386 PCs to Pentium processors, Macintoshes, and UNIX systems. By adhering to a "hands off the desktop" principle, ITS staff did not have to install software on 3,000 user desktops to roll out the application. Consequently, ITS staff had more time to dedicate to developing the application -- a much better use of resources.

Feedback and future directions

Feedback to the FSO page has been extremely favorable. Users appreciate the ability to check job status and to receive notification on work-order progress. In the future we plan to tie the FSO page directly into MCW's financial system for automatic billing. We also are working with additional MCW service departments to bring their work-order requests online.

Perry Brunelli ([email protected]) manages the Information Technology Systems group at the Medical College of Wisconsin.
Lynn Gunn ([email protected]) is a systems programmer at the Medical College of Wisconsin.

...to the table of contents

[Comments] [Search] [Home]