OCLC has released more modules for their “cloud-based” integrated library system. This has lit our fire. We’ve known for awhile that we need to review how we use our ILS and determine if there is a business case for retaining it or migrating to another option. The OCLC option represents a sea-change in library automation. It’s the only web-services based ILS in the current market.
It is time for us to stop talking and start doing. We know how in a rough sense (needs assessment, functional requirements, review). It’s the devil-y details which make the process intimidating. The ILS is one of the largest expenses in a library. Almost all daily work processes touch it. It is a capital B big deal. Any mistake will be costly.
So, we’re planning. Something concrete will emerge shortly. Meanwhile, I await the publication of this . Guidance of any sort is welcome at this stage in the game.
I anticipate doing a thorough review of the integrated library system here at MPOW within the next couple of years. A wise friend once told me, “there are two types of librarians. Those who have done an ILS migration. And those who will.” I’ve been lucky so far. In 15 years as a librarian I haven’t yet had the pleasure migrating an ILS. It remains to be seen if we do a migration here. Periodic review of systems is necessary due diligence. There is always a chance that we will discover our current system continues to meet our needs.
There have been many developments in the field since this library implemented its online catalog. The number of vendors selling ILS has declined through mergers & acquisitions and economic attrition. The open source ILS movement has grown with the development of Koha, Greenstone, and others. There has been a movement to dis-integrate the integrated library system by separating the search layer from the administrative inventory modules. The options available are somewhat overwhelming. It’s time to evaluate the current state of the marketplace to ensure that we’re providing the best possible system for our customers needs.
That’s key. One needs to understand the functional requirements of a system before one can evaluate options. There’s no point going out to test drive cars if you don’t know why you need a car and how you’re going to use it. So we need to do some user needs assessment. This could, and should, take many forms. I haven’t yet brainstormed the different modes of information gathering available. There is usage information from our current systems. There is human inquiry to find out how our customers use our systems (surveys, interviews, focus groups). There is current workflows analysis to determine how we utilize our systems from the back end. All of this information can be translated into use case scenarios for our “ideal” system. Obviously there is no perfect system. The idealized system provides us with an evaluation template, however. We can prioritize which components of an ideal system are most critical. Then we have a check-list of features that we compare to the functions provided by any given system.
It sounds simple in writing. In practice, it’s a long and difficult process involving multiple library departments and a variety of stakeholders. I’m glad it’s not an imminent project. It’s on my mind though. I’m monitoring developments in the field and gathering quite the file of documents for my “to-read” pile.