Moduldenke ist von gestern, man muss immer geschäftsprozessorientiert denken. Geschäftsprozesse erstrecken sich immer über mehrere Module. Bestenfalls findet eine tiefergehende Auseinandersetzung mit einer Modulgruppe statt -- so war ich über viele Jahre in der Logistik tätig. Da habe ich viele Jahre lang MM und SD gemacht, bei einem neuen Kunden musste ich dann aber EWM machen. Angefangen hab ich aber in FI/CO, speziell im Öffentlichen Sektor.
Das endete dann bei meinem jetzigen Kunden, bei dem ich ausschließlich HR mache (speziell bAV, also eine Nische in der Nische, wenn man so will). Denen war egal, dass ich HR noch nie gemacht habe, weil es denen auf ganz andere Punkte ankam, und auf die komme ich jetzt zu sprechen.
Als Freiberufler hat man zwei Möglichkeiten: Entweder man ist immer die "verlängerte Werkbank" und arbeitet das ab, was intern nicht geschafft wird. Das ist aber kurzsichtig, weil man so irgendwann immer überflüssig wird.
Viel klüger ist es, wenn man spezielle Kenntnisse hat, die es intern nicht oder zu wenig gibt. Ich habe meine drei letzten Projekte (also meine Projekte der letzten >5 Jahre) nur bekommen, weil das bei mir der Fall ist: Ich verstehe etwas von Softwarequalität, das ist sozusagen mein Alleinstellungsmerkmal, das mich von vielen anderen internen und externen Entwicklern unterscheidet. Ich weiß, wie man einen Unit-Test schreibt, ich weiß wie man mockt, ich kenne das ABAP testdouble framework und kann damit umgehen. Und ich kann Software so schreiben, dass sie gut testbar ist -- das fängt an mit der Isolierung der UI von der Geschäftsprozesslogik. Das bedingt, dass ich OO kenne mit Design Patterns und Interfaces und dem ganzen Abstraktions-Kram drumrum.
Darum bin ich bei meinem jetzigen Kunden, darum wurde ich von meinem vorherigen Kunden eingekauft und bei dem davor. HR oder die Prozesse in einem Blutspendedienst lernt man schneller als OO oder Design Patterns oder Testdouble Framework, zumal dann, wenn man über viele Jahre bewiesen hat, dass man dieses schnelle Lernen leisten kann.
Zur Fortbildung: Natürlich wollen Kunden Entwickler, die seit zehn Jahren Projekterfahrung in S/4 mit Fiori und ODATA haben. Die gibt es aber nicht. Die müssen nehmen, was der Markt hergibt. Im Zweifel müssen sie entscheiden, welche Freiberufler in der Lage sind, neue Technologien schnell zu lernen und diese einkaufen.
Auch da gibt es zwei Möglichkeiten: Entweder man hat das Glück, dass der aktuelle Kunde z. B. auf S/4 umsteigt und man im Zuge dieses Umstellungsprozesses die neuen Technologien lernen kann.
Dieses Glück habe ich derzeit zum Beispiel nicht. Mein derzeitiger Kunde arbeitet derzeit an einem Langzeitprojekt, das im Grunde die Ablösung des SAP zum Ziel hat. Darum werden die z. B. auf 7.5x upgraden, aber auf keinen Fall auf eine HANA-DB umstellen. Damit kriege ich nur noch Nr. 2 hin: Mich fortbilden und wenn es drauf ankommt, überzeugen. Und im Überzeugen von Kunden bin ich ziemlich gut ;) Ich muss es halt "nur" bis ins Gespräch schaffen, mich hat noch nie ein Kunde abgelehnt, nachdem ich mit ihm gesprochen habe.
Insbesondere habe ich meinen jetzigen Kunden davon überzeugt, dass ich derzeit nach einem anderen Kunden suche, bei dem ich 50% meiner Zeit in einem S/4-Projekt arbeiten kann, weil ich das für meine Zukunft brauche. Denn auch wenn dieses Ablösungsprojekt noch einige Jahre dauern wird, werde ich danach nicht in Rente gehen und es kann freilich nicht sein, dass ich dann der letzte SAP-Applikationsentwickler bin, der noch kein S/4 gemacht hat. Das wurde verstanden und akzeptiert, dass ich dann natürlich nur noch 50% für sie arbeiten kann.
Ralf
PS: Wer ein solches S/4-Projekt kennt, wo man 50% mitarbeiten kann, bin ich immer offen dafür -- noch war keines so, dass es mich gereizt hätte, da mitzuarbeiten.