|
06/24/2009 12:26 PM
|
|
|
There is probably a simple answer to this which I'm missing but .....
Other than predicting foot flow/calls and staffing accordingly how do you control WIP in a service led business?
|
|
|
|
|
06/26/2009 08:50 AM
|
|
|
One of the key ways to minimize WIP in a Service environment is to prevent Batching.
An example would be the Apple Stores. They don't force you to wait in a queue to check out. They come to you, ask you if you are ready to check out, swipe your credit card on a portable device, and email you your receipt.
|
|
|
|
|
06/26/2009 08:50 AM
|
|
|
It depends a little on what you consider "WIP"
Are you asking about incoming work queues?
Or work-in-process that is accepted, but not delivered?
|
|
|
|
|
06/29/2009 02:41 PM
|
|
|
I struggled with this for some time. Most service companies are "Build to Order" by nature. In such a case, you can't really control the orders received at step 1 but you can control what is between the first and last step by pulling the work instead of pushing. You won't really reduce the WIP per say but having the orders at step 1 is better then having them unfinished throughout the process.
I would welcome comments from others who have done this.
|
|
|
|
|
07/02/2009 08:55 AM
|
|
|
Actually pulling the work WILL reduce the WIP, usually considerably. "Orders-in-process" would go from "no upward bound" to a limit based on the number of discrete process steps established for the pull.
The backlog level would then be the only variable for service level. Given a more-or-less predictable rate of processing at the internal constraint, the wait time for any given customer could be easily determined and predicted. That, in turn, leads to better decisions about capacity requirements vs. tolerable waiting, etc. At the same time, with the bottleneck clear, capacity becomes a matter of kaizen at that point.
The net result is first, clarity and stability, then the opportunity to make rational operational decisions about kaizen and service levels.
|
|
|
|
|
07/02/2009 08:55 AM
|
|
|
Hello Clive,
Actually I think there is literally thousands of answers depending on how you define WIP but more importantly what you mean by control. To control is "to get something to do what you want it to do". So what is the desired end result of "good control". Some service sector businesses control the wip by scheduling, such as a dentist or a doctor; others are focused on lead time issues such as a fast food restaurant, checking out at Sams or a hotel for example. I can think of literally thousands of mechanisms, depending on the circumstances. Better define them and we can take a crack at it.
Lonnie Wilson
law@qc-ep.com
|
|
|
|
|
07/02/2009 08:56 AM
|
|
|
Thank you for the feedback you have confirmed the conclusions I have come to in that the initial point of contact should be your main queue and then once it's been started on the system should flow quickly with minimal queuing.
On the what is WIP question, As we meansure Cycle Time as the time from initial contact to delivered product (customer) or paid invoice (the company) for us all items as WIP.
|
|
|
|
|
07/06/2009 09:09 AM
|
|
|
It would be good to segregate, at least mentally, your inventory so you know what is true work-in-process, what is a queue (buffer) at the front end.
The true work-in-process is what you would put under tight visual control. Any departure from the standard should trigger some kind of effort to respond, correct the situation, understand why it occurred, and improve the process.
As a sidebar, the term "cycle time" has a lot of vague, and sometimes overlapping, definitions out there. I would like to suggest the term "lead time" or "throughput time" for your measurement of time-through-the-process. That would then reserve "cycle time" for an "actual" value that can be compared to takt or expected processing time. Just a suggestion, I have found it helps avoid confusion.
|
|
|
>
Community >
Forums
Send to a Friend
