Return to Strategic Planning page. HANDBOOK
FOR BASIC PROCESS IMPROVEMENT How to use this
website This website can be used for individual
training or used by teams as a step-by-step guide for basic process improvement. The
core of the Handbook for Basic Process Improvement is found in the 14-step basic process
improvement model. There are tools for basic process improvement identified
throughout the website: The "Tools" listed in the Table
of Contents contain an in-depth training module for each tool. The recommended tools within the 14-step
process contain a quicklook reference describing what the tool is and how it is
used. You may view the entire website using the
scroll bar or if you want to visit a particular section in the handbook, use the Table of
Contents to hyperlink you there. Use <Control> <Home> to return to the
top of the page.
Return to the Index for Leaders at the Center for Strategic Leadership Studies
Table of Contents
HANDBOOK FOR BASIC PROCESS IMPROVEMENT
How to use this website
This website can be used for individual training or used by teams as a step-by-step guide for basic process improvement. The core of the Handbook for Basic Process Improvement is found in the 14-step basic process improvement model. There are tools for basic process improvement identified throughout the website:
The "Tools" listed in the Table of Contents contain an in-depth training module for each tool.
The recommended tools within the 14-step process contain a quicklook reference describing what the tool is and how it is used.
You may view the entire website using the scroll bar or if you want to visit a particular section in the handbook, use the Table of Contents to hyperlink you there. Use <Control> <Home> to return to the top of the page.
CINCPACFLTINST 5224.2, Handbook for Basic Process Improvement (cover letter only)
What is the new Handbook for Basic Process Improvement?
What is a process?
Who owns processes?
What is process improvement?
How does process improvement benefit the organization?
How does an organization get started on process improvement?
Whats in the Basic Process Improvement Model?
Step-by-Step Guide for Process Improvement
Step 1: Select a process and establish the process improvement objective
Step 2: Organize the "right" team
Step 3: Flow chart the current process
Step 4: Simplify the process and make changes
Step 5: Develop a data collection plan and collect baseline data
Step 6: Is the process stable?
Step 7: Is the process capable?
Step 8: Identify root causes for lack of capability
Step 9: Plan to implement the process change
Step 10: Modify the data collection plan, if necessary
Step 11: Test the change and collect data
Step 12: Is the modified process stable?
Step 13: Did the process improve?
Step 14: Standardize the process and reduce the frequency of data collection
Forms (To save these forms, open the form, click "File, Save As" and save to your hard drive.)
Process Selection Work Sheet
Team Charter Work Sheet
Process Improvement Team Meeting Record
Cause-and-Effect Diagram Work Sheet
(Use "Insert Text Box" and position text box under applicable cause.)
Module 1 - Operational Definitions
Module 2 - Brainstorming
(Hint: If you are brainstorming a large quantity of issues, goals, etc., use Post-its or similar product. Post-its can then be organized into related groups (affinitize).)
Module 3 - Decision-Making Tools
Module 4 - Affinity Diagram
Module 5 - Cause-and-Effect Diagram and (Cause-and-Effect worksheet)
Module 6 - Flow Chart
Module 7 - Data Collection
(Use a spreadsheet, such as Microsoft Excel, or a database, such as Microsoft Access, to develop following charts.)
Module 8 - Pareto Chart
Module 9 - Run Chart
Module 10 - Control Chart
Module 11 - Histogram
The new handbook has been developed to assist team leaders at all levels who are involved in process improvement efforts. Together with the Basic Tools for Process Improvement, or "tools kit," it provides the practical information you need to initiate and successfully carry out process improvement activities.
The approach and tools described in the handbook follow a Basic Process Improvement Model. This model differs in many respects from the Process Improvement Flow Chart found in the CNO-sponsored "Starter Kit for Basic Process Improvement" (Dec 1992) distributed to commanding officers several years ago. The Basic Process Improvement Model is much more detailed, in keeping with the "how to" approach used in the new handbook. Together, the model and handbook explain the actual actions teams must take to improve a process.
Before diving into the step-by-step discussion, lets first clarify some terms, look at the benefits of process improvement, and think about the best way to get started.What is a process?
A process is no more than a series of steps and decisions involved in the way work is accomplished. Everything we do in our lives involves processes and lots of them. Here are some examples:
. . . and the list goes on.
As you can see, the level of importance of processes varies.
- Some processes, such as conducting an UNREP or mooring a ship, are very important. If such a process performs very poorlyif it is not doing what it is supposed to dothe command may not be able to complete its mission.
- Other processesfor example, ordering a part or developing a budgetare less significant in terms of the commands mission. But, while they are less important to the overall operation of the command, such routine processes are still vital to the smooth functioning of an office or work center.
Besides differing in importance, processes can be either simple or complicated. Some processes may be comparatively simple. Repairing a valve, for example, may be a relatively simple task involving only a few people and straightforward procedures. On the other hand, some processes, such as conducting a main space fire drill, are very complicated. Many people are involved and numerous process steps and contributing processes are required.Who owns processes?
Everyone has a stake in one or more processes. Groups of individuals usually share inand "own"the activities which make up a process. The one individual who is ultimately responsible and accountable for the proper working of the process is known as the "process owner." The process owner is the immediate supervisor or leader who has control over the entire process from beginning to end.
A process owner may choose to be a team leader and participate directly in the actions of a process improvement team. Or, the process owner may decide to delegate the team leadership role to another person who is knowledgeable about the process. Whatever the case, it is very important for the process owner to stay informed about the teams actions and decisions affecting the process.What is process improvement?
"Process improvement" means making things better, not just fighting fires or managing crises. It means setting aside the customary practice of blaming people for problems or failures. It is a way of looking at how we can do our work better.
When we take a problem-solving approach or simply try to fix whats broken, we may never discover or understand the root cause of the difficulty. Murphys Law comes into play and our efforts to "fix" things may actually make things worse.
However, when we engage in true process improvement, we seek to learn what causes things to happen in a process and to use this knowledge to reduce variation, remove activities that contribute no value to the product or service produced, and improve customer satisfaction. A team examines all of the factors affecting the process: the materials used in the process, the methods and machines used to transform the materials into a product or service, and the people who perform the work.How does process improvement benefit the organization?
A standardized process improvement methodology allows us to look at how we perform work. When all of the major players are involved in process improvement, they can collectively focus on eliminating wasteof money, people, materials, time, and opportunities. The ideal outcome is that jobs can be done cheaper, quicker, easier, andmost importantlysafer.
A teamwork approach is intrinsic to life in the Navy. Using total quality tools and methods reinforces teamwork. Using team members collective knowledge, experiences, and efforts is a powerful approach to improving processes. Through teamwork, the whole becomes greater than the sum of its parts.How does an organization get started on process improvement?
An essential first step in getting started on process improvement is for the senior leader to make it a command priority. The importance of process improvement must be communicated from the top. Leaders need to foster an organizational environment in which a process improvement mentality can thrive and people are using quality-related tools and techniques on a regular basis.
For the organization to reach this state, leaders must ensure that everyone receives the training that will enable them to carry out their process improvement efforts effectively. The TQL training made available within the DON provides background and learning experiences for leaders, quality advisors, TQL coordinators, and supervisors, who can then train teams on a just-in-time basis. In addition, this handbook has been developed to provide teams with a step-by-step approach for their process improvement efforts.
Instilling a process improvement mentality in an organization can be difficult because it requires some different ways of thinking than we are accustomed to in the Navy. Process improvement requires everyone to become a "fire preventer," rather than a "fire fighter." The focus is on improving a process over the long term, not just patching up procedures and work routines as problems occur. To get started on process improvement, leaders who have been fighting fires need to set aside the CO2 bottle and start thinking in these terms:
The Basic Process Improvement Model has two parts:
Using all 14 steps of the model will increase the teams process knowledge, broaden decision-making options, and enhance the likelihood of satisfactory long-term results.
Lets take a quick look at whats in each of the steps in the model.
Step 1: Select the process to be improved and establish a well-defined process improvement objective. The objective may be established by the team or come from outside tasking.
Step 2: Organize a team to improve the process. This involves selecting the "right" people to serve on the team; identifying the resources available for the improvement effort, such as people, time, money, and materials; setting reporting requirements; and determining the teams level of authority. These elements may be formalized in a written charter.
Step 3: Define the current process using a flow chart. This tool is used to generate a step-by-step map of the activities, actions, and decisions which occur between the starting and stopping points of the process.
Step 4: Simplify the process by removing redundant or unnecessary activities. People may have seen the process on paper in its entirety for the first time in Step 3. This can be a real eye-opener which prepares them to take these first steps in improving the process.
Step 5: Develop a plan for collecting data and collect baseline data. These data will be used as the yardstick for comparison later in the model. This begins the evaluation of the process against the process improvement objective established in Step 1. The flow chart in Step 3 helps the team determine who should collect data and where in the process data should be collected.
Step 6: Assess whether the process is stable . The team creates a control chart or run chart out of the data collected in Step 5 to gain a better understanding of what is happening in the process. The follow-on actions of the team are dictated by whether special cause variation is found in the process.
Step 7: Assess whether the process is capable . The team plots a histogram to compare the data collected in Step 5 against the process improvement objective established in Step 1. Usually the process simplification actions in Step 4 are not enough to make the process capable of meeting the objective and the team will have to continue on to Step 8 in search of root causes. Even if the data indicate that the process is meeting the objective, the team should consider whether it is feasible to improve the process further before going on to Step 14.
Step 8: Identify the root causes which prevent the process from meeting the objective. The team begins the Plan-Do-Check-Act Cycle here, using the cause-and-effect diagram or brainstorming tools to generate possible reasons why the process fails to meet the desired objective.
Step 9: Develop a plan for implementing a change based on the possible reasons for the processs inability to meet the objective set for it. These root causes were identified in Step 8. The planned improvement involves revising the steps in the simplified flow chart created after changes were made in Step 4.
Step 10: Modify the data collection plan developed in Step 5, if necessary.
Step 11: Test the changed process and collect data.
Step 12: Assess whether the changed process is stable . As in Step 6, the team uses a control chart or run chart to determine process stability. If the process is stable, the team can move on to Step 13; if not, the team must return the process to its former state and plan another change.
Step 13: Assess whether the change improved the process. Using the data collected in Step 11 and a histogram, the team determines whether the process is closer to meeting the process improvement objective established in Step 1. If the objective is met, the team can progress to Step 14; if not, the team must decide whether to keep or discard the change.
Step 14: Determine whether additional process improvements are feasible. The team is faced with this decision following process simplification in Step 7 and again after initiating an improvement in Steps 8 through 13. In Step 14, the team has the choice of embarking on continuous process improvement by reentering the model at Step 9, or simply monitoring the performance of the process until further improvement is feasible.
STEP-BY-STEP GUIDE FOR PROCESS IMPROVEMENT
Selecting the Process
When a command initially undertakes process improvement efforts, the Executive Steering Committee may identify problem areas and nominate the first processes to be investigated. Later, candidate processes may be identified at the deckplate level by work center supervisors. The Process Selection Worksheet can be used to guide selection at whatever level the choice is made. Some important considerations in selecting processes for improvement are these:
After command members have some experience working with the Basic Process Improvement Model, processes can be selected which have been performing poorly or which offer a potentially high payback in improving mission performance. The former category might include drills and procedures which are routinely accomplished in a less than satisfactory manner. The latter category includes mission critical processes, such as conducting main space fire drills. In each case, its best to move from the simple to the complicated, and from the better performing to the worst performing processes. A process that is primarily controlled, or significantly constrained, by outside factors is probably not a good candidate for improvement by command personnel. Processes selected must be controlled entirely within the lifelines of the command. Only one team should be assigned to work on each process improvement.
Establishing the Process Improvement Objective
Once a process is selected, the team needs to establish a well-defined process improvement objective. The definition of the objective should answer this question: What improvement do we want to accomplish by using a process improvement methodology?
The process improvement objective is frequently discovered by listening to internal and external customers. The team can use interviews or written surveys to identify target values to use as goals for improving the product or service produced by the process. Identifying a problem associated with the process helps define the process improvement objective. The people working in the process can identify activities that take too long, involve too many man-hours, include redundant or unnecessary steps, or are subject to frequent breakdowns or other delays. This is not just a problem-solving exercise; this is process improvement. Problems are symptoms of process failure, and it is the deficiencies in the process that must be identified and corrected. For an improvement effort to be successful, the team must start with a clear definition of what the problem is and what is expected from the process improvement. Lets look at a couple of examples:
A team formulating a process improvement objective may find it helpful to proceed in this way:
A final note: Without a stated improvement objective, the team may conduct meetings but achieve little improvement in the effectiveness, efficiency, or safety of their process. A clearly stated process improvement objective keeps the teams efforts focused on results.
Team members are selected by the team leader or the individual who formed the team. Members may be of various ranks, rates, paygrades, or ratings. Depending on the nature of the process, they may come from different departments, divisions, work centers, or offices. The key factor is that the people selected for the team should be closely involved in the process that is being improved. Being a team member has certain obligations. Members are responsible for carrying out all team-related work assignments, such as data collection, data analysis, presentation development, sharing knowledge, and participation in team discussions and decisions. Ideally, when actual process workers are on a team, they approach these responsibilities as an opportunity to improve the way their jobs are done, rather than as extra work.
A charter is a document that describes the boundaries, expected results, and resources to be used by a process improvement team. A charter is usually provided by the individual or group who formed the team. Sometimes the process owner or the team members develop a charter. A charter is always required for a team working on a process that crosses departmental lines. A charter may not be necessary for a team that is improving a process found solely within a work center of office space. A charter should identify the following:
Team Ground Rules
No process improvement team should go beyond Step 2 without developing a clear-cut set of ground rules for the operation of the team. The ground rules act as a code of conduct for team members and provide a basic structure for conducting effective meetings. Some areas in which ground rules should be established are:
Guidelines for Effective Team Meetings
The Improvement Team Meeting Record helps teams follow the guidelines for conducting effective meetings that are outlined below.
Training for the Team
At this juncture, team members need to receive some training that will help them reach their process improvement objective. The Team Leader or Quality Advisor should provide training on how to operate effectively as a team as well as just-in-time training in the use of statistical tools. All aspects of team formation and functioning are discussed in the DON TQL course, Team Skills and Concepts. Statistical and process management tools is explained in the Basic Tools for Process Improvement as well as in numerous DON TQL courses.
Before a team can improve a process, the members must understand how it works. The most useful tool for studying the current process is a flow chart . This tool is explained in the Basic Tools for Process Improvement. To develop an accurate flow chart, the team assigns one or more members to observe the flow of work through the process. It may be necessary for the observers to follow the flow of activity through the process several times before they can see and chart what actually occurs. This record of where actions are taken, decisions are made, inspections are performed, and approvals are required becomes the "as-is" flow chart. It may be the first accurate and complete picture of the process from beginning to end.
As the team starts work on this first flow chart, they need to be careful to depict what is really happening in the process. They dont want to fall into the trap of flow charting how people think the process is working, how they would like it to work, or how an instruction or manual says it should work. Only an as-is flow chart that displays the process as it is actually working today can reveal the improvements that may be needed.
When teams work on processes that cross departmental lines, they may have to talk to people at all levels across the command who are involved in or affected by the process they are working on. It is even more important to get an accurate picture of these cross-functional processes than those whose boundaries are inside a work unit or office.
As an example, "launching a helicopter" is a cross-functional process involving contributing processes performed by bridge personnel, controllers in the CIC, firefighting teams, the fueling team, engineers, the cargo handling team, flight deck personnel, and others. Each of these contributing processes has to be accurately flow charted and clearly understood before the larger process can be improved. The goal of this step is for the team to fully understand the process before making any attempt to change it. Changing a process before it is fully understood can cause more problems than already exist.
The team can define the current situation by answering these questions:
The team described the current process by developing a flow chart in Step 3. Reviewing this depiction of how the process really works helps team members spot problems in the process flow. They may locate steps or decision points that are redundant. They may find that the process contains unnecessary inspections. They may discover procedures that were installed in the past in an attempt to goof-proof the process after errors or failures were experienced. All of these eat up scarce resources.
Besides identifying areas where resources are being wasted, the team may find a weak link in the process that they can bolster by adding one or more steps. But before stepping in to make changes in the process based on this preliminary review of the as-is flow chart, the team should answer the following questions for each step of the process:
If the answers to these questions indicate waste, the team should consider doing away with the step. If a step or decision block can be removed without degrading the process, the team is recovering resources which can be used elsewhere in the organization. Eliminating redundant or unnecessary steps confers an added benefit: a decrease in cycle time. Only part of the time it takes to complete most processes is productive time; the rest is delay. Delay consists of waiting for someone to take action, waiting for a part to be received, and similar unproductive activities. Consequently, removing a step which causes delay reduces cycle time by decreasing the total time it takes to complete the process.
After making preliminary changes in the process, the team should create a flow chart of the simplified process . Now comes the sanity check:
If the answer is "yes," and the team has the authority to make changes, they should institute the simplified flow chart as the new standard picture of the process. But perhaps the team is required to get permission to make the recommended changes. In that case, a comparison of the simplified flow chart with the original as-is flow chart can become the centerpiece of a briefing to those in a position to grant approval. At this point, the people working in the process must be trained using the new flow chart of the simplified process. It is vital to ensure that they understand and adhere to the new way of doing business. Otherwise, the process will rapidly revert to the way it was before the improvement team started work.
Steps 1 through 4 have taken the team through a process simplification phase of process improvement. In this phase, all decisions were based on experience, qualitative knowledge of the process, and perceptions of the best way to operate. For the remaining steps in the Basic Process Improvement Model, the team will be using a more scientific approach.
Steps 5 through 14 of the model rely on statistical data which, when collected and analyzed, are used to make decisions about the process. In Step 5, the team develops a data collection plan, as described in the Basic Tools for Process Improvement. The process improvement objective established in Step 1 is based on customers expectations and needs regarding the product or service produced by the process. When the team develops a data collection plan, they must first identify the characteristic of the product or service that has to be changed in order to meet the objective. Lets look at an example:
The key to this segment of the model is to use process knowledge and common sense in determining where to take measurements. The team should ask: Will the data collected at this point help us decide what to do to improve the process?
The team in the example investigated the process further and opted to take measurements of the temperature of the coffee at the urn on the serving line. Once the team determines what data to collectand why, how, where, and when to collect itthey have the rudiments of a data collection plan. To implement the data collection plan, the team develops a data collection sheet. This data collection sheet must include explicit directions on how and when to use it. The team should try to make it as user-friendly as possible.
The team can collect baseline data when, and only when, the data collection plan is in place, the data collection sheet has been developed, and the data collectors have been trained in the procedures to use.
In this step, the team analyzes the baseline data collected in Step 5. Two tools which are useful in this analysis are a control chart and a run chart. Both of these tools organize the data and allow the team to make sense of a mass of confusing information. They are explained in the Basic Tools for Process Improvement. Control charts are better at revealing whether a process is stable and its future performance predictable. However, even if a team begins with the simpler run chart, they can convert it to a control chart with a little extra work. These two tools are important because they help teams identify special cause variation in the process. Whenever an individual or a team repeats a sequence of actions, there will be some variation in the process. Lets look at an example:
In our example, investigation revealed that you were delayed by an early-morning phone call from one of your children who is at college. The data provided a signal of special cause variation in your getting-off-to-work process. But what if, over a period of 10 days, a series of times is recorded that averaged 48 minutes? It seems that your getting-off-to-work process now includes making breakfast for your son and daughter. This is not just a variation. The data indicate that your process has changed.
While this example portrayed an obvious change in the process, subtle changes often occur without the knowledge of the workers. These minor changes produce enough variation to be evident when the data are analyzed. If special cause variation is found in the process, the team is obliged to find the cause before moving on to the next step in the model. Depending on the nature of the special cause, the team may act to remove it, take note of it but no action, or incorporate it in the process.
When special cause variation reduces the effectiveness and efficiency of the process, the team must investigate the root cause and take action to remove it. If it is determined that the special cause was temporary in nature, no action may be required beyond understanding the reason for it. In the example above, the early phone call caused a variation in the data which was easily explained and required no further action.
Occasionally, special cause variation actually signals an improvement in the process, bringing it closer to the process improvement objective. When that happens, the team may want to incorporate the change permanently. If the team fails to investigate a signal of special cause variation and continues on with their improvement activities, the process may be neither stable nor predictable in the future. This lack of stability and predictability may cause additional problems to occur, preventing the team from achieving the process improvement objective.
Once the process has been stabilized, the data collected in Step 5 is used again. This time the team plots the individual data points to produce a bar graph called a histogram . This tool is explained in the Basic Tools for Process Improvement. To prepare the histogram, the team superimposes the target value for the process on the bar graph. The target value was established in Step 1 as the process improvement objective. If there are upper and/or lower specification limits for the process, the team should plot them also. (Note: Specification limits are not the same as the upper and lower control limits used in control charts.)
Once the data, the target value, and the specification limits (if applicable) are plotted, the team can determine whether the process is capable . The following questions can be used to guide the teams thinking:
Are there any unusual patterns in the plotted data?
Does the bar graph have multiple tall peaks and steep valleys? This may be an indication that other processes are influencing the process the team is investigating.
Do all of the data points fall inside the upper and lower specification limits (if applicable)? If not, the process is not capable.
If all of the data points fall within the specification limits, are the data grouped closely enough to the target value? This is a judgment call by the team. While the process is capable, the team may not be satisfied with the results it produces. If thats the case, the team may elect to continue trying to improve the process by entering Step 8 of the Basic Process Improvement Model. If there are no specification limits for the process, does the shape of the histogram approximate a bell curve? After examining the shape created by plotting the data on the histogram, the team has to decide whether the shape is satisfactory and whether the data points are close enough to the target value. These are subjective decisions. If the team is satisfied with both the shape and the clustering of data points, they can choose to standardize the simplified process or to continue through the steps of the Basic Process Improvement Model.
From here to the end of the Basic Process Improvement Model, the team is going to use a scientific methodology for conducting process improvement called the Plan-Do-Check-Act (PDCA) Cycle. They will plan a change, conduct a test and collect data, evaluate the test results to find out whether the process improved, and decide whether to standardize or continue to improve the process. The PDCA Cycle is just that: a cycle. There are no limitations on how many times the team can attempt to improve the process incrementally.
Steps 1 through 7 of the model were concerned with gaining an understanding of the process and documenting it. In Step 8, the team begins the PDCA Cycle by identifying the root causes of a lack of process capability. The data the team has looked at so far measure the output of the process. To improve the process, the team must find what causes the product or service to be unsatisfactory. The team uses a cause-and-effect diagram to identify root causes. This tool is explained in the Basic Tools for Process Improvement.
Once the team identifies possible root causes, it is important to collect data to determine how much these causes actually affect the results . People are often surprised to find that the data do not substantiate their predictions, or their gut feelings, as to root causes. The team can use a Pareto chart to show the relative importance of the causes they have identified.
Step 9 begins the Plan phase of the PDCA Cycle. Steps 9 and 10 together comprise the whole Plan phase. After considering the possible root causes identified in Step 8, the team picks one to work on. They then develop a plan to implement a change in the process to reduce or eliminate the root cause. The major features of the plan include changing the simplified flow chart created in Step 4 and making all of the preparations required to implement the change. The team can use the following list of questions as a guide in developing the plan:
Once the improvement plan is formulated, the team makes the planned changes in the process, if empowered by the team charter to do so. Otherwise, the team presents the improvement plan to the process owner, or other individual who formed the team, to obtain approval to proceed.
|Step 10: Modify the data
collection plan, if necessary
Step 10 concludes the Plan phase of the PDCA cycle.
Reviewing the data collection plan
The data collection plan was originally developed in Step 5. Since the process is going to change when the planned improvement is instituted, the team must now review the original plan to ensure that it is still capable of providing the data the team needs to assess process performance.
Modifying the data collection plan
If the determination is made that the data collection plan should be modified, the team considers the same things and applies the same methodologies as in Step 5.
|Step 11: Test the change and collect data
Step 11 is the Do phase of the PDCA cycle. If feasible, the change should be implemented on a limited basis before it is applied to the entire organization. For example, the changed process could be instituted in a single office or work center while the rest of the command continues to use the old process. If the organization is working on a shift basis, the changed process could be tried on one shift while the other shifts continue as before. Whatever method the team applies, the goals are to prove the effectiveness of the change, avoid widespread failure, and maintain command-wide support. In some situations, a small-scale test is not feasible. If that is the case, the team will have to inform everyone involved of the nature and expected effects of the change and conduct training adequate to support a full-scale test.
The information the team developed in Step 9 provides the outline for the test plan. During the test, it is important to collect appropriate data so that the results of the change can be evaluated. The team will have to take the following actions in conducting the test to determine whether the change actually resulted in process improvement:
Steps 12 and 13 together comprise the Check phase of the PDCA cycle. The team modified the process based on the improvement plan and conducted a test. During the test of the new procedure, data were collected. Now the team checks whether the expected results were achieved. The procedures in this step are identical to those in Step 6. The team uses the data they have collected to check the process for stability by preparing a control chart or run chart . Since the process has changed, it is appropriate to recompute the control limits for the control chart using the new data. If the data collected in Step 11 show that process performance is worse, the team must return to Step 8 and try to improve the process again. The process must be stable before the team goes on to the next step.
|Step 13: Did the process improve?
Step 13 completes the Check phase of the PDCA cycle. The procedures are similar to those in Step 7. This is a good place for the team to identify any differences between the way they planned the process improvement and the way it was executed. The following questions will guide the team in checking the test results:
Did the change in the process eliminate the root cause of the problem? Whether the answer is "yes" or "no," describe what occurred.
Are the data taken in Step 11 closer to the process improvement objective than the baseline data? This indicates how much or how little the process has improved.
Were the expected results achieved? If not, the team should analyze the data further to find out why process performance improved less than expected or even became worse.
Were there any problems with the plan? The team needs to review the planned improvement as well as the execution of the data collection effort.
14: Standardize the process and reduce the frequency of data collection
Step 14 is the Act phase of the PDCA cycle. In this step, the team makes some important decisions. First, they must decide whether or not to implement the change on a full-scale basis. In making this decision, the team should answer the following:
If the answers are affirmative, the changed process can be installed as the new standard process .
Second, they must decide what to do next. Even when everything is in place for implementing and standardizing the process, the team still has to choose between two courses of action:
Identifying possibilities for making further process changes. Assuming that resources are available and approval given, the team may choose to continue trying to improve the process by reentering the PDCA cycle at Step 9.
Standardizing the changed process without further efforts to improve it. If this decision is made, the team is still involveddocumenting the changes, monitoring process performance, and institutionalizing the process improvement. To standardize the changed process, the team initiates documentation changes involving procedures, instructions, manuals, and other related documentation. Training will have to be developed and provided to make sure everyone is using the new standard process.
The team continues to use the data collection plan developed in Step 11, but significantly reduces the frequency of data collection by process workers. There are no hard-and-fast rules on how often to collect data at this stage, but, as a rule of thumb, the team can try reducing collection to a quarter of what is called for in the data collection plan. The team can then adjust the frequency of measurement as necessary. The point is, enough data must be collected to enable the team to monitor the performance of the process. The team must periodically assess whether the process remains stable and capable . To do this, the data collected in Step 14 should be entered into the control chart or run chart and histogram developed in Steps 12 and 13 respectively.
Whichever course of action the team pursues, they should complete one last task: documenting the lessons learned during the process improvement effort and making the information available to others.