Recently in Sacred Cows Category
Okay, so I have not been the most faithful blogger, lately. I was going to make an excuse about increased micro-blogging on Twitter or social activity on Facebook, but those have fallen rather dormant as well, so I have no good excuses. I do, however have some good news, and that is some guest postings from my friend and colleague, Matt Goldner.
So today, guest columnist, Matt Goldner, Product and Technology Advocate, contributes his thoughts on sharing systems and workflows to deliver a more effective experience to patrons. In his new role, Matt will be on the road visiting libraries to see what new things are happening in the community. I'm hoping he will be a frequent poster to Hectic Pace (Hectic Goldner?) and make up for my periodic slacking.
Take it away, Matt....
While attending the 2009 Information Delivery Services (IDS) Conference in Oswego, I saw a challenging presentation on a new service the project is building for the members. The Getting It System Toolkit (GIST) was discussed and demonstrated. The service offering itself was interesting and well thought out but it is the concept behind it that really challenged me.
library collections. The focus of GIST is instead to break down the silos that library staff experience in their supply chains for information selection, acquisition, accessioning and description. The truly radical part is the premise that libraries are simply another supply chain to each other and that the workflow between inter-library loan departments and acquisition departments should be broken down.
The end goal of GIST is for ILL and acquisition departments to use the same service to manage their selection and ordering process with the ability to also get the descriptive record into the systems it needs to reside in. I view this type of thinking as critical to the future of libraries. We often continue to maintain workflows and look for new systems that will support these old methods. Instead projects like GIST challenge some basic concepts and assumptions and give us the opportunity to change workflows to match the real needs of today's library.
For more information on GIST: http://idsproject.org/Tools/GIST.aspx
-Matt
In case you're wondering how many cows are in this pasture, I started
counting and figured I could keep this series going for at least the
rest of the calendar year. How long can I milk this one? After a
while, though, it begins to look whiny and tired, so I thought I would
end with a cow for which it might make sense to make more hay. (there,
have I...ahem...butchered that metaphor enough?).
Some of last week's work had me thinking about notes fields in bibliographic and item records. Boy, do we love notes. We didn't quite have the guts to call them what they really are--miscellaneous fodder that doesn't really fit in a real MARC field. No, we went one further, and created 48 different kinds of notes and put them in the 5XX fields. Was that enough? Of course not. Let's throw in ten more (590-599) for local notes. Anyone else think we could have just scanned the whole book in the time that it took to write all those notes?
If social tagging in library catalogs is library 2.0, then notes were our 1.0 effort. We fret over their protection, their proper migration, where they display, their impact on keyword indexes, and the new relevance algorithms required to make sure they get just enough weight as we migrate MARC records to new bolt-on catalogs. Notes run the gamut from arcane impossible to interpret codes and numbers to the invaluable characteristic that distinguish one book from another.
Putting my OCLC hat on, I can't help but argue that at least the local notes belong with the item record, not the bibliographic one. The MARC Holdings record (MFHL, MFHD, LHR...whatever you want to call it) makes a place for both local and staff notes, and if it's truly local in nature, shouldn't it go there? This is mostly a rhetorical question...believe me when I say that I have no intention of getting into an argument with catalogers on this one--a fight that would leave me beaten and bloodied.
What if all those notes--like social tags--were put in a great big pile, used semantically, indexed accordingly? What if all the little localized changes to OCLC bibliographic records were put in a pile and "localized" for local purposes. We might end up with 80% chaff in the pile, but the results could be interesting. Our notes are somehow sacred, but are they as useful as they could be?
Some of last week's work had me thinking about notes fields in bibliographic and item records. Boy, do we love notes. We didn't quite have the guts to call them what they really are--miscellaneous fodder that doesn't really fit in a real MARC field. No, we went one further, and created 48 different kinds of notes and put them in the 5XX fields. Was that enough? Of course not. Let's throw in ten more (590-599) for local notes. Anyone else think we could have just scanned the whole book in the time that it took to write all those notes?
If social tagging in library catalogs is library 2.0, then notes were our 1.0 effort. We fret over their protection, their proper migration, where they display, their impact on keyword indexes, and the new relevance algorithms required to make sure they get just enough weight as we migrate MARC records to new bolt-on catalogs. Notes run the gamut from arcane impossible to interpret codes and numbers to the invaluable characteristic that distinguish one book from another.
Putting my OCLC hat on, I can't help but argue that at least the local notes belong with the item record, not the bibliographic one. The MARC Holdings record (MFHL, MFHD, LHR...whatever you want to call it) makes a place for both local and staff notes, and if it's truly local in nature, shouldn't it go there? This is mostly a rhetorical question...believe me when I say that I have no intention of getting into an argument with catalogers on this one--a fight that would leave me beaten and bloodied.
What if all those notes--like social tags--were put in a great big pile, used semantically, indexed accordingly? What if all the little localized changes to OCLC bibliographic records were put in a pile and "localized" for local purposes. We might end up with 80% chaff in the pile, but the results could be interesting. Our notes are somehow sacred, but are they as useful as they could be?
Though I heard it in a much different context once, I like to apply something from religion to the world of libraries (don't worry). Preparing the congregation for a "radical change," a senior pastor told his flock: "There's a difference between 'tradition' and 'traditionalism'." Tradition is what we do all the time and for some good reason. Traditionalism is what we do all the time but we can no longer recall the reason. I think libraries excel at traditionalism, and I have been giving quite a bit of thought to the processes we use to perpetuate it.
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.
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.
Sorry for the long gap between cows...I had some technical difficulties that were making it hard for me to blog. On with it...
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?
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?
About the Author
