[Prodev] Other factors in migration

Jean Willis jwillis@sdcll.org
Wed, 07 Nov 2001 16:12:25 -0800


Georgia just responded to some of these important issues and covered a lot of the
bases in her email.  I'll attempt to answer some of the other issues that Rob
raised.  These are important issues for all libraries to consider.  Before I address
issues directly, it's worth noting that attendance at any continuing education
seminars concerning any of the issues, below, is recommended.  For example, my LAN
Manager and I both attended a couple of different Z39.50 classes offered in our area
prior to migrating.  Our Cataloging staff attended MARC21 classes, and so on.  The
issues raised by Rob generally are more technical in nature, and ongoing training
may be the best bet, if possible.

Additionally, everything he brings up, below, should be addressed in one fashion or
another in your RFP.  See below for my comments.

Richards Robert wrote:

> Greetings:
>
> Could list-members comment on other selection criteria for IOLS systems
> such as the following?
>
> * Compliance with standards (e.g. EDIFACT, Internet standards,
> Z39.50, USMARC, etc.) ---

Compliance with Z39.50 is an absolute, but continuing ed is worthwhile to
familiarize yourself with the differing versions of Z39.50; what Z39.50 really
means; and how it is supposed to operate. Find out what version of Z39.50 the vendor
supports.  It's rather complex to launch into further details here, but check your
local area for classes offered by different types of library associations.  This is
not a law library issue solely.

EDIFACT is also required.  Most of the vendors should offer this.  Same with USMARC
and MARC21.  Smaller libraries may find these somewhat less relevant, but it pays to
learn about these and determine for yourself whether they are or will become
relevant in your library situation.

> * Database structure (e.g. relational);

Even if you are not database "savvy," it's best to include an RFP question as to
what the database structure is.  There is dispute as to whether it's absolutely
necessary for a database to be strictly relational or not.  Some vendor's products
do not fit the strict definition of a relational database, but they still work
fine.  If you have further questions about this, it may be worthwhile discussing it
with your IT folks.

Actually, having IT people assist you with questions about the technical side of the
product is also worthwhile, unless you feel you have the training and/or expertise
to handle this yourself.

> * Customization (e.g. to what extent can librarians/patrons modify the
> interface?) ----

This is, indeed, a critical question, and one that I struggled with during our
decision process.  Some vendors' products are much more "open" or user-customizable
than others.  There are pros and cons to both sides.  What I discovered for our
situation was that we simply did not have enough staff to support the more
customizable products that we reviewed and considered seriously.

Those products were very good and would have suited our needs and handled our
database just fine.  However, those particular products required a lot more user
intervention, maintenance and upkeep than some other products.  The product we chose
allows a certain amount of customization, but it requires less support and upkeep
from my staff.  Due to staff size and time limitations, I felt that we had to go
with that.

Another issue here to consider is:  who is responsible for maintaining, upgrading
and troubleshooting the hardware, the operating software (e.g., most larger ILS's
run on Unix, which requires specialized knowledge and expertise to manage and
upgrade), and the database software, itself.  Again, depending on your situation,
this can become critical.  We chose a vendor where we did not have to manage this,
ourselves.  Although we probably have the knowledge and expertise to do it, our IT
staff is, quite simply, too small and overworked to take on these additional tasks
ourselves.  We saw it as a means of outsourcing this work.

> * Support for e-commerce (electronic ordering, claiming, invoicing);

Again, this is critical.  Nearly all libraries, if not all, will want to have their
ILS have these capabilities.  Again - good RFP question:  How does your software
handle...

> * Support for electronic collections (e.g. electronic reserves; linking to
> full text publications; delivery of sound and image files as well as
> text).

As above, another RFP question.  Obviously, electronic reserves will probably only
be relevant to academics, but I suggest asking questions about the other issues
listed above.  Even if you are, for example, a small law firm, it's worth having as
much knowledge about your system's capabilities as possible.

While the delivery of sound and image files may seem less relevant to some, it's
quite likely that we will all be dealing with this at some point in the future.  It
pays to ask and see how robust the software is - or how much extra such capabilities
might cost.

Don't forget to ask about URL management and maintenance in the Catalog.  Does the
software support some type of automatic URL checking?  Does the software support
hyper-linking from URLs in the Catalog?  These are important issues to consider when
writing your RFP.

> Thank you,
>
> Rob

Jean
______________________________
Jean L. Willis                          jwillis@sdcll.org
Assoc. Dir. for Information Systems     (619) 531-4443
San Diego County Public Law Library     (619) 238-7716 (fax)
1105 Front Street                       http://www.sdcll.org
San Diego, CA 92101-3904