„Luzern / Schweiz – Nachdem 3 tägigen Marathon-Turnier im Luzerner Convention Center steht nun der aktuelle SAP-Weltmeister bekannt. Es ist der 34 jährige Gundolf Stelzinger aus Sprockhövel. Er konnte sich in der letzten Runde gegen seinen chinesischen Kontrahenten Chi-Ho Yeung durchsetzen. Vor allem seine detaillierten Kenntnisse der Zusammenhänge zwischen den User-Exits in der Preisfindung und Schnittstelle zum CO-PA verhalfen ihm dazu, seinen knappen Vorsprung zu wahren, und den Titel für sich zu erringen. Auf die Frage unseres Report, welche Projekte er in nächster Zeit annehmen werde, um sein geballtes Wissen gewinnbringend einzusetzen, antwortete der wortkarge Stelzinger, dass er noch nie in einem Projekt gearbeitet hätte „
Natürlich ist der Bericht frei erfunden, und es gibt keinen Gundolf Stelzinger, und natürlich werden in Luzern keine SAP-Weltmeisterschaften ausgetragen (wobei der Gedanke schon süffisant ist). Doch trotzdem stellt sich die Frage: Warum oder unter welchen Umständen würde ein Weltmeister in SAP nie ein Projekt bekommen?
Wenn man sich Gundolf vorstellt, hat er schon etwas von einem Nerd an sich. Er kennt bestimmt jede Transaktion, will aber nichts von einem Workshop hören. Er wird jede Nachrichtenfindung in Windeseile einstellen, wird aber eine Kosten-Nutzen-Analyse meiden. Und letztlich wird er wohl in jedem im Projekt scheitern, wenn er diese 15 Statements loslässt:
1. „Projektplanung – den Plan habe ich im Kopf.“
„Schön, dass du ihn kennst“, würde man Gundolf sofort antworten wollen. Der Projektplan wird nicht nur erstellt, um den Ablauf und die Phasen des Projekts durchzuplanen. Man will eine Kommunikationsplattform und Transparenz für alle beteiligten schaffen, man will einzelne Meilensteine definieren, um Zwischenziele zu messen und letztlich will man die Organisation am Projektplan orientiert aufbauen.
Wenn man der Meinung ist, den Projektplan habe man im Kopf, wird man es in einem SAP-Projekt nicht weit bringen.
2. „Teamfähigkeit – ich bin mein Team.“
Es gibt bestimmt tausende Definitionen für Teamfähigkeit und bestimmt ist keine dieser Definitionen „Ich bin mein Team.“
SAP-Projekte werden immer in Teams durchgeführt, und damit ist eine kooperative, kollegiale und konstruktive Zusammenarbeit essentiell für einen SAP-Berater. Damit bildet das Fehlen von Teamfähigkeit eine gute Grundlage, wenn man es drauf anlegt, in einem Projekt rauszufliegen.
3. Prozessoptimierung – das kommt eh mit SAP.
Ja, vielfach ist es das Ziel von SAP-Projekten Prozesse zu optimieren, zu vereinheitlichen und sie transparenter zu gestalten – doch es ist kein Selbstläufer. Das ERP-System von SAP kann eingesetzt werden, um die Prozesse effektiver zu steuern, aber dafür muss das Projektteam und jeder einzelne Berater dieses Ziel explizit im Auge behalten und nachhaltig verfolgen.
4. Prozessanalyse und -dokumentation – keine Ahnung, das sollen andere machen!
Prozessanalyse ist eine Pflichtübung für SAP-Berater – nicht mehr und nicht weniger. Letztlich muss man sich das wie folgt vorstellen: Du hast einen Klumpen frische und formbare Tonerde in der Hand, und willst daraus eine schöne Blumenvase formen. Nun legst Du voller Elan los und im günstigsten Fall merkst Du nach ein paar Sekunden, dass Du keine Ahnung hast, wie eine Vase aussieht – Uppps!
Mit SAP werden Unternehmensprozesse abgebildet und gesteuert. Und bevor man sich dran macht diese Prozesse mittels SAP zu designen, sollte man sich klar machen, wie diese aussehen und dies auch ausreichend dokumentieren.
5. Entwicklungsvorgaben schreiben – nein danke, SAP ist doch eine Standardsoftware.
Die Ur-Väter von SAP würden dieses Statement wahrscheinlich liebend gerne unterschreiben. SAP ist nun mal eine Standardsoftware, die möglichst nur durch Customizing (Einstellungen) an die Unternehmensbelange angepasst werden soll. Aber leider sieht die Praxis an dieser Stelle anders aus. Die Fachbereiche stellen vielfach Anforderungen, die mit den SAP-Standardfunktionen nicht realisiert werden können, so dass diese Features „nachentwickelt“ werden müssen.
An dieser Stelle kommt dem SAP-Berater die Aufgabe zu, als Schnittstelle zwischen Fachbereich und Entwicklern zu fungieren. Er muss die Anforderungen aufnehmen und sie in Entwicklungsvorgaben formulieren. Diese Vorgaben dienen den Entwicklern als Umsetzungsgrundlage.
6. Kommunikation – wird überbewertet!
Nein Herr Stelzinger, Kommunikation kann man nie überbewerten. Wenn ich mir ein Synonym für SAP-Berater aussuchen dürfte, würde Kommunikator zu meinen Favoriten gehören. Als SAP-Berater steht man im Fokus von verschiedenen Interessengruppen, deren Belange verstanden, weiter kommuniziert, berücksichtigt und umgesetzt werden müssen.
Wenn man sich mit Kommunikation auf unterschiedlichen Ebenen und mit diversen Medien nicht anfreunden kann, dann sollte man seine Brötchen anders verdienen und den Beruf des SAP-Beraters an den Nagel hängen.
7. Englischkenntnisse – SAP ist doch eine deutsche Software.
Mach mal bitte folgenden kleinen Test: Öffne bitte irgendeine gängige Jobbörse im Internet und gib den Suchbegriff SAP-Berater ein. Du wirst wahrscheinlich auf hunderte Treffer stoßen. Wenn Du Dir nun das Anforderungsprofil der Stellenbeschreibungen anschaust, wirst Du wahrscheinlich keine Anzeige finden, wo Englisch nicht vorausgesetzt wird.
SAP wird besonders in großen, multinationalen Konzernen eingesetzt, wo es als Standardsoftware seine Stärken ausspielen kann. Da nun mal in den meisten Unternehmen die Konzernsprache Englisch ist, ist es für SAP-Berater fast Pflicht Englisch zu beherrschen.
8. Networking – damit soll sich das Rechenzentrum beschäftigen.
Wie würdest Du Networking ins Deutsche übersetzen?
Netzwerk, Beziehung, Vernetzen … wohl eher nicht.
Ich würde sagen: Einen guten Draht aufbauen – das trifft es.
SAP-Berater arbeiten mit Informationen und sind auf Informationen angewiesen. Und diese bekommt man nur, wenn man sich peu-a-peu ein gutes und umfangreiches Netzwerk aufgebaut hat.
9. Aufwandsschätzung – wir sind dann fertig, wenn wir fertig sind.
Wenn man es drauf anlegt, schnell und im hohen Bogen aus einem Projekt rauszufliegen, sollte man auf die Frage „Wie lange dauert es und was ist der Aufwand?“ wie folgt antworten: “ … wir sind dann fertig, wenn wir fertig sind …“
Aus langjähriger Erfahrung kenne ich die Szene zu genüge: Der Kunde will immer wissen, was es kostet – und diese Frage ist legitim. Wenn wir in einen Laden gehen und ein paar Schuhe kaufen wollen, dann wollen wir auch genau wissen was sie kosten. Aber im Gegensatz zum Schuhverkäufer steht der SAP-Berater vor dem Dilemma, dass er nicht genau weiß was der Kunde will, und was er ihm anbieten kann. Das Bild sieht eher wie folgt aus: Du kommst in einen riesiges Kaufhaus und fragst an der Infotheke, was kostet es. Der Mitarbeiter an der Info will Dich natürlich nicht vergraulen und fragt vorsichtig nach, was man haben will. Du antwortest, etwas zum Anziehen. Der Verkäufer stellt sich vor, hmmm ein Pelzmantel, aber führen wir sowas überhaupt …
Natürlich könnte man dieses Bild immer weiter spinnen, aber das Prinzip sollte klar sein: Aufwandsschätzungen sind ein schwieriges und „glattes“ Terrain, und um eine valide Aufwandsschätzung zu erstellen, braucht ein SAP-Berater langjährige Erfahrung in seinem Fachgebiet. Trotz dieser Schwierigkeiten sollte ein SAP-Berater dies beherrschen, da die Frage kommen wird: Was kostet es?
10. ABAP lesen und debuggen – ist das ein böhmisches Dorf?
In den letzten Jahren hat sich bei den SAP-Implementationen die Anzahl der Reports, User-Exits oder gar Modifikationen mittels ABAP gravierend erhöht. So ist heutzutage auch für SAP-Berater unerlässlich geworden, dass sie mindestens ABAP-Coding lesen und debuggen können.
Auch wenn der SAP-Berater nicht aktiv an der Entwicklung involviert war, ist das Verständnis von ABAP für die System- bzw. Funktionsanalyse ein Muss.
11. SAP-Schulungen durchführen – das ist doch was für Anfänger.
Im Rahmen eines Projekt-Ablaufs werden neue Prozesse konzipiert, designt, eingestellt und getestet. Und dann kommt die Feuertaufe: Sie müssen eingeführt werden. Hierbei ist ein wesentlicher Punkt, dass die Fachbereiche professionell geschult werden. Auch wenn sich viele SAP-Berater vor diesem Punkt drücken und eher auf das Konzept „train the Trainer“ setzen, wird der SAP-Berater irgendwann doch mit dieser Aufgabe konfrontiert werden. Dann sollte man genau wissen, wie man eine Schulung organisiert, das Schulungssystem aufbaut und die Schulungsaufgaben vorbereitet.
12. In welchem Markt bewegt sich der Kunde – das muss ich nicht wissen.
Ja, da kann man Hr. Stelzinger teilweise Recht geben. Hingegen wird es in SAP-Projekten immer wieder Aufgaben oder Situationen geben, in denen eine detaillierte Kenntnis der Branche / des Marktes viele Vorteile bringt. Bspw. ist es unglücklich, wenn man nicht weiß, dass man im Blumengroßhandel ins Frühjahr keinen Go-Live legen sollte. Oder sie sollten schon darüber informiert sein, ob der Kunde gerad nicht vor der Insolvenz steht.
Die Kenntnis des Marktes, in dem sich das Unternehmen bewegt, ist hilfreich, damit in der täglichen Projektarbeit ein Draht zum Kunden und seinen Anforderungen aufgebaut werden kann.
13. Workshop – ich kann auch ohne Shop worken!
Weiß Gundolf, wie er einen Workshop durchführen muss? – Wahrscheinlich nicht.
Weiß Gundolf, wann es hilfreich ist einen Workshop durchzuführen? – Wahrscheinlich nicht.
Wird Gundolf aus einem Projekt fliegen, weil er das nicht kann? – Auch hier ein entschiedenes: Wahrscheinlich nicht.
Doch trotzdem sollte ein erfolgreicher SAP-Berater genau diese Fragen zum Workshop mit Ja beantworten können. Auch wenn die Planung und Durchführung eines Workshops nicht zu den täglichen Aufgaben eines SAP-Beraters gehören, sollte er in seinem Methodik-Repertoire den „Workshop“ führen. Workshops bieten die Möglichkeit – wenn sie gut vorbereitet und moderiert sind – in einer konzentrierten Form innerhalb einer Gruppe Lösung für ein bestimmtes Problem zu erarbeiten.
14. Präsentation – am GUI sieht man doch alles.
Nein Gundolf, am GUI sieht man „nur“ das Ergebnis. Der ganze Weg, wie man zum Ergebnis gekommen ist, ist da nicht zu sehen.
Es gibt die schöne Aussage „Ein Bild sagt mehr als 1.000 Worte.“ Über die Jahre habe ich immer wieder die Erfahrung gemacht, dass alle Kollegen diese Aussage kennen und als richtig anerkennen; aber nur wenige halten sich an diese Aussage. PowerPoint wird meist nur als Zeichen-Programm für den Nachwuchs eingesetzt. Doch gerade wenn man ein Konzept oder Abschlusspräsentation vorstellt ist eine strukturierte und ansprechende Präsentation das A und O.
15. Konzepte – brauch ich nicht, habe ich alles im Kopf.
Ein strukturiertes und durchdachtes Konzept zu erstellen ist nicht einfach, und man braucht viel Erfahrung und Zeit, um es abzuschließen. Doch um sich langfristig als erfolgreicher SAP-Berater auf dem Markt zu etablieren, ist das Schreiben eines Konzeptes eine Pflichtübung vor der sich fast kein SAP-Berater drücken kann. Es reicht leider nicht, wenn man das Konzept im Kopf hat – es muss schwarz auf weiß in Word stehen.
Fazit
Puuuhhh … werden wohl einige zu Recht sagen – von SAP-Beratern wird einiges abverlangt, und mir kommt sofort das Bild der eierlegenden Wollmilchsau in den Sinn.
Natürlich sieht es in der Praxis nicht schwarz und weiß aus. Abhängig von der Projektrolle des SAP-Beraters (Projektleiter, Integrationsmanager, Solution Architect, Tester, …) und der Phase, in der sich das Projekt aktuell befindet, werden bestimmte Fähigkeiten mehr oder weniger gefordert sein. Aber trotzdem ist meine Erfahrung, dass ein erfolgreicher SAP-Berater einen großen, bunten „Strauß“ an Skills beherrschen muss, um sich auf dem Markt zu behaupten.
Und das schöne ist, dass man diese Fähigkeiten mit der Zeit (vielfach unbewusst) immer besser beherrscht.
* Es wäre toll, wenn du ein kleines Feedback hinterlassen würdest, Isa.