Ausbildung als Fachinformatiker Richtung Anwendungsentwicklung?
Hallo zusammen, ich habe eine Frage: Als Fachinformatiker Anwendungsentwicklung, macht man da auch etwas anderes, als programmieren? Also ich hab mal ein Praktikum gemacht, da hab ich auch PC innerhalb der Firma getauscht und eingerichtet, aber da gab es auch was, was sich Servicedesk nennt. Da hat man mit anderen aus der Firma telefoniert, wenn Probleme aufgetreten sind und diese dann auch versucht zu lösen. Also macht man sowas auch als Anwendungsentwicklung, oder ist das dann Systemintegration?
Danke für eure Hilfe :)
8 Antworten
Bitte lies auf jeden Fall den seit August 2020 gültigen neuen Ausbildungsplan für Fachinformatiker (aller Richtungen):
Ausbildungsplan für Fachinformatiker ab August 2020
Insbesondere der §5 sagt, wie die Einsatzgebiete der unterschiedlichen Fachinformatiker sich unterscheiden.
In der Regel gibt es 2 Wege, die des Anwendungsentwickler und die des Systemintegrator.
Die Ausbildung hat viele Grundsätzlich gleiche Themen rund um die Informationstechnik, jedoch geht es bei den Integratoren mehr um Infrastruktur Betriebssysteme oder eben auch Service Desk, während der Anwendungsentwickler, wie die Bezeichnung es bereits beschreibt, mehr in Richtung des Programmierens ausgelegt ist.
Eine Firma wird in Richtung ihrer spezifischen Bedarfe ausbilden, also würde ich dazu raten mir im klaren zu sein was ich anfange. Wenn deine Neigungen eher bei der Systemintegration liegen, dann solltest du eben nicht eine Ausbildung zum Anwendungsentwickler beginnen.
OK, ich werde nochmal in mich gehen, und nochmal genau nachdenken. Auf jeden Fall danke für deine Antwort
Also als ich mal bei einem Vorstellungsgespräch war, hab ich die Frage, was der Unterschied zwischen den beiden Berufen ist, verhauen. Dann hat mir mein Gegenüber erklärt, dass alle Kompetenzen die man als Fachinformatiker Richtung Systemintegration hat auch als Fachinformatiker für Anwendungsentwicklung haben muss und die Programmierung quasi obendrauf noch dazu kommt.
Beide haben das gleiche Grundgerüst und erstmal das gleiche Verständnis von Software und Hardware. In der Schule wird allerdings der Fokus vorallem im 3. Jahr auf die Hard- oder Software festgelegt.
Support hat nichts mit FISI oder FIAE zu tun. Das können beide machen. Der FIAE kann genau so gut Kundenkontakt haben, wenn in einem Systemhaus kundenspezifisch programmiert wird.
Nun erst einmal ist der FIAE eine Ausbildung, wo gewisse Fähigkeiten vermittelt werden. Welche davon in den jeweiligen Unternehmen benötigt werden und welche da noch zukommen, dass ist erstmal offen.
Die Leute bauen ihr Unternehmen nicht auf indem sie sagen was kann ein FIAE, sondern indem sie fragen, was brauch der Kunde.
Es gibt sicher Unternehmen da arbeitest du intern an Tools für den Laden selbst, hast mit Kunden nix am Hut. Es gibt große Unternehmen, da bist du eher spezialisiert auf deinen Sektor und es gibt kleine Unternehmen, wo du eher Mädchen für alles bist, sprich ein Generalist, statt Spezialist.
Mal ein Beispiel wie es bei uns läuft:
Ich arbeite z.B. in einem KMU mit 15 Mitarbeitern. Wir stellen Software für den Logistikbereich her und zwar auf Auftragsbasis. Ich hab als reiner Entwickler angefangen, mittlerweile bin ich auch in der Projektleitung involviert.
Generell läuft es bei uns so, der Vertrieb macht via Planer, Partnern und Ausschreibungen Aufträge klar und arbeitet mit der Geschäftsführung ein Angebot aus. Was hoffentlich in einem Zuschlag endet.
Anschließend wird die Projektleitung gesetzt, was bei uns i.d.R. immer zwei Leute zusammen machen. Je nach Projektumfang treffen die sich über einen Zeitraum von 1-3 Monaten wöchentlich oder alle zwei Wochen beim Kunden oder bei uns in der Geschäftsstelle um das Pflichtenheft auszuarbeiten.
Nach jeden dieser Gespräche wird ein Protokoll erstellt, um die Ergebnisse zusammen zu fassen. Dort stehen dann Beschlüsse, Aufgaben und teilweise Termine drin und natürlich wer teilgenommen hat.
Am Tisch sitzen dann meist die Projektverantwortlichen vom Kunden, sprich der Leiter des Standorts, ggf. hier und da nen Schichtleiter, jemand der dort Schnittstellen umgesetzt hat, nen genereller ITler, für Infrastruktur fragen usw.
Letztlich geht man da dann die arbeitstechnischen Prozesse des Kunden durch. Auf unserer Seite probiert man natürlich möglichst viele Prozesse mit Sachen abzubilden, die wir schon bei uns im Standard haben, die wir schon können, die kein Aufwand bedeuten und fehlerfrei funktionieren. Am Ende kommen ein paar Lösungen von uns bei rum, ein paar Sonderlocken für den Kunden, hier und da trifft man sich in der Mitte, wirft was über den Haufen oder beschließt etwas mehrstufig zu machen und erstmal eine abgespeckte Lösung zu fahren.
Nebenbei laufen dann ggf. noch mal über Mail, Telefon vom Büro aus Fachgespräche mit Schnittstellenpartnern und man tauscht Dokumente aus.
Wenn am Ende alles steht und das Pflichtenheft unterschrieben ist, geht es an die Umsetzung.
Bedeutet bei uns Datenbankinstant in der Entwicklungsumgebung bei uns aufsetzen. Die Projektleitung schnürt Arbeitspakete und stimmt sich mit den Abteilungen ab, wer in welchen Projekt aktuell ist, wer dafür Zeit hat, wer wann im Urlaub ist etc. pp. und verteilt die Aufgaben zur eigentlichen Umsetzung.
Neben der Umsetzung laufen für fertige Sachen dann schon mal parallel mit Schnittstellenpartnern Tests. Sei es für die Host-Schnittstelle oder mit einem Fördertechnikanbieter, der oft Simulationen bereit hält oder gar eine Teststrecke bei sich hat, an die man via VPN rankommt.
In der Regel haben dann alle erstmal zutun, unser Projektteam, was meist so 4-6 Leute sind, wobei auch immer mal jemand anders kurz mit dabei ist, als auch Schnittstellenpartner und der Kunde selbst mit seiner IT. Natürlich gibt es auch intern mehrere Meetings zum Thema und man setzt sich häufiger zusammen. Ebenso gibt es Telkos, sei es mit dem Kunden oder mit Schnittstellenpartnern.
Die Projekte haben i.d.R. bei der Umsetzung meist so einen Umfang von einem halben Jahr, teilweise was länger. Wenn der Großteil steht wird die Anwendung meist auf ein Testsystem des Kunden oder gar schon den Produktivsystem übertragen, was aktuell eh noch nicht benutzt wird.
Viel dieser Arbeiten erfolgen vor allem wegen den Zahlungszielen und Rechnungsstellungen. Da gibt es eben dann X% der Zahlung bei Überstellung zum Kunden usw. Unabhängig wie sinnvoll oder nicht das zu dem Zeitpunkt ist.
Anschließend testet oft noch eine kleine Gruppe beim Kunden und schaut sich schon mal grob die Abläufe an
Wenn alles fertig ist geht es dann raus zum Inbetriebnahme Termin. Sprich wir fahren je nach Projektgröße mit 2-6 Leuten rum zum Kunden. Wie lange das dauert ist dann auch abhängig von der Projektgröße, mal sind es 1-2 Wochen, es waren aber auch schon 10 Wochen.
Dort wird dann erstmal mit der realen Anlage getestet, sprich die Fördertechnik Vorort, andere eingerichtete Geräte wie MDE Computer oder Drucker etc. pp. Da gibt es dann natürlich noch Abstimmung, Fehlersituationen und Korrekturen.
Wenn das alles stabil läuft gibt es die Schulungen mit den Keyusern. Sprich man spielt einen Testplan und die ganzen Abläufe mit den Leuten runter.
Leider ergibt sich da auch manchmal, dass der Kunde an den eigentlichen Gegebenheiten vorbei geplant hat. Da gibt es dann ggf. noch einmal Kommunikation und Änderungen in der letzten Minute als kostenpflichtige Mehrung oder es bleibt erstmal so und wird als kleines Erweiterungsprojekt anschließend terminiert.
Anschließend geht der Kunde in Betrieb und wir sind da noch 1-2 Wochen als Produktionsbegleitung. Bedeutet, wenn dann was brennt, müssen wir schnell ran. Es gibt Leute die sich eher bei den Nutzern aufhalten, für Fragen zur Verfügung stehen und Fehler aufnehmen und Leute die am Rechner sitzen und sich um diese Fehler kümmern.
Läuft alles geht es eben wieder zurück in unsere Geschäftsstelle, finale Dokumentation und Benutzeranleitung wird dann erstellt, weil sich eben wie oben erwähnt häufig noch Sachen ändern.
Wenn der Kunde Probleme hat, dann ruft er eben an. In der Regel mit einer relativ unspezifischen Aussage ala "hier steht alles", "die Palette fährt nicht", "ich finde den Auftrag nicht". Dann darf man ihn quasi alle Details aus der Nase saugen, um das Problem zu verstehen.
Sprich was steht? Welche Palette? Welcher Auftrag? Seit wann? Betrifft das nur diese Palette bzw. den Auftrag oder alle? Was probieren sie gerade zu machen? Kriegen sie eine Fehlermeldung? etc. pp.
Je nach Problem und Kunden schaltet man sich dann via Fernwartungssoftware wie TeamViewer direkt auf einen Client PC oder auf den Datenbankserver. Sprich wenn der Benutzer eine Buchung durchführen will und dann eine Exception kriegt, dann probiert man diesen Schritt dann auf den Datenbankserver.
Klappt es da, liegt es ggf. am Client und man probiert es, wenn der Fehler wieder auftritt auf diesen mit dem Kunden zusammen aus, sofern möglich. Nebenbei sichtet man eben noch die Logfiles und schaut ob man da auf die Schnelle was findet.
Dann gibt es andere Fehler bzgl. Prozesse auf dem Server. Aufträge bleiben in bestimmten Statis hängen, erscheinen gar nicht, die Fördertechnik steht etc. pp. Da baut man dann eben eine VPN Verbindung mit dem Datenbank Server auf und geht ggf. auch so drauf und schaltet sich mit seinen Entwicklungstools drauf.
Da sieht es meist so aus, dass man erstmal schaut laufen die Prozesse auf dem Server überhaupt? Gibt es ggf. eine Fehlermeldung auf dem Server? Gibt es Logfiles für die betroffenen Prozesse (sofern man gleich weiß wo in etwa der Fehler liegt)?
Anschließend geht es dann in die weitere Analyse. Man feuert ein paar SQL Abfragen ab und probiert den Fehler einzugrenzen. Im Idealfall lässt er sich dadurch festmachen und auch dort korrigieren. Wenn das nicht so gut läuft, dann muss man eben rein debuggen und schauen was das Programm an welcher Stelle macht um den Fehler zu finden.
Je nach Kunde und wie schlimm das Problem ist, ruft der dann natürlich im zwei Minuten Takt an, ggf. wandert das Telefon immer weiter eine Stufe hoch, so dass man erstmal den normalen Mitarbeiter hat, anschließend den Leitstand, den Schichtleiter und ggf. mal einen Bereichsleiter oder gar Geschäftsführer.
Da ändert sich der Ton dann natürlich. Die werfen dann gerne mit Wörtern wie Regressansprüchen (quasi Schadensersatz) usw. um sich. Und natürlich will jeder wissen, wann das Problem gelöst ist, obwohl man gar nicht weiß was das Problem ist. Und wesentlich schneller wird man auch nicht dadurch, dass man den Hörer in einer Hand hat und dem Kunden zuhört.
Ggf. hängt es auch noch mit einen Schnittstellenpartner zusammen, dann wird der auch noch mit ins Boot geholt. Kann also durchaus alles mal stressig werden. Und die Fehler sind vielfältig, mal ein Fehler bei uns, mal ein Bedienerfehler, mal ein Fehler beim Host-System, mal wurde was geändert vom Kunden, wo er dachte, dass hat nix damit zutun, mal ein Fehler bei Schnittstellenpartnern, mal ein Folgefehler eines anderen Fehlers etc. pp.
Letztlich ist das meist erstmal schauen, dass der Kunde weiterarbeiten kann, was ein natürlich erst einmal Ruhe gibt zur weiteren Analyse, um den Fehler zu finden, der für das Problem gesorgt hat. Manchmal kann man den Fehler natürlich gleich fixen.
Nebenbei haben die meisten Kunden auch einen Vertrag für eine Supporthotline. Sprich bei uns geht wöchentlich ein Handy rum zwischen den Kollegen. Wenn der Kunde außerhalb der Bürozeiten ein Problem hat, ruft er da an.
Da ist es dann eben gleiche Entstörung wie oben beschrieben. Im Idealfall kann derjenige das selbst, ansonsten muss er eben schauen, dass er einen Kollegen zur Unterstützung rankriegt, sprich da klingelt durchaus auch mal das Telefon nach Feierabend, im Urlaub etc. pp.
Trifft mich z.B. relativ häufig, weil ich bei fast allen Projekten involviert bin, die 24/7 arbeiten und das meist auch bei den eher komplizierten Sachen, wo etliche Schnittstellenpartner involviert sind usw. Da muss man eben drin sein, weil man im Zweifel auch selbstbewusst sagen können muss, Problem liegt nicht bei uns, wir können nix dafür, dass bei dir gerade 50 Leute die Hände in den Taschen haben, da musst du dich an Schnittstellenpartner Xy wenden, sofern wir nicht Vertragstechnisch so im Support sind, dass wir das alles koordinieren und da anrufen.
Neben der eigentlichen Projektumsetzung gibt es natürlich auch immer mal wieder kleinere Erweiterungen. Je nach Umfang laufen die einfach über den Betreuungsvertrag oder es wird dafür ein Angebot erstellt vom Vertrieb. Läuft dann aber alles meist über kürzere Wege.
Also ja, wir machen durchaus auch anderes als programmieren. Sei es Schulungen, sei es Absprachen im Team, mit den Kunden, Dokumentationen und Protokolle, Fehleranalysen, Mails, Telefonate oder die Inbetriebnahmen Vorort, MDE Geräte und co. einrichten oder auch mal bei der Inbetriebnahme eine Europalette rumschleppen oder an einen Regal hochklettern, wenn da was klemmt.
Wie gesagt, ist eben ein kleines Unternehmen. In großen Unternehmen sind viele dieser Sachen eben getrennt und es gibt extra Supportmitarbeiter die Fehler aufnehmen, Tickets erstellen, dort verschiedene Service Levels. DBAs die sich um die Datenbank kümmern, Frontendentwickler, Backendentwickler oder eben auch Systemintegratoren.
Aber ja grob kann man sagen der FIAE erstellt Anwendungen und kümmert sich um alles drum rum.
Der FISI installiert, konfiguriert und hat häufig auch mit der Hardware zutun. Aber auch als FISI kannst du Kundenkontakt haben, wenn man z.B. extern für die Verwaltung von Mailservern und was weiß ich zuständig ist. Ansonsten hast du ja eben deine Leute intern, Benutzer kann sich nicht anmelden, Passwort muss zurückgesetzt werden und eben auch die ganzen Serverdienste. Virtuelle Server aufsetzen und konfigurieren. Anwendungen installieren, Ports freigeben, Firewall konfigurieren etc. pp.
Aber letztlich, je nach Firmengröße, verschwimmen da die Grenzen eh. Ein FISI endet auch häufig mal schlicht als Admin oder tauscht worst case echt nur ein paar Mäuse und Tastaturen aus und haut mal gegen den Drucker, wenn was nicht funktioniert.
Bei uns ist der FISI z.B. eher auf Kundenseite. Der besorgt dort die Hardware oder installiert den virtuellen Server. Bindet den ggf. im Netz ein und konfiguriert die entsprechenden Adressbereiche. Installiert dort das Betriebssystem und einen Fernzugang, bis wir da loslegen können. Wenn was mit der Konfiguration nicht passt, rufen wir an und er darf ran.
Moin,
das ist je nach Unternehmen unterschiedlich.
Der Systemintegrator hat fast immer mit Kunden bzw Stakeholdern zu tun - wäre mir nicht bekannt, wo nicht.
Der Anwendungsentwickler bekommt auch seine Aufträge. Je nach Unternehmen kann da auch Support dazukommen - ich hatte mal in einem Krankenhaus hospitiert, da wurde neben der Programmierung auch der IT-SD (IT Servicedesk) gemacht.
Auch gerne für die eigenen Leute im Unternehmen.
Die große Unterscheidung der Berufe ist lediglich Soft- oder Hardwarelastig - auch im Punkto Support.
LG
Nun dann hast du zwar eine FISI Ausbildung, übst aber eine andere Tätigkeit aus. Natürlich hat der FISI als Mitarbeiter am McDonald Schalter mit Kunden zutun. Das hat dann aber nix mit dem FISI zutun.
Wenn du hauptsächlich programmierst, dann bist du eben ein Softwareentwickler, unabhängig davon was du gelernt hast.
Wie apachy schon sagt. Du führst dann nicht die Aufgaben eines FISIs aus.
Ich selbst war sowohl FISI als auch mittlerweile Softwareentwickler.
Das weiß ich selbst, Problem ist nur, dass meine Stelle sich mehr die Programmierung fokussiert als auf andere Dinge. Ein weiteres Problem ergibt sich daraus auch, da ich Programmieren sehr einseitig und unspannend finde. Leider lässt sich das nicht ändern.
Ja ich schaue mich schon seit einer Weile nach anderen Alternativen um. ^^.
Mein Bereich ist eher die Netzwerktechnik. Natürlich ist auch hier Programmierung notwendig, aber nicht jeden Tag wie als FIAE.
In meinem Betrieb. Selbst als Systemintegrator besteht meine Aufgabe zu 95% aus Front- und Backend-Programmierung.