Analyse the as-is
The first step is to review the as-is process to capture issues that need improvement. Generically, the issues will fall into one or more of the following:Lack of standard process
This is where there is no one standard, and there are lots of local variations. This can arise for a number of reasons, which include:- Lack of documentation: when a process isn't clearly documented people won't know what to do in particular situations so may invent their own methods;
- Gaps in documentation: similar to the above, this is where the documentation doesn't cover a specific situation: again locally invented methods will arise;
- Systems issues: this is where a system (often an IT system) is hard to use or understand. Staff may create their own work-around to cope with this;
- Changes over time: processes can become accreted with changes over time - some contradictory - but because they aren't monitored/managed out of date procedures aren't discontinued and reactionary process additions aren't carefully thought through [1].
Duplication
One of the commonest types of duplication is authorisation, where something has to go through more than one stage of being authorised. Typically this happens where money is involved, but it can also be for things like workload assignment, prioritisation, etc..Quite often duplication occurs in a chain, i.e. it goes here for first level sign off, then there for second level, and so on; but do watch out for duplication that occurs more widely dispersed, e.g. a supervisor agrees something, a chain of events occurs, and then a manager signs it off.
Hand-offs
A hand-off is where the work passes from one person (role) to another. Most processes will have an element of this, and in itself it's not wrong. However whenever there is a hand-off you can get delays either as batches or queues or both.- Batches: this is where someone gathers a number of items before handing them off - so there is a delay because the earlier items are waiting until the latest ones are added. Batching often has rules like "once a day" or "every 10 items" or "a minimum of £1000 of orders".
- Queues: this is at the receiving end, so it's when incoming items are stored for a while before being processed. In effect, it's creating a batch at the receiving end of the hand-off.
One of the principles of a good process is to have "flow" with nothing being held up along the way. So you should carefully consider whenever batching/queuing occurs if it can be avoided. However sometimes it does make sense to batch things up, so do be careful. For example ordering low cost items: it may make sense to batch these up per supplier to reduce the overheads of processing each item.
Delays also occur when hand-offs aren't synchronised, e.g. person a sends the form through on Monday and person B only works on Wednesdays. This happens with systems too, e.g. a system only picks up items for processing at a certain time of the day. Queues can result from this, but even when they don't (because the volume is low) there is still a delay between one task and the next which - if possible - should be reduced or eliminated.
Another form of hand-off delay is conversion. This often occurs between automated systems, where one system has to convert the data from another before it can be processed. The act of doing the conversion creates the delay, so if possible you want to work towards system hand-off where no conversion is required.
Scheduled delays
In addition to the delays that arise from hand-off you sometimes see delays within a swim lane due to some form of scheduling, e.g. I do this on a Monday and that on a Tuesday. There is no hand-off involved, but the effect is the same because you have created your own batch and queue activity.There is often the idea that it's more efficient to handle things in this way: e.g. I do all the order inputting and then I do all the order send-out. Measures often show that this isn't the case and allowing single piece flow is often more efficient. It also makes the job more variable and thus more interesting.
Copying and filing
This is the act of making copies of documents for storage and potential future review. It is always worth asking whether the copies are really needed (questions like "when was the last time you had to retrieve a copy" help), and deleting the activity if possible. One of the common things one sees is the printing off and storing of data that is in a system. If it's in the system, why do we need a hard copy?Sometimes a whole industry can build up around creating and maintaining filing systems that are never used!
Prioritisation
When the volume of work is greater than the resource available, something has to give. So one question to ask is whether the process is adequately resourced. In real life it's often the case that you just have to make the best of this situation, so the next question to ask is whether the tasks are adequately prioritised. Human nature is such that we'll do the easy and/or most interesting things first: these may not be the most important ones.Poor resource allocation
Paradoxically, having too much resource can also cause problems as this could lead to queues building up down the line. Look for situations where resources are allocated in a reactionary manner, because this often has that consequence - e.g. team A are really busy today so we'll assign a couple of extra staff to help them - so team A "efficiently" move all their work on to the next stage, but it builds up further down the line. If you measure this end-to-end you often find that working in that way ends up with lower overall throughput! Here is a simulation game you can do that shows this in action.Inspection
A tool that can help provide additional information about some of these is a value stream map (VSM). VSMs are outside the scope of these articles, but they are similar to process maps and show the time taken to carry out activities as well as the overall flow. The time measures include waiting times as well as processing times, and you can work out the ration of process to waiting to get a measure of the the process "efficiency". If you'd like me to include an article on VSM in this blog leave a comment - if I get more than 5 comments I'll do one :-)
Building the to-be
This is a three stage process. The first stage has already been discussed: analysis of the as-is. Stage two is to take your analysis to the working group and identify improvements. Stage three is to draw up the to-be process and check back with the working group (and make amendments).Identify improvements
Analysis of the as-is should provide you with a number of questions to ask. The to-be workshop should involve all the relevant stakeholders: usually the same people that took part in the as-is workshop (see part 1 and part 2).Present them with the as-is map and walk them through the map. (If people are not used to such maps, don't send out copies beforehand as this will only cause confusion).
After the first walk through, add coloured stickers to the diagram (use different colours for the different sorts of issues, and maybe different shaped stickers as well. For example the inspection sticker could be a person, the delay could be a clock, the hand-off a hand, etc..)
Ask questions for each sticker and guide people towards consensus on finding an agreed improvement. For example with batching you may not be able to get rid of it all together, but maybe you could prioritise certain items within the batches.
Have a scribe on hand to make notes as each issue is discussed and possible solutions are agreed.
After you have been through all of your prepared questions, based on your analysis, ask for more general feedback and ideas: people will often come up with their own suggestions beyond what you may have considered. Above all, try and make sure the improvements are things the workshop attendees have identified themselves (even if they're ones you thought of as well) - this will help with buy-in to making the changes. Watch out for managers / supervisors trying to force through their ideas.
Draw the to-be
Based on the outcome of the workshop, you draw up the to-be process using an appropriate tool (see part 2 and part 3). Bear in mind that the ideal to-be may not be achievable in the short term, so potentially draw up one or more intermediate to-be diagrams that allow you make changes along the way.Once you are happy that you have a to-be process that reflects what was discussed and agreed, and that seems to work, identify the key actions that will need to take place, e.g.
- New systems or system enhancements;
- Changes to team resources;
- Changes to role activities;
- Changes to policy and regulations.
This should be discussed with the sponsor to check that he/she is happy to support the changes (if they are not, clearly the changes can't happen!) You may need to make some amendments resulting from this.
Present the to-be map(s) back to the working group to check that the changes are what they agreed. If sponsor-driven changes have been made, get the sponsor to present these.
Agree and finalise (hopefully minor) changes, and then document the final to-be map along with the actions to be taken. The actions need to be assigned to someone who will take responsibility for ensuring they occur: this may feed into a project, in which case the project manager should also be involved.
The to-be map is now not only the road map for improvement, but it is key document for how the process will work. As it is implemented, relevant parts of the map should be issued to the teams involved, supported by documentation on the steps involved (see part 2 for a discussion of tasks and steps). The entire map should also be provided so they can see how their part fits into the whole. [3]
Finally, carry out regular reviews of the process to see whether it's working and check on progress. If this work is being done as part of continuous improvement, go through the whole cycle again (e.g. Deming's PDSA, (plan-do-study-act; also known as PDCA, where C = check) [4].
Good luck!
Notes and References:
[1] A story that illustrates this is as follows. Once upon a time there was a beautiful princess and she loved roses. Her bedroom overlooked a garden and she wanted a rose bush planted in the centre so that she could see it when she looked out. So a bush was planted, and she would look out and admire it. One day she saw a scullery maid cut one of the roses off the bush, so she ordered that a guardsman should stand next to the bush day and night to protect it from further abuse. Many years passed. The princess grew up, had a family and died. More years passed. One day a princess looked out of her bedroom window at the paved quadrangle that had many years ago replaced the garden. She saw a guardsman standing in the centre, doing nothing. She asked why he was there and was told that it was what was done. Nobody knew why any more, but the order had never been changed!
[2] Ross, G. and Jeffrey, B. (2010) Practical Quality pp. 26-27
[3] BizAg Process Modeler, a free tool for drawing BPMN process maps, has the ability to link tasks to documents and explanatory text (such as steps in a task). When published as a web page, the process maps become clickable so that the documents associated with tasks can be read - thus the process map becomes the key for the documentation of the process.
[4] Deming, W.E. (1994) The New Economics for Industry, Government, Education (2nd Ed) pp. 131-133
No comments:
Post a Comment