Wartungsaufwände werden durch Eigenentwicklungen 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 oft notwendig, um die Systeme richtig auf die Unternehmensprozesse einzurichten und Vorteile zu schaffen.

sieber&partners und QUANTO Solutions beleuchten in diesem Artikel die Auswirkungen von Eigenentwicklungen und Erweiterungen auf die Betriebskosen der SAP-Lösungen. Es geht dabei nicht um die Sinnhaftigkeit von Erweiterungen und Eigenentwicklungen an für sich, sondern um den Aspekt der Qualität der Entwicklungen in Bezug auf die späteren Folgekosten. 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 häufig zu sehr langsamen Umsetzungsgeschwindigkeiten von wichtigen Funktionalitäten. 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 so verzögert. Dies wiederum hat dazu geführt dazu, dass innovative Lösungen, die schnell umgesetzt werden sollten, außerhalt 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. Vor allem in Vorbereitung der neuen SAP S/4 HANA 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.

Softwarequalität

Zur Beurteilung der Qualität von Software gibt die ISO Norm 25010 gute und umfangreiche Kriterien und einen ausgereiften Rahmen vor. Erstaunlich ist wiederrum, 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 wichtige Bereiche wie Sicherheit, Usability und Performance einen guten Rahmen vor. In diesem Bereich ist auch viel zu Berücksichtigen und sowohl in der Umstellung auf SAP S/4 HANA gilt es Dinge zu berücksichtigen und richtig zu machen. An Beispielen, dass nach dem Upgrade auf SAP S/4 HANA 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 aber 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 – das Schlüsselkriterium, welches als Kostentreiber Auswirkung auf alle anderen Kriterien hat.

Erstaunlich ist wiederrum, dass die Qualitätsmerkmale für Wartbarkeit wenig Berücksichtigung finden und hier auch selten Tools verwendet werden. Und dies ist unverständlich, da nur wenige Unternehmen mit den Wartungskosten der SAP-Lösungen zufrieden sind.

Benchmark von Softwarequalität

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 fusst auf dem ISO/IEC Standard 25010 für Softwarequalität. 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:

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

Im Weiteren wurde der Sourcecode von mehreren Tausend System 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össen, 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 Sternen 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 mit Blick auf die Wartbarkeit deutlich schlechter als der Durchschnitt ist.

Abbildung 2: SAP Systeme im Vergleich zu anderen Systemen

Im Benchmarking stellt man fest, dass der Durchschnitt von Erweiterungen und Eigenentwicklungen in SAP 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

Spezifika von SAP Projekten

Die geringe Qualität von SAP Entwicklungen hat verschiedene Ursachen. Wichtige 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 Testing.
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.

Abbildung 3: Gründe für schlecht wartbaren Code

Vernachlässigung von Qualität in der Entwicklung

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. Wir von sieber&partners haben darauf einen Fokus und verfügen über umfangreiches Wissen. Somit ist ein schneller und sicherer Benchmark möglich.

Wie verbessert man Softwarequalität?

Monitoring der Qualität

Die Verbesserung der Softwarequalität 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 Qualität in der Entwicklung ausgebaut wird, die Richtlinien zusammen mit dem Knowhow der Entwickler verbessert werden, kann schnell eine weitere Verbesserung erzielt werden. Marc André Hahn von sieber&partners beurteilt das so: „Allein die Tatsache, dass es ein regelmässiges Monitoring der Qualität gibt, führt in der Regel zu einer besseren Qualität. Wird dann noch zielgerichtet auf gut 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 langfristige zu deutlich tieferen Wartungskosten“.

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

Messbare Auswirkungen von Qualität

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

Abbildung 4: Einfluss von Qualität auf Aufwand und Durchlaufzeit

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.

Der Invest 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 der Invest in Qualität sich noch im direkten Projekt finanziert und somit der RoI über 1 liegt. Betrachtet auf den Lebenszyklus typischer IT Lösungen liegt er dann bei über 3.

Next Steps

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

Am besten nicht erst hinterher
Wenn hinterher, dann Start mit einer Analyse
Fokus auf selbstgeschriebenen Code
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ässiges Monitoring des Sourcecodes gibt. Periodisch (z.B. alle 2-3 Monate) gibt es eine umfassende Analyse und es werden Massnahmen vereinbart, falls gewisse Kennzahlen nicht die Qualitätsziele erreichen.

Qualität kann nicht in fertige 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 grosse 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

Der Invest in Softwarequalität 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 ISO25010 Norm wie auch weitere Unterlagen einen gut nutzbaren Rahmen vor. 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.

Weitere Qualitätskriterien wie Sicherheit, Usability oder Benutzbarkeit für Endanwender unterschiedlicher Kompetenz und Sprachkenntnisse tragen ebenso zur Reduzierung der Aufwände bei, wurden in diesem Beitrag aber nicht behandelt. Auch dafür stehen spezielle Modelle und Tools zur Verfügung.

Hintergrund zum Software-Qualitätsmodell

Die Software Quality Services sind eine Dienstleistung von sieber&partners in Kooperation mit der Software Improvement Group B.V. und der deutschen TÜV Informationstechnik (TÜViT, Teil des TÜV Nord).

Zertifizierung:
«Trusted Product Maintainability»

Labor:
Nach ISO/IEC 17025 vom TÜViT zertifiziertes Labor für die Messung von Softwarequalität

Gutachten, Beratung und Umsetzung:
Entwicklung der Massnahmen zusammen mit den Kunden, Erstellung von Gutachten.

Die Benchmarking-Datenbank umfasst derzeit (Juli 2020) über 5’000 Systeme und über 36 Milliarden Codezeilen (Lines of Code) in über 285 Programmiersprachen und Dialekten. Die Codebasis für das Benchmarking wächst täglich an. Viele der 5’000 Systeme werden regelmässig neu gemessen. Per Juli 2020 wurden über 295'000 Messungen vorgenommen. Je nach Bedarf der Kunden findet die Messung wöchentlich, monatlich, quartalsweise oder sporadisch statt.