Whenever we think/speak of Lean Six Sigma, the first and foremost thing that comes to our mind is eliminate waste and reduce variation!! Though there is nothing wrong about that mindset as so many six sigma projects in the world, do focus on that, there is another sibling of that which can do some interesting things as well.Will talk about that now.
In General, Six Sigma can be broadly classified into two DMAIC and DMADV.
While DMAIC is to improve an existing process, DMADV is to go for a new process for providing the service or product , because the old process cannot be improved at all or revamping the product/service itself with a new design. The concept is so powerful that there are few variations in DMADV and is there is a separate branch called "DFSS" (Design for Six Sigma). The major variations of DMADV are DMADOV(Define, Measure, Analyse, Design, Optimize, Verify) and IDDOV (Identify, Define, Develop/Design, Optimize, Verify). So much so has been done using these concepts that the modern definition of Lean Six Sigma can be rephrased as a methodology used for business improvement that enriches the shareholder values by providing high-quality product/service at affordable cost with considerable speed on a consistent basis, thereby maximising customer satisfaction
I very strongly believe that use of Lean Six Sigma helps us to innovate a product/service or make it supreme.
Let me provide an example. Explaining this concept with two imaginary companies. In reality, this happens across in Insurance or for that matter in any other domains.
Background: Consider two insurance companies, 'StandIns' and 'TotalIns'. TotalIns was acquired by StandIns. Both the companies had a Policy Claims product, but both were written in different technologies. StandIns used a legacy system (mainframe) for its product 'SIPC' and TotalIns used its own proprietary system for its product 'TIPC'. After acquiring TotalIns , StandIns decided to migrate the 'TIPC' into its product 'SIPC' after some time of acquiring, so that it can provide continuous support to the existing TotalIns customers.Both the products were handling 3 variations/types namely individuals, corporates and other business entities.
DFSS, the remedy:
Now they decided to add the existing users' data from 'TIPC' product to the 'SIPC' product. This was not easy to migrate the data. Migrating the data from proprietary one to legacy system became cubersome and error-prone. Halfway through that migration project was abadoned. So it was decided that the existing users of 'TIPC' would continue with that product only . The stakeholders were at their wit's end as what could be done. The 'TIPC' product had some good features which 'SIPC' product did not have and the stakeholders at StandIns wanted to utilise them for getting better business growth.
The stakeholders of 'SIPC' product felt that with a proper ground work on the needed functionalities and with a strong desgin base, they would be able to provide a high quality product which can bring profitable business, great customer satisfaction, in the longer run. One of the stakeholders who was in the quality department convinced the others stakeholders of doing a Lean Six Sigma project using DMADV(DFSS) to create a new top-notch product which can cater to both 'SIPC' and 'TIPC' customers. It was overwhelmingly approved.
Problem Statement : StandIns insurance company has been struggling to migrate all the data of 'TIPC' product into its 'SIPC' product since
the Oct 1 2016. All these days 'SIPC' unable to produce customer reports/data properly resulting in extremme customer dissatisfaction and also in a loss of 1 million US $
Goal Statement : Create a high quality product,'SSPC', which caters to both the existing customers of 'SIPC' and 'TIPC'.
The new product will also cater to the new customers and the product should be crated by by 17,Aug 2017.
How was it done:
Following are the steps/activities that were done:
1. Voice of the Customer(VOC) : The stakeholders of the new product thought that focus should be given to the key customers who use 'TIPC' product and that their opinions should be heard. They believed that those customers needs/requirements should be satisfied. Those were captured.
2. The requirements data collected from VOC, was added to the existing list of requirements already available for those two products('SIPC' and 'TIPC')
3. Those captured needs were categorized/affinitized , for brevity so that none of the functionalities are missed out during the product development. For instance, all requirements/needs related to administrative activies, were put under the group "Administation". Needs related to an individual customer were put under "Personal", needs related to a corporate were put under "Corporate" and needs related to other business entities were put under "Business" and so on.
4. All the needs were prioritized with the help of a Kano model. All the must functionalities were highlighted , then satisfactory functionalities were listed out and then the delighting functionalities were drawn out. The objective was to ensure that a minimum viable product (MVP) was achieved at the earliest so that customer dissatisfaction is eliminated right at the outset.
5. Next thing was to find the characteristic through which the success output could be measured. For such a complex sytem which requires two different products to be merged , how could the critical-to-quality(CTQ) be measured ? After much deliberation ,it was decided that CTQ would be a factor called , 'SuccessCode'.
A combination of certain parameters decided the fate of the CTQ. They included various fields from the existing 2 products -
a).PolicyNumber (for both the products),
b).location Code(for existing users of 'TIPC' -needed because both companies were in different regions),
c). policystatus,
d).isActivepolicy,
e). response time (to user's query).
'PolicyNumber' should adhere to the validation rules specified for it. 'Location Code' should be unique and should not be a NAN. 'PolicyStatus' should be either new/renewal and
' isActivePolicy' should be true. 'Response time' should be <=5 seconds.If anyone of this had a discrepancy or throw an error, then 'SuccessCode' would fail with a '0' code , else it will pass with a '1' code.
6. Now the product team/stakeholders decided to have a brainstorming session what are the grey areas where they need to improve their design/technology so that they do not go into the same issues which is why in the first place, this project was started. How to achieve the key parameters/vital X factors which can help to achieve a better product. That was decided
7. The product team decided to go for a Pugh matrix, (named after the person who introduced it - Pugh) which can evaluate multiple options (as a solution to the problem) with various criteria against a baseline option and then allow us to pick the best one. With multiple options, they picked the combination of a web-based system with SpringBatch system, Oracle DB , j2EE . This became the selected option
Below was the Pugh matrix used.
Baseline Option : Mainframe System – PL/1
Criteria
Option1
Option 2
Option 3
Response Time
+
-
-
Batch Processing speed
+
-
+
Concurrent Processing
+
S
+
Effective handling of all CTQ parameters
+
+
-
Total
4
-1
0
Option 1 : Uses Java EE with Object Relational Mapping database and SpringBatch
Option 2: Uses Jave EE with Relational Database Management
Option 3: Uses Mainframe Systems (COBOL) with legacy Database
8. Now the product team developed the product using the selected option (from Pugh), for 'Personal' type (1st variation of the product).
9. The product team loaded all the data for existing users of 'SIPC' and 'TIPC' and got amazed at the speed they were able to see the data for both the users of 'SIPC' and 'TIPC'. The team was able to add new users, seamlessly. Months of pain seemed to be gone in a trance.
10. The product team replicated the development for the remaining two variations for Corporate and Other Business Entities and loaded with data and successfully tested.
11. Product Team had a deployment flowchart and also a checklist that clearly provided how things should be done. There were great celebrations and all the stakeholders and senior management celebrated with great fanfare.
12. A full-fledged Implementation plan was created and on 17th Aug 2017, as scheduled, the product was deployed and it went into live. All the stakeholders were extremely happy.
13. The product team created a list of metrics with which the management can measure the progress of the product's success post its deployment.
14. The product team created a transition plan to the operational team and created a documentation of what was done and how they were done.
15. Three months into the production, because of the product, the StandIns company marginalised its loss that occured earlier and by the end of sixth month, the company had a surplus revenue of 1 million US $. New customers got added and there was so much customer satisfaction and the company's business grew three times.
This improvement was possible only because there were tools and techniques which captured data systematically and stastically and using which the team was able
to work out with a complete and proper solution. By having well organized and scientifically proven techniques/tools , the team was able to achieve its target in style.
There are many other tools and techniques which can be of real use to developing a new product or designing a new product/service. For instance, its worth mentioning about the Quality Function deployment tool which helps your requirements to be converted into design. It essentially converts "What do yo want" to "how do you want" .A sound design will result in a solid product. For instance, you want to create a cage for an animal say Tiger. What would be your requirements. You would want a iron bar with a comfortable space for the tiger just walk a few steps and also ensuring enough height to accomate it. You would want strong doors. How do you convert this into a design requirement. So you would think of
Iron bar or rods and you would specify the length and width of the cage (say, in feet). Then you would talk about thickness of the cage, followed by door quality(in which material, its strength ) . Now your design also has to consider the material used for the cage should not be too light. If its too light, then chances are that the Tiger could break it. So while doing design, all factors should be thought about and ensure that a balance is found out. We should know which factor is affecting which other factor and in what way whether in a positive or negative way. Instead of putting an iron cage, what if i put a wooden cage. It may be light weight(thats one factor) but would it be a safety one(Safety is another factor). These kind of analysis can be obtained through QFD which will help us to decide the design considerations which can help us in creating a best product/service.
Hence i conclue that with the advent of Lean Six Sigma, product innovation has taken gargantuan proportions