Wirtschaftsinformatiker FA common mistakes
Wirtschaftsinformatiker FA · Understand the traps and how to avoid them.
In Szenarioaufgaben wird sofort eine Lösung (z. B. ein konkretes System oder Tool) präsentiert, ohne vorher Geschäftsnutzen, betroffene Stakeholder und Ist-Prozess zu klären; die Antwort beginnt mit 'Wir führen SAP X ein'.
Die Prüfung ist auf die Vermittlerrolle zwischen Fachbereich und IT ausgelegt. Kandidaten mit technischem Hintergrund springen zur Technik, weil ihnen das vertraut ist, und übersehen, dass die Bewertung die Herleitung der Anforderung aus dem Geschäftsproblem verlangt.
What to do instead
Vor jeder Lösungsnennung drei Sätze einbauen: Welches Geschäftsziel ist betroffen, wer sind die Stakeholder, wie sieht der Ist-Prozess aus. Erst danach Optionen mit Nutzen und Aufwand abwägen. Eine kurze Vorlage (Ziel – Stakeholder – Ist – Soll – Maßnahme) im Antwortmuster einüben.
Fachliche Anforderungen werden mit technischen oder nicht prüfbaren Formulierungen vermischt, etwa 'Das System soll benutzerfreundlich und performant sein', statt messbarer Kriterien wie Antwortzeit unter 2 Sekunden bei 500 parallelen Nutzern.
Im Berufsalltag werden Anforderungen oft mündlich und unpräzise weitergegeben. Kandidaten übernehmen diese Sprache, weil sie plausibel klingt, und kennen die Prüfkriterien guter Anforderungen (eindeutig, vollständig, testbar, priorisiert) nicht sicher genug, um sie unter Zeitdruck anzuwenden.
What to do instead
Jede Anforderung gegen ein Prüfschema testen: eindeutig, vollständig, widerspruchsfrei, testbar, priorisiert, mit Akzeptanzkriterium. Nicht-funktionale Anforderungen immer mit Messgröße und Bedingung schreiben. Ein Übungsset mit zehn schlechten Anforderungen so umformulieren, dass jede ein messbares Akzeptanzkriterium erhält.
Bei der Prozessmodellierung werden Ist- und Soll-Zustand in einem Diagramm vermischt, oder es wird ein reines Ablaufdiagramm gezeichnet, ohne Verantwortlichkeiten, Schnittstellen und Entscheidungspunkte kenntlich zu machen.
Die Notation wird oft nur als Zeichenübung gelernt. Kandidaten verwechseln das Ziel der Modellierung (Kommunikation und Analyse) mit dem Ziel, ein vollständiges Bild zu zeichnen, und packen deshalb alles in ein Modell.
What to do instead
Immer getrennt modellieren: erst Ist, dann Soll, dann die Differenz als Maßnahmenliste. Pro Modell eine Frage beantworten (Wer macht was, wann, mit welchem Ergebnis). Schwimmbahnen für Rollen, explizite Verzweigungen für Entscheidungen und benannte Schnittstellen zu Nachbarsystemen einbauen. Notation (z. B. BPMN) nur so tief verwenden, wie die Fragestellung es verlangt.
Im Projektmanagement werden Phasen, Vorgehensmodelle und Rollen durcheinandergebracht, etwa Wasserfall als Methode neben Scrum als Phase genannt oder der Product Owner als disziplinarischer Vorgesetzter des Teams beschrieben.
Die Begriffe stammen aus unterschiedlichen Denkschulen und werden in Schulungen oft nebeneinander vorgestellt, ohne die Ebenen zu trennen (Vorgehensmodell, Methode, Rolle, Artefakt). Unter Prüfungsdruck greifen Kandidaten auf die zuletzt gehörte Zuordnung zurück.
What to do instead
Eine eigene Zuordnungstabelle anlegen: Vorgehensmodell (klassisch, agil, hybrid) – Methode – Rolle – Artefakt – typisches Risiko. Jede Rolle mit Entscheidungsbefugnis und Verantwortung beschreiben, nicht mit Hierarchie. An einem Beispielprojekt durchspielen, wer welche Entscheidung trifft.
Auf Führungsfragen wird mit reiner Sachargumentation geantwortet: Der Konflikt im Projektteam wird durch eine bessere Aufgabenliste gelöst, ohne Ansprechen der Beteiligten, ohne Eskalationsstufe und ohne Reflexion des eigenen Führungsverhaltens.
Viele Kandidaten sind fachlich stark und haben wenig Führungserfahrung. Sie behandeln Führungsfragen wie technische Probleme, weil sie dort sicher sind, und unterschätzen, dass die Prüfung situatives Führungsverhalten und Kommunikation bewertet.
What to do instead
Bei Führungsfällen strukturiert vorgehen: Situation und Beteiligte benennen, Interessen und Widerstände herausarbeiten, Gesprächs- und Eskalationsweg festlegen, Ergebnis und Lernpunkt reflektieren. Zwei oder drei Führungsstile (situativ, transformativ, kooperativ) mit je einem passenden Anwendungsfall parat haben.
In Architekturaufgaben wird eine Technologie als Selbstverständlichkeit gesetzt (Microservices, Cloud, Event-Bus), ohne Qualitätsziele, Randbedingungen und Alternativen zu nennen; die Begründung lautet 'weil es modern und skalierbar ist'.
Trends aus dem Berufsalltag und aus Fachmedien prägen die Antwort. Kandidaten verwechseln Aktualität mit Angemessenheit und versäumen, die Architekturentscheidung an nicht-funktionalen Anforderungen zu verankern.
What to do instead
Jede Architekturoption gegen explizite Qualitätsmerkmale stellen (Skalierbarkeit, Verfügbarkeit, Wartbarkeit, Betriebsaufwand, Kosten). Mindestens eine Alternative mit Trade-off nennen und die Entscheidung mit Randbedingungen begründen. Eine Architecture Decision Record Skizze (Kontext, Entscheidung, Alternativen, Konsequenzen) als Antwortmuster üben.
Datenmodelle werden ohne Normalisierung und ohne Bezug zu den Geschäftsregeln entworfen; Kardinalitäten werden geraten, Redundanzen bleiben stehen, und die Abfrage- oder Berichtsanforderung wird nicht geprüft.
Kandidaten konzentrieren sich auf Entitäten und Attribute und behandeln Beziehungen und Integritätsregeln als Nebensache. Ohne Gegenprüfung an einem konkreten Auswertungsfall bleiben Fehler im Modell unentdeckt.
What to do instead
Nach dem Entwurf drei Prüfungen durchführen: Normalformen bis zur dritten Normalform begründen, Kardinalitäten anhand von Geschäftsregeln in beide Richtungen durchspielen, und eine typische Berichtsabfrage auf dem Modell gedanklich ausführen. Jede Redundanz entweder entfernen oder bewusst mit Begründung belassen.
Sicherheitsfragen werden nur mit Technik beantwortet (Firewall, Verschlüsselung), während Schutzbedarf, Bedrohungsanalyse, organisatorische Maßnahmen und rechtliche Pflichten zur Meldung von Vorfällen fehlen.
Sicherheit wird als Produkt oder Werkzeug wahrgenommen, nicht als fortlaufender Prozess. Kandidaten kennen Technikbausteine, aber selten das Zusammenspiel von Schutzbedarfsfeststellung, Maßnahmenauswahl und Notfallplanung.
What to do instead
Antworten entlang eines Vorgehens aufbauen: Schutzobjekt und Schutzbedarf bestimmen, Bedrohungen und Verwundbarkeiten benennen, technische und organisatorische Maßnahmen kombinieren, Restrisiko und Verantwortlichkeit festhalten, Melde- und Notfallprozess beschreiben. Immer mindestens eine organisatorische und eine technische Maßnahme nennen.
Wirtschaftlichkeitsbetrachtungen bleiben bei der Anschaffungssumme stehen; Betriebs-, Änderungs- und Ausfallkosten sowie Nutzen und Amortisationszeit fehlen, und Annahmen werden nicht offengelegt.
Kandidaten scheuen Rechnungen mit unsicheren Annahmen und liefern lieber eine qualitative Aussage. Dadurch bleibt die Antwort an der Oberfläche, obwohl die Prüfung eine begründete Entscheidungsgrundlage für das Management erwartet.
What to do instead
Für jede Investitionsfrage eine einfache Total-Cost-of-Ownership Skizze über mehrere Jahre erstellen: einmalige und laufende Kosten, qualitativer und quantifizierter Nutzen, Amortisation, Sensitivität bei abweichenden Annahmen. Annahmen explizit auflisten und als Annahmen kennzeichnen, nicht als Fakten.
Aufgaben werden nicht vollständig beantwortet: Es wird nur der erste Teil bearbeitet, oder eine Antwort wird ohne Bezug zur konkreten Fragestellung auswendig heruntergeschrieben, sodass geforderte Begründung, Abwägung oder Empfehlung fehlen.
Zeitdruck und die Angewohnheit, bekannte Wissensblöcke abzuspulen, führen dazu, dass Operatoren wie 'begründen', 'bewerten' oder 'empfehlen' übersehen werden. Kandidaten erkennen nicht, dass die Bewertung an der Erfüllung des Operators hängt.
What to do instead
Vor dem Schreiben die Operatoren der Aufgabe markieren und in Teilschritte zerlegen (nennen, erklären, abwägen, empfehlen). Nach dem Schreiben prüfen, ob jeder Operator mit einem eigenen Satz bedient ist, und die Empfehlung mit einem Satz Begründung abschließen. Zeitpuffer für diese Kontrolle einplanen.