KPIs der Softwarequalität und der Zusammenhang zu Wartungskosten

Wartungsaufwände werden durch geringe Softwarequalität verursacht: Kundenspezifische Eigenentwicklungen, Erweiterungen oder Add-Ons von Drittanbietern sind für die meisten SAP Anwender notwendig und bringen viele Vorteile. Auch wenn der SAP Standard immer umfangreicher wird, sind Erweiterungen durch Entwicklungen meist notwendig, um die Systeme richtig auf die Unternehmensprozesse einzurichten und Vorteile zu schaffen. Wird bei diesen Entwicklungen aber auch die Softwarequalität berücksichtigt und die KPIs der Softwarequalität beachtet? 

QUANTO Solutions und sieber&partners beleuchten in diesem Artikel die Auswirkungen von Eigenentwicklungen und Erweiterungen auf die Betriebskosten der SAP-Lösungen. Es geht dabei nicht um die Sinnhaftigkeit von Erweiterungen und Eigenentwicklungen an für sich, sondern um die Berücksichtigung der KPIs der Softwarequalität dieser Entwicklungen und den Bezug zu den Folgekosten, also den Wartungskosten. Denn diese werden oft unterschätzt und führen zu Frust und teils auch ungerechtfertigt zu Ablehnungen gegenüber SAP. SAP sei zu teuer. 

Wir kennen von vielen Unternehmen die Unzufriedenheit, dass sich die Betriebskosten und dabei vor allem die Wartungskosten nach SAP-Einführungen deutlich höher zeigen als vor der SAP-Einführung geplant. In einigen Fällen hat dies zu einem Wechsel zu externen Dienstleistern, vor allem Nearshore- und Offshoredienstleistern, geführt. Dies führt dann aber häufig zu sehr langsamen Umsetzungsgeschwindigkeiten und wichtige Funktionalitäten werden erst spät fertig. In vielen Fällen hat der Wechsel zu Offshoredienstleister zwar die Stundensätze verbessert – dafür ist aber die Zahl der eingesetzten Stunden gestiegen und der TimeToMarket von Funktionen wurde verzögert.  Dies wiederum hat dazu geführt, dass innovative Lösungen, die schnell umgesetzt werden sollten, außerhalb von SAP umgesetzt wurden. Schlimmstenfalls wurden diese dann sogar an der internen IT vorbei entwickelt. Beides sind langfristig keine zielführenden Wege und die Analyse der „zu hohen Wartungsaufwände“ muss tiefer gehen und es muss ein Blick auf die wesentlichen KPIs der Softwarequalität gerichtet werden. Vor allem in Vorbereitung der neuen SAP S/4HANA Lösungen, damit sich diese Fehler nicht wiederholen.  

Wie wir später sehen, liegt die Ursache der hohen Wartungskosten oft in der geringen und unterdurchschnittlichen Softwarequalität. Dabei sind die Verbindungen von Softwarequalität zu Wartungsaufwänden sehr gut zu beschreiben und zu bewerten. Die KPIs der Softwarequalität nach ISO sind hier gute Grundlagen. 

KPIs von Softwarequalität 

Zur Beurteilung der Qualität von Software gibt die ISO Norm 25010 gute und umfangreiche Kriterien (KPIs der Softwarequalität) und einen ausgereiften Rahmen vor. Erstaunlich ist wiederum, dass die ISO 25010 trotzdem nur bei wenigen Unternehmen Verwendung findet und sie auch in den spezifischen Entwicklungsrichtlinien kaum zur Anwendung kommt. Zumindest nicht in der Praxis. 

Die ISO 25010 gibt für die wichtigen KPIs wie  

• Sicherheit  
• Usability 
• Zuverlässigkeit 
• Performance 
• Portierbarkeit 
• Funktionalität 
• Kompatibilität und 
• Wartbarkeit 

einen guten Rahmen vor.  In diesem Bereich gilt es sowohl in der Umstellung auf SAP S/4 HANA viele Dinge zu berücksichtigen als auch richtig zu machen. An Beispielen, dass nach dem Upgrade auf SAP S/4HANA die Performance schlechter statt besser wird, mangelt es nicht. Und an Beispielen für schlechte und eventuell auch unsichere Zugriffe ebenso nicht. Für den Bereich Sicherheit gibt es auch gute und bekannte Lösungen (ABAP Test Cockpit SAP, SonarQube, Tools über GitHub oder den CodeProfiler von Onapsis (ehemals Virtual Forge)). 

Die Wartbarkeit – als Aussage darüber, wie gut sich der Sourcecode verändern lässt – ist der KPI der Softwarequalität, welcher als Kostentreiber Auswirkung auf alle anderen Kriterien hat.  

Erstaunlich ist wiederum, dass der KPI der Wartbarkeit wenig Berücksichtigung finden und hier auch selten Tools verwendet werden. Dies ist besonders unverständlich, da nur wenige Unternehmen mit den Wartungskosten der SAP-Lösungen zufrieden sind. 

Benchmark von Softwarequalität – Vergleich der KPIs 

Um Wartungsaufwände sichtbar und vergleichbar zu machen, hat die deutsche TÜV Informationstechnik (TÜViT, Teil des TÜV Nord) zusammen mit einem Forschungslabor für Software  ein Modell entwickelt, das die Wartbarkeit eines Systems objektiv messen kann. 

Das Modell basiert auf dem ISO/IEC Standard 25010 für Softwarequalität und vergleicht diese KPIs. Der Begriff der Wartbarkeit wird Im ISO Standard unterverteilt in Subcharakteristiken, die die Arbeitsschritte bei Änderung am Code unterstützen: 

• Analyse von bestehendem Code 
• Änderung des Codes 
• Testen des Codes 
• Modularisierung des Codes 
• Wiederverwenden von bestehendem Code  

Zur Entwicklung eines operativen Modells für Wartbarkeit wurden messbare Eigenschaften vom Sourcecode bestimmt, die einen Einfluss auf die Aufwände für diese Arbeitsschritte haben. Für eine gute Messbarkeit ist es wichtig, dass die Eigenschaften unabhängig sind von folgenden Kriterien:  

• der Entwicklungssprache, die angewendet wird 
• der Domäne, in welcher die Software eingesetzt wird 
• der Funktionalität, die abgebildet wird 
• der Größe des Systems 

Im Weiteren wurde der Sourcecode von mehreren Tausend Systemen analysiert. Der Fokus lag darauf, eine Korrelation von Wartungsaufwänden und spezifisch messbaren Eigenschaften der Software zu finden. Aus dem Sourcecode lässt sich eine Vielzahl von Kennzahlen berechnen (Größen, Anzahl Methoden, Abhängigkeiten, Komplexität usw.). In der Analyse der Systeme haben sich dann Eigenschaften finden lassen, die den obigen Ansprüchen an universellen Einsatzmöglichkeiten genügen. Daraus entstand ein Benchmarking von 1 bis 5 Sternen. Drei Sterne bilden den Marktdurchschnitt. 

Vergleicht man nun die Softwarequalität von SAP Lösungen mit der Qualität anderer Lösungen, wird sichtbar, dass die Qualität im Blick auf die Wartbarkeit deutlich schlechter als der Durchschnitt ist. 

Im Benchmarking stellt man fest, dass der Durchschnitt von Erweiterungen und Eigenentwicklungen bei SAP Software mit 1,3 Sternen deutlich geringer ist als der Industriedurchschnitt mit ca. 3 Sternen. Woran liegt das? 

Gründe für geringe Softwarequalität bei SAP Entwicklungen 

Die geringe Softwarequalität von SAP Entwicklungen hat verschiedene Ursachen. Wichtige Ursachen sind: 

• Entwicklungen sind fachlich getrieben: Oft werden bestehende Prozesse auf Anforderung der Nutzer angepasst, fachlich verbessert und SAP User Exits, BAPIs usw. verwendet. Der Fokus der Entwicklung liegt in der Umsetzung der fachlichen Anforderungen. Auf der Qualität der Entwicklung liegt kein Fokus.  

• Berater statt Softwarearchitekten: Die Umsetzung wird von Fachbereichen und Fachberatern konzipiert. Berater mit oft nur geringen Entwicklungs- und Architekturkompetenzen verantworten die Umsetzung, die Abnahmen und das Testen.  

• Schnelle und kleine Lösungen sind gewünscht: Erweiterungen und Eigenentwicklungen sollen schnell und mit wenig Aufwand umgesetzt werden. Der Fokus liegt meist auf der schnellen und kostengünstigen Umsetzung von fachlichen Anforderungen. Abnahmen werden vom Fachbereich aufgrund der korrekten Umsetzung der fachlichen Anforderungen gemacht. Eventuell findet vor den Transporten eine Prüfung auf Sicherheit statt, nur ganz selten aber auf Architektur, auf Einhaltung der Entwicklungsrichtlinien, Dokumentation und Wartbarkeit. 

• Auswahl der Berater und Entwickler: Bei der Auswahl des Beratungs- und Umsetzungsteams liegt der Fokus auf fachlichem Wissen, Branchenwissen und Modulkenntnissen. Beispielumsetzungen, Design- und Architekturkompetenz werden nur selten bewertet und stehen bei den Auswahlkriterien eigentlich an letzter Stelle. 

• Anpassungen über Jahre: Entwicklungen in SAP beginnen oft klein. Es soll am Standard etwas angepasst werden. Dann erfolgen aber die Weiterentwicklungen über Jahre und verschiedene Berater und Entwickler sind im Einsatz. So wird über Jahre ein Balkon an den anderen gebaut und kaum jemand überarbeitet die ganze Entwicklung.  

• Kein Redesign: Entwicklungen werden ergänzt und erweitert, aus verschiedenen Gründen verbessert, aber nur selten wirklich komplett überarbeitet, auf Standard zurückgeführt oder insgesamt architektonisch neu gemacht. So beinhalten Entwicklungen oft viel toten Code und viele alte Kommentare. Das macht Fehlersuchen aufwändig und teuer und führt zu langen Einarbeitungszeiten und langen Umsetzungen. Das Business sieht die Notwendigkeit meist nicht, für Aufräumarbeiten Ressourcen bereit zu stellen. 

Die Bewertung der Softwarequalität  

Für die Beurteilung der Softwarequalität bietet die ISO 25010 einen guten Rahmen. Auch gibt es Tools, die eine sehr automatisierte und schnelle Beurteilung erlauben. Während aber Tools zur Securityprüfung von den meisten Unternehmen verwendet werden, findet eine Prüfung auf die umfassende Qualität nur selten statt. Wie bei allen Werkzeugen hilft auch nicht der schnelle Griff in das Baumarktregal, sondern es benötigt in der Anwendung und Beurteilung Wissen und Erfahrung. Die Schweizer Beratung sieber&partners hat darauf einen Fokus und verfügt über umfangreiches Wissen. Somit ist ein schneller und sicherer Benchmark möglich. 

Wie wird die Softwarequalität verbessert? 

Die Verbesserung der Softwarequalität über die KPIs in SAP hat verschiedene Aspekte und es kann nicht einfach versprochen werden, dass man mit wenigen Handgriffen von einem typischen Rating von < 1,5 auf über 3 Sterne kommen kann. Allerdings zeigt die Erfahrung, dass allein durch die Prüfung und Messung der Qualität sowie dem Feedback an die Entwicklung und initial einer weiteren Runde die Qualität um 0,5 Punkte verbessert werden kann. Wenn dann das Bewusstsein für Softwarequalität und ihre KPIs in der Entwicklung ausgebaut wird, die Richtlinien zusammen mit dem Knowhow der Entwickler verbessert werden, kann schnell eine weitere Verbesserung erzielt werden. Marc Andre Hahn von sieber&partners beurteilt das so: „Allein die Tatsache, dass es ein regelmäßiges Monitoring der Softwarequalität gibt, führt in der Regel zu einer besseren Qualität. Wird dann noch zielgerichtet auf gute Qualität hingearbeitet, das Entwicklerteam angeleitet und Qualitygates aufgesetzt, lassen sich signifikante Qualitätssteigerungen erreichen. Dies führt zum einen zu einer schnelleren Projektumsetzung und langfristig zu deutlich tieferen Wartungskosten“. 

Die weitere Verbesserung der Qualität entsteht unter Berücksichtigung der Architekturprinzipien. So ist eine Bewertung mit 2-3 auf jeden Fall möglich. 

Was bedeutet die Verbesserung um 0,5 oder 1 Sterne 

Die Verbesserung der Softwarequalität lässt sich aufgrund von Benchmarks wirtschaftlich sehr gut bewerten. Eine Verbesserung des Codes um einen Stern hat eine Halbierung der Wartungsaufwände zur Folge. 

Während eine individuelle Betrachtung natürlich immer einen Vergleich und damit Zeit benötigt, ist ein Vergleich mit anderen Unternehmen (Benchmark, der dem Modell zu Grunde liegt), sehr schnell gemacht. Die Erfahrung zeigt hier, dass die Investition in Qualität sehr wirtschaftlich ist. Wobei wir das eigentlich alle wissen und das ja nicht nur bei der Qualität von Software gilt.  

Das Investment muss bei der Wirtschaftlichkeitsbewertung in Bezug zu typischen Lebenszyklen und typischen Wartungsaufwänden gesetzt werden und es zeigt sich, dass die Verbesserung der Qualität sich sogar noch in einem Projekt rechnen kann. Wenn ein etwas größeres Vorhaben über 1-2 Jahre erfolgt und man in der heute typischen agilen Vorgehensweise mit einem MVP beginnt, gibt es eine hohe Wahrscheinlichkeit, dass andere noch mehrmals vor der wirklichen Produktivsetzung an dieser Entwicklung arbeiten und sie ausbauen. So gibt es viele Beispiele, bei denen die Investition in Qualität sich noch im direkten Projekt finanziert und somit der Return of Investment (RoI) über 1 liegt. Betrachtet auf den Lebenszyklus typischer IT Lösungen liegt er dann bei über 3. 

Softwarequalität bei unseren Lösungen 

Auch unsere Lösungen werden weiterentwickelt und verursachen Wartungsaufwände. Die Qualität bewerten wir selbst zusammen mit sieber&partners regelmäßig und erreichen bei QUANTO-GO mit 1,9 Sternen eine überdurchschnittliche Qualität für SAP. Eine höhere Bewertung streben wir an. Dies ist aber durch die Lauffähigkeit der Produkte auf SAP Systemen unterschiedlichster Releaese (ab SAP R/3 4.6x bis zu S/4HANA) kaum möglich. Unsere neueste Lösung QTC (QUANTO Transliteration Center) erreicht eine Qualität von über 2,5. 

Next Steps 

Wie verbessert man nun die Softwarequalität in SAP Entwicklungen, besonders vor oder während der Einführung von SAP S/4HANA?  

1. Am besten nicht erst hinterher 

2. Wenn hinterher, dann Beginnt mit einer Analyse 

3. Fokus auf selbstgeschriebenen Code  

4. Einführung einer Qualitätskultur 

Am besten sorgt man bereits währende der Entwicklung dafür, dass gar nicht erst schlechter Code entsteht. Dies geschieht dadurch, dass vor Projektbeginn die angestrebten Qualitätsziele definiert werden und es ein regelmäßiges Monitoring des Sourcecodes gibt. Periodisch (z.B. alle 2-3 Monate) gibt es eine umfassende Analyse und es werden Maßnahmen vereinbart, falls gewisse Kennzahlen nicht die Qualitätsziele erreichen.  

Qualität kann nicht in fertigen Sourcecode hineingetestet werden, sondern muss am Anfang hineinentwickelt werden. Stellt man erst am Ende des Projekts fest, dass die Qualität nicht den Vorgaben entspricht, muss sehr viel Code wieder angefasst werden und eine große Zahl von Tests müssen erneut gemacht werden. 

Will man bestehenden Code verbessern, sollte immer mit einer Analyse des gesamten Sourcecodes begonnen werden. Dabei werden idealerweise alle Releases der letzten 2-3 Jahre analysiert. So gewinnt man einen Eindruck, wie die Qualität des Codes ist und wo viele Veränderungen im Code stattfinden. Das gibt erste Aufschlüsse darüber, wo es sich besonders schnell auszahlt, die Qualität im Zuge der normalen Wartungsarbeitet an Code zu verbessern. 

Bei der Verbesserung sollte der Fokus auf dem selbstgeschriebenen Code liegen. D.h. in der Analyse müssen die Clones aus dem SAP Standard ausgeschlossen werden, um nicht langfristig in Kompatibilitätsprobleme zu kommen.  

Der wichtigste und alles entscheidende Faktor ist jedoch eine Einführung und Etablierung einer Qualitätskultur – „Quality Driven SAP Development“. Die bisherige Kultur lässt sich vielerorts eher als „Functionality Driven SAP Development“ beschreiben. Findet die Entwicklung intern statt, braucht es hier einen Kulturwandel. Findet die Entwicklung mit einem externen Partner statt, sollte ein Partner gewählt werden, der eine qualitätsorientierte Entwicklung verfolgt. 

Fazit: KPIs Softwarequalität

Ein Investment in Softwarequalität in SAP lohnt in den allermeisten Fällen und verbessert damit langfristig die Wartbarkeit und somit unmittelbar die Betriebs- und Weiterentwicklungskosten. Es zeigt sich, dass das Potential gerade bei SAP Erweiterungen, Eigenentwicklungen und fremden Add-Ons sehr hoch ist und die geringe Softwarequalität meist Ursache der hohen Folgekosten ist und oft auch zu Frustrationen führt. 

Für die Softwarequalität gibt die ISO wie auch weitere Unterlagen einen gut nutzbaren Rahmen und KPI vor und auf dem Markt sind erprobte Tools verfügbar. Zur Anwendung, zur Einführung und zur Beurteilung der Ergebnisse sowie zur Erarbeitung der Handlungssträngen und zur nachhaltigen Verbesserung haben Experten von sieber&partners und QUANTO Solutions Erfahrung und Referenzen. 

Überzeugen Sie sich in einem unverbindlichen Gespräch. 

Finden Sie unseren Artikel auch auf dem Blog von sieber&partners.