DOC

Designing Service Quality for Lean Six Sigma

By Sylvia Marshall,2014-06-19 18:52
11 views 0
Designing Service Quality for Lean Six Sigma

     1

    SOFTWARE DEVELOPMENT PROCESS DESIGN BY USING AN

    INTEGRATED DESIGN FOR LEAN SIX SIGMA APPROACH

    Che-Ming Chang,

    Department of Business Administration,

    Minghsin University of Science and Technology,

    No. 1, Xinxing Road, Xinfeng Shiang, Hsinchu County 30401, Taiwan, R.O.C.

    benchang@must.edu.tw

    ABSTRACT

    A well-designed software development process is a key to developing high-quality software systems in a fast manner. To achieve a superior software quality level to the competitors, Design for Six Sigma (DFSS), which has evolved from Six Sigma as a breakthrough strategy for product and/or service development process design, is fit for filling the need. Meanwhile, a faster time-to-market capability of software development can be obtained through utilizing the speed advantage of Lean Production (Lean). Therefore, it is the motivation of this paper for researching that DFSS when combined with Lean can be synergistic in the upfront design phases of the software development process. In addition, a methodology that integrates the individual benefits of DFSS and Lean was developed, and an empirical case study was conducted to examine the effectiveness of the methodology.

    Keyword: Software Development Process, Design for Six Sigma, DFSS, Lean Production, Lean.

     2

    INTRODUCTION

    Many software organizations have trouble in delivering high-quality software in a fashion of faster time-to-market than their competitors, and one of the reasons for causing this problem is due to a lack of a better software development process, a coherent set of activities for software production (Sommerville, 2007). Recently, two popular process-oriented quality programs, Design for Six Sigma (DFSS) and Lean Production (Lean), have been applied individually to a variety of non-manufacturing industries though they were both rooted in the manufacturing arena (Su et al., 2006). Therefore, to obtain excellent software development processes, this paper aims at developing an integrated approach which can be synergistic by combining DFSS with Lean, and applying it to the design of software development process.

    Since its inception in 1987 at Motorola, the world has witnessed the enthusiasm for pursuing Six Sigma initiative for quality improvement. Many leading companies such as General Electric (GE) have achieved operational excellence through successful Six Sigma implementations. However, its incremental improvements alone sometimes do not allow an organization to keep up with the rapid pace of changes in the areas of technology, customer demands, and competition (Pande et al., 2000). That is why DFSS has treaded in Six Sigmas steps as a breakthrough strategy for developing

    high-quality products and/or services. The major objective of DFSS, when applied to the software project in particular, is to design processes for developing software that achieve the Six Sigma quality level.

    In addition, most software organizations have also perceived faster delivery of their software products as one of the key factors for gaining competitiveness in the market. To sustain the speed advantage, recently some researchers and practitioners have adopted the concepts and practices of Lean to improve the cycle time of the product and/or service delivery process (George, 2003). Specifically, the objective of Lean is to rapidly respond to changing customer demands and to create more value at a lower cost through implementing a systematic five-step methodology (Womack, 2004). Although it was originally developed for product manufacturing, the advantages of Lean when applied to the design of software development process can ensure accelerating the development of new software.

    The germination of the idea about combining DFSS with Lean for software development process design is derived from a literature review of publications by Nave (2002) and McAdam and Evans (2004), which highlighted there are some

     3

    complementary benefits between Lean and Six Sigma. In view of the significant growth of the software industry in todays global economy, this paper focuses on the

    development of an integrated methodology that combines the strengths of DFSS and Lean for enhancing software development process design. In addition, the rationale for the integration of the two methods was examined and used to justify the means. Finally, an empirical case study was conducted to illustrate the deployment process and to investigate the effectiveness of the methodology developed in this research.

    DFSS

    DFSS is a rigorous approach to designing products and/or services from the very beginning of the development cycle to ensure that meet customer expectations (Harry and Schroeder, 2000). As a complement to Six Sigmas improvement methodology,

    DFSS integrates the characteristics of Six Sigma at the outset of the product and/or service development process with a disciplined set of tools to achieve Six Sigma performance (Brue and Launsby, 2003). However, unlike the DMAIC methodology of Six Sigma, the phases or steps of DFSS are not universally recognized or defined. In fact, many deploying companies of the Six Sigma philosophy have devised their in-house views of DFSS such that there are different labels of acronyms of DFSS methodology as shown in TABLE 1 (Simon, 2002). The best strategy an organization can take is to understand the critical elements contained within each version of DFSS methodology, and then customize it to fit the organizational culture (Verduyn, 2002).

    TABLE 1 Some different versions of DFSS methodology

    Methodology Definition

    DMADV Define, Measure, Analyze, Design, Verify

    IDOV Identify, Design, Optimize, Validate

    ICOV Identify, Characterize, Optimize, Verify

    DMEDI Define, Measure, Explore, Develop, Implement

    DCCDI Define, Customer, Concept, Design, Implement

    Despite the different versions of DFSS methodology, each one basically uses the same advanced design and production development tools and generates the same deliverables in the underlying phases (Kleinert, 2004). In this paper, DMADV is selected as the fundamental structure to develop an integrated methodology for software development process design. The reason for this selection is that DMADV has been a proven and well-established DFSS methodology used among many industries. The framework of DMADV methodology is further depicted in FIGURE 1

     4

    a(Anonymous, 2005).

    FIGURE 1 The framework of DMADV methodology

    DMADV

     Verify the Design the Measure and design Analyze the Define the the process to determine performance process options project goals meet the customer and ability to to meet the and customers customer needs and meet customer customer needs needs specifications needs

    Design Verify Define Measure Analyze

    KEY DELIVERABLES

    ? Charter ? CTQs ? Concept ? Detailed ? Prototype Design and Process Selection Design

    KEY TOOLS

    ? Kano/survey ? QFD ? TRIZ ? FMEA ? FMEA ? Project ? FMEA screening ? Brainstorming ? SPC ? SPC management ? Pareto analysis ? Simulation ? Simulation ? Control plan tools ? Benchmarking ? Risk analysis ? Project selection ? Pugh concept selection

    LEAN ? SIPOC ? Gap Analysis ?Machine design ?Control plan

Initially, the publication of the book, The Machine that Changed the World: the Story

    of Lean Production (Womack et al., 1990) started the diffusion of some Lean production practices developed by the most competitive automobile manufacturers in the world (Sanchez and Perez, 2001). Thereafter, Lean production was studied in other industries, for example, the service sector (Moore and Gibbons, 1997). Some scholars have even suggested that rapid change industries have adopted Lean production versus mass production as a growth paradigm (Duguay et al., 1997).

    The Lean methodology consists of a five-step thought process, which was developed by Womack and Jones (1996), to guide organizations through a lean transformation. These steps are:

Step 1: Value

    Define value from the perspective of the final customer. Express value in terms of a specific product or service which meets the customers needs.

     5

    Step 2: Map

    Identify the value stream, the set of all specific actions required to bring a specific product through the three critical management tasks: the problem-solving task, the information management task, and the physical transformation task. Create a map of the initial state and the future state of the value stream. Identify and categorize any waste in the initial state, and eliminate it.

Step 3: Flow

    Incorporate the remaining steps to streamline the value stream. Eliminate functional barriers, reduce interruptions, and develop a process-focused organization that dramatically improves lead time.

Step 4: Pull

    When flow is introduced, the ability to design, schedule, and make exactly what the customer wants just when the customer wants it, is established. In other words, let the customer pull products on an as needed basis rather than push products, often unwanted, onto the customer.

Step 5: Perfection

    There is no end to the process of reducing effort, time, space, cost, or mistakes. Return to the first step and begin the next lean transformation process, offering a product or service which is closer to what the customer really wants.

    THE RATIONALE FOR THE COMBINATION OF DFSS AND LEAN

    To demonstrate the rationale in support of the combination of DFSS and Lean, Smith (2001) offered a more comprehensive view on this subject through the framework as shown in FIGURE 2. He attempted to locate each discipline in a two-dimensional array, one related to Suhs (1990) model for domains of designs, and the other one

    related to reality perception according to Senges (1990) model of Systemic Thinking.

    The Suhs model emphasizes a mapping between various domains from customer attributes to functional requirements to design parameters to process variables. On the other hand, the Senges model distinguishes the levels of thinking in terms of events, patterns, or structure.

     6

    FIGURE 2 A comprehensive view on the combination of DFSS and Lean

    Process Physical Customer Functional domain domain domain domain

    Axiomatic Axiomatic design design TRIZ Structure Lean directed evolutionTRIZ TRIZ

    FMEA VA/VE DFM Parameter Systems SPC Patterns QFD and Engineering tolerance DFA design

    Warranty Inspection Verification and and scrap/ tests customer rework Events complaints

    Design for

    Six Sigma Six Sigma

    By examining the combined model, it helps justify the appropriateness of integrating DFSS and Lean. First, compared with Six Sigmas focus on problem solving at the

    event level of thinking, DFSS is used to prevent problems by building quality into the design process across domains at the pattern level of thinking. Since up to 80 percent of the total cost of the product and/or service is accrued in the upfront design phases (Fredriksson, 1994), more and more organizations have their focus transitions from Six Sigma to DFSS.

Next, Lean is identified at the structure level in Senges model. Thinking at a level of

    fundamental structure offers even higher leveraged opportunities to create products and/or services that not only function as intended, but also deliver unprecedented customer satisfaction. When the foundational structure of design is properly established, the methods at the pattern level are much more effective. When pattern level methods work well, the event outcomes become world-class (Smith, 2001).

    DEVELOPING AN INTEGRATED METHODOLOGY

    Now that the rationale for blending DFSS and Lean to create synergy has been demonstrated, the next step is to develop an integrated methodology that is applicable for software development process design. A conceptual framework of the integrated methodology is delineated in FIGURE 3, and following that the descriptions of each

     7

    step in the methodology are given in further detail.

FIGURE 3 A conceptual framework of the integrated methodology for software

    development process design

    Define Measure Analyze Design Verify

    ? Draft a project charter ? Identify voices of customers (VOCs) ? Translate the VOCs into measurable requirements/ ? Prioritize the CTQs critical-to-quality and establish characteristics performance ?(CTQs) Develop conceptual metrics process design ? Determine the alternatives (apply specification levels TRIZ technique) for the performance ? Construct metrics initial-state value stream maps ? Evaluate the process design alternatives and select the best ? Develop a one detailed ? Construct a future- process state value stream design map map ? Pilot test and ? Identify and refiningremove ? Develop and unnecessary implement process loops process control or steps plans ? Document and transition

    Value Flow & Pull Perfection Map

Phase I: Define

Step 1: Draft a project charter.

    The primary deliverables in the establishment of a project charter include the

    following items (Pyzdek, 2003):

    ; Business case

    ; Project goals and objectives

    ; Milestones

    ; Project scope, constraints, and assumptions ; Team memberships

    ; Roles and responsibilities

    ; Preliminary project plan

     8

    Step 2: Identify the voices of the customers (VOCs).

    In this step, both external and internal customers are fully identified, and their needs that are valued by either of them are collected and analyzed. Some commonly used tools such as surveys, focus groups, interviews, or market research can be exploited to perform this task (Pande et al., 2000).

    Step 3: Translate the VOCs into measurable requirements/critical-to-quality characteristics (CTQs).

    Each of the VOCs is then translated into a measurable requirement because the VOCs could be disorganized, nonspecific, or qualitative in nature. In addition, all of the translated measurable requirements then become the CTQs that must be satisfied by the design solution. Using the quality function deployment (QFD) method (Mizuno and Akao, 1994), this transformation of the critical customer needs into measurable terms/CTQs can be accomplished.

Phase II: Measure

Step 1: Prioritize the CTQs and establish performance metrics.

    The CTQs identified in the last step are further prioritized through the employment of QFD again. Then, applying Pareto analysis (Juran, 1979), the performance metrics are established to measure the performance of the new process design.

Step 2: Determine the specification levels for the performance metrics.

    This step is to set the goals for achieving the desired or acceptable levels of the design performance for both customers and employees. The task can be performed along with conducting surveys among the customers and employees, or using benchmarking and competitive analysis within the industry.

Phase III: Analyze

Step 1: Develop conceptual process design alternatives.

    Based on the performance metrics established earlier, this step proceeds to generate several conceptual process design options that can deliver the design requirements of the performance metrics. For this purpose, TRIZ technique can be applied to creating innovative design concepts particularly when the existing technology or the known process design cannot fulfill all the design requirements satisfactorily.

     9

    Step 2: Construct an initial-state value stream map for each process design alternative.

    An initial-state value stream map is utilized to identify the non-value-added activities in the process design alternatives that need to be eliminated, if unnecessary, and to present the opportunities for improvement. By taking advantage of the Lean principles, the non-value-added process activities can be identified and eliminated.

Step 3: Evaluate the process design alternatives and select the best one.

    Several process design alternatives and initial-state value stream maps might be generated in the last two steps, and they need to be evaluated to make a final determination on which process design concept will be selected.

    Step 4: Construct a future-state value stream map for the selected process design alternative.

    A future-state value stream map exploits the opportunities for improvement identified in the initial-state map to achieve a higher level of performance. This means once the unnecessary non-value-added activities are eliminated, the remaining activities can be re-sequenced to further enhance the value delivery by the new process flow.

Phase IV: Design

Step 1: Develop a detailed process design map.

    bSome limitations exist in value stream mapping (VSM) process (Anonymous, 2004).

    For example, VSM does not begin to capture all specific actions, and it is a technical tool that lacks the capability to address non-technical and/or human issues. On the other hand, a detailed process design map can help identify the unnecessary loops or steps in the overall process design which may not be discovered in the value stream maps.

    Step 2: Identify and remove the unnecessary loops or steps in the detailed process design map.

    Identify the unnecessary process loops or steps in the detailed process design map, if any, and then remove them from the overall process design in order to eliminate the waste in Lean terminology.

Phase V: Verify

Step 1: Conduct pilot test and refining.

     10

    Prior to launching the new design of software development process, a pilot and small-scale implementation can be used to test and evaluate real-life performance.

Step 2: Develop and implement control plans.

    Control plans need to be developed and implemented to make sure the new process design endures, and control must occur at both the strategic and tactical levels.

Step 3: Document and transition.

    As the new process design is validated and process control is established, the full-scale commercial rollout can be started, and the new design, together with the supporting processes, can be handed over to design and process owners, complete with requirement settings, and control and monitoring systems.

    CASE STUDY

Background of the case

    The specific case studied in this research is a practical project that the authors had been involved in designing the software development processes of a software house with its headquarters located in Taipei, Taiwan. Today, the company is operating the business in more than twenty countries across the regions of Asia Pacific, South Asia, and North America. To compete in the market, the strategic focus of the company is on the sector of small and medium-sized enterprises (SMEs), and currently there is a total of over 35,000 SMEs, which constitute its major customer base.

    Since established in 1998, the company has grown up rapidly in its business while at the same time experiencing some operational challenges from the competitors. The key issue that the company was facing and had to resolve is to continue providing customers with high-quality, price-competitive software applications and related services in a timely fashion in order to compete in the market. However, the processes for software development before the project implementation obviously could not keep up with the pace of the considerable changes in customer demands. Therefore, a major thrust for the company to rebuild the software development processes is to reflect such an issue as specified.

    Designing software development processes by implementing the methodology

    In early 2004, the company started the nine-month project case, and the methodology

Report this document

For any questions or suggestions please email
cust-service@docsford.com