FEATURE
How to Conduct a Library Services Platform Review and Selection
by Matt Gallagher
| The apparent benefits of migrating from client-based ILSs to web-based LSPs seem pretty straightforward. ... However, that doesn’t necessarily mean that your library is ready for or wants those changes. |
ILSs are being swiftly replaced by library services platforms (LSPs). While many may find this next-generation rebranding unnecessary, it is true that librarians across the country are in the midst of assessing their ILSs and looking critically at these LSPs and their own technological infrastructures. We’ve been told that these LSPs will seamlessly integrate with all our other systems and software. They are more user-friendly, help create a single log-in environment with learning management systems (LMSs), and free up library personnel and resources. However, it is obviously more complicated in practice than in scripted webinars and sandbox environments.
When considering an ILS migration to an LSP, libraries, more than ever, must think about their digital infrastructure holistically alongside whatever other systems are in place within their greater institution. Further, the marketplace for LSPs and other library-related technology is rapidly changing and must be regularly monitored. Only then can a critical assessment be made to decide which LSP is the best fit for your institution and whether it is flexible enough to grow with your future needs. But where to begin on such a sprawling topic, if you find yourself at a small to midsize institution with limited personnel and resources?
In a previous job, I was charged with evaluating an existing ILS and investigating web-based LSPs as replacement options. As an early career librarian who was new to the institution and largely responsible for all technical services, I had little time and guidance on how to approach this important, challenging, and exciting responsibility. After reading Heidi J. Webb’s “Managing E-Resources: Do You Choose Your Stuff or Did It Choose You?” (Computers in Libraries, October 2014), I wished there was a similar how-to article addressing the situation I was in. Now, as I settle into another job in which the existing ILS is being assessed, I’m gathering my thoughts and summarizing my experience to date for fellow librarians who are looking at their own ILS/LSP needs.
Current Contract, General Finances, and RFPs
Before beginning an LSP assessment, the expiration date of your current ILS must be determined to figure out a go-live date. Look for opt-out clauses or the potential to upgrade to your current provider’s new LSP. Sometimes, vendors will be willing to terminate the contract early or extend it to coincide with an ideal date, hoping to win the future bid for its previous service and this concession. If your current provider offers a new LSP, ask for a rough price quote to gauge expectations moving forward. Importantly, an additional sum of money must be budgeted for one-time implementation costs, which can be more expensive than a 1-year LSP subscription.
Knowing your institution’s RFP process may have a dramatic impact on deciding between vendors later on, especially taking into consideration the first-year implementation fee. For example, if any expense more than $50,000 merits an RFP process, you may lose some control on deciding which LSP best fits your needs and budget. Please note that some vendors are willing to split this one-time fee across the years of a new contract, if it means avoiding an RFP process or accommodating the annual budgetary limitations of any given library.
Survey of Library Users and Colleagues
The apparent benefits of migrating from client-based ILSs to web-based LSPs seem pretty straightforward. Software updates no longer need to be manually run internally. User interfaces are fully mobile and more user-friendly. Reporting functionalities are more robust and are easier to manipulate; they can pull usage statistics directly from vendors. Integrations between systems through APIs have the potential to dramatically reduce duplication. Knowledgebases that are being regularly updated and indexed between service providers and publishers have the potential to lift large burdens off libraries’ technical services staff.
However, that doesn’t necessarily mean that your library is ready for or wants those changes. Summarize some of these larger differences and find out which features are the most and least important to your users and colleagues. Polling student workers is a helpful option if the resources aren’t there to conduct a more random user sample. While your library may not be ready for an LSP migration yet, demonstrating how the library can offer an improved user experience with concrete data for patrons and library personnel can help make compelling arguments for increased funding later on.
Have Conversations Early On
Next, identify the key stakeholders responsible for making this process happen. Who will execute the final contact? Who is responsible for the enrollment, financial aspects, and LMSs? Who in the IT department will need to be involved? Who is in charge of library access, public services, and technical services? Talk to them and find out what projects are looming through the potential go-live date and determine if any other major system changes are being discussed and/or are pending. Ask what systems and software are pivotal to their essential job functions, and discuss if interoperability with the LSP would be desirable.
Looping colleagues in early on minimizes the risk of being blindsided by a competing interest mid-migration. For example, my previous institution was in the process of changing LMSs (WebStudy to Canvas) at the onset of my ILS assessment. Making sure the LSP and LMS were interoperable—in order to achieve a single log-in environment for students—was considered extremely important. Further, our financial and enrollment departments used Banner as its enterprise software. As such, any LSP that had already been successfully integrated with Canvas and Banner was more desirable than those that had not.
Having a list of third-party services that are already in use at your library and institution is a pivotal step in addressing the fundamentals of what an LSP can promise to deliver. This step may ultimately eliminate some LSPs from consideration.
Market and Product Research
Next comes worrying about vendors, interfaces, and features—and how each of those components will affect library services and workflows. It’s important to assess how long the vendors being considered have actively provided library systems solutions, what types of libraries they primarily serve, and how they are rated in comparison with each other. Resources are readily available that provide good entry points into the general landscape, terminology, vendors and their respective products, and the rate at which other libraries are migrating to specific LSPs.
Taking into consideration the user and personnel survey data previously mentioned, it’s best to start a spreadsheet or similar working document that lists out features and any other measurables you’d like to compare. This list will expand as more is learned about each product, but it will be a good shared reference for the stakeholders throughout the process. Also, trying to determine some scale of importance for each feature can help later on in the decision-making process, considering there is a good deal of overlap as far as primary functionality is concerned.
Some of the larger features that I was most interested in confirming and assessing in greater detail included discovery layers and their look/feel customizations, training materials, implementation/migration expertise, link resolvers and A-to-Z list functionality, knowledgebases (bibliographic, authority control, and econtent), e-resource management (including COUNTER statistics harvesting via SUSHI protocol), the analytics/reporting modules and the ability to create dashboards for individual logins, cataloging interfaces, approaches to BIBFRAME and linked data, e-reserves/document repositories, and mobile circulation apps.
Request Price Quotes and Demos
To determine some of the aforementioned product research steps, it’s likely that correspondence between a vendor has already been initiated. During any point of that correspondence, it’s appropriate to ask for a rough quote. In order to narrow down the list of LSP providers, it’s important to have an idea of the asking price. However, once the final list of LSP providers is selected, it’s important to request an official price quote based on a 3- to 5-year contract and begin to schedule demos. Price quotes for annual subscriptions ($7,200–$40,000) and implementation fees ($5,000–$40,000) varied pretty drastically on these next-generation LSPs, in my experience working at a community college (with approximately 8,000 full-time employees).
Arranging the demos is one of the trickier aspects of selecting a new LSP. Trying to find multiple times when all stakeholders are free is a logistical nightmare and unlikely to be completely inclusive. A few vendors may offer to visit your institution in person to make their sales pitch, but I found that recorded webinars are the best option. Any person who cannot attend is able to watch at his or her own convenience later on.
Give the vendors specific instructions on what features you’d like demonstrated, as well as some specific search queries and workflows that your current system has difficulty with. In my experience, it was helpful to ask each presenter to perform the same set of tasks to see if he or she was able to accomplish his or her sales pitch plus what was requested within a 90-minute time frame, followed by 30 minutes of Q&A. In one instance, stylistic differences left a lasting impact on whether we were comfortable trusting a particular vendor with our migration. It’s also important to come up with a list of questions to ask each vendor after the demo to confirm specific details in front of the larger group.
After all the demos are completed, generating feedback of some kind is particularly important. Library staffers that may not have been able to take part in the steps previously mentioned are seeing the LSPs in action for the first time and may notice (un)favorable aspects of any given product in relation to their specific workflows and responsibilities. This may be their only chance to voice their opinion, and it’s best that they are given the opportunity. Also, it’s nice to have this type of documentation to present as part of a larger package justifying a final selection.
Conduct a Cost-Benefit Analysis
As you near the final stages of selection, conduct a cost-benefit analysis of your current ecosystem compared to that offered by competing vendors. This can produce a helpful document that summarizes benefits, while simultaneously envisioning future library services.
As of this writing, not one LSP is capable of offering all the features listed in the chart. As such, it is worth gathering price estimates for all the features/services your library would like to have moving forward, some of which are likely already being paid for. A comprehensive document that shows how much each product will ultimately cost the library and what are the benefits for each LSP can be quite convincing to decision makers. At the very least, it shows that the library is striving to be as fiscally responsible as possible. In some cases, cost-savings can be realized with the potential to reallocate funds to collection development, new services, or staffing needs.
Selecting a Vendor
Finally, it’s time to select a vendor. If necessary at this point, use the documents and data created in the aforementioned steps to create a final report to present to senior administration. Rank the LSPs in order of desirability, and make contextual suggestions as to which systems serve which needs. Once decided, notify the vendor that’s the best fit, and request a contract for execution. After the prerequisite back and forth legalese occurs, the new contract will usher in the first phase of the migration process.
|
