Ten Steps to Improving a Process
I have come up with an approach to improving processes that can be broken down into a series of steps. Following these steps, while using my skills and experience, allows me to deliver quality improvements that hit the mark.
1. Understand the scope of the issue
I can’t even start to improve a process until I understand the scope of the issue. Where does the process start and finish? Who operates the process? Who are the stakeholders? What do they think is the issue? And what are they hoping to get from the improvement?
It is also very useful to find out at this early stage exactly what systems, shared folders, mailboxes etc are used in the process. It will be very beneficial to get at least read access to these if possible, in order to analyse the process, and it may take some lead-time to get this access.
It is useful to have some way of clearly documenting the whole scope. Lean/Six Sigma uses a single page Project Charter, whereas change projects will often use a project initiation document (PID).
2. Map the As-Is Process
The next step is to document the current process in order to understand it. I find it useful to sit with the people who operate the process, so that they can take me through it step by step. I also interview other stakeholders for their perspectives. Then I map the process at a fairly high level, by freehand or using Microsoft Visio. I can then fill in any blanks and clear up any misunderstandings, and overlay where I believe any of the issues lie, before talking them through my mapping diagram to confirm my understanding is right.
3. Understand outputs/reports/requirements
When analysing a process, I ALWAYS start with the outputs. What are we trying to achieve? What is required to be reported? How often? Who requires them – is the recipient an internal or an external customer? Are the requirements must-haves, or nice-to-haves?
I also measure and analyse the outputs from the as-is process to see to what extent the required output is actually being achieved or not.
4. Understand source data/inputs
Once I understand what output the process is trying to achieve, I can look at what source data, inputs or resources are available to produce that output. Again, are they internal or external sources? Is it transactional data or standing data? How is it transmitted? What are the timings? How could it be received? How reliable is the source data?
It is vital to consider all possible/available inputs, not just those that are currently used in the as-is process. This is where having experience and business knowledge is critical. Talking to SMEs and wider stakeholders may also throw up other possibilities, which must be critically assessed to see whether these can have a bearing on the solution.
5. Design improved solution
So now I can design a process map that uses available inputs to produce the required outputs.
It needs to be as efficient and effective as possible. An efficient process will be quick and easy to operate, with as few steps, and as much automation, as possible. An effective process will have controls to make sure the output is produced accurately.
This is where experience and business knowledge come in again. Experience of processes used by other teams/businesses to solve similar business requirements in the past, can be applied to the current issue.
Creativity is key. It is not enough just to simplify and automate the as-is process. Is there a better, different, way of producing the required output?
6. Design controls
Good controls are vital to designing an effective process – they are what makes the process robust and reliable. They can take the form of internal checks within the process to make sure, for example, that source reports have valid dates. Or they may be error reports – where output falls outside certain tolerances perhaps.
It is easiest and best to design controls in from the very start. They need to be quick and easy to operate so they do not detract from the efficiency of the process.
7. Mock-up solution
Once I have designed my preferred solution, I produce a quick mock-up model of how it would work. This would be an example of how the process would operate. It would ideally utilise and have access to the systems to be used in the full new version.
The aim of this mock-up is to give me confidence that my solution will work as intended. And it can also be a great way of explaining the solution to stakeholders.
8. Get Buy in for improved solution
I now need to sell my solution to the stakeholders. I write a small PowerPoint presentation for them that details 1. What is the current as-is situation? 2. What are the problems with the current situation? 3. What is my solution? 4. Why does my solution solve the problems?
It is important to get their formal approval before committing the time needed to build the solution.
9. Build solution
Once I have their sign-off for the solution, I can go ahead and build it. This may take the form of writing system report queries, designing excel spreadsheets, automation through writing VBA macros.
I document the process and write clear simple user instructions.
It is vital to test, test, test the solution. I test it with data that is obviously wrong. And with missing data, and with doubled-up data.
Then I pass the solution to the people who operate the process, for them to test it (User Acceptance Testing). They will test the new process with a fresh pair of eyes and will come up with any issues that I would then fix.
10. Deliver solution, documented and supported.
Once I have a robust process, with any bugs fixed, the users can sign off that they are happy with it. They can then start using it as the live process.
I deliver the process with documented process flow, user guide and troubleshooting guide. It is usual to provide support for one or two operating cycles of the process in live.
So those are my ten steps to improving a process. Following the structure of these steps makes sure that the solutions I deliver are a quality product – they are well designed, well received and are fit for purpose.