They are both very different institutions.
LSE - single campus; social sciences focus; 9,200 students; a single library; 4 million print; Voyager and Summon; period of looking at a possible new LMS Jan-Sept 2012.
KCL - Multi-campus; multidisciplinary, 26,000 students; 6 libraries; 2 million print (more electronic than print); Aleph and Primo; period of looking at a possible new LMS Aug 13-Mar 2014.
Both institutions looked at the same broad areas when looking at the question whether to stay with the existing LMS or to go to a new one:
- Existing system functionality
Acquistions: LSE and KCL both good.
ERM: LSE - weak. KCL - adequate.
Print: LSE and KCL both declining. There is still a need to deal with print, especially at KCL, where there is an interest in South American literature where many titles are print-only.
ERM: LSE and KCL both growing.
ILL: LSE and KCL both continuing.
- Systems Review
- Requirements
Seven questions were asked by each institution:
Q1 - Stay or Go?
Here both institutions had slightly different results when looking at their individual requirements. At KCL and LSE journals at that point where better in the existing system. LSE found that their existing reporting function as well as their ERM had to go. For ILL LSE was neutral about moving and KCL wanted to stay.
Q2 - System maturity?
The new-generation LMS is untested. So what is the best time to go? There are advantages and disadvantages of being an early adopter.
Advantages include: early access to new functionality; discounts; chance to influence development; more attention from vendor.
Disadvantages include: possible reduction to full functionality; staff time committed to development; staff stress.
Both KCL and LSE did not want to be early adopters. LSE wanted a fully functional system and were not prepared to commit additional staff resource or increase staff stress by being an early adopter.
Q3 - System hosting model?
There is an opportunity here to use a hosted service. It would reduce in-house infrastructure costs and IT staff costs, though it is not sure if this would mean less staff time taken. It would also improve resilience.
There are also risks, such as lose of control over system performance. Moving to a multi-tenant solution (full cloud model) would mean access to webscale functionality, e.g. shared community data, community analytics, but it would also mean a lose of local control over system customisation and updates.
LSE decided to go as they are very keen on benefiting from community data. Their exisitng infrastructure was at end-of-life. There are potential significant IT savings to be made and the IT department have accepted the risks of cloud services. They have taken advice on contracts and service level agreement, as it is extremely important to know your rights.
KCL decided to stay. They didn't want a "one-size-fits-all" multi-tenant system. Also, their IT department is highly risk-adverse towards a cloud system.
Q4 - System development?
Looking at how the LMS will evolve over time. Open source vs Commercial systems (two ends of the spectrum). With open source systems such as Koha and Kuali there is a lot of choice and input, but more in-house support and expertise is needed for this. Commercial systems involve less choice and input, but less in-house support and expertise is needed. In-house development resource is required, but you can develop it all yourself.
Q5 - Fit with systems strategy?
The LMS is only one part of an entire ecology within the institution, which includes HR systems, finance systems and registry. It would need to integrate with these systems, and possibly others from outside the institution. The choice of LMS can constrain how libraries can deal with other systems.
LSE undertook a landscape review and drew up a diagram showing all the LMS modules, which illustrated potential integrations. They found that they have 4 search points within the LMS.
At LSE the process was taken to rule things out. They looked at the fit with the the resource discovery system, but not the other library or university systems.
At KCL they took a more holistic approach to the landscape review, and looked at the strategic environment; existing systems and technologies, alternative systems and technologies, technology trends and did a SWOT analysis.
They also looked at data-usage trends, spoke to staff, visited other libraries, had vendor demos, attended events, and looked at the literature. They complied a list of 30 different systems, with there being lots of different layers of systems. They found that four different teams were set up to look after the four different parts of these systems, so there was a mixed-support scenario. They also marked which were back-end and which were public-facing systems. They also looked at the usage trends, noting what was much used and what was little used, and the known issues.
Q6 - Fit with library strategy?
You have to know where you want to go and why you want to go there, for example change or reinforce a particular staff model.
LSE has a strategic focus on improving the "back-end" business processes. New LMS functionality needed to support improvement, so staff resources are justified. The new LMS review to motivate process change and create a culture of continuing improvement. There are not many ERM processes. Their decision was go as a new LMS was a priority.
KCL has a strategic focus on innovation in "customer-facing" staff culture. New LMS functionality was not needed to support this. Customer benefits are not clear enough to justify a new LMS. Their decision was to stay. A new LMS wasn't a top priority.
Q7 - Fit with IT strategy?
At LSE IT infrastructure is moving away from the support of local services to the cloud. IT development is also moving away from bespoke construction and towards standard APIs. IT staff is moving away from departmental IT teams toward central IT support. Their decision was therefore to go.
At KCL they have a similar trajectory with IT support as LSE. However, making a case for a change of LMS would be very challenging. There are major pain points elsewhere: authentication; research data management; digital assets. The therefore decided to stay. IT investment in a LMS change was not justified.
So did LSE and KCL stay or go?
LSE decided to GO as they had functionality needs, IT staffing and infrastructure changes, existing LMS contract was ending and the required financial resources (they had in fact delayed the tender several times in order for the systems to mature). They undertook their tender in July-September 2013 and selected Alma. They have been running Alma for the last 9 months, having implemented it during January to July 2014.
KCL decided to STAY, but they haven't stayed still. There have been further team changes to streamline the LMS support, etc., and improvements made to hardware and software. They are also committed to shared services, such as JUSP and KB+.
What did LSE learn?
- Functionality is important but not the most important factor;
- The hosting model affects costs and control;
- Development approach affects your ability to fit the system to future needs;
- Vendor ethos and on-going relationships are important.
What did KCL learn?
- Know what your institution actually needs;
- Test your assumptions as widely as you can;
- Learn about systems innovation in other sectors;
- Consider friction - changing LMS has hidden costs;
- Systems don't solve problems, people do.
What do you think?
- Functionality
- Business model
- Up-front and maintenance costs
- Ethos of supplier
No comments:
Post a Comment