applying qfd for software process improvement at sap ag ... - CiteSeerX

14 downloads 110934 Views 84KB Size Report
During this time, SAP has changed from a small software company employing 30 people in ... the use of QFD in SAP's software process improvement efforts.
APPLYING QFD FOR SOFTWARE PROCESS IMPROVEMENT AT SAP AG, WALLDORF, GERMANY Andreas Hierholzer, Georg Herzwurm, Harald Schlang SAP AG, Walldorf, Germany, Fax: +49 6227 57280; Email: [email protected] Universität zu Köln, Köln, Germany; Fax: +49 221 470 5386; Emails: [email protected] or [email protected]

Keywords Software process improvement, quality management, change management

Abstract Due to continual organizational change in its effort to extend its leading position in the rapidly growing market for standard business software, it is critical for SAP to continually adjust its software development process to changing market conditions as these are reflected in new and varying requirements. SAP must answer the question which requirements are the most important and offer the greatest potential for improvement in order to ensure SAP’s continued success. Quality Function Deployment (QFD) offers an effective way for selecting the mission critical requirements of the software development process. This article describes the approach used to improve the software process in a pilot project at SAP. Partly due to the success of this pilot project, QFD is currently being integrated into SAP’s Total Quality Management approach to software improvement.

Introduction SAP‘s revenue and employment have been rising an average 60% p. a. over the course of the last 15 years. During this time, SAP has changed from a small software company employing 30 people in 1973 and catering mainly to the needs of major businesses, to a multinational corporation producing software for businesses of all sizes. Today, SAP employs approximately 16,000 people across the world and has become the worldwide market leader in the field of standard business software. The SAP AG is structured in several dimensions, with the regional divisions, the industry solutions and R/3 core components divisions, and the service, consulting and development divisions being among the most important. The central development division in Walldorf near Heidelberg has grown from approximately 1,500 developers ten years ago to 7,500 today, and was reorganized every year as a result of that rapid growth. An important aspect of the last reorganization in 1997 was the introduction of the Product Management, Quality Management and Development Management functions for the 16 R/3 core and 13 industry solution divisions, each of which is headed by a Program Director. (see Figure 1). In addition, several staff divisions have been established that deal with tasks related to cross-division integration and report directly to the board of directors.

One of these staff divisions is the quality and planning group (QaP), whose task it is to ensure the quality of the software development processes. A client – supplier relationship has been established between QaP and the approximately 40 quality management groups.

Executive Board Responsibility for the development process

Responsibility for the product

Program Directors Quality & Planning Group

Development Managers

Quality Managers

Development Managers QM-Team:

Figure 1

Quality Organization in the Software Development at SAP

Outline of the QFD project for software process improvement at SAP The QFD project described in this paper was based on this client – supplier relationship between QaP and the Quality Managers. Its primary purpose was to give the Quality Managers effective aid in improving the development process within their groups. To do so, it was necessary to identify and prioritize the general requirements SAP’s software developers and management had regarding their software development process and contrast them with the appropriate process improvements. Because the Quality Managers are fully integrated into development, they possess a great deal of inside knowledge about the process in their groups. Therefore, their involvement in the project was of great importance to its success. The project was initiated as a pilot project in the spring of 1997, with the goal of assessing QFD’s suitability for software process improvement. If it were successful, it would be considered to institutionalize the use of QFD in SAP‘s software process improvement efforts. Because of previous successful cooperations, the project was carried out in cooperation with the German QFD Institute and the Chair of Business Computing of the University of Cologne.

The methodical approach for a QFD for SAP’s software process Improvement The project structure was oriented on Deming’s Plan-Do-Check-Act cycle (see Deming, 1986; and Figure 2).

Clustering Stakeholders

Determining Process Requirements

Determining Stakeholders

Imroving the software process Legend: = Cycle for Software Process Improvement with QFD = Deming PDCA Cycle

Figure 2

Plan

Do

Act

Check

Determining suggested process improvements Structuring requirements and process improvements

Planning and implementing Establishing and actions to improve analyzing the the software process House of Quality

The cycle of software process improvement with QFD

Determining and clustering customers for Software Process Improvement (Phase Plan) Coordinating the improvement of the development process is the responsibility of the Quality Managers at SAP, each of whom is responsible for one of the components of SAP’s R/3 system. To keep the pilot project focused, it was restricted to the processes in the development of the R/3 Logistics application. In consideration of this, the QFD team was staffed with several representatively selected Quality Managers from the Logistics development, who agreed to participate in the project. The developers, Development Managers, Quality Managers, Product Managers and Program Directors within the Logistics development were identified as distinct stakeholder groups of the development process and weighted according to their importance for the project’s success (see Zultner, 1995).

Determining process requirements and recommendations for process improvement (Phase Do) First, standardized interviews were conducted with a random sample drawn from the developers, the Quality, Development and Product managers and the Program Directors. The aim of the interviews was to elicit the interviewees‘ requirements on the software development process and their suggestions for possible process improvements. Pretests of the interview guide showed that direct questions concerning requirements and suggestions for process improvements gave few meaningful results. Obviously, the notion of having requirements on something as abstract as a process was alien to the way most of the stakeholders thought. Because of this,

the interviewees had a very hard time answering questions put in this way. What was required was a way to adjust the style of questioning to the interviewees‘ way of thinking. A good approach to this problem was derived from R. Lyman’s article >>Selling QFD to ManagementTo what degree would the implementation of process improvement Y help to better fulfill the requirement X? Current(y) otherwise

Finally, the Difficulty of Implementation had to be judged for each process improvement on a scale from 1 (very easy to implement) to 5 (very difficult). The implementation of a suggestion would be judged difficult for various reasons: Some required a substantial investment to implement, some required major organizational changes, and some were expected to meet with heavy resistance from the developers or from management. There was a correlation to the Current Integration and Target Integration values here: Achieving a higher level of Target Implementation (say, 5 instead of 3) was sometimes likely to result in a much greater degree of difficulty. The difficulty of implementation was also judged on a scale of 1 (extremely easy to implement) to 5 (extremely hard to implement). These two characteristics formed the basis for calculating the Modified Improvement Weight of each suggested process improvement, which served as the final criterion for prioritizing the process improvements (see Herzwurm, Schockert, Mellis, 1997):

Modified Improvement Weight ( y ) =

Total Improvemen t Weight ( y ) ⋅ Improvement Ratio( y ) Degree of Difficulty( y )

A pareto-analysis over the results of the evaluation process showed that the concentration of the total Modified Improvement Weight on the most important process improvements was even more pronounced

Requirement Significance (absulute sum)

Requirement Significance (relative sum)

Ranking of requirements according to requirements significance

seperate release shipping of german and english R/3

...

encapsulate release cycles of the components

1,00

1,00

5,39% 4,14% 2,75%

3,19 3,14 2,70

1,82% 6,28% 1,45% 5,02% 1,19% 4,11%

2 6 12

3,00% 3,57% 3,68%

3,09 3,28 2,93

1,03% 3,56% 1,33% 4,59% 1,56% 5,38%

17 8 3

2,58%

2,88

0,98% 3,38%

21

38,62%

1,00

0,00% 52 0,00

5

3

4

3

4

5

1

0,00%

0,00%

-48,42%

84,60% -33,42% 51,18% 46 4,00

4

40,94%

14,83%

189,90% 189,90% 0,00% 16 2,00

4

94,95%

55,02%

393,07% 393,07% 0,00% 2 113,89%

1,67

2

218,37%

152,62% 0,00% 20 4,00

3

152,62%

44,22%

152,62%

37,66% -37,76% 0,00% 52 0,00

2

0,00%

0,00%

126,91% 126,91% 0,00% 4,00

25

Figure 11

3

101,53%

36,77%

81,20%

1

Absolute modified Improvement Weight according to relative Req. Significance

0,00% 81,20% 37

1

4

3,00

1

4

60,90%

23,53%

89,80%

2

5

Difficulty of implementation

0,00% 89,80% 34

3

4

1,33

1

1

29,93%

26,02%

204,56% 204,56% 0,00% 14

2

4

1,67

1

3

170,47%

59,27%

65,30%

1

4

Improvement Ratio

0,00% 65,30% 42 18,92%

3

5

2,00

221,85% 0,00%

3

4

43,53%

208,38% 0,00%

9

2

4

Overall weight of absolute Requirement Significance

1,33

3

3

Ranking according to overall weight

1,50

2

Target

Overall Weight of relative Requirement Significance (SUM)

147,90%

Current

Overall Weight of relative Requirement Significance (only negative correlations)

104,19%

12

221,85%

9

64,28%

208,38%

3

99

3 9 -9

3

Overall satisfaction

3 9

5

Decrease time stress

Improve competence of external consultants 9 9 9

98

Prototyping

Improve communication to/from customer

9 9 3

Overall weight

1

64

3 3 3

63

Improve sharing of work (Analysis, Design, Implementation & Test / CATT) 6

58a decrease spezialisation

9

Reorganize Development

OO Development

9

58

support information exchange about architecture and interfaces

Encapsulation and reuse

3

60,38%

Overall Weight of relative Requirement Significance (only positive correlations)

43

9

create a framework of reusable components

18

42

1

better support for reuse

4 5 6

41

9 5

Create new function using encapsulation and documentation interfaces

5 3

40

1 2 3

39

3

developer participation on customer workshops

1

Requirements Determine and prioritize customer requirements Precise determination of customer requirements Focus on most important customer requirements Account for cost / benefit ratio Ensure innovation Dealing with new problems Use of the latest technology Time to market reduction Ensure product properties Broad functionality ...

more meetings with customers and devolpers

Process improvements

Software Process Quality Function Deployment

Improve customer contact

than was the case with the requirements.

QFD Matrix (Extract)

The final step involved planning concrete actions for implementing the process improvements with the greatest Modified Improvement Weight. It was essential to focus on the most important requirements, to avoid overtaxing the stakeholders’ tolerance for change (see Conner, 1995).

Planning and implementing actions to Improve SAP’s Software process (Phase Act) In this phase, concrete actions were derived from the most important process improvements by the project team. For each such action, a member of the QFD project team was assigned the responsibility for acquiring the necessary support from developers and managers and, if necessary for the action in question, the expert knowledge and resources. This is the current state the QFD project as the changes made due to its results are gradually being introduced into the development process. The following Figure 12 gives a comprehensive summary of the QFD project’s workflow:

Process Improvement Voice Table Interviews with Stakeholders

Affinity Diagram Structuring the Recommendations for Process Improvement

Recommendations

Recommendations for Process Impr.

Review of Recommendations of Process Impr.

Hierarchy Diagram Recommendations

Statements of the Stakeholders

Interview reports

How

Statements of Stakeholders

W h a t

Stakeholder Voice Table

House of Quality

Process Requirements

Structuring the Process Requirements

Why

How much Affinity Diagram Process Req.

Review of the Process Requirements

Hierarchy Diagram Process Req.

Survey for the Evalutaion of the Req.

Evaluation Questionnaires

Priorized Process Improvements

Action Planning and Implementation Improved Process

Figure 12

The workflow and products of QFD for Software process improvement at SAP

Conclusion Overall, the cost-/benefit-relation of using QFD for software process improvement at SAP was very positive. The most significant advantages were: •

QFD allowed for concentration of the improvement effort on the most important problems with the current process. This could not have been accomplished as well by using the ISO 9000 or CMM, which gave only general and less concrete suggestions for improvements that were not directly related to the process to be improved (see Mellis, Herzwurm and Stelzer, 1996).



The QFD approach described above allowed to analyze not only the problems the stakeholders had with their current process but also the potential for improvement that could be achieved by solving them.



The use of QFD efficiently structured the long-standing discussion about possibilities for process improvement at SAP.



The structure of QFD allows for very efficient reuse of the information gathered during the project. When the Software Process QFD is repeated, most of the results from the project can be reused and easily merged with the new information gathered, thus greatly reducing the effort required for conducting the new iteration.

Even considering the benefits derived from the use of QFD, there are still possibilities for reduction on the cost side (see Figure 13). The QFD sessions, especially, proved quite time-consuming. Phase

Task

QFD-Team

Determining Stakeholders

2h

Clustering Stakeholders

1h

Determining Process Requirements

47h

Determining suggested process improvements

8h

Structuring requirements and process improvements

80h

Establishing and analyzing the House of Quality

68h

Stakeholder

Plan 23h

Do 14h

Check

Planning and implementing actions to improve the software process

still in process

still in process

Improving the software process

still in process

still in process

206h

37h

Act SUM

Figure 13:

Estimated time for the tasks of the QFD study (excluding phase Act)

Aside from time considerations, the expense of travelling to a common location is also seen as a problem - especially with regard to the increasing globalization of SAP’s software development. Because of this, SAP is currently working on a tool-based implementation of QFD in its Intranet, to allow every member of the QFD project to contribute to the project independently of place or time. Also, several forms of organizational implementation are currently being discussed as means for permanently integrating QFD into SAP’s process improvement effort.

References Bicknell, B. A. and Bicknell, K. D. (1995), ‘The Road Map to Repeatable Success: Using QFD to Implement Change’, Boca Raton et al.

Bossert, J. L. (1991), ‘Quality Function Deployment. A Practicioner’s Approach’, Milwaukee.

Cohen, L. (1995), ‘Quality Function Deployment. How to Make QFD Work for You’, Reading (Mass.).

Conner, D. R. (1995), ‘Managing at the Speed of Change. How Resilient Managers Succeed and Prosper

Deming, W. E. (1986), ‘Out of the Crisis’, Cambridge

Hayes (1992), ‘Measuring Customer Satisfaction: Development and Use of Questionnaires’, Milwaukee.

Herzwurm, G., Schockert, S. and Mellis, W. (1997), ‘Qualitätssoftware durch Kundenorientierung. Die Methode Quality Function Deployment (QFD): Grundlagen, Praxis und SAP R/3 Fallbeispiel’, Wiesbaden.

Herzwurm, G., Mellis, W., Schockert, S. and Weinberger, C. (1997), ‘Customer Oriented Evaluation of QFD Software Tools’, in Proceedings of the Third Annual International QFD Symposium, Volume 1, Linköping, Editors A. Gustafsson, B. Bergman and F. Ekdahl, pp309-323.

Hierholzer, A. (1996), ‘Benchmarking der Kundenorientierung von Softwareprozessen’, Aachen.

Lyman, D. (1996), ‘The Keys to Successful Selling of QFD or Helping Management Choose to “Do Transactions from the Eighth Symposium on Quality Function Deployment, Novi (Michigan), Editors QFD-Institute, pp151-156.

Mellis, W., Herzwurm, G. and Stelzer, D. (1996), ‘TQM der Softwareentwicklung. Mit Prozeßverbesserung, Kundenorientierung und Change Management zu erfolgreicher Software’, Braunschweig Wiesbaden.

Saaty, T. L. (1995), ‘Decision Making for Leaders: The Analytic Hierarchy Process for Decisions in a Complex World.’, 3rd edition, Pittsburgh. Saaty, T. L. (1996), ‘Multicriteria Decision Making: The Analytic Hierarchy Process’, 2nd edition, Pittsburgh.

Saxby, C. and Streckfuß, G. (1996), ‘Produktplanung mit Quality Function Deployment (QFD) – in Der Qualitätssicherungsberater. Aktueller Ratgeber für alle Bereiche des Qualitätsmanagements im Industriebetrieb, Cologne, pp07500/1-07500/25.

Shilito, M. L. and De Marle, D. J. (1992), ‘Value: Its Measurement, Design and Management’, New York et al.

Shilito, M. L. (1995), ‘Advanced QFD’, New York.

Zultner, R. E. (1995) ‘Business Process Reengineering with Quality Function Deployment. Process Innovation for Software Development’, in Transactions from the Seventh Symposium on Quality Function Deployment, Novi (Michigan), Editors QFD Institute, pp627-640.