Introduction to Industrial Engineering

By Jane M. Fraser

Chapter 5

The IE Approach

Return to the Table of Contents.


How does an IE create a process to reliably produce a product or service with specified requirements? While the definition of industrial engineering says “the design or improvement” of a system, most IEs are involved mostly in improvement. The IE approach is to continually improve the system.

Collins and Porras found a focus on continuous improvement in the companies they studied:

Visionary companies focus primarily on beating themselves. Success and beating competitors comes to the visionary companies not so much as the end goal, but as a residual result of relentlessly asking the question 'How can we improve ourselves to do better tomorrow than we did today?' And they have asked this question day in and day out – as a disciplined way of life – in some cases for over 150 years. No matter how much they achieve – no matter how far in front of their competitors they pull – they never think they've done 'good enough.' (page 10)

Improving the whole system at once is hard, so the IE focuses on a particular process in the production system. Harrington (page 9) provides a good definition of process:

Any activity or group of activites that takes an input, adds value to it, and provides an output to an internal or external customer.

Plan-Do-Check-Act (PDCA) and Define-Measure-Analyze-Improve-Control (DMAIC) are two acronyms indicating the steps an IE does to improve a process in a production system.


PDCA stands for Plan, Do, Check, and Act. The steps were developed by Shewhart and popularized by Deming; they are sometimes called the Shewhart Cycle.

When you are done with PDCA, you do it again. Or, in other words, you are never done because you must practice continuous quality improvements.

This web page has several good examples of PDCA, each with several cycles of PDCA.

This web page has a good summary of the steps.


DMAIC stands for Define, Measure, Analyze, Improve, and Control.

Read this DMAIC example titled Process Redesign to Reduce Cycle Time, by D. Bandyopadhyay

PCDA, DMAIC, and other versions all have in common these important features:

PDCA and DMAIC are very similar, but have some differences. Since it is sometimes called the Shewhart Cycle, PDCA emphasizes more the need to repeat the steps, while DMAIC adds the Control step lacking in PDCA.

In some ways, PDCA and DMAIC are organized common sense, but the fact that the steps enforce organization is good. Others have developed similar steps. For example, Juran's "Universal Sequence for Breakthrough" (page 16-2) is similar to PDCA and DMAIC but is more explicit about how a quality improvement project must fit into an organization:

The tools for PDCA and DMAIC

Both PDCA and DMAIC use these tools:

I have listed the tools in roughly the order in which an IE is likely to use them. I’ll give an example and explain each now. I have given each of you a copy of The Memory Jogger II, which is a good reference on these tools and it will fit in your pocket.

Teams. Continuous improvement of a process requires the involvement of everyone who works on that process. A team is usually created to focus on a particular problem or a particular process, but may include people who work in the processes that provide input or receive the output from the process being studied. For example, a team to improve the process of moving patients from the Emergency Department to a hospital room should include people who move the patients, but should also include people who work in the Emergency Department as well as people who work in the hospital. Team members may need training in some of the tools described below and support from staff people for data analysis.

Documentation. According to Robitaille (page 65):

“If the documents aren’t correct, the system will always have problems.”

One of the first steps of a team in analyzing a problem should be to determine whether a process is actually being implemented the way the documentation says it should be. Differences may require adjusting the process or the documentation. The team should also document its work, including data collection and analysis, and conclusions reached. Finally, when the team completes its work, it should be sure that the recommended changes are reflected in the documentation of the process, materials used for training new workers, and so forth. Documents form the long lasting memory for the organization.

Process flow diagram or flowchart. A flowchart is a visual representation of the steps involved in the process being studied. If a product is being manufactured, the flowchart shows the operations done by differnent workers on that product. If a service is being produced, the flowchart shows the steps performed by different workers for that customer. Usually a flowchart should follow the product or the customer. One acronym to help you include all the relevant parts of each process on a flowchart is SIPOC: for each process, make sure you include the suppliers, the inputs, the process, the outputs, and the customers. This web page has a flow chart for the Student Judicial Process at Drexel University. This web page has a flow chart for the manufacture of Styrene Monomer.

This flow chart, from Parkview Hospital, shows the flow of patients from the Emergency Department to the Hospital. The chart was used to study the components of the time to transfer patients, so the chart also includes information about the average time patients spend at each step.

This web page has a flow chart for courses in the BSIE program that was created using the program Visio. Employers often expect that IEs will know how to use Visio. Spend about 20 to 30 minutes using this introduction to learn how to use Visio. More training courses for Visio are here. You must be using a computer with Visio if you want to use the Practice in Visio portions, but you can still learn a lot if you don't have Visio on your computer. Each training course has a Quick Reference Card that you might want to print. Another flow charting program is iGrafx.

Check sheet. An important type of documentation is to routinely record all exceptions and problems. Each instance of a problem may seem to be isolated, but analysis of such data may turn up problems that should be studied and fixed. A check sheet is a simple chart allowing workers to put a check mark next to the type of problem that has occurred, or to record by hand a problem that does not fit into the types listed. An example of a checksheet used to record the reason for telephone interruptions is shown here. The Quality Training Portal has another example at the web page Tally Sheet.

Histogram. Categorical data such as data recorded in a check sheet can be displayed visually in a histogram. The relative number of different types of problems is easier to see in such a visual display. The following histogram shows the reasons why a patient was not able to moved from the Emergency Department to a hospital bed. [use Parkview data] The Quality Training Portal has another example at the web page Histograms.

Pareto chart. A Pareto chart is a special type of histogram in which the categories are listed from most frequent to less frequent. The following Pareto chart shows the data from the previous histogram. The Quality Training Portal has another example at the web page Pareto Analysis.

The following Pareto chart from Parkview Hospital shows the causes for a delay in moving a patient from the Emergency Department to a hospital bed.

Putting the items in order by frequency means that the biggest cause is listed first; that cause is usually the one that should be focused on first. If you can fix the biggest causes, then you will have eliminated a large proportion of the defects.

The Pareto principle (named after economist Vilfredo Pareto, but generalized by J. M. Juran) is also sometimes called the 80-20 principle. Juran wrote (page 2-16):

Managers are well aware that the numerous situations and problems they face are unequal in importance. In marketing, 20% of the customers (the 'key' customers) account for over 80% of the sales. In purchasing, a few percent of the purchase orders account for the bulk of the dollars of purchase. In personnel relations, a few percent of the employees account for most of the absenteeism. in inventory control, a few percent of the catalog items account for most of the dollar inventory. In cost analysis, roughly 20% of the parts contain 80% of the factory costs; the basic function of a product accounts for 80% of the cost, while the secondary functions account for only 20% of the cost. In quality control, the bulk of the field failures, downtime, shop scrap, rework, sorting, and other quality costs are traceable to a vital few field failure modes, shop defects, products, components, proceses, vendors, designs, etc.

The Parkview chart had 9 causes; 20% of 9 is 1.8 or about 2. The largest 2 causes (Bed and Report) account for only 56.7% of the problems, so we can see that the Pareto rule doesn't always hold. It is, however, often a useful guideline.

Juran points out that quality improvement projects should be selected by the use of Pareto analysis, that is, the IE should focus first on the most frequent errors.

"It is these projects which contain the bulk of the opportunity for improvement in failure rates, quality costs, downtime, process yields, etc." (Juran, page 2-17)

Defect concentration chart. Sometimes defects or other problems can be recorded or displayed according to location. For example, breakdowns of machines can be displayed on a map of a factory to determine if the breakdowns are occurring in a particular area. Defects in welds on a product can be displayed on a diagram of the product to see if the weld defects are concentrated in a particular part of the product. The Quality Training Portal has an example at the web page Concentration Diagrams. As I'll discuss in Chapter 10, visual displays of data often help people reach conclusions more quickly.

Brainstorming and Nominal Group Technique. Usually everyone on the team has ideas about why the problem is occurring. However, a good process should be used to develop a list of possible causes to avoid the team from focusing too early on just a few causes. Team brainstorming usually works best with these steps:

  1. Clear statement of the problem or issue for which ideas are being generated. For example, generate possible causes why customers sometimes receive shipments that are missing items.
  2. Silent generation of ideas by each individual, writing on paper.
  3. Round robin collection of ideas, recorded on a board or flip chart visible to all. Each person gives one idea during each round, and can “pass” during any round. During this step, ideas are not evaluated. The more ideas and the more different the ideas, the better. After a round in which all pass, some time should be allowed for all to think a bit more. The facilitator should be sure to encourage everyone to volunteer all the items generated during the silent generation. Sometimes people are hesitant to volunteer ideas that differ from what others have said, but one of the values of working in a team is the generation of different types of ideas.
  4. Clarification and combination of ideas. Often some ideas are similar in concept, but different in wording. The team works together to clarify and combine ideas. Ideas should not be overly combined; if the person who volunteered an idea wants to keep an idea separate, the team should usually defer to that person.
  5. Prioritization among the ideas. This step is not always appropriate. If the team is brainstorming causes for a problem, data, not voting, should usually be used to determine which causes are more important. If the team is brainstorming ideas for next steps for the improvement, prioritization is needed. If there are 10 or few items, each team member can rank order the items (from 10 for the highest priority to 1 for the lowest) and the sum is used to prioritize. If there are more items, voting can be used to first reduce the list. For example, each person is given a number of votes equal to half the number of items. Each person allocates votes; votes can be allocated all to one item (expressing a strong preference), or allocated among items. Sometimes colored dots or colored pens are used, so the team’s preferences are visible and can be discussed.

Cause and effect diagram or fishbone diagram. Often causes can be grouped into overall categories such as people, equipment, methods, and materials. The figure below includes those labels on what are called the major bones of the fishbone, with more specific ideas categorized under those labels. Smaller lines can be included as needed.

The five whys and root cause analysis. According to Robitaille (page 1).

“Root cause analysis (RCA) is an in-depth investigation into the cause or causes of an identified problem, a customer complaint, a nonconformance, the nonfulfillment of a requirement, or an undesirable condition."

The goals are

  1. to determine why the situation occurred, tracing back in time through previous steps in the process, and
  2. to prevent the situation from occurring again.

The goal is not to blame a person, but to fix the system. One approach is to continue to ask "why" at least five times, as we did in chapter 2 in the example about an incorrect shipping label. That situation could be solved superficially by telling the workers “don’t put the wrong shipping label on a customer’s shipment,” and that solution may last an hour, a day, or a week, but unless the reasons for the wrong labels are identified and fixed, wrong labels will happen again.

Box plots. Box plots are useful for the visual display of variability in data. For example, data were collected on the number of damaged shipments for first and second shift for 3 weeks (15 data points for each shift).

First shift Second shift
8 6
6 5
5 5
8 5
6 4
7 5
3 6
5 6
5 3
3 6
7 2
3 6
6 8
2 4
9 4

Comparing the average number of defects, we might conclude that because the first shift has a higher average number of damaged packages (5.53 versus 5.00 for the second shift), the workers on that shift are doing something to cause more damage; the analyst might focus on determining what is different between how those shift works. However, that conclusion would not be correct, as shown by the diagram below, with a box plot for each shift.

The top edge of each box is the 75th percentile of the data for that shift (75% of the time the number of defects for that shift was below that number), the middle is the median (50% of the time the number of defects for that shift was below that number), and the bottom is the 25th percentile (25% of the time the number of defects for that shift was below that number). The lines extend out to the largest and smallest value for each shift. This box plot shows that while the medians differ (as did the averages), the data have considerable overlap and the difference in shifts probably do not account for the damages. Thus, the analyst would know that defects are probably being caused by some reason that occurs on both shifts. This plot used only two box plots for the two shifts, but more box plots can be compared in one chart.

Scatter diagram. A scatter diagram (or X-Y plot) shows how one variable affects another. Perhaps heavier boxes are receiving more damage. The plot below shows the damage rate (that is the fraction of packages that are damaged) as a function of weight (to the nearest half pound). This plot gives some support to the argument that the damage is related to weight.

Regression analysis. A scatter diagram shows the effect of only one variable (weight, in our example) on the variable we are studying (damage rate, in our example). More sophisticated analysis allows for more independent or explanatory variables. With more variables, plots cannot be used, but the mathematical techniques of regression analysis can indicate which variables are most important in explaining the variation in the dependent variable, that is, the variable being studied.

Design of experiments and analysis of variance. After careful analysis of data, the team may have some good ideas about why the problem is occurring and may have some good ideas about how to fix the problem. A carefully designed experiment (for example, mailing some test packages with different padding, by different carriers, over different distances) will help test these ideas. The analysis of variance (ANOVA) is a mathematical technique (like regression analysis) for determining which variables have the most effect on the variable we are studying.

Control charts. Key measurements of a process should be monitored to make sure that the process is functioning within the required limits. Data on damaged packages should be gathered and plotted to be sure that the damage rate is staying below an unacceptable rate. The design and use of control charts requires mathematical analysis to distinguish natural variation in the system from clear indications that the process has changed. I'll show you more about control charts in Chapter 10.