Two months ago, I talked about some developments of interest from the larger library automation perspective. This month, I’ll take a look closer to home and discuss one of the projects that might be of practical use to a systems librarian or to someone managing a systems office. Whether you’re a one-person operation or part of a larger group, I hope that you’ll find the approach useful. I chose this project to write about because it involves both exciting technology--Web-enabled databases--and practical experience that I’ve gained by providing support for the Vanderbilt University libraries.
One of the biggest challenges that a systems office faces involves managing the problems and requests that come in from library staff and users. The incoming flow of tasks often seems relentless, and without an effective set of procedures, processes, and tools, a systems operation can really get bogged down. In this column I’ll focus on some processes we have implemented at Vanderbilt to deal with this issue.
Keeping Up with Demand
I lead the library technology team at Vanderbilt’s Heard Library. Our group comprises 10 staff members who are expected to provide a wide range of services for a large academic library that relies heavily on technology. Our computing environment is large and complex, and includes over 350 desktop computers, 10 Novell NetWare servers, three large UNIX servers, and three Windows NT servers. We manage the SIRSI Unicorn system for basic library automation, OCLC SiteSearch for virtual catalogs and some locally built digital collections, an electronic reserves system, a large SilverPlatter ERL server, the library’s Web servers and its mail server, and a number of Web-enabled databases using Inmagic’s DB/TextWorks and DB/Text WebPublisher. Given that there are about 250 library staff members and all these systems and services under our care, it isn’t surprising that we always have a fairly high number of problems and requests to deal with.
A Problem-Management System
We consider it very important to provide a high level of support for these computer systems and services. To facilitate this goal, we’ve developed a Web-based problem-tracking system (PTS) to help us manage our work. Such a problem-management system must include a number of features to be effective. It should store all the details about each task presented to us, manage workload, and help identify priorities. It should provide all the necessary information to the person assigned to carry out the work, and it should give the person requesting the task feedback on the status of his or her request.
There are a number of commercial products on the market that perform these tasks, but we chose to develop our own for several reasons. First, the commercial products are rather expensive. Also, we wanted the experience of developing dynamic Web-based applications, and we felt that we could create a system that would be more responsive to our needs than one we might buy. Finally, there were a number of other projects in the library that would benefit from our ability to link databases with the Web.
The technical portion of PTS consists of a database that holds the information about each task, Web forms for retrieving information from the database, Perl scripts that process the requests, and a piece of middleware that allows information in the database to be presented on the Web. But even the most efficient automated system cannot work well without the right human elements.
Using the Products
We selected DB/TextWorks and DB/Text WebPublisher from Inmagic, Inc. (www.inmagic.com) to power this application. We looked at a number of other competing products, and found these to be rich in features, though a little high in price. DB/TextWorks specializes in the management of text-oriented information. It can deal with numerical information to a large extent, but doesn’t necessarily shine in this area. One can link databases together to establish a relational structure, but it isn’t a true relational database--it is a multi-user database with record locking and other features to prevent data corruption. The real strength of DB/TextWorks lies in its ability to manage large amounts of text, and to store and retrieve that information efficiently. I was very impressed with the information-retrieval speed from a DB/TextWorks database, even with large data sets and many queries on the same database occurring simultaneously. DB/TextWorks is one of the few applications I’ve used lately that hasn’t become bloated in size as its features have become more sophisticated.
DB/Text WebPublisher is a set of programs that can be placed on an NT-based Web server to pass queries from a Web browser to DB/TextWorks and deliver the results back. Special templates and forms can be defined in DB/TextWorks to control how the results will be formatted in HTML as they are presented to a user on the Web. With very little effort, it is possible to use the graphical editor in DB/TextWorks to create Web displays, or you can program the HTML directly to gain full control of the display to build highly customized applications. It’s the same for the Web pages that prompt users for search criteria--you can either let DB/TextWorks create a basic one for you, or advanced users can craft the Web forms by hand to control every detail of appearance and function. I like the fact that you can get it going with just a small amount of effort but then work up to building more advanced applications.
DB/TextWorks and DB/Text WebPublisher find their greatest popularity in special libraries where they are used for basic library automation functions as well as managing full-text information resources common in law firms, corporate libraries, and similar types of information centers. These products don’t find a lot of use in large academic libraries because they fall far short of being a full-blown library automation system for a complex multi-library organization such as ours. But that isn’t a problem for us, as our SIRSI Unicorn system fulfills that function quite nicely. We also have OCLC’s SiteSearch for creating large-scale local databases. SiteSearch is a large and complex environment that takes considerable effort and expertise to develop an application. DB/TextWorks and DB/Text WebPublisher complement these other systems nicely. They work well for applications that need to be fast and efficient, but that don’t need to support Z39.50.
DB/TextWorks and DB/Text WebPublisher are just examples of software that can be used for creating Web-enabled databases. I won’t go into all the alternatives, but there is a variety of options available, ranging from free, open-source applications to expensive, large-scale commercial products.
The Technical Components of PTS
The problem-tracking system that we developed with the Inmagic software includes a number of software components.
The DB/TextWorks database. We defined a database with a record structure that has fields to hold the data related to each task: who reported the problem, time/date reported, department, room/building, description of the problem or request, priority level, time resolved, the person assigned to work on the problem, actual time spent working on the problem and description of the steps taken to resolve it. A status field indicates whether the task is still active or if it has been resolved. Another field automatically calculates the time between when the task was reported and when it was finally resolved. We’ve developed a Windows-based form where this data can be keyed or pasted in from other sources, such as a mail message.
Web submission form. We created a Web form that library staff can use to submit new problems and requests. This form guides staff members through the process of submitting their requests using drop-down menus, radio buttons, and fill-in fields.
Perl processing script. When the Web form is submitted, it is processed by a Perl script that validates the information, checks for required fields, and sends an e-mail message to our help desk operator so that the information can be put into the problem-tracking database. It also writes the information to a data file so that the information can be imported directly into the database without re-keying. Essentially the e-mail message acts as a notification that a problem has arrived and needs to be processed.
The Web query form. An HTML form and a set of reports were created in DB/TextWorks and DB/Text WebPublisher to query the database and list results. This provides a convenient way to list all the tasks in any given category. A technician on the team, for example, can easily display all the tasks currently assigned to him or her. Anyone who has submitted a request can use this form to see its status and whether any action has been taken on the problem.
An update form. When displaying the record for a task, a link is displayed that can be used to send updated information. Clicking this link invokes a form that allows additional information to be added to the record. The user might use this update form to send follow-up information about the problem, to ask about when it will be finished, or to tell us that it has resolved itself. The technicians often use this update form to record what they’ve done to resolve the problem and to indicate that they’re finished with it and are ready for it to be closed out.
Report generator. Another HTML form generates statistical information from the problem-tracking system. One can simply use the set of drop-down options to select the month in question. Pressing the submit button will cause the system to display the number of requests completed in that month and the total time spent, tabulated for each library unit. This report instantly generates the information that we previously spent many hours accumulating.
The Human Components
Just as important as the hardware and software components, we have developed a set of principles, processes, and priorities that underlie our service operation.
Single point of contact. One of the keys to making sure that the system works well involves making sure that all requests and problems are reported to a single source. For various reasons, the name NetFix describes this clearinghouse. This single point of contact can be accessed in many ways, however, including telephone, e-mail, and the Web forms. We’ve worked hard to train staff to send their requests and problems to NetFix rather than send them directly to the individual members on the team. Concentrating the requests into a single source allows us to prioritize and assign the work to the individual that can most quickly resolve the issue. Many times library staff members have ended up frustrated because they sent their requests to an individual technician’s mailbox, not knowing that the person was on vacation or away for training.
Well-defined priorities. We know that we won’t be able to solve every problem instantly. The number of tasks that come in each day often exceeds the resources available. Given that some issues are more important than others, we’ve defined a set of priorities that help us decide which tasks get immediate attention and which must wait. In general terms, anything that affects the users of the library’s systems and services gets higher priority than those that affect library staff. Problems that have more widespread disruption obviously need more attention than those that affect a single user. Requests for new software or functionality take a back seat to fixing established systems and services.
Consistent operation. It takes a lot of discipline to keep up with an automated problem-management system. Each individual in the technology team must spend some time every day working on PTS to document their activities, to close out problems, and to send e-mail to notify staff that their problem has been resolved. Inconsistent and incomplete information in the PTS causes confusion and results in poor service.
Planned and coordinated workdays. The problem-tracking system allows the members of the technology group to plan their days and maximize each trip to a campus library. Thus, the PTS makes it easy for the technician to see all the tasks that might need to be done on-site at a given library, and to make decisions on which ones to attempt to resolve on each trip.
Open communication. We find that library staff members find it reassuring to be able to check the status of their problems whenever they want to. They are more likely to be patient with their pending requests if they are confident that they have not fallen through the cracks. We’ve found that it is vital to notify staff when we think that their problem is resolved, let them test it, and confirm with us that it’s really fixed. We don’t close out a problem until the person who originally reported it agrees that it’s resolved.
Efficiency Pays Off
The time that it takes to operate the problem-tracking system places a certain amount of overhead into our overall workload. You might wonder whether the time that it takes to document each task performed and to follow all the procedures related to the PTS actually saves time over a more informal system. Though we have not made a great effort to collect formal data on the time savings, it is my observation that this system helps us work much more efficiently and more than makes up for the time we invest in its maintenance.
An important by-product of this system is that the PTS serves as a local technical-support knowledge base. Technicians can access easily the descriptions of the steps that were used to resolve a problem when the same problem comes up again. Other library staff can sometimes figure out how to solve problems themselves from the information in the PTS.
See for Yourself
I welcome others to take a look at the problem-tracking system that we use at Vanderbilt. Just point your Web browser to staffweb.library.vanderbilt.edu/libtech/ptsquery.html.
This project is just one example that demonstrates how useful Web-enabled databases can be. We also use this approach for managing access to our electronic journals and for various electronic publishing projects, including an oral history resource that includes streaming audio. I also use DB/TextWorks and DB/Text WebPublisher for "lib-web-cats," a directory of library Web pages and online catalogs that currently lists about 4,500 libraries (www.librarytechnology.org/libwebcats/). Several other projects are underway.
Marshall Breeding is the technology analyst for the Jean at Vanderbilt University in Nashville. He is a freelance writer and consultant in the areas of library automation and networking technologies. He can be reached at http://www.librarytechnology.org/ or marshall.breeding@librarytechnology.org.
