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.
