One of the questions I received from one of my students this week is how to better capture customer demand data. While I have previously viewed this concept as obvious, I have learned that capturing demand data can be somewhat elusive.
Let's begin with a brief review as to why this data is essential. Demand data makes up the denominator of the takt time calculation. Recall that takt time is equal to the available time divided by the demand ( also known as volume). In our continuous process improvement world, takt time drives most of our analytical calculations. Takt time determines our staffing compliment, our space requirements, our standard work in process amounts, and our just in time kanban calculations, along with setting the rate of products or services.
One of the important requirements in calculating demand data is that the data must align with the units used in capturing the available time. So if we choose to use one work week, or 40 available hours, as our available time, then we are in need of the customer demand data over that one week period. Likewise if we are looking at a year as our available time, then we require the demand data over the same one year time period.
Demand is based on actual customer need. I often hear, we can produce 100 units a day, or we can complete 30 tests a day, or we can schedule 16 appointments per day. This is not demand this is capacity. Similarly, I hear we purchased 1000 units last year. This would be an example of purchases and not demand. What was consumed or what was sold is the demand. We cannot properly calculate takt time based on capacity.
Another common action I see is improvement teams will use the backlog of items (or units) and use that number for demand. For example, we have a 12 week backlog and we would like to burn down the backlog in 3 months, so our demand is 1/3 of the backlog per month. This is also not demand. This assumes there are no further requests for services or units over the next 12 weeks.
When we ask for demand data, we are looking for the steady state customer need. Let's assume in our 12 week backlog example the customer demand is 16 units per week. To get to a 12 week backlog, we would need to have 168 units already in the queue. Being able to process 16 units per week, would prevent the backlog from growing. We would need to run faster than 16 units per week to burn backlog. The steady state customer demand is 16 units. Normally when you desire to burn backlog, you need to get to steady state first, then make a plan to burn the backlog.
Now to actually get demand data, we may need to employ a variety of data collection techniques. Common approaches include mining electronically captured data, direct observation, and check sheets. If you cannot immediately capture demand data, the electronic approach will likely not be successful and you will need to quickly move to manual data collection approaches.
In summary capacity does not equal demand. For takt time calculation, we need the steady state customer demand. Once the steady state demand is understood and we are capable of producing to that rate, we then can evaluate accelerating the run rate to burn down a backlog (if it exists) to meet our customer required service levels.
Lean Blessings,
Ron Bercaw
President, Breakthrough Horizons Ltd
Shingo Award Winning Author
No comments:
Post a Comment