Ein spannendes Interview über das Leben als Consultant mit Nina Sauermann gibt es in der einhundertelften Episode des Anwendungsentwickler-Podcasts.
TL;DR
Mit SAP-Beraterin Nina Sauermann spreche ich darüber, wie du nach der Ausbildung zum/zur Fachinformatiker:in Anwendungsentwicklung ins Consulting einsteigen kannst. Je nach Projekt gehört dazu viel ABAP-Code, während du in anderen Projekten vor allem Anforderungen klärst und mit Kund:innen sprichst. Dafür brauchst du fachliches Wissen und die Fähigkeit, technische Fragen verständlich zu vermitteln. Wechselnde Projekte bringen neue Erfahrungen mit sich; zum Arbeitsalltag gehören auch kurzfristige Überstunden und Dienstreisen, die dein Privatleben belasten können.
Podcast: Play in new window | Download (Duration: 1:21:44 — 36.2MB)
Abonnieren: Apple Podcasts | Spotify | RSS
Kapitelmarken
- [00:00:00] Einführung ins Interview über Consulting
- [00:01:15] Nina Sauermann und ihr Weg zur Anwendungsentwicklung
- [00:05:07] SAP HCM und Erfahrungen mit der Zeitwirtschaft
- [00:08:37] Fachliche Regeln am Beispiel eines Bonussystems
- [00:11:17] ABAP und weitere Technologien im SAP-Umfeld
- [00:13:10] Systemzugriff und Rechte beim Entwickeln
- [00:14:45] Transaktionen und Programmnamen
- [00:17:11] SAP und kundenspezifischer Code
- [00:18:30] Einstieg in den Beruf als SAP-Beraterin
- [00:21:03] Anforderungen klären und Aufwand vermitteln
- [00:25:01] Schulung zu Kommunikation und Auftreten
- [00:27:44] Wie viel Programmieren zum Consulting gehört
- [00:28:53] Projekte vorbereiten und technische Begriffe klären
- [00:32:58] SAP-Standard an betriebliche Abläufe anpassen
- [00:35:55] SAP ohne eigene Entwickler:innen betreiben
- [00:38:01] Daten finden und mit der SAP-Hilfe arbeiten
- [00:40:15] Zeit zum Einarbeiten und Module wechseln
- [00:43:35] Fachwissen und der Einstieg als Junior-Berater:in
- [00:46:25] Aufgaben und Betreuung während der Ausbildung
- [00:47:23] Dienstreisen und Remote-Arbeit
- [00:50:43] Warum Unternehmen externe Berater:innen beauftragen
- [00:53:22] Widerstand gegen zusätzliche Freigaben
- [00:55:50] Systeme zum Testen und Transportaufträge
- [00:58:42] Nachwuchs für SAP und ABAP finden
- [01:03:06] Selbstsicher auftreten und Vertrauen gewinnen
- [01:07:04] Neue Aufgaben und unregelmäßige Arbeitszeiten
- [01:09:02] Wie Kund:innen die Arbeit kontrollieren
- [01:10:22] Dienstreisen und ihre Folgen fürs Privatleben
- [01:13:32] Zeit für Städte und gemeinsame Unternehmungen
- [01:14:50] Gespräche führen und Small Talk üben
- [01:18:48] Lieblingsprogrammiersprache und Kontakt zu Nina
- [01:20:39] Shownotes und Feedback
Inhalt
Folgende Fragen haben wir u.a. im Verlauf des Gesprächs geklärt.
Consulting
- Was ist eigentlich ein Consultant?
- Was macht ein Consultant den ganzen Tag?
- In welchem Bereich bist du als Consultant unterwegs?
- Wie bist du zum Consultant geworden?
- Welche Skills sollte man mitbringen, wenn man Consultant werden möchte?
- Welche Rolle spielen Soft Skills in deinem Arbeitsalltag?
- Erwarten Kunden von dir, dass du die Technik komplett beherrschst oder darfst du auch mal etwas nachfragen?
- Wie laufen Consulting-Projekte ab?
- Warum engagieren deine Kunden dich, anstatt einen eigenen Mitarbeiter einzustellen?
- Bist du ständig auf Reisen oder hast du auch mal einen „normalen“ Alltag?
- Besteht dein Alltag nur aus Meetings oder setzt du auch etwas um?
- Welchen Teil deiner Arbeitszeit musst/darfst du in Weiterbildung investieren?
- Wie bildest du dich weiter, um die bestmöglichen Lösungen für deine Kunden zu finden?
- Was gefällt dir an deinem Job als Consultant?
- Was magst du nicht an deinem Job als Consultant?
- Hast du Literaturempfehlungen für den Bereich Consulting?
Literaturempfehlungen
Im Nachgang hat Nina mir noch diese Buchempfehlung geschickt für alle, die in die Programmierung mit ABAP einsteigen möchten: Schrödinger programmiert ABAP*.
Links
- Permalink zu dieser Podcast-Episode
- RSS-Feed des Podcasts
- Nina bei fachinformatiker.de
- Nina bei XING
Zusammenfassung
Ninas Weg ins SAP-Consulting
Für einen Einblick in den Beruf habe ich Nina Sauermann interviewt, die seit 2013 als SAP-Beraterin arbeitet. Sie hat zuvor eine Ausbildung zur Fachinformatikerin Anwendungsentwicklung bei der Hypovereinsbank abgeschlossen.
Ursprünglich hatte Nina sich für die Fachrichtung Systemintegration beworben. Nach einem Tag in der Entwicklungsabteilung und einer persönlichen Pro-und-Contra-Liste entschied sie sich für Anwendungsentwicklung, weil sie dort mehr Neues lernen konnte. Ihr erster Kontakt mit SAP war durch die vielen Informationen anstrengend.
In der Ausbildung arbeitete sie mit dem Personalmodul HCM, ausgeschrieben Human Capital Management. Dort beschäftigte sie sich unter anderem mit Arbeitszeiten und Lohnabrechnungen. Ihre Ausbilderin wählte passende Aufgaben aus und besprach mit ihr, wie sie diese umsetzen konnte. Direkten Kontakt zum Fachbereich hatte Nina vor allem bei ihrem Abschlussprojekt.
Fachliche Regeln verstehen und in Code abbilden
Wenn ein nächtlicher Job für die Zeitwirtschaft ausfiel, fehlten am nächsten Morgen die gebuchten Arbeitszeiten. Dadurch entstanden viele Tickets. Manche Mitarbeiter:innen trugen ihre Zeiten selbst nach, wodurch nach dem nächsten erfolgreichen Job doppelte Buchungen entstanden.
Bei einem späteren Projekt sollte Nina ein Bonussystem überarbeiten, das auf manuell ausgefüllten Excel-Listen beruhte. Dabei waren Boni an Personen ausgezahlt worden, die laut Vertrag keinen Anspruch hatten. Auch verstorbene Mitarbeiter:innen erschienen noch in den Vorschlägen.
Mit dem Fachbereich besprach Nina ausführlich, unter welchen Bedingungen jemand einen Bonus erhalten durfte. Der Code musste diese Regeln vollständig abbilden, damit berechtigte Personen ihren Bonus bekamen und unzulässige Zahlungen ausgeschlossen wurden. Solche Aufgaben verlangen, dass du die fachlichen Zusammenhänge verstehst.
Mit ABAP im SAP-System entwickeln
Nina programmiert beruflich ausschließlich mit ABAP. In ihrer Ausbildung lernte sie außerdem Java und erhielt eine Schulung zu COBOL. Je nach SAP-System und Modul kommen auch Java-Komponenten vor. UI5 und Fiori werden im Gespräch als Technologien für neuere Oberflächen und Apps genannt; damit arbeitete Nina zum Zeitpunkt des Interviews selbst noch nicht.
Für ihre Arbeit braucht sie Zugriff auf das jeweilige SAP-System. Die Entwicklungsumgebung ist darin integriert. Nina arbeitet in der Transaktion SE80, in der sie Programme schreiben und direkt ausführen kann.
Eine Transaktion kann auch als Aufruf für ein Programm dienen. Anwender:innen geben dann den Transaktionsnamen ein und starten darüber das Programm, ohne es in der Entwicklungsumgebung suchen zu müssen.
Zu den beschriebenen Rahmenbedingungen gehören:
- Viele Kund:innen betreiben für HCM ein eigenes System. Der Zugriff hängt davon ab, welches System freigegeben ist.
- Quellcode konnte Nina in ihren Projekten meist einsehen. Zum Ändern brauchte sie einen zusätzlichen, bei SAP registrierten Schlüssel, der mit Lizenzkosten verbunden war.
- Eigene Programme beginnen mit Y oder Z. Kund:innen können auch einen eigenen Namensraum kaufen.
- Nina beschreibt, dass SAP kundenspezifischen Code unter den vereinbarten Bedingungen in den Standard übernehmen kann.
Im Gespräch zeigt sich außerdem, wie unterschiedliche Begriffe technische Gespräche erschweren können. ABAP- und Java-Entwickler:innen diskutierten längere Zeit über denselben Sachverhalt, bis Nina zwischen ihnen vermittelte. Als Beispiel nennt sie Wahrheitswerte, die in ihrem ABAP-Alltag häufig durch ein Zeichenfeld mit X beziehungsweise einem leeren Inhalt dargestellt werden.
Was du im Consulting machst
Ninas Einstieg führte sie früh zu Kund:innen. Die angekündigte längere Phase mit Schulungen wurde verkürzt, sodass sie zunächst kleinere Programmieraufgaben übernahm und kurz darauf an umfangreichen Projektgesprächen teilnahm.
Als Berater:in klärst du mit Kund:innen, was ein Programm leisten soll und welchen Aufwand das verursacht. Häufig sprichst du dabei mit Personen, die ihre fachlichen Ziele kennen und wenig technisches Wissen mitbringen. Du musst nachvollziehbar vermitteln, warum eine Aufgabe beispielsweise zehn Tage dauert und welcher Aufwand hinter einem gewünschten Ergebnis steckt.
Wie viel Zeit du mit Code verbringst, hängt vom Projekt ab. Nina schätzte ihren Anteil zum Zeitpunkt des Interviews auf etwa 80 Prozent. In anderen Projekten hatte sie viele Besprechungen und Telefonate, gegen Projektende teilweise zwei einstündige Telefonkonferenzen pro Tag.
Vor einem Termin sind der grobe Umfang und erste Konzepte meist bekannt. Mitarbeiter:innen im Vertrieb klären vorab Wünsche und fragen nach, wie viel Zeit die Arbeit erfordert. Im Termin werden anschließend Details und Termine besprochen. Nina erlebte auch kurzfristige Einsätze, bei denen sie erst vor Ort erfahren sollte, was zu tun war.
Mit Kund:innen sprechen und auftreten
Eine einwöchige Schulung behandelte, wie Nina E-Mails formuliert und Fehler bei Kund:innen diplomatisch anspricht. Auch Kleidung und Verhaltensregeln wurden geübt. Beim ersten Besuch erschien sie grundsätzlich formell gekleidet; bei weiteren Terminen orientierte sie sich am jeweiligen Umfeld. Gerade bei Banken und Versicherungen gehörte entsprechende Kleidung dazu.
Präsentationen müssen zu den teilnehmenden Personen passen. Für eine Geschäftsführung bereitest du Inhalte anders auf als für Entwickler:innen.
Nina betont außerdem, wie wichtig es ist, sicher aufzutreten und für die eigene Arbeit einzustehen. Als junge Beraterin wurde sie teilweise zunächst wenig ernst genommen. In einem Projekt schrieb ein Kunde trotz ihrer Antworten weiterhin ausschließlich ihrem erfahrenen Kollegen. Nachdem Nina die Fragen über zwei Wochen hinweg bearbeitet hatte, wandte er sich direkt an sie.
SAP an betriebliche Abläufe anpassen
SAP bietet Standardprozesse, während Betriebe eigene Anforderungen mitbringen. Diese werden durch Customizing oder zusätzlichen Code abgebildet.
Ein Beispiel aus Ninas Ausbildung betrifft das Spenden der Cent-Beträge des Nettogehalts. Ihr Ausbildungsbetrieb wollte das Geld selbst sammeln und um denselben Betrag ergänzen. Dafür wurde die vorhandene Funktion entsprechend angepasst.
Solche Änderungen kosten Geld. Manche Unternehmen übernehmen deshalb die vorgegebenen Abläufe und beschäftigen keine eigenen SAP-Entwickler:innen. Für Mitarbeiter:innen sind dann Schulungen hilfreich, damit sie sich im System zurechtfinden. Beim Customizing lassen sich außerdem überflüssige Felder ausblenden, wodurch Masken übersichtlicher werden.
Neues lernen und Projektzeit abrechnen
Daten liegen in SAP an vielen Stellen. Bevor Nina Code schreibt, muss sie häufig herausfinden, wo die benötigten Informationen gespeichert sind. Das kann mehr Zeit beanspruchen, als der fertige Code vermuten lässt.
Dabei helfen Kolleg:innen mit Erfahrung in verschiedenen Modulen. Über F1 ist die Hilfe direkt aus dem Quellcode erreichbar. Sie enthält auch veraltete Befehle, sodass du lernen musst, welche Angaben im jeweiligen Kontext passen.
Nina wechselte im Laufe ihrer Arbeit von HCM zum Solution Manager und später in weitere Bereiche, darunter BW sowie Themen rund um Materialwirtschaft und Finanzbuchhaltung. Dafür erhielt sie beim neuen Arbeitgeber fast einen Monat lang fachliche Grundlagenschulungen.
Ob Zeit zum Einarbeiten Kund:innen berechnet wird, hängt vom Auftrag ab. Bei einer Unicode-Umstellung war von Anfang an klar, dass das Team fremde Programme untersuchen musste. Diese Zeit gehörte zum Projekt. Wenn Nina wegen eines neuen Fachgebiets eigene Wissenslücken schließt, bucht sie entsprechende Zeit teilweise intern. Solche Fragen klärt sie mit der verantwortlichen Person.
Zu Beginn ihrer Laufbahn wurde ihre Teilnahme an Kundenterminen zum Lernen zunächst nicht in Rechnung gestellt. Später wurden ihre Leistungen als Junior-Beraterin zu einem niedrigeren Satz abgerechnet als die eines/einer Senior-Berater:in.
Warum Unternehmen externe Berater:innen beauftragen
Oft brauchen Unternehmen für eine begrenzte Aufgabe zusätzliche Personen. Ein Auftrag kann nach einem Monat abgeschlossen sein. Bei der beschriebenen Unicode-Umstellung dauerte das Projekt mehrere Monate; die internen Entwickler:innen mussten währenddessen ihr Tagesgeschäft weiterführen.
Externe Berater:innen übernehmen solche Aufgaben für die Dauer des Projekts. Wie schnell sie produktiv arbeiten können, hängt auch davon ab, ob die nötigen Zugänge bereitstehen und die Zusammenarbeit vor Ort funktioniert.
Änderungen testen und freigeben
Nina beschreibt eine SAP-Landschaft mit einem Entwicklungssystem, einem System für die Qualitätssicherung und einem Produktivsystem. Änderungen werden zunächst entwickelt und anschließend getestet, bevor sie produktiv gehen. Manche Unternehmen betreiben zusätzlich eine Sandbox.
Freigaben und Rechte werden unterschiedlich streng gehandhabt. Mit dem Solution Manager lässt sich beispielsweise ein Ticket verlangen, das die geplante Änderung beschreibt, bevor ein Transportauftrag erstellt werden kann.
Bei einem Kunden sollte Nina gemeinsam mit einer Kollegin ein Verfahren einrichten, bei dem zwei Personen einen Transport freigeben mussten. Ein Verantwortlicher wehrte sich gegen die zusätzlichen Schritte und diskutierte so lange darüber, dass beide nach zwei Tagen ohne Ergebnis abreisten.
Nachwuchs für SAP und ABAP
In Ninas früherer Firma arbeiteten etwa 75 Berater:innen, darunter ungefähr fünf Entwickler:innen. Viele beschäftigten sich mit fachlichen Fragen und Customizing. Nina betreute dort mindestens fünf, eher sieben Projekte gleichzeitig.
Der Einstieg in ABAP erfordert ein SAP-System. Eine Testversion zu Hause einzurichten ist aufwendig. Im Gespräch wird außerdem beschrieben, dass frühere Pläne, stärker auf Java umzustellen, das Interesse an ABAP beeinflusst hatten.
Ninas damaliger Arbeitgeber mit 16 Personen bildete selbst nicht aus, weil die häufig reisenden Kolleg:innen keine verlässliche Betreuung im Büro gewährleisten konnten. Neue Mitarbeiter:innen kamen unter anderem nach einem Studium hinzu und arbeiteten sich in SAP ein.
Unterwegs arbeiten und mit Belastungen umgehen
Wie oft du reist, hängt von den Kund:innen und Projekten ab. Nina war früher meist alle zwei Wochen für zwei bis drei Nächte unterwegs. Zum Zeitpunkt des Interviews arbeitete sie wohnortnah und schlief täglich zu Hause. Manche Projekte liefen vollständig remote.
Mit einem passenden Zugang kann sie sowohl im Büro als auch beim Kunden auf dem SAP-System arbeiten. Einschränkungen entstehen durch die jeweiligen Netzwerke. Bei einem Kunden konnte sie auf dessen Laptop während der VPN-Verbindung keine Internetdienste für eine Telefonkonferenz verwenden, was gemeinsame Vorführungen erschwerte.
Nina schätzt die wechselnden Aufgaben und die Begegnungen mit unterschiedlichen Menschen. Dienstreisen gaben ihr Gelegenheit, Städte kennenzulernen und mit Kolleg:innen etwas zu unternehmen.
Zum Beruf gehören auch kurzfristig längere Arbeitstage. Gerade gegen Projektende kann Arbeit nachts oder am Wochenende anfallen. Häufige Reisen ließen Nina zeitweise wenig Raum für ihr Privatleben und belasteten Freundschaften. Auch die Kontrolle durch Kund:innen fiel unterschiedlich aus: Manche prüften ihren Code ausführlich und verlangten Erklärungen.
Gespräche durch Praxis lernen
Nina empfiehlt, auf fremde Menschen zuzugehen und Gespräche zu führen. So kannst du üben, ins Gespräch zu kommen und ein Gespür für die Interessen deines Gegenübers zu entwickeln. Small Talk gehört etwa beim gemeinsamen Mittagessen zum Berufsalltag.
Eine konkrete Buchempfehlung zum Consulting nennt sie nicht. Du kannst Nina im Fachinformatikerforum kontaktieren. Die Shownotes zu meinem Gespräch findest du unter anwendungsentwicklerpodcast.de/111.
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
Herzlich Willkommen zum Anwendungsentwickler-Podcast, dem Podcast rund um die Ausbildung zum Fachinformatiker
für Anwendungsentwicklung. In dieser Episode gibt es ein Interview mit Nina Sauermann zum
Thema Consulting. Viel Spaß! Hallo und herzlich Willkommen zur 111. Episode des Anwendungsentwickler-Podcasts.
Mein Name ist Stephan Macke und heute habe ich wieder ein spannendes Interview mitgebracht und
zwar mit Nina Sauermann. Die ist SAP-Consultant und erzählt uns ein bisschen was über das Leben
als Consultant und was der Job so mit sich bringt. Wir haben ganz viele tolle Sachen besprochen und
die Idee ist, dir vielleicht auch eine Entscheidungshilfe zu geben, wenn du vielleicht mit
der Idee spielst, auch selber im Consulting-Bereich aktiv zu werden. Einfach mal zu hören, wie ist
denn das Leben, was macht man da so den ganzen Tag, was sind die Herausforderungen und was sind
vielleicht auch die Vor- und Nachteile. Wir haben über eine Stunde lang geschnackt, also gibt ganz
viel spannende Inhalte und deswegen höre ich jetzt auch auf mit dem Vorgeplänkel mal wieder und
gehe direkt über zum Interview. Viel Spaß! Okay, also ja, hallo Nina, schön, dass das geklappt hat mit
unserem Interviewtermin. Vielleicht magst du so zum Einstieg kurz was zu dir sagen. Wer bist du
eigentlich und was machst du so? Hallo Stefan, ja nach dem dritten Mal musste das ja auch mal
klappen. Es ist gar nicht so einfach, da einen Termin zu finden. Ja, ich heiße Nina, ich bin 28, komme aus dem
schönen Bayern und bin seit 2013 im SAP-Consulting unterwegs. Habe vorher die Ausbildung zur
Fachinformatikerin Anwaltsentwicklung gemacht und reise jetzt so mehr oder weniger durch die Welt
und berate die Kunden. Okay, und zwar im SAP-Bereich. Also eigentlich so ein Bereich, wo ich
immer so denke, ich freue mich sehr darüber zu hören, was man da so schönes macht eigentlich den
ganzen Tag. Ja, so der Bereich, wo viele sagen, ich musste wahrscheinlich beim Eingang meine Seele
abgeben. Das höre ich ganz oft, aber ja, das mache ich. Okay, und da hast du quasi die Ausbildung im
Bereich Anwaltsentwicklung auch schon direkt im SAP-Bereich gemacht zum Einstieg oder hast du
erst was anderes gemacht? Genau, wir hatten damals das Assessment Center mit ganz vielen
Menschen aus verschiedenen Abteilungen und der damalige Chef war es nicht. Er wurde von unserem
Chef quasi geschickt, um einen Azubi auszusuchen, weil bei denen war das so, dass HR entschieden hat,
wir nehmen den oder nicht und die Personaler von den einzelnen Abteilungen haben sich
dann quasi einen Azubi ausgesucht. Und so wurde ich ausgesucht, um dann im SAP zu arbeiten. Also
direkt vom ersten Tag war das so, hier hast du dein SAP-System, mach mal, viel Spaß. Noch nie
was davon gehört. Am Anfang hatte ich mich tatsächlich auch für eine Physi beworben und
wurde dann gefragt, ob ich mir nicht das einfach mal angucken möchte. Als Anwaltsentwickler war
dann ein Tag in dieser Abteilung und ja, habe mich dann doch dafür entschieden. Okay, also hast du
dich quasi auf den ersten Blick in SAP verliebt? Nein, überhaupt nicht. Also wirklich gar nicht.
Ich saß damals neben dem Azubi den ganzen Tag und er hat mich mit Infos zugemüllt,
zugeschmissen. Ich hatte danach das Gefühl, mein Kopf ist dreimal größer als heute Morgen,
weil es einfach viel zu viel Input war für einen Tag und die Hälfte habe ich mir nicht gemerkt,
weil das gar nicht möglich ist. Und wie das halt so ist an einem Tag, dann werden dir die ganzen
Leute vorgestellt. Dann sitzt du in der Abteilung, wo 35 Menschen sitzen. Die Namen sollst du dir dann
merken und vielleicht noch irgendwie Infos und guck mal, was man im SAP so alles Tolles machen
kann. Also der Tag hat mich tatsächlich mehr überfordert als alles andere so ein bisschen.
Aber ich habe mich dann zu Hause hingesetzt und überlegt, willst du Physi machen oder nicht? Und
habe tatsächlich eine Pro- und Contra-Liste geschrieben. Oh, okay. Das klingt so nach Klischee,
aber es war tatsächlich so. Und ich hatte früher schon einige Praktika im Bereich Physi und habe
da einfach schon vieles für mich gelernt und habe dann entschieden, als Anwendungsentwickler würde
ich für mich persönlich selber vieles Neues lernen, was ich beim Physi einfach schon weiß und kann.
Und deswegen habe ich mich dafür entschieden und habe dann festgestellt, dass das eigentlich ganz
spannend war. Und in der Abteilung, in der ich die Ausbildung gemacht habe, ging es um Personalsachen,
also Zeiterfassung, Lohnabrechnung, Urlaubsanträge etc. Also auch Sachen, wo man sich reinfinden kann
und was für jeden ja irgendwie auch einen Anwendungsfall hat. Und Sachen, die auch wichtig
sind, weil wenn mein Gehalt am Ende des Monats nicht kommt, dann habe ich natürlich ein Problem.
Und wenn ich meinen Urlaub nicht beantragen kann, ist das natürlich auch irgendwie doof.
Und dementsprechend fand ich das ganz spannend, weil man halt nicht mit irgendwas arbeitet,
was man gar nicht erfassen kann, sondern einfach tatsächlich Sachen, wo du weißt,
ach, das benutze ich ja selber.
Und ist das dann in SAP tatsächlich so ein HR-Modul? Ich kenne mich jetzt nicht so richtig
aus, aber ich glaube, da gibt es ja irgendwie so eine Komponente von SAP, die extra für
Mitarbeiterzeug da ist.
Genau, die SAP hat verschiedene Module und das war damals, also es hieß ganz früher mal HR,
mittlerweile heißt es HCM, weil die SAP gesagt hat, HR klingt so ein bisschen, weiß nicht, blöd.
So Ressourcen halt.
Ja, so Ressourcen klingt ein bisschen blöd. Und jetzt ist es Human Capital Management.
Okay.
Ob das besser ist, hat er gestellt, aber es ist jetzt so. Und ja, das fand ich eigentlich
ganz spannend, weil wie gesagt, du hast halt selber Anwendungsfälle und Anwendungsmöglichkeiten.
Es war zum Teil auch ein bisschen anstrengend, weil die anderen Azubis, man tauscht sich
natürlich aus, man kriegt mit, was so der Rest macht.
Und ich war zum Teil für die Zeitwirtschaft zuständig, so ein bisschen mit.
Und wenn der Job nachts nicht gelaufen ist, wurden die Zeiten nicht gebucht.
Das bedeutet, ich habe gestern gestempelt und gucke in meinem System nach und da steht für
gestern keine Uhrzeit, weil der Job natürlich niedrige Europrio hatte.
Andere Sachen sind halt tatsächlich wichtiger.
Aber für manche Leute bedeutet das so, Gott, ich weiß nicht, wann ich gestern gearbeitet
habe, also kann ich heute auch nicht arbeiten.
Und die meisten Leute haben dann an solchen Tagen wurden Tickets geöffnet ohne Ende.
Und die meisten Azubis kamen dann zu mir.
Dann kam Nina, kannst du mal?
Nein, kann ich nicht, weil es ist nicht wichtig.
Aber ja, also ich wusste schon, wenn der Job nicht gelaufen ist, kam spätestens um halb
neun die erste E-Mail.
Nina, meine Zeiten sind nicht da.
Was ist da los?
Weil für die Leute ist das ganz wichtig.
Es gab ganz viele scheinbar Kollegen, die sich morgens erst mal angemeldet haben, System
und geguckt haben, wie viel habe ich denn gestern gearbeitet?
Und wenn das nicht geht, dann war das irgendwie Katastrophe.
Das Nachvollziehen so direkt kann ich es nicht.
Aber wir haben tatsächlich für unsere Mitarbeiter genau wie du sagst, Zeitbuche und so
haben wir auch SAP im Einsatz.
Und da gucken tatsächlich sehr viele Kollegen morgens erst mal rein.
Ich unter anderem auch. Und wenn es auch nur dazu da ist, um zu gucken, wie ist denn
aktuell der Stand der Überstunden oder Minusstunden und so weiter?
Ich meine, klar, ich habe da auch relativ häufig reingeguckt, auch um zu sehen, ist
der Job gelaufen? Funktioniert das?
Und natürlich auch, wie du sagst, Überstunden, Minusstunden.
Aber dieses Ich muss jetzt ein Ticket mit einer ganz hohen Prio aufmachen, weil ich
kann ja quasi nicht arbeiten, nur weil die Zeiten nicht drin sind.
Das ist halt einfach Quatsch und das kann ich nicht nachvollziehen.
Das stimmt vorher.
Und dann gab es auch Leute, die es bis im dritten Jahr von den Azubis nicht gelernt
haben. Die haben dann meine Zeiten fehlen von gestern.
Ja, dann trage ich sie manuell nach.
Ja, und dann lief in der nächsten Nacht der Job und dann war das System natürlich
verwirrt, weil ich habe doppelte Stunden.
Ja, die haben es bis zum Ende nicht gelernt, dass man ja wieder löschen muss und es
dann wieder nachdauert, bis ich das wieder gerade ziehe.
Naja, so ist das.
Ich hätte mal interessiert, was gewesen wäre, wenn mal irgendwie das Gehalt zu spät
gekommen wäre. Dann wäre wahrscheinlich alles.
Dann wären sie alle heimgegangen wieder.
Genau.
Wahnsinn. Ja, gut. Aber da hängt natürlich viel viel dran, was man so vielleicht auch
nicht unbedingt aus Entwicklersicht immer so bedenkt.
Aber es ist halt für viele Mitarbeiter ganz wichtig, dass das halt irgendwie passt,
dass das funktioniert. Und ja, die drehen irgendwie durch, wenn da diese
Standardsoftware nicht ihr Werk tut.
Ja, es ist auch manchmal schwierig oder man kann das gar nicht so richtig
nachvollziehen oder denkt an manche Sachen einfach gar nicht.
Ich hatte mal einen Kunden, der wollte das Bonussystem ändern.
Die hatten das Bonussystem so, dass der Vorgesetzte eine Excel-Liste
gekriegt hat mit seinen Mitarbeitern und er hat quasi per Hand eingetragen.
Mitarbeiter A kriegt so und so viel Bonus, Mitarbeiter B kriegt so und so viel
Bonus. Und da gab es dann die Fälle,
dass jemand einen Bonus gekriegt hat, der eigentlich keinen hätte kriegen dürfen,
weil er irgendwie im Vertrag steht, wenn du vor sechs Monaten einen Gehaltserhöhung
gekriegt hast, kriegst keinen Bonus oder solche Geschichten.
Und das ist erst aufgefallen, als die Dame gekündigt hat.
Fünf Jahre später.
Und na ja, wenn dann irgendwie ein fünfstelliger Bonus ausbezahlt wird,
dann ist das halt auch schwierig, der Dame zu sagen, wir kriegen übrigens noch Geld
von dir wieder, weil die hat vermutlich das Geld irgendwie angelegt oder ausgegeben
oder was auch immer. Das ist natürlich viel Aufwand für die Firma, das Geld
wieder zurückzuholen. Und dann gab es auch Fälle,
dass dem Mitarbeiter vorgeschlagen wurde, für den Herrn XY einen Bonus
einzutragen, der Herr XY aber von einem Jahr verstorben ist.
Das fanden die Vorgesetzten natürlich nicht so schön.
Und deswegen sollte ich da dann ein Programm schreiben, was so gewisse Fälle
einfach von vornherein ausschließt und sagt, ne, der kriegt gar keinen Bonus.
Und da macht man sich gar keine Gedanken drüber, weil ja, das System weiß doch,
passt doch alles doch gut.
Aber da hängt halt hinten viel mehr dran, als man so vor allem als User
irgendwie mitkriegt oder sich überhaupt bewusst ist.
Definitiv. Auch so, ich meine, das war jetzt noch für den Einstieg noch locker.
Aber wenn man so komplexe Businessregeln sich dann auch mal anguckt und so ganze
Regelwerke, wo irgendwie was ablaufen muss, damit am Ende dann der Betrag richtig
ist und so, da ist das wahrscheinlich ja noch Spaß, was wir gerade gehört haben.
Ja, richtig. Also wir haben auch bei dem Projekt habe ich mit drei
Leuten vom Fachbereich damals zusammengesessen und wir haben, glaube ich,
drei Stunden diskutiert, wann, wie, wo, in welchem Fall jetzt jemand einen Bonus
kriegt oder nicht und überhaupt.
Und das muss ja dann auch alles tatsächlich ordentlich abgebildet sein, weil du kannst
ja auch nicht jemanden ausschließen. Das wäre genauso schlecht, wenn ich jetzt
jemanden vergesse, der dann irgendwie sagt, ey, aber ich hätte doch, ich habe
da einen guten Job gemacht. Warum kriege ich denn kein Geld?
Das ist genauso schlecht, wie jemandem kein Geld zu geben, der es nicht verdient
hätte oder nicht bekommen dürfte.
Spannend. Das heißt, also genau, da steigen wir auf jeden Fall noch mal einmal
tiefer ein in die ganze SAP-Schiene.
Wir waren eigentlich gerade noch so bei der Standardfrage, wie du eigentlich zur
Informatik gekommen bist. Aber schön, dass sich das Gespräch so ergibt.
Aber eine Frage habe ich dann doch noch, weil du es gerade auch schon selber gesagt
hast. Du hast dann auch was entwickelt.
Machst du das dann in SAP mit ABAP oder hast du noch andere PoE-Sprachen da im
Einsatz?
Nee, ich mache das tatsächlich ausschließlich mit ABAP.
Wir haben zwar in der Berufsschule auch Java gelernt und auch in den Schulungen in
der Arbeit COBOL, was ich auch sehr spannend fand.
Aber es ist ausschließlich ABAP.
Auch wenn die SAP mal umstellen wollte, haben sie das ja nicht getan.
Deswegen bleibt das alles so.
Das, wo du es jetzt gerade sagst, also ich hatte jetzt dieses Jahr eine IHK-Prüfung,
wo auch im SAP-Umfeld mit Java gearbeitet wurde.
Ist es denn so, dass eigentlich die fachliche Komponente, also das Backend, noch
ausschließlich mit ABAP programmierbar ist?
Oder kann man da auch Java einsetzen?
Oder wird das nur fürs Frontend benutzt?
Also das Frontend ist auch viel, was mit ABAP gemacht wird.
Du kannst im Hintergrund aber einige Sachen mit Java machen, zum Teil musst du es
auch. Das kommt darauf an, auf welchem System
das SAP läuft. Also das kann ich am Anfang eigentlich mir aussuchen.
Und es gibt aber auch ein paar Module.
Da ist einfach eine Java-Komponente dabei, die kann man auch nicht
umgehen. Das sind so ein paar neue Sachen oder neuere Dinge.
Und jetzt seit ein paar Jahren gibt es ja,
sind sie jetzt auf diesem Mobility-Zug aufgestiegen und man muss
aus allem eine App machen und weiß ich nicht.
Und jetzt wird eben auch viel mit UI5 und Fiori
und solchen Geschichten gemacht.
Da mache ich aber tatsächlich einfach gar nichts.
Also noch zumindest.
Weil es einfach aktuell noch nicht wirklich eingesetzt wird, weil
die Kunden da doch ein bisschen Angst haben, weil wenn es dann irgendwie um
Personaldaten geht oder irgendwelche Finanzbuchhaltungskram,
da muss ich keine App für haben.
Das geht auch so.
Und die Entwicklung in dem ABAP, so wie ich das bislang gesehen habe, ist man da
quasi, das ist ja komplett integriert, irgendwie in das Backend macht man irgendwie
eine, ich habe keine Ahnung, Transaktion auf und tippt da dann sein Source-Code ein.
Und das ist eigentlich komplett integriert, richtig?
Oder wird das irgendwie anders entwickelt?
Nee, du brauchst auch das SAP-System, um überhaupt entwickeln zu können.
Also wenn ich jetzt beim Kunden bin, brauche ich als allererstes den Zugang auf
den SAP-System, sonst funktioniert gar nichts.
Es ist nicht so wie jetzt irgendwie bei anderen Programmiersprachen, dass du dir
das auf deinem Rechner erst mal zusammen friemelst und dann quasi an den Rest
verteilst. Du brauchst tatsächlich von Anfang an das System.
Anders macht das alles gar keinen Sinn.
Also das heißt, wenn du auch beim Kunden bist, dann kriegst du da wie einen
Zugang und kannst theoretisch dir den ganzen Code angucken oder gibt es da so
feingliedige Berechtigung, dass du zum Beispiel nur im HCM-Modul arbeiten darfst?
Nein, also beim Kunden ist es so, dass viele die Systeme getrennt
haben, also die haben dann fürs HCM quasi ein System.
Wenn ich dann natürlich nur am HCM Zugriff habe, dann habe ich nur das HCM.
Es gibt aber auch welche, wo sich die Module einfach überschneiden.
Und wenn ich Zugang habe, angucken, den Code
kann sich dann erst mal jeder.
Also du kannst, also es ist klar, könntest du die Transaktion auch einschränken.
Das macht aber eigentlich, das hatte ich noch nie, dass die eingeschränkt ist, weil
du kannst erst mal nichts kaputt machen.
Und wenn du dann irgendwie was ändern möchtest, da brauchst du dann nochmal einen
Extraschlüssel. Den musst du auch bei der SAP registrieren, weil der kostet nochmal
Lizenz.
Ah, okay, verstehe.
Kann man Transaktionen ganz grob mit Programmen übersetzen oder?
Nein.
Okay, schade.
Also prinzipiell arbeite ich in der Transaktion SE80.
Da wird entwickelt, programmiert.
Ich kann da mein Programm auch direkt drin starten.
Das wäre für den User aber einfach unpraktisch, weil die kennen sich nicht aus.
Die wissen überhaupt nichts und die können mit meinen kryptischen Namen gar nichts
anfangen.
Und deshalb kannst du hinter jedes Programm eine Transaktion
hängen, die quasi nur der Aufruf ist.
Weil wenn ich jetzt in mein Programm gehe, gehe ich eben über die SE80 und entwickle
dann da. Und da habe ich oben einen Knopf, der sagt hier, führ mal aus, teste
mal. Das wäre, wie gesagt, für den User völlig unkomfortabel,
weil der weiß ja gar nicht, in welchem Paket habe ich das abgelegt?
Wie heißt denn mein Programm? Was macht das denn überhaupt?
Weil mein Programm heißt dann ZMMSD, schlag mich
tot. Und Programmnamen sind ja dann auch nicht so ewig lang.
Also das wäre für den User einfach unpraktisch.
Deswegen hänge ich da eine Transaktion dahinter und er kann dann, sobald er sich am
SAP angemeldet hat, quasi den Namen von der Transaktion eingeben und dann startet das
Programm. Er muss das nicht erst suchen.
Du hast gerade gesagt, die Namen sind so ein bisschen unsprechend.
Also ich kenne das aus unserem Legacy-System mit AWS Natural, dass man acht Zeichen
für Programmnamen zur Verfügung hat.
Ist das in SAP auch so?
Ähnlich. Es ist begrenzt auf jeden Fall.
Und es fängt schon damit an. Es gibt die Standardprogramme von der SAP.
Die fangen mit irgendwas an, ist völlig egal.
Die können, die kannst du, also die sind benannt, wie die SAP gerade lustig war.
Dann gibt es die Programme, die ich oder du oder sonst wer schreiben kann.
Die müssen mit Z oder mit Y anfangen, was schon nicht so schön klingt.
Oder ich kann mir als Kunde einen sogenannten Namensraum kaufen.
Der fängt dann mit Slash an, sind dann drei Zeichen und nochmal ein Slash.
Das ist dann, weiß ich nicht, ich habe in der Hypovereinsbank gelernt, da war das
Slash HVB. Das ist dann mein Namensraum, in dem kann dann auch nur ich
programmieren, da kann dann kein anderer was machen.
Aber der Hersteller, der SAP, hat da immer irgendwie den Daumen drauf.
Alles, was man machen will, kostet Geld wahrscheinlich.
Ja, ziemlich. Und du stimmst auch zu, wenn ich jetzt irgendwas entwickle und die
SAP guckt, also die SAP ist mit jedem System verbunden auf dieser Welt, schon
allein wegen Updates etc.
Die SAP kann sich auch auf die Systeme schalten.
Natürlich nicht irgendwie ohne zu fragen oder so, aber sie können das.
Und wenn die SAP jetzt irgendwie ein Programm sehen sollte, was sie toll
finden, was ich geschrieben habe oder sonst wer, dann können sie das in ihren
Code übernehmen und als Standard ausliefern.
Okay, das muss man quasi als SAP-Entwickler so hinnehmen.
Das ist einfach so.
Ja, das ist so. So wie ich halt auch alles, was im Standard ist, ändern kann.
Okay, witzig.
Das wusste ich nicht. Ja, spannend.
Es ist immer wieder cool zu sehen, wie andere Entwicklungsumgebungen
funktionieren und was da so dahinter steckt.
Und SAP wird ja wirklich in so vielen Firmen benutzt, bei uns jetzt auch.
Wir entwickeln zwar selber damit nicht, aber wir nutzen es halt.
Und es ist ja, ja, es kann halt quasi irgendwie alles.
Ja, das stimmt. Für jeden Fitzel gibt es da irgendwie so ein Modul.
Ja.
Krass. Ja, okay, sehr spannend.
Also ein schöner Exkurs zum Thema Wie funktioniert überhaupt SAP?
Und dann würde ich sagen, machen wir so den Schwenk zum eigentlichen Thema.
Denn dein Job ist ja jetzt quasi, wie ich es gehört habe, auch bei Kunden das ganze
Zeug irgendwie in die Produktion zu bringen, sage ich jetzt einfach mal.
Und ja, wie würdest du deinen Job eigentlich beschreiben?
Also heute soll das Thema sein Consulting.
Und ja, was machst du eigentlich den ganzen Tag?
Schwierig. Das ist total tagesabhängig oder projektabhängig.
Ich fange einfach mal an nach der Ausbildung.
Die erste Firma, da wurde ich direkt ins kalte Wasser geschmissen.
Mein Chef hatte damals gesagt Ja, also wenn du dann bei uns anfängst,
dann kriegst du erst mal eine Schulung, eine SAP-Schulung und dann kriegst du eine Schulung.
Wie gehe ich mit dem Kunden um? Wie habe ich mich zu verhalten? Etc.
Und er meinte, dann bist du erst mal drei Monate beschäftigt
und dann fangen wir langsam an und fahren mal zum Kunden.
So der Plan.
Plan war, dass ich am Mittwoch anfange, weil das der erste war.
Eine Woche vorher hat er angerufen und gesagt, da kannst du nicht am Montag schon kommen.
Wir haben dann eine ABAP-Schulung.
Du weißt zwar wahrscheinlich schon alles, aber vielleicht bringt dir das ja was.
Und du lernst schon mal die Kollegen kennen.
Ja gut, also bin ich am Montag schon hin.
Und dann war die ABAP-Schulung quasi zu zweit gehalten haben
vor Beratern, die alle keinen Strich programmieren können.
Aber Ziel war einfach, dass sie die Angst vom Code nicht mehr haben
und vielleicht so ein bisschen lesen.
Das reicht manchmal einfach schon, wenn der Kollege einfach so ein bisschen
sich reinliest.
Der muss ja nicht programmieren, aber manchmal.
ist das schon ganz praktisch. Wir hatten dann auch eine Kollegin, die tatsächlich zum Teil angerufen hat,
ach, ihr seid im Auto, ja, ich glaube in Zeile so und so, da steht das und das und ich glaube, ich würde das
so und so ändern, ist das richtig? Die hat das dann auch gemacht. Also, es hat wohl geholfen.
Und dann habe ich mich mit dem Kollegen unterhalten, der die Schulung gehalten hat,
und habe ihn gefragt, wie denn jetzt der Plan aussieht, weil er mir gesagt hat, er wäre jetzt für mich zuständig
und soll so ein bisschen die Hand über mich halten und aufpassen. Und ich sagte, ja, also, wir fahren
nächste Woche Mittwoch zum Kunden. Also, das war es dann mit den drei Wochen Schonfrist.
Und der erste Kunde, das war ganz witzig und war auch gar nicht so tragisch,
weil wir sind zu dem Kunden gefahren in Braunschweig, bei dem schon ganz viele von unseren Kollegen
einfach fünf Tage die Woche saßen. Hatten dementsprechend auch mehr mit unseren Kollegen zu tun,
als mit dem Kunden selber. Aber haben da so hier eine Baustelle gehabt und da eine Baustelle
und immer so ein paar kleine Programmieraufgaben, war gar nicht so tragisch.
Dann ging es die Woche drauf nach Kiel. Das war dann schon irgendwie spannender und anstrengender,
weil da saßen wir dann tatsächlich den ganzen Tag in einem Meeting, wie man sich das so vorstellt,
mit irgendwelchen wichtigen Menschen, die fürs Geld zuständig sind, mit anderen Entwicklern,
mit allen Leuten, die irgendwie was zu sagen haben und diskutiert haben, wir wollen ein Projekt,
wie machen wir das, wer macht das, wann machen wir das und überhaupt.
Und das war dann schon so ein bisschen seltsam, weil vorher war halt in der Ausbildung,
du kennst die Leute, du weißt, was du zu tun hast, du redest ganz normal, du duzt die alle.
Das ist halt, jeden Tag hast du mit den gleichen Menschen zu tun und dann sitzen da auf einmal Leute,
die du noch nie gesehen hast, die gar nicht wissen, wer du bist, die gar nicht überhaupt verstehen,
was überhaupt Sache ist, weil in der Beratung hast du ganz oft Leute,
die von der technischen Seite so gar keine Ahnung haben.
Die wissen, was es am Ende machen soll, die wissen, dass es nicht zu teuer sein soll,
aber die haben keine Ahnung. Und das ist so auch ein bisschen schwierig,
da dann den Zwischenpart zu bilden, weil du musst dem ja irgendwie auch erklären,
wenn ich sage, das dauert zehn Tage zu programmieren, warum es denn zehn Tage dauert und nicht nur fünf.
Und da sitzen dann noch Menschen, die sich gerne einen Einhorn wünschen,
dem man dann erklären muss, dass es keine Einhörner gibt und dass manche Sachen
halt tatsächlich einfach so nicht umsetzbar sind oder schon umsetzbar sind,
aber mit so viel Aufwand, dass es sich gar nicht lohnen würde.
Und das ist so eigentlich das tägliche Brot.
So ein bisschen im Moment programmiere ich viel, aber je nach Projekt ist halt auch viel Diskutiererei,
viel Telefonieren, viele Meetings. Ich hatte jetzt bis vor kurzem ein Projekt,
da hatten wir zur Endphase hin zweimal am Tag ein Meeting mit zehn Leuten, glaube ich.
Zweimal am Tag eine Telco über eine Stunde. Und gefühlt wurde jedes Mal das Gleiche besprochen.
Aber das gehört tatsächlich, glaube ich, bei jedem Berater irgendwie dazu.
Man telefoniert viel, man redet viel und guckt, was am Ende bei rumkommt.
Also ist das quasi auch wie, zumindest das zweite Versuch des Hilters,
so in Richtung Anforderungsanalyse eigentlich?
So was will der Kunde eigentlich und wie setzen wir das am besten um?
Ja, definitiv. Manchmal ist es halt auch schwierig, weil der Kunde gar nicht so richtig weiß,
wie er das auszudrücken hat oder wie er das ausdrücken soll, was er gerne möchte.
Wir hatten zum Beispiel einmal einen Kundentermin.
Eigentlich war der Plan, nur mit den Entwicklern von der anderen Seite uns zusammenzusetzen.
Und dann kam der CEO und wollte am Meeting teilnehmen.
Hat sich dann mit reingesetzt, hat dann erstmal 15 Minuten telefoniert
und hat dann sich an irgendeiner PowerPoint-Folie festgebissen,
wo er gemerkt hat, oh, er versteht jetzt was.
Weil er hat vorher einfach nicht verstanden, worüber wir reden,
weil es war ja nicht für ihn geplant, der Termin.
Dementsprechend war das rein technisch.
Und ja, das war sehr anstrengend, weil er dann versucht hat, sich irgendwie einzumischen
und zu zeigen, dass er wichtig ist und er was zu sagen hat.
Aber er wusste gar nicht, wie, weil er gar nichts verstanden hat.
Und da dann zu verstehen, was er denn jetzt von dir möchte,
weil er ja selber eigentlich gar nicht weiß, was er überhaupt zu sagen hat,
ist schon manchmal gar nicht so einfach.
Also wir haben da viel diskutiert und viel hin und her und dann nochmal.
Jeder fasst das auch so ein bisschen anders auf.
Also nur weil da drei Entwickler am Tisch sind, heißt das nicht,
dass die alle das gleich machen würden.
Da muss man irgendwie am Anfang, glaube ich, schon auch ein bisschen ein Händchen für entwickeln,
um zu merken, ach, der erzählt mir jetzt was, was meint denn der überhaupt?
Und ist das dann was, du hast gerade am Anfang gesagt, du solltest eine Schulung bekommen,
so wie gehe ich mit Kunden um?
Ist das dann sowas, was man da lernen muss, wenn Leute wirklich keine Ahnung von der Technik haben,
dass man irgendwie ruhig bleibt und das versucht so zu vermitteln,
dass auch ein Nicht-Techniker das verstehen kann?
Oder was war da der Inhalt?
Ich hatte die Schulung dann tatsächlich auch, das war dann eine Woche.
Da ging es halt auch darum, wie spreche ich mit dem Kunden?
Wie schreibe ich eine E-Mail, dass sie nicht irgendwie falsch ankommt?
Was darf ich beim Kunden auf gar keinen Fall machen?
Also auch wenn der Kunde beispielsweise einen Fehler macht, darf ich ihm das nie sagen,
weil der Kunde bezahlt.
Klar muss man ihn irgendwie darauf hinweisen und ihm zu verstehen geben,
dass er was falsch gemacht hat.
Aber ich kann ihm nicht sagen, ey du, das war dein Fehler.
Das geht nicht.
Oder das sind dann so Sachen, da ging es natürlich dann auch darum,
wie hat der Mann sein Hemd in die Hose zu stecken?
Hat er eine Krawatte anzuziehen? Hat er keine Krawatte anzuziehen?
Wie viele Knöpfe am Jackett müssen offen sein? Wie viele nicht?
Wann darf ich mein Jackett bzw. Blazer ausziehen?
Solche Sachen haben wir da einfach besprochen.
Okay, also ist das tatsächlich bei euch dann wirklich so gang und gäbe,
dass man sich, ich sag jetzt einfach mal vernünftig kleidet
und wirklich die ganze Zeit im Anzug dort auftaucht?
Das ist dann üblich in eurem Umfeld?
Also wenn ich das erste Mal zum Kunden gehe, auf jeden Fall.
Ich war lieber overdressed als zu wenig.
Wenn ich dann länger beim Kunden bin, muss man das einfach abwägen.
Also wir hatten schon einen Kunden, da sind wir zu dritt damals hingefahren
und er macht uns die Tür auf in kurzer Hose und T-Shirt.
Wir standen da alle im Anzug und er sagt,
oh, wieso seid ihr so schick, ist doch viel zu warm.
Das ist auch cool.
Aber man weiß es halt nicht,
weil ich war auch viel in Versicherungen und Banken unterwegs
und da geht sowas natürlich nicht.
Wenn dann der Kunde dir gegenüber im Anzug sitzt,
dann kannst du da natürlich nicht in Jeans und Pulli sitzen,
auch als Entwickler nicht.
Genau, und sowas haben wir dann gelernt,
oder dass du dich am besten oder man sollte sich nicht hinsetzen,
bevor der Kunde nicht sitzt, zum Beispiel.
Das war immer anstrengend, weil der Kunde immer sagt,
ach komm, setz dich doch bitte hin, nehm doch bitte Platz.
Und laut der Schulung sollst du ihn dreimal bitten lassen,
bevor du dich hinsetzt, wenn er noch nicht sitzt.
Das ist so.
Das sind so Sachen, die wir da besprochen haben
und die man dann geübt hat.
Oder wie du eine Präsentation führst,
je nachdem, wer in dem Termin sitzt.
Im Normalfall weiß ich ja, wer zu dem Termin eingeladen ist.
Und wenn da jetzt jemand, der CEO zum Beispiel, sitzt,
muss ich ja die Präsentation ganz anders vorbereiten,
als wenn da nur Techniker sitzen.
Und sowas haben wir da einfach geübt, wie man damit umgeht
und wie ich denen das so erkläre und nahe bringe,
was ich da überhaupt tue.
Aber kannst du dann so grob abschätzen,
wenn du jetzt sagst, das ist ein großer Teil deines Berufs,
eigentlich auch mit den fachlichen Leuten dich auseinanderzusetzen.
Kannst du irgendwie so sagen, Programmieranteil
oder Technikanteil allgemein und dieses Ganze drumherum,
das ist so Hälfte-Hälfte oder irgendwie doch eher die weichen Themen?
Oder kannst du das irgendwie einschätzen?
Also im Moment ist Programmierung, würde ich behaupten, 80%.
Das kommt aber tatsächlich komplett aufs Projekt an.
Also es gibt viele Projekte, wo es ganz wichtig ist,
viel zu reden, viele Meetings, viel mit den Leuten,
die technisch eben nicht das Know-how haben.
Und dann gibt es Kunden oder Projekte, die sagen,
ja, ich mach das schon, das passt schon.
Und in meinem aktuellen Projekt ist einfach meine Chefin und mein Chef,
die sind da so die Federführenden,
die jetzt aktuell auch schon wieder unterwegs sind
und Meetings ohne Ende haben.
Und also mit meiner Chefin irgendwie einen Termin zu kriegen,
um mal einen Kaffee zu trinken, ist ganz schwierig,
weil die ist halt immer kalendervoll mit irgendwelchen Meetings.
Und in dem Projekt macht sie das halt mit dem Kunden
und gibt uns dann quasi die Arbeit.
Okay. Und wenn man sich jetzt so ein Meeting vorstellt,
also wo es vielleicht auch ein bisschen technischer zugeht,
ist das dann so, dass man an einem Whiteboard steht
und malt da irgendwie UML-Diagramme
oder irgendwie uralte Flussdiagramme oder was?
Ist überhaupt dann so ein Ergebnis von so einem Meeting?
Das ist auch ganz abhängig davon, wer in dem Termin sitzt.
Also wir haben, es werden ja vorher meist schon
irgendwelche Konzepte ausgetauscht und überlegt,
was ist denn überhaupt die Anforderung?
Wie sieht es denn überhaupt aus?
Also wir wissen meist schon, was so der grobe Umfang ist,
worum es überhaupt geht.
Also du gehst selten in ein Meeting und weißt gar nicht,
was der Kunde überhaupt möchte.
Weil der Vertriebler schon so ein paar Sachen geklärt hat
und dann gab es auch in der alten Firma ganz oft,
dass der Vertriebler kam und sagte,
ja, der Kunde will das und das.
Macht mir mal eine Aufwandsschätzung.
Das heißt, der Kunde wusste da auch schon ungefähr,
in welchem zeitlichen Rahmen wir uns da irgendwie befinden.
Und dann sitzt man halt einfach zusammen
und bespricht quasi die Feinheiten
und guckt, wie wird es umgesetzt?
Wann ist Zeit, dass wir es umsetzen?
Und ja, ich hatte aber auch schon Kunden.
Da hieß es, Freitagnachmittag, Nina,
kannst du dich bitte ins Auto setzen?
Du müsstest am Montagmorgen um 8 in Hamburg sein.
Und ich schicke dir nachher eine E-Mail, was du zu tun hast.
Also auch das hatte ich schon.
Beziehungsweise ich rufe dich dann am Montagmorgen,
wenn du beim Kunden bist, können wir ja telefonieren.
Dann erkläre ich dir, was du machen sollst.
Also auch das hatte ich.
Das ist natürlich nicht der Idealfall,
aber auch sowas kommt vor.
Also Meetings sind ganz unterschiedlich.
Bei dem Termin in Kiel saßen zwei Java-Entwickler mit im Raum.
Das war ganz witzig, weil mein Kollege
hat in seinem Leben noch nie was anders programmiert als mit ABAP.
Und die zwei, glaube ich, noch nie was anderes als mit Java
und haben versucht, sich zu unterhalten.
Und sie haben das Gleiche gemeint,
aber sie haben es nicht verstanden.
Und da das ja einer meiner ersten Kundentermine war,
haben die Kollegen mich gebeten, mich zurückzuhalten.
Sie haben gesagt, hör nur zu.
Am besten nichts sagen.
Dann habe ich mir das so zugehört.
Und dann habe ich gesagt, es tut mir leid,
aber ich muss mich jetzt einmischen.
Ihr redet von einem und demselben.
Es heißt nur anders.
Und ihr versteht euch nicht.
Aber ihr sprecht seit einer halben Stunde vom Gleichen.
Und das kann halt auch vorkommen.
Dass man sich einfach untereinander
auch die Technik nicht versteht.
Witzig, ja.
Ja gut, wenn SAP so als separates Ökosystem, sage ich mal,
und so ein Java-Entwickler damit auch nie was zu tun hatte
und umgekehrt genauso, ist vielleicht wirklich schwierig.
Ja, zum Teil.
Weil ABAP hat zum Beispiel kein Boolean.
Oh, okay.
Also man kann es umsetzen, natürlich.
Man kann es abbilden, aber es gibt kein Boolean.
Und das war dann auch damals das Thema,
wo sie hin und her diskutiert haben.
Ei, ei, ei.
Und da würde man quasi irgendwie ein Int mit 0 und 1 nehmen, oder?
Nee, man nimmt ein Charakterfeld
und da steht dann entweder ein X drin oder eben nix.
Oh, ah, okay.
Das kenne ich sogar aus Natural.
Da ist das, oder zumindest in der Visualisierung,
ist das auch einfach X oder nicht X.
Ja, okay.
Ja.
Oder man hat ganz oft,
ja, Charakterfelder haben nur eine Stelle.
Und im ABAP kann ich mir das einfach aussuchen.
Also da kann ein Charakterfeld auch 30 Stellen haben,
wenn ich das möchte.
Okay.
Aber dann würde schon irgendwo im Code so was stehen wie,
wenn Charakter gleich Y, dann ja.
Also es ist nicht irgendwie spezifiziert,
dass zum Beispiel ein X immer true ist, oder doch?
Nein, es ist nicht spezifiziert.
Es gibt zwar mittlerweile Datentypen von der SAP,
die dann, oh, ich weiß es gar nicht,
irgendwas mit bool heißen,
die da die Spezifikation haben.
Aber im Normalfall habe ich einfach,
dass ich im Code abfrage, steht da ein X drin oder nicht?
Okay, jetzt hast du ja gerade gesagt,
irgendwie, dass in den Meetings dann auch oft natürlich besprochen wird,
was soll eigentlich umgesetzt werden,
oder ihr kriegt das auch schon vorher.
Dann frage ich mich eigentlich immer,
so SAP, das kann doch eigentlich die ganze Fachlichkeit schonen,
oder was muss dann noch so individuell
eigentlich umgesetzt werden beim Kunden?
Prinzipiell die Geschäftsprozesse kann das SAP,
aber jeder Kunde hat ja so sein eigenes Süppchen,
was sie kochen.
Und da gibt es immer irgendwas,
was sie dann doch anders haben,
als der Standard und jeder andere.
Also die SAP hat den Standard so ausgeprägt,
dass es für die meisten oder für viele
einfach passend sein könnte.
Ob es dann wirklich so ist, das sei immer dahingestellt.
Und es gibt dann auch den ein oder anderen Angebersfall,
wo es den SAP-Standard gibt,
der Kunde aber einfach doch seinen eigenen Henkel dran haben möchte.
Wir hatten zum Beispiel in der Ausbildung,
es gibt vom SAP, auch im Standard kann das das SAP,
du kannst als Mitarbeiter die Cent-Beträge von deinem Lohn spenden.
Also du kannst im Portal einen Haken setzen,
sagen hier, die Cent-Beträge möchte ich spenden.
Dann wird das direkt von deinem Lohn abgezogen,
also von deinem Netto.
Das heißt, du spendest dann zwischen einem und 99 Cent.
Und eigentlich ist das von der SAP so gedacht,
dass das an die SAP geht.
Die SAP sammelt das quasi
und das, was zusammengekommen ist,
setzt die SAP nochmal oben drauf
und spendet das dann irgendwie an eine Hilfsorganisation
oder SOS Kinderdörfer oder ich weiß nicht genau,
wo sie es hin spenden.
Klingt alles ganz toll.
Jetzt hat mein Ausbildungsbetrieb,
die wollten das auch,
aber die wollten das komplett unabhängig von der SAP machen.
Deswegen haben wir da unser eigenes Süppchen gekocht
und das wurde dann quasi bei der Bank gesammelt
und die Bank hat dann gesagt,
so, wir schmeißen jetzt nochmal alles,
was die Mitarbeiter gespendet haben,
nochmal on top drauf und spenden das gesondert
und nicht direkt mit der SAP zusammen.
Okay, witzig.
Also erstmal coole Geschichte, finde ich ja gut.
Habe ich noch nie gehört, dass so was geht.
Finde ich ja super.
Okay, klasse.
Aber dann heißt das,
dass ich doch, wenn ich mich für SAP entscheide,
also ich höre es immer so,
die Leute haben sich für SAP entschieden,
also wird die ganze Firma so umgebaut,
dass man das macht, was SAP will.
Aber dann ist es ja doch irgendwie gar nicht so.
Ich muss dann doch sagen,
hier, der Prozess läuft aber anders,
also muss ich ihn customisen oder anders programmieren sogar.
Ja, das kommt darauf an.
Also eine Freundin von mir,
die hatten letztens SAP Einführungen in der Firma
und sind alle todunglücklich,
weil da ist es so,
ja, wir haben jetzt SAP,
wir machen das jetzt ab sofort so,
wie das SAP das vorgibt.
Und sie hat da wohl auch mit ihrem Vorgesetzten drüber gesprochen
und er sagt, ja, klar könnte man das ändern,
ist aber zu teuer.
Okay.
Weil, wenn ich natürlich die Leute nicht in der Firma habe,
die das ändern können,
dann muss ich mir natürlich jemand einkaufen
und das kostet halt einfach Geld.
Aber prinzipiell ist es natürlich besser,
wenn ich das System so umbiege,
dass es für mich passt, anstatt andersrum.
Und jetzt hast du gerade schon gesagt,
wenn die Kunden niemanden im Haus haben,
der es anpassen kann,
ist das denn häufig so,
dass sie die SAP einfach nur als Software quasi einkaufen
und die muss dann laufen
und die haben wirklich auch keinen,
der das selber entwickeln kann?
Gibt es, ja, tatsächlich.
Also, ob das sinnvoll ist, weiß ich nicht.
Aber gerade in mittelständischen Unternehmen,
die jetzt gerade SAP erst neu bekommen,
wird das tatsächlich so gemacht, ja.
Die dann auch merken,
ach, wir brauchen ja vielleicht doch jemanden,
die dann vielleicht auch mal Berater sich einkaufen.
Aber es gibt auch Firmen,
die das einfach so hinnehmen
und dann so lassen, wie es ist.
Also für die ist dann SAP wirklich so eine Art Microsoft Office.
Das kaufe ich einmal,
mache meinen Prozess und dann setze ich das ein, ja?
Genau.
Okay, witzig.
Ja, klar, kann man sich ja machen.
Ist ja eigentlich auch eine Standardsoftware.
Dafür ist sie ja eigentlich auch gedacht, sage ich mal.
Aber ist natürlich schon auch irgendwie ein Risiko,
wenn so krasse Geschäftsprozesse darüber laufen.
Das kennt sich eigentlich keiner mit der Software aus, ne?
Ja, das ist richtig.
Also ich weiß auch nicht, ob das richtig so ist.
Vor allem gerade, wenn ich mir die Software hole,
sollte ich zumindest jemanden haben,
der mir das erklärt
und Schulungen für die Mitarbeiter gibt und sowas.
Weil sonst ist man, glaube ich,
auch ganz schnell als User völlig überfordert.
Weil wenn man das vorher in weiß ich nicht was abgebildet hat
und jetzt auf einmal im SAP ist,
läuft halt doch alles ein bisschen anders.
So wie jeder halt so seine Software anders läuft.
So wie Microsoft Office oder Open Office.
Das ist dann doch was anderes.
Und wenn ich da nicht so affin bin,
weil ich nur Anwender bin,
dann ist das, glaube ich, schon ein bisschen schwierig,
sich da reinzufinden, so ohne Hilfe.
Ja, definitiv.
Also die Oberfläche ist jetzt,
wenn man sich so einige Masken anguckt,
jetzt auch ziemlich komplex teilweise.
Das ist auch für die Anwender schon schwierig, glaube ich.
Ja, richtig.
Und man kann zwar beim Customizing viel machen.
Also ich kann bei vielen Programmen einfach die Masken
dann alles ausblenden, was ich nicht brauche.
Aber wenn ich ja mich beim Einstellen schon nicht auskenne,
dann habe ich halt da, weiß nicht, 50 Felder
und brauche davon vielleicht nur 10.
Das natürlich macht es nicht einfacher für die Leute.
Ist das denn genau jetzt das Problem?
Also SAP kann eigentlich alles,
hat meinetwegen die 100 Felder im Background.
Ist das dann so, wenn man in den Code auf der anderen Seite einsteigt,
also wenn du jetzt irgendwie was anpassen musst tatsächlich,
hast du dann wirklich eigentlich mit diesem enorm großen Datenmodell
und auch der Komplexität zu kämpfen im Hintergrund immer?
Ja, zum Teil auf jeden Fall.
Also was manchmal ganz schlimm ist,
SAP speichert an ganz vielen verschiedenen Stellen irgendwelche Daten.
Und wenn ich jetzt irgendwas auslese,
muss ich mir erstmal überhaupt zurechtsuchen,
wo ist jetzt was gespeichert und wie komme ich an was?
Also es ist manchmal schon,
es sieht vielleicht irgendwann relativ einfach aus.
Ich hatte heute wieder so ein Programm, wo ich mir denke,
eigentlich sieht das aus, als hätte ich das in zwei Stunden runtergeschrieben.
Aber die ganze Vorarbeit, um überhaupt rauszufinden,
wo komme ich denn überhaupt an die Sachen, die ich brauche,
ist manchmal schon ein bisschen verwirrend und viel.
Und hast du da irgendwie eine Strategie,
beziehungsweise gibt es da bei euch irgendwie Schulungen,
um da sowas zu lernen oder musst du da auch tatsächlich selber
so ein bisschen Archäologie betreiben?
Das ist tatsächlich Learning by Doing.
Also da führt gar kein Weg dran vorbei.
Und natürlich hat man dann Kollegen, die man fragen kann
und jeder weiß so ein bisschen was anderes.
Und der eine kennt es mit dem Modul besser aus
und der nächste mit einem anderen.
Aber im Endeffekt muss man es einfach Learning by Doing
und manchmal auch einfach suchen.
Okay. Und da gibt es dann irgendwie so eine Riesen, keine Ahnung,
jetzt zum Beispiel, wie bei Microsoft, so eine MSDN,
wo irgendwie alle Funktionen drinstehen, die es gibt.
Oder wie findet man das dann?
Ja, auch die gibt es.
Die kann ich mir direkt aus dem Source Code aufrufen.
Über F1 habe ich dann direkt die Hilfe.
Und da steht alles drin, was es manchmal,
also gerade wenn man anfängt mit ABAP,
fand ich das zum Teil sehr verwirrend,
weil es gibt dann auch Befehle, die eigentlich schon obsolet sind
und gar nicht mehr verwendet werden sollen.
Dann gibt es welche, die gar nicht mehr verwendet werden dürfen.
Und das ist manchmal auch so ein bisschen Frickelarbeit
und ausprobieren, was geht denn in welchem Kontext,
was kann ich machen, was darf ich machen,
was sollte ich nicht machen.
Und da muss man auch erst mal lernen, damit umzugehen, mit der Hilfe, die man da gestellt bekommt.
Gibt's denn da irgendwie dann so eine Art, ich soll mal sagen, eine Art Zeitkonto, wo du irgendwie pro Woche x Stunden
in so eine, ich sag mal, Forschungsarbeit oder Weiterbildung oder sowas investieren darfst?
Oder ist das quasi die Zeit, die du dann einfach beim Kunden am konkreten Projekt verbringst und das in dem Kontext dann irgendwie ermittelst?
Das kommt drauf an. Wir hatten jetzt den letzten Kunden, da haben wir eine Unicode-Umstellung gemacht
und haben im Endeffekt auf jedem Modul gearbeitet. Und wenn dann ein Fehler hochkommt in Programm XY,
muss ich was anpassen, dann weiß ich ja erst mal gar nicht, wie funktioniert dieses Programm überhaupt,
weil das irgendwer geschrieben hat. Und da war es eben so, dass du viel nachgucken musstest, ausprobieren musstest,
da wurde das alles auf dem Kunden quasi gebucht, weil das von vornherein klar war, dass wir uns nicht mit jedem Programm auskennen können.
Und wenn ich jetzt Wachen mache, die normal sind, der Standard sind, so wie beim aktuellen Projekt,
das kommt immer drauf an, wie viel Zeit einfach für das Projekt noch da ist. Und was muss ich mir angucken?
Ist das mein Fehler, dass ich mir das angucken muss? Oder ist es einfach, weil ich das noch nicht so lang mache?
Oder weil es eine neue Anforderung vom Kunden ist? Das muss man dann immer so ein bisschen abwägen
und mit dem Projektverantwortlichen dann einfach klären.
Okay. Und ist das dann wirklich so, also habe ich jetzt noch gar nicht gefragt, aber bist du jetzt quasi ein Consultant für das HCM-Modul
und kennst dich damit besonders gut aus? Und ist das bei deinen Kollegen dann halt irgendwer anders, der ein anderes Modul macht?
Oder macht man das auch übergreifend? Oder wie funktioniert das dann?
Also meine Kollegen sind alle für ein Modul Berater. Bei mir ist das ein bisschen schwierig.
Okay.
Weil ich habe in der Ausbildung eben mit HCM angefangen, bin dann zum Solution Manager gewechselt,
dann nochmal zurück ins HCM und bin jetzt im BW und MFI. Also wieder was ganz anderes.
Deswegen gibt es halt bei mir dann auch einige Sachen, die ich nicht auf das Kundenkonto buche,
weil ich einfach sage, da kann der Kunde ja nichts für, dass ich einfach noch nicht tief genug in der Materie drin bin
und mir ein paar Sachen einfach noch angucken muss.
Magst du ganz kurz einmal sagen, was BW und MFI heißt?
Ja. Also MFI ist alles, was Finanzbuchhaltung und den ganzen drumherum, also alles, was mit Geld zu tun hat,
dann auch mit BWL-Kundenbuchung. Da werden auch die Abschlüsse drin gemacht und solche Geschichten im FI.
Und BW steht für Business Warehouse. Das ist so schwierig. Das hat mit Kundendaten und solchen Geschichten zu tun
und Bestellungen vom Kunden und ist viel vernetzt mit dem Materialstammsatz, wo ich dann meine Materialien drin habe
und welche Maschine benötigt wie viele Schrauben und solche Geschichten.
Und wo ich dann auch von dem Kunden quasi direkt bestellen kann und die Rechnung dann und alles den ganzen Summs eingeben kann.
Es greift halt alles so ein bisschen auch ineinander im Moment, weil wenn der Kunde was bestellt, kriege ich natürlich auch Geld.
Das muss dann wieder in die Finanzbuchhaltung und ja, es greift alles ineinander.
Ja, aber das sind ja auch so, wenn du es jetzt sagst, super unterschiedliche Bereiche, die auch für sich alleine schon eine enorme Komplizität haben,
die ganze Finanzbuchhaltung und so weiter. Das heißt, da musst du auch wahrscheinlich sehr tief auch in der fachlichen Materie drinstecken, oder nicht?
Ja, zum Teil schon. Also ich habe auch jetzt bei der jetzigen Firma angefangen, erst mal einen Monat fast,
und so eine Grundlagenschulung quasi gemacht über das ganze BW und MM und FI-Thema,
wo man auch wusste, wo es darum ging, wann stelle ich denn eine Rechnung? Was ist denn mit den Kundendaten?
Welche Daten vom Kunden speichere ich überhaupt? Was passiert, wenn ich geliefert habe und solche Geschichten?
Einfach um auch das fachliche Hintergrundwissen so ein bisschen zu haben, weil sonst funktioniert die ganze Arbeit am SAP nicht.
Wenn ich nicht verstehe, warum ich jetzt eine Rechnung rausschicken muss, dann kann ich es auch schwierig programmieren.
Ja, genau. Richtig. Aber wie gehen denn die Kunden dann an so einen Termin zum Beispiel ran?
Also wenn die jetzt sehen, Mensch, da ist so ein SAP-Consultant, dann erwarten die, dass du es fachlich und technisch einfach total drauf hast?
Ja, definitiv. Also die erwarten natürlich, dass man es total drauf hat, weil dafür zahlen die ja auch Geld.
Und deswegen bringt das auch nichts da irgendwie Versprechungen zu machen, die man nicht halten kann.
Also am Anfang wurde bei den Terminen zum Beispiel immer gesagt, dass die Nina, die ist jetzt seit einem Monat bei uns,
die ist gerade von der Ausbildung fertig und kennt sich noch nicht so gut aus.
Also ich wurde auch am Anfang grundsätzlich bei Kundenterminen nicht bezahlt, weil du musst ja erstmal lernen.
Und du kannst ja nicht vom Kunden erwarten, dass der x Euro für dich ausgibt, obwohl du da drin sitzt und eigentlich gar nichts beitragen kannst.
Da wird schon unterschieden. Die sind jetzt noch Trainees. Der Fokus ist bei denen noch das Lernen.
Und sobald die dann fertig sind, dann wird auch eine Rechnung geschrieben.
Ja, also im Normalfall läuft es eben so, dass am Anfang fragst du den Kunden auch, ob das okay ist, dass du die Person mitbringst,
weil es ja auch Datenschutz unserer Geschichten ist. Erstmal gucken, ob der Kunde das möchte.
Und wird am Anfang eben keine Rechnung gestellt. Und dann fängt man ja bei der Stufe Junior an
und wird natürlich auch mit deutlich weniger berechnet als jemand, der Senior Consultant ist.
Okay. Junior und Senior, das hört man jetzt häufiger. Ist das irgendwie so eine allgemeine Bezeichnung für so eine Seniorität?
Oder ist das jetzt was, was nur bei SAP immer benutzt wird?
Ich glaube gar nicht, dass das was SAP spezifisch ist, weil es gibt ja auch irgendwie Junior PAP Entwickler oder sowas.
Das ist, glaube ich, einfach so die Stufe, dass du weißt, ey, der macht das noch nicht so lang, der lernt noch, aber ist auch nicht mehr in der Ausbildung.
Also das ist vermutlich einfach so die Stelle nach der Ausbildung oder nach dem Studium.
Und je nachdem, wie viel man dann irgendwie drauf hat fachlich, steigt man halt auf.
Ich bin mir jetzt nicht mehr ganz sicher, ob du es gesagt hast. Wie war das denn in der Ausbildung?
Also durftest du da auch mit zum Kunden und hast dir das dann da angeguckt? Oder wie lief das?
Wir hatten bei der Ausbildung quasi gar keinen Kunden. Wir hatten den Fachbereich, der die Anforderungen gestellt hat.
Mit dem hatte ich nicht ganz so viel zu tun. Ich war zweimal an einem Termin dabei.
Das war tatsächlich auch nur für mein Abschlussprojekt. Und ansonsten lief das einfach.
Der Fachbereich hat gesagt, er möchte irgendwas geändert haben.
Und die Dame, die für mich zuständig war für die Ausbildung, die hat dann überlegt, ob ich das machen kann oder nicht.
Und sie hat quasi dann mit mir das alles gemacht, hat mir dann erzählt, was umgesetzt werden muss, was das Ziel ist.
Und hat dann auch zum Teil gesagt, mach du mal, wie du denkst oder erzähl mir, wie du es machen würdest.
Und dann haben wir das gemacht.
Also eigentlich, ich sage jetzt mal, wie man sich so eine klassische Ausbildung vorstellt.
Jemand, der dann Ansprechpartner ist und dir das quasi beigebracht hat.
Genau, ja.
Okay, ja, ich habe mir schon ein paar Städte notiert, wo du schon im Einsatz warst.
Du hast ganz am Anfang gesagt, du kommst aus Bayern, musstest aber schon nach Braunschweig, Kiel, Hamburg und so weiter.
Also ist das dann auch so dein Arbeitsalltag, dass du ständig woanders unterwegs bist?
Im Moment gar nicht. Im Moment bin ich tatsächlich nur hier.
Und der Kunde ist irgendwie fünf Kilometer weiter von mir zu Hause als das Büro.
Und ich schlafe tatsächlich im Moment jeden Tag zu Hause.
Früher in meiner alten Firma war ich sehr viel unterwegs.
Also Braunschweig war alle zwei Wochen zwei Tage.
Sind meistens sonntags losgefahren und dienstags wieder zurück.
Dann hatte ich eben Kunden in Lübeck, in Hamburg, in Kiel, in, ich weiß nicht wo, überall in München.
Da habe ich in Heidelberg gewohnt bei der alten Firma.
Da ist man dann auch nach München gefahren.
Also es kommt ganz darauf an, welche Kunden man hat, welche Projekte.
Es gibt auch Kunden, mein altes Projekt in Konstanz sitzt der Kunde.
Die haben wir kein einziges Mal gesehen, weil die haben gesagt, doch uns reicht das,
wenn wir über Skype irgendwie regelmäßig eine Telco haben.
Und den Rest macht ja einfach Remote und alles ist wunderbar.
Okay.
Ist eigentlich ja in anderen Bereichen auch ab und zu mal üblich, dass man nicht immer ständig hin und her fährt.
Aber wenn du auch schon sagst, ihr müsst halt viel auch mit dem Business-Bereich zusammenarbeiten.
Es ist ja auch in der normalen Softwareentwicklung und nicht im SAP-Umfeld so, dass es am besten ist,
wenn man einmal mal face-to-face mit den Leuten redet, zumindest um sich kennenzulernen.
Ich kann das schon verstehen, dass man da mal hinfahren muss.
Ja, es kommt halt ganz auf den Kunden an.
Also ich hatte Kunden, die gesagt haben, wir wollen dich einmal sehen.
Haben mir dann einen Laptop mitgegeben und hier arbeitest du dran,
den ich dann irgendwann mit der Post tatsächlich zurückgeschickt habe.
Es gab Kunden, die wollten, dass man komplett die ganze Zeit vor Ort ist.
Und es gab Kunden, die wollten, dass man ab und zu sich blicken lässt.
Also das ist ganz unterschiedlich.
Aber grundsätzlich, glaube ich, ist ja sogar die Entwicklung im SAP-Umfeld dann remote relativ einfach,
wenn du eigentlich dich nur mit diesem System verbinden musst und die ganze Entwicklungsumgebung da ja quasi drin ist, richtig?
Ja, also prinzipiell ist es auch völlig egal, ob ich hier im Büro sitze oder beim Kunden.
Vom System her ist das völlig wurscht.
Ja, das ist natürlich echt ein sehr guter Vorteil.
Wenn ich sonst auf der Entwicklermaschine erstmal, ich weiß nicht, 37 Tools installieren muss,
um überhaupt irgendwas nachbilden zu können, das ist da natürlich dann nicht der Fall.
Ja, das ist richtig.
Es ist nur manchmal ein bisschen schwierig, sich mit den Kundensystemen zu verbinden,
weil auch da jeder Kunde so sein eigenes Ding hat.
Und manchmal sind da seltsame Konstellationen.
Ich hatte, wie gesagt, bei dem einen Kunden mal, der hat mir dann einen Laptop mitgegeben,
weil man in den Netzwerk nur mit eigener Hardware kommt.
Und da musste ich mich dann entscheiden, entweder ich verbinde mich mit dem VPN,
sodass ich auf das SAP-System komme, oder ich habe eine Internetverbindung.
Ja, das kenne ich. Sponsorende Versicherung, ha, genau so.
Und das Schönste war dann, wenn der Kunde angerufen hat,
ja, wir machen heute ein Telco und jetzt sharen Sie doch mal Ihren Desktop.
Wir wollen gerne mal sehen, was Sie so gemacht haben, wie weit Sie sind.
Und dann sitzt er da und ist ja, ja, und wie?
Weil entweder ich kann mit euch telefonieren oder ich kann euch das System zeigen.
Beides geht nicht.
Also bei unserer Hardware ist es sogar noch schlimmer.
Ich habe ein bisschen gelogen, denn man hat entweder VPN oder einfach gar nichts.
Also ohne VPN geht auch kein Internet. Das ist noch restriktiver tatsächlich.
Sehr gut. Also was mich immer nochmal interessiert,
wenn du jetzt so bei Kunden unterwegs bist,
warum arbeiten die Kunden überhaupt mit Consultants, mit externen Leuten zusammen?
Warum stellen die nicht eigene Leute ein oder machen das selbst?
Sind das tatsächlich immer irgendwie nur so Hochzeiten,
wo ihr irgendwie unterstützen müsst, weil zu viel auf einmal kommt?
Oder sind das einfach auch Leute, die komplett mit Externen zusammenarbeiten?
Was sind da so die Gründe?
Also ganz oft sind es die Gründe, weil die Kunden nur für Projekte einkaufen.
Und ich hatte schon Projekte, die waren in einem Monat vorbei.
Das war halt nur für ein Programm quasi oder eine Aufgabe, die erledigt werden musste.
Und dafür kaufe ich halt dann jemand ein.
Der ist dann nach einem Monat wieder weg und ich habe nach einem Monat keine Kosten mehr.
Wenn ich mir dafür jemanden fix einstelle, bleibt der natürlich länger als ein Monat.
Das ist dann irgendwie doof.
Okay, setzt natürlich auch voraus, dass das Problem dann wirklich nach einem Monat gelöst ist
und nicht noch irgendwie laufend gepflegt werden muss.
Ja, richtig. Aber wir hatten jetzt zum Beispiel das Unicode-Projekt.
Das fing an letztes Jahr im September, Oktober, glaube ich.
Und wir sind jetzt letzten Monat fertig geworden.
Das ist zwar schon relativ lang für ein Projekt,
aber trotzdem besser, als wenn ich mir dafür fünf Leute komplett fix einstelle,
die ich danach einfach nicht mehr brauche.
Weil wir haben das System nur Unicode-fähig gemacht im Endeffekt und umgestellt.
Und das ist ja dann erledigt.
Okay, ja. Wenn man so wirklich abgeschlossene Projekte hat.
Klar, das stimmt wohl.
Es gibt dort vor Ort Entwickler, aber die haben natürlich auch ihr Tagesgeschäft.
Und da konnte man jetzt nicht einfach fünf Leute abstellen für ein halbes Jahr und sagen,
ihr habt jetzt nur noch das zu tun.
Deswegen werden dann einfach Berater eingekauft, die sich darum kümmern.
Und dann hat man die dann nach dem Projekt auch wieder los.
Okay, das stimmt.
Aber wenn du jetzt wirklich in ein ganz neues Projekt reinkommst,
musst du dich ja dann auch in die custom-meisten Sachen in dem SAP-System erstmal einarbeiten,
weil das ja nicht überall immer identisch ist.
Geht da denn nicht auch viel Zeit gerade zu Beginn dann irgendwie verloren?
Das geht, weil das Customizing mir als Entwickler eigentlich völlig egal ist.
Okay.
Also im Zweifel kann es sogar sein, dass das Customizing am Ende angepasst werden muss an die Entwicklung.
Je nachdem, worum es geht.
Das heißt also in den meisten Projekten, wenn du wirklich eingekauft wirst und du kommst da hin,
bist du relativ schnell auch produktiv und kannst wirklich was umsetzen.
Ja, im Normalfall schon, außer der Kunde stellt sich irgendwie quer.
Okay, gut. Davon gehen wir jetzt mal nicht aus.
Oh, wir haben alles schon gehabt.
Sehr gut.
Ja, man ist bei manchen Menschen nicht allzu beliebt.
Ja, das ist vielleicht so ein bisschen dieses Klischee-Bild eines Consultants.
Gibt es da irgendwie auch eine weibliche Form für? Ich weiß es gar nicht.
Ich glaube, Consultant ist auch weiblich.
Ist auch weiblich, okay.
Ja, wenn natürlich dann die SAP-Leute im Anzug da auflaufen, ist natürlich dann immer so ein Eindruck, den man da hat.
Vielleicht.
Ja, wir hatten das schon.
Da war ich mit der Kollegin unterwegs und kam montags beim Kunden an und es war schon alles in trockenen Tüchern.
Der Vertrag war unterschrieben und alles.
Und dann kamen wir da an und dann erstmal Termin mit dem vorgesetzten Teamleiter und seinem Stellvertreter.
Und irgendwie haben die dann diskutiert und der Stellvertreter hat die ganze Zeit in Frage gestellt,
warum wir denn jetzt überhaupt hier sind und warum wir das denn machen.
Und er möchte das nicht, weil es ging darum, die SAP hat eine Schutzvorrichtung, wenn ich etwas entwickle.
Diese SAP hat drei Systemlandschaften.
Ich entwickle auf einem System, schiebe das dann aufs nächste zum Testen.
Und wenn da alles gut ist, dann schiebe ich es erst produktiv.
Und eigentlich ist das von der SAP vorgesehen, dass ich als Entwickler zwar vom Entwicklungssystem ins Qualitätssicherungssystem schieben kann,
aber nicht einfach so weiter.
Was ja Sinn macht eigentlich.
Aber das haben viele Kunden nicht so im Einsatz.
Die schieben einfach wild hin und her, wie sie das gerne möchten.
Dementsprechend sehen manche Systeme auch echt schlimm aus.
Und das war bei dem Kunden eben auch.
Und wir waren dafür da, um diese Sicherungseinstellung quasi vorzunehmen,
dass da zwei Leute das Ganze freigeben müssen, bevor das transportiert wird.
Und ja, das macht dem Entwickler erst mal das Leben schwieriger.
Und deswegen wollte er das nicht.
Und hat im Endeffekt anderthalb Tage mit uns darüber diskutiert.
Und wir sind dann nach zwei Tagen wieder gefahren, ohne irgendwas gemacht zu haben.
Weil er kam alle zwei Minuten ins Büro und hat wieder irgendwelche Fragen gestellt und wieder diskutiert.
Und so, dass du tatsächlich nicht zum Arbeiten gekommen bist.
Okay. Ja, das ist dann so ein bisschen bei den Entwicklern.
Da schleicht sich auch irgendwann die Routine ein.
Und wenn man dann mal eben auf der Produktion was ändern kann,
ist das natürlich auch ein kleiner Luxus, den will man nicht sich nachgeben.
Ja, richtig.
Das kann ich nachvollziehen.
Also ich möchte jetzt nicht zu sehr ins Detail zu unserer Firma gehen,
aber so ähnlich ist das bei uns auch.
Also genau, okay.
Das ist eigentlich eine schöne Frage, die mir jetzt gerade so eingefallen ist.
Also diese drei Stages, sage ich mal so, Entwicklung, QS, Prod, finde ich ja auf jeden Fall erstmal gut.
Gibt es denn da irgendwie auch moderne Konzepte,
vielleicht was man aus anderen Entwicklungsumgebungen kennt,
sowas wie ein Continuous Integration oder Unit Testing,
wo man dann sagt, das wird nur auf die QS deployed, wenn die Tests grün sind oder so.
Oder wie funktioniert das?
Ja, da haben sie auch alle so irgendwie ihre Sache.
Gibt dann oft noch ein Sandbox-System, auf dem dann erstmal überhaupt irgendwas gemacht wird,
bevor es aufs Entwicklungssystem darf.
Also es kommt ganz auf die Firma drauf an.
Manche sind da sehr streng, wo das tatsächlich so läuft,
wo dann auch bestimmte Personen irgendwas freigeben müssen, die ihr okay geben müssen,
bevor da irgendwas irgendwo hingeschoben wird.
Und manchen Kunden ist es irgendwie gefühlt egal.
Es ist ganz unterschiedlich.
Okay. Also ich habe jetzt immer so den Eindruck, ohne das genau bewerten zu können,
dass im SAP-Umfeld übrigens auch analog zu Adabas Natural, was wir im Einsatz haben,
dass da jetzt nicht unbedingt mit den modernsten Tools und Ideen und ich weiß nicht,
Docker und Microservice und so gearbeitet wird,
sondern dass es schon so das eigene Ökosystem gibt
und auch gerade zum Beispiel für so ein Deployment von Dev auf QS oder so,
dass es da einfach etablierte Verfahren gibt, von denen man eigentlich wenig abweicht.
Oder wie würdest du das einschätzen?
Also gibt es da auch irgendwie moderne Einflüsse, wo man merkt,
hier gibt es aber Kunden, die sind richtig topmodern und lassen die SAP auf Docker laufen oder irgendwas?
Nee, die sind da schon so alle ein bisschen in ihrer eigenen Welt.
Natürlich hat die SAP auch Werkzeuge, mit denen das gemacht werden kann.
Ich kann zum Beispiel den Solution Manager dafür nehmen, dass ich vorher ein Ticket brauche.
In dem Ticket muss stehen, was geändert wird.
Ohne das Ticket kann ich gar keinen Transportauftrag stellen,
mit dem ich dann irgendwo hinschiebe.
Man kann das relativ modern machen, aber viele nutzen es einfach gar nicht.
Ja, das passt zu dem, was ich aus dem Umfeld von Allerwas Natural kenne.
Also Allerwas Natural ist quasi genau das Gleiche wie SAP.
Die haben ein paar Jahre später, glaube ich, angefangen und auch versucht, da ihr eigenes Ding zu drehen.
Und da ist das heute auch noch genauso.
Die Leute arbeiten irgendwie noch auf dem Mainframe wie vor 30 Jahren.
Ich glaube, im SAP-Umfeld ist es vielleicht nicht ganz so extrem,
aber ich könnte mir da durchaus Parallelen vorstellen.
Ja, es ist halt einfacher.
Und es gibt halt viele Gradentwickler, die meisten sind, oder viele sind doch schon ein bisschen älter auch.
Und die machen das halt so, wie sie es schon immer gemacht haben.
Warum soll ich das ändern?
Weil es kommen irgendwie nicht so viele SAP-Entwickler nach.
Das ist jetzt nicht das, was jeder zu Hause im Wohnzimmer lernt.
Und deswegen hat sich das einfach so eingebürgert.
Und es wird halt einfach so weitergemacht, wie das die anderen Leute schon machen.
Ja, also gibt es da wirklich eine Art Nachwuchsproblem auch?
Weil das ist tatsächlich genau das, mit dem Adabas Network auch sehr, sehr, sehr, sehr stark zu kämpfen hat.
Ich hatte auf der letzten User Group, hat mir einer erzählt,
der hat seinen Datenbank-Administrator in den Ruhestand geschickt,
um ihn zu ersetzen mit jemandem, der dann 64 war.
Also auch nur noch ein Jahr Zeit hatte quasi.
Ist das im SAP-Umfeld auch so, dass da quasi wirklich Nachwuchs fehlt?
Ja, es gibt tatsächlich nicht viele, die damit anfangen,
weil du kannst es eben nicht wie Java oder C++ mal eben,
ich mache das jetzt und lerne das,
weil du brauchst halt einfach das SAP-System, um damit was anzufangen.
Klar kannst du dir das auch zu Hause auf deinem Rechner in der Testversion installieren,
aber das ist nicht mal so eben schnell, weil ich gerade Langeweile habe gemacht.
Und die SAP hatte mal die Theorie, wir stellen von Adab alles auf Java um,
weil das können ja viel mehr Leute und ist viel praktischer.
Und zu der Zeit haben dann natürlich die Leute aufgehört, Adab zu lernen,
weil auch die Stellen als EU lohnt ja nicht.
Wofür soll ich jetzt was lernen, wenn ich dann doch mit Java viel weiterkomme?
Und dann ist die SAP wieder zurückgerudert, hat gesagt,
eigentlich läuft doch alles, ist ja Quatsch.
Ja, also ich kenne mittlerweile schon den einen oder anderen,
der Adab entwickeln kann, aber es sind nicht so viele Leute.
In der ersten Firma nach der Ausbildung, in der ich war, waren wir 75 Consultants und davon
Vielleicht fünf Entwickler.
Okay, das finde ich jetzt allerdings krass. Aber was haben denn die 70 Leute dann gemacht? Nur über die Fachlichkeit geschnackt oder?
Ja, und das ganze Customizing.
Ah, okay. Also jetzt mal ganz blöd gesagt irgendwo
Config-Einträge gesetzt oder irgendwo Haken angekreuzt oder irgendwie sowas.
Ja, richtig.
Ah, okay. Wahnsinn. Okay, das ist heftig.
Also mein Kollege, der für mich zuständig war, meinte,
hat mir die anderen vorgestellt und die andere Kollegin meinte, oh Gott sei Dank bist du endlich da, der redet von nichts anderem mehr.
Weil er einfach
zugeschüttet war mit Arbeit, weil am Anfang gab es gar keinen Entwickler, zumindest in der Abteilung.
Und dann kam er und dann, ah, wir haben ja jetzt einen Entwickler, wir können dem Kunden ja jetzt anbieten, dass man ein paar Sachen anpassen kann.
Und sowas spricht sich halt rum. Also ich hatte in der Firma
mindestens fünf, eher sieben Projekte parallel.
Okay, Wahnsinn.
Das ist schon heftig.
Ja, das ist einfach auch so, der Großteil der Leute wirklich in Anführungszeichen nur das Customizing macht,
zeigt ja schon, wie enorm komplex dieses System einfach ist.
Krass. Aber wie geht ihr denn da
irgendwie vor, um irgendwie für Nachwuchs zu sorgen? Also bildet ihr da zum Beispiel selber aus oder
also für mich ist zum Beispiel so der Studiengang Wirtschaftsinformatik sowas, wo man, da wird man doch eigentlich quasi für SAP
ausgebildet. Holt ihr euch die Leute dann quasi vom Markt weg oder wie funktioniert das?
Ja, das ist gar nicht so einfach. Also wir sind im Moment 16 Leute, also jetzt eine kleine Firma.
Deswegen, Ausbilden funktioniert nicht, weil ich hatte zum Beispiel letzte Woche, saß ich bis auf Freitag die ganze Woche komplett alleine im Büro.
Also da ist mit Ausbilden einfach nicht, weil keiner da ist.
Und schwierig. Also die meisten, wir haben jetzt
letztes Jahr jemanden eingestellt, der komplett neu angefangen hat, der vorher studiert hat.
Und der jetzt erstmal überhaupt in die SAP Welt eintauchen möchte, der sagt, ja mal gucken, ob ich programmieren lerne oder nicht.
Das muss er für sich selber erstmal gucken. Und das ist halt, es ist wirklich schwierig.
Da einfach jemanden zu finden, der es kann und der da überhaupt Bock drauf hat. Also ich kenne auch
mittlerweile drei Leute, die alle mal abab gemacht haben, die gesagt haben, nie wieder.
Also das ist, man muss da auch schon Lust drauf haben und überhaupt auch auf die Idee zu kommen.
Ich bin jetzt Abab Programmierer, ich gehe jetzt in die Beratung.
Also ich denke, dass das Inhouse vielleicht ganz anders aussieht, weil viele Leute, die
denken, ich bin so der Entwickler, so klischee mäßig im Keller mit einer Kanne Kaffee.
Die würden sich nicht auf Beraterstellen bewerben, glaube ich.
Okay, ja, das ist dann vielleicht aber auch ein bisschen das Klischee, weil ich glaube, das ist auch so ein
bisschen das Klischee oder die Denkweise der Entwickler von den Consultants wieder, denn die Leute
werden ja definitiv gebraucht, so wie ich es jetzt höre.
Ja, natürlich.
Also jetzt, wo du schon das Klischee bemüht hast vom Entwickler, würdest du denn sagen, dass man
irgendwie besondere Skills oder sowas mitbringen muss?
Also gerade in Richtung Soft Skills, wenn man Consultant werden will?
Oder reicht auch die die fachliche und technische Tiefe da irgendwie aus?
Also da muss ich immer an das Gespräch denken während der Ausbildung.
Als ich mir dann überlegt habe, was mache ich dann nach der Ausbildung, habe ich mit einem meiner
Lieblingskollegen gesprochen, der auch externer Berater war und habe so
hin und her. Und ja, was denkst du denn?
Wie könnte ich denn weitermachen?
Dann sagte er, du könntest doch einfach in die Beratung gehen.
Und dann habe ich gefragt, was brauchst du denn als Berater?
Weil man kann sich das ja auch ganz schwer vorstellen, wenn man so drei Jahre in der gleichen Firma war,
drei Jahre der gleiche Platz und jetzt auf einmal soll man in die Beratung gehen.
Und er hat gesagt, und das kann ich so unterschreiben, gesagt Natürlich, das Fachliche
brauchst du, aber das Fachliche kann man lernen.
Und du musst eh als Berater immer lernen.
Es wird immer was Neues geben, was du können musst.
Und es wird immer Sachen geben, die du noch nie gemacht hast.
Aber er hat gesagt, was viel wichtiger ist, du musst, wenn du in den Raum kommst, musst du was
darstellen. Du musst irgendwie so wirken, dass die Leute dir zuhören.
Und du musst auch mal auf den Tisch hauen können.
Und das ist so. Also wenn ich da irgendwie als kleines graues Mäuschen in den Raum
betrete und gerade so Hallo sagen kann, wird mich keiner ernst nehmen.
Und gerade wenn man mit jungen Jahren dann als Berater unterwegs ist und ja, auch als
Frau wird man dann oft doch mal schief angeguckt, so nach dem Motto.
Was willst du denn jetzt? Und was soll ich?
Keine Ahnung. Und da muss man halt einfach Arschbanken zusammenkneifen und denen zeigen,
dass man auch Ahnung hat.
Okay, ich meine, das ist ja vielleicht auch was, wo viele Technikere so richtig Bock
drauf haben, sich so mit einer Programmiersprache richtig intensiv auseinanderzusetzen und
Probleme lösen und so weiter.
Und das natürlich dann auch noch vor anderen Menschen so darzustellen und vielleicht auch
sich darzustellen, was ja auch dazugehört.
Das fällt dann vielleicht dem ein oder anderen Techniker doch ein bisschen schwer.
Ja, man muss das definitiv lernen.
Ich hatte am Anfang ein Projekt, wo dann eben auch gesagt wurde, Nina, die ist noch nicht
lang dabei. Und dann war der Kollege und die Projektleiterin, also alle waren im Urlaub
und der Kunde hat dann immer meinem Kollegen per E-Mail geschrieben, mich komplett
außen vor gelassen. Mein Kollege hat mir die E-Mail dann weitergeleitet mit der Bitte, ich
soll mich doch daran kümmern.
Ich habe das dann gemacht, dem Kunden geantwortet und die Antwort vom Kunden ging wieder an
den Kollegen ohne mich.
Das Spiel ging zwei Wochen.
Nach zwei Wochen habe ich dann, ich habe das dann so weiter gemacht.
Am Anfang war das so völlig ätzend und du hast auch eigentlich keine Lust mehr.
Und was bist du denn für ein Arsch und nimm mich doch ernst.
Und man fühlt sich auch irgendwo verarscht, so ein bisschen.
Aber wir haben das dann zwei Wochen so weitergemacht.
Er hat mir die E-Mail weitergeleitet.
Ich habe geantwortet.
Der Kunde hat ihm geantwortet.
Und nach zwei Wochen war es dann so weit, dass der Kunde nur noch mir geschrieben hat, dem
Kollegen gar nicht mehr.
Und auch später, als der Kollege aus dem Urlaub wieder zurück war, wenn es eine Antwort
gab, ging die an mich.
Also man muss halt dann auch einfach quasi seinen Mann stehen und sagen, ey, mag sein,
dass das noch nicht so lange mach und du kennst mich nicht, aber ich kann das.
Also es ist schon eine Herausforderung offensichtlich, die erstmal mit der Technik gar
nichts zu tun hat.
Ja, definitiv.
Cool, ja.
Okay, also das hätte ich mir jetzt schon auch vorgestellt unter dem Beruf Konsulten,
dass man sich halt auch insbesondere mit den Menschen da auseinandersetzt.
Aber das ist dann so dieses klassische Klischee oder dass ich über die Anfänger gar nicht
kommunizieren möchte, sondern nur mit den vernünftigen Leuten.
Und das ist natürlich schwierig, wenn man das noch nie selber gehabt hat.
Wenn man zum Beispiel wirklich in einer Firma arbeitet, wo man halt nur mit den Kollegen
zusammen ist, dann kriegt man sowas natürlich gar nicht mit.
Ja, richtig.
Okay, also das hörte sich jetzt ja irgendwie zumindest für den Einsteiger nicht ganz so
prickelnd an, wenn so quasi über den eigenen Kopf hinweg kommuniziert wird.
Hast du denn irgendwie so ein bisschen jetzt mit deiner Erfahrung, du machst das jetzt
ja schon ein paar Jahre, irgendwie so ein bisschen eine Art Pro-Contra-Liste, wie du
sie schon zu Beginn angefertigt hast?
Was findest du eigentlich an dem Job gut und was findest du nicht so toll?
Was ich gut finde, dass es ständig was Neues ist.
Also es wird nicht langweilig.
Ich stelle mir manchmal einen In-House-Job fürchterlich langweilig vor, wenn man immer
das Gleiche zu tun hat.
Das ist auf jeden Fall mein Pro-Contra, eigentlich das Gleiche.
Man muss sich halt immer neu einarbeiten und man trifft auch manchmal auf Menschen, die
irgendwie nicht so sympathisch sind, die dann irgendwie seltsam dich behandeln, weil du
bist ja der böse Berater, der viel Geld kostet.
Der Vorteil daran ist aber wieder, wenn ich weiß, der Mensch sitzt beim Kunden, mit dem
ich nicht zurechtkomme, dann weiß ich heute nach Feierabend, ich muss ihn nicht sehen
und es ist mir egal, weil es ist ja nur beim Kunden.
Das würde mich in der Firma viel mehr stören, wenn ich da irgendwie mit dem Kollegen jeden
Tag das Büro teilen müsste, mit dem ich nicht zurechtkomme.
Das ist beim Kunden einfach ganz anders.
Wenn ich beim Kunden reingehe, ist das der Kunde, der bezahlt heute quasi mein Gehalt
für heute und wenn ich gehe, dann ist das quasi abgehakt.
Es hat schon Vorteile.
Nachteil.
Ja, schwierig, es ist viel Arbeit, es ist oft kein 9-to-5-Job.
Es ist ganz oft, dass auch mal jemand, das auch mal länger bleiben muss.
Ganz spontan hatte ich auch schon, dass abends um sechs der Kollege sagt, du, wir müssen
noch was fertig machen. Dann saßen wir bis abends um neun noch.
Wenn man dann natürlich irgendwie was vorhatte, ist das natürlich ein bisschen schwierig.
Da gibt es dann auch Leute, die dafür kein Verständnis haben und was nicht wenig häufig
vorkommt, gerade am Ende von Projekten, dass man eben auch am Wochenende oder mal nachts
arbeiten muss.
Und fühlt man sich da irgendwie, also so würde ich mir das vorstellen, ich sitze jetzt
hier beim Kunden und liefere dafür das Projekt ab und der bezahlt für mich ja auch ein
Heidengeld, sag ich einfach mal. Fühlt man sich da ständig irgendwie unter Beobachtung,
so nach dem Motto, oh, ich muss jetzt aber besonders gut programmieren, weil der bezahlt
mich ja dafür oder ist das nicht so?
Kommt auf den Kunden an. Hatte ich schon, dass der Kunde neben mir auf einmal stand oder
hinter mir. Ja, was machen Sie denn da?
Ich habe da mal im System geguckt und wollte mal wissen, was das und das und das ist.
Oder ich kam morgens beim Kunden ins Büro und hatte eine E-Mail vom Leiter der Entwicklung.
Ja, er möchte da eine Erklärung haben.
Er versteht nicht, was ich da gemacht habe.
Also wo man dann schon dachte, also ich habe gestern einen Feierabend gemacht und du hast
quasi zwei Stunden meinen Code durchwühlt und geguckt, was ich tue.
Das ist manchmal schon ein bisschen, dass man denkt, da sitzt einer neben dir und guckt
dir auf die Finger. Aber das hängt ganz stark vom Kunden ab.
Es gibt auch Kunden, die lassen dich einfach laufen und sind dann froh, wenn du dann
irgendwann Bescheid gibst, es geht jetzt.
Und es gibt halt welche, die natürlich erst mal gucken, gerade wenn du neu in die Firma
kommst und die dich noch nicht kennen.
Verstehe ich das auch irgendwie, dass sie dann erst mal gucken, was macht ihr denn da den
ganzen Tag? Weil wird ja bezahlt.
Genau. Da würde ich mir dann auch immer so irgendwie so kontrolliert vorkommen.
Ich meine, es ist ja gut, wenn man mal so ein Code-Review macht, aber da weiß man ja, dass es
kommt. Aber wenn der Kunde dann heimlich nur den Code durchschaut, dann ist er nicht
ah. Oh Gott, oh Gott.
Spannend. Und jetzt hast du schon gesagt, das ist natürlich auch sehr zeitintensiv und am
Wochenende und abends und hin und her.
Und dann geht man ja abends dann meist auch ins Hotel, vermutlich, weil man ja ständig
durch die Gegend reist. Ist das auch irgendwie für dich ein Negativpunkt oder?
Also ich fand das am Anfang sehr spannend, überall ständig zu sein, irgendwo anders,
wo man viel gesehen hat. Und ich hatte dann auch den Kollegen, mit dem ich mich sehr gut
verstanden habe, weil wenn man dann mal eben nach Braunschweig fährt, fünf Stunden im
Auto sitzt, ist das natürlich doof, wenn man sich nicht versteht.
Aber das war so ein bisschen Liebe auf den ersten Blick bei uns beiden und hat wunderbar
funktioniert. Dementsprechend, wenn wir zusammen auf Projekten waren, sind wir dann
abends was essen gegangen oder in Kiel zum Beispiel am Hafen einfach spazieren gegangen und
was trinken gegangen oder zum Bowling oder was auch immer.
Also da fällt einem schon was ein.
Aber es ist manchmal schon ziemlich ätzend, dann nur aus dem Koffer zu leben, irgendwie nur am
Wochenende zu Hause zu sein, zum Wäsche waschen und zum Putzen.
Hatte ich teilweise, dass du Freitagsabends um elf, zwölf irgendwann nach Hause kommst,
sonntags, nachmittags wieder los musst.
Da ist es wirklich nur, ich wasche mal schnell meine Wäsche, putze mal kurz durch die
Wohnung, einkaufen brauche ich eigentlich schon gar nicht, weil es lohnt nicht.
Ja, war wirklich so.
Das ist auf Dauer nicht ganz so angenehm und wirkt sich natürlich auch irgendwie auf
Sozialleben auf, weil viele Leute da so gar kein Verständnis für haben.
Also auch Freundschaften sind daran tatsächlich so ein bisschen kaputt gegangen, weil
sie irgendwie kein Verständnis hatten, warum, wenn man Freitagsabends erst um elf nach
Hause kommt, man am Samstag nicht irgendwie Party machen gehen möchte.
Ja, das kann ich verstehen.
Ja, ich stelle mir das auch immer sehr hart vor.
Also ich bin schon nach einer kleinen Dienstreise aber schon froh, wenn ich jetzt zu
Hause bin. Aber es ist natürlich auch sehr, sehr stark typabhängig.
Ich habe jetzt irgendwie auf der letzten Konferenz mit jemandem geredet, dessen Job
quasi es ist, auf den ganzen Konferenzen weltweit Vorträge zu halten.
Und der ist irgendwie auf 50 Konferenzen im Jahr und ständig irgendwie unterwegs und
der findet das halt richtig geil. Also das ist genau das, was er machen will.
Also für mich wäre das nichts, aber es ist auch wirklich sehr stark typabhängig.
Ja, bei mir klingt das jetzt vielleicht auch viel schlimmer, als es war.
Meistens war ich alle zwei Wochen unterwegs, so zwei bis drei Nächte.
Das erhielt sich dann noch in Grenzen.
Aber es gab also die schlimmste Woche war sonntags nachmittags nach Braunschweig.
Montag, Dienstag dort vor Ort jeweils acht bis zehn Stunden, dann am Dienstag weiter
nach Kiel für den Termin am Mittwoch und am Mittwoch nach dem Termin weiter nach
Hamburg. Da habe ich dann meinen Kollegen zum Flughafen gebracht, weil er am Freitag
in München sein musste.
Und ich bin dann am Freitag quasi zurück nach Heidelberg gefahren und dann noch mal
ins Büro. Also das war schon hart an der Grenze.
Und das war dann wirklich so, dass du denkst, endlich zu Hause eigenes Bett.
Aber man sieht halt auch viel von der Welt.
Also ich fand das oder von Deutschland in dem Fall.
Ich fand das schon sehr spannend, weil ich weiß nicht, ob ich sonst nach Braunschweig
zum Beispiel gefahren wäre oder ja, ich hatte dann auch mal ein Hotel in Lübeck
direkt am Strand. Das war super.
Machst morgens die Augen auf und kannst erst mal aufs Meer gucken und Schiffe.
Das ist dann schon auch was Schönes.
Cool. Aber da hat man dann, also wenn du jetzt auch sagst, ja, da muss man doch mal
eben bis neun Uhr arbeiten.
Oder hattest du dann zwischendurch auch tatsächlich irgendwie mal ein bisschen Zeit,
dir irgendwie was anzugucken?
Oder ist das eigentlich nur vom Hotel zum Kunden und wieder zurück?
Unterschiedlich. Wir haben meistens geguckt, wenn wir mehrere Tage da waren, dass wir
den ersten Tag dann irgendwie länger gearbeitet haben, dass zum zweiten dann irgendwie
ein bisschen Zeit hattest und dass man sich dann einfach was angucken kann.
Und gerade in den Sommermonaten war das auch gar nicht so tragisch, auch wenn dann erst
irgendwie spät oder wir haben einfach früh beim Kunden angefangen, dass du früh ins
Büro gehst und dann relativ früh auch wieder gehst, damit du so ein bisschen von der
Stadt zumindest hast.
Das muss man sich dann halt auch irgendwie versuchen, so ein bisschen selber zu legen.
Okay, dann ist es ja vielleicht noch ein bisschen so, keine Ahnung, dass man noch ein
bisschen Kultur mitnehmen kann oder halt einfach mal was Schönes sich angucken kann.
Dann ist natürlich, kriegt man sonst nicht zu sehen.
Ja, oder als ich in Lübeck war, das war eigentlich von Montag bis Freitag geplant, wobei
der Kunde gesagt hat, ich könnte auch Freitagmittag schon nach Hause fahren, das wäre
kein Problem. Aber ich bin dann bis Freitagabend geblieben, habe dann noch einen Tag
verlängert, das Hotel und bin dann mit der Kollegin, die aus Hamburg kam, in Hamburg
Freitagabends noch aufs Volksfest gegangen und noch was trinken und so was geht halt
dann auch.
Das ist natürlich auch nett, ja, cool.
Jetzt hast du schon gesagt, quasi auf deiner Pro-Contra-Liste steht eigentlich auf beiden
Seiten, dass man immer was Neues lernen muss.
Klar, ist auf deiner Seite stressig, aber es ist natürlich auch super spannend, auf
jeden Fall.
Wie, also ich persönlich bin ja immer ein Freund davon, dass ich irgendwie nochmal so ein
bisschen Bücher empfehle, wenn Leute sich da irgendwie einarbeiten wollen.
Jetzt ist es natürlich schwierig, wenn man Consulting auch viel mit Menschen und
Kommunikation zu tun hat.
Gibt es da überhaupt irgendwas, was man da empfehlen kann, um sowas zu lernen?
Also hast du da irgendwie vielleicht eine Buchempfehlung oder sagst du, das muss man
irgendwie wirklich Face-to-Face oder in Schulungen oder in einer Theatergruppe
lernen? Oder wie kann man überhaupt sich da weiterbilden in dem Bereich?
Ob man Consulting lernen kann, mit Büchern wage ich zu bezweifeln,
weil es mag so einige Regeln geben, wie zum Beispiel das mit dem, wann ziehe ich mein
Jackett aus oder solche Geschichten.
Aber das ist sehr stark typeabhängig und man muss es einfach machen.
Man muss einfach mit den Leuten reden und vielleicht einfach, wenn man das machen
möchte, auf fremde Menschen zugehen und mit Menschen sprechen.
Also quasi so, ganz blöd gesagt, wie werde
ich weniger schüchtern? Ich versuche einfach mal mit Leuten zu kommunizieren.
Guck mal, dass ich ins Gespräch komme, ein bisschen Small Talk.
Das, was man ja wahrscheinlich auch sogar macht, wenn man als Consultant den Kunden zum
ersten Mal sieht, muss man ja auch erst mal mit dem irgendwie ins Gespräch kommen und so ein
bisschen, ja, wie war die Reise? Wie war das Wetter?
Ganz genau, Small Talk ist ganz, ganz wichtig, weil man geht mit dem Kollegen, mit dem
Kunden ja auch vielleicht mal Mittagessen und da sich anschweigen ist natürlich
ziemlich doof.
Das ist tatsächlich ganz wichtig, auch Small Talk führen zu können und auch ein bisschen
das Gespür dafür zu haben, über was möchte er denn reden?
Wir hatten zum Beispiel einen Vertriebler beziehungsweise Projektleiter,
der hatte da totales Gespür für, über was möchte der Mensch mir gegenüber
sprechen? Was für Interessen hat der?
Und er hat dann mitgekriegt, dass von einer Firma ein ganz wichtiger, der über Geld
entschieden hat, um 15 Uhr immer zum Rauchen gegangen ist.
Und der Projektleiter raucht nicht, aber er ist um 15 Uhr dann mit zum Rauchen gegangen
und hat sich dann mit ihm über das Golfspielen oder was weiß ich unterhalten.
Und das ist einfach ganz wichtig, dass ich einfach dem Menschen das Gefühl gebe, ich
interessiere mich für ihn.
Ich rede nicht nur mit ihm, weil ich es jetzt muss.
Und das muss einfach irgendwie funktionieren, weil wie gesagt, wenn ich mit dem Kunden
zum Mittagessen gehe oder vielleicht auch mal abends essen gehe, weil der Kunde das
möchte, dann ist das ganz schlecht, wenn ich da nur sitze und nicht weiß, was ich
sagen soll.
Das stimmt. Aber es ist ja andersherum auch für den Consultant, der das dann macht,
eigentlich eine super Geschichte, weil man halt ganz viele unterschiedliche Leute auch
kennenlernt und ganz viele unterschiedliche Interessensgebiete oder auch technische
Gebiete ja kennenlernt. Also es ist ja auch sehr bereichernd, wenn man so viel mit
anderen Menschen kommunizieren muss.
Ja, richtig. Und ich finde das auch sehr interessant.
Ich freue mich immer, wenn ich mit einem Kollegen telefoniere, der in Singapur wohnt.
Das ist ganz schön, weil er auch immer so ein paar Sachen erzählt, wie das dann so in
Singapur ist, weil ich mir das gar nicht vorstellen kann.
Und das ist schon schön.
Ja, das finde ich schön.
Also es ist ein schöner Abschluss, finde ich, um nochmal zu zeigen, was so der Beruf
auch an positiven Sachen mit sich bringt, auch wenn er vielleicht ein bisschen
stressiger ist als so eine Festanstellung irgendwo im Büro.
Aber dass man halt auch ganz andere Perspektiven dadurch bekommt, andere Städte
kennenlernen, andere Menschen kennenlernt.
Also das, finde ich, hört sich sehr spannend an auf jeden Fall.
Ist es, ja.
Sehr schön. Ja, damit wäre ich jetzt mit meiner Frageliste eigentlich durch.
Haben wir noch irgendwas zum Bereich Consulting vergessen, was du gern noch
besprechen möchtest?
Ich glaube nicht. Nee, wir sind ja auch schon fast bei anderthalb Stunden.
Ja, wir haben ganz gut was rausgehauen hier, aber ich fand es sehr, sehr spannend.
Für mich persönlich auch sehr spannend, weil ich diesen großen Bereich der SAP
selber ja noch nicht kennenlernen durfte.
Und ja, es ist halt schon irgendwie ein Entwicklervölkchen
so für sich ist und auch ja nicht ganz so klein, weil es halt wirklich in vielen
Firmen eingesetzt wird, von daher für mich auch sehr, sehr interessant heute.
Also hat mir wirklich Spaß gemacht.
Ja, das ist schön. Das freut mich.
Aber zum Abschluss habe ich doch noch eine kleine Frage, die ich eigentlich schon am
Anfang stellen wollte. Jetzt hast du ja ein bisschen mit ABAP und Java und so
gemacht. Hast du persönlich denn eine Lieblingsprogrammiersprache?
Ich weiß nicht. Ich glaube nicht. Nein.
Also ich arbeite ganz gern mit dem ABAP, aber ich weiß nicht, ob ich es als
Lieblingsprogrammiersprache bezeichnen würde.
Es ist halt meine Arbeit.
Also ich arbeite gern damit.
Gibt viele Leute, die es ja verfluchen.
Aber als Liebling würde ich nicht bezeichnen.
Nein.
Okay, sehr schön.
Kann ich verstehen.
Gut, dann würde ich sagen, kommen wir einfach zum Abschluss.
Wenn jetzt die Leute vielleicht noch mit dir in Kontakt treten wollen und noch was
wissen wollen oder einfach mehr über dich erfahren wollen.
Gibt es irgendwas, wo man dich online finden kann?
Selbstverständlich.
Sehr gut.
Möchtest du das kundtun?
Da bin ich mir gerade nicht so sicher.
Okay, nein.
Sie können mir natürlich im Fachinformatikerforum schreiben.
Ah, sehr gut.
Da haben wir uns nämlich rein zufälligerweise auch kennengelernt.
Ja, sehr gut. Da bist du auch sehr aktiv.
Genau.
Ja, das finde ich gut, dass du trotz deiner Zeit als Consultant noch irgendwie Zeit
aufbringst, um da Leuten auch zu antworten und so.
Ja, ist ja auch richtig so.
Und ich habe da ja auch Hilfe gesucht.
Also von daher.
Dann gibt man das später wieder zurück.
Das finde ich gut.
Sollten irgendwelche Kontaktmöglichkeiten bestehen, packt die natürlich in die
Shownotes, wenn die Leute dich kontaktieren wollen.
Ich bin sehr gespannt auf das Feedback zur Episode, wenn es denn welches gibt.
Ja, ich auch.
Wenn du nichts mehr zu ergänzen hast, würde ich sagen, dann sind wir fertig.
Ja.
Sehr gut. Dann sage ich nochmal vielen, vielen Dank für das interessante, für
mich sehr spannende Gespräch und schön, dass du dir Zeit genommen hast.
Ja, sehr gerne. War schön, dass du mich eingeladen hast.
So, das war also mein Interview mit Nina.
Es hat mir sehr viel Spaß gemacht und Nina anscheinend auch.
Wir haben auf jeden Fall ohne Ende gequatscht über das Thema Consulting.
Und vielleicht hat es dir jetzt auch ein bisschen geholfen, um dir mal einen
Einblick zu geben, was man eigentlich so den ganzen Tag macht und was so die
Herausforderungen dieses Jobs sind.
Und vielleicht möchtest du ja sogar selber in diesem Bereich aktiv werden.
Wäre doch vielleicht eine coole Geschichte.
Die Shownotes zur Episode findest du wie immer unter
anwendungsentwicklerpodcast.de
slash 111 für die 111.
Episode, die das hier heute war.
Und da findest du alle Links und genannte Literaturquellen und alles, worüber wir
so gesprochen haben.
Würde mich freuen, wenn du mal reinschaust.
Und wir freuen uns natürlich auch auf dein Feedback.
Also wenn es dir heute gefallen hat oder wenn du selber noch was beizutragen hast,
dann schreib uns doch einfach einen Kommentar.
Das würde uns sehr freuen.
Damit sage ich für heute vielen Dank fürs Zuhören und bis zum nächsten Mal.
Tschüss.










Mensch, Herr Macke, det war ja mal ’n feines Interview!
🙂
Danke auch an Frau Sauermann für die Offenheit und die klaren Worte – fand ich sehr erfrischend und informativ!
Definitiv keine vergeudete Zeit! Prima.
Hallo Ingo,
schön, dass dir das Interview gefallen hat. Ich fand es auch sehr spannend. Die SAP-Welt ist ja sonst nicht ganz so zugänglich (zumindest meines Eindrucks nach) und ich fand den Einblick in die Welt der Consultants auch sehr interessant.
Viele Grüße!
Stefan
Hallo Ingo,
vielen Dank für dein Feedback. Es freut mich, dass das ganze für dich informativ ist. Dann haben wir ja was richtig gemacht 🙂
LG
Nina
Diese Folge und die letzte waren die interessantesten, die ich im ganzen Podcast gehört habe (ich habe alle Folgen gehört). Sie machten was ich mir immer von dem Podcast gewünscht habe, nämlich mehr über echte Projekte und über den „normalen“ Arbeitsalltag eines Anwendungsentwicklers zu sprechen. Ja, ich will über die ständigen Probleme hören. Nach meinem eigenen stressigen Alltag kann ich ehrlich gesagt nichts unterhaltsameres und erfrischenderes hören :P. Natürlich lernt man auch viel über die Denkweise, die einem dabei hilft diesen Stress zu bewältigen, was immer sehr hilfreich ist.
Schön, dass dir unser Gespräch gefallen hat. Ich schaue mal, ob ich noch weitere Gesprächspartner für Praxisberichte finde.
War der erste Podcast den ich hier angehört habe und fand ihn gut. Authentische Praxisberichte sind fast immer interessant. Habe den RSS feed abonniert und mal sehen was noch kommt. Grüsse, bigvic
Hallo bigvic, das freut mich! Und es kommen bestimmt noch mehr spannende Inhalte! 😉