Everything posted by mohanpb0
-
Are Corrective and Preventive Actions Always Necessary — or Is Simple Correction Sometimes Better?
Examples of Correction, Corrective Action and Preventive Actions In a typical outsourcing organisation, when as part of a transaction being processed, a wrong entry has been made by an associate in a web form and this is identified in an internal audit, the transaction is not completed and dispatched, but is reverted back to the associate for action. The associate corrects the entry made and sends it back. This is the Correction that has been done. At the end of the week, the error log for the week is compiled and this error is root-cause analysed. It is found out that this error occurred because the concerned associate had missed the recent update on the rules to be followed given by the Team Leader, who had of course received this from the Customer. Therefore, in order to ensure that this type of root cause does not cause errors again, a practice of recording the attendance of all team members in all these update and feedback sessions, against the full team list is implemented in multiple shifts as required. This reveals the names of the team members who have not attended the session. When these team members then return to work and log in to the application, they get a prompt, “Please get the last update from your Team leader”, without doing which they cannot log in and start working. Thus, all team members have to get the update, before working again. The SOP is updated with this additional control. This is the Corrective Action that has been implemented. In the Monthly Review Meeting attended by all Business Heads, the summary with selective details of all errors and omissions are presented and reviewed by the Senior Management. This error and the actions taken are also discussed and it is agreed to extend this practice to all Business Lines and Customers. This is implemented with due support from the Internal Development team. The Central Documentation and all relevant Business Line level documentation are updated to ensure that this root cause does not have the opportunity to cause errors in other Business Lines. This is the Preventive Action that has been implemented. Situations where both preventive action and corrective action are undesirable and correction is the only preferred action A popular, if old-time saying on efficiency goes, “Nothing is more inefficient than doing efficiently, that which should not be done at all”. There could be situations in some processes in which some obviously non-value adding or for that matter waste steps are being done. These could typically be only temporary situations till a fix is being implemented that will eliminate these NVA / Waste steps altogether. If the fix is not very far away, and in the intervening period, an error occurs in one of these NVA / Waste steps, it may actually be a good idea to restrain actions to just corrections as the investments of time, effort and money in CAPA may not be justifiable as the environment or even the eco-system may undergo a complete change soon and there may not enough time to get a return on investment. The same reasons stated above may be valid in not implementing CAPA when a core application is going to be upgraded to a higher version or be replaced by an entirely new technology. Yet again, there could be errors associated with a specific location or work station, which precludes any CAPA as the process could be moved to a different location or the work station could be shifted elsewhere and so on. Further, in this age of instant Mergers and Acquisitions, in an organisation that is being swallowed by a larger one, as a result of which, the smaller organisation may cease to exist altogether or a product or an entire line of products may be discontinued. In such situations too, CAPA may be superfluous. To push the envelope open further, when some CAPA relates to a staff, who is going to attrite shortly, it may not be worthwhile to plan and implement CAPA.
-
Check sheet
The best way to correctly understand the evolution of Quality tools is through an analogy with a process, the results from which all of us have benefited, are benefiting and will benefit - Cooking. Once upon a time, a most important part of cooking was to prepare the spices (Masala) that was the very life of the dish. The process of dry roasting raw materials, crushing and grinding them, mixing them in the correct proportion was a difficult skill to master and needed specialized training and practice to achieve reasonable proficiency at it. However as time went on, lean principles were applied and after it was realized that spice preparation was not quite as core a process as the cooking itself, it was outsourced. Now, the cook has multiple options and brands of spices to choose from and neither is the value-add of the spice to the dish diminished due to outsourcing nor are the performance KPIs of the output adversely impacted due to outsourcing. The process of cooking has been effectively deskilled with the result that more people are able to do an effective job of it. Similar to the above, all Quality tools go through a process of evolution to become even better albeit in different forms. The "Check sheet" tool may not be explicitly used nowadays as it was in the past but the principles behind check sheeting that give valuable data which are the life of any structured improvement approaches still remain relevant. On the contrary, it is because "Check sheet" is such an essential, inseparable part of data collection, has it been automated. On the Quality education side, one good way to have trainees or students understand tools and methodologies better, would be to explain them from first principles in a brief manner. Therefore, explaining the concept of Check sheet would continue to be a part of Quality Education. It need not continue to be an independent tool, but will be an essential part of an integrated, automated data collection "Tool" perhaps along with Stratification.
-
Kanban / Pull System
Some of the situations in which the "Push" system is generally successful would be one or more of the following. No two situations are the same, even if some appear similar. 1 Demand is easily and accurately predictable Due to an accurate forecasting system, the risk of carrying “dead” inventory is less. Moreover, by planning and pushing a steady volume to the market, supply chain and production are also steadied, thereby eliminating delay losses. 2 Conversion costs between products is low due to late point differentiation If in spite of an accurate forecasting system, there is a difference in the final product type demanded, the stock of Product A can be converted to Product B at a very low cost and pushed on to the market. 3 Very short time demanded from order to delivery If a very short delivery time or instant delivery from the point of time an order is placed is demanded by the market or customer, there is no option except to supply from stock and avoid revenue losses due to short supplies. 4 Products do not deteriorate during storage When there is no constraint on “shelf life”, the risk of inventory to be written off is low. Further more, inventory is being used up sooner rather than later, reducing cost of delays. 5 Carrying cost is less than cost of lost business When a manufacturer is able to make up for the expense of carrying inventory by exploiting the predictable demand, the likelihood of profiting, “net-net” is high when compared with the potential loss of business, customers and reputation by becoming Just-Short-Of-Time rather than Just-In-Time 6 Long, geographically global supply chains with their own unpredictability Even with the best e-Kanban-powered pull system, the long winding, supply chain that traverses the entire globe is so packed with potential “delay-bombs”, that some “good-old” stock, which can be pushed becomes the life-saver 7 Shipping costs can be optimised by shipping in bulk When the costs of transporting raw material or components or sub-assemblies can be whittled down to almost next to nothing by using up (say) full container space, stocking up and pushing is not a bad idea 8 Demand profiles across time periods are static When there is no fluctuations between days of a week, weeks of a month and months of an year, it is profitable to stabilise production and supply chains by planning and pushing an average volume periodically to the market
-
Cost of Poor Quality (COPQ) sounds powerful — but is it truly driving improvement, or just measuring failure?
The principle, "No pain No gain" used by body-builders, athletes and sportsmen is applicable to all aspects of life, including the corporate world. Cost of Poor Quality (CoPQ) is a classical example of the truth of this adage. Would explain CoPQ as the cost of the four "tion"s - Prevention, Detection, Correction, Dereliction. The last "tion" may raise more than just a few eye-brows, but the more popular term, "failure" happens ultimately due to some kind of dereliction somewhere. CoPQ when correctly assessed and used turns out to be a great "Decision-making" tool. It speaks the language preferred by the Top Management - the language of Vitamin M - Money. Convincing the Top Management to take decisions and approve investments becomes easier when the negative impact (Costs) are realistically assessed and presented. After all, avoiding the loss of a rupee is considered the equivalent of three rupees earned. For example, the decision to invest in an advanced machine or in specialised training becomes easier when the costs of dereliction (failure) i.e. revenue already lost or revenue that can be lost are quantified realistically and presented. In certain other scenarios, awareness beforehand of the expected costs of 100% inspection and rework (Detection and Correction) can sway a decision on investment in Prevention efforts. This investment need not be only equipment. It could also be increased inspection of inputs and raw material or a longer training programme for staff that preclude possibilities of dereliction leading to increased losses downstream. In yet other situations, the decision to implement sample inspection or audits of the output becomes easier to make if the costs of not doing this are known beforehand. To reach the position described above, where an organisation can calculate the various components of CoPQ quickly as well as accurately, is not easy. It requires a lot of effort to set up the system, but only some effort at periodic intervals to maintain the system. Be it costs of various activities done by different people of different skills, at different levels, using equipment of varied sophistication, or the costs of Management time spent in discussions, meetings video conferencing etc. root cause analysing, defending, explaining or apologising for defects, the basis needs to be established first in terms of (say) Cost per Hour of people at various levels, Functions and roles, and Cost per hour of various activities in terms of the equipment used. Once this made available and periodically updated, extracting the value of various components of CoPQ is not as difficult as it would have been when doing it for the first time. Review and update of these cost norms should happen regularly both at a fixed period and also be triggered by specific events. An annual review is a good trade-off between keeping the CoPQ cost norms updated without indulging in an overkill. Salary increases happen once a year and all costs including CoPQ would also change. Other events warranting a review, even if not immediately, at the next opportunity would be organisational changes, equipment replacement, equipment AMC changes, National Budget & tax regime changes and so on. For any metric to be accurate, there needs to be time, effort and money invested in setting up and maintaining the metric infrastructure. This is applicable to CoPQ also. The CoPQ measured and reported needs to be accurate enough to differentiate between the different products, different types of errors or defects and different market situations. If with the good intentions of simplifying calculations of CoPQ to increase its usage, the process of calculation is approximated to the extent that the system becomes insensitive to some of the key points of differentiation listed above, the effectiveness of usage of CoPQ derived from this method will not be very high. One need not always measure CoPQ to the last paisa, but CoPQ need to remain accurate in the context in which it is used. When projecting costs of the future, one can weight it down with a probability factor to project a realistic picture. Typically, if a defective piece reaches a strategic customer, the potential loss of business with that customers and a chain reaction from some others could be a crore of rupees. But if it is assessed from past history that the likelihood of that happening is only 5%, the CoPQ could be 5% of one crore, which is the less threatening than the total value of business. Such considerations may avoid the usual branding of CoPQ as theoretical by Operations and the Top Management. Monthly CoPQ reports will add more value when it contains trends for the earlier months of the current year and also the last year. It would also be a good idea when publishing Monthly CoPQ Reports to add narratives that seek to explain changes especially increases. For example, in a month, if due to an unavoidable reasons, there has been inputs of quality slightly poorer than normal and having known this before hand, a temporary pre-processing cell is created to filter out defect-ridden inputs and if for various reasons, this cost cannot be passed on to the supplier, it can appear that the costs of prevention have increased. In such a case, if the narrative can include an estimate of the value of other components of CoPQ that have been avoided by investing upstream in prevention, there may be better understanding of the reasons for increase. To summarise, it may be asking too much to expect people to appreciate CoPQ but if consistent, organisation-wide understanding is achieved, it would be a commendable job done.
-
SIPOC
The SIPOC is one of the most useful, yet one of the most maligned tool. Like with any tool, merely preparing a SIPOC will not yield much benefit. One should consciously attempt to draw maximum benefits from it. The SIPOC is pocket treasure trove of process information, which is all sufficiently all-encompassing in its completeness, yet manageably small in size, both physical and electronic. The traditional SIPOC has information on Suppliers, Inputs, Process, Output and Customers, while the enhanced SIPOC has a whole lot of additional, related information like process step times, who does what step, the team size and distribution across shifts, the average volumes of these transactions, the qualifications of staff for this process, the training required and so on. The first beneficiary of a SIPOC is the person or team preparing it. Documenting multiple aspects of a process makes the SIPOC creators first understand their process better and also raises various questions in their mind. They will either find answers to these questions and better their understanding or identify opportunities for improvements in the unanswered questions. Once the SIPOC is complete and is available for viewing or study by all, this opens up more and more opportunities for improvements. All the potential triggers required for stimulating improvement ideas are self-contained in the SIPOC. There are the process step times, which can provoke improvements to automate and reduce work content. There are various stakeholders in the process, which can trigger efforts to simplify the process. There are staff qualifications and skills required, which can initiate deskilling programmes. Every data point or piece of information in the SIPOC has a lot of value in the current context as well as in the outlook for improvements. Additionally, the SIPOC is a most excellent training tool both for the Senior Management who may want to have a bird's eye view of the process to take certain strategic decisions or for the hands-on trainee who wants to understand the process step by step to execute them. To summarise, the SIPOC being a repository of process information is a wonderful documentation, improvement, knowledge management and training tool.
-
Hypothesis Testing
In my humble opinion, Hypothesis Testing (HT) would be the life of the Six Sigma Methodology, where reality checks are conducted to validate one way or the other, assumptions, hunches or expert opinion. In short, Hypothesis Testing is the password to access the Domain of Excellence. Of course, access to the domain alone is not sufficient to achieve excellence. However, HT provides the opportunity for the same. HT symbolises the value add, the Six Sigma methodology brings to the table when compared with traditional improvement approaches. HT captures the essence of the "Data driven-ness" of the Six Sigma Methodology. In a validated Measurement System, HT remains the ultimate decision enabler. Apart from the uses of HT during the Six Sigma project life-cycle, HT is very effective even when used as a stand-alone, "Six Sigma Infrastructural process tool". Any comparisons of period based performance becomes that much enriched with HT. Daily, Weekly, Monthly Performance reports all become even more smarter when combined with HT. All staff can take more educated decisions in their daily work if they apply HT. In the Analyse Phase, HT is used to identify the Vital few Xs from the overall X universe. Further in the Improve Phase, HT is used to validate the results of the pilots. Again, after full blown implementation of the improvements in the Control Phase, HT is again used to validate the success of the project. Apart from the above-mentioned, almost mandatory uses of HT, in certain very specific situations, HT is sometimes also used in the Measure Phase to come to a conclusion on the Measurement System. In some even more peculiar situations, HT can come in handy in Project selection during the Define Phase.
-
Six Sigm in a KPO environment
Thanks to Senthil, Anees and Gurshit for their kind responses Kind Regards, P.B.Mohan
-
Six Sigma Applicability
Hi, Maybe you are right Sundar; just to keep the data complete, one gentleman (incidentally named after a title given to the first Prime Minister of independent India) replied privately on another BMSS forum mentioning that he may be willing to share a case study from his company; the bottom line still remains that till now I have not received a case study yet Thanks, P.B.Mohan
- Six Sigma Applicability
-
Six Sigm in a KPO environment
Hi, I am only trying to use this to push Six Sigma in my company which is a KPO. These case-studies will be used to convince my Management. Names of people and companies can be hidden. Thanks and Regards, P.B.Mohan
-
Six Sigma Case study in a KPO environment
Hi, Could you let me have a Six Sigma Case Study in a KPO environment? (Not BPO) Thanks and Regards, P.B.Mohan
-
Six Sigm in a KPO environment
Hi, Could you let me have a Six Sigma Case Study in a KPO environment? (Not BPO) Thanks and Regards, P.B.Mohan