Marc:
I agree with both sides of this discussion--I think both situations are
part of the problem that we and our vendors have made for ourselves.
One of the underlying problems was the push to "integration" in library
systems that has been a feature of the last few decades. This created
situations that both (as Karen points out) resulted in ghastly detailed
RFPs--often derived from templates provided by a few library
consultants--that sought to enforce how standards were invoked in
systems but instead resulted in checklists that provided librarians with
the illusion that they were making choices. This strategy was often an
abject failure from the point of view of the various technical services
functions (as Mark correctly notes) and often pitted Acquisitions
against Cataloging and Circulation against everybody as the various
software packages were compared and contrasted and library directors
were forced into Solomon-like solutions. I remember one of the reasons
given for Cornell's choice of Voyager back at the turn of the century
(!) was that it had a decent circulation module and the circ folks had
been in extremis for years as we struggled with the dying NOTIS system.
This tied us to the deeply dysfunctional Voyage serials control module,
which over the next few years forced library staff into continual
workarounds as standard holdings data was continually degraded to force
the system to "work"--defined then as providing the ability to claim
missing issues.
Clearly we've suffered greatly from this notion that our software must
be "integrated" in that tight manner--often in proprietary ways (as Marc
notes, acquisitions has been particularly affected because of the
standards gap). At least as destructive were the ways systems that from
staff the methods operating behind the curtain, forcing those searching
for understanding to reverse engineer the systems in order to make them
work the way the library wanted, sharing pretzel shaped workarounds with
other sufferers.
Part of our problem is that like the French building the Maginot Line
after WWI, we're still fighting the last war. What systems do or don't
do with MARC data is irrelevant these days--they won't fix the old
systems and the new ones will most likely not be using MARC. But unlike
the French, we should be careful about the lessons we learn, because
they may well send us down the wrong paths as we moving forward.
So how should we shift our thinking as we plan for the future? The idea
that most of these functions can use the same (or more likely some of
the same) data is one of the integrated ILS ideas that still works, but
we won't necessarily want to tie everything together so tightly that one
function suffers to allow others to work properly. As we move away from
MARC data towards options both more various (DC, VRA, EAD, etc.) and
hopefully more modern (RDA) we will have both challenges and
opportunities. I would suggest that the following questions might
provide a way to think about these options:
* Is our insistence on 'records' rather than 'data' one of the things
holding us back? (I think it is)
* Will we need different ways to share data in order to realize the
kinds of efficiencies we need? (I think this is clearly 'yes')
* Are we far enough into re-conceptualizing technical services that we
can think clearly about future needs rather than past ones? (I sure hope so)
It'd be great if we could articulate better what the backroom will need
in the "new" library, because until we do that, it's hard to figure out
how the transition can happen. The kinds of piecemeal approaches we've
been taking (jettisoning deck chairs off the Titanic) don't seem to be
working all that well.
Diane
Marc Truitt wrote:
> 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
>
Received on Sun Mar 08 2009 - 13:58:49 EDT