|
|
4th Annual Global Lean, Six Sigma and Business Improvement Summit & Industry Awards
Swan and Dolphin Resort, Walt Disney World, Orlando, FL (Workshops: October 13 & 16, 2009. Summit: October 14 & 15, 2009.) |
   |
| 05/20/2009 |
Risk/Science-Based Approach to Validation: A Win-win-win for Patients, Regulators, and Industry
Published in PDA JOURNAL OF PHARMACEUTICAL SCIENCE AND TECHNOLOGY, Jan/Feb 2004
by Karen A. Welch, Conrad A. Fung, Stephen R. Schmidt
Abstract
Regulatory compliance is often perceived to be in conflict with business success and profitability. In many cases this perception cascades down through the ranks, resulting in meeting only the letter of the law of the regulations without satisfying their intent. This in turn generates further problems that can ultimately lead to non-compliance and/or product failure with a negative impact on the patient, both in health risks and high costs of medication. In the end the conflict between regulatory and business generates risk for every facet of the health care system: patients, regulatory, and industry.
This paper proposes a risk/science-based strategy for “validation” using design of experiments that will be viewed as a victory for all—patients, regulators, and industry—a win-win-win. This strategy offers vital assurance that regulatory will see no degradation of previous expectations, while affording business leaders a high level of confidence that compliance can also reduce waste within the business and therefore positively affect the bottom line. Science-based validation supports new FDA views outlined in a new Draft Guidance for Industry, PAT – A Framework for Innovative Pharmaceutical Manufacturing and Quality Assurance, published August 2003. Patients can ultimately expect benefits in improved quality and lower cost. In short, the three-fold goals of this strategy are to achieve compliance to regulations, combined with return on investment (ROI) to industry, and lower health risks and costs to the patient.
ntroduction
Few doubt the need for validation, but there is often confusion about exactly what validation is, and precisely how to validate. The Food and Drug Administration (FDA) (1) defines process validation as “establishing documented evidence, which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality characteristics.”
Initially borrowed from the aerospace industry in the 1960’s, validation concepts were first applied in the pharmaceutical industry in sterilization processes and solid-dose forms with extremely low levels of active ingredient. Application of these concepts began to expand in the 1970’s, and by the 1980’s they covered all pharmaceutical manufacturing processes. The FDA added to this expansion with public statements, journal articles, and, most importantly, through issuance of finalized guidelines in l987. Today virtually all of industry considers process validation to be current good manufacturing practice (cGMP) (2).
Although the original intent of validation was clear—to establish “documented evidence that a process will consistently do what it purports to do”—most pharmaceutical manufacturers have come to rely on an expedient, but scientifically unsound, approach of testing three successive lots with the hope that all will produce acceptable results. Yet these three lots are likely to be untypical of the ultimate process—in fact they may be the least variable of any lots ever to be produced—because of the business need to complete validation successfully and the consequent care given to the manufacture of these three lots. Furthermore, most pharmaceutical manufacturers implement formal validation master plans involving enormous detail, much of which is documented in Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) documents. In part this is in response to the guideline General Principles of Process Validation prepared by the Center for Drugs and Biologics and the Center for Devices and Radiological Health (CDRH), of the FDA, in May 1987 (3).
A presentation at the American Association of Pharmaceutical Scientists 38th Annual Pharmaceutical Technologies Conference in January 2003, at Arden House in New York, stated that “validation reached a point of diminishing returns in the 1980’s. Since then, industry has spent much money and tremendous energy on validation, with little benefit to the end users of the products. In 2000, validation costs in most projects exceed 10 and for sterile operations or projects that include newer technology validation, costs may reach 15” (4).
In fact, excessively restrictive process requirements are a symptom of incomplete knowledge of the basic sciences underlying the manufacturing process. If precise understanding is missing about causal relationships between key product and process input variables (KPIVs) and critical quality attributes (CQAs), inspection is often put in place to “check quality in.” If this lack of knowledge begins in research and development (R&D), it will surely be transferred to manufacturing, resulting in enormous costs to the business. These costs can take the form of “fire-fighting” when a high level of short-term resources are expended on “fixing” a problem when it is not known how to recover, as well as high costs due to inefficient manufacturing and off-market situations. These costs are inevitably passed on to the patient, with the ultimate risk of products becoming cost-prohibitive. The current approach to validation does little to reduce these costs.
In contrast, the desired state of validation should be that it is not an “event,” but rather an integral part of development and manufacturing based on product and process knowledge. In order to gain this much-needed knowledge about products and processes, validation must be science-based, have its roots in customer requirements, and must start well before production. It must include knowledge-generating characterization studies of the product and process, employing scientifically sound experimental design. Key product and process input and output variables that relate to customer requirements must be identified, characterized, and subsequently monitored to predict future performance. In short, characterization builds knowledge, and consequently reduces costs and risks associated with lack of knowledge. Validation concludes with a simple confirmation run, after scale-up, of the process model(s) established during characterization.
This science-based approach to validation unites with, and amplifies, new initiatives of the FDA—“A Drug Quality System for the 21st Century”—which in turn supports and drives process analytical technology (PAT). The Drug Quality System for the 21st Century will incorporate the most up-to-date concepts of risk management and quality systems while continuing to ensure product quality and encouraging the latest scientific advances in pharmaceutical manufacturing and technology. PATs promote process understanding in design, predictability and capability by identification, characterization and subsequent monitoring of critical process control points (CCPs).
The FDA defines PATs as
- systems for analysis and control of manufacturing processes based on timely measurements of critical quality parameters and performance attributes of raw and in-process materials
- processes to assure acceptable end product quality at the completion of the process
PATs involve
- optimal applications of process analytical chemistry tools
- feedback process control strategies
- information management tools and/or product/process optimization strategies to the manufacture of pharmaceuticals
Science-based (prospective and retrospective) validation is a key factor for successful implementation of PAT in the development and manufacture of pharmaceuticals. The new Draft Guidance for Industry, PAT – A Framework for Innovative Pharmaceutical Manufacturing and Quality Assurance states, “A desired goal of the PAT framework is to design and develop processes that can consistently ensure a predefined quality at the end of a manufacturing process. Such procedures would be consistent with the basic tenet of quality by design and could reduce risks to quality and regulatory concerns while improving efficiency” (5).
Prospective validation: A science-based Approach
According to the FDA (6), the formal definition of prospective validation is “validation conducted prior to the distribution of either a new product, or product made under a revised manufacturing process, where the revisions may affect the product’s characteristics” (emphasis added). Science-based, prospective validation should be integrated as a continuous part of the development process, beginning in R&D; see Figure 1. Prospective validation includes knowledge of customer requirements, identification of critical quality attributes (CQAs) that relate to end-customer requirements, understanding of key process input variables (KPIVs) and how they affect CQAs, and confirming these relationships throughout the development process. This science-based approach supports the principle of “design for simplicity and consistency,” which in turn promotes successful scale-up and validation. It not only starts with customer requirements, but also protects the integrity of these requirements throughout subsequent specifications that are set for product components and process steps, from incoming materials to final release of the product. The basic elements of prospective validation follow.
Knowledge of Customer Requirements and Critical Quality Attributes (CQAs)
The first step in this science-based approach to validation lies in the assumption that the fundamental requirements of the end-user or patient are known. These requirements form the foundation for establishing CQAs, which are measurable final product characteristics, identified during feasibility studies, that relate to customer requirements. These CQAs are high-level metrics to judge whether customer requirements are met. For example, if the end user is a patient who wants relief from or prevention of some effect such as a headache, customer requirements for a headache medication might be fast, effective pain relief that is easy to administer at an acceptable cost. These conceptual customer requirements must then be translated into quantifiable CQAs, for example, a uniform, specific dose tablet with a specific dissolution rate, which in turn are the basis for identifying output variables, or critical Ys. These high-level requirements are key inputs for the package insert. During this step, the measurement system and sampling plan should be evaluated.
Identifying Product Design
A product design which meets customer requirements must be decided upon at this time, for example, whether the product should be a tablet, capsule, gel cap, liquid, etc. The product should be designed for simplicity and consistency, in addition to the fundamental requirements of safety and efficacy. It is also important to generate a high-level process flow, or value stream, to anticipate the activities needed to produce the product.
Developing Manufacturing Process
At this point a process design that meets the requirements of the product identified above must be created. Options to manufacturing methods should be evaluated for simplicity and reliable scale-up, as this is a critical failure mode. Thought must be given to potential differences between small scale in R&D and full-scale production.
Once a manufacturing process has been identified, it must be refined and further developed by identifying sub-processes to achieve the product design. Factors that may affect the product and process differently when made to full scale should be considered. For example, is the chosen mixing method robust to scale-up factors? Is there an alternative process that is less dependent on scale-up? Is there a measurable output variable that can give a more useful indication of the efficacy of this intermediate step, other than machine parameters? PAT online measurement tools can play a key role in answering the above questions; for example, online measurement can be used to assess completion of mixing instead of end-product testing. The flow of all the sub-processes involved must be documented.
Next, product and process output variables (critical Ys) that relate to the CQAs must be identified for each sub-process. Critical Y’s are measurable outputs of each process step used to provide evidence that the process step has been performed correctly and relate directly to CQAs, which, in turn, relate to customer requirements. These are ideal candidates to predict future performance using Statistical Process Control (SPC).
Identification of Key Process Input Variables (KPIVs)
At this time, KPIVs—all factors that could potentially affect the mean and standard deviation (SD) of the critical Ys of each sub-process—must be identified. It is important to identify both process (physical) and product (chemistry) variables that could affect the critical Ys. A useful tool to generate initial information on input factors is the cause and effect diagram, coupled with brainstorming, to identify all possible causes of variation for each critical Y. These potential factors are initially reviewed to determine which ones should be held constant based on scientific judgment. Where and how they are held constant should then be documented in standard operating procedures (SOPs). The next step is to use a screening design, a designed experiment used to separate the vital few factors from a large number of factors to be tested. The vital few factors are identified as KPIVs, factors that have been evidenced by DOE to influence the critical Ys when varied. DOE is defined as the purposeful changes of the input factors to a process (or activity) in order to observe the corresponding changes in the output responses. This is an approach for effectively and efficiently exploring the cause-and-effect relationship between numerous process variables (Xs) and the output or process performance variables (Ys). Certain designs can yield an equation that quantifies the relationship between the Xs and Ys.
Product/Process Characterization (DOE)
Because numerous examples of interactions between product and process variables are known to exist in pharmaceutical manufacturing, proper use of DOE is essential to understand these synergistic effects. In this final phase, KPIVs will be modeled and optimized in designing the manufacturing processes, and subsequently monitored to assess process capability. Critical Ys (outputs or responses) from one sub-process are often inputs for the next sub-process. The KPIVs identified above are now used in a modeling DOE, a designed experiment used to build a linear or non linear model to characterize the relationship between process inputs and output(s). A modeling DOE is a useful tool to (1) gain an understanding of the relationship between the key input factors and critical Ys for each sub-process, (2) build a mathematical model (transfer function) relating input factors to the responses (critical Ys), often referred to as product/process characterization, (3) determine the settings of input factors that optimize the response and minimize costs, and (4) use identified transfer functions to set process guardbands on the input variables to ensure capability of the critical Ys. Process guardbands are ranges set for KPIVs where no statistical change to the output is observed. (7)
Advantages of designed experimentation versus traditional experimental techniques include reduced sample size, the ability to identify synergistic effects (interactions), and the ability to model how outputs relate functionally to inputs, including how product variability (measured by SD) may be a systematic function of input factor settings.
Other tools can also be used in an orchestrated manner to gain understanding of the process, for example, Six Sigma’s DMAIC (Define, Measure, Analyze, Improve and Control). This sequence of knowledge-gaining steps may employ a variety of tools depending on one’s current objective. For characterization, the backbone of Risk/Science-based validation, the primary tool is DOE. However, in order to obtain meaningful information and to prepare for a successful DOE, two other facets of validation are critical and must be addressed. The first is simplification, where we design for simplicity, removing non-value-added activities, etc., and the second is consistency, where we remove as much variation as possible before running a DOE, employing tools such as Process Flow, Cause & Effect, identification of “Constant, Noise, Experimental Variable”, and Standard Operating Procedure (PF, CE, CNX, SOP) (7).
Production Confirmation
Following this science-based characterization, validation concludes with a simple confirmation of the transfer functions (process models) identified by DOE in R&D, over the variability inherent in full-scale production. If the process was developed to mitigate potential causes of scale up differences, this step is simply a confirmation that employs different supplier lots and full-scale equipment.
If all results are within ranges that produce acceptable product, validation is complete.
If parameters set in R&D are not confirmed after scale-up, the Scale-Up Calibration step below is needed. If new parameters must be set, and clinical lots were used before scale-up, some evidence of “comparability” between production lots and the clinical lots must be demonstrated.
Scale-Up Calibration
In Scale-Up Calibration, a screening DOE is used first to identify additional KPIVs, and a modeling DOE can subsequently be applied to these critical Xs to identify transfer functions specific to the scaled up production process; see Figure 2. The modeling concepts of the Product/Process Characterization section above apply to scale-up calibration as well.
A critical need during this entire activity is to keep a central “knowledge notebook.” In many cases, even when process characterization work is completed within R&D, knowledge may exist in so many different scientists’ and engineers’ independent notebooks that important activities may be forgotten and then repeated, wasting both time and money.
Retrospective Validation: A Science-Based Approach
Retrospective validation is never a desirable substitute for the full prospective approach described above, but it is sometimes unavoidable and it necessitates a science-based approach. According to the FDA (6), the formal definition of retrospective validation is “validation of a process for a product already in distribution based upon accumulated production, testing and control data.” Because of potential incompatibilities among these disparate sources of historical data, we suggest that a more scientific approach would be to employ a screening DOE to establish that the specifications do indeed maintain the CQA’s at levels that ensure that customer requirements are met. See Figure 3.
Understanding Customer Specifications and CQAs
The first step in retrospective validation is to create a high-level process flow—or value stream—from incoming raw materials to final acceptance.
The next step is to obtain, from package insert claims, the high-level product specifications that relate to the customer requirements. These are outputs (CQAs) for the high-level process flow diagram, and are the key metrics for determining whether the process has been validated successfully. During this step, the measurement system and sampling plan should be evaluated.
Identifying the Sub-processes and Key Process Input Variables
For each sub-process relating to the manufacture of the product, the critical Ys and their allowable ranges should be identified. Typically these are internal specifications for each critical Y.
It is important to identify all factors that could potentially affect the mean and SD of the critical Ys. A useful tool to generate initial information on potential input factors is the Cause and Effect Diagram, coupled with brainstorming, to identify all possible causes of variation for each critical Y. These potential factors are initially reviewed to identify which ones should be held constant based on scientific judgment. Where and how they are held constant should then be documented in SOPs. It should be noted that some factors identified above may not currently be controlled by internal specifications, but if scientific judgment suspects they may affect the critical Y, they should be identified. For those factors currently controlled, one should set the highs and lows for each KPIV or input factor (critical Xs) in the screening design to their internal specifications. For those not controlled, one should choose a high and low setting consistent with current operations.
Design of Experiment & Evaluation
At this time, an appropriate screening design for each sub-process must be determined. The DOE is run on the input variables identified during Cause and Effect, making sure the remaining variables are held constant in adherence with their SOPs. The input factors are then set to the limits of their internal specifications, or to limits consistent with current operations if there are no internal specifications. All output values from the experiment must satisfy the package insert claims in order for the retrospective validation to be considered successful.
If the output values are outside the internal specifications, but within the package insert claims, the internal specifications may be re-evaluated, subject to the cautions documented below, using the DOE results as justification to change them.
If any values do not meet package insert claims, additional studies in the form of Scale-Up Validation must be performed.
Cautions During Evaluation
Stability over the life of the product must be taken into consideration, for example, the use of product in the designed experiment that spans the entire life-cycle of the product, from newly manufactured product to almost expired product. This will ensure that the results apply across the entire life of the product.
If initial internal specifications were not set scientifically (i.e., they were set in terms of mean +/- 3 SDs), then they should be redefined taking into account DOE knowledge, measurement system analysis, and sampling plan.
Outliers must be explained, not just omitted. Causes of outliers must be identified and corrected; only then can they be removed. Typical causes of outliers include inadequate procedures, failure to follow procedures, and uncontrolled variables.
Return on Investment Resulting from A Science-Based Approach
The return on investment from this science-based approach to validation results directly from knowledge gained, which in turn reduces risks to all parties—patients, industry, and regulatory bodies. Risks to the patient include harm due to incorrectly manufactured drugs, drug unavailability due to manufacturing failure, and high costs of drugs resulting from high development and troubleshooting costs. Risks to industry include regulatory action due to noncompliance; off-market situations when processes are not properly validated; cost-prohibitive, inefficient development and manufacturing; and the high costs of regulatory oversight, a cost not necessarily contributing to better science. Finally, risks to regulatory include legal action and/or litigation and a shortage of medically necessary drugs.
In short, the return on investment from this science-based approach to validation comes from mitigating the above risks by gaining knowledge, understanding the causal relationships between key input variables and critical quality attributes, and by assuring that R&D and scale-up are knowledge-based. This in turn increases process efficiency by decreasing waste, decreasing rework, and increasing the likelihood of successful scale-up and validation.
References
1.Food and Drug Administration, Center for Drugs and Biologics and Center for Devices and Radiological Health. Guideline on General Principles of Process Validation. FDA Division of Manufacturing and Product Quality: Rockville, MD, 1987; p. 4.
2.Ferreira, J; Cooper, D. Process Validation and Drug cGMPs: A Detailed Analysis of the Proposed Revisions. Journal of Validation Technology 1996, 3, 81.
3.Food and Drug Administration, Center for Drugs and Biologics and Center for Devices and Radiological Health. Guideline on General Principles of Process Validation. FDA Division of Manufacturing and Product Quality: Rockville, MD, 1987; pp. 9-11.
4.Akers, J. E. Putting the Product and Process Back into Validation. American Association of Pharmaceutical Scientists 38th Annual Pharmaceutical Technologies Conference at Arden House. The Key for Achieving New Standards of Development and Manufacturing Excellence and Regulatory Compliance: Process Analytical Technology; Harriman, NY, 2003.
5.Food and Drug Administration, Center for Drug Evaluation and Research, Center for Veterinary Medicine, Office of Regulatory Affairs. Draft Guidance for Industry, PAT – A Framework for Innovative Pharmaceutical Manufacturing and Quality Assurance. FDA: Rockville, MD, 2003; p. 8.
6.Food and Drug Administration, Center for Drugs and Biologics and Center for Devices and Radiological Health. Guideline on General Principles of Process Validation. FDA Division of Manufacturing and Product Quality: Rockville, MD, 1987; p. 2.
7.Welch, K. A. Validation of Checkweighers; A Case Study. Journal of Validation Technology 2003, 9, 248.
8.Schmidt, S. R.; Launsby, R. G. Understanding Industrial Designed Experiments, 4th edition; Air Academy Press: Colorado Springs, CO, 1994; inside front cover.
|
| 05/19/2009 |
The E-Z Way Out: An enthusiastic embrace of Lean Manufacturing initiatives has kept golf cart manufacturer E-Z-GO on par for success
By Jeff Reinke, Editorial Director, IMPO
Source: http://www.impomag.com/scripts/ShowPR.asp?RID=9864&CommonCount=0
It’s an interesting parallel that can be drawn between an American manufacturer and a professional sports franchise. Both operate in highly competitive environments which are becoming more global in reach and opportunity. Additionally, finding qualified workers is always a challenge, and both have very passionate stakeholders that are constantly demanding a better return for their invested time and money. And in the end, both want, and need, to win.
Perhaps there is no better example of these two worlds colliding than the E-Z-GO golf car headquarters in Augusta, GA. It’s on these walls that quotes from legendary football coach Vince Lombardi can be found reminding the company’s 1,100 employees that, “The achievements of an organization are the results of the combined efforts of each individual.” Similar to the way his football teams embraced this mantra of teamwork and responsibility, so have the people at E-Z-GO. Unfortunately, this wasn’t always the case.
“When I came here about four years ago, our plant floor was chaos,” reflects Westy Bowen, E-Z-GO’s V.P. of Six Sigma. “The floor was covered with materials, there was little organization, and the whole facility was very dark. Most concerning, however, was that much of the processes were at the same level as the plant’s appearance.” It was about this same time that E-Z-GO’s parent company, Textron, was looking for a volunteer to pilot their Lean Accelerator program.
“We raised our hand,” states E-Z-GO President Kevin P. Holleran, “because it was a great opportunity to tap into the available resources and implement some much needed change. In all honesty, I’m not sure this plant would still be operating in the same capacity if we hadn’t gotten so involved in Six Sigma and its Lean methodologies.”
E-Z-GO is one of the top two manufacturers of golf cars in the world, and has been a part of Textron since 1960. The company’s origins go back to 1954 when a couple of brothers, Bev and Bill Dolan, thought up the concept for their car while sitting on the front porch of the club house at the famed Augusta National Golf Club. Although its history and brand recognition are second to none, increased competition, especially offshore, demanded that the company find new ways of improving quality, and lowering overhead costs.
The Answer Within
“We started by benchmarking ourselves against a number of automotive production plants, and related manufacturers, like Crown fork lifts,” begins Eric Cardinali, E-Z-GO V.P. of Integrated Supply Chain. After garnering a better foothold on what Lean was all about, the company began implementing a number of Six Sigma related tools, including:
* The implementation of a Design For Manufacture & Assembly (DFMA) methodology. This translates to those designing the cars being tied into the production element, so the product design meshes more appropriately with manufacturing strengths and capabilities.
* Highly visible production scoreboards that show, in real-time, how many cars have been built versus how many were scheduled. By instilling a sense of accountability for their work, employees are asked to take greater responsibility for the company’s results. This ties them in to the big picture and offers a stronger connection to producing higher quality work in a more efficient manner.
* SQDC (Safety, Quality, Delivery and Cost) boards were put in place to demonstrate how much labor has been invested in each vehicle. It’s another efficiency benchmark that shows workers how they can help the company to be as profitable as possible.
* New warehouse and transportation management systems that have resulted in efficiency improvements, i.e. being able to transport two additional carts per trailer. The use of their own Cushman-branded industrial tugs for Kanban replenishment, instead of fork trucks. This serves as an excellent selling point when taking visitors and prospective clients through the plant.
* RFID technology has been implemented for better inventory tracking and production management.
* When servicing higher-end customers, added attention to these logistical details goes a long way. As Cardinali, explains, “When you deliver to some of these prestigious golf courses, they expect even the driver to look and act a certain way, so you can imagine how they’re going to react if something’s wrong with their order. This is where the ability to track that order throughout the production process to ensure timely and accurate delivery has been a real benefit. By tracking the order though the manufacturing process we can avoid any final delivery problems, or be supplied with enough time beforehand to make the necessary accommodations.”
Cardinali’s favorite story, however, doesn’t relate to any of these initiatives. Rather, he points to how an old piece of equipment exemplifies the new mindset these changes have inspired. In looking at the welding operations that were in place, E-Z-GO thought they would either have to invest significantly in a new robotic welder and related automation equipment, or investigate outsourcing frame production. Those working on the cell responded by re-organizing production flow themselves in order to better accommodate new product demands.
“The changes that were implemented on that cell, by those working here, have made our operating margins so much better,” explains Cardinali. “It just demonstrates how the people here have embraced what we’re trying to do, and they understand that they’re having an impact on our business’ long-term viability, and as a result, their own future.” And it’s not just those in the welding department. Cardinali points to how people are always asking questions, and have laid out or re-organized other cells as well.
It’s this mentality that fuels the “Passion For Premier– Greatness Starts With Me” program referenced throughout the E-Z-GO facility. “This keeps the customer and the goal to be “the” premier golf car and utility vehicle manufacturer– the very best at the center of all we do,” explains Kathy Searle, V.P. of Communications. “Passion For Premier program recognizes employees who exhibit the behaviors that will improve customer satisfaction and quality. It is all about providing our end customer with as high-quality a product as possible. Keeping the customer happy makes the company more profitable and creates a better place to work for everyone involved.”
“In addition to our employees, we’ve also had an upper management team that was very receptive to the changes that have been made,” adds Bowen. “Everyone involved knows and understands that this is a continuing process; we can always get better. Changes continue to be made weekly or even daily.”
Not only have employees taken notice of the changes, so have officials at its parent company. E-Z-GO won Textron’s Top Gun Six Sigma competition two years in a row, and continues to embed these Lean approaches into other areas of the company, such as accounting. Future goals also include winning the illustrious Shingo Prize for manufacturing excellence.
A New Opportunity
Although the continuous journey that is Six Sigma helped E-Z-GO realize tremendous improvements in safety, materials management, and labor costs, perhaps the biggest test came with the introduction of a new line. With the release of the RXV golf car, and the multi-million dollar production investment that accompanied it, E-Z-GO was faced with not only implementing all they had learned, but also adapting and overcoming the normal challenges that accompany a new production line.
Additionally, the RXV is positioned as a revolutionary product with enhanced suspension and motor control capabilities, so its assembly is much more technical in nature. This led Cardinali and his teams to spend more time in getting the right employees in place. The company has also invested significantly in Lean and Six Sigma training.
This line has been in operation since January 28 and embodies a number of lessons learned, with greater ergonomic cell considerations, and reversible and adjustable frame carriers that are identical to those used on Harley-Davidson motorcycles. All of this is housed in a facility that is bright, clean, and exhibits little wasted space.
Although the RXV production line has not been without its challenges, Bowen knows things will improve: “We're starting to see a pull versus push mentality here. The people are implementing these improvements themselves, and no stone is left unturned when it comes to ways of making things better.”
Perhaps the best way to summarize the turnaround comes from Holleran, when referencing a recent customer visit. He describes a client who, before selecting E-Z-GO, toured its facility, as well as those of its competitors. “Previously, we tried to deter people from visiting our production facility; now it’s a selling tool. Our operation, in many cases, is what seals the deal.”
|
| 05/15/2009 |
How do we win this game when the rules keep changing? - A Case for the Increased Application of Design for Six Sigma in Systems Engineering
Neal Mackertich, Ph.D, Raytheon Integrated Defense Systems & Dave Cleotelis, Raytheon Network Centric Systems
Abstract We all know the goal of the game: “Develop increasingly complex systems with smaller performance margins that meet the user’s requirements in the shortest time, with high reliability, open and adaptable, and at the lowest cost”. The environment we are working in continues to push Systems Engineering challenges to the next level. As Systems Engineers, we all want to win the game i.e. beat our competitors, satisfy our customers, develop unprecedented systems to address political and economic challenges. We have a proven process and a common set of tools, which we use and refine. Yet as we begin to participate in the game, we find that not only do we have huge challenges, but the rules keep changing. The customer/user requirements change, the conceptual design needs modification, the analysis reveals design challenges, and budgets are reallocated. So how do we win this game? This paper presents a case for the increased application of a suite of enablers, processes, and practices referred to as Design for Six Sigma at appropriate integration points during the Systems Engineering process lifecycle.
1. Introduction to the Game
Whether we practice Systems Engineering in the Aerospace, Automotive, Commercial, Automotive and Service Oriented industries, the game we play is the same. “Develop increasingly complex systems with smaller performance margins that meet the user’s requirements in the shortest time, with high reliability, open and adaptable, and at the lowest cost”. As Systems Engineers, we focus on the basics: define the requirements and architecture, develop the plan, design and analyze, and finally integrate, verify and validate. We all know that these are the basics and you have to follow the standard process or you can’t even be in the game. We have configuration management practices to assure that we manage changes along the way and do contract modifications and negotiations with the customer throughout the lifecycle
Our customers understand the process and adhere to it. However they naturally want to push on the boundaries of what is possible, desiring that capabilities are delivered to their users in the least amount of time and at the lowest cost. Companies and Systems Engineers that are good at managing their customers and providing data to support contract, specification, schedule, and cost negotiations usually win the game. Yet with increasing complexities, increased emphasis on mission assurance, aggressive cost reductions targets, shorter time to market requirements, ever-changing user needs, and our developed systems must be more become increasingly robust in order to keep us ahead in the game. And our process, our tools, our training, and our people must be adapting just as quickly, if not quicker, to the customer and user demands. We need enablers that we can insert into our existing process to address these challenges in our environment. This paper will present a suite of Design for Six Sigma practices and enablers that can be quickly inserted into the Systems Engineering process framework to enhance our ability to manage the changing rules and increase the chance of winning the game. The DFSS recommended practices are integrated throughout the paper to their Systems Engineering product development lifecycle points of insertion: Requirements Management, Architectural Evaluation, Systems Design & Analysis, Project Management, and Test Optimization. These recommended DFSS practices include: Quality Function Deployment (QFD), Architecture Tradeoff & Analysis Method (ATAM), Critical Parameter Management (CPM), Defect Predictive Modeling, Critical Chain Project Management (CCPM), Usage-based Statistical Modeling, and Combinatorial Design Methods (CDM).
2. Requirements Analysis
“Requirements Management is the identification, derivation, allocation, and control in a consistent, traceable, correlatable, verifiable manner of all the systems functions, interfaces, and verification methods that a system must meet including customer, derived (internal), and speciality engineering needs” (Stevens & Martin, 1995). This comprehensive Requirements Management definition, which is as good as, we have seen, highlights its integral degree of importance. Simply stated, no Systems Engineering project ends well if the Requirements process is not well managed. It is with good reason that Buede refers to Requirements as the “cornerstone of the Systems engineering process” (Dennis Buede, 2000). Without well defined requirements, the systems design problem is neither well understood nor well defined. Not only does our challenge of winning the Game rely on this, it is becoming increasing more difficult in these days of higher customer expectations and ever-changing customer needs and requirements. Good requirements always start with well understood customer needs and expectations. And this is precisely where Quality Function Deployment has proven itself to be highly effective.
Quality Function Deployment (QFD) is a well proven, systemic approach for more thoroughly understanding, prioritizing and correlating customer needs (the “whats”) with the system architecture / design approach (the “hows”). The still limited use of QFD in this decision space is quite surprising given what is at stake, its proven return on investment, and how relatively easy the approach is to utilize. The QFD approach is really quite simple and yet of illuminating. It all starts with asking the customer / user community / maintainers directly to prioritize / weight their needs / requirements. This in itself is often quite interesting since the first response is often; “they are all important”! But then after showing appreciation for this initial response, the customer will begin to share with you information regarding their requirements development thought space that most often was not well understood by the Systems Engineering team. In reality it is generally holds that there are a few high-level key requirement areas of the utmost concern that were rather precisely defined or thought through, and the remainder was estimated in order to provide general guidance (hint: some flexibility / trade space may exist). At times, we have found that some of the customers’ most important requirements are not stated in the formal documentation or stated differently. As with most aspects of a developed QFD matrix, the real gains are most often qualitative and not quantitative in nature. Next in a basic QFD analysis, comes the determination of which “hows” are to be correlated in their ability to deliver against these defined and weighted “whats”. Which hows is stated, since most QFDs use this opportunity to not only evaluate their predisposed design approach and look for performance / cost risks & opportunities, but rather to evaluate a series of architectural alternatives (see next section) and started to build hybrids / alternatives, and go from there. Some even choose to cross-link and correlate within the whats and hows for interdependencies as well benchmark their design approach against a competitors. Others choose to waterfall cascade their developed QFDs down from the Customer through Systems to Software and Hardware Engineering onto the manufacturing / supply chain process. All in all the number of cited positive case studies cited within industry from utilizing the QFD approach is very large. However, it is still oddly far from ingrained in the way we do business in Systems Engineering usually not for reasons of choice, but rather due to the lack of QFD awareness and available subject matter expertise.
3. Architectural Evaluation
There may be no greater leverage point for a System (and for winning the Game) than that of its architectural design. And while there is generally agreement on this, it is remarkable how often we rush through this all-important development phase, failing to generate and evaluate viable alternatives that could greater enable system robustness, reduce cost and improve upon its producibility. As nicely stated by Barry Boehm of USC: “Marry your architecture in haste and you can repent in leisure” (Barry Boehm, 2000). Paul Clements and his Carnegie Mellon team’s developed Architecture Tradeoff and Analysis Method (ATAM) and has proven itself to be highly effective in this regard both at Raytheon and across industry, enabling both our abilities to think more broadly in the generation of architectural alternatives and in our ability to evaluate these generated alternatives for their inherent risk and opportunities (Paul Clements, 2002).
What first drew us to the Architecture Tradeoff and Analysis Method was its stated intent to not only evaluate architectures against various requirement objectives but to also provide insight as to how that requirement objectives tradeoff against each other. This key distinction from other evaluation approaches is makes it a natural fit with Systems Architects and DFSS Masters as both think that way to begin with (or at least they should). The ATAM structured process is made up of nine steps which can be affinitized into four natural groups described by Clements as:
Presentation
- Present the ATAM. The evaluation leader describes the evaluation method to the assembled participants, tries to set their expectations, and answers questions that they may have.
- Present the business drivers. A project spokesperson describes what business goals are motivating the development effort and hence what will be the primary architectural drivers.
- Present the architecture. The architect describes the architecture, focusing on how it addresses the business drivers.
Investigation & Analysis
- Identify the architectural approaches. Architectural approaches are identified by the architect but are not analyzed.
- Generate the quality attribute utility tree. The quality attributes that comprise Systems “utility” (performance, availability, security, modifiability, usability and so on) are elicited, specified shown to the level of scenarios, annotated with stimuli with responses, and prioritized.
- Analyze the architectural approaches. Based upon the high-priority scenarios identified in the previous step, the architectural approaches that address those scenarios are elicited and analyzed. During this step: architectural risk, non-risks, sensitivity points, and tradeoff points are identified.
Testing
- Brainstorm and prioritize scenarios. A larger set of scenarios is elicited from the entire group of stakeholders. This set of scenarios is prioritized via a voting process involving all the stakeholders.
- Analyze the architectural approaches. This step reiterates the activities of Step 6 but uses the highly ranked scenarios from step 7. Those scenarios are considered to be test cases to confirm the analysis performed thus far. This analysis may uncover additional architectural approaches, risks, non-risks, sensitivity points, and tradeoff points, which are then documented.
Reporting
- Present the results. Based upon the information collected during the ATAM evaluation (approaches, scenarios, attribute-specific questions, the utility tree, non-risks, sensitivity points, tradeoffs), the ATAM team presents the findings to the assembled stakeholders
Results from the structured up-front use of the ATAM process at Raytheon have been encouraging. There is no better evident than that from your customer, and here’s a direct quote from a DoD customer: “The ATAM report represents a very good application of the ATAM, given the relative newness of the methodology and without assistance from ATAM expertise. Many new risks were identified and documented and many more existing risks in the risk register were corroborated as a result. A variety of scenarios and threads were generated during the ATAM and over 130 sensitivity points were identified and mapped to risks. As a result of the ATAM tradeoff and sensitivity analyses, (there were) nine identified significant findings.” Raytheon has also achieved noteworthy results from the use of complementary approaches supporting architectural evaluation ranging from the modified deployment of the “IDEO” innovation process to those using a modified Design Failure Modes Effects Analysis (DFMEA) for architecture.
4. System Design & Analysis
At the heart of our Systems Design & Analysis effort is our intent to optimize the system relative to its performance, cost and producibility. This is typically what often motivates Systems Engineers to become Systems Engineers in the first place, to model and analyze a set of system needs and optimize the whole, not a part, but the whole system. Early returns from an emerging DFSS practice, called Critical Parameter Management, has been proving itself to be of great utility (both here at Raytheon and across the industry) in the enablement of systems optimization. Critical Parameter Management (CPM) is a disciplined methodology for managing, analyzing and reporting program technical product performance. In this vernacular, program “Critical Parameters” include the set of contractual specified technical parameters (often called out as a Technical Performance Measure or TPMs) plus any other identified critical technical system parameters. (So CPM = TPM + X identified additional technical system parameters.). Using the CPM methodology, a hierarchy of technical requirements are flowed down. Sometimes it is easiest to think of this in terms of analogies: the use of CPM does for technical parameter requirements and its developed mathematical interdependencies (described in terms of transfer functions), what DOORS and other requirements management tools do for systems requirements and their developed qualitative interdependencies. Building and interconnecting the technical parameter hierarchy, benefits are gained on many fronts not only from a systems optimization perspective but also from the perspective of creating a collaborative design environment and with regards to future design reusability.
From a systems optimization perspective this is a dream- as the models / transfer functions are developed, engineers up and down the hierarchy can more directly understand and analysis how their inputs are statistically impacting system parameter responses. Developed margins and the performance / cost trade space can be explored in terms of sensitivity analysis.
From a collaboration perspective, the use of CPM has provided our engineers (particularly those downstream) with far more visibility and understanding regarding Systems behavior, the roles of others on the job and of course into our technical performance design space. Also, as our Systems have become more complex, so has our workforce become more geographically distributed. Accordingly, the use of our real-time CPM system is already showing promise as a collaborative environment for distributed technical exchange well beyond what tools like eroom are capable of providing for us.
From a technical reuse perspective, there also some opportunities for exploration down the road. We expect our developed technical trees, transfer functions and analyses from one program to be of terrific value / reuse for next generation and related program use efforts. Additionally, we expect our developed technical hierarchies to be of usefulness in the sparking of technical debate and discussion between our various developed Communities of Practice networks.
5. Project Management
As our Systems become increasingly more complex and our workforce more distributed (and virtual), successfully managing Systems Engineering projects against performance, cost and schedule requirements is becoming more and more of a challenge. DFSS approaches that have been proven to enable Systems Project Management include that of Predictive Defect Modeling and Critical Chain Project Management.
Most mature Systems Engineering organizations collect and produce Defect Containment charts across the various phases of their Systems Engineering development lifecycle. They are motivated to do so either through their involvement with CMMI and / or in through their desires to see how well they are able to discover their defects within phase. Unfortunately, these developed Defect Containment charts often only represent “lagging” indications of how well the Systems Engineering project team is discovering defects and containing them within phase. The key question that typically is unfortunately not addressed is: “how well are we doing against our expectation?” The answer to this question can only be answered through the use of predictive models and developed statistical confidence intervals. The concept behind Predictive Defect Modeling is for an organization to build probabilistic defect models based on historically collected information for different domain product types / environments. Once these models are developed, confidence intervals can be easily established for each square within the Defect Containment Chart from which the Systems Engineering project team can measure themselves. Similarly this concept can be applied to each individual Systems Engineering Requirements or Design Review. For example, given the domain product type and number of requirements to be reviewed from our predictive models we would expect a discovery of between 12 and 24 defects to fall within our plus or minus three sigma limits. If our review discovers a number outside of that statistically expected range, then it is warranted for us to examine the process to see if there is some action that is warranted (this is not an inquisition). If we were on the low side for our number of expected defects, perhaps our review process wasn’t as robust as usual and we should re-review. If we were on the high side for our number of expected defects, perhaps this product is either more technically complex that we expected or our lead in this area may need some help. The key point here is that we are alerted that something statistically unexpected has occurred and that we may want to take some kind of action to preclude future potential issues from arising. Raytheon has been successfully applying this real-time decision-making approach within Software Engineering for several years and is presently making strong headway within Systems Engineering.
There may be no more daunting challenge than that of schedule pressure. Countless job are falling under the category of “yes we can do it, but not with that schedule”! Critical Chain Project Management is a highly effective, multi-project management philosophy and methodology which focuses on the cycle time optimization of the system (Eli Goldratt, 1997). It is based on Goldratt’s Theory of Constraints, a set of management principles that both identifies barriers to the achievement of objective and implements solution to overcome them. Critical Chain Project Management challenges the assumptions behind current practices we use in identifying and managing the inherent uncertainty in our product development plans, replacing them with a leaner, more easily executed approach. This is accomplished through the use of schedule / resource constraint identification, prioritization and escalation coupled with the strategic use of management buffers to account for project uncertainty and variability. Results from Critical Chain Project Management implementations have been encouraging within Raytheon and across industry with significant cycle time and / or schedule risks reductions cited.
6. Test Optimization
The validation that indeed our system is achieving its intended mission is of course also of critical importance. The Game is simply not over until our Systems are achieving their Mission. Enablers in this regard are the use of the Usage-based Modeling and Combinatorial Design Methods test optimization strategies in the development of system and subsystem test cases. Both methods have been cited as industry best practices by the Department of Defense and the National Academy of Sciences.
The modeling of Use Cases is of course nothing new in the realm of Systems Engineering. What is remarkable is how very rarely the developed Usage models are utilized in the development of System test cases. Given the complexities of modern developed systems, the testing of all possible scenarios quickly becomes infeasible. Under this typical scenario, the decision is then not just about how should we test but also about what should we test. The most common approach for dealing with this challenge is to think of the problem from purely a domain expertise perspective. If we are building a Radar, our Radar experts and Radar test experts will think about the technology involved and what they and our customer’s requirements state they would like to see demonstrated. The results of which are typically shall based one-at-a-time testing of different scenarios independent of whether or not this scenario is either statistically likely or of high criticality. The integrated use of Usage-based probabilistic models with that of the all important domain expertise has been shown to both improve upon our up-front understanding of requirements as well as through gained System test efficiencies and effectiveness. One Raytheon project employing this Usage-based model approach throughout the lifecycle, has been able to demonstrate a 50 reduction in test associated costs while significantly improving (4x) upon its previously experienced quality levels during System certification testing. While most deployment results have not been as remarkable, opportunity gains of 20+ are typical targeted and achieved.
It all starts with the developed Systems Mission Profile (often referred to as a state diagram) with estimated transition probabilities shown as arcs between the states (this is nothing more than a Markov Chain). Our experiences have shown that the development of this state diagram and the co-estimation of these probabilities with the End User itself to be of high value during Requirements Management phase as it brings further dialogue on perhaps the most important aspect of any system: what is to be its intended use. Next this developed model is used as a simulator for generating likely combinatorial paths and their relative frequency of occurrence. Here at Raytheon we typically run a thousand to ten thousand runs for starting point A to ending point B and calculate the percentage of each unique path that has occurred. Based on this Pareto listing, we now have a handle on what paths are likely to be explored during system use. And do not forget that we can always add to our listing any critical but statistically unlikely paths. While to some the degree the effectiveness of this approach is directly related to how good a representation our model is (isn’t that always the case?), this approach has proven itself to clearly superior to typically one-at-a-time shall based test plan generation.
A second statistically-based best practice has emerged with the motivation to marry up domain expertise with that of statistical methods in order to best cover the test space at minimum cost. This technique, typically referred to as Combinatorial Design Methods although (it has a number of aliases such as that of “High Throughput Testing”), has proven itself to be of great utility primarily in the subsystem and regression resting arenas. The concept here, as before, is that we can’t feasibly test all combinations, so let’s use our statistical training in concert with our domain expertise. Combinatorial Design Methods in essence could be retitled n-way testing as that is what is mathematically happening. Examples of its effective application abound within industry (including Raytheon) and typical results have shown similar 20%+ reductions in test costs and cycle times while as effectively covering the test space. A word of caution must be expressed here as the purpose of Combinatorial Design Methods is to provide balanced test coverage across a test space at minimal cost not as a method to justify the reduction of tests based on mathematics. In essence don’t go to the other extreme and now subordinate your involvement of domain expertise and Use Case models to that of statistical combinatorials in your test case planning- they must remain partners in your test solution development.
7. Summary
As previously stated, we all know the goal of the game: “develop increasingly complex systems with smaller performance margins that meet the user’s requirements in the shortest time, with high reliability, open and adaptable, and at the lowest cost”. Accordingly, we need enablers that we can insert into our existing process to address these challenges in our environment. The primary purpose behind this paper has been to provide increased motivation for the integrated application of proven DFSS enablers in Systems Engineering. Our approach for accomplishing this has been to provide the readers with both an increased exposure to proven DFSS enablers and the context for most effectively integrating them during the product development lifecycle. Since our purpose is to improve our deployed Systems Engineering capabilities and not prove out DFSS, what does success look like? Our Systems Engineering Leadership team has been examining this and has defined the following DFSS enabled attributes of a high-performing Systems Engineering organization:
- Voice of the Customer modeling and analysis an part of the Requirements analysis process
- Up-front Architectural trade space evaluation (vs. validation)
- Statistical modeling & optimization of the performance / cost system design trade space
* Utilizing a mathematically linked, collaborative environment for managing and performing Systems design TPM sensitivity analysis
* With CAIV strategically deployed up-front as standard program practice for product lifecycle cost management
- Enabled decision-making through predictive defect modeling
- Stochastically modeled System Integration, Verification & Validation
The motivation and enablers for each of these attributes was developed during the course of this paper. Our Systems Engineering organization has successfully achieved significant results in each of these areas but that in of itself is a different statement than saying that these enablers are being employed as standard practice. Towards this end, each Systems Engineering Department (typically employing around 150 Systems Engineers) within the Raytheon Integrated Defense Systems and Network Centric Systems businesses have developed a plan for more effectively integrating these enablers as standard Systems Engineering practices. Their progress against their developed plans has been captured as a key goal measurable as a core part of our performance review process.
With enabling Systems Engineering and further program integration being our goal, we have also developed a set of DFSS Input – Output process diagrams for the various gated activities within our enterprise-wide Integrated Product Development System. The purpose of such framings is to provide additional details as to how DFSS enablers play and integrate in with our standard Systems Engineering practices. We did this at first with some hesitation as long-term we would like for only a set of Systems Engineering process diagrams to exist, but in the short-term until full integration occurs, the use of these diagrams has been helping further develop our organizational thinking relative to DFSS integration within Systems Engineering processes. To date, we have developed these high-level process diagrams for the DFSS Planning activity during pre-gate 5 (contract award), DFSS in Requirements & Architectural Development (Gate 5 to Gate 6), DFSS in Preliminary Design (Gate 6 to Gate 7), DFSS in Critical Design (Gate 7 to 8), and DFSS in Integration, Verification & Validation (Gate 8 to Gate 9).
8. Bibliography
Blanchard, Benjamin, Systems Engineering and Analysis, Prentice Hall, 1998.
Buede, Dennis, The Engineering Design of Systems, Wiley, 2000.
Boehm, Barry, The 15th Annual Software Engineering Symposium, 2000.
Carnegie Mellon University, The Capability Maturity Model, Addison Wesley, 1995.
Clements, Paul, Evaluating Software Architectures, Addison Wesley, 2002.
Creveling, Clyde, Design for Six Sigma, Prentice Hall, 2003.
Dalal, Siddhartha, Innovations in Software Engineering for Defense Systems, The National Academies Press, 2003.
Fowler, M. and Highsmith, J., The Agile Manifesto in Software Development, August 2001.
Fowlkes, William, Engineering Methods for Robust Product Design, Addison Wesley, 1995.
Goldratt, Eli, Critical Chain, North River Press, 1997.
Humpreys, Watts, Managing the Software Process, Addison Wesley, 1989.
Judd, Thomas, Program Level Design for Six Sigma, Cognition Corporation website posted white paper, 2005.
Kelley, Tom, The Art of Innovation, Doubleday, 2001.
Khuri, Andre, Response Surfaces, Dekker, 1996.
Stevens, R, and Martin J., What is Requirements Management? In Systems Engineering in the Global Market Place Vol. 2, C. Kirkpatrick and C. Wilke (eds.), 5th Annual International Symposium of INCOSE, 11-32, 1995.
Prowell, Stacy, Cleanroom Software Engineering, Addison Wesley, 1999.
9. Biography
Dr. Neal Mackertich is an Engineering Fellow and founder of the Raytheon Six Sigma Institute. A Six Sigma Master Expert versatile in technical background and application experience, Neal is presently responsible for the Systems Engineering enablement of Mission Assurance through product and process optimization strategies (including DFSS) within Raytheon’s Integrated Defense Systems business.
David Cleotelis is a Certified Six Sigma Expert/Black Belt and an Engineering Manager for the Network Centric Business area of Raytheon. David is a Systems Engineer with a diverse background in Secure Voice & Data, Communications, Networking, Intelligence Systems, and Space Systems. He has held management positions responsible for System Requirements, Design, Architecture, Platform Integration, and Integration, Verification, and Validation. David is a Certified Six Sigma Expert (Black Belt), working projects across all Engineering disciplines, business development, and manufacturing. Additionally, he is a DFSS Champion responsible for deployment of DFSS in the Florida region for Raytheon. He has been Chapter President for the Central Florida Chapter multiple years and is the technical chair for the 2006 INCOSE International Symposium. |
| 05/14/2009 |
Tough Economic Times Call for Lean Six Sigma - Investing in quality in a slow economy
Source: http://www.qualitydigest.com/inside/six-sigma-article/tough-economic-times-call-lean-six-sigma.html
Criteria changes and lean Six Sigma
In these difficult economic times, organizations are looking at all possible means to operate profitably. As demand for products and services drops and customers expect the lowest possible price, organizations are feeling urgent pressure to cut costs as a response to lower revenues and decreased margins.
However, many companies are missing the mark by cutting resources indiscriminately when they should be revamping their business processes to achieve improved, sustainable business results.
Many businesses react to such pressure by going into panic mode. Cost-cutting targets—often in proportion to the budget or staff headcount—are handed down from senior management to various departments. With across-the-board cost cutting comes the risk of throwing out the good along with the bad. In the rush to cut back, there’s always the danger that an “anything goes” mentality may prevail, with little focus on determining what adds value to customers and what can be considered waste.
Organizations engaging in this practice inevitably find themselves in a downward spiral. By not paying careful attention to and investing in the value-adding components of their business, these organizations cannot differentiate themselves from the competition to stand out during challenging times when it’s the most critical. More than ever, customers are looking for value. Organizations unable to demonstrate a unique value in a tough economy fall out of favor, invariably responding with more cost cutting, leading to a decimated internal structure lacking the necessary resources to support core processes.
This directly affects the ability to satisfy customer expectations. In a growing economy, imprecise decision making—or even outright mistakes—can be forgiven. Often in prosperous times, companies end up with superfluous processes, created in reaction to immediate needs. In a shrinking economy, however, there is no room for error or redundancy. Cost cutting is effective only when focused on areas of waste. A paring knife is more valuable than an ax; organizations need to streamline costs yet still provide optimal value through exceptional product or service quality.
Investing in process improvement while cutting costs may appear counterintuitive. However, by understanding how the processes work to produce the desired output, organizations can pare back in a manner that ensures the quality of the output and continues to meet customer needs. In fact, a well-designed and well-implemented improvement effort will identify nonvalue-added activities that can be eliminated, thereby saving money while positively affecting customers. In contrast, a rash effort to cut costs without an understanding of the effect on processes will most likely end up disappointing customers and further deflating revenue.
In tough economic times, business leaders must understand that although eliminating resources to reduce costs may result in short-term gains, it will prove detrimental in the long run. Improving organizational processes is the sustainable way to reduce costs and maintain quality.
But how can organizations improve their processes with the urgency required to face the challenges of a financial downturn?
Consider the following:
1. Identify the critical organizational processes that provide the greatest value to customers.
2. Define (or redefine) the needs and wants of your customers and adjust your offerings accordingly.
3. Understand how your processes work and identify the critical variables that transform inputs into outputs (e.g., people, hardware, software, material, the environment).
4. Establish/review criteria for the operation of these processes (e.g., process performance metrics related to process outputs and critical variables).
5. Use lean tools to quickly and aggressively eliminate waste in these processes.
6. Follow up with Six Sigma tools to minimize process variation and improve the accuracy and precision of your processes.
7. Focus on relentlessly improving value drivers to ensure that they consistently provide the highest quality.
The list above is at the core of good process management and includes the application of lean Six Sigma methodologies to achieve measurable, sustainable process improvement.
Successful, profitable organizations adhere to these guidelines judiciously. In poor economic times, it’s especially important to follow these steps effectively and exigently.
This requires leadership determination and organizational commitment to the correct application of lean Six Sigma, which like any other methodology, is only effective when its tools are applied within a holistic approach to process management.
In closing, cutting costs during an economic downturn for the sake of reducing expenses won’t ensure what Peter Drucker called “the first priority of business: To avoid loss." Rather, organizations should manage their processes with the goal of improved, sustainable business results.
Lean Six Sigma has accomplished this for many successful enterprises.
For more information visit www.orielinc.com
About The Authors
Ernani Pires is president of Oriel Inc., a SAM Group company. He has more than 35 years of experience in corporatewide business management, including manufacturing and service environments, and extensive experience in total quality management, quality assurance, quality control, testing and inspection, auditing, and supplier performance. He is a certified Six Sigma Master Black Belt.
Rohit Ramaswamy, Ph.D., has been involved in the design/redesign, management, and improvement of services for more than 12 years. In addition to extensive work with call centers, customer support, and sales; his experience includes supporting marketing and operations organizations with customer needs analyses and innovative service concept designs. He also works with cross-organizational design teams to develop and implement strategic service designs, often involving the joint redesign of processes, systems, and organizations. |
|
|
