Braucht ich unbedingt SAP ERP zum Besuch ABAP-Kurs?

Re: Braucht ich unbedingt SAP ERP zum Besuch ABAP-Kurs?

Na ja, ABAP ist eine Programmiersprache. Als solche lässt sie sich schon isoliert erlernen. Nutzen tut man sie allerdings zum Umsetzen und Unterstützen von Geschäftsprozessen. Von daher macht es schon auch Sinn, sich ergänzend mit SAP zu beschäftigen.

Ob allerdings ein generischer "integrierte Geschäftsprozesse"-Kurs dafür taugt, habe ich so meine Zweifel. SAP ist in viele Module für verschiedenste Anwendungsbereiche gegliedert. Kein Mensch kennt sich in allen Modulen aus. Von daher würde ich eher empfehlen, sich mit einem interessanten Modul zu befassen und in Kombination damit dann ABAP zu erlernen, damit man etwas hat, worauf man sein ABAP anwenden kann.

Re: Braucht ich unbedingt SAP ERP zum Besuch ABAP-Kurs?

Hallo,

meine Meinung geht in die Richtung des Vorgängers. Natürlich kannst Du in ABAP auch "Schiffe versenken" programmieren.

Ich denke aber, dass es extrem hilfreich ist, wenn Du das Umfeld verstehst, in dem Du Dich bewegst. Also zum Lernen erstmal nicht, im Job / Praktikum aber sehr sinnvoll.

Gruß

Re: Braucht ich unbedingt SAP ERP zum Besuch ABAP-Kurs?

Der Sturz von der Theorie in die Prraxis ist in jedem Fall tief, weil Übungsaufgaben in sich stimmig und didaktisch korrekt aufgebaut sind. Beim Flugmodell ist bekannt, wo was steht. Gerade das muss man aber oft erstmal herausfinden. In welcher Tabelle stehen welche Daten zum Technischen Platz?

Die Frage, ob dieser Schnellkurs etwas bringt, ist allerdings berechtigt — die Praxis ist dann doch immer komplett anders. Aber vielleicht bekommt man ein Gefühl dafür, was ein Prozess ist und wie Prozesse beispielhaft Abhängigkeiten unterliegen.

Viel mehr wird der kaum leisten können.


Ralf

Re: Braucht ich unbedingt SAP ERP zum Besuch ABAP-Kurs?

DeathAndPain hat geschrieben:Das ist wie wenn man objektorientierte Programmierung anhand vom Objekt "Flugzeug" erklärt, mit Superklasse "Fortbewegungsmittel", zu der es auch andere Ausprägungen "Auto" und "Schiff" gibt, mit Attributen wie "Höchstgeschwindigkeit" und Methoden, die diese setzen oder lesen. Alles wunderbar schlüssig, aber hinterher fragt man sich, was einem das alles nutzt, wenn man in ABAP reale Kundenanforderungen umsetzen soll, denn da geht es um die Umsetzung bestimmter Prozesse und nicht um theoretische Datenmodellierung von Objekten des täglichen Lebens.

Richtig, zumal es immer dieselben Beispiele sind. Wirklich VERSTEHEN tut man es dann, wenn man es wirklich TUT. Als ich dachte, ich hätte es begriffen, öffnete sich mir eine unglaublich vielfältige Welt von Möglichkeiten und ich wusste: Ich habe bestenfalls angefangen, es zu begreifen.

Und wenn man dann mal ein richtig großes Ding schreibt und dann merkt, dass die "Grundgesetze" immer dieselben sind. Dann kann man wirklich die Prozesse (die die Objekte miteinander kommunizieren lassen) so allgemein codieren, dass es als Nebenwirkung dazu führt, dass die einzelnen Codingstrecken isoliert betrachtet nicht mehr verständlich sind (da gebe ich Daniel durchaus recht), was aber auch den Wartungsaufwand dramatisch senkt, weil man das Rad nicht ständig neu erfindet (und x Stellen ändern muss, wenn sich das Rad ändert). Aber man darf so ein Coding eben nicht isoliert betrachten, sondern im Kontext des Ganzen Großen. Nur weil etwas kompliziert ist, muss man ja nicht die Finger davon lassen (ansonsten könnte man die Automobilindustrie zumachen), man muss halt höhere Ansprüche an die stellen, die es machen und die, die es warten.

Alternativ: Man packt Wissen wirklich in das Coding, so dass andere Entwickler etwas damit anfangen können. Dann muss aber einer den Hut aufhaben, der sieht "das hatten wir woanders schonmal, mach eine Serviceklasse dafür" (oder von mir aus auch eine Service-Funktionsgruppe). Dann braucht sich kein Mensch mehr darum zu kümmern, wie es funktioniert (es kann aber jeder, wenn es mal sein muss), man benutzt einfach etwas Fertiges, von dem man weiß, dass es funktioniert.

Ich habe nun einige Projekte gemacht, wo DB-Anweisungen verboten sind (selbst ein einfacher SELECT) und zuerst mag man stutzen, aber irgendwann wird einem klar, welche Vorteile es hat, wenn man die Persistenz auf diese Weise abstrahiert.

Aber dazu muss man es wirklich mal gemacht haben - und ich kenne eine Reihe von Zweiflern, die sich im laufenden Projekt bekehren ließen, weil sie gesehen haben, was sie alles NICHT mehr machen müssen. Darum nehme ich Leute in der Diskussion nicht ernst, die OO nie ausprobiert haben. Da bin ich eigen.

Aber diese Unterschiede zwischen Theorie und Praxis (die wir ja auch beim Flugmodell thematisiert haben), gibt es überall. Ich bin Segler und man lernt rauf und runter, die man ein gekentertes Boot aufrichtet und weiterfährt. Beim ersten Kentern (bei mir: beim Kentertraining) stellt man dann verwundert fest, wie hoch selbst eine kleine Congerjolle ist, wenn man selbst buchstäblich bis zum Hals im Wasser steckt. Da kommt man nicht hoch, wenn man nicht ziemlich gelenkig und sportlich ist. Das Weiterfahren ist kein Problem, das Aufrichten auch nicht. Aber wenn das Boot aufgerichtet ist, fährt es weiter, wenn man nicht schnell genug hochkommt Auf der Alster ist das nicht so wild, da kommt das Boot nicht weit. Aber auf der Ostsee mit einer Yacht, da lernt man, wie lebenswichtig eine Badeleiter ist. Das erklärt einem in der Segelschule keine Sau.


Ralf