There is a bunch of techniques for analysing processes. Here are some;
1. Colour code them according to who values the step (eg blue for the customer, green for the company, yellow for regulatory, grey for unknown.) Then think about whether things are really as they should be. Where can you cut costs by reducing steps.
2. Swim lanes show handovers – a red flag for problems. You can get bottlenecks when capacity issues arise, you can get rework as the downstream team reject the upstream team’s work and you can get things lost or just put aside as handovers (and priorities) change.
3. Break out the process boxes into descriptions under headings like [Input > Process steps > Failure conditions > Exit criteria] Then go back and make sure the input and exit criteria reconcile – and that there is a next step for all the failure modes. Look for opportunities to simplify failure/exception handling.
To be honest the process is quite streamlined as you had mentioned. I've made some changes to it and the overall process has been developing over the past 25 years that the company has been in business.
One major downfall to the process that I do not mention in the process flow is the fact that when items are in inventory occationally the warehouse staff will have trouble finding them. The reason being that our legacy inventory system was not efficient at all in keeping track of inventory bin locations. Because of that we had a number of bin locations import incorrectly into our new inventory system. The new inventory system is highly accurate however as you know, garbage in, garbage out. So, we are in the process now of updating all the inventory bin locations in our current system. This should drastically cut down on the amount of material that is either picked incorrectly from stock or simply cannot be found in stock by the warehouse staff. If we can cut down those errors it will also help to limit the amount of time that a manager will have to spend helping the warehouse staff to get the material picked correctly.
Variations in the picking process are actually not all that prevalent. Occationally warehouse workers will forget to fill in some of the information such as the weight of the shipment or the number of packages in the shipment. That can cause some confusion down the line but it really does not happen that often. Beyond that the only other variation I can think of off the top of my head is when a real rush shippment comes in. In that case occationally managment will bring the pick ticket out to the warehouse themselves and at times even pick the material from inventory themselves to speed the shipment out the door.
Frank,
Craig has provided several great methods for analyzing a process flow for areas that may required some improvement. This type of analysis is an important step.
Just from what you have told me we can take a look at the variation of managers picking the material to rush an order. Typically a manager's time is worth far more than a standards worker's time, so if we can find a way to expedite or rush an order while using the workers that might be ideal. Is there any prioritizing mechanism or process for the orders that arrive at the office?
While were at it, I want to add that you may find that there is little meanful improvement that you can make to a documented process. This doesn't mean that taking the time to document the process was wasted. Having a set of process flows that model your business (often call the business architecture model) is useful for several reasons.
In short, the act of documenting you business processes in graphical form allow everyone in the business to understand the business operations, agree upon exactly how they are done, and suggest changes as necessary.
Chris
Hi Frank,
And just to toss my two more cents out there: one thing to keep in mind about business processes is that, once created, there needs to be a procedure (process) in place for keeping them up to date. Nothing worse than having business processes documented but not kept up to date as people will assume that they represent the current business processes.
This is an issue/problem with having documentation in the first place. Don't get me wrong, I am not advocating not creating documentation, however procedures needs to be put in place to manager, version, and track changes for any artifact including business processes.
Best regards,
- Adrian
Thanks guys. This has been very helpful. I'm thinking about moving on and modeling another one of our processes here soon. In the mean time does anyone have any more advice for me when it comes to the path I should be taking to break into the BA field? To update you I'm still in the process of reading through the IIBA Body of Knowledge and I've read the Introduction to BPMN paper.
brought to you by enabling practitioners & organizations to achieve their goals using: