Coordinating Committees

CUWL Library Management System Exploratory Task Force

DRAFT Final Report – October 8, 2009

Charge
“The task force is charged with developing a vision for a new library management system (LMS) for all UW libraries. The committee should provide an environmental scan of options currently available and on the horizon, both proprietary and open-source.   In addition, the committee should review the initiatives of other libraries and library systems, in the state, region and nationally. The committee should consider options that can connect to other computer applications (e.g. student information systems, course management systems, campus financial systems).”

Background

While reading through this report, it is important to distinguish the work of this task force from the work of the CUWL Resource Discovery Exploratory Task Force (RDETF).  The RDETF is concerned with the OPAC and other tools which our patrons use to find or discover information that we own or provide access to and then to deliver that information via the best method possible.  The LMS Task Force is concerned with the staff-side of the automation system--the larger, underlying system that that we use to acquire, purchase, catalog, inventory and circulate those physical (and sometimes electronic) items we own or license.  The OPAC and the staff modules no longer have to be integrated in the same automation system (i.e. Voyager).  They can be totally separate from each other and still function well together.

The UW libraries have been using our current integrated library system (ILS) (or library management system—LMS), Voyager, since late 1999/early 2000.  Voyager still functions quite well for many things, but there are a number of needs that it no longer fulfills/performs well. The following limitations were pulled from the published literature, reports from other libraries and discussions of the task force.  These apply not only to Voyager specifically, but legacy ILSs in general:

1) It was designed for a print world, but more and more of what we offer to patrons is electronic and doesn’t “live” in our library building.

2) It doesn’t always work well with campus systems (e.g., single sign-on) or involves more work or redundancies than should be necessary (e.g., loading patron data, working with the financial side).

3) Staff interfaces are cumbersome--too many clicks.

4) We have to use tools outside the ILS to get things done (e.g., MarcEdit to modify records before loading them into the catalog, Access/SQL to create reports).

5) We’re all doing the same things locally that would make more sense to do at a higher level (e.g. downloading bib records for the same titles, making local modifications that aren’t shared back to the larger community, customizing user interfaces).

6) We don’t always have good integration between our systems (Voyager, SFX, MetaLib, ILLiad, homegrown ERM systems).

7) Bug fixes and enhancements are always needed, but slow to materialize.  Our vendor is not as responsive to our needs as we would like.

8) It’s not easy to export our data to make it available for other purposes.

Voyager will not be significantly developed in the future.  There are two more minor releases expected prior to the projected end of product development.  The software vendor, Ex Libris, is already developing a next-generation resource management product called the Unified Resource Manager (URM) that will replace Voyager in the next 10 years.

The Task Force feels it is important to be proactive in this matter by researching the options and preparing staff for the eventual replacement of Voyager.  Whatever the change is, it will be disruptive to many staff.  To minimize stress and disruption, we want to ensure that UW System has thoroughly analyzed the options and chosen the best replacement with input from a wide variety of stakeholders.

Environmental Scan of Options
We did an environmental scan of options currently available or in development in order to make initial comparisons with what we have now.  14 open source and proprietary products were identified using professional literature sources, blogs, library marketplace reports and conference sessions.  For a complete listing of products reviewed, see the Appendix.  Most of these products are not considered suitable replacements for Voyager at this time.  Many were developed for public or school libraries rather than academic libraries, or are not appropriate for a consortium.  Many are not scalable to a library of Madison’s size.  Several are not practical because the customer support is located overseas, making it difficult to receive help during normal business hours.  The well-established products which are direct competitors to Voyager (such as Innovative Interfaces Inc.) do not offer anything significantly better to justify the tremendous cost in staff time and money to migrate to a new system.  Two of the open-source products (Koha and Evergreen) are intriguing but are not yet well enough developed to recommend at this time. 

The OLE (Open Library Environment) Project, however, is intriguing in a different sort of way.  OLE has the advantage of incorporating flexibility to allow for future growth in the system.  It places an emphasis on enterprise level integration in order to connect with other campus systems such as business financials, student databases and authentication systems in a more seamless fashion. Aimed specifically at academic and research libraries, one of the OLE founding partners is the OhioLink consortium.  This will bode well for development that will truly meet the needs of academic institutions such as ours.  What really differentiates it from other open source software is that it says it will not just replicate the concepts of software we already have, but will transform library workflows so we can manage changing services and resource formats—this is not just replication of a traditional ILS.  OLE also has a governance model that is more appealing than the open source with vendor model.  OLE will have tiered membership that represents different levels of involvement but will “ensure that all participating members have a voice in the development, maintenance and propagation of the code consistent with each tier as well as a commitment to the project’s ongoing success.”  LibLime’s model is more that of a gatekeeper where they are the sole decision makers as to what development will be pursued and when. 

A summary of all the options:

a) Stick with our current vendor, Ex Libris, and eventually upgrade from Voyager to their new URM - under development
b) Switch to another vendor – proprietary software

i) WorldCat/OCLC LMS – under development
ii) Innovative Interfaces Inc. – well established competitor

c) Choose an open source product (like Koha or Evergreen) and develop it ourselves.

i) This would be much more complicated than the resource discovery development work currently being done by the UW Madison Shared Development Group.

d) Choose an open source product and contract with a vendor to assist with migration from Voyager and future development (Koha with LibLime or Evergreen with Equinox)
e) Commit to the OLE Project and eventually migrate - under development
f) Wait for other options; the landscape is changing quickly and other products may be developed in the next few years

Initiatives of Other Libraries
There wasn’t a great deal of specific information available on the initiatives of other academic consortiums that are also considering a possible migration.  The Kansas State University Libraries, however, happen to be in a very similar position as UW System.  KSU libraries are also a large academic library consortium currently using Voyager.  They formed an ILS Task Force and were charged to “1) Identify functional and system requirements for the K-State Libraries and vet them with the library administration and staff and 2) Evaluate available options, both proprietary and open source, against approved function and system requirements, and make recommendations to the library administration on the strengths and weaknesses of available options.”  Their phase I report focused on the high priority and standard requirements of a new LMS based on focus groups and conversations with library staff.  The full report can be found at
http://ksulib.typepad.com/ilstf/files/library_systems_evaluation_task_force_report_part_1.doc

Many of the high priority features they identified are the same ones our task force has discussed: 

  • An improved catalog interface
  • Reports that can be run by anyone in the library
  • Easy-to-use staff interface with better integration between modules
  • Improved bulk record handling and global changes
  • Interaction with other systems such as financials and the student information system as well as ILLiad, SFX and MetaLib.

Their results identified several driving principles that will affect their evaluation of systems: 

  • Retention of existing functionality
  • The public interface is “broken”
  • Integration of modules
  • A system should have an existing user base and clearly established vendor support network

Their phase II report, located at http://ksulib.typepad.com/ilstf/files/integrated_library_system_task_force_phase_2.doc has four recommendations:

  • Migrate to an open source integrated library system (ILS), to be accomplished by 2011
  • OPAC overlay and fixes to Voyager in the interim
  • Explore consortial opportunities
  • Continue to monitor the state of integrated library systems

Discussion/What did we learn so far?

a) Reviewed 15 products currently available or on the horizon.  They are at various stages of development.  The mature products have nothing to offer that we don’t already have in Voyager or that would justify the huge expense of a migration.  Others would not work well in an academic consortium.  The open source options are still young and don’t offer all of the functionality we need.  Several vendors and projects are worth watching to see how their products develop in the next 3-5 years.
b) Open source vendors are not necessarily more responsive to their customers than proprietary vendors.  Growth pains occur as libraries become more interested in open source software and small vendors sign on more customers.
c) Enhancement and development with open source is not governed the same for all situations.  Developments are not always released back to the community either.
d) Barriers exist with both open source and proprietary systems--funding, time, resistance to open source, resistance to change in workflows, resistance to switching to a system that doesn’t have everything we currently have.
e) Several campuses are reviewing their services and workflows at the micro or macro level to identify duplication, new services we want to provide and possible services and workflows to jettison. Efficiencies can be gained this way and can prepare libraries for implementing a more streamlined library management system in the future. Although a next-generation LMS alone can result in greater staff efficiencies, a combination of the two would have the greatest payback in terms of reducing effort and complexity.
f) A system-wide analysis of services and procedures is supported by UW library directors. 

i) A union catalog--whether it consists of the holdings of all UW libraries or a subset of a world catalog (i.e. WorldCat) is of particular interest, as well as centralizing the processing of materials for all the campuses. 
ii) An evaluation of Universal Borrowing should be done to evaluate the costs/benefits of UB versus ILL.
iii) Other services besides processing should also be analyzed as candidates for centralization.

g) The Google Book Project will have an impact on our book collection development and other processes.

Task Force Recommendations
1. Continue to watch the changing landscape, to maintain awareness of options and to educate and inform UW staff.
2. Talk to UC San Diego about their experiences to streamline technical processing
3. Analyze our staff workflows and decide what we must continue to do, what workflows and services we can discard, and what we can outsource to others who can do it more efficiently.  In particular, look at UB/ILL; union catalog (catalog once; design one interface), centralized processing and coordinated collection development.  Use this analysis to determine what we need our library management system to do for us.
4. Decide how much control we need to maintain.  Must we host it ourselves, or allow a vendor to maintain the servers, run the backups and handle upgrades for us?
5. Prepare for a possible migration in 3-7 years (although it may not be necessary).
6. Participate in product development with Ex Libris and OLE

Task Force Members:

Marlys Brunsting (Green Bay) Co-Chair
Jon Mark Bolthouse, (Colleges) Co-Chair
Bill Doering (La Crosse)
Sharon Knight (Whitewater)
Jim Lowrey (Milwaukee)
Mitch Lundquist (Madison)
Terri Muraski (Stevens Point)
Jon Musselman (Platteville)
Maureen Olle-LaJoie, (River Falls)
Deb Nordgren (CUWL)
Lisa Jewell (UWSA)