Die funktionale Spezifikation im SAP-Projekt

2017-02-04

Kein SAP-Projekt ist frei von Zusatzentwicklungen. In kleinerem oder größerem Umfang sind sie immer notwendig - und sei es nur die unternehmensspezifische Anpassung von Formularen wie Rechnungen oder Lieferscheinen, die technisch als "Entwicklungen" abgewickelt werden.

Alle Zusatzentwicklungen sollten ausnahmlos schriftlich spezifiziert werden - gerade weil ich die Sagen und Legenden natürlich kenne, die an den Hotelbars dieser Welt erzählt werden, wo heldenhaft programmierende Berater unter Aufbietung ihrer letzten Kräfte durch undokumentiertes Anpassen von MV45AFZZ gigantische Großprojekte vor dem kläglichen Fehlschlag gerettet haben.

Gerade dieses Beispiel zeigt aber eine Tatsache deutlich:

Die Mehrheit der Entwicklungen in einem SAP-Projekt sind Kleinstentwicklungen. User-Exits von 5 Zeilen Länge. Formularanpassungen, bei denen lediglich das Logo ausgetauscht wird. Standard IDOC-Schnittstellen bei denen es einen Entwickler braucht, um die IDOC-Partnervereinbarung anzulegen. (Es gibt ein ungeschriebenes Gesetz, dass funktionale Berater das nicht können dürfen. Ich habe bis heute nicht verstanden, warum.) Die Projektabläufe zum Umgang mit Entwicklungen werden dem aber - gerade in größeren Projekten - nicht gerecht. Da wird davon ausgegangen, dass für jede Entwicklung eine kiloschwere Spezifikation in ferne Länder geschickt wird, die dann von jungen weisen aufstrebenden Programmier-Superstars agil cloudbasiert mit Big-Data in innovative Lösungen umgesetzt werden. Nichts könnte ferner der Realität sein als das!

Klassischerweise unterscheidet man folgende Arten von Entwicklungen:

• (R)eports. Kundenspezifische Berichte. Früher meistens als kundeneigene Reports direkt im ERP-System programmiert. Diese werden heute in aller Regel als BI-Reports umgesetzt.
• (I)nterfaces. Schnittstellen. Hier gibt es eine Reihe möglicher Technologien mit unterschiedlichen Vor- und Nachteilen. Entscheidend ist jedoch: kann eine vorhandene Standardschnittstelle genutzt werden, muss eine solche speziell angepasst werden oder muss eine komplett kundenspezifische Schnittstelle neu entwickelt werden?
• (C)onversion. Hier geht es um die Migration von Daten (Stamm- und Transaktionsdaten) aus Altsystemen. Diese müssen konvertiert werden, wenn sie in die SAP-Lösung migriert werden. Dazu braucht es geeigente Lösungen, die in aller Regel unter Nutzung geeigneter Werkzeuge individuell programmiert werden müssen.
• (E)nhancements. Die SAP-Standardfunktionalität soll erweitert werden. Dazu hat SAP über die Jahre eine Reihe von Technologien (z.B. User-Exit, BADI, Enhancement) zur Verfügung gestellt, die je nach Anforderung zum Einsatz kommen.
• (F)orm. Formulare. Vorhandene Standardformulare müssen immer unternehmensspezifisch angepasst werden. Manchmal gibt es auch spezielle unternehmensspezifische Prozesse, die durch neue Formulare unterstützt werden. Die klassische Technologie war hier SapScript, dazwischen gab es kurz Smartforms, inzwischen sollten sämtliche Formulare nur noch per Adobe Forms Technologie erstellt werden.
• (W)orkflow. Workflow-Prozesse unterstützen transaktionalie Prozesse immer da, wo ein Vorgang arbeitsteilig von mehreren Bearbeitern nacheinander abgewickelt werden muss. Klassisches Beispiel ist die Bestellfreigabe.

Nach den Anfangsbuchstaben dieser Kategorien wird die Spezifikation von Zusatzentwicklungen gerne RICEFW genannt.

Auf der ersten Seite eines solchen Dokuments befindet sich bei den meisten Unternehmen eine Tabelle, auf der man irgendwelche angeblichen Eigenschaften dieser Entwicklung kurz angeben soll. Abgesehen davon, dass die Word-Vorlagenentwickler der meisten SAP-Projekte die Formularfunktionen in Word sowieso nicht beherrschen und das Formular damit meistens auch nicht funktioniert, halte ich es auch inhaltlich für überflüssig:

• der sogenannte GAP-Prozess (dazu ein anderes mal mehr), der die Freigabe von Zusatzentwicklungen regelt, sollte zeitlich vor dem Verfassen der Detailspezifikation abgeschlossen sein. Daher sind GAP-relevante Informationen (z.B. über mögliche Alternativlösungen) in der Spezifikation sowieso zu spät.
• eine kurze Zusammenfassung, was eine Entwicklung leisten soll, benötigt keine Tablle, sondern besser ein kurzes Zusammenfassungskapitel.

Anschließend wird beschrieben, was die Entwicklung leisten soll. Und zwar so, dass ein Entwickler keine Ratespiele mehr veranstalten muss. Das bedeutet eine Menge Detailarbeit. Ein klassisches Beispiel aus der Formularentwicklung ist beispielsweise bei Rechnungsformularen der Positionskurztext. Ist das:

• der Kurztext der Fakturaposition?
• der Kurztext des Artikels der Fakturaposition in Formularsprache?
• der Verkaufs-Langtext des Artikels der Fakturaposition in Formularsprache - wenn nicht vorhanden in Englisch, wenn nicht vorhanden in Deutsch, wenn nicht vorhanden der Kurztext?

An dieser Stelle sei insbesondere auf rechtliche Anforderungen in Dokumenten hingewiesen (Pflichtangaben in Rechnungen!), die unbedingt in die Spezifikation gehören!

Der Spzeifikationsteil sollte darauf verzichten, bereits Namen für angeforderte Objekte zu vergeben ("benötigt werden zwei Tabellen ZAEPFEL und ZBIRNEN"), da der Entwickler es doch anders implementieren könnte ("ZOBST") oder gar muss, wenn z.B. Namenskonventionen es anders erfordern ("/ACME/Z_O_FRUIT_0B").

Meistens ist es zum Zeitpunkt der Erstellung der Spezifikation schwierig, konkrete detaillierte Testvorgaben zu machen, da notwendige Stammdaten in aller Regel noch nicht definiert sind. Dann sollte aber zumindest die Vorgehensweise zum Testen der Entwicklung vorgezeichnet werden.

Bevor eine Entwicklung umgesetzt wird, sollte die Spezifikation einem intensiven Review-Prozess unterworfen sein. Einmal fachlich, wo ein Abgleich der spezifizierten Entwicklung mit den fachlichen Anforderungen im Zentrum der Analyse stehen sollte, einmal technisch, wo es um einen zentralen Punkt geht:

Ist diese Entwicklung in dieser Form tatsächlich notwendig?

Gibt es einfachere Lösungen? Kann nicht doch eine Standardfunktionalität genutzt werden?

Wir sind hier an einem Punkt, den ich nach vielen Jahren Betreuung und Verantwortung für Zusatzentwicklungen nicht laut genug betonen kann. Es ist für mich das Grundgesetz der SAP-Zusatzentwicklung:

Jede zusätzliche Zeile ABAP-Code in einem produktiven SAP-System ist ein potenzielles Unternehmensrisiko.

Zusatzentwicklungen in SAP sind keine Assets, sie sind Liabilities!

Und damit nur da angebracht, wo sie wirklichen Nutzen entfalten und nicht durch vorhandene Standardfunktionalität ersetzt werden können.

Eigentlich müsste ein Unternehmen bei jeder genehmigten Zusatzentwicklung eine Rückstellung für den erwarteten Pflegeaufwand bilden. Denn der kann manchmal gigantisch werden - auch wenn es derjenige, der die Entwicklung veranlasste noch so gut meinte.

Kommen wir noch zu ein paar Punkten in Bezug auf die Dokumentation:

Ich bin ein Freund von Sammelspezifikationen. Dort, wo es sinnvoll ist, viele gleichartige Kleinentwicklungen zusammenzufassen: Preisfindungsformeln, Kopiersteuerungsbedingungen, Nachrichtensteuerungsbedingungen, Profit-Center-Substitutionen. Das sind Dinge, die der Übersichtlichkeit halber in einem vorab definierten Dokument zusammengefasst werden sollten. Auch um den politischen Diskussionen zu entgehen, wenn im Integrationstest auffällt, dass ein bestimmtes Problem nur durch eine neue Preisfindungsformel gelöst werden kann. Das ist keine neue Entwicklung. Das ist eine Fehlerkorrektur.

Damit kommen wir zur Umsetzung der Spezifikation in Software. Ich habe da immer eine klare Regel: zu jeder Spezifikation (die bekommt eine Nummer), gibt es im SAP-System ein sogenanntes "Paket" mit der gleichen Nummer. (Früher hiessen die "Entwicklungsklassen"). Damit findet man ganz leich alle Entwicklungen wieder, die zu einer Spezifikation gehören. Sie erkennen einen schlechten Entwickler daran, dass er diese Regel nicht mag. (Ja, ich weiß, es gibt ein paar Ausnahmen.)

Anstatt einer separaten technischen Spezifikation bevorzuge ich aus Übersichtsgründen ein separates Kapitel in der funktionalen Spezifikation wo niedergelegt wird, welche Entwicklungsobjekte angelegt wurden und wie die zusammenhängen. Entscheidend ist, diese Objekte zu finden. Eine genauere Beschreibung braucht es selten, denn ABAP-Code kann man lesen und verstehen.

Im letzten Artikel gehe ich zusammenfassend auf die Rolle von Methoden-Frameworks ein.