Reduce the Batch Size
"We are what we repeteadly do. Excellence, then, is not an act, but a habit"
- Aristotle.
We have discussed previously (Tip #02) how minimizing the number of handoffs will make your process more agile and more straightfoward. Today we'll be discussing the virtues of minimizing the size of the handoff - and, since the handoff contains a batch of work done, the size of that batch.
Historically, companies have built up manufacturing systems to be efficient in terms of cost-per-product. Traditional management science views the products as cost collectors and therefore one of the way of minimizing unit costs (like overhead) was to increase batch size. More products in the same batch accumulate same absolute overhead (say, for QA), therefore less overhead per unit, right?
Not necessarily. Toyota has long time ago turned this concept upside down with their TPS (the predecessor of the lean manufacturing concept). The actual cost drivers are the activities, if you want to reduce costs per unit, you are better off optimizing activities within processes.
By minimizing the batch size you get several key benefits, crucial especially in an intangibles production system (like, services and software):
1/ smaller batches = faster feedback. In a lean start-up, the build-measure-learn cycle needs to run many times before the invention of a valid business model. Ability to iterate as fast as possible is vital to success. Ideally, the batch size should get as close as possible to 1. If we build excellence by repeating what we do, then let's repeat what we do a whole lot more, and then we'll be excellent much earlier.
2/ smaller batches = less overhead. You will find that, with the right batch size (depending on your size of business), your QA/testing overhead will actually decrease significantly. That's because the QA/testing function will get much more responsive, much more automated, much faster in identifying issues - you would need less QA resources overall, and they will be more evenly allocated across your product cycle.
3/ smaller batches = less risk. You will be able to check your work much faster and correct errors much earlier in the process, before they become ticking bombs in your value chain.
More to come :-)
Showing posts with label handoffs. Show all posts
Showing posts with label handoffs. Show all posts
Monday, September 16, 2013
Monday, September 9, 2013
Lean Processes, Tip #03
Morph Your Handoffs Into Teamwork
I discussed last week about the need to minimize the number of handoffs, as they build up cycle time and noise in the organization.
When we cannot reduce anymore the number of handoffs, we should try to optimize the handoff process, so that we enable process roles to be more aware of each other in their quest to fulfill the common process goal:
1. Make your upstream roles proactive on the downstream information needs.
This way upstream roles can design templates and checklists before they push the info downstream.
Example: an efficient salesperson (what is that, anyway? :-) ) would follow a predefined checklist when finding out about a new customer to ensure the lead is fully qualified (do they have the budget / the authority, the pain / the urgency to buy?) before proceeding along the sales funnel.
2. Promote downstream roles upstream.
Sometimes you just need to redesign the whole process and have your downstream role take up upstream responsibilities.
To note, this "tip" requires quite a bit of proper transformation within the organization:
- cross-functional trainings;
- setting up stand-ins / back-ups for all process roles;
- setting up systems to automate data validations (in templates and checklists) wherever possible;
- have a Business Process Lifecycle Management practice in place.
I never said it would be easy! :-)
More to come :-)
I discussed last week about the need to minimize the number of handoffs, as they build up cycle time and noise in the organization.
When we cannot reduce anymore the number of handoffs, we should try to optimize the handoff process, so that we enable process roles to be more aware of each other in their quest to fulfill the common process goal:
1. Make your upstream roles proactive on the downstream information needs.
This way upstream roles can design templates and checklists before they push the info downstream.
Example: an efficient salesperson (what is that, anyway? :-) ) would follow a predefined checklist when finding out about a new customer to ensure the lead is fully qualified (do they have the budget / the authority, the pain / the urgency to buy?) before proceeding along the sales funnel.
2. Promote downstream roles upstream.
Sometimes you just need to redesign the whole process and have your downstream role take up upstream responsibilities.
To note, this "tip" requires quite a bit of proper transformation within the organization:
- cross-functional trainings;
- setting up stand-ins / back-ups for all process roles;
- setting up systems to automate data validations (in templates and checklists) wherever possible;
- have a Business Process Lifecycle Management practice in place.
I never said it would be easy! :-)
More to come :-)
Sunday, September 1, 2013
Lean Processes, Tip #02
Minimize the number of handoffs
If you want a fast and reliable process, cut the middlemen.
A process handoff is an intermediate step in a business process where work and information passes from an upstream player to a downstream player.
Handoffs are the usual suspects for a slow process. Here's why:
1. a handoff is an opportunity for cycle time build-up
Prior to a handoff, the upstream employee usually prepares the information, the documents, the action history or any other data that will assist the downstream employee in performing future work.
After the handoff, the downstream employee will consume the data prepared by the upstream employee, will seek clarifications and / or further guidance and will then proceed with work.
These additional activities create additional time in the process, only for the sake of the process.
Example: most Sales people abhor doing paperwork - especially when they create a new sales transaction. If they have to bring complete cases to the Legal Department, they have to spend time building them. Under pressure, they will deliver incomplete cases just to hand them off quickly and then the time waste is moved in the Legal Department. This could be redesigned through a technique I am going to discuss about next week.
2. a handoff adds noise in the information flow
With signal, comes noise. The more we communicate, the more likely we are to be misunderstood. When handing off multiple activities multiple times, the noise can get out of control.
In the SCRUM methodology (an agile software development methodology), an estimated 50% of knowledge is wasted after 5 successive handoffs. Therefore, a handoff is a significant opportunity for mistakes and misplaced work, to the point you could reliably measure its cost.
Example: a purchasing employee obtains an additional rebate deal for a complex Purchase Order, gets approval of Management in one form, then passes this to Contract Management, who then passes this to the Warehouse (if it's a goods deal) or to a Service acceptance function (if it's a service deal), then somehow this info needs to come to Invoice Passing (maybe other functions, like Engineering or Tax). The more complex the deal is, the more likely it is to get misunderstood, to get stuck, or to get executed very differently from what has been approved - and generate lots of waste.
If you cannot minimize the number of handoffs (especially in large organizations), there is a solution: morph your handoffs into teamwork.
More on that next week :-)
If you want a fast and reliable process, cut the middlemen.
A process handoff is an intermediate step in a business process where work and information passes from an upstream player to a downstream player.
Handoffs are the usual suspects for a slow process. Here's why:
1. a handoff is an opportunity for cycle time build-up
Prior to a handoff, the upstream employee usually prepares the information, the documents, the action history or any other data that will assist the downstream employee in performing future work.
After the handoff, the downstream employee will consume the data prepared by the upstream employee, will seek clarifications and / or further guidance and will then proceed with work.
These additional activities create additional time in the process, only for the sake of the process.
Example: most Sales people abhor doing paperwork - especially when they create a new sales transaction. If they have to bring complete cases to the Legal Department, they have to spend time building them. Under pressure, they will deliver incomplete cases just to hand them off quickly and then the time waste is moved in the Legal Department. This could be redesigned through a technique I am going to discuss about next week.
2. a handoff adds noise in the information flow
With signal, comes noise. The more we communicate, the more likely we are to be misunderstood. When handing off multiple activities multiple times, the noise can get out of control.
In the SCRUM methodology (an agile software development methodology), an estimated 50% of knowledge is wasted after 5 successive handoffs. Therefore, a handoff is a significant opportunity for mistakes and misplaced work, to the point you could reliably measure its cost.
Example: a purchasing employee obtains an additional rebate deal for a complex Purchase Order, gets approval of Management in one form, then passes this to Contract Management, who then passes this to the Warehouse (if it's a goods deal) or to a Service acceptance function (if it's a service deal), then somehow this info needs to come to Invoice Passing (maybe other functions, like Engineering or Tax). The more complex the deal is, the more likely it is to get misunderstood, to get stuck, or to get executed very differently from what has been approved - and generate lots of waste.
If you cannot minimize the number of handoffs (especially in large organizations), there is a solution: morph your handoffs into teamwork.
More on that next week :-)
Subscribe to:
Posts (Atom)