Meine Projekte - Christian Schwanse

• Auftraggeber: Ich selbst
• Projektziel: Aus eigenem Interesse Blog über Fitness als auch etwas über neue Themen lernen und darüber berichten (z. B. Bügeln). Mit SEO Sichtbarkeit der Webseiten erhöhen und mit bspw. Affiliate-Marketing den ein oder anderen Groschen verdienen.
• Anzahl Projektbeteiligte: 1
• Zeitraum: 07/2017 - 02/2020
• Branche / Bereich: Divers / Webentwicklung
• Rolle: Webseiten-Betreiber
• Sprache: Deutsch
• Ergebnis: Webseiten inklusive Inhalt erstellt. Bei bestimmten, weniger kompetitiven Suchbegriffen auf den Google-Suchseiten 1, 2 oder 3 auffindbar gewesen und dadurch Internet-Besucher weltweit generiert. Aneignung von Wissen über diverse Themen wie:
  • Content-Management-System
  • Domain-Hosting
  • Recht im Internet
  • Marketing (Affiliate-Marketing, Copywriting, Google Ads, SEO, ...)
  • Nicht zu vergessen: Bügeln 😉

  Webseiten wurden am Ende eingestampft, da zu wenig Zeit & Geld verfügbar. Zu dieser Zeit war ich Schüler / Student. Für mehr Optimierungs-Tests und Besucher (die gewinnbringenderen, kompetitiveren Suchbegriffe) hätte ich deutlich mehr Zeit und ggfs. Geld zur Hand nehmen müssen. Die Konkurrenz ist stark gewesen.

• Tech Stack:
  • Content-Management-System: WordPress
  • Auszeichnungssprache: HTML
  • Stylesheet-Sprache: CSS
  • Vektorgrafik-Software: Inkscape
  • Bildbearbeitung-Software: Gimp
  • E-Mail-Marketing-Plattform: Mailchimp
  • Domain-Hosting: All-Inkl
  • Monitoring: Google Analytics
  • Suchmaschinenoptimierung (SEO)

Ich hatte grob eine Idee, was ich machen wollte - eine Webseite, die ich mit Inhalt befülle und anschließend vermarkte.

Ganz am Anfang musste ich mir Wissen über Webentwicklung, Recht und Internet Marketing aneignen. Für die Aneignung des Wissens las ich Bücher, Blogs und schaute Videos auf Youtube an. Themen wie:

1. Wie erstelle ich eine Webseite ohne Programmierkenntnisse?
2. Wie mache ich eine Webseite im Internet auffindbar?
3. Wie bringe ich meine Besucher dazu, meine Webseite zu durchstöbern?
4. Falls etwas nicht funktioniert: Wie optimiere ich? Wie teste ich die Ergebnisse bzw. wie messe ich Kennzahlen?
5. Was gilt es, rechtlich zu beachten?

Die Umsetzung der einzelnen Seiten der Webseite lief wie folgt ab:

1. Suche nach geeigneten Begriffen, die Benutzer im Internet eingeben (Keyword Recherche)
2. Planung des Inhalts der Seite
3. Umsetzung des Inhalts der Seite
4. Optimierung (SEO und Copywriting) der Seite
5. Kennzahlen messen und dokumentieren (z. B. Google Analytics)
6. Falls genügend Besucher: Tests einbauen und durchführen (z. B. A/B-Tests)

Am Anfang steckte ich sehr viel Zeit in die Aneignung des Wissens, bevor ich mich an die Umsetzung gewagt habe. Das hatte drei Gründe:

1. Ich hatte absolut null Ahnung. Je mehr ich wusste, desto mehr wusste ich, dass ich nichts weiß.
2. Vermeidung von aufwendigen Anpassungen im Nachhinein
3. Vermeidung von Verschwendung von Ressourcen (Zeit & Geld)

Ich habe wahnsinnig viel in den unterschiedlichsten Bereichen gelernt. Die 3 wichtigsten Punkte:

1. Es ist gut, einfach mal etwas auszuprobieren und ins kalte Wasser zu springen. Im schlimmsten Falle lieber einen Fehlschlag als Reue, es nicht probiert zu haben.
2. Um Webseiten zu erstellen, zu pflegen, zu optimieren und zu vermarkten gehört viel mehr dazu als man denkt.
3. Steckt man Zeit und Disziplin in etwas, kann man viel mehr erreichen als man sich vorstellen kann.

• Auftraggeber: Führender Hersteller in Bürostuhl-, Loungemöbel- und Automobilindustrie, > 2.000 Mitarbeiter
• Projektziel: Report über alle möglichen Preisfindungs-Konditionen (Transaktion VOK0). Jede Konditionsart hat dabei eine Zugriffsfolge mit mehreren Zugriffen. Jeder Zugriff besitzt eine Datenbanktabelle. Jede Datenbanktabelle hat mehrere Felder bzw. Primärschlüssel. Zur selben Zeit können auch mehrere unterschiedliche Konditionsarten abgefragt werden.
• Anzahl Projektbeteiligte: ~ 4 MA (SAP-Entwickler, SAP-Berater, 2 Tester aus Fachabteilung)
• Zeitraum: 06/2024 - 07/2024
• Branche / Bereich: Bürostuhl-, Loungemöbel- und Automobilindustrie
• Rolle: SAP-Entwickler
• Sprache: Deutsch, Englisch
• Ergebnis: Report, mit dem alle möglichen Preiskonditionen und deren Sätze angezeigt werden können. Es skaliert schön, da neue Preiskonditionen nicht extra programmiert werden müssen. Auch bei Löschung oder Änderung von bereits existierenden Preiskonditionen (inkl. Zugriffsfolge, Zugriffe und Felder) keine Anpassung nötig. Mögliche Fehler während der Verwendung werden abgefangen und Anwender als auch Entwickler mit inhaltsreicher Meldung entsprechend informiert.
• Tech Stack:
  • ABAP (Prozedural, OO)
  • ABAP Eclipse
  • ABAP-Unit-Testing
  • SAP-Reports (ALV)
  • SAP-Standard-Erweiterung (Customizing)

Nachdem die Anforderungen klar waren, hatte ich zuerst ich keine Ahnung, wie ich das Projekt umsetzen soll. Wie schreibe ich einen Report, ohne mindestens 50 Selektionsbildschirme, Datenbankabfragen sowie Ausgabe-Tabellen erstellen zu müssen?

Das wäre unheimlicher Aufwand. Und bei neu hinzugefügten Preiskonditionen als auch wenn neue verändert oder gelöscht werden, ist Wartungsaufwand notwendig.

Als ich das Vorgehen in der Transaktion VOK0 (Preisfindung Customizing) aus der Vogelperspektive auf ein Blatt Papier gezeichnet hatte, kam mir die goldene Idee: Dynamische Programmierung.

Bisher hatte ich damit nur oberflächlich in der Schulung „ABAP für Fortgeschrittene“ der TH Brandenburg (siehe Über mich-Seite, Abschnitt Zertifikate für mehr Informationen) zu tun. Also musste ich mich erstmal ausführlich einlesen und ausprobieren.

Während der Entwicklung wurde viel getestet, dokumentiert als auch Code Refactoring betrieben. Es wurden ebenfalls Unit-Tests geschrieben.

War der Report fertig, wurden die finalen Tests gemacht und der Code als auch die Dokumentation verfeinert. Anschließend stellte ich es vor.

Da jede Preiskondition eine andere Zugriffsfolge inklusive mehrerer Zugriffe mit jeweils unterschiedlicher Datenbanktabelle + Selektionsfelder hat, ist eine manuelle, statische Programmierung nicht möglich.

Zusätzlich kommt auch die Anforderung mehrere Konditionsarten gleichzeitig abfragen zu können. Das wiederum macht das Programm deutlich komplexer (z. B. nur ein Feld namens „Verkaufsorganisation“ im Selektionsbildschirm dynamisch anzeigen lassen, obwohl es mehrmals in verschiedenen Datenbanken vorkommt. Zudem muss die Verkaufsorganisation auch dementsprechend in jeder Datenbanktabelle mitgegeben werden, falls vorhanden).

Das wäre unheimlich viel Schreibaufwand, wenn das Programm statisch geschrieben werden würde. Außerdem würde es auch nicht schön skalieren bzw. bringt bei Preiskonditions-Änderungen viel Wartungsaufwand mit sich.

Da keiner im Betrieb dynamische Programmierung beherrscht hatte, habe ich viel Wert auf Dokumentation und Code Refactoring gelegt. Damit die Programmanpassung durch meine Kollegen möglichst einfach und schnell vonstattengeht - falls ich mir z. B. zu dem Zeitpunkt ein schönes Leben im Ausland mache 😉

Im Report wurde einiges an Fehlerbehandlung betrieben. Damit Anwender als auch Entwickler nicht im Dunkeln gelassen werden. Bei dynamischer Programmierung muss man auch sein Handwerk verstehen, da es z. B. keine Syntax-Prüfung gibt und der Code erst zur Laufzeit festgelegt wird.

Zudem habe ich Unit-Tests geschrieben, damit per Knopfdruck automatisch verschiedene Tests durchlaufen werden. Das erspart nicht nur einiges an Testaufwand. Es erleichtert auch deutlich die Erweiterbarkeit des Programms. Man kann direkt sehen, ob das Programm immer noch so läuft, wie vorgesehen. Das kommt meinen Kollegen als auch mir selbst zugute!

1. Dynamische Programmierung: Zu dem Zeitpunkt des Projektes beherrschte niemand im Betrieb die Technik. Das heißt, ich war auf mich alleine gestellt. Durch Recherche und Ausprobieren weiß ich nun deutlich mehr (dynamischer Selektionsbildschirm, Datenbankabfrage, Ausgabe-Tabelle, ...).
2. Papiergekritzel kann Gold wert sein. Durch die Skizzierung des ganzen Preiskondition-Prozesses konnte ich schnell den gemeinsamen Nenner finden, wodurch die dynamische Programmierung erst möglich wurde.
3. Preisfindung: Preiskonditionen und die Transaktion VOK0 (Preisfindung Customizing) waren mir vorher unbekannt. Ich bin sehr beeindruckt, wie viel dahintersteckt.

• Auftraggeber: Führender Hersteller in Bürostuhl-, Loungemöbel- und Automobilindustrie, > 2.000 Mitarbeiter
• Projektziel: Umstieg von bisherigen ERP-Software Macola auf SAP. Bisher wurde SAP nur in den Werken in Deutschland und Ungarn eingesetzt. Kanada (> 150 MA) soll zwecks Vereinheitlichung nun ebenfalls SAP benutzen. Vorteil ist u. a. einfacheres Controlling bzw. Management von Ressourcen.
• Anzahl Projektbeteiligte: ~ 40 - 60 MA („Normale“ Kanada-Angestellte ausgeschlossen, nur Führungskräfte bzw. Hauptverantwortliche der jeweiligen Abteilungen in Kanada eingeschlossen)
• Zeitraum: 10/2022 - 10/2023
• Branche / Bereich: Bürostuhl-, Loungemöbel- und Automobilindustrie
• Rolle: Hauptentwickler für Formulare (Inhouse). Nebenbei Benutzer- & Berechtigungsverwaltung sowie diversen, kleineren Tätigkeiten unterstützt
• Sprache: Deutsch, Englisch
• Ergebnis (allgemein): Erfolgreiche SAP-Integration in Kanada. Die wichtigsten Prozesse laufen reibungslos ab. Alles Go-Live-kritische in allen möglichen SAP-Modulen (PP, MM, WM / EWM, SD, FI, CO, ABAP, BASIS) abgedeckt. Nach Go-Live kleinere Optimierungen / Schulungen.
• Ergebnis (in Bezug auf meine Rolle): Erfolgreiche Entwicklung von mehr als 8 Formularen in diversen SAP-Modulen (Rechnung, Auftragsbestätigung, Frachtbrief, Zollrechnung, Kundenbeschwerde, ...), welche im gesamten Kanada-Werk eingesetzt werden. Darunter Anpassung von bereits existierenden als auch neu entwickelten Formularen. Umstellung des Papierformates DIN A4 auf Letter bzw. kanada-spezifische Maßen. Nach Go-Live kleinere Optimierungen.
• Tech Stack (in Bezug auf meine Rolle):
  • ABAP (Prozedural, OO)
  • XML
  • SAP-Formulartechnologie Adobe Forms (druckbasiert, nicht interaktiv)
  • SAP-Reports (ALV, Queries)
  • SAP-Druckerverwaltung
  • SAP-Berechtigungs- & Benutzerverwaltung
  • SAP-Standard-Erweiterungen (Code als auch Customizing für Nachrichtenarten / Druckersteuerung)

Das war mein erstes, großes SAP-Projekt. Am Anfang des Rollouts war ich ein SAP-Neuling. Ich hatte zwar vorher schon abseits von SAP mit Software-Entwicklung zu tun, aber SAP (technisch als auch funktional) war mir größtenteils noch fremd.

Von unserem Senior-Entwickler hatte ich eine kleine Einführung in die Formular-Entwicklung bekommen - generell und in Bezug auf die bisherige Code-Basis des Unternehmens. Dieser hatte bisher nur mit den Vorgänger-Formulartechnologien SAPscript und Smart Forms zu tun.

Um die aktuellste Formulartechnologie Adobe Forms und weitere Zusammenhänge zu verstehen, arbeitete ich mich eigenständig in die Thematik mithilfe des Buches „SAP Interactive Forms by Adobe“ von SAP Press ein.

Weitere Themen wie Customizing der Nachrichtenarten, SAP-Druckersteuerung und funktionale Zusammenhänge / Prozesse wurden mir von Kollegen meiner Abteilung beigebracht.

Die Planung von Entwicklungen fanden mit den jeweiligen SAP-Beratern und Abteilungen statt. Meine technischen Fragen klärte unser Senior-Entwickler, Google oder das SAP-Formularbuch. Waren die Anforderungen geklärt, ging es an die Entwicklung.

Meine Entwicklungen, Tests usw. dokumentierte ich ausführlich. Die Dokumentationen standen dem ganzen Projekt-Team zur Verfügung. Die Tests führte ich während der Entwicklung selbst durch und danach mit den jeweiligen Abteilungen und SAP-Beratern.

Meine Entwicklungen dokumentierte ich ausführlich (Word als auch innerhalb des Codes), um nachträgliche Anpassungen meinerseits oder durch meine Kollegen zu vereinfachen und zu beschleunigen.

Dabei legte ich großen Wert auf Übersichtlichkeit und Warum-Kommentare (bspw. Warum wurde genau dieses Feld in der Transaktion XYZ verwendet und nicht ein anderes?).

Ebenfalls benutzte ich objektorientiertes ABAP. Unsere bisherigen Formulare wurden größtenteils prozedural umgesetzt (FORM-Routinen, Funktionsbausteine, ...).

Objektorientierte Programmierung hatte gegenüber der prozeduralen Programmierung große Vorteile wie:

• Intuitiverer Code, da Objekte in der realen Welt nachgeahmt werden
• Vererbung, wodurch Code-Wiederverwendung möglich wird (z. B. bei einheitlichen Kopf- und Fußzeilen von Formularen)
• ABAP OO hat eine strengere Syntaxprüfung als prozedurales ABAP und lässt somit weniger Bugs und schöneren, lesbareren Code zu.
• Modularität. Es bleibt zusammen, was zusammengehört.
• Aufgrund der oben genannten Vorteile ist die Software insgesamt skalierbarer und die Wartung / Erweiterung effizienter. Es gibt noch mehr Gründe, warum die Software mit ABAP OO skalierbarer und wartbarer wird.

1. Projektmanagement: Wie plane und führe ich ein Projekt? Welche Punkte müssen hinsichtlich Formularentwicklung beachtet werden? Wie dokumentiere ich ein Projekt?
2. Wie gehe ich mit Stress und Verantwortung um? Es war großer Zeitdruck während der Entwicklung. Schlaflose Nächte inklusive.
3. Formularentwicklung: Funktional (z. B. Wareneingang, Warenausgang, Fertigung, Bestellung) als auch technisch (Nachrichtenarten, Druckprogramm, Schnittstelle, Layout, Drucker, ...)