Lean Six Sigma

Internal Assignment September - 2022

Semester - 4

1Q. List the various activities of DMAIC along with tools for
conducting business process improvements for a manufacturing
organization. Make a list of any 5 process audits that
can be used in a car manufacturing company and explain at least 2
such audits
Ans -
INTRODUCTION – Before we go forward, we need to understand that DMAIC
is the problem-solving approach that drives Lean Six Sigma. It’s a five-phase
method—Define, Measure, Analyse, Improve and Control—for improving
existing process problems with unknown causes. DMAIC is based on the
Scientific Method and it’s pronounced
“duh-may-ik.”

The focus of any process improvement effort is selecting the right project.
Good candidates for improvement will set you up for success with DMAIC.
Here are 4 key guidelines:
- Choose an obvious problem within an existing process
- Choose something that would make a difference but would not be
overly complex to address—Meaningful but Manageable
- Make sure there is potential to reduce lead time or defects while
resulting in cost savings or improved productivity
- Check if you can collect data about the selected process—you want to
achieve Measurable improvement
Once you’ve selected a good project, you and your improvement team can
apply DMAIC to dig into process issues and deliver quantifiable, sustainable
results.
As we go forward in the process, its essential to understand,
What Problem do we have to solve?
Define is the first phase of the Lean Six Sigma improvement process.

During this phase the project team drafts a Project Charter, plots a high-level
map of the process and clarifies the needs of the process customers. By
conducting Process Walks and talking to process participants they begin their
journey of building their process knowledge. Before moving on to the Measure
Phase, the team refines their project focus and ensures they’re aligned with
the goals of organizational leadership.

DEFINE - The Define phase is all about selecting high-impact opportunities for
improvement and understanding what it means to be successful .
During this phase, we need to identify as such below -
- Identify or validate the improvement opportunity
- Outline the scope of the project
- Develop the business process and critical customer requirements
- Document business opportunity
- Estimate project impact
- Identify stakeholders
- Form the team
- Create team charter
- Identify and map related business processes
Measure – During the Measure phase, existing processes are documented,
and a baseline is established. There are many ways to measure process
results, including processing time, the number of defects, the number of steps
in the process, distance travelled, and work units in progress. Now is the time
to choose the handful of metrics that will be useful for this improvement
opportunity
Critical activities at this point include:
- Developing the methodology by which data will be collected to evaluate
the success
- Identifying input, processes, and output indicators
- Gathering, plotting, and analysing current state data
- Completing failure modes and effects analysis

As seen above, in general Control Charts are used for better explanation as
they are helpful during the Measurement Phase.
Analyse - The goal of the Analyse phase is to find and validate the root
causes of business problems and ensure that improvement is focused on
causes rather than symptoms. To do this, we have to –
- Develop a problem statement
- Complete a root cause verification analysis
- Implement process control
- Conduct regression analysis
- Design measurable improvement experiments
- Develop a plan for improvement

Improve - Once you reach the Improvement phase, it is time to determine

precisely which steps will be taken and begin to roll out the changes that the
analysis has prescribed.
- The following activities are common:
- Determine expected solution benefits
- Develop revised process maps and plans
- Define a pilot solution and plan
- Communicate solutions to all stakeholders

If the initial three phases of the cycle have been thoughtfully and thoroughly
completed, the Improve phase is often the easiest. Because you understand
the problem, its impact, and root cause, you can proceed with confidence as
you implement positive change.

Control - The last stage's objective is to develop the monitoring processes

and procedures that will ensure long-term success.
- Verify reduction in failures due to the targeted root cause
- Determine if additional improvement is necessary to achieve the project
goal
- Identify and document replication and standardization opportunities
- Update Standard Work documentation
- Integrate lessons learned
While it may feel like the project is over after the improvement is implemented,
that's far from the case. Only if you take steps to maintain the progress will
you have the opportunity to build from there, creeping ever closer to
perfection.
Although it is most commonly associated with Six Sigma, DMAIC can be used
as a standalone tool for process improvement. Close adherence to the
process of DMAIC helps leaders and their teams ensure that improvement
projects are organized, effective, and repeatable.

SUMMARY - DMAIC is the most critical part of understanding Lean Six

Sigma. People who know how to use DMAIC can remove obstacles, take
friction out of improvement, and create positive change in warp speed. If you
are looking to increase quality, reduce defects, and control costs, then you
have to start with DMAIC.

1. Plan Audit and Define Audit Agenda -

Practitioners can set the audit agenda by answering the five W and one H:
Who, When, Where, What, Why and How. The agenda should include
the goal of the audit, the name of the person conducting the audit, the date it
will be conducted, the venue, what is to be audited and the reason why the
audit is to be conducted. The auditor should also be clear about the directions
to be followed during the audit. To cover every critical aspect, a checklist
could be used.

2. Conduct Audit and Measure Performance - The audit should be

conducted according to the scope and goal defined in the audit agenda. The
auditor will measure key aspects of the current process and collect relevant
data. Of course, every organization must follow its defined policy and the
regulatory norms of its country. Audits should also be conducted to review
processes and systems of an organization; by measuring their performance,
practitioners can determine their reliability.

3. Record Results and Analyse Findings - All problems found during audits
should be documented and categorized in order of their importance. Problems
can be categorized as critical, major or minor, based on the significance of
their break with organizational policy.
Audit reports provide a balanced overview of the current process, with details
about any under- or over-performing metrics. All problems observed during
the audit should be sent to the organization’s leadership, with critical and
major noncompliance issues flagged as early as possible.
4. Uncover Trends and Make Improvements -
Auditors should highlight process areas that show excellence and best
practices. They should also separate all critical and major problems from the
minor problems so the organization can focus improvement efforts
accordingly.
Problem importance can be determined after conducting a root cause
analysis of the process issues. Causes can be mapped on a Pareto chart,
which typically reveals that 20 percent of the problems create 80 percent of
the negative impact on a quality system. Through the use of the Pareto chart,
practitioners can identify areas of improvement and suggest necessary
changes.
5. Control System with Follow-up Audit
After defining process control limits, auditors can identify and implement
measures, such as control charts, to help prevent problems from occurring
again. Follow-up audits are required to measure actions taken to improve
processes and systems of organization.

AUDIT –
Approach – By conducting a literature review to examine the different
frameworks for applying the lean method and to extract case studies related to
the DMAIC approach which is missing on the selected articles, only one article
that addresses this possibility.
Finding – DMAIC has allowed a better structuring of the entire project,
choosing the right improvement solutions with the right choice of Lean tools
and several advantages that are not valid for other frameworks, this
implementation show a spectacular improvement in the production planning
the fluidity of the flow as well as an important financial fain for the company.
Implication – The project duration was not sufficient to apply other beneficial
lean tools as the study was limited only to a single line production time.
Value of Paper – This article Demonstrates the added value of the structured
DMAIC approach to lean manufacturing methodology and implementation.

Define - State of the situation and metrics before the intervention

The billing process under this investigation starts when the company initiates
the “contract” with the owner of the car who authorizes the Car dealer to do
the warranty service. It ends when the car dealer receives money for this
service by the Car brand.
- The contract is the legal and technical documentation that keeps track
of the process, and is part of evidence, should a Car Brand visit (and
audit) a car dealer. The steps for a warranty service, considering here
the Brand as the final client (which will pay for the service) are: to do the
service itself (that can include substituting spare parts or not), to bill the
service (computer wise) to the Brand, to receive the payment from the
Brand. Billing is made on a confidence basis between the authorized
repairer (car dealer) and the Brand. It takes place every day.

- At some point, every year or more, a technician of the Brand (an

Auditor) visits the car dealer to check for evidences. This moment is
called an Audit. For each service the Brand paid for before, Auditors
check for evidences in documents (like the owner’s signature or the
mechanic’s report, for example) and look for the substituted defective
parts that should be stored in an exclusive and closed store room.

- Some Brands have a checklist of up to thirty evidences to check. Other

brands are not so specific and formal. In the Audit, should any evidence
to be submitted fail, the car dealer has to return the money already
received for that service from the Brand. In this case study the company
billed an average of 720 000 Euros a year. So, the company is
interested in avoiding giving any money back (we will call money cuts in
the subsequent text).

- Normally, every month, in a global view of the accounting service, an

average of 60 000 Euros were billed to the Car Brands. Yet this amount
was not all received monthly. Preliminary measures taken of the last
year and a half showed that a total of 180 000 Euros of done/billed
services were missing. The car dealer had been compelled to make a
loan to face cash flow expenses. So, there are basically two problems
for the Car dealer: potential money cuts in an Audit and a growing and
significant negative cash flow.
Before the intervention, the process was controlled, by 5 financial metrics, on
a monthly basis:
1) How much money was in progress (measured upon labor and parts
recorded as already used in that service),
2) How much money was billed (total),
3) How much money was received (total),
4) How much money was lost in brand audit.
5) The difference between the total amount billed in a certain month with what
had been respectively received from this “billed” month.
A total losses/gains metric (although losses or gains were registered for each
service, what was checked was the total balance). These losses/gains
happened because of a disagreement of the Brand with the content of some
of the bills (the brand might have paid less or little more than what had been
billed). An example of this situation could be the car dealer billing a service for
100 Euros but the Brand paying only 95 Euros, due to the Brands’ medium
price of the spare part (different). On the contrary, because of a so called
“handling rate”, the car dealer could receive 100 Euros from a Brand, although
only 90 Euros were billed. The total balance of these losses/gains did not
alarm for losses since there was not a significant difference between total
losses and gains (although some bills had significant losses.

In terms of time, the Brands value the time elapsed between the starting of the
process with the client’s signature on the contract and the time when the
contracted service is billed to the Brand (computer wise).
- Although, as we found out, the right time varied from Brand to Brand, it
was always desirable to be under 15 days.
- We proposed 8 days as a Standard to have time compliance to do the
service. Although the Company recorded in its software dates of staring
of each service and of its billing, for services in progress (not billed yet),
it did not calculate in a systematic way the time elapsed between the
date of measurement and the date the contract started.
- Therefore, it was not possible to know if services were becoming out of
standard. It was a matter of introducing a new simple digital information
treatment (value of the difference between the starting of the service
and the date of measurement).
Measure - Although Six Sigma is generally identified with complex statistics
use, in our case, measurements of performance with the new metrics were
made through simple histograms of four classes and results exposed to the
people in the company.
- Each of these classes of the histogram goes progressively, from left to
right, to a bigger and bigger deviation from standard. The first class is
the standard. The second is the process at the limit of compliance.
- The third class is out of compliance, but shortly, it may be reworked.
The fourth class is most probably not re-workable, thus having to be
assumed as a definitive loss. Measurements included all the bills (not a
sample).
- We extracted data to an excel sheet and treated differences between
dates or money (billed and paid for). We measured how many bills were
waiting to be paid for more than 90 days. If that time overcame 60 days
(the proposed standard),
- It meant that the Brand was not satisfied with the information billed. We
also measured how many bills had already been paid for, but only the
ones with losses.
- If the brand paid much less than had been billed for, this was internal
evidence of a defect in billing. We proposed 10% loss as a standard to
have losses under control.
- Normally, in the Measure stage of the DMAIC methodology, statistic
training sessions are delivered to the people involved. As these
histograms were easy to understand, these training sessions were not
necessary.
- Classes out of control are the ones we used to study the root-causes.
As it is possible to see in, measurements show that all the new metrics
were far from meeting the standards

Analyse –
We walked the process through back and forth, endless times, in each
work station, evolving people in DMAIC, questioning them, using the 5
Whys technique18, showing the state of measurements in relation to
the established standards, observing and listening.
- We gathered past and current data, measured with the proposed
metrics and confronted with the proposed standards. The possible
causes and solutions were discussed with every one as people turned
themselves available.
- We used the Ishikawa fish-bone to resume root-causes: metrics,
method, people, machine, material and environment. Conclusions of the
analysis for noncompliance led us to identify bad method as one of the
 main causes. There was absence of control (bad method) of the
scheduling and of requested parts, absence of documentation control,
and absence of parts control (to be stored in warehouse).
- We observed that 34% services registered “in progress”, either awaited
a spare part, or, if the spare part had already arrived, the service had
not been scheduled with the client. In relation to the information to fill in
the bills, out of the 200 returned invoices to be reworked/corrected, we
found out that the information available to bill was not always correct or
sufficient (for example lack of a code or incorrect series number of the
car). No one controlled what was written in the documents, for example,
what had been diagnosed and what had been done. The reason that
could explain “bad information” was that the current “service order” form
which accompanied the service had an unclear design and very little
space for the mechanics to write down the diagnosis and explain the job
done.
- On the other hand, the billing clerk would usually talk with the
mechanics and get the essential information orally. In relation to the
substituted parts, to be in the storeroom, they had to be returned to the
parts’ balcony. Every time a new part for a warranty service was given
to a mechanic to substitute the defective one, the parts’ clerk made a
card with its identification and kept it besides the computer screen
among other papers and only when the substituted defective part would
be put there, he would search for the respective card and store the
substituted defective part.

- If an audit would occur, the greater probability was that people would
start looking everywhere for the parts to be evidenced only some days
before the parts audit’s date. It was assumed that they should be in the
store and easy to find.

- However, there was no control method of this aspect. Another root

cause was the lack of motivation of people. People were not motivated
to control or improve the warranties process or potential problems.
People performance was evaluated upon their punctuality and presence
at work. Some people, like the warranty clerk, were assessed with
productivity measures (value billed per month).

- People were therefore punctual, present and maybe productive but the
process had still a potential problem and significant money losses.
Another founded root cause was related to the bad use of the
machines: the mechanics did not fill in and/or print the results of the
diagnosis processed by a computerized system. The origin of the
situation lied in the lack of training of the mechanics in the use of these
 machines. In addition, some services were refused because they were
not correctly billed in the software. Training was needed for warranties
clerks and mechanics. Finally, as we could observe in most
workstations the environment was not the best: information and office
material were not always available or not available on time. Processes
could be more efficient if more organized.

Improve - The Results presented AFTER come from data extracted seven
months after the introduction of the improvements. The AFTER metrics
revealed services and bills that could not be recovered and had to be
assumed as losses. These were integrated in these results and constitute part
of the reason for some improvement. Yet significant operational improvements
made (and new metrics) allowed an easier way to work and control the
process. Since audits did occur during the IMPROVE step, it was possible to
measure results for money and time compliance to find a part, both in an
Audit.
- These results were due to several improvements made tackling all the
identified root causes for the problems. Instead of the information being
dispersed between all people or workstations, the use of a Google excel
sheet allowed the control of time compliance of the scheduling and of
the requested parts in a fluid manner.

- In relation to the storing of the substituted parts, the solution found

consisted in storing the substituted parts by a numerical order (the
number of the service order) as they would be asked for in an audit.
Every part was stored with a label corresponding to the number of the
service order. Parts were stored by blocks of large numbers. All pieces
of the services within these numbers were stored there and easy to find.
We first eliminated a very big number of parts that had been stored for
too long. Also, from then on, the cards (related to the new parts) were
put in a specific box on the balcony so that everyone could see them. At
the end of the day, the parts’ clerk could control which defective parts
had not been returned and why there were parts missing, if service was
still in progress or already finished.
- In relation to people, improvement consisted also in making processes
more visual to the mechanics. People started to be more motivated
because they were involved in the problem, knew, weekly, the initial
state and the improvements. This information was given in each work
station, by the Project manager. Training was given, with inner
resources, from colleagues and supervisors, to improve the use of
machines, including in printing diagnosis and interventions.
Control –
For all the metrics, and since compliance was expressed in percentage,
people could easily visualize improvements. For example, in one location, and
for one brand, time compliance improved from 24% to 64%,
(in 7 months), so still there was improvement to be made to achieve 100%.
Standards could, in the future, evolve and become tighter.

Conclusions -
Along the nine months of its implementation, the DMAIC approach took us to
DEFINE compliance for Car Brands (the paying customer), study current
metrics, improve them and set the standards to meet compliance,
- To MEASURE noncompliance, to ANALYSE root causes for non-
compliance, to IMPROVE the problems deriving from the root causes,
and then to CONTROL compliance.
- This case study made clear that the company’s current metrics only
attended financial budget concerns and were not able to establish
where and why money was being lost or missing.
- Moreover, the “to budget” financial metrics in use did not attend the Car
Brands values of an efficient billing service, nor helped having the cash
flow under control. This article showed how the DMAIC approach, used
consistently with all its stages, was powerful to define the problem and
to find the locations and the causes of the inefficiencies.
- The Measure stage turned out to be of greatest importance to
understand the reasons why the company was not meeting compliance
standards. We put in evidence how the proposed metrics, expressed in
percentages, allowed to seek for improvement of the billing process in a
continuous cycle, thus turning the cash flow under tighter control and
decreasing the loss of money, and in parallel accomplish Value for Car
Brands.
Three out of the five proposed new metrics dealt with time. Consequently,
the main direct benefits for the Car Dealer consisted in time gains, more
specifically in the cycle time confirming what the bibliographic review had
already mentioned for other services. Consequently, the company
benefitted from a tighter cash flow control. The other two metrics Money
compliance for each service received, Money compliance in an audit
allowed direct measure of losses in money.
2Q. Imagine yourself to be a six-sigma project leader in a hospital.
Create a fishbone diagram for the problems (any 5) being faced by a
hospital OPD and explain the steps involved in the FMEA with an
example for each step.
ANS –

INTRDUCITON - Very First we need to understand, what is FMEA which is a

short form for – Failure Mode and Effects Analysis. is a structured
way to identify and address potential problems, or failure and their
resulting effects on the system or process before an adverse event
occurs. In comparison, root cause analysis, is a structured way to
address problems after they occur. Here it gives Six Sigma project
teams a tool to help them predict the most likely process failures that
will impact a customer. FMEA also helps estimate the significance of
the impact

- Product development and operations managers can run a failure modes

and effects analysis (FMEA) to analyze potential failure risks within
systems, classifying them according to severity and likelihood, based on
past experience with similar products or processes. The object of FMEA
is to help design identified failures out of the system with the least cost
in terms of time and money.

- FMEA defines the term “failure mode” to identify defects or errors,

potential or actual, in a product design or process, with emphasis on
those affecting the customer or end user.

- A “failure effect” is the result of a failure mode on the product or system

function as perceived by the user. Failure effects can be described in
terms of what the end user may see or experience. The study of
consequences of identified failures is called effects analysis.

- FMEA prioritizes failures according to severity, frequency and

detectability. Severity describes the seriousness of failure
consequences. Frequency describes how often failures can occur.
Detectability refers to degree of difficulty in detecting failures.

- FMEA also involves documenting current knowledge about failure risks.

FMEA seeks to mitigate risk at all levels with resulting prioritized actions
that prevent failures or at least reduce their severity and/or probability of
 occurrence. It also defines and aids in selecting remedial activities that
mitigate the impact and consequences of failures. FMEA can be
employed from the earliest design and conceptual stages onward
through development and testing processes, into process control during
ongoing operations throughout the life of the product or system.

FISHBONE DIAGRAM - A fishbone diagram is a visualization tool for categorizing

the potential causes of a problem. This tool is used in order to identify a
problem's root causes. Typically used for root cause analysis, a fishbone
diagram combines the practice of brainstorming with a type of mind map
template.
A fishbone Diagram is useful in development and troubleshooting processes,
typically used to focus a conversation around a problem. After the group has
brainstormed all the possible causes for a problem, the facilitator helps the
group to rate the potential causes according to their level of importance and
diagram a hierarchy. The name comes from the diagram's design, which looks
much like a skeleton of a fish. Fishbone diagrams are typically worked right to
left, with each large "bone" of the fish branching out to include smaller bones,
each containing more detail .

Here We, need to understand how to create a FISHBONE Diagram –

Fishbone diagrams are typically made during a team meeting and drawn on a
flipchart or whiteboard. Once a problem that needs to be studied further is
identified, teams can take the following steps to create the diagram –
1. The head of the fish is created by listing the problem in a statement
format and drawing a box around it. A horizontal arrow is then drawn
across the page with an arrow pointing to the head. This acts as the
backbone of the fish.
2. Then at least four overarching "causes" are identified that might
contribute to the problem. Some generic categories to start with may
include methods, skills, equipment, people, materials, environment or
measurements. These causes are then drawn to branch off from the
spine with arrows, making the first bones of the fish.
3. For each overarching cause, team members should brainstorm any
supporting information that may contribute to it. This typically involves
some sort of questioning methods, such as the 5 ways or the 4P's
(Policies, Procedures, People and Plant) to keep the conversation
focused. These contributing factors are written down to branch off their
corresponding cause.
 4. This process of breaking down each cause is continued until the root
causes of the problem have been identified. The team then analyses
the diagram until an outcome and next steps are agreed upon.

SUMMARY –

STEPS INVOLVED IN FMEA –

• Step 1: Identify potential failures and effects
• Step 2: Determine severity
• Step 3: Gauge likelihood of occurrence
• Step 4: Failure detection
• Risk priority number (RPN)

Step 1: Identify potential failures and effects –

The first FMEA step is to analyse functional requirements and their effects to
identify all failure modes. Examples: warping, electrical short circuit, oxidation,
fracture. Failure modes in one component can induce them in others. List all
failure modes per function in technical terms, considering the ultimate effect(s)
of each failure mode and noting the failure effect(s)
Examples of failure effects include: overheating, noise, abnormal shutdown,
user injury.
Step 2: Determine severity -
Severity s the seriousness of failure consequences of failure effects. Usual
practice rates failure effect severity (S) on a scale of one to 10 where one is
lowest severity and 10 is highest. The following table shows typical FMEA
severity ratings and their meanings:
 Rating Meaning
1 No Effect, No danger
2 Very Minor – usually noticed only be discriminating or very
observant users
3 Minor – only Minor part of the system affected, Noticed by
average users.
4-6 Moderate – Most Users are inconvenienced and / or annoyed
7-8 High – Loss of primary function, users are dissatisfied
9-10 Very-High – Hazardous. Product becomes inoperative,
customers angered, Failure constitutes a safety hazard and
can cause injury or death.

Step 3: Gauge likelihood of occurrence - Examine cause(s) of each failure

mode and how often failure occurs. Look at similar processes or products and
their documented failure modes. All potential failure causes should be
identified and documented in technical terms. Failure causes are often
indicative of weaknesses in the design. Examples of causes include: incorrect
algorithm, insufficient or excess voltage, operating environment too hot, cold,
humid, etc. Failure modes are assigned an occurrence ranking (O), again from
one to 10, as shown in the following table
Rating Meaning
1 No document failures on similar product/services
2-3 Low – relatively few failures
4-6 Moderate – Some occasional failures
7-8 High – Repeated Failures
9-10 Very High – Failure is almost certain
9-10 Very-High – Hazardous. Product becomes inoperative,
customers angered, Failure constitutes a safety hazard and
can cause injury or death.

Step 4: Failure detection –

After remedial actions are determined, they should be tested for efficacy and
efficiency. Also, the design should be verified and inspections procedures
specified.
1. Engineers inspect current system controls that prevent failure mode
occurrence, or detect failures before they impact the user/customer.
2. Identify techniques used with similar products/systems to detect failures.
These steps enable engineers to determine the likelihood of identifying or
detecting failures. Then, each combination from steps one and two is
assigned a detection value (D), which indicates how likely it is that failures will
be detected, and ranks the ability of identified actions to remedy or remove
defects or detect failures. The higher the value of D, the more likely the failure
will not be detected

Rating Meaning
1 Fault is certain to be caught by testing
2 Fault almost certain to be caught by testing
3 High Probability that tests will catch fault
4-6 Moderate Probability that tests will catch fault
7–8 Low probability that tests will catch fault
9-10 Fault will be passes undetected to user/Customer

Risk priority number (RPN) After the foregoing basic steps, risk assessors
calculate Risk Priority Numbers (RPNs). These influence the choice of action
against failure modes. RPN is calculated from the values of S, O and D as
follows:
RPS = S* O*D

RPN should be calculated for the entire design and/or process and
documented in the FMEA. Results should reveal the most problematic areas,
and the highest RPNs should get highest priority for corrective measures.
These measures can include a variety of actions: new inspections, tests or
procedures, design changes, different components, added redundancy,
modified limits, etc. Goals of corrective measures include, in order of
desirability:
• Eliminate failure modes (some are more preventable than others) • Minimize
the severity of failure modes
• Reduce the occurrence of failure modes
• Improve detection of failure modes
When corrective measures are implemented, RPN is calculated again and the
results documented in the FMEA.
FISH BONE DIAGRAM –
Dr.Kaoru Ishikawa, a Japanese quality control expert, is credited with
inventing the fishbone diagram to help employees avoid solutions that merely
address the symptoms of a much larger problem. Fishbone diagrams are
considered one of seven basic quality tools and are used in the "analyse"
phase of Six Sigma's DMAIC (define, measure, analyse, improve, control)
approach to problem-solving.
The following graphic is an example of a fishbone diagram with the problem
"Website went down." Two of the overarching causes have been identified as
"Unable to connect to server" and "DNS lookup problem," with further
contributing factors branching off.

When to use a fishbone diagram -

A few reasons a team might want to consider using a fishbone diagram are:
- To identify the possible causes of a problem.
- To help develop a product that addresses issues within current market
offerings.
- To reveal bottlenecks or areas of weakness in a business process.
- To avoid reoccurring issues or employee burnout.To ensure that any
corrective actions put into place will resolve the issue
SIX – Sigma- Six Sigma is a method that provides organizations tools to
improve the capability of their business processes. This increase in
performance and decrease in process variation helps lead to defect reduction
and improvement in profits, employee morale, and quality of products or
services
- It's called Six Sigma because the term sigma refers to one standard
deviation in a data set. The idea is that six such deviations should occur
before the process results in a defect. When a process achieves Six
Sigma, it reaches a point where only 3.4 errors per one million process
events result in a defect

EXAMPLE for Fishbone Diagram –

Operations Outage - A Production line goes down for three shifts due to a
failed machine. Root cause analysis determines that the machine had multiple
design issues. Such Problems weren’t detected or mitigated maintenance
processes. When the machine needed to be replaced, several issues,
complicated the process making the outage longer.

Service Outage –
A software service experienced an outage after a bug that was missed in
testing was launched to Production. The procedures required to fix the
problem did not go smoothly as backout procedures failed and developers had
trouble accessing environment due to issues with security keys.
Quality Failure - Customer finds a problem with a product that had passed
quality control. A quality assurance investigation reveals that a machine error
caused the defect. Quality tests and processes failed to detect Problems.

Security Incident –
A Worker loses a laptop filled with company data at a bar. The incident
investigation discovers a lack of policy and procedure to prevent such
problems. Root cause analysis also reveals technical shortcomings such as
weak Encryption. A poor password policy and lack of audit trail for data.
CONCLUSION - A fishbone Diagram is Visualization of the causes of a
problem, As the term suggests the diagram looks like a fishbone with each
bone representing a category of root cause. This discourages the common
tendency to assign a single root cause to problems that may have deeper
causes such as human error that could have been prevented with controls.
The following illustrative examples of a fishbone diagram.
Equally the FMEA to evaluate processes for possible failures and to prevent
them by correcting the processes proactively rather than reacting to adverse
events after failures have occurred. This emphasis on prevention may reduce
risk of harm to both patients and staff. FMEA is particularly useful in
evaluating a new process prior to implementation and in assessing the impact
of a proposed change to an existing process.
3.a Mention all the points to be considered for constructing the SIPOC
diagram with an example from service industry.

ANS -

INTRODUTION - A SIPOC (suppliers, inputs, process, outputs, customers)

diagram is a visual tool for documenting a business process from beginning to
end prior to implementation. SIPOC (pronounced sigh-pock) diagrams are
also referred to as high level process maps because they do not contain much
detail.
The term SIPOC requirements make reference to the constraints,
measurements and customer requirements of a SIPOC model.

- SIPOC analysis is widely used in process design and improvement

initiatives (such as Six Sigma) to identify important elements of a
process, and to defines the scope of a project when it is too early for a
detailed process mapping.

- A SIPOC diagram is a tool used by a team to identify all relevant

elements of a process improvement project before work begins. It helps
define a complex project that may not be well scoped, and is typically
employed at the Measure phase of the Six Sigma DMAIC (Define,
Measure, Analyse, Improve, Control) methodology. It is similar and
related to process mapping and ‘in/out of scope’ tools, but provides
additional detail.

- A SIPOC diagram is a tool used by a team to identify all relevant

elements of a process improvement project before work begins. It helps
define a complex project that may not be well scoped, and is typically
employed at the Measure phase of the Six Sigma DMAIC methodology.

SUMMARY –
SIPOC Diagrams are very easy to complete. Here are the steps as follow’s –
1- Create an are that will allow the team to post additions to the SIPOC
diagram. This could be a transparency made of the provided template,
flip charts with headings.
2- Begin with the process. Map it in four to five high level steps
3- Identify the outputs of this process.
4- Identify the customers that will receive the outposts of this process.
5- Identify the inputs required for the process to function properly.
 6- Identify the suppliers of the inputs that are required by the process.
7- Optional – Identify the Preliminary requirements of the customers. This
will be verified during a later step of the Sox sigma measurement phase
8- Discuss with project sponsor, and other involved stakeholders for
verification.
The SIPOC diagram is an important visual tool that is easy to create. It helps
to define who supplies the input to the process, what raw materials are placed
in the inputs, the customer requirements of the process and more. First, you
have to choose a business process that will benefit from creating a SIPOC.
Then to create a SIPOC diagram, follow these steps

1- Identify Suppliers - Who are the suppliers that will provide you with the
materials you need for your inputs? They should be listed here. There
might be a different supplier for each input. If that’s the case, list them
all. By supplier, we mean anyone who has a direct impact on the
outputs.
2- Identify Inputs - Now you want to identify the raw materials and other
resources needed for your business process to work. You don’t have to
list every single one, only those that are important, overarching inputs.
3- Outline the Process – This is an overview of the business process.
only list the four or five high- level steps that consist of actions and
subjects. This is like the starting and ending points in the process or it
could be a simple flowchart.

4- Define Outputs - Use nouns to describe the outputs. These can be

materials, products, services or information.

Example For SIPOC –

- The creation of a healthy smoothie. To begin, create a table with five
columns for the five words that make up the SIPOC acronym. First,
there’s the supplier, who is tasked with creating a smoothie for a
customer. To do so there must be a smoothie preparer, a store owner
where that person works, a kitchen manager and an order taker.

- That leads to the inputs, which are first the request, or order, of the
smoothie. Then there’s the recipe to make it, the receipt to acknowledge
the sale, the countertop to interact with the customer and other
equipment. That includes a blender and probably a timer of some sort.
And, of course, whatever ingredients are required to create the
smoothie.
 - Now we’re getting to the process. It starts by receiving and preparing
the order and ingredients, which must be clean, cut and sorted. Then
blend those ingredients as required by the recipe. You’ll probably want
to test the order before you notify the customer that the order is
complete.

- The output of this process is the completed purchase, the order, and
hopefully, a delicious smoothie and a happy customer. You provide the
receipt, and they might give you a tip for good service. This finally leads
us to the customer, who entered your establishment with a need, in this
case, hunger. But there’s also the smoothie preparer and even the store
owner, who is a customer when out buying the ingredients

CONCLUSION - SIPOC is a great tool to diagram the inputs and outputs in

your business process. But once everyone is on the same page you’re going
to need to plan, execute and monitor that project. Project Manager is award-
winning work and project management software that has multiple project
views that allow everyone to work how they want, no matter where they are,
how they work or even if they’re in a different department.
Organize all the tasks that you need to create the product or service your
customers want with our online Gantt charts. They put your project on a visual
timeline so you can see the whole schedule in one place, link dependencies
and set milestones. You can also filter for the critical path and create a
baseline to measure actual progress against your plan to keep on track.

3 b. Mention any 5 points of difference between verification and

validation with examples for each.

ANS-
Introduction –
Verification Vs Validation
Verification - The evaluation of the product or a system or a service to check
if it is compliant as per the design requirements / regulations / specifications /
conditions. It confirms that the product / system / service has been developed
correctly.
- That ensures that the model is producing or predicting the right
outcomes based on the relationships of input variables
and output variables that are built into the model. The verification
process does not rely on, or compare to, the real-world process. Its
purpose is to confirm that the model is doing exactly what the modeler
“thinks” it should do when it was created. Basically, if it is desirable for
the model to return a rounded-up integer value of X1 divided by X2,
does the model always provide the integer result of 1 when X1 = 3
and X2 = 4 is entered? Or does it return a result of 0.75?

Validation - The evaluation of a product or a system or a service to check that

it meets the customer requirements or specifications. It confirms that the
product / system / service will fulfil the customer requirements.
- That the model is representing the real world as much as possible. The
validation process helps a modeler be certain the correct model is built.
The validation process relies heavily on the data collected from the real
world, and the perception and understanding of the process of the
modeler. The validation process ensures that the model is doing what
the real process is doing.
Example –
Distribution Centre - Why are both verification and validation of a model
needed? Consider another example of a process creating a simulation model
for a distribution centre consisting of four product-sorting machines. In each
step, a machine sorts product to its destinations.
- A LSS team collects data on cycle time and processing step at each
machine. After that, the team builds a model using simulation software.
Based on the data that was collected and statistically analysed, the
team found that the processing time of Machine A is normally
distributed with a mean of 5 minutes and a standard deviation of 1
minute, Machine B has a constant processing time of 1.5 minutes and
Machine C has a constant processing time of ten minutes. Products B
and C arrive with equal distribution at Machine A every 5 minutes.
- After the model was created, the team ran the model until reaching a
steady state and found that there is an excessive queue in front of
Machine B, but none in front of Machine C. Based on the assumption of
the processing time at these three machines, and the arrival profile of
products B and C, the team realizes that there could be an error in the
model code or parameters. The team ensures that all parameters have
been entered correctly, including breaks and lunch times, processing
time and distribution types, staffing and time available in a day
-
- Eventually, the team found a mistake in the processing time parameter
at Machine B – 15 minutes was entered instead of 1.5 minutes. This
error-checking process is a verification process. By ensuring that the
model is producing what it should be producing, the modeler verifies
that the model is error free. Based on the assumption that Machine B
sorts products faster than Machine A, there should not be any physical
queue in front of it. Without a proper verification, this model would have
led to misguided results.

- Consider the same distribution centre and a corrected model. The team
decides to use the model to predict the behaviour of the process during
a peak demand period. What is the best way to validate the model and
ensure the model acts as close to the real process as possible? For an
existing process for which the data is available, the process is simple.
The team may use data from the previous peak. They can use the
known data as input variables and compare the results of output
variables to the last known data collected to adjust the model. This way
the team can ensure that the model acts similarly to the real-world
process. Validating the model is not as easy when the process did not
previously exist or data is not available. The team can only assume the
 most likely behaviour of the process based on the relationships between
input and output variables.

CONCLUSION - The validation process should be performed after the

verification process has been completed. The validation process normally
involves real data, which can consume more of a team’s resources than the
verification process. The table below suggests some validation methods for
each modelling scenario.

There is no one verification or validation process that fit all scenarios. A

modeler should be aware of the available methods. Both verification and
validation processes should be completed at the earliest stage in the project –
and as thoroughly as possible. The key question for verification is whether the
model was built correctly. After verification, the model should be error free.
The key question for validation, on the other hand, is whether the correct
model was built. After validation, it should be clear that the model acts similar
to the real-world process so a team can be confident in using it to predict the
behaviours of a process.