Managing systems change @ LSE

2. Systems change @ LSE Alma & Primo • Requirements review, Summer 2012 • Tender and selection, July – September 2013 • Implementation, January – August 2014

3. Managing the change • Managing process change • Managing people through change

4. Managing process change Challenge 1 = Out with the old  How things are done in Voyager  How things are done

5. Managing process change Challenge 2 = In with the new  Software  Service

6. Managing process change The LEAN approach • As Is process review

8. System requirements • One integrated front-end interface • One unified back-end system

9. Managing process change The LEAN approach • As Is process review • Critical To Quality (CTQs)

10.

11. Managing process change The LEAN approach • As Is process review • Critical To Quality (CTQs) • Value vs waste

12.

13. Managing process change The LEAN approach • As Is process review • Critical To Quality (CTQs) • Value vs waste • Could Be process review

14.

15. Managing people through change Managing change workshops • Managing my team through change • Managing myself through change

16. Managing people through change Staff-driven process change • Staff trained as Business Change Champions

17.

18. Managing people through change Staff-driven process change • Staff trained as Business Change Champions • All staff invited to Process Review workshops

19.

20. Managing people through change Staff-driven process change • Staff trained as Business Change Champions • All staff invited to Process Review workshops • Outcomes shared

21. Managing systems change @ LSE It’s an ongoing process …

22. Questions? Anna Grigson Head of Collection Services Group a.c.grigson@lse.ac.uk

Hinweis der Redaktion

LSE recently implemented Alma and Primo (at the same time), having migrated from Voyager and Summon As with any Library system implementation, there was a formal and lengthy project: Requirements review Summer 2012 Tender process Mar-Oct 2013 Implementation Jan-Sep 2014 We launched both systems exactly on schedule on 1 August 2014. As we go into the new academic year we are bedding in both systems and getting our first real user feedback on Primo now that students have returned.
Long and exhausting though the project was, in many ways changing the systems was the easy bit – it was a lot of work, but the work was clearly defined, with a clear project implementation plan from ExLibris, and lots of support from our ExLibris project team. The more challenging aspects were the ‘softer’ side of systems change, including 1 Managing process change 2. Managing our people through change Whilst we could have got through the implementation project without paying much attention to these aspects, we knew that they were both essential if we were to deliver the longer-term improvements to library services that we were seeking to gain as a result of getting the new systems.
There was an acknowledgement from (almost) all library staff that process change was needed. After all, the requirements review had showed that our previous system couldn’t fully support our operational needs, which was the reason we were getting a new system in the first place. But acknowledging the need for change at a strategic level will not automatically translate into change at the operational level. We had to be able to work out what we would need to do differently in the new system at the level of day-to-day working routines. First, had to be able to see what we needed to change. In some cases, the capabilities of our legacy system had determined how we did things, but this was not necessarily the most efficient way. For example, the way in which we manage our eresources had been set around the limited flexibility of Voyager, and we knew that there were things that we wanted to change to achieve a more streamlined workflow. In other cases, our workflows had simply become fixed over time. We had Voyager for a long time, and as a stable system some routines barely changed over the years. Whilst routines might originally have been determined by the “how things were done in Voyager”, over time we had forgotten the reasons why the processes worked as they did, and has simply assumed that this was “how things were done”. In other words, we no longer always questioned why they were done in this way, and whether there was potentially a better way to do them in a new system. We were therefore aware that if we simply translated our existing processes from Voyager to Alma, there was a risk that we would inadvertently bring some inefficient routines with us, simply because we no longer recognised them as inefficiencies -- because couldn’t easily step back and perceive the difference between “how things were done” and “how things were done in Voyager” Since one of the goals of getting a new system was for efficiency gains and service improvement, we clearly needed to find a way to look at our processes with fresh eyes, and to make sure that our legacy system didn't leave behind an unwanted legacy.
In with the new So we wanted to go into Alma with "fresh eyes" -- but it was also important that we didn’t go in totally "wide eyed" Whilst we were already aware of risk of having been somewhat constrained by the capabilities of legacy system, we were equally aware of the risk of being overwhelmed or led by the capabilities of the new system – of setting up routines based on what the system could do, rather than focussing on what we wanted it to do. Rather than being restricted by limited choice, with the new system we faced the opposite risk of having too many choices of how to configure the system, and we needed to find a way to focus these choices. This was partly for the very practical reason of needing to finish the implementation project on time – and with only a few months to get through a lot of work, we knew that we wouldn’t have time during the implementation phase to spend several weeks deciding working out which options we should choose, so we had to have a clear picture of what we were aiming for before we started. It was also for the more strategic reason of ensuring that we remained focussed on the service benefits that we wanted to achieve from the system. We needed to remember that we weren’t just launching a new system, we were launching an improved service based on a new system. We didn’t just want a better system – we wanted a system that could give us a better service. And to achieve that, we needed to have a very clear picture of what we meant by “better”. We needed to reconsider not just how we did things, but also why we did things We needed to make sure that we didn’t just look at how to improve our existing processes, but that we also looked at whether our processes were necessary at all – or whether we needed new ones. So our challenge was not to be driven by systems requirements – either the restrictions of old or the potential of new system – but to keep the emphasis on what we need our service to deliver, and to shape the new system around those goals
The LEAN (Six Sigma) approach To ensure that we understood the service goals we wanted to achieve, we used LEAN methodology to hold a series of “rapid improvement workshops” which would: Capture our existing processes Consider the value we were aiming to deliver to customers through those processes – which steps in process did or did not create value for our customers, and what aspects determined whether we delivered what our customers considered to be a quality service Reconsider how our processes could be improved 1. The first stage in our LEAN process review was to document our existing routines, our “as is” processes To capture in detail what we do now (in some cases we would that the process maps we created in the workshops were our only documentation for some key processes) To capture who does it (in some cases we discovered there was only one person in the library who did / could do a part of the processes, creating risky “single point failures” and bottlenecks)
Here’s an example of one of our “as is” processes, showing how complex some of them had become. This example shows the process to accession an Official Publications standing order, which involves several different teams and has a “single point of failure” if our colleague Jennifer is absent!
This is another example of one of our “as is” process maps in its documented form, this time showing the (somewhat complicated) process for ordering a single e-book.
Stage 2 was to look at value and quality from the point of our customers. This stage was the most critical to achieving success, because we needed to be sure we got to the heart of what really matters to our users, and use that as the goal which all our processes should be based around. It was therefore central to setting the goals for our new system, and focussing on exactly what benefits it needed to deliver. We looked at: 1. What is ‘value’? What do our customers need? For example, for the acquisitions process, value for a student library user might be acquiring and making available an e-book on their reading list for this week. 2. What is critical to quality (CTQs)? Where do we want to see improvement? For example, a CTQ for a reading list is clearly to get the e-books to students in time for the class, so “speed of delivery” is a CTQ, and to make it easy to find and access, so “link reliability” is also a CTQ.
This is an example of some value and CTQ analysis from a workshop on e-resource discovery and access. We also looked at the performance measures we could use to assess how well we were meeting our CTQs.
The next stage was to look at value and waste in our processes Which steps in our processes deliver value -- we want to keep these Which steps in the processes are “non-value” added, ie we have to do them but they don’t directly add value for the user – we want to minimize these Which steps in the processes are waste -- we want to stop these This was where we took a hard look at each step in our “as is” process map and asked which steps were essential, and which we had added because they were how things were done in Voyager, or simply because we’d never questioned whether we still needed to do them. It sounds obvious that you don’t have steps that you don’t really need in a process, but it is surprising how many steps in a process don’t “add value”. In the example of acquiring an e-book, adding the book to the catalogue created value, because it meant the user could find and the book. Time spent paying an invoice is a “non-value” step because we clearly have to do it, but it is not creating value for the customer so we have to have to keep the time this takes to a minimum, and try not to let it delay making the book available. But we found that we had ended up with a rather convoluted process for passing orders between our library system and the vendor’s system, designed to support our budget control. This delayed the order by 24-48 hours – a long delay for an ebook – so we identified it as waste which we had to take out of the process.
The final stage was to go back to our “as is” process map, and look at how we could redesign it into a “could be” process that would strip out the waste and focus more on value and CTQs. In some areas there were some steps which were relatively easy to simplify, but there were some areas where this meant asking some searching questions about whether something was “waste” or “value” and therefore whether we should carry on doing it. …
… For our e-book example, we need to have a catalogue records so that users can find the book, but how much time should we spend adding lots of detail to that record? How much detail is essential and ‘adding value’ and how much is non essential and represents ‘waste’? Once we looked hard at where we could simplify processes without seriously affecting value and quality, we were able to simplify some of our “could be” processes. For example, this is the “could be” process to order a single e-book – much less complex than the “as is” example shown earlier. So by the end of the process review project, we had a series of “could be” process maps which we could use as a framework for how we were aiming to set up the new system. We knew that we wouldn’t necessarily be able to achieve such streamlined processes in all cases, but it was still important to have these as guidance for what we were aiming to achieve as we implemented the system.
The second major element of change management was managing our library staff through the change process, and this was just as critical to success – if not more so: It was a long project It was going to be a big changeSo we needed to give people the resilience to cope, both for themselves and for the staff they managed Unpicking routines is unsettling, because we are not just changing what people do but we are potentially questioning why they do it. This was especially the case in my area of Collection Services, where many of the jobs in acquisitions and cataloguing are built around routines, and often very stable routines which staff have spent many years doing without significant change. For many staff, their measure of doing a good job is that they are doing their particular routine well – they are hitting their deadlines, and meeting standards of accuracy. It can be very hard to then have someone come and ask whether the routine itself is worth doing, and to essentially ask them whether there is any point to what they spend their day doing. There is a risk that that they feel their contribution is not valued, which may make them feel personally devalued, and possibly questioning whether they are at risk of redundancy. At all stages of the project, we assured staff that we were not aiming to reduce staff numbers and find redundancies – the aim of improving our processes was to improve our services, and any staff time saved was to free up for other activities. Needless to say not everyone was wholly convinced – there will always be some doubters – but it was essential to state this before starting the process review. In addition to giving this reassurance, we took two approaches to managing people: Our first approach was to give training on change management We ran training for managers on how to manage their staff through change We ran training for non-managers on how to manage themselves through change In both courses, the focus was on identifying our emotional reactions to change, and how to manage them, to give all staff some skills and tools for dealing with change. In addition to these benefits, there mere fact of running the training was an important acknowledgement from the senior library staff that the LMS project was going to bring major changes, that it was OK for staff to feel unsettled by the project, and that feeling nervous about the changes wasn’t a sign that they were ‘failing’ in any way.
Our second approach was to involve as many staff as possible in the business process review. Rather than bringing in consultants to review our processes, we trained our own staff to act as “business change champions” and lead process reviews.
Here’s one of our workshops in progress …
2. We invited wide range of staff to workshops, which both recognized the value of their knowledge, and by gave them a sense of ownership and control of the process. About the only staff who weren’t invited were the senior managers from the Library Leadership Team. For the process review to work, it was important that staff could record the “as is” processes with complete candour, including any faults in the processes, so excluding senior managers was a deliberate choice to make sure no-one felt they could not admit to having less than perfect processes in front of their manager.
Here’s another workshop in progress …
3. Once the process review had produced a report for the senior team with recommendations for how to change processes, we shared (almost) all the reports with all staff. We wanted to create a culture where we could share problems with processes, get them out in the open and deal with them, so sharing the process maps and recommendations was an important part of this. The only elements which were not shared were where recommendations had particularly sensitive impacts on particular members of staff.
Our implementation project has now finished, but change is clearly an ongoing process. Managing people through change takes time Not everyone responds to change at the same pace, so it’s been important to recognise this and be patient. Whilst some staff are keen to engage with the new features of the system (especially Alma Analytics), other staff will need more time to get used to no longer having Voyager. We are currently in the middle of our annual appraisal process, and many staff objectives for this year are picking up on this ongoing change management process, focussing on handovers of responsibilities, ongoing training in using the new systems, and supporting staff in developing new skills where necessary Similarly, the process review hasn't fixed all our processes, but it has been a catalyst for change: It has given us the direction we need to go in to ensure our processes remain aligned with service needs It has given us the mindset to be more critical of our processes, to be alert to spotting opportunities to improve them, and willing to change And it has given us the skills to review our processes as a team, and make changes In short, it has started to build the culture of "continuous improvement" that we need to ensure that we continue to develop both Alma and Primo to their full potential.

Managing systems change @ LSE

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (11)

Andere mochten auch

Andere mochten auch (15)

Ähnlich wie Managing systems change @ LSE

Ähnlich wie Managing systems change @ LSE (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Managing systems change @ LSE

Hinweis der Redaktion