Truth in Automating: The Multi‐Library Experience
| Pages | 53-68 |
| Date | 01 March 1989 |
| Published date | 01 March 1989 |
| DOI | https://doi.org/10.1108/eb047766 |
| Author | Jon Drabenstott,Marvin E. Pollard,Sara C. Heitshu,John Webb,Michael Madden |
| Subject Matter | Information & knowledge management,Library & information science |
Truth in Automating:
The Multi-Library Experience
A forum edited by Jon Drabenstott:
with contributions by Marvin E. Pollard,
Sara C. Heitshu, John Webb, and Michael Madden
These studies provide a cross-section of current
library automation activity. They illustrate some
of the forces acting on libraries, the growth and
development of the library marketplace, and the
increasing complexity and interrelationships of
automated systems. Above all, they lead to an ap-
preciation of just how daunting automation pro-
jects can be, and how profoundly these new sys-
tems are changing libraries. These contributors
have administered projects in which many successes
have been realized in often difficult, but not
atypical, circumstances.
The first installment of this column appeared
in Issue 25 of Library Hi Tech. As stated in the
original introduction, "The series does not seek
the 'how-we-done-it good' article, nor a graphic
expose of the marketplace. Instead, contributors
have been asked to provide thoughtful, penetrating
administrative observations of how their automation
experiences differed from their expectations, and
how others could approach automation projects
more realistically."
This second and final "Truth in Automating"
column includes four more case studies, contributed
by Marvin E. Pollard from the University of Alaska,
Fairbanks, Sara C. Heitshu from the University
of Arizona, John Webb from the Oregon State Li-
brary, and Michael Madden from the Schaumburg
Township Public Library in suburban Chicago. Each
administrator was given the same questions listed
in the first "Truth in Automating" column to help
structure his or her observations. Readers are
referred to the first column for the complete list
of questions.
Although each of these systems evolved quite
differently, they have at least one common theme.
Each automation project is, or has been, part of
a larger system. The Alaska project (VTLS) was
ambitious, and included the state library as well
as the state universities. Similarly, the Schaumburg
Library had been part of a consortium, but made
the difficult decision to separate from the library
cluster and implement a CLSI system on its own.
At Arizona, the Innovacq system was implemented
alongside a GEAC circulation system. The Oregon
State Library implementation (DRA) was perhaps
closest to an independent system, but it, too, ex-
Drabenstott is Associate Dean for Library
Services at Eastern Michigan University, Ypsilanti,
Michigan.
ISSUE 27 53
panded through an array of databases and informa-
tion resources to provide remote service through-
out the state. The four projects unfolded as they
did for many reasons; taken together, these case
studies represent a number of options that libraries
typically face in an automation environment that
has become increasingly complex and interrelated.
In exploring how these libraries pursued their
separate automation initiatives, it is helpful to
look first at the impact of external events on the
projects, then examine each project from the per-
spective of the vendor and the library.
External Events
External events did affect these projects.
The most dramatic example is perhaps the severe
decline in the Alaskan oil economy that changed
the budget climate completely for this state's li-
braries. As a result, the Alaskan libraries were
pressed to fund the original ambitious automation
plan, or later upgrade the system. Although some
of the original plans were scaled back, there is
considerable evidence that other factors, par-
ticularly organizational issues, systems problems,
or unclear expectations, contributed at least as
much to these planning revisions as funding con-
straints. Despite the decline of the oil industry,
the project did move forward, albeit with some
delays and modifications, and administrators were
ultimately successful in upgrading the system.
In a less severe example, the Oregon State
Library was unable to complete its retrospective
conversion project because of funding limitations
but the larger automation effort proceeded despite
consequent operational inefficiencies.
In short, while external events can sig-
nificantly affect automation projects, particularly
their schedules, such factors do not appear to be
the overriding determinants of success. Further,
in most cases, librarians appear able to minimize
the effects of outside circumstances.
The Vendors
Another project element that extends beyond
a library is its relationship with its vendor. Most
of the comments in these case studies are favor-
able toward vendors. In the first column, a num-
ber of librarians were troubled by "vaporware" or
slow delivery of equipment or services. These
contributors cite few such problems, however, that
are clearly the sole responsibility of vendors.
Madden, for example, notes how helpful the
Schaumberg vendor was during the transition from
the consortium to an independent site with a newly
separated database. Similarly, Webb stresses how
Oregon's vendor met every deadline. Nevertheless,
problems with technical assistance and documentation
noted in the first column recurred in these case
studies along with a number of other vendor issues:
• Technical Assistance and Documentation.
Automation projects present major technical
challenges for most libraries. Many of the
technical problems cited in these case studies
are frequent or typical. For example, Webb
mentions the unexpected difficulties and costs
encountered with computer room construction.
More seriously, Pollard discusses an initial
system design that proved to be seriously
flawed.
During project implementation, automa-
tion planners must make many technical de-
cisions. Administrators must be able to define
these decisions in their appropriate sequence,
determine options from all pertinent informa-
tion at hand, and craft organizational decision-
making processes that are efficient yet collec-
tively supported.
Vendors cannot be separated from these
technical decisions. Any information or docu-
mentation that a vendor does or does not
provide will inevitably have a bearing on this
complicated decision-making trail. For ex-
ample, Heitshu expresses regret that the Arizona
library did not have earlier and more complete
system documentation to assist with system
decisions. While vendors may have little invol-
vement with or influence in how client libraries
make decisions, vendors can provide written
documentation, technical assistance, and even
occasional strong advice to help outline deci-
sions and options. Such assistance can contri-
bute to more successful installations, more
client satisfaction, and a more positive product
image. Conversely, frustration with technical
matters during implementation can easily lead
to frustration with vendors. Such assistance
should not take away from the local administra-
tion of a project; librarians must retain respon-
sibility for making informed decisions. How-
ever, it is in the interests of both libraries
and vendors to understand and cultivate such
advisory roles for vendors.
• Training. After the initial sale of the system,
training can provide important person-to-per-
son contact between a vendor and a library.
As such, training can represent much more
than providing essential system information
to library
staff.
For example, the unfortunate
change in trainers at Arizona did negatively
affect the staff's perception of the system.
Because direct, personal interaction between
a library and a vendor can be very limited
54 LIBRARY HI TECH
To continue reading
Request your trial