Formularplanung und Qualitätsmanagement

Aus SAP-Wiki
Wechseln zu: Navigation, Suche

Die Formularerstellung ist jedoch sehr häufig ein Thema, was in seiner Komplexität und seinen zeitlichen Anforderungen vom Fachbereich und vom Projektmanagement unterschätzt wird.

In aller Regel weiß der Kunde, er brauchtFormulare (z. B. Rechnung, Lieferschein, Kundenauftrag etc.), einen oder mehrere Formularentwickler, Berater zur fachlichen Unterstützung und den Fachbereich, um die fachlichen Vorgaben zu machen und das Formular zu testen.

Ein Gesamtkonzept gibt es in aller Regel nicht. Wenn es gut läuft, gibt es eine Designvorlage und ein paar Seiten zur Spezifikation - und dann gehts los ...

Dieses Vorgehen funktioniert grundsätzlich. Aber erfordert sehr viel Zeit. Meist gibt es 15 bis 30 Formulare, die praktisch alle laufenden Geschäftsprozesse mit Formularausgaben abdecken. Hier wiederholen sich verschiedene Aufgaben und es lohnt sich, die wiederholen Programm-/Formularteile zu identifizieren und Struktur in die Formularentwicklung zu bringen.

Quick & Dirty versus Struktur

  • Der Kunde sollte sich nicht ausschließlich auf den gewünschten Formularinhalt beschränken, sondern auch kritisch die Arbeit der Formularentwickler prüfen.
  • Wenn die Formularentwickler, Berater und das Projektmanagement immer nach dem Motto „Quick & Dirty“ vorgehen, dann wird schnell nur noch das „Dirty“ übrigbleiben und Formularänderungen in einer fortgeschrittenen Projektphase stets zeitlich aufwendig und fehlerträchtig sein.
  • Geht der Formularentwickler strukturiert vor, modularisiert sauber sein Coding und etabliert Standards, die sich von Formular zu Formular wiederholen, wird die Formularentwicklung in einer deutlich höheren Qualität erfolgen und Anpassungen werden wesentlich schneller und weniger fehlerträchtig sein.
  • Beginnt man gleich den Code in Moduleinheiten (wie Form-Routen oder Methoden) zu schreiben, benötigt das nur minimal mehr Zeit in dieser Anfangsphase, als wenn man den Code in einer sehr großen Programmeinheit untereinander weg schreibt. Am Beginn der Entwicklung gibt es auch keine Gefahr eine bestehende Funktionalität zu verschlechtern, da man erst dabei ist die Funktion zu erstellen. Daher ist dringend zu raten nicht erst auf eine spätere Refakturierung zu spekulieren, sondern gleich mit sauberen Moduleinheiten zu beginnen. Beginnt man gleich mit sauberen Modularisierungseinheiten benötigt man am Anfang nur wenige Minuten mehr, aber später spart man 80% der Zeit bei Fehleranalysen und Anpassungen im Vergleich zu großen Programmeinheiten.
  • Auch das Debugging eines Druckprogramms wird durch das Schreiben von Unterroutinen/Modularisierungseinheiten wesentlich leichter und schneller, weil man beim Debuggen viele Unterroutinen mit F6 als eine Einheit ausführen kann und man erst dann durch in die Unterroutine mit F5 springen muss, die im konkreten Einzelfall von Relevanz ist.
  • Ein kritscher Faktor bei der Formularerstellung kann der Zeitdruck sein, der durchs Projektmanagement vorgegeben wird. Bei komplexen Formularen ist der Zeitaufwand zur Erstellung eines Formulars hoch und nur extrem schwer zu schätzen. Wird ein sehr kurzfristiger Fertigstellungstermin für ein komplexes Formular vorgegeben, noch gern mit den Worten „Komme was wolle, dass muss am .. fertig sein“, dann baut man einen Druck auf, der meist die Codingqualität mindert, am Ende zudem meist auch die Fertigstellung verzögert wird und zur Unzufriedenheit bei allen Parteien führt. Für sehr komplexe Formulare, wie z. B. die Rechnung, benötigen auch erfahrene Formularentwickler mehrere Monate, bis das Formular ausgereift ist. Das Formular wird hier über einen längeren Zeitraum Korrekturen und Erweiterungen erfahren, bis die Zahl der gemeldeten Fehler sehr gering wird.

Refakturierung

  • Der Formularentwickler sollte auch den Mut haben bestehenden „Spagetthi-Code“ zu überarbeiten. Code, wo z. B der Code in einzelnen Programmeinheiten Tausende Codingzeilen umfasst, ist extrem schwer zu warten und jede Programmänderung bringt die Gefahr mit sich, die bestehende Funktionalität massiv zu beeinträchtigen.
  • Es ist jedoch nicht möglich umfangreichen Spagetthi-Code in einem Arbeitsgang in gut strukturierten Qualitätscode zu refakturieren. Die Überarbeitung erfordert Zeit und sollte Stück für Stück erfolgen, mit jeweils Tests, dass die Funktionalität des Formulars nicht beeinträchtigt wurde.
  • Im Buch „Der pragmatische Programmierer“, von David Thomas, Andrew Hunt u. a. wird diese Problemstellung des Spagetthi-Codes, bzw. der Refakturierung sehr schön und nachvollziehbar diskutiert. Man sollte den Code bei jeder Überarbeitung ein wenig besser hinterlassen als man ihn vorgefunden hat.
  • Das beständige Bemühen um besseren Code bewirkt letztlich eine hohe Qualität des Codings und eine sehr gute Wartbarkeit des Codes.
  • Als Faustregel sollte man ca. 10% der Zeit der Formularentwicklung in die Refakturierung des Codes investieren.

Formularplanung

Bei der Formularplanung sind von den Verantwortlichen folgende Fragen zu stellen und zu beantworten.

Anzahl Formulare

  • Welche Formulare werden benötigt?
  • Welche Formulare gibt es bereits und welche sind zu erstellen?

Übersetzungen

  • Welche Ausgabesprachen gibt es?
  • Wer kann die Übersetzungen machen? (Entwickler, Fachbereich, Berater, Übersetzungsbüros)

Wahl der Formulartechnologie

  • Werden die Formulare in SAPscript, Smart Forms oder Adobe Forms erstellt? (SAPscript ist veraltet und sollte für nicht mehr für neue Formulare verwendet werden - mit der Ausnahme, wenn lediglich für SAPscript das Druckprogramm/Formularvorlage vorliegt.
  • Sind es reine Ausgabeformulare oder sollen sie auch interaktiv sein? Nur mit Adobe Interactive Forms könneneingabefähige Formulare erstellen werden.
  • Gibt es im SAP-System bereits einen Java-Stack und wenn nein, kann er aufgesetzt werden, um Adobe Forms einzusetzen?

Formularvorlagen

  • Wer definiert die fachlichen Vorgaben für die Formulare und wer erstellt die Formularvorlagen? (Fachabteilung oder Projektmanagement in Absprache mit Fachabteilung)
  • Welches Papierformat wird verwendet?
  • Müssen die Ausdrucke auch farbig sein?
  • Müssen Formulare auch duplex gedruckt werden?
  • Welche Seitenabstände (links, oben, rechts, unten) und Corporate-Design-Vorgaben sind einzuhalten?
  • Was ist die Standardschriftart (z. B. Arial oder Helvetica)?
  • Welche Standardschriftgröße wird verwendet (z. B. 8 oder 10)? Die verwendeten Schriftgrößen sollten sich immer um mindestens 2 Schriftgrößen unterscheiden, da sie sonst schwer zu unterscheiden sind und unsauber aussehen, also 6, 8, 10, 12, 14. Die Schriftgröße 6 ist schon sehr schwer zu lesen und sollte nur für AGBs oder Fußtexte verwendet werden.

Hardware

  • Können die vorhandenen Drucker ggf. Farbigkeit und Duplex oder müssen neue Drucker angeschafft werden?
  • Wird auf vorgedrucktes Papier gedruckt (inklusive Logo)?

  • Welche Logos müssen dargestellt werden? Gibt es für verschiedene Organisationseinheiten unterschiedliche Logos?
  • Welche Größe und Auflösung sind für die Logos nötig?
  • Wer liefert die Logo-Vorlage als elektronische Vorlage (BMP)?
  • Müssen die Logos farbig gedruckt werden?

Datenversorgung

  • Woher kommen die Daten, die auf den Formularen angedruckt werden?
  • Gibt es genügend Testdaten im Entwicklungssystem oder muss der Entwickler im Q-System seine Ausgaben testen
  • Wer kann den Entwicklern helfen bei der Findung und Pflege der Testdaten?
  • Welche Daten sind im Formular fix und welche sind Variablen, bei denen die Datenversorgung sicherzustellen ist?

Personalressourcen

  • Gibt es mindestens einen Senior-Formularentwickler und einen internen (Formular-)Entwickler, der irgendwann die Formulare weiter betreuen kann?
  • Wer unterstützt von Beraterseite den Formularentwickler? Für die größten Module (meist SD, MM, FI) sollte es feste Berater-Ansprechpartner geben, die den Formularentwickler bei der Datenversorgung unterstützen können und technisches Verständnis haben.
  • Wer testet vom Fachbereich die Formulare? Meist werden das wechselnde Anwender für die verschiedenen Formulare sein.