New Zealand’s premier university
The Customer
Based in Dunedin, on the South Island of New Zealand, the University of Otago was established in 1869 by the early Scottish settlers arriving to the area. They placed high value on the University’s role in shaping individuals and society.
The Challenge
The University’s purchasing process is split across many teams using up to 5 different systems to create and manage requests. This makes it difficult for the centralised team to keep abreast of procurement matters. Communication has shifted to email due to the variety of systems in use, and management often involves duplicating content from one system to another. The energy being invested by people is inconsistent with the value that is being created.
The Solution
By focusing on the pain felt by users and asking how they would like to work in the future, the project team used LINQ to create a current and future state for procurement. Data from time and motions studies were input into the LINQ models and LINQs Insights were used to prove the value the change would create. The ease of presenting to Decision Makers with the evidence to support the recommendations being made, created all the necessary conditions for the change project being funded.
The Benefits
Consolidating to 1 procurement system realised the opportunity to remove 10,000 hours of effort from the current process. This is energy which can be redirected to tasks that deliver additional value. Employee Experience is significantly increased – people can now apply their expertise to ensure that procurement benefits the University rather than significant admin effort to make the process work.
From one model, LINQ provides analysis from multiple angles that can be used to drive improvement decisions and calculate benefits.
Kirsty Irvine
Senior Business Analyst, Business Process Management Office
The University of Otago Story
Across the University, up to 5 different systems are used by departments in the purchasing of equipment and services. Until very recently, managing paper-based Purchase Orders was a typical part of the working day. The centralised purchasing team spend a significant proportion of their day duplicating content from one system to another using copy & paste or having to manually re-enter content so that a consolidated view can be created and maintained.
The large number of systems also means that communication with PO submitters is also a manual process with large numbers of emails being sent, multiple times to multiple people, daily.
The approval process is also manual as a result, requiring more email to be sent which is then reconciled with the system which was used to raise the PO.
It is hard not only to track the progress of procurement through the process, but also to generate data from the process to help inform the business about the success of procuring from suppliers.
A ’discovery first’ process was used to understand the pain of the current state and to capture how the users felt the process could be improved. The business was able to provide the requirements for the new process and system based on user identifying the challenges they were faced with daily.
Capturing process time directly from a selection of end-users gave us certainty that our data and findings was accurate, rather than having to justify an educated guess.
To get the data needed to build the business case for change, the team sat with users, watching and timing them as they did their work. The data from these time and motion studies was input into LINQ recording the frequency and duration of work being done.
One of the systems in use has been selected as the one to standardise on. The relationship with the provider already exists so being able to assess capabilities against requirements was straight forward.
The requirements from users were translated into a Future State model which, alongside the knowledge of how the preferred system worked, was able to reflect how the team would operate once the implementation was complete.
A test system was created, and the process improvement team used this to understand how long it would take to complete the necessary tasks. The combination of knowing how the system would work alongside how long it would take to complete the necessary tasks were fed into the Future State model.
LINQs Compare tool was used to understand the impact the change would have. This showed the opportunity to reallocate 10,000 hours of time from the procurement process each year, to tasks that deliver additional value.
The one-page summary of the Compare function was fantastic for the business case. Then we used the data export to analyse impacted areas and prove that we were saving time across the board rather than shifting effort from one team to another.
Stakeholders were concerned that optimisation in one area would shift the pain to another part of the process, but the model was able to show how each team involved in the process was impacted by the change and prove that this would not be the case.
The business case was approved, and the project has been funded. Implementation is underway and with the knowledge of what success looks like, the project team will keep track of progress. Before the end of the year, the as-built metrics will be entered into the model and the final impact will be understood.