Poka Yoke - Mistake Proofing

Inspection with the aim of finding the bad ones and throwing them out is too late, ineffective, and costly. In the first place, you can't find the bad ones, not all of them. Second, it costs too much. Quality comes not from inspection but from improvement of the process.

[W. Edwards Deming, the American statistician who drove Japan's post-war quality revolution]

Poka means an error

Yokeru means to avoid

Poka Yoke is one of the main components of Shingo's Zero Quality Control (ZQC) system -- the idea being to produce zero defective products. One way this was achieved is through the use of poka yoke; a bunch of small devices that are used to either detect or prevent defects from occurring in the first place. These poka yoke methods are simple ways to help achieve zero defects.

A more powerful approach is to design your processes to automatically prevent defects from happening. The Japanese name for such techniques is Poka Yoke, meaning mistake proofing. Poka Yoke has two aspects: prevention and detection. For instance, having different shaped plugs for each type of connection in a PC prevents novices and experts from making mistakes when installing a new PC, and the electric fuses and circuit breakers in your home detect when electrical circuits are overloaded which prevents electrical fires.

Likewise, one of the most common causes of defects – ambiguous requirements - can be prevented by writing comprehensive acceptance tests when each requirement is captured. Furthermore, automating these tests and running them as part of frequent integration-builds help detect defects when they happen.

Ref:

http://en.wikipedia.org/wiki/Poka-yoke

http://www.isixsigma.com/tt/poka_yoke/

http://www.school-for-champions.com/tqm/poka-yoke.htm

John Grout's Poka-Yoke - http://facultyweb.berry.edu/jgrout/

Zero Quality Control By Shigeo Shingo, Andrew P. Dillon - http://books.google.com/books?hl=en&id=gkE8K7axQbYC&dq=poka+yoke&printsec=frontcover&source=web&ots=AiVC2NOBaI&sig=DrrGyvuyGwVe6d4FLkUXcFtzRws&ei=amOUSfCAHIKUsQOR_JiuBw&sa=X&oi=book_result&resnum=12&ct=result#PPA68,M1

http://csob.berry.edu/faculty/jgrout/tutorial.html

http://www.isixsigma.com/offsite.asp?A=Fr&Url=http://www.campbell.berry.edu/faculty/jgrout/tutorial.html

http://www.campbell.berry.edu/faculty/jgrout/pokayoke.shtml

Kaizen - Continual Improvement

Kaizen - Continual improvement philosophy in Japanese ... a system of continuous improvement in quality, technology, processes, company culture, productivity, safety and leadership.

Kai => change
Zen => good

Ref:
http://en.wikipedia.org/wiki/Kaizen

http://en.wikipedia.org/wiki/Continuous_improvement

http://www.valuebasedmanagement.net/methods_kaizen.html

http://www.graphicproducts.com/tutorials/kaizen/index.php

http://www.leankaizen.com/tag/overview-level/

The rule of thirds, team selection

Here is a quick tip for selecting team members for a kaizen blitz or rapid improvement event.

It's called the rule of thirds. The basic idea behind this rule is to choose team members based on the following split.

1/3 rd of the team should be people who have Day to Day association with the project area.

1/3 rd of the team members should have a Functional association with the project area.

1/3 rd of the team members should not be connected with the project area

FMEA and FishBone Analysis

FMEA - Spotting problems before a solution is implemented

FishBone Analysis - Identifying the Likely Causes of Problems



Failure Mode and Effects Analysis (FMEA)



Spotting problems before a solution is implemented when things go badly wrong, it's easy to say with hindsight, "We should have known that would happen". And with a little foresight, perhaps, problems could have been avoided if only someone had asked "What Could Go Wrong?"



By looking at all the things that could possibly go wrong at design stage, you can cheaply solve problems that would otherwise take vast effort and expense to correct, if left until the solution has been deployed in the field. Failure Modes and Effects Analysis (FMEA) helps you do this.

More than this, FMEA provides a useful approach for reviewing existing processes or systems, so that problems with these can be identified and eliminated.



Understanding FMEA

FMEA grew out of systems engineering, and is a widely-used tool for quality control. It builds on tools like Risk Analysis and Cause and Effect Analysis to try to predict failures before they happen. Originally used in product development, it is also effective in improving the design of business processes and systems.



Link : http://www.mindtools.com/pages/article/newTMC_82.htm



Cause & Effect Diagrams



Identifying the Likely Causes of Problems

Related variants: Fish or Fishbone Diagrams, and Ishikawa Diagrams



Cause and Effect Diagrams help you to think through causes of a problem thoroughly. Their major benefit is that they push you to consider all possible causes of the problem, rather than just the ones that are most obvious.



The approach combines brainstorming with use of a type of concept map.

Cause and Effect Diagrams are also known as Fishbone Diagrams, because a completed diagram can look like the skeleton of a fish.



Link: http://www.mindtools.com/pages/article/newTMC_03.htm



Risk Analysis & Risk Management



Evaluating and Managing the Risks You Face



Almost everything we do in today's business world involves a risk of some kind: customer habits change, new competitors appear, factors outside your control could delay your project. But formal risk analysis and risk management can help you to assess these risks and decide what actions to take to minimize disruptions to your plans. They will also help you to decide whether the strategies you could use to control risk are cost-effective.



How to use the tool:

Here we define risk as 'the perceived extent of possible loss'. Different people will have different views of the impact of a particular risk – what may be a small risk for one person may destroy the livelihood of someone else.

One way of putting figures to risk is to calculate a value for it as:



Risk = probability of event x cost of event



Doing this allows you to compare risks objectively. We use this approach formally in decision making with Decision Trees.

CMM

CMM - Capability Maturity Model



Structure of the CMM



The CMM involves the following aspects:



Maturity Levels: A 5-Level process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement.



Key Process Areas: A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.



Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.



Common Features: Common features include practices that implement and institutionalize a key process area. There are five types of common features: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.

Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.



Levels of the CMM:



There are five levels defined along the continuum of the CMM, and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."



The levels are:



Level 1 - Ad hoc (Chaotic)

It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.



Level 2 - Repeatable

It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results.Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.



Level 3 - Defined

It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.



Level 4 - Managed

It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.



Level 5 - Optimized

It is characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.

At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the process (for example, shifting the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.



Links:



http://www.sei.cmu.edu/cmm/



http://en.wikipedia.org/wiki/Capability_Maturity_Model

ITIL vs SIXSIGMA

ITIL essentially provides a clearly defined structure for delivering and supporting IT-based services.

Six Sigma is a quality-management process based on statistical measurements used to drive quality improvement while reducing operational costs.

The ITIL structure is a framework to deliver and support IT-based services. SLM, by definition, is the process of defining and then managing IT service delivery to a standard of quality. Six Sigma fits well with this because it creates a way to tangibly measure the service that can either formally be built into service-level agreements (SLA) or informally within the organizational structure.

ITIL defines a framework for IT Service Management. It consists of a set of guidelines, based on industry best practices, that specify what an IT organization should do. ITIL does not, however, define how to do it. For example, ITIL specifies that IT should allocate a priority for each incident that comes into the service desk. But, it does not specify how to allocate those priorities.
With ITIL, it's up to the IT staff to flesh out the details of process flow, and create detailed work instructions, all in a way that makes sense for their organization.

Six Sigma, on the other hand, defines a specific process, based on statistical measurement, that drives quality improvement and reduces operational costs. It helps in developing detailed work instructions, and it defines a methodology for continually mapping, measuring, and improving the quality process. Six Sigma tells you how, but doesn't tell you what. This approach does not specify any best practices specifically for IT Service Management.

In summary then, ITIL defines the "what" of service management, and Six Sigma defines the "how" of quality improvement. Together, they are a perfect fit for improving the quality of IT service delivery and support.

Links:

SixSigma -http://www.isixsigma.com/

ISO 9001 , ITIL , Sixsigma - http://www.thinkhdi.com/library/deliverfile.aspx?filecontentid=526

Combining ITIL & SixSigma - http://documents.bmc.com/products/documents/67/60/46760/46760.pdf

Use Sixsigma to complement ITIL v3 - http://www.eweek.com/c/a/Knowledge-Center/How-to-Use-Six-Sigma-to-Complement-ITIL-v3/

Quality Methods / CMM / ITIL / Six Sigma - http://www.sourcingmag.com/outsourcing_tactics/quality_methods_cmm_itil_six_sigma.html

Use Fishbone to solve complex problems - http://blogs.techrepublic.com.com/tech-manager/?p=561&tag=nl.e053

Communication is the key to controlling project chaos - http://blogs.techrepublic.com.com/tech-manager/?p=544&tag=nl.e053

Manage project time requirements with these methods - http://blogs.techrepublic.com.com/tech-manager/?p=548&tag=nl.e053

http://www.nextslm.org/itil/itil_sigma.htm