Karen Coyle wrote:
> The one time I worked on an ILS RFP we gathered up RFPs from other
> libraries as examples. Huge amounts of those rfps went into excruciating
> detail on acquisitions, serials control, etc. Out of 100+ pages, usually
> only about 5-10 were on the user interface, while an acquisitions system
> could easily take up 20-30. Talking to vendors, for integrated systems
> libraries select them based on particular management functions -- in
> part because those have to interact well with existing institutional
> practices. I got the impression that the features of the user interface
> were definitely secondary to most system selection.
>
Hmm... well, I have to say that my experience and observations are at
variance from those of both Karen and Bernie. I began my career in
Technical Services, spending many years in Acquisitions and doing a year
of cataloguing special materials (videotaped interviews), as well. I
have yet, in years of talking to acquisitions librarians (especially
those in larger academic libraries) to meet one who considers them to be
any more than just what the vendors advertise, when they disparagingly
refer to them as "ordering and paying systems". Those who do
acquisitions understand their work to be much more than that. It's a
pity that systems designers can't seem to understand that.
The simple truth of the matter is that ILS acquisitions functionality is
all too often at best an afterthought, seemingly tacked onto a product
after the fact. Without local programming, acquisitions systems
frequently don't interface well with larger institutional financial
systems. They don't handle anything other than single-order monographic
items very well. Their management reporting capabilities are pathetic.
And, because there are no standards for ILS acquisitions data, their
content is not very portable -- ask most any ILS vendor, and you'll be
told quite candidly that the stuff that is migrated successfully between
systems least often is acquisitions data. To borrow from Karen and
employ a term I frankly dislike, if OPACs "suck", then ILS acquisitions
systems "suck" twice as badly... at least.
Shirley Lincicum, in her answer to Karen, observes:
> In fact, one of the most frustrating things for me about Next
> Generation Catalog systems as they currently exist is that they seem
> wholly focused on the user interface and can, in fact, actually hold
> libraries back from designing or implementing improved "back end"
> systems because of the dependencies introduced by the new "discovery
> layer" applications.
I would generalize this and posit that the OPAC-centric focus of vendors
long predates such trendy terms as "next-gen" interfaces and "discovery
layers". Walk up to any ILS vendor booth at ALA and first watch what
the sales people are demonstrating. How often are they showing-off new
public functionality or interfaces? Then ask one to show you how the
acquisitions module might track, say, items received as a result of a
deposit account placed with some jobber in Latin America. Very likely,
you'll hear something such as "Oh, that's *acquisitions*... I don't
really have much expertise in *that*." Then, if you are really
fortunate, you'll be shown how to place a one-off firm order for a
monograph. ;)
In places I've worked, Bernie's and Karen's "back office" focus of RFPs
has often seemed turned on its head. Few senior library administrators
much understand or care about "back office" processes, at least, until
they want -- probably to justify further cuts in TS staffing -- a
management report based on the aggregation and analysis of transaction
data whose collection they dismiss as uninteresting and unnecessary. At
the same time, the focus of administrators and library ILS managers all
too often seems to be on the much more visible and politically sensitive
function and appearance of the OPAC. The great irony is that -- as this
thread and this list so clearly show -- all that focus on the public
side seems to result in as little satisfaction for users of the ILS'
public face, as is felt by those of us in the oft-maligned "back office".
Which, I think, raises the real issue here. It's not whether OPACs
suck, or acquisitions sucks, or cataloguing modules, or circulation, or
serials... or name-your-function. They all are terrible; at best, they
are barely tolerable, and at worst, they are abysmal. The question is,
why? There are lots of answers. I'll throw out one, in the hope that
others of you may contribute more, if you agree with my basic premise:
The "suck-y elephant" theory. We all know we're way too silo-ed in
libraries. The ILS is the elephant, of course. PS folks can only see
one leg of the elephant, the one that is the OPAC/discovery
layer/whatever. Cataloguers see their leg. Acquisitions folks see
theirs. Systems managers see their part (the belly? ;) ). Who knows
what part senior administrators -- who by rights should see an entire
elephant -- see from where they sit? And don't even ask who gets to see
the beast's back-end! But we all see only one part, and we're unhappy
with what we see.
It follows, doesn't it?, that if our part "sucks", then *somebody
else's* part must not, else we would never have brought this thing into
our living room, right? Well, no, it doesn't work that way, because
*nobody* is looking at the entire elephant, ensuring that all its parts
fit logically and functionally with each other and the surrounding
environment. The all-too-predictable message that results is one of
incoherence, confusion, and lack of consensus. Karen's RFP may have a
20 page statement of acquisitions requirements, and mine may have the
same for the public interface. And trust me, in neither case will
*anyone* be happy. In neither case will we have anything more than a
very poorly designed and disintegrated elephant.
Vendors focus design efforts on what they think will sell. They will
"hear" from our incoherent RFPs (and user group enhancement request
processes) that we want everything and nothing. We want our new ILS to
do everything our old ILS did (only better). Or, we want our new ILS to
be nothing like our old ILS. We want all of our workflows to remain
unchanged (for "inflexible back-office" staff), but we still want the
product somehow to function well in spite of these archaic workflows.
At the same time, we don't want to offend our public services staff --
or their users, who are "used to things the way they are" -- by
introducing changes in the front-end, even though everyone complains
about it anyway. Adding to all of this is the fact that we can't even
keep our minds made up when we think we've decided something. Five
years ago, in response to customer demands for an ERM that would come to
market quickly and not be delayed by integration into that vendor's
flagship ILS, the vendor in question complied. The other day, I learned
in a conversation with a representative of the same vendor that the
company's three-year roadmap now envisions folding both ILS and ERM
together into yet another solution. Plus ça change, plus c'est la même
chose.
If we can't make sense out of all this noise, can we expect systems
designers -- whether they work for vendor ABC or open-source project XYZ
-- to do any better? Of course not. So, we're still left with that
poorly designed and disintegrated elephant... everything and nothing at
the same time. Indeed, the wonder of it all may be that, as "suck-y" as
our systems are, we somehow in spite of everything manage to get useful
work done using them.
Thanks for listening,
- mt
--
*************************************************************************
Marc Truitt
Associate Director,
Bibliographic and Information Voice : 780-492-4770
Technology Services e-mail : marc.truitt_at_ualberta.ca
University of Alberta Libraries fax : 780-492-9243
Cameron Library cell : 780-217-0356
Edmonton, AB T6G 2J8
"When you've seen beyond yourself
Then you may find peace of mind is waiting there.
And the time will come when you see
We're all one and life flows on within you and without you."
-- G. Harrison (1967)
*************************************************************************
Received on Sat Mar 07 2009 - 13:33:39 EST