Académique Documents
Professionnel Documents
Culture Documents
Official Publication
V 1.03
October 2015
Table of Contents
Scope and Purpose
1 Introduction
1.1 Definitions...................................................................................................................................................................................................... 6
1.2 The Kaizen Mindset.................................................................................................................................................................................. 7
1.3 Improvement methods.......................................................................................................................................................................... 8
1.4 DMAIC............................................................................................................................................................................................................. 9
1.5 Lean and problems..................................................................................................................................................................................10
1.6 Problems in IT............................................................................................................................................................................................ 10
2 Organizing Kaizen
12
3 A3 Method
16
3.1 A3...................................................................................................................................................................................................................... 16
3.2 Contents of a Problem-solving A3................................................................................................................................................. 16
3.3 A3 Status Report and A3 Proposal............................................................................................................................................... 19
3.4 Skills for completing an A3.................................................................................................................................................................20
3.5 Building communication.......................................................................................................................................................................20
4 Define Phase
23
5 Measure Phase
37
5.1 Data................................................................................................................................................................................................................. 37
5.2 Measurement Systems........................................................................................................................................................................39
5.3 Baseline and Benchmark.....................................................................................................................................................................42
5.4 Value Stream Map..................................................................................................................................................................................43
5.5 Measure phase and A3.........................................................................................................................................................................45
5.6 Key Steps in the Measure phase.....................................................................................................................................................45
5.7 Case Study: Measure Phase...............................................................................................................................................................48
6 Analyze Phase
50
7 Improve Phase
71
8 Control Phase
79
9 Appendix 1: References
89
10 Appendix 2: Glossary
90
101
Target audience
The target audience for this document is:
Copyright notes
ITIL is a registered trade mark of AXELOS Limited.
COBIT is a trademark of ISACA registered in the United States and other countries.
PRINCE2 is a Registered Trade Mark of AXELOS Limited.
PMI is a registered Trade Mark of the Project Management Institute, Inc.
Acknowledgements
The author would like to thank everyone who put their time and effort into improving this document.
The author would especially like to thank Troy DuMoulin (Pink Elephant) for the inspiring discussions
to get the right content into the Kaizen syllabus and the first reviews.
Many thanks to the following peoplefor their critical reviews, which helped to improve this
publication:
Mike Orzen, Mike Orzen and Associates, Member of Lean IT Association Content Advisory
Board
Barry Fairingside, APMG
Gary Case, Pink Elephant
Rita Pilon, Exin, Member of Lean IT Association Content Team
Hans van den Bent, CLOUD-linguistics
Marianne Hubregtse, Exin
Natasja Soselisa, Quint Wellington Redwood
Ilona op de Weegh, Quint Wellington Redwood
1 Introduction
As one of the pillars of Lean and Lean IT,
ensuring that an IT organization is competent at
ensuring continuous improvement in line with
the interest of the customer(s) is absolutely
vital to the success of Lean within IT.
In the Lean IT Foundation, we looked at the
basics of Kaizen (continuous improvement) and
the DMAIC problem-solving method. In this
document, we will build on this material to help
you on your journey to mastering continuous
improvement, and becoming a Lean IT Kaizen
Lead. The Lean IT Kaizen Lead is someone who
is involved with Lean improvement that could
be at any level of the IT organization, in any
department.
We will be using terms defined in the Lean
IT Foundation publication. Where a term is
central to this document, we may repeat
Foundation material. If you are no longer
familiar with a particular term, please refer to
the aforementioned document.
We will take an in-depth look at the key aspects
of organizing and running a Kaizen event. We
will also investigate the DMAIC problem-solving
method in substantially more detail than we
did in the Foundation document. On top of
this, we will use the A3 method to record and
communicate the findings of our Kaizen event.
1.1 Definitions
There are three main words used within the
domain of improvement: Kaizen, Kaikaku and
Kakushin.
Kaizen is the Japanese word for continuous
improvement using small incremental changes.
mindset?
1. Seeing and prioritizing problems: are
both managers and employees truly
prepared to uncover problems, accept
them as a part of daily life and initiate
action to identify the problems that
most need solving?
2. Solving problems: are both managers
and employees prepared to invest time
and other resources to understand the
root causes of problems and resolve
problems completely?
3. Sharing lessons learned: are both
managers and employees driven to
share the lessons learned as a result of
solving problems with others in the IT
organization, so that they may benefit
from the lessons learned?
It is important to note at this point that
Problem Solving is not about reactively waiting
for problems to appear and then resolving
them as they occur. A problem solving mindset
is to first establish a desired state for the
service and or process, understand the current
baseline and gap and, then, to incrementally
close the gaps towards the desired state
through Kaizen improvement steps. The
essence is that identifying problems and
solving their root causes drives individual and
organizational learning.
There are, in fact, two types of kaizen:
Improvement Kaizen and Daily Kaizen. The
one we will be dealing with in detail in this
document is the former and we will refer to this
as kaizen. It is focused on carrying out kaizen
events to bring about incremental change. Daily
Kaizen will be further discussed in the Lean IT
Leadership certification.
Daily kaizen is more closely related to the
kaizen mindset as it entails continuously looking
as the Deming Circle. This is the Plan-Do-CheckAct (PDCA) sequence. This cycle is applicable
in any situation, and forms the basis for all
improvement within Lean. Its premise is that
by following the plan, do, check and act steps
in that order, we are able to purposefully take
steps to improve the capabilities of individuals,
organizations, processes and technology. The
Deming Circle consists of the following steps:
1.4 DMAIC
Within Lean IT, we also recognize the PlanDo-Check-Act cycle as an integral part of
continuous improvement and recommend its
use in all circumstances. We have, however,
chosen a more specific problem-solving method
1 ITIL is a Registered Trade Mark of Axelos Limited,
2 COBIT is a Registered Trade Mark of ISACA
1.6 Problems in IT
IT is one of the fastest developing areas of
society; the phenomenal increase in processing
power, transmission of data across networks
10
11
2 Organizing Kaizen
As we saw earlier, the aim of kaizen is to ensure
that problems are identified and solved, and
that lessons learned are shared within the IT
organization. It is vital that leaders within the IT
organization emphasize the need for the kaizen
mindset.
12
13
14
15
3 A3 Method
One of the powerful tools that Toyota has
institutionalized within Lean is working with A3
reports. It supports and promotes continuous
improvement, and is based on the PDCA cycle.
3.1 A3
A3 is not a clever acronym, it simply refers to
the size of a piece of paper. A3 is 29,7 cm by
42 cm (11,7 in by 16,5 in). It is twice the size
of A4 and half the size of A2. The beauty of
the A3 sheet is that it provides enough space
to explain a relatively complicated story, but
limits the writer in their verbosity. The aim
of the A3 is to encourage conciseness in the
communication of a message. It also works as
a checklist to ensure strict adherence to the
chosen problem-solving methodology, in our
case DMAIC.
It is important to understand that there is no
hard and fast way to complete an A3 problemsolving sheet. Most A3 sheets tend to have 7
or 8 sections, as we will see below. However, if
you wish to have 5 sections focusing on DMAIC,
then this is acceptable. It is important that the
problem-solving A3 covers the complete PDCA
cycle. The key determinants for a good A3
sheet are:
1. Does it help the team compiling it to
follow a structured problem-solving
method?
2. Does it help people who need to take
action on the outcome, to understand
the logic that led to the outcome?
16
Alternatives may include the following models. The first model includes a flow in which the position of
the Analysis step is clearly seen as an intermediate step.
17
Each of the three models presented is valid as it helps the team carrying out the kaizen to both follow
a process and to communicate a result.
As we stated earlier, within IT, we not only recognize problems to be solved. We also recognize
Problems. These tend to be issues of a technical nature that are the root cause of incidents. An A3
model for the resolution of these Problems could be the one below.
18
19
20
The Situation-Complication-Key Question trilogy will be recognizable in the next chapter as a problem
statement. The answer includes the structuring process required to bring the Measure, Analyze and
Improve steps together.
Using the Pyramid Principle means using a bottom-up approach for grouping arguments (the As in
the above figure) in a logical way such that they support a motivation for the answer you give. The
Answer should be supported by three clear motivations as to why this answer is the best answer to
the Key Question. The arguments and motivations will come from the Analyze phase of your kaizen
event. The Answer will be the result of the Improve phase.
A useful technique in constructing an argumentation pyramid is MECE. This stands for Mutually
Exclusive, Collectively Exhaustive. Mutually Exclusive means that all items in a particular category
only belong to that category, and no other. Collectively Exhaustive means that all possibilities have
been covered.
In an IT context, we may encounter a situation where there is a lack of satisfaction with two services.
Based on a data set including a variety of calls, we would need to have each call put into a single
category, e.g. the call may be an incident, a service request, a request for information or a complaint.
These categories would need to be defined in such a way that all calls in the data set fall into one of
the four categories, and only one of the four categories. In this way, the set and the analysis on which
the data is based would be assured to be MECE.
Subsequently conclusions drawn and proposals suggested would also be relevant to the correct
calls. Analysis may show that the calls for a particular application are distributed 80% incidents and
20% service requests, whereas a second application may have 20% incidents, 40% requests for
information and 40% service requests. Assuming for one moment that the absolute volumes of calls
are the same, the analysis may conclude that application 1 is technically unsound since it has many
technical disruptions. Further analysis may identify the causes of these disruptions. Secondly the
21
analysis may show that there has been insufficient training of users regarding application 2 because
there are many calls for support.
The result is two motivations resolve the technical problems and train the users and a series of
arguments leading to these motivations. The answer to the key question may then be: we need to
invest differently in applications 1 and 2, to increase the user satisfaction of the two services.
22
4 Define Phase
'The beginning of wisdom is the definition of
terms is a quote attributed to Socrates. He
might just well have said The beginning of
solutions is the definition of problems. And,
in practice, it turns out to be true. Once a
problem has been defined, the problem can
appear to diminish in size or importance. As our
understanding increases, so does our feeling of
our ability to solve the problem.
This issue of the perceived diminishing size of
a problem gets more significant the more we
understand about the problem. We will return
to this issue as we go through the DMAIC cycle.
Unsurprisingly, Define is the starting point
for DMAIC, namely with the definition of the
problem to be solved.
Before we can start, we need to work out
which problem we are going to solve. This may
appear to be simple, especially since one of
the most prevalent starts to a sentence within
IT is The problem is followed by a problem
statement of dubious quality. On top of this,
the problem statement usually includes the
preferred solution somewhere in an adjoining
sentence, e.g. The problem is that [x] is not
possible with Windows/Linux, but is possible
with Linux/Windows, or The problem is that
development doesnt provide us in Operations
with a decent handover document.
A good way to start developing the Kaizen
mindset within the IT organization is to have
a standard response to these The problem
is statements. The standard response
could be something like But is that the real
problem? Experience has shown that this
simple question, gets IT people thinking about
problems in a constructive manner.
23
24
25
26
27
28
Problem
Explanation
29
Undoubtedly, while reading the list, you will have recognized problems; others may not be relevant
in your IT organization. There will also be problems for which there are standard solutions (if
you use [standard IT solution], you can solve the problem). Although the above problems may be
recognizable, their specific causes may be diverse and different per IT organization.
30
For each of the types of stakeholders, we see that there is a communication strategy involved in
keeping the stakeholders engaged with the problem.
31
The questions may seem simple but can take considerable time and effort to answer accurately.
32
33
34
35
As a result of the pre-kaizen information sessions, it was quite easy for the participants to state
what they thought the problem statement should be. It took a further two hours to finally gain
full agreement among all parties regarding the problem to be solved. The result was particularly
interesting because the problem statement was closest to the problem statement as stated by
the infrastructure engineers. It was not the case that management and team leaders used their
hierarchical power to push through their idea of the problem to be solved. Other cases have proved
that a 2-hour session to define the problem statement for a complicated or complex problem is no
luxury. In fact, it is often very necessary. This is because the team had to ensure that symptoms did
not end up being defined as the problem. The kaizen lead had to continually keep the team focused
on the goal and had to question the team members when he felt the symptoms are being turned into
the problem.
Having agreed on the problem statement, the team needed to agree on how much time they would
take to solve the problem. The urgency and impact dictated that the team needed to work as fast as
possible.
36
5 Measure Phase
The second phase in the DMAIC cycle is the
Measure phase. In this phase, we refine the
problem statement based on measurement.
The goal is to ensure that there is a detailed
understanding of the current situation
surrounding the problem area. This is done
by collecting reliable data on the variables
related to the problem. The aim is to provide
information to help identify the underlying
causes of the problem.
5.1 Data
The first step is to define the data to be
collected. The data obviously needs to be
related to the problem statement.
5.1.1 Variables
During this phase, we need to fully understand
the role of variables in the resolution of
problems. There are essentially three types of
variables:
Independent variable: this is an input. In the
case of problem-solving, the independent
variable can be seen as something that may
or may not contribute to the problem. The
aim is obviously to find the independent
variables that have the greatest effect on the
problem.
Dependent variable: this is the output; in
effect, this is the problem.
Control variable: this kind of variable is
particularly useful in experiments. This
variable is kept constant while others are
changed so that they can be investigated.
The mathematical notation for the relationship
between independent and dependent variables
is:
y=f(x)
37
Incident
Service Request
Problem
Standard Change
Operational activity
Any activity necessary to keep the current IT service running, not being
an incident or service request. This category includes events, monitoring
and other daily/weekly activities that ensure the health of an IT service.
Non-standard
Change
Advice
Plan
Within Lean, three categories of units of work are identified. Within IT, there are two basic criteria on
which the categories can be defined: size in hours worked and the process dynamics.
Runners: these are units of work that occur on a daily basis and tend to require up to one hour of
work for them to be completed. Within IT, we can say that incidents, service requests, standard
changes and operational activities fall in this category. The dynamics of these processes is that
work is statistically predictable (per week) but its exact occurrence is not known. This work cannot
be planned as such but time can be reserved for these units of work.
Repeaters: these units of work occur regularly; indicative frequency is weekly. Within IT, we find
high impact incidents, small to medium sized non-standard changes and the smaller advisory
services. This category is partly plannable (advice and changes). However, the high impact incidents
require direct response, and therefore have a dynamic that more closely resemble runners.
Unfortunately, their impact means that solving the incident can require a different effort than
regular incidents.
Strangers: these are units of work that have an irregular occurrence. IT strangers are large nonstandard changes, large requests for advice and plans, which all tend to occur or be updated on a
monthly or quarterly basis.
5.1.3 Technical Data
The other type of data (alongside the units of work) is technical data. This is data that helps us to
understand the behavior of the technology. This type of data includes such entities as
38
Log files: files in which activities (normal and abnormal) of individual IT hardware and,
particularly, software components are recorded
Monitoring data: data and information from monitoring tools, including alerts based on
thresholds
Technical performance data: Data about
CPU, memory, network speed/capacity
and storage usage
39
Automated Data
Collection
Reliability issues
Remedy
Do we correctly understand
what the automated data is
telling us?
40
attempt to create objectivity in the subjective data. This can be done by using a framework of criteria;
most maturity models work on this basis. However, the maturity model is also based on human
perception. This means that qualitative measurement systems are always open to bias, be it based on
the questioning or on the answers. Three forms of qualitative measurement system are the following:
Annotated Observation: This basically means watching what happens and noting the number
of times something happens, the amount of time spent on a task, the number of errors made
in finished products and other such observable occurrences. The tool often used here is the
check sheet.
Interview: One of the preferred methods of gathering information is through interviewing
people involved or people associated with the aspect that is being investigated. An interview
can involve one or more people involved with the subject matter. Generally, multiple points of
view are sought when gathering information through interviews.
Registration: During the course of work in an IT organization, data is recorded on work
units (incidents, changes, problems, service requests). This data provides valuable input for
understanding how the organization performs regarding these units of work. In registering units
of work, the system records time stamps and other data either automatically or as a result of the
action of a user. As a result of the dependency on human action, registration is seen as qualitative
rather than quantitative.
These methods may be combined, and may take the form of asking the person or people being
observed questions about their activities. However, interrupting the work to ask questions does
affect concentration and the overall performance.
Collection
Reliability issues
Remedy
Annotated
observation
of actions?
method
interviewee of course
preferably data
always biased
Involved means having an interest in
the outcome of the interview
41
Registration
Is everything registered
and classified correctly?
Does the registration tool
allow access to the desired
information?
42
to understand how well others perform a particular activity. This may help to identify what
improvements are possible.
Explanation
Lead time
The time between the moment the customer submits their request
to the time they receive the requested item or service
Takt rate
Changeover time
Queue time
Machine Time
Work-in-process
Capacity
The maximum amount of output that the process can deliver over a
period of time
Throughput
VSM Calculations
The most essential calculations in a Value Stream Map are PCE (process cycle efficiency) and Littles
Law
Process Cycle Efficiency = VA time / Process lead time
43
Littles Law helps us to understand the relationship between lead time and work-in-progress.
Littles Law = the number of units of work in the process (WIP) / average completion rate
These calculations can be done over the entire process, but also per process step. This helps to create
a richer picture of the dynamics of the process, and identify where issues exist.
44
45
As we stated above, the value stream map (VSM) describes the current situation of the process at
this phase of the kaizen. Describing the current situation may seem easier than it actually is.
Often, people working in the same process have different perceptions as to how the process actually
works. It is vital to go and look at the Gemba to see how the process is actually executed.
Within IT organizations, there is a tendency to say we already have a process picture" when the
kaizen lead recommends creating a VSM. The process document is usually a couple of years old and
will have been based on a process-oriented implementation. These documents are essentially useless
since they describe a desired situation that has never been achieved; nobody knows the document
except the people who wrote it and it distracts the team from the focus of creating a description of
how the process currently works.
Always take a clean sheet of paper when making an initial VSM.
3. Create and execute the data collection plan
Once we know what the process looks like, we can identify the independent variables that may affect
the problem. When we know the independent variables, we can define the data that needs to be
collected in order to investigate the problem.
There is a strong tendency to believe that IT organizations are difficult to measure. As a result,
kaizen teams within IT may try to take a short cut in the Measure phase. Often, the involvement of a
powerful sponsor will lull the team into a false sense of security.
Powerful sponsorship does not mean we do not need to collect the right data to support the
resolution of the problem. The data is a continuous reminder of how important it is to completely
solve the problem. However difficult collecting data may be, it still must be done. In fact, measuring
the various aspects of IT is not so difficult. The team just needs to be prepared to extract data from
databases. And if theres one business that has people who know how to do this, it is IT.
4. Validate the measurement system
We have already discussed possible inaccuracies within measurement systems. This is why the
kaizen team must validate the measurement system(s) it uses. The idea here is to show that the data
collected can be reproduced and repeated, in exactly the same way.
Any assumptions made must be made explicit. Any manipulation of data must be documented and
explained so that it is clear on which premises analysis is being done in the Analyze phase.
5. Assess the capability and performance of the process
For each measurement we make, we must set a baseline. In the case of the IT units of work, we tend
to create time series charts and determine average performance over a defined period. Setting a
46
single data point as a baseline tends to create an arbitrary and highly contentious baseline.
Although there are organizations that sell benchmark data and reports for considerable sums,
there is also doubt as to whether benchmarking truly helps IT organizations. The problem is that IT
organizations are service organizations in which the factors influencing performance and cost may be
similar but may have very different effects from one organization to another. It is therefore vital to
baseline while benchmarking is optional.
6. Identify Quick Wins
During the execution of measurements, it may become clear that there is a course of action that
everyone involved agrees on; a solution that can be implemented straightaway. This so-called
quick win should be implemented as soon as possible. On rare occasions, a problem thought to be
complicated or complex may turn out to be simple.
As with the Define phase, it is vital to ensure that the key deliverables from this phase are completed
before moving on the Analyze phase. In practice, it is almost impossible to think of everything that
needs to be measured. Often, further necessary measurements will emerge as a result of gaps in the
analysis. This should, however, not be a reason for rushing the Measure phase or too easily accepting
that something is not measurable.
47
Data was incomplete, start date of the work was not always available
Data was unreliable, the time stamp of status 2 was sometimes earlier than that of status 1
Data was not used to manage the process
This meant that the kaizen team needed to be careful when drawing conclusions. It was also a trigger
for the operational team to improve their data registration.
Based on this data, the kaizen team was able to construct a VSM. The VSM provided insight into
where data was missing, particularly details about waiting times. These gaps were filled in using
a bespoke time registration sheet (in Excel) adapted to the specific situation. The sheet allowed
registration of NVA, NNVA and VA activities. This time registration lasted for two weeks to ensure
representative data. The VSM further uncovered that there was no standard process for each of the
three basic request types.
During the Measure phase, the following quick wins were identified.
48
Daily (manual) measurement was instituted straightaway. It was carried out by the team and
49
6 Analyze Phase
The Analyze phase is aimed at getting to the root cause of the problem (finding the key xs). From the
Define phase, we have a clear problem definition. This has been refined during the Measure phase
and data has been collected. The data will be processed to a certain extent during the Measure phase.
In the Analyze phase, the goal is to translate the data into information that will provide insight into
the key variables that have the greatest impact on the problem. By determining these key variables,
we will be able to provide input for the Improve phase, in which we will try to find the possible
actions that will reduce the negative impact of the variables.
In short, the Analyze phase is about identification, quantification, interrogation and prioritization of
the root causes of the problem we are investigating. We do this using a number of tools. There are
tools that help us make sense of the data we have uncovered during the Measure phase and there
are tools that help us to further decompose the problem into its constituent parts.
50
Step
Description
Step 1
Step 2
Collate the data into groups. In the case of incidents, we bundle them into timerelated groups, e.g. incidents solved within 1 day / 2 days / etc. or younger than 10
days, between 10 and 20 days, etc.
Step 3
Count the number of data points per group. Plot the groups onto a graph with on
the vertical axis the number of data points and on the horizontal axis the names of
the groups. The incident graph will have the number of incidents along the vertical
axis and the time intervals along the horizontal axis.
Step 4
Investigate the pattern that is depicted by the graph. Determine the cause of the
pattern. In the case of the incidents, we can easily see how long incidents have been
open and what the distribution is according to age.
The above diagram shows an IT example of a histogram. This one shows the number of open
51
Description
Step 1
Step 2
Count the frequency (cost or time) for each item. Add these amounts together to
create the grand total for all items. Calculate the percent of each item in relation
to the grand total, by taking the sum of the item, dividing it by the grand total and
multiplying by 100.
Step 3
List the causes in decreasing order of the measure of comparison, from most
frequent to least frequent. On top of the individual percentages, a cumulative
percent is calculated by adding the causes percent of the total to that of all the
other items that come before it in the ranking.
Step 4
List the items on the horizontal axis of a graph from highest to lowest. Label the left
vertical axis with the numbers (frequency, time or cost), then label the right vertical
axis with the cumulative percentages.
Step 5
Draw in the bars for each cause. Draw a line graph of the cumulative percentages.
The first point on the line graph should line up with the top of the first bar.
52
Step 6
Analyze the diagram by identifying those causes that appear to account for most
of the problem. Identify those causes that account for around 80 percent of the
effect. In most cases, 2 or 3 causes will generate 80% of the effect. There is usually
an inflection point where the graph levels off. If there appears to be no pattern (the
bars are essentially all of the same height), you may need to subdivide the data and
draw separate Pareto charts for each subgroup to see if a pattern emerges.
By comparing Pareto charts regarding a single problem made at intervals over a
period of time will indicate whether mitigation actions have had a positive effect on
the problem.
The above Pareto diagram shows the prevalence of particular causes of an incident, both absolute (in
numbers) and cumulative (in percentage).
6.1.3 Scatter diagram
A Scatter diagram is a graph that aims to demonstrate the relationship between two sets of
data. We try to understand whether there is a correlation between two sets of data and whether
this correlation is positive or negative. This type of diagram can be used to both interpolate and
extrapolate.
53
Description
Step 1
Select the two data sets that need to be plotted against one another. A simple
example is the investigation of the lead time (in days) of changes in relation to the
size (in hours) of the change. Not that it is not necessary for the units of the two
data sets to be the same.
Step 2
Create a graph whereby one of the data sets is plotted on the vertical axis and the
other on the horizontal axis.
Step 3
Determine whether there is a correlation between the data sets. This is done by
plotting a straight line known as the line of best fit or trend line through the data
points. The trend line is drawn by ensuring that the line is as close as possible to all
of the data points and has the same number of points above it as below it.
Step 4
The scatter diagram can be used in two ways. It can be used to find the value
of a particular data point within or outside the existing data set (interpolating
and extrapolating). The second analysis is the most important. This is to find the
correlation. The correlation is positive if the values increase together; it is negative
if one decreases as the other increases. Based on this analysis, we can determine
which variables have a positive or negative (or no) correlation, and we can take this
into account when determining the solutions during the Improve phase.
54
The above scatter diagram shows the relationship between the average time to repair of incidents
in days and the days of inventory within an IT organization. In effect, this is a chart depicting Littles
Law.
6.1.4 Flowchart
A flowchart is one of the simpler of the seven quality tools. The flowchart is the visual representation
of series of steps in a process, and helps to break down a complicated process into a simple series of
steps. This simplification ensures that the process becomes understandable to anyone.
A flowchart shows actions and decisions at points where variations occur in the process. These
decision points are always marked by a question that can be answered with yes or no. The basic
forms are blocks (actions) and diamonds (decisions). There are many other symbols used for drawing
flowcharts. A further elaboration is the use of so-called swimming lanes. These are horizontal or
vertical lines that separate the activities of different roles or groups responsible for completing a
particular task in the process.
In Value Stream Mapping, a very simple version of flowchart is used. The goal of the VSM is to
understand waste and time usage within the process. The flowchart discussed here is generally used
for a more detailed look at the process
55
Step
Description
Step 1
Select the process you wish to analyze. You may already have a SIPOC or VSM of
the process. Use this as a starting point.
Step 2
Step 3
Create blocks for the activities and use diamonds for recording the decision points.
Build the process step-by-step. Use an arrow between two symbols to denote the
flow of the process.
Step 4
The analysis of the flowchart centers around the logic of the steps. Drawing the
flow of steps can indicate where there are (unnecessary) feedback loops, parallel
activities that influence one another, i.e. should be sequential. The use of swimming
lanes indicates whether there are many transfer moments between roles. In
general, transfer moments cause delays within the process.
Below is an IT example of a Flowchart. In this case, the flowchart of the Problem Management
process.
56
Common cause variation: the variation due to random shifts in the Xs that are always present
in the process. As a result, the pattern shows variation with noise, the collective effect of
many minor influences. A process affected by common cause variation is called stable or in
57
control. It makes no sense to figure out what the causes are. The only way to improve the
performance is to redesign the (parts of the) process to reduce common cause variation. An
example of this is when a process, e.g. the ability to deliver a new piece of standard software
to the customer, performs consistently at a level that does not meet the requirement of the
customer. We would need to completely redesign the process to improve the performance.
Special cause variation: In these cases, the effect of variation can be assigned to a specific
cause which can usually be discovered. Special causes generate patterns in the data. They
provide signals about the problems in the process and how they can be resolved. You cannot
predict if and when the special cause variation will occur and what the impact will be.
Therefore, the process is unstable and unpredictable. Continuing the example above, if the
ability to deliver the software shows a spike in lead times, we can investigate and possibly
remove the reasons for the spike.
The control chart can thus be used to identify whether a process is under control (statistically)
and whether it suffers from special and/or common cause variation. It can also be used to detect
statistically significant trends in measurements, e.g. to identify whether improvements have had an
effect on performance.
Process is in control
Control charts are best suited to processes where regular measurements can be made. Typically this
is in processes that repeat within a reasonably short space of time. Within IT, we look at Incident,
58
Service Request and Standard Change processes. Control charts are also very suited to monitoring
technical processes like the ability to load a data warehouse.
Create a control chart using the following steps:
Step
Description
Step 1
Identify the objective of using the Control Chart. Typically this will be either to detect
defects or to monitor/investigate a process.
Step 2
Identify the actual measurement to be made, including what to measure, and where
in the process to measure it. Select the measurements based on their ability to
identify problems or defects.
Step 3
Identify the type of Control Charts to use. This will depend on the type of
measurement being made.
Step 4
Choose the measurements that will make up each plotted point on the Control
Chart. Measure more frequently when significant variation can occur over a short
period. Use consecutive measurements, rather than a random sample, as this will
result in less variation within the subgroup, with tighter, more sensitive control
limits.
Step 5
Step 6
Calculate mean and upper and lower control limits. Note that control limits are
usually straight lines.
Step 7
Draw the chart. This should include plotted points, with a line drawn between
successive points, horizontal lines for each of the central line, upper control limit and
lower control limit, and labeling and other information to uniquely identify the chart.
Step 8
Analyze the chart, looking for significant patterns and points, and find the cause
of any identified significant set of points. In the Improve phase, we will look for a
method of correcting the problem. To be clear, the Control Chart shows us when the
problem occurs, but not where.
59
Causes are usually grouped into major categories to identify these sources of variation. Depending on
the industry, there may be up to 7 categories. Within IT, we commonly use four categories: People,
Process, Technology and Policy
People: deals with all aspects to do with people, particularly behavior and attitude, but also
personnel and knowledge issues
Process: concerns all issues that relate to processes
Technology: any issues or causes related to the technical part of IT services should be posted
in this category
Policy: this category deals with all of the factors that determine the environment in which the
people, process and technology exist.
In practice, these categories are Collectively Exhaustive. The factors affecting a problem can,
however, often be placed in one or more categories i.e. the set of categories is not Mutually Exclusive.
An example: is the fact that people do not follow a process a people factor or a process factor? The
answer is that it does not matter as long as the factor is posted on the Ishikawa diagram and its
impact on the problem is analyzed accordingly.
Create an Ishikawa diagram using the following steps:
Step
Description
Step 1
An Ishikawa diagram should be made with by the Kaizen team. Use a whiteboard
and sticky notes to create the first version of the diagram.
Step 2
Draw a horizontal arrow pointing to the right. At the end of the arrow, write the
problem to be solved.
Step 3
Draw 4 diagonal arrows (2 from below, 2 from above) pointing towards the
horizontal arrow; each arrow should be labeled with one of the categories: People,
Process, Technology and Policy.
Step 4
The team collects as many causes as can be identified. The team can use the 5 Why
method to find and detail root causes. The value of the Ishikawa rises with the
quality and detail of the root causes.
Step 5
Use the other six basic tools to quantify the impact of each cause. This will create a
list of the causes with the greatest impact.
60
Description
Step 1
State the problem for which data is being collected. Identify and record the location
where and time when data will be collected.
Step 2
Create a table with the symptoms or occurrences to be observed and counted in the
left-hand column. Depending on how you wish to measure you may have a single
column in which to mark the number of occurrences or you may have a column per
day of the week.
Step 3
Collecting data may be done by the people actually doing the work or may be done
by an observer. The person collecting the data puts a mark in the recording column
for each time a particular symptom or occurrence takes place.
61
Step 4
Per registration period (usually a day), the data can be processed into a Pareto
chart for further analysis. Alternatively, a histogram can be used to understand the
relative amount of times a particular symptom is observed.
Make a table with two columns and 5 rows and write the question from the
problem statement at the top of the table
Step 2
Ask the question: why did this happen? Find the answer, supported by evidence,
and write the answer in the left-hand column of the top row.
Step 3
Repeat this question and answer cycle, four more times. List the answers in the lefthand column of the table.
Step 4
Determine a solution for each of the answers and record these in the right-hand
column.
62
Start by listing all the possible input factors (the Xs) as individual rows of the matrix.
The inputs should come from a previously completed VSM or Ishikawa diagram.
Step 2
List the multiple outputs (the Ys) of the process across the columns of the matrix.
There may be only a single physical output, however there will also be outputs such
as a performance level, a cost target or a maximum lead time.
Step 3
The key to the cause and effect matrix is building the relationships. Analyze and
quantify the relationships between each listed input and each output by placing a
relationship score (on a scale of 0 to 9) at the matrix intersection of each row and
column. Strong cause-effect relationships are scored as 9s; moderate cause-effect
relationships get 3s; weak relationships are 1s; and having no relationship means a
score of 0.
Step 4
For each matrix row-column intersection, ask yourself whether the associated input
affects the level of variation in the associated output. Then place the appropriate
score in the matrix cell.
Step 5
Summarize the results by calculating the weighted score for each row. For each row,
multiply the first matrix cell score by the first column weight; do this for the second
matrix cell, and so on. Finally, add up the weighted scores for the entire row. Place
this weighted row sum in the far right column of the C&E matrix.
Step 6
Apply Pareto analysis to the scores for each row. Those rows with high scores are
the ones that indicate important, high-leverage input factors. The factors with low
scores can be ignored.
List the key process steps in the first column. These may come from the highest
ranked items of a C&E (Cause and Effect) matrix or VSM made previously.
Step 2
In the second column, list the (potential) failures for each process step, i.e. state how
this process step or input could go wrong.
Step3
Per failure, describe what the effect would mean to the IT organization and the
customer, in the third column
63
Step 4
We then complete three columns with ranks from 1 to 10. Before you start, ensure
the team agrees on what each number in the scale means before you start. The
three columns are:
1. The severity of the effect -1 (not severe) to 10 (extremely severe)
2. The frequency of occurrence of the effect - 1 (almost never) to 10 (very
frequently)
3. Our ability to detect based on controls in place - 1 (predictable) to 10
(undetectable)
Step 5
Multiply the severity, occurrence, and detection numbers and record this value in
the RPN (risk priority number) column. This is the key number that will be used
to identify the principal causes to address first. An RPN of 1000 (10 x 10 x 10) is
obviously the most critical.
Step 6
Sort the causes by RPN number and identify most critical causes.
64
Time Trap: this is a process step that introduces a delay into the process. A classic example
is the need for an approval. This is not a capacity constraint. A time trap is based on a policy
decision (muri). The waiting times in the VSM must be analyzed carefully to determine the
reason for waiting times. Removing time traps will improve the efficiency of the process.
Capacity Constraints: this is a process step that does not have sufficient capacity to process
all of the work it must process in a particular timeframe. These steps are also referred to
as bottlenecks. Removing capacity constraints allows the process to deliver the value in
the quantities required to meet customer demand. Takt rate is an important metric for
understanding bottlenecks. Each process step for which the takt time is higher than the
takt time for the entire process is a bottleneck. Capacity constraints can cause variability
(mura) throughout the process. A capacity constraint may be caused by lack of resources or
knowledge.
Waste: Time traps and capacity constraints are important causes of waiting time. Obviously
we need to analyze the other types of waste (TIMWOOD) in the VSM to ensure that these are
not causing delays or quality issues (muda). We do this by analyzing each step in the process
and determining whether a particular type of waste is present in the step. This waste is
identified with a symbol on the VSM (See Lean IT Foundation)
6.4 Analysis in IT
Much of what has been dealt with in this chapter is not specific to IT. Does this mean that the analysis
within IT kaizen is the same as non-IT kaizen? From a tool perspective, maybe. However, within IT, we
find that there are specific challenges. Looking at People, Process and Technology, we find a number
of characteristic analyses.
Technology
There is a massive amount of data available within IT organizations regarding the behavior of the
technology. Technology delivers data that is very suitable for the creation of control charts and
histograms.
Having said this, Murphys Law dictates that the bit of technology that you need to investigate does
not have the right set of monitors in place to ensure that the technology can be researched. It is vital
that monitoring can be put in place quickly to understand the technological aspects of a problem.
The analyses most related to technology are control charts, Pareto charts and scatter diagrams.
Control charts help to understand the behavior of technology over time, Pareto charts help to
rank the importance of causes and scatter diagrams are used to understand whether there is a
relationship between symptoms.
Process
The analyses described above in relation to VSM are all used in relation to IT processes. It is
important, as already stated in the Measure phase, that people within IT organizations (especially
those involved in kaizen) know the difference between the IT units of work and the associated
processes. The dynamics of each unit of work must be understood so that the effects can be
understood.
People
People-related analysis is particularly related to the availability of skills and knowledge, and the usage
of time.
Skills and knowledge can be analyzed using a skills & knowledge matrix. The aim is, particularly, to
understand in which ways muri and mura are caused by choices made regarding people.
One of the IT-specific analyses is time-related. Where traditional Lean analyses look at the time
aspects of processes, within Lean IT, we also manage time on an organizational level. In essence, we
look at VA time versus NNVA and NVA time at an organizational level, i.e. per team, department or
the whole IT organization. This helps us to understand whether teams are faced with substantial
65
amounts of ad hoc work or whether they have a high diversity of units of work, leading to muda and
mura.
6.5 Analyze phase and A3Complete Analysis section of A3. The Analysis phase tends to be the phase
in which most time is spent. The team will spend much effort trying to bring together the various
symptoms, causes, effects and indications of how these may be mitigated.
There are two major pitfalls to avoid in the phase.
All the hard work that goes into the Analysis phase is in fact only a step to determining the correct
course of action. Most of the charts, graphs, matrices, etc. will not find their way onto the A3; only
the most significant. This does not mean you should throw away the analysis once made. All analyses
should be stored as a baseline for checking the effect of improvements made and for starting future
improvement initiatives.
Based on the insights gained in the Analysis phase and the relief that the solution of the problem
is getting close, the team may have a tendency to think that they have found the solution as they
uncover root causes. Jumping to conclusions will mean that other, possibly more significant, root
causes may be overlooked. This is where a kaizen lead proves their value, by keeping the team on
track.
Completing the Analysis part of the A3, ensures that the team must focus on what the essence is of
the analysis.
66
67
68
69
70
7 Improve Phase
At the end of the Analyze phase, the kaizen team basically has a list of the most important Xs, the
factors that cause the problem. The next goal is to identify improvement options. This is the aim of
the Improve phase.
The Improve phase is really the moment that we start thinking in solutions. Earlier in the cycle, we
may have come across a solution, especially if the problem turns out to be an obvious one. Assuming
that we are dealing with a complicated or complex problem, the Improve phase is the time to start
gathering solutions
In this section, we will look at ways of generating solution ideas, techniques for selecting and
prioritizing the solutions and testing solutions. All of these methods are useful but the one that
stands hand-and-shoulders above all of them is going to the Gemba.
Observing the Gemba and validating solutions at the Gemba are two of the most important ways to
ensure that the right improvements are implemented in the right way. Going to the Gemba facilitates
the generation of ideas for solutions, especially because ideas can be discussed with the people.
Gemba validation ensures that the implementation of improvements is carried out in a way that
garners support with the people doing the work.
71
72
commonly used.
7.2.1 Affinity mapping
Affinity mapping reduces the number of solutions by bundling solutions that are linked, similar or
overlapping. The benefit of this way of working is that by bundling we are able to identify the central
themes of a set of solutions. This in turn can provide further insight into the best solution. Affinity
mapping is all about sorting the large number of solutions into a manageable set of clusters.
As with brainwriting, the first part of affinity mapping is done in silence. Team members put sticky
notes with possible solutions together, if they believe the solutions should be clustered for whatever
reason. Then one by one the clusters are discussed, and a header describing the key theme is given to
each set of solutions.
The team then determines which solutions are most suitable from each of the clusters, or potentially
they may develop a different solution based on the insight gained from the bundling exercise.
7.2.2 Solution Matrix
The solution matrix is a simple tool made up of two axes: feasibility and impact. Feasibility represents
the ability of the IT organization to actually implement the solution. Feasibility is high if the costs,
effort and time involved are low. Impact is about judging the effect that the solution will have if it
were implemented. Impact is about the effect on the IT organization and its customers in financial,
performance and/or learning terms. In paragraph 4.4, we already dealt with a number of questions
that can help to determine feasibility and impact.
All of the solutions are then plotted by the team on to the solution matrix. The important part of the
process is that team members discuss the reasons why they believe a given solution should have a
73
particular impact and feasibility. This helps to understand how the team members see the adoption
of solutions within the organization.
Once all the solutions have been plotted, there will be a group that is clustered in the high
impact, high feasibility quadrant. These will be the solutions that need to be considered first for
implementation.
7.2.3 Multi-voting
Each of the above techniques helps to gain control over a large group of solutions. The solution matrix
helps to make a broad prioritization of the solutions, as well. Multi-voting focuses on prioritizing the
solutions. This is done by each team member allocating votes to a set of solutions.
Lets assume there are 30 solutions. Each team member is given 10 votes (a third of the total number
of solutions that can be voted for). After everyone has voted, the scores are tallied and the top 10
solutions are selected. It is possible to do a second round in which everyone gets 3 or 4 votes in order
to select the best solutions from the previously determined top 10. In this way, the kaizen team can
reduce the number of solutions to a manageable number.
7.2.4 Business case development
The last technique is one to use once the number of solutions has been reduced to less than a
handful. The aim is to build comparable business cases for each of the solutions. Each business case
will include both the costs and the returns for the same fixed period of time.
The solutions of a kaizen should give a positive return within a maximum of six months. Anything
more probably means that the solution is too big and costly; the team should look for smaller
solutions, possibly only tackling part of the problem. It is advisable, where possible, to implement part
of the complete solution to a problem at a fraction of the cost, rather than spend huge amounts of
resources to completely solve a problem in one go. The key consideration here is the acceptance of
the change: smaller changes are more easily accepted and assimilated into the way of working than
large changes.
Solution test
Obvious
Complicated
74
Complex
Chaos
Determine which actions to take and carry out a risk analysis for
each action
ITIL: the most widely accepted approach to IT Service Management. It describes best practices
within IT organizations covering the entire lifecycle of an IT service from concept to retirement.
It identifies and describes 26 processes, all of which contain solutions to common problems
within IT organizations. A more concise version, related to ISO/IEC 20000, is part 2 of this
standard.
Cobit: approaches IT from a strategic governance perspective. Cobit aims to link business
goals to IT objectives including the definition of metrics, and roles and responsibilities. Cobit
primarily provides answers to the governance issues of IT organizations
Scrum: is a best practice model for rapid application development. It describes the way to
ensure that software is developed rapidly and that the final product delivers value to the
customer. A number of the problems faced by IT organizations in delivering new software to
customers are solved in this best practice.
Prince2/PMI: are best practices that help to solve problems in the area of project
management and project governance.
On top of the best practices, IT also has good practices. These are frameworks of principles and tools
that help to improve the ability of IT to deliver and improve its services to customers. In this category,
we find methods like
Lean IT: On top of kaizen problem-solving to continually improve services, Lean IT applies
lean principles to IT. As such, it helps to focus IT processes on single piece flow and delivery of
value to customers. Lean IT describes the principles and good practices that can be applied to
complex and complicated problems. An example of a lean solution is 5S, which guides teams
through a series of steps to take action on how work is organized.
Agile: This is a set of principles, originating from the development of software, that can and
is applied to a variety of areas (e.g. Agile Project Management). The essence is about focusing
on individuals and interaction, working product (software), customer collaboration and
responding to change. Agile can be used problems in a similar way to Lean IT.
DevOps: A more recent addition to the list of methods, DevOps is a solution that derives
its effectiveness from the integration of a number of critical areas: process, organization,
performance, behavior & attitude and automation. This combination ensures that all aspects of
75
Determine the key actions to be taken per cause. Once actions have been completed, re-score the
occurrence and detection. In most cases we will not change the severity score unless the customer
decides this is not an important issue
76
77
78
8 Control Phase
The Control phase is the last step in de DMAIC
cycle. In this phase, the goal is to successfully
implement and, more importantly, maintain
the gains achieved, i.e. it is all about ensuring
the sustainability of the improvement. The
question that the Kaizen team is trying
to answer is, How can we guarantee the
improved performance? Ensuring that the
successes from the Improve phase will continue
means transferring the responsibilities for
performance to the process owner. One way to
look at the concept of establishing controls is
to ask yourself what elements, activities, roles,
policies, etc. you need to put in place to make
sure that, the next time you go to Gemba, the
improvement is still in place and preferably
better than you left it.
The Control phase has two main focus areas:
guarantee the increased performance and the
hand-off the improved process to its process
owner.
79
80
8.3 Monitoring
To detect any irregularities, we need to know
how the implemented changes are affecting
performance. To do this, we need monitoring.
Our approach for monitoring should focus on:
Metrics
Visual management
81
management.
As we saw in the Lean IT Foundation, Visual
Management is about effective communication
and real-time updates regarding the work.
Performance and workload is shared for
visibility and effective communication. Visual
management covers steering the work,
planning and reviewing progress and, of course,
managing improvements on a daily and weekly
basis. Including the Visual Management tools,
therefore make sense as control mechanisms.
Visual management helps to create consistent
and effective communication. It removes the
need for a series of one-to-one communication
that inherently has the risk of an inconsistent
message. The communication is effective
because the entire team hears the same
message at the same time. Lastly, frequent
feedback loops are established. This is based on
common knowledge of the chosen solutions to
problems.
Performance dialogues
Measurement is vital to understanding the
dynamics of our processes. Measurement
in itself does nothing, it is what we do with
the measurement that counts. Measurement
must lead to changes in behavior and we
must ensure that our behavior helps us to
achieve our goals. Once again, as we saw in
the Lean IT Foundation, the performance
dialogue is an instrument that helps us better
understand what good performance is and
how to collaborate in order to create value for
customers.
To engage in meaningful communication to
control our process, we setup performance
dialogues. Their aim is to ensure a structured
and objective discussion of performance. These
82
83
8.5 Closure
The final step in our kaizen is its closure and the hand-off from the kaizen team to the problem owner
(as we saw, this tends to be the kaizen sponsor). We consider the Kaizen closed when the problem
owner has accepted the following deliverables:
Improved performance, including the before and after data on metrics, to be used as a baseline for
further improvements
A completed Kaizen A3, including lessons learned (both success and failures) and recommendations
for further improvements
Documentation, including Standard Operating Procedures, policies and other documentation
produced during the kaizen such as Value Stream Maps and other tools
Operational training, including training on the Standard Operating Procedures and changes in
processes or policies
Transfer plan for sharing gained knowledge and new best practices
One of the powerful aspects of running kaizens is to transfer successful implementations across the
entire organization, through replication and standardization. Replication means taking the solution
from the team and applying it to the same type or a similar type of problem. Standardization
means taking the lessons learned from the team and applying those good ideas and solutions to
other problems. The kaizen team should consider standardization and replication opportunities to
significantly increase the impact on the business, to far exceed anticipated results.
The transfer of best practices demands great care and a well-devised implementation method.
Special care should be given to:
The people working in other processes. The background of the changes should be well
explained to them.
The changes made should be verified whether they work well enough in practice, and are
transferable to the new situation. This can be done by carrying out pilots of the improvement
actions
Any feedback, especially on complications at the start
Acceptance of the changes
Never assume that your proposed improvements work perfectly at once somewhere else. Usually
the improvements come across some complications. Fine-tuning the improvements may be necessary
84
and provide a great opportunity to involve the others. Ensure that any feedback given is captured
and used.
When the kaizen event is officially over, a team evaluation may be done to assess how each individual
did as a team member, management may devise rewards to recognize the work of the team, and the
team may share the gained knowledge on how to run a successful Kaizen with others.
In finalizing the A3, we focus on creating a consistent story based on the prior documentation and,
principally, describe the solution to the problem defined in the background section.
In the Plan / Improvement section, the chosen solution to the problem is described. It is accompanied
by a plan defining how the chosen solution will be implemented in the IT organization. The Follow-up
section is where we describe the activities that we have devised to ensure that the solution remains
embedded in the IT organization, or if necessary how the solution will be disseminated throughout
85
the IT organization.
86
move the responsibility from a project team back to the hierarchical line. The kaizen sponsor should
be pleased with the result, since a (part of the) problem has been solved.
Therefore, do not forget to celebrate the success with all involved.
87
88
9 Appendix 1: References
9.1 Lean Six Sigma Pocket Toolbook (chapters 1-4, 9)
Authors: Michael L. George et al
ISBN number 0-07-144119-0
Publisher: McGraw Hill
89
10 Appendix 2: Glossary
A3
A3 Proposal
A3 Status Report
Affinity Mapping
Agile
Andon
Analysis
Analyze (Phase)
Third phase of the DMAIC cycle in which the analysis of the problem is
done.
Annotated
Observation
Baseline
90
Benchmark
Capacity
The maximum amount of output that the process can deliver over a
period of time
Check sheet
The check sheet is a simple and highly effective tool for collecting
quality-related data in a structured way. It is a way to assess a process
and can function as input for other analyses when there is limited or no
numerical data to be analyzed.
Common cause
variation
Continuous
Improvement
Control Chart
Control (Phase)
The fifth and final phase of the DMAIC cycle. This phase ensures that
improvements are implemented and anchored into the way of working
91
Control Plan
Control Variable
Customer
The person or group of people who use your product or service OR the
person next in line in the value stream.
Customer Value
Cynefin (Model)
Daily Kaizen
Define (Phase)
The first phase of the DMAIC cycle, in which the problem to be solved is
defined and agreed
Dependent Variable
this is the output; in effect, this is the problem that is captured as part
of the Measure phase.
DevOps
DMAIC
Acronym for the five steps in problem solving with Kaizen, i.e.: Define,
Measure, Analyze, Improve and Control.
DMEDI
Acronym for the five steps in problem solving with Kaikaku, i.e.: Define,
Measure, Explore Decide and Implement
Fishbone diagram
92
Five Whys.
Flow
Flowchart
Gemba
The place where the work is done. Within a lean context, Gemba simply
refers to the location where value is created
93
Histogram
Hypothesis
A hypothesis is a statement that will start with the words I/We think/
believe that . The hypothesis is as yet not supported by any factual
basis. The hypothesis is based on peoples beliefs as a result of their
observations. These are by definition selective and biased, and very
much in need of testing through thorough analysis of the data and facts
that can be found.
Improve (Phase)
Fourth phase of the DMAIC cycle. The kaizen team thinks up possible
solutions to the problem based on the analysis done.
Improvement Board
Incident
Independent Variable
Ishikawa diagram
Jidoka
94
Kaikaku
Kaizen
Kaizen board
Kaizen charter
Kaizen Event
See DMAIC
Kaizen lead
This person manages the kaizen process on behalf of the sponsor and
the team
Kaizen Mindset
Kaizen sponsor
This person is the owner of the problem, and has a direct interest in
having the problem solved.
The people executing this role will do the required work. They must be
involved with the problem as it occurs on the work floor
Kakushin
Known Error
A Problem for which the root cause and a workaround have been
documented
Lead Tme
The time between the moment the customer submits their request to
the time they receive the requested item or service
95
Littles Law
Machine Time
Measure (Phase)
Second Phase of the DMAIC cycle. In this phase, facts and figures are
collected to understand the problem we are trying to resolve.
MECE
Muda
Multi-Voting
Mura
Muri
Pareto chart or
diagram
Bar chart showing the causes of problem or condition order from large
to small contribution. Effective tool to show what the big contributors
to the problem are.
PDCA Cycle
Performance Dialogue
Poka Yoke
Problem
Problem Board
96
Problem Management
Problem Statement
A statement that helps the team investigating the problem to focus its
attention. The problem statement may be in the form of a question or
in the form of a statement. The former is preferable because it is then
clear when you have found the answer to the question.
Process Cycle
Efficiency (PCE)
Pyramid Principle
Queue Time
Repeater
Root cause
Runner
Units of work that occur on a daily basis and tend to require up to one
hour of work for them to be completed. Within IT, we can say that
incidents, service requests, standard changes and operational activities
fall in this category.
97
SCAMPER
Scatter diagram
Shewhart Cycle
SIPOC
SMART
Solution Matrix
Special Cause
Variation
Standard Operating
Procedure (SOP)
Stranger
Summarize
98
Synthesis
System Thinking
Takt Time
Volume of customer demand per time period (takt time is the inverse of
this number)
Tally sheet
Throughput
Variable, Control
Variable, Dependent
Variable, Independent
99
Visual Management
Visualize
Gives the IT organization feedback on how the customer, the user of the
IT service, actually experiences the IT service
VSM
Work in Progress
The number of uncompleted units of work that are still in the process.
This number is directly related to the lead time (Littles Law)
100
101
102