Implementing the Design for Lean Six Sigma methodology …

In early 2004, the company started the nine-month project case, and the methodology proposed in this paper was followed through by the project team. The specific steps of the project implementation are described in detail as follows.

Phase I: Define

Step 1: First of all, a project charter is established at the outset of the project

implementation. Once the prerequisite such as project goals, scope, and necessary resources are clearly defined, the subsequent steps then can be followed to proceed. For example, the company has set the project goals as follows.

y To achieve a 15 percent market share of e-business solutions in the Asia market by the end of the year 2005;

y To obtain a 25 percent growth rate of total revenue in 2005; and y To sustain at least 30 percent overall profit margin in 2005.

Step 2: Secondly, two surveys are conducted separately to identify what the

customer really wants. One of the surveys has a total of 196 effective responses out of the 225 external customers that are randomly selected from the existing client base. The other one survey includes 72, in total, effective responses out of the 76 internal customers that are picked up from the corporate employees. The VOCs are gathered and summarized as shown in Tables 4.14 and 4.15. For the simplicity of this project research, the VOCs are selected and defined as those items in the surveys with a given priority level of high or extreme importance by one or more of the respondents.

Table 4.14 Summary of the VOCs in the external customer survey for the software

development process

VOCs Frequency* Percentage

Customizable software systems 182 93

Quick order delivery 173 88

Consistent schedule for order delivery 152 78

Compatible with other operating systems or software

applications 112 57

User friendly system interface 98 50

Easy system setup, installation, and maintenance 79 40

Providing on-site customer support 56 29

Low cost for version upgrade 35 18

Reasonable charge for technical support 27 14

Downloadable service pack for system defects 22 11 Online interactive system help menu 9 5

*

The frequency was accumulated by counting the number of those responses which gave the priority level of at least 4 to each specific item in the VOCs (1=not important; 2=low importance; 3=important; 4=high importance;

5=extremely important).

Table 4.15 Summary of the VOCs in the internal employee survey for the software

development process

VOCs Frequency* Percentage

Shortened software development cycle 68 94

Faster make-or-buy decision making processes 59 82 Effective and timely communications within the supply

chain

53 74

Improved collaborative models for the software

development teams located in different countries 47 65 Integrated customer relationships management (CRM)

systems for handling customer services 38 53

Easy to access and maintain the source codes of the

software developed by different teams 24 33

To be an Asia market leader in e-business solutions 19 26 Stabilized staffing plan during the implementation of a

development project 6 8

*

Step 3: A simple affinity diagram can be used to categorize the VOCs identified

in the last step based on the five dimensions of service quality. The completed affinity diagram for the categorization of the VOCs is shown in Figure 4.10. It is noted that all of the items in the VOCs are eligible to be categorized into a specific dimension of the service quality. Thus, all of the identified VOCs should be taken into account as the factors that would affect the service quality level. In addition, to prioritize the VOCs, the percentage orders shown in Tables 4.14 and 4.15 are adopted to serve the purpose. In other words, the larger the percentage is, the higher the priority level is given.

Responsiveness

Easy to access and maintain

market leader in e-business service pack for

system defects within the supply

chain Improved collaborative models for the

different software development

teams

Figure 4.10 Categorization of the VOCs by using an affinity diagram

Phase II: Measure

Step 1: In this step, all of those categorized and prioritized VOC items in the

previous phase are translated into measurable requirements/CTQs from

the design perspective. The result of the translation is shown in Figure 4.11 as the main matrix of the house of quality obtained by using QFD.

Relationships

▲ Strong positive (Score=9)

△ Medium positive (Score=3)

↑ Weak positive (Score=1)

↓ Weak negative (Score=1)

▽ Medium negative (Score=3)

▼ Strong negative (Score=9)

Importance to the customer (Scale 1-5) Percent level of customer satisfaction with the customisation Cycle time for order delivery Variation of the cycle time for order delivery Number of the cases in which the issues of system incompatibility reported Time needed to learn to operate the system interface Cycle time for the system setup, installation, and maintenance Total time of on-site customer support annually Total cost for each version upgrade Charge rate for technical support Number of system defects discovered Provided with online problem-solving guides Cycle time for the software project development Cycle time for the make-or-buy decision making process Cycle time for a communication within the supply chain Throughput rate for the project development through collaboration among different teams Throughput rate for handling customer services via the CRM systems Cycle time for an access to source codes developed by different teams Market share in the Asia market of e-business solutions Turnover rate of the project team members during the project implementation

Customisable software systems 5 ▲ ▽ ▽ ▽ ↑

Quick order delivery 5 ▽ ▼ ▽ ▽ ▼ ▼ ▽ ▽ ↓

Consistent schedule for order delivery 4 ▼ ↓ ↓ ▽

Compatible with other operating systems

or software applications 3 ▼ ▽

User friendly system interface 3 △ ▽ ▼ ▼ ▽ △

Easy system setup, installation, and

maintenance 2 △ ▽ ▽ ▼ ▽ △

Providing on-site customer support 2 ▲ ↓ ▽

Low cost for version upgrade 1 ▼

Reasonable charge for technical support 1 ▽ ▽ ▽ ▼ ▽ ↑ ↑

Downloadable service pack for system

defects 1 ▽ ▼

Online interactive system help menu 1 ▽ ▲

Shortened software development cycle 5 ▽ ▽ ▽ ▼ ▼ ▽ ↑ ▽ ↓

Faster make-or-buy decision making

process 5 ▼ ↓

Effective and timely communications

within the supply chain 4 ▼

Improved collaborative models for the software development teams located in

different countries 4 ▽ ▲ ▽

Integrated customer relationship management (CRM) systems for handling customer services

3 ▽ ▲

Easy to access and maintain the source codes of the software developed by different teams

2 ↓ ▼ ↓

To be an Asia market leader in e-business

solutions 2 △ ▼ ▼ ▼ ▼ ▽ ▼ ▽ ▲

Stabilised staffing plan during the

implementation of a development project 1 ▼

Importance weighting 99 63 54 115 33 48 21 27 30 103 32 96 135 94 36 38 60 18 33

Figure 4.11 The translation of the VOCs into measurable requirements by using

QFD

Step 2: The measurable requirements/CTQs identified in Figure 4.11 are further

prioritized based on the calculations of importance weightings in the

QFD matrix which is also shown in Figure 4.11. Next, Using Pareto analysis, those few CTQ items that account for the substantial portion of the total importance weighting are selected to establish the performance metrics as follows.

z Cycle time for the make-or-buy decision making process;

z Number of the cases in which the issues of system incompatibility reported;

z Number of system defects discovered;

z Percent level of customer satisfaction with the customization;

z Cycle time for the software project development; and

z Cycle time for a communication within the supply chain.

Step 3: By using the methods of customer surveys among both internal and

external customers, as well as benchmarking and competitive analysis within the industry, the specification levels that represent a range of acceptability for each performance metric are determined in Table 4.16.

Table 4.16 The specification levels for the performance metrics

Specification levels CTQ

Upper level Lower level

Cycle time for the make- or-buy decision

making process

40 days N/A

^**

Number of the cases in which the issues of system incompatibility reported

1,350 DPMO

^*

N/A

^**

Number of system defects discovered 2,555 DPMO

^*

N/A

^**

Percent level of customer satisfaction with the customization

N/A

^**

60 %

Cycle time for the software project

development 130 days N/A

^**

Cycle time for a communication within the supply chain

7 days N/A

^**

* DPMO stands for defects per million opportunities.

** N/A indicates that the data is not available.

Phase III: Analyze

Step 1: Since the performance metrics have been established in the last phase,

this step takes the metrics into the design requirements and starts to develop conceptual process design alternatives. However, one contradictory issue exists when all of the performance metrics are taken into account. That is the contradiction between the two metrics of the percent level of customer satisfaction with the customization and the cycle time for the software project development. To overcome this dilemma, TRIZ technique (Altshuller, 2004) is adopted by referring to its contradiction matrix and 40 principles. In this case, a reference is made to the mapping between the two parameters, ‘adaptability’ and

‘speed’, in the contradiction matrix, and one suggested solution,

‘preliminary action’, can be obtained by consulting the 40 principles. As a result, an idea of developing modularized designs of software applications can be derived from the solution suggested by TRIZ.

Finally, two conceptual design alternatives are generated and described respectively as follows. Alternative 1: the company may initiate an in-house project for dealing with the customer’s request for software development. Alternative 2: the company may outsource some independent software development firms for fulfilling its customers’

orders for new software designs.

Step 2: Based on the conceptual design alternatives developed in the last step, an

initial-state value stream map can be constructed for each alternative. An example of such a map is outlined in Figure 4.12 for Alternative 2. In this example, there are two process steps identified to be non-value-added by

applying Lean principles. They are the steps of ‘Confirm with R&D’ and

‘Tested by product marketing’, which also expose the opportunities for design improvements.

Step 3: To evaluate the design alternatives, further examinations on their

respective value stream maps are required. In this case, both of the two design alternatives can be evaluated and compared in terms of the cycle time data for each process step in the value stream maps. For example, the cycle time data, which is obtained based on the practical experience, for Alternative 2 is also depicted in Figure 4.12. As a result, Alternative 2 is preferable to Alternative 1 by comparison between their total process cycle times, and therefore is selected to be the option for further design work.

Step 4: The design work begins with the improvement on the initial-state value

stream map. It means first to eliminate the non-value-added process steps as identified in Step 2 of this phase. Next, a future-state value stream map can be constructed as shown in Figure 4.13 to represent a desired performance level. It is noted that the non-value-added step,

‘Tested by product marketing’, in Figure 4.12 is eliminated and replaced by a new value-added step called ‘Tested on partner’s platform’ as exhibited in Figure 4.13.

Yes

Integrated CRM Systems

Present

Figure 4.12 An initial-state value stream map for Alternative 2 of the software development process

Yes

Integrated CRM Systems

Present

Phase IV: Design

Step 1: A detailed process design map is developed as shown in Table 4.17. It is

noted that the input/output items in each step of the whole process are identified and established whether or not they are controllable or uncontrollable items.

Table 4.17 A detailed process design map for the software development process

Process step VA /

NVA Input/output items I/O Specification levels

Controllable/

uncontrollable VA Data of customer requests I Complete and

readable

U VA Examine the data of customer

requests I U: 3 days

requests by product marketing Present analysis report

VA Submit analysis reports O N/A C

VA Analysis reports I N/A C

VA Examine analysis reports I U: 2 days

L: 1 day C

VA Evaluate technical feasibility I U: 3 days L: 1 days

C VA Evaluate development

schedule

I U: 3 days L: 1 day

C VA Prepare for R&D comment

reports

I U: 2 days L: 1 day

C Evaluated by R&D

VA Submit R&D comment reports

O N/A C

VA R&D comment reports I With technical

comments C

VA Review E&D comment reports

I U: 20 days C

VA Executive meeting(s) for discussions

Evaluate and select an outsourcing firm VA Settle down the staffing,

facilities, location issues

I U: 14 days L: 7 day

C Initiate a development

project

Table 4.17 A detailed process design map (continued)

Process step VA /

NVA Input/output items I/O Specification levels

Tested on partner’s platform

Step 2: In this case, there is one non-value-added activity discovered in the detail

process design map. It is the activity of searching for other suppliers and should be removed from the overall process design.

Phase V: Verify

Step 1: A pilot test of the new process design is conducted to verify the design

solution. Its performances are measured and evaluated in details such that refinements might be identified to be necessary in different areas. In this particular case, the pilot result indicates the documentation of the process manual is needed to be addressed.

Step 2: Develop process control plans, which involve the use of a Check List for

the internal strategic management and an R-chart for the long-term service-processing time control, so that the process owner can monitor and maintain the process.

Step 3: Since the new process design is verified and process control plans are

developed, a full-scale rollout is launched next. Finally, the new process design is documented and transitioned to the process owners.

4.3.3 The implementation results and discussions

After the process redesign project was completed, the company conducted a follow-up study to examine the effectiveness of the integrated methodology. A total of 52 software development projects were randomly picked up for this 12-month study.

The results of the performance metrics and the achievement of the company’s goals are summarized in Tables 4.18 and 4.19 respectively.

Table 4.18 The results of the performance metrics for the software development

process redesign

Target After Performance metrics

Average Sigma level Average Sigma level

Cycle time for the make-or-buy

decision making process

14 days 4.73 12 days 4.79

Number of the cases in which the issues of system incompatibility reported

500 DPMO 4.79 323 DPMO 4.91

Number of system defects discovered 900 DPMO 4.62 558 DPMO 4.76 Percent level of customer satisfaction

with the customization

80 % 4.50 87 % 4.73

Cycle time for the software project

development 92 days 4.59 83 days 4.74

Cycle time for a communication within the supply chain

5 days 4.42 3.5 days 4.58

Table 4.19 The achievement of the company’s goals* for the software development

process redesign

Goals Actual (year 2004) Target (year 2005) Actual (year 2005)

Percent share in the Asia market of

e-business solutions

9.5 % 15 % 22 %

Percent growth rate of total revenue 12 % 25 % 42 %

Percent overall profit margin 22 % 30 % 39 %

* Data was collected based on the 2006 annual report published by the company.

Based on the results as shown in Tables 4.18 and 4.19, the major findings in this follow-up study are two-fold. Firstly, all of the performance metrics achieved the target levels and the company’s goals were totally realized after the integrated methodology was implemented. The successful results demonstrate that the combined approach of both DFSS and Lean is an effective strategy. Despite that the project implementation is for the particular case of software development process, the integrated methodology can be also applicable for the process design/redesign in other service industries. It is because the concepts of service quality dimensions were involved and applied in the development of the essentially integrated system.

Secondly, each performance metric in Table 6 has its individual implication in relation to the subject matter of quality or speed; therefore, the achievement of a level above 4.50-sigma for all the performance metrics implies that the new process design is capable of delivering high-quality and desired services to the customer in a fast speed.

在文檔中 整合精實與六標準差方法論於服務品質之改善與創新設計 (頁 69-84)