Andrew K. Pace: August 2008 Archives
In the first two posts in this series, I have attacked services and policies, both of which are strongly supported by the traditionalism of system migration. I find it insanely ironic that after long RFP and shopping processes to improve our lot, the first step in migrating from one system to another is to ensure that the new system works just like the old one did (the other irony is that the first post-migration step is to beatify the old system that was once so hated).
More often than not, a libary system vendor will send a consultant onsite with a big spreadsheet and a large group (mostly librarians, of course) will sit around and cram old policies into that new spreadsheet. Rarely would the vendor propose a standard list of item types, languages, or circulation policies. No, each library is unique, just as each libraries patrons are unique. Right then.
Next, the catalogers and IT professionals debate indexing rules. We don't want to have to re-index this database any time in the next 5-10 years, so let's make these decisions stick (thankfully, a new generation of online catalogs is already tipping this cow). Once we've determined all the stuff that will hold us for the next decade and replicated all of the traditional policies, it's time for the 'data fretting' to start.
"What do you mean I can't migrate Acquisitions Code #1 from my old system to the new one? If code #1 equals 'a' then I know that it was purchased from that special fund created by Professor Styckndamud in 1962! Someone might ask for a report on that fund!" Granted, we do indeed use some of these data (some more often than MARC data, which flows to and fro between systems like it was designed for data transfer instead of public display...oh, wait...).
So we load the data, and we load it again, and again, and again. Rarely do we ask ourselves how much we need those data. Take it from someone who has done two coast-to-coast moves, and just completed my 6th house move in a dozen years...asking "do I really need this" is a useful exercise. We like to think that because it is data, it's intangible nature makes it's movement and storage simple, but even data has a cost that often far exceeds its value.
I'm not suggesting that changing systems should be as easy as flipping a switch. I am suggesting, however, that it should be more akin to profiling online services than building a system from scratch. We're in the mood for change these days, it seems. New systems are the at the beginning of change. New interfaces are at the other end of the change. Let's play both sides against the middle and see what we can do about changing the way we change.
I've been thinking about one of the most bloated sacred cows in library management systems. No, not the MARC record--I'll leave that one to others. I'm talking about Circulation Rules. It's become almost cliche to compare what we do in libraries (and this accusation is pointed primarily at academic libraries) to a typical commercial customer service.
Picture me at the Blockbuster checkout desk.
Me: Hi, I'm visiting here for the next six months and was wondering if I could check out your movies.
BB: Um. Can you verify your residency to prove that I should trust you?
Me: Yes. Here is a signed affidavit from the CEO of my company who moved me here. He can vouch for my credibility.
BB: Yeah, okay. I can make you a "visiting resident with special privileges." You'll get movies for 3 days fewer than other "regular" customers. Oh, and you can't check out new releases or games. I'll need your Social Security number and a permanent billing address just in case we need to bill you.
Me: Is there any way I can get regular privileges?
BB: Um, well....no.
Me: How many other users have this kind of borrowing privilege.
BB: You're the only one. We add profiles for people like you one at a time.
Who are we helping by ensuring that the professor emeritus in veterinary medicine gets bound periodicals for 3 days more than a full professor? I'm starting to find Amazon's delivery options confusing and there are only 3 or 4 of them? Why must we complicate something that could be so simple? Without disparaging the gargantuan effort that was the Evergreen ILS development in Georgia, the real victory, I think, was the creation universal borrowing rules.
Take a hard look at those systems, folks. Are all those item types really helping? Are all those patron categories useful beyond reporting usage statistics that rarely lead to any business intelligence decisions? Is it time to simplify?