This case study makes use of the following, which are described in more detail in the linked resources:
|A - What? - Function Palette||Possibly|
|B - What? – Shared Services Spectrum||Discussed|
|C - What – Profiles, Scenarios & User Stories||Yes|
|D - Who? - Business Ownership Map||Yes|
|E - Where? - Service Location Map||Documented|
|F - How? – Requirement v. Resource Matrix||Possibly|
|G - Why? – Business Benefits Ranking||Documented|
|H - Difficulty - Dependencies Matrix|
|I - Difficulty – Potential Risk Register||Yes|
Ken Chad and Owen Stephens from the LMS Change project visited Cardiff to work with:
- Glyn Ryland
- Helen Thomas
- Sue Stevens
1. The Problem
The Wales Higher Education Libraries Forum (WHELF) is a group of 13 Welsh University Libraries, and the National Library of Wales. The WHELF partners are working together to explore the potential benefits, and challenges, of taking a centralised approach to hosting and delivering a suite of library systems software for WHELF partners.
The current project is exploring the business case for a ‘shared’ library system, and as part of this process to understand what such a shared system should look like to deliver the maximum benefits to all WHELF partners.
- Obtaining institutional buy-in for changes
- Diversity of requirements across different WHELF partners (e.g. support for NHS users a requirement for some institutions, not for others)
- Diversity of related systems used across different WHELF partners (e.g. VLE, Finance systems, 3rd party vendor system integration etc.)
- Large variation in size and local resources (skills and money) available between WHELF partners
- Understanding how far a collaborative approach can support the requirements of WHELF partners
a) Understanding the nature of ‘sharing’
Terms used in the context of the WHELF project, and the LMS Change programme in general, such as ‘shared systems’, ‘shared services’, ‘cloud system’ whilst being used widely across the HE sector, do not necessarily have good definitions. This can make gaining a common understanding of what is being discussed or proposed challenging.
It is only once discussion moves beyond these general terms to specific proposals of approaches which define such things as what aspects of infrastructure might be shared, what services could be shared, how shared systems might be configured, that it is possible to fully understand the implications, and the potential challenges and benefits.
There is also a danger that discussions focusing on the underlying aspects can obfuscate the true requirements. For example, if provision of a library management system is outsourced to a third party, it may not matter to those consuming the service how the underlying software is actually configured.
b) Experimenting with scenarios
The complexity of systems and services, especially across 14 partners, means that when considering some level of shared approach there are a large number of approaches that can be considered, each with different potential benefits and challenges.
Perhaps one of the simplest ‘sharing’ scenarios discussed was simply sharing requirements and tender documentation across the partners, but ultimately each partner institution making their own decision and buying their own system.
At the other end of the spectrum is a scenario where WHELF as a consortium purchases a single library system which is completely shared between all partners, with a single bibliographic database, single configurations for policies such as circulation, and shared services such as centralised acquisitions for all partners.
Neither of these extreme scenarios is a likely outcome for WHELF, but they illustrate two ends of a spectrum representing a multitude of possible scenarios.
However, isolating specific scenarios and discussing their implications and the extent to which they might meet requirements across the WHELF partners allowed the options being considered to be narrowed down and discussed in detail, and potentially opened up a set of options which could then be the subject of costings, business cases, SWOT analysis, or other methods of appraisal as appropriate.
c) Potential Benefits
The potential benefits being looked for by WHELF essentially fall into two categories:
- Saving money
- Improving service
Discussion suggested these might be realised through:
- Design of more efficient workflows
- Leverage with specific content vendors, single point of integration for external services (e.g. EDI)
- Reduction of duplication (e.g. the cataloguing of the same book across multiple partners)
- Ability to collaborate effectively on shared challenges (e.g. increase of consumption of content on smartphones, tablets and other ‘mobile’ devices)
- Sharing systems knowledge (e.g. where common integration points with other systems such as Student Information or Finance Systems)
- Exploit common experience of integration with VLEs (all WHELF partners use either Moodle or Blackboard)
- Leverage with vendors through consortial purchasing
One challenge is that not all partners are equally invested in these areas, so a saving for one partner may be a best neutral, and at worst a new expense, for another partner. There are also areas where a shared approach may make savings, but not to the extent that a substantial saving would be made. An example of this latter case discussed was reduction in application administration and configuration.
d) Framework agreement
From the discussion of potential benefits it is clear that while some partners may make small gains through reduction in the need for systems administration and related tasks, many of the potential savings are through shared practice, skills, and reduction of duplication where possible.
To this end WHELF is already in the process of establishing a Framework agreement that can be used to both establish and enforce approaches to working across the partners. This would be a major part of delivering the benefits noted above, and in some ways the question of how systems are shared or hosted becomes a secondary consideration. However, the Framework can also be used as a mechanism for reaching a shared set of requirements, and agreement on compromises that may be necessary to realise a shared system across the partners.
3. Methods Used
a) Service Location Map
b) Business Benefits Ranking
4. Observations on methods
The ‘Service Location map’ had an immediate appeal to some of the participants in the workshop. In this case there was an attempt to not just map the current situation, but also where services might map if there was a general trend to move from left to right on the chart (i.e. from local services to shared services).
While this drew out some useful discussion, it perhaps needed several versions of this chart to compare different scenarios before the mapping could truly offer useful insight into the impact of sharing aspects of library management systems and services. It is perhaps interesting to note Copy Cataloguing and ‘Local’ cataloguing behave differently, and that it was not seen as possible to ‘share’ Copy Cataloguing as a service without also moving to ‘shared operation’, while other aspects of service could move left to right (towards a shared service) without necessarily implying a move from bottom to top (towards shared operation).
As noted above, establishing a common understanding of what was meant by ‘shared operation’ and ‘shared service’ was challenging.
The Business Benefits Ranking was not completed during the meeting. The key challenge to this was there had to be an agreed scenario for which to assess the benefits. While it is possible to talk generically about the benefits of ‘sharing’, unless the detail of what this means is clear the question of how far certain types of benefits will be realised is unanswerable.
While there was a positive reaction, especially to the ‘Where’ tool from some of those at the meeting, overall the tenor of the meeting was that talking about specific scenarios and ‘running experiments’ might be a more useful approach overall. This is very close to a formal Scenario Planning approach described at http://en.wikipedia.org/wiki/Scenario_planning.