When it comes to defects here is a great example I suspect other readers may have experienced. But as you will see it has made me question the Six Sigma approach. I would like to ask for guidance. It’s an example I find is happening with increasing regularity and seems to be linked to the proliferation of web-only businesses and poorly skilled call centres.
How it started: – I had a problem with my broadband connection at home. I called the provider and asked if an engineer could take a look. This was agreed and a date set.
- Defect 1: – The engineer arrives, says he is a PSTN engineer, can’t help and leaves.
- Defect 2: – A Broadband engineer arrives a couple of days later without any notice while I am at work. Concludes there are no problem with connection so must be my equipment.
- Defect 3: – Telephone bill includes £45 engineer call out charge, which I was not informed I would incur!
- Defect 4: – Call the number on telephone bill to complain. Spend 20 minutes listening to “thank you for holding, your call IS important to us” before I give-up.
- Defect 5: – Call first thing next day and get through after only 10 minutes. But its the wrong department, am immediately transferred, “thank you for holding, your call IS important to us”.
- Defect 6: – Call the new department and get through after only 10 minutes. But again it’s the wrong department, am transferred, “thank you for holding, your call IS important to us”.
- Defect 7: – Call the new department and get told they will take 2 weeks to review the case and make contact when they have made a decision.
I lose it at this pointand tried to call the CEO to complain. This has the desired affect and the £45 charge is dropped. As a customer I encountered defect after defect after defect. I felt that everything was wrong.
So lets take a look at Six Sigma.
- What is Six Sigma?
An approach that produces processes with 3.4 defects per million opportunities
- What is a defect?
A failure to meet one of the acceptance criteria of your customers
Now when you run a DMAIC project and are in Define, a key area is the Problem statement. I have been in meetings where we have taken hours to agree a problem statement. It should be SMART, refer to a process output, not attempt to describe the solution etc…
We know that everything is a process. So I encountered the “field engineer” and the “customer billing” processes both with defects.
So here is where I need guidance.
I suspect I’m just the squeaky wheel so they probably wouldn’t. But if by chance the telecom provider decided to launch a project they may start by defining the problem e.g.
We have received over 1000 complaints of customers being charged for engineering callouts in the last 3 months.
And a few months later they would end-up with a message to the call centre to always inform staff to tell customers that they will incur a call-out charge. Great job done, problem solved. I suspect I am not giving enough credit to a potential Six Sigma team here, but it illustrates the point.
But I had loads of defects of which one may be improved. So the point I am coming too is this. If we get the problem statement wrong the whole project is liable to get a poor result. So it would seem that before we can rush into any DMAIC projects we need to do considerable ground-work to thoroughly understand our customers and the sheer variety and opportunity for defects. This could be through tools like Voice of Customer, CTQ-tree, QFD, and FMEA. Its as though there is a major stage pre-DMAIC where you invest in building the infrastructure and a clear understanding of the customer and all the issues they face in doing business with you.
If so, this pre-DMAIC stage is not very well communicated in the training or literature. Please let me know what is wrong in my thinking.