Portfolio

SAP-Beratung

Seit 1996 besteht mein berufliches Leben aus SAP-Projekten aller Grössenordnungen in den unterschiedlichsten Rollen. Angefangen mit einem Inhouse-Job als ABAP-Entwickler in einer Universitätsklinik, weiter über eine langjährige Phase bei mehreren Energieversorgern als externer und interner Entwickler mit Beratungsskill, hin zum freiberuflichen Senior-Berater mit Erfahrung in allen Projektphasen.

Mein Schwerpunkt in dem weiten Spektrum der SAP-Anwendungen liegt dabei auf dem Modul SAP PM (Plant Maintenance / Instandhaltung).

Projektphasen

Project Management

Jedes Projekt beginnt mit einer Projektidee, die aus verschiedenen Quellen stammen können:

  • Es wird festgestellt, dass ein SAP-Modul, dessen Einsatz für das Unternehmen eigentlich generisch ist, noch gar nicht oder nur rudimentär genutzt wird.
  • Es gibt immer noch Prozesse, in denen Daten handschriftlich weitergegeben werden.
  • Ein fachlicher Prozess ist zum Ressourcenfresser geworden.
  • und vieles mehr.

In dieser kreativen Phase gebt es noch keine Umsetzungsstruktur. Zunächst einmal muss ein Entscheidergremium (Projektlenkungskreis) zusammengestellt werden und ein Projektleiter benannt werden. Diese Gruppe trifft sich regelmäßig, um den Projektfortschritt zu begutachten und die nächsten Schritte zu definieren.

Die operative Verantwortung wird durch den Projektleiter wahrgenommen, der je nach Größe des Projekts die Aufgaben auf mehrere Teilprojektleiter deligieren kann.

Pre-Study

Bevor die Implementierung eines oder mehrerer SAP-Module beginnen kann, ist es notwendig, eine Vorstudie durchzuführen, in der zunächst abzuklopfen ist, was der Kunde braucht.

In der IST-Analyse werden die bisherigen Prozesse gewürdigt. Es gibt sicherlich Funktionen, die für bestimmte Zwecke mit viel Herzblut von Mitarbeitern der Firma aufgebaut wurden, und die für sich betrachtet sehr gut funktionieren. Sich von diesen lieb gewonnenen Anwendungen zu trennen, wird für manch einen Kollegen schmerzhaft sein. Deshalb ist es von hoher Bedeutung, gerade diese Erfinder frühzeitig mit ins Boot zu nehmen, zumal sie über ausgeprägtes Expertenwissen in ihrem Fachgebiet verfügen.

Die IST-Analyse wird aber auch schon ans Licht bringen, welche Schwierigkeiten damit verbunden sind, einzelne Applikationen miteinander zu verbinden. Manchmal sind in verschiedenen Abteilungen parallel mehrere gute Lösungen für den gleichen Prozess entstanden. Oder die Daten müssen manuell von einer Anwendung in nachfolgende übertragen werden. Neben dem zeitlichen Aufwand für das Abschreiben machen die hier entstehenden Fehlerquellen das Leben schwer. Als Quintessenz liefert bereits diese Phase Forderungen an die zukünftige Lösung aus Kundensicht.

Ausgehend von den existierenden Problemen („Business Pain“) sowie der Vision der Nutzung eines integrierten Systems (z.B. SAP ERP, SAP S/4 HANA, etc.) als IT-Plattform, werden die untersuchten Geschäftsprozesse neu definiert und im SOLL-Konzept (oder Business Blue Print) dargestellt. Eine erste Idee, wie die Prozesse in Zukunft aussehen können, wird durch einen Experten, der sich mit dem jeweiligen SAP-Modul professionell auskennt, vorgestellt. Die weitere Verfeinerung der SOLL-Prozesse geschieht dann im Dialog zwischen dem Modul-Experten und den Prozessverantwortlichen.

Ein wesentlicher Bestandteil des SOLL-Konzepts ist die Betrachtung der Integration mit anderen SAP-Modulen und Fremdsystemen. So steht ein Instandhaltungsvorgang niemals allein. An einer Wartung oder Reparatur sind Handwerker, Meister und Ingenieure beteiligt, die bestimmten Qualifikationskriterien genügen müssen. Soll dieses Kriterium besonders berücksichtigt werden, muss die Auswirkung auf das Modul SAP HR (Human Resources) betrachtet werden. Ersatzteile, Verbrauchsmaterial und Fremddienstleistungen werden beschafft über SAP MM (Material Management). Kosten werden abgerechnet über SAP FI/CO (Finances and Controlling), und in Projektstrukturen abgebildet (SAP PS). Wenn die technischen Objekte über ein größeres Gebiet verteilt sind, ist die Anbindung eines GIS (Geographical Information System) sinnvoll. Diese Aufzählung kann beliebig erweitert werden.

Von grosser Bedeutung ist in allen Projektphasen eine umfassende Dokumentation, zum einen als Ergebnisprotokoll im Word-Format, zum anderen in Form einer Fortschreibung der Präsentationen im Powerpoint-Format. Die Präsentationen sollten auch Ablaufdiagramme der Prozesse enthalten. Hierfür eignen sich Formate wie BPMN (Business Process Modeling Notation) oder EPC (Event Process Chain).

Je umfangreicher das Projekt ist, je komplexer die Anforderung sind, desto höher ist das Risiko, dass sich Anforderungen ändern und zu Mehraufwänden führen. Die Pre-Study muss auch organisatorische Vereinbarungen enthalten, wie mit Change Requests umgegangen wird. Eine Risikoanalyse kann Anhaltspunkte für einen Aufschlag für Mehraufwände enthalten. Von Anfang an sollte ein Claim Manager aufgesetzt werden, der diese Problematik verfolgt.

Lesen Sie hier über meine Projekterfahrung in der Phase Pre-Study.

Design

Die Pre-Study liefert viele High Level Ideen, die noch nicht detailliert ausgeführt sind. Würde man jetzt sofort mit der Umsetzung beginnen, wäre das mit vielen Rückfragen und Missverständnissen verbunden. Vergleichbar wäre das mit einer Bergwanderung, bei der zwar der Gipfel als Ziel klar vor Augen liegt, aber über den Weg dorthin kein Gedanke verschwendet wird. Zwar ist dem Design bereits eine Aufwandsschätzung vorangegangen, die davor schützt, zu viel des Guten zu tun, aber noch liegen viele Herausforderungen im Verborgenen.

Jetzt sind die Experten am Zuge. Fachliche Berater, die sich auf ein oder mehrere SAP-Module spezialisiert haben, technische Berater, die in der Welt der Bits und Bytes zu Hause sind, und Generalisten, die über alles einen Überblick haben, sind jetzt am Zuge. Jedes Teammitglied hat einen anders geprägten Blick auf das Geschehen, und es braucht Projektmanager, die gleichermassen mit Durchsetzungskraft und Feingefühl ausgestattet und in der Lage sind, Konflikte zu lösen.

Es braucht nicht mehr besonders erwähnt zu werden, dass die Ergebnisse der Design-Phase sorgfältig dokumentiert werden müssen, damit im weiteren Verlauf des Projekts die Ergebnisse mit den Erwartungen übereinstimmen.

Spätestens in dieser Phase sollte auch ein Ticket-System aufgesetzt werden, das bereits Arbeitspakete für alle Umsetzungsschritte, die jetzt und später geplant werden, enthalten. SAP stellt für diesen Zweck den Solution Manager zur Verfügung, es gibt aber auch jede Menge anderer Ticket-Systeme auf dem Markt.

Lesen Sie hier über meine Projekterfahrung in der Phase Design.

Build

Wer will fleissige Handwerker seh’n,
der muss zu uns Entwicklern geh’n.
Bit auf Bit, Bit auf Bit,
die Software ist bald wirklich fit.
(frei nach einem Volkslied)

Wenn gefragt wird, wer ein Haus gebaut hat, werden häufig Architekten genannt. Richtig, schöne Ideen und Pläne gehören auch dazu, aber diejenigen, die sich wirklich ins Zeug gelegt haben, sind Maurer, Dachdecker, Zimmerleute, Installateure, etc. Das sind auch die, welche am besten etwas reparieren können, wenn es Schäden am Gebäude gibt.

Nicht erst wenn alle planerischen Vorbereitungen abgeschlossen sind, dann sind Anpacker gefragt, die eine Vision nicht nur haben, sondern auch umsetzen können. Viele Jahre habe ich mich in diesem Bereich bewegt und kann unzählige Projekt nennen, in denen ich als Entwickler tätig war. Meine Programmierkenntnisse fingen mit 16 Jahren in Basic an, es kamen Pascal, Fortran, Cobol, VBA, C, und schliesslich ABAP Objects dazu.

Sie fragen sich möglicherweise, warum ich heute nicht mehr oder nur noch sehr wenig programmiere. Das hat zwei wichtige Gründe:

  1. Nach vielen Jahren als Entwickler habe ich mir etwas Abwechslung gewünscht. Die dominierende Kommunikation mit der Maschine sollte durch Kommunikation mit Menschen ersetzt werden.
  2. In meinem Alter ist es gut, wenn ich meine Kenntnisse an Jüngere weitergeben kann.

Das soll aber nicht heissen, dass ich vor Projekten zurückschrecke, in denen auch programmiert wird. Insbesondere wenn es dabei etwas neues zu lernen gibt, bin ich gerne dabei.

In der Phase Build zeigt sich die Qualität des Designs. Fehler im Design können sich fatal auf die Qualität des Ergebnisses auswirken. In agilen Projekten kann die Erstellung auf kleinere Schritte aufgeteilt werden. Auf diese Weise können Fehler erkannt werden, bevor ihre Auswirkungen dramatisch werden, und das Design kann leichter angepasst werden.

Lesen Sie hier über meine Projekterfahrung in der Phase Build.

Test

In der Phase Test wird ausprobiert, ob die neu erstellten Funktionen die Erwartungen erfüllen. Den ersten Test (Entwicklertest) wird stets der jeweilige Customizer oder Entwickler durchführen. Erst dann wird er das Ergebnis für den funktionalen Test freigeben.

Für den funktionalen Test sollten Key User bereitstehen, die das Projekt bereits in der Phase Design begleitet haben, und damit über eine Vorstellung von der Funktionsweise der neuen Funktionen verfügen. Diese Personengruppe wird später die Anwenderschulung durchführen und den post-produktiven Support sicherstellen. Es lohnt sich, die Schulungsunterlagen und den Testplan bereits in der Phase Build zu erstellen.

Für den anschliessenden Integrationstest sollten ausreichend viele Endanwender zur Verfügung stehen. Der Test soll auch Drittsysteme einbeziehen, alle Schnittstellen sollen hier berücksichtigt werden. Negative Testergebnisse können Änderungen im Customizing, der Entwicklung, aber auch im Design der neuen Funktionen nach sich ziehen. Je größer die Komplexität des Projekts, desto höher ist das Risiko von Mehraufwänden.

Es ist deshalb sinnvoll, Konzepte aus dem agilen Projekt Management zu übernehmen. Wenn erst ein Teil der Funktionen implementiert ist, aber ein Integrationstest bereits möglich ist, kann bereits mit der Keyuser-Schulung und dem funktionalen Test begonnen werden. Auf diese Weise können Probleme früher erkannt und geheilt werden. Die Komplexität eines Projektes wird dadurch erheblich entschärft.

Lesen Sie hier über meine Projekterfahrung in der Phase Test