>> S Q P S Blog

In the previous post, I outlined how lean projects can be manged through Plan-Do-Check-Act (PDCA) cycles. Here, I’ll be walking through an example.

Plan

This step includes drawing current value stream (VS) map in terms of processes (or activities), calculating processing times on the value stream, and analyzing for waste. After conducting some brainstorming, the PDCA team can list opportunities for removing such waste by reducing, re-organizing, realigning, training. Finally, we prioritize such opportunities start implementation with those with highest impact first.

In this example, a pizza shop takes orders for delivery over the phone and processes manually.  Customers complain about delivery time being long. Here is how the process works:

• The order taker writes down all order information (type of pizza, size, ingredients, ..etc.) as well as the address.
• Order gets verified by the manager before forwarded to the kitchen. In case of any missing information, the order taker calls the customer back for corrections
• Prepare pizza
• Pizza sits in queue before baking
• Bake, cut, package and label pizza
• Pizza waits in warmer for delivery
• Deliver pizza

The goal here is to eliminate all complaints due to “long delivery time”and increase customer satisfaction.

Times form the above value stream can be summarized as follows:

Lead Time: The time from the customer calling in until the pizza is delivered. In this example, the Lead time is 44 minutes.Value-Adding: All activities that add value to what the customer experiences / pays for. Those steps amount to 15 minutes which is about 34% of the lead time.

Delays / Waiting amounts to 8 minutes.

The PDCA team has conducted root-cause analysis to eliminate waste (and shorten delivery time). The team decided that the manual system for orders created delays and inefficiencies. So it was decided to implement a computerized system for entering orders and communicating them to the kitchen using computer monitors. Also, it was decided to hire an additional delivery driver. The future value-stream table is expected to look as follows:

Do

• Prepare and implement action plan for  computerized system
• After implementation, let the system run and stabilize
• Collect delivery times data again for measuring progress

Check

• Data analysis after implementation of plan show a reduction of  lead time by an average of 11 minutes. This is a reduction of approximately 25% of lead time.
• Complaints due to long delivery time were reduced by 60%.

Act

The updated  value stream after implementation will become the “current” for the next PDCA. As can be seen from the updated value stream table, delays due”waiting for oven space” and “waiting for driver” are still there and could be minimized or eliminated by coming up with efficient methods and creating additional capacity.

Mustafa Shraim

In the previous post, I related the Toyota issue of sticking accelerator to the type of costs incurred. When failure occurs after the product reaches the customer, the associated costs are regarded as External Failure costs. This goes much further upstream than just replacing the defective part or settling a liability issue. Many examples where given in the previous post as well.

Here, I would like to relate this to the type of error. In general, there are 4 scenarios:

1. Your product or service is GOOD and your QC program let it PASS
2. Your product or service is GOOD and your QC program REJECTED it
3. Your product or Service is NO GOOD and your QC program let it PASS
4. Your product or service is NO GOOD and your QC program REJECTED it

Now guess which scenario affected Toyota’s reputation and bottom line!

When QC lets a NO GOOD product go to the customer, that’s a serious type of error (Type II). This is often called “Consumer’s Risk” beacuase the customer is paying a price as well as Toyota (In this case, deaths resulted from failure). The impact of such error for Toyota, primarily because it deals with safety, is huge and most likely will last a long time.

The Toyota case of sticking accelerator is a good example of how External Failure costs can add up very quickly. As mentioned in the previous post, external failure costs (the worst type of quality costs) are those related to a failure after the product has reached the customer. In addition to the impact on Toyota’s near-perfect reputation, and the loss customer confidence in the brand name, other immediate costs are incurred by the company and include, but not limited to, the following:

• Recall costs
• Warranty (of unaffected cars)
• Replacement / repair of sold and unsold cars
• Training service staff on special repair
• Liability / lawsuits
• Downtime at factories
• Wages during downtime
• Scrap and disposition of questionable parts
• Troubleshooting / Corrective actions
• Trips made by executives / engineers / designers
• Public relations
• Working with suppliers
• Dealership support
• Overtime for suppliers (for making good replacement parts)
• Additional freight and premium freight for replacement parts
• Additional legal council (in many countries)
• Discounts for future sales

It is estimated that, with the lawsuits associated with the recall, this will cost Toyota over $2 Billion. The question is could this have been prevented? or at least taken seriously after the very first few complaints? was failure mode and effects analysis (FMEA) or equivalent done for the break subsystem?

Six Sigma is a disciplined method that works in phases. A Six Sigma Black Belt (BB) learns that he/she must complete a phase before going to the next. The phases in order are: Define, Measure, Analyze, Improve, and Control (also known as DMAIC). To ensure that a BB does not go from one phase to the next prematurely, checkpoints (tollgates) are set up. These tollgates might be a number of questions (checklist items) that the Master Black Belt (MBB) or Champion goes through with the BB to ensure satisfaction with the phase. Once completed, the BB can move to the next phase.

After leading and coaching many Six Sigma projects, I found it more natural to go back and fourth between phases. For example, I found myself making a number of iterations among phases (Measure==>Analyze==>Improve==>Measure… and so on). Once the process is improved and measured to meet established goals, it can then move to the Control phase. Feedback to the Define should be open after evaluating process control.

In addition to measuring improvements using appropriate metrics, the real test of success is sustaining such improvements over time.

What is your experience?