Interviewfragen für IT-Berater, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Beantworte jede Frage mit den Schritten, die du gehen würdest, und ergänze dann ein eigenes Projekt: die Plattform, die Branche des Kunden, deinen Teil und wie es ausging. Interviewer für Beratungsrollen hören auf den Moment, in dem du mit dem Kunden eine Entscheidung getroffen hast, also nenne ihn.

Was ein IT-Berater können muss

• Analyse: Anforderungsworkshops, Prozesslandkarten und eine Fit-Gap-Analyse, die der Kunde freigibt.
• Eine Plattform in der Tiefe: etwa SAPIn 6 % der Anzeigen für IT-Berater gefragt (Stand 05.11.2026).Wissen, wie ein Modul die Prozesse eines Kunden abbildet, wo Customizing endet und Entwicklung beginnt und was ein Release ändert., SalesforceIn 4 % der Anzeigen für IT-Berater gefragt (Stand 05.11.2026).Objekte, Flows, Profile und die Grenzen der Standardfunktionen, bevor jemand nach Eigenentwicklung fragt., ServiceNow oder Microsoft Dynamics, dazu ein Überblick über die anderen und die Clouds, auf denen sie laufen.
• Umsetzung: ProjektmanagementIn 28 % der Anzeigen für IT-Berater gefragt (Stand 05.11.2026).Einen Rollout mit Meilensteinen, Verantwortlichen und Risiken planen und den Lenkungsausschuss des Kunden jede Woche informieren., agilesIn 16 % der Anzeigen für IT-Berater gefragt (Stand 05.11.2026).Ein Kundenprojekt in kurzen Iterationen führen, mit einem Backlog, das dem Kunden gehört, und Demos, an denen er teilnimmt. Arbeiten mit einem Backlog in Jira, Schätzungen, Change Requests und Statusberichte.
• Daten und Tests: Datenmigration, SQLIn 6 % der Anzeigen für IT-Berater gefragt (Stand 05.11.2026).Die Daten des Kunden selbst abfragen, um eine Migration zu prüfen, Summen abzugleichen und eine Frage im Workshop zu beantworten., um sie zu prüfen, Testpläne, Cutover und die Wochen nach dem Go-live.
• Menschen: Stakeholder-ManagementIn 17 % der Anzeigen für IT-Berater gefragt (Stand 05.11.2026).Herausfinden, wer entscheidet, wer nutzt und wer blockiert, und jeden in seinen eigenen Worten informieren., PräsentierenIn 4 % der Anzeigen für IT-Berater gefragt (Stand 05.11.2026).Einem Lenkungsausschuss in zehn Minuten eine Empfehlung vorstellen, mit den Optionen und den Risiken. vor einem Lenkungsausschuss und Anwender so schulen, dass sie das System selbst betreiben können.

Anforderungen, Workshops und Stakeholder

Wie leitest du einen Anforderungsworkshop mit einem Kunden, der wenig Zeit hat und skeptisch ist?

Worauf sie achten: Vorbereitung, Führung im Raum und ein Ergebnis auf Papier.

Kurze Antwort: „Ich bereite aus dem, was ich schon habe, einen Entwurf des Prozesses vor, damit die Leute etwas korrigieren, statt bei null anzufangen. Ich lade die Menschen ein, die die Arbeit machen, und eine Person, die entscheidet, halte mich an eine klare Agenda, parke Nebenthemen auf einer sichtbaren Liste und schließe mit dem, was wir vereinbart haben und wer was liefert. Das Protokoll geht am selben Tag zur kurzen Bestätigung hinaus.“

Die ausführliche Antwort: Ein skeptischer Kunde hat meist schon ein Projekt erlebt, das viel von seiner Zeit genommen und wenig zurückgegeben hat. Zeig früh, dass du zugehört hast: Übernimm seine Worte in die Prozesslandkarte, behebe ein kleines Ärgernis, das er nennt, und halte den Workshop kurz. Trenne, was das System können muss, davon, wie es heute aussieht, denn Anwender beschreiben ihre Umwege oft als Anforderungen.

Schwache Antwort: „Ich schicke einen Fragebogen und warte auf die Antworten.“ Nachfrage: „Die Hälfte der eingeladenen Anwender ist nicht gekommen.“ Sag, wie du ihren Beitrag bekommst, bevor das Design feststeht.

Was ist eine Fit-Gap-Analyse, und was machst du mit den Lücken?

Worauf sie achten: dass du den Standard der Plattform kennst und ihn verteidigst, bevor gebaut wird.

Kurze Antwort: „Eine Fit-Gap-Analyse vergleicht jede Anforderung mit dem, was die Plattform im Standard kann. Was passt, wird eingerichtet. Für jede Lücke gibt es vier Antworten: den Prozess an den Standard anpassen, eine Einstellung oder ein Add-on nutzen, eine Erweiterung bauen oder einen manuellen Schritt akzeptieren. Ich schreibe zu jeder die Kosten und das Risiko auf, und der Kunde entscheidet.“

Die ausführliche Antwort: Jede Erweiterung muss mit jedem Release der Plattform getestet und gepflegt werden, deshalb ist die billigste Antwort am ersten Tag über fünf Jahre oft die teuerste. Eine gute Fit-Gap-Liste sagt, welche Lücken gesetzliche oder vertragliche Pflichten sind und welche Gewohnheiten. Kunden nehmen den Standard leichter an, wenn sie ihn in einer Demo mit ihren eigenen Daten sehen.

Schwache Antwort: „Wir bauen alles, was die Anwender wünschen.“ Nachfrage: „Der Vertriebsleiter besteht auf seinem alten Berichtslayout.“ Erklär, wie du damit umgehst, ohne eine Eigenentwicklung zu bauen.

Wie gehst du mit Stakeholdern um, die von demselben System Verschiedenes wollen?

Worauf sie achten: dass du Konflikte früh sichtbar machst und die richtige Person entscheiden lässt.

Kurze Antwort: „Ich mache den Konflikt in einfachen Worten sichtbar: was die Finanzabteilung will, was der Vertrieb will und was jede Option an Zeit und Risiko kostet. Ich ergreife keine Partei. Ich bringe ihn mit einer Empfehlung zu der Person, der die Entscheidung gehört, meist dem Sponsor oder dem Lenkungsausschuss, und halte das Ergebnis schriftlich fest.“

Die ausführliche Antwort: Eine Stakeholder-Landkarte hilft: wer entscheidet, wer das System jeden Tag nutzt, wer informiert werden muss und wer das Projekt stoppen kann. Sprich mit jeder Gruppe in ihren eigenen Worten. Viele Konflikte verschwinden, wenn beide Seiten dieselben Daten sehen; der Rest braucht eine Entscheidung, und ein Projekt, das ohne Entscheidung auf Einigkeit wartet, gerät in Verzug.

Schwache Antwort: „Ich folge dem, der am höchsten in der Hierarchie steht.“ Nachfrage: „Der Sponsor ist drei Wochen im Urlaub.“ Sag, wie du das Projekt am Laufen hältst, ohne deine Befugnisse zu überschreiten.

Umfang, Schätzungen, Verträge und Angebote

Wie schätzt du eine Arbeit, die du noch nie gemacht hast?

Worauf sie achten: Methode, Ehrlichkeit über die Unsicherheit und eine Zahl, die du verteidigen kannst.

Kurze Antwort: „Ich zerlege sie in Teile, die ich mit bekannter Arbeit vergleichen kann, schätze jeden Teil mit einem niedrigen und einem hohen Wert und ergänze die Teile, die man leicht vergisst: Tests, Daten, Schulung, Meetings und Korrekturen nach dem Go-live. Ich bitte eine Kollegin oder einen Kollegen, der Ähnliches gemacht hat, um eine Prüfung, und schreibe die Annahmen auf, auf denen die Schätzung beruht.“

Die ausführliche Antwort: Eine Schätzung ohne ihre Annahmen wird zum Versprechen. Nenne die offenen Fragen, gib am Anfang eine Spanne statt einer einzelnen Zahl und grenze sie ein, sobald die Analyse die Fragen beantwortet. Vergleiche in jedem Projekt deine eigenen Schätzungen mit der tatsächlichen Zeit; diese Historie ist das beste Werkzeug, das ein Berater hat.

Schwache Antwort: „Ich nehme, was das Budget des Kunden hergibt.“ Nachfrage: „Der Kunde sagt, deine Schätzung sei doppelt so hoch wie das Angebot eines anderen Beratungshauses.“ Erklär, wie du den Umfang vergleichst statt der Summen.

Was ändert sich zwischen einem Festpreisprojekt und einem Projekt nach Time and Materials?

Worauf sie achten: dass du verstehst, wo das Risiko liegt und wie es dein Verhalten ändert.

Kurze Antwort: „Bei einem Festpreisprojekt trägt das Beratungshaus das Risiko, das Budget zu überschreiten, deshalb muss der Umfang eng beschrieben sein, und jede Änderung läuft über einen Change Request. Bei Time and Materials, also nach Aufwand, bezahlt der Kunde die geleisteten Stunden und trägt mehr vom Risiko, deshalb braucht er häufige Berichte über Fortschritt und Ausgaben.“

Die ausführliche Antwort: Viele Verträge mischen beides: die Analyse nach Aufwand, dann ein Festpreis für die Umsetzung, sobald der Umfang klar ist. So oder so ist die Leistungsbeschreibung (Statement of Work), das Dokument, das sagt, was bis wann und unter welchen Annahmen geliefert wird, das, worauf beide Seiten zurückkommen, wenn sie uneins sind.

Schwache Antwort: „Für meine Arbeit macht das keinen Unterschied.“ Nachfrage: „Du bist in der Mitte eines Festpreisprojekts, und der Aufwand liegt über dem Plan.“ Sag, was du ansprichst und bei wem.

Zwei Wochen vor dem Go-live will ein Kunde etwas außerhalb des Umfangs. Wie gehst du mit dem Change Request um?

Worauf sie achten: ruhige Kontrolle über den Umfang, ohne die Beziehung zu beschädigen.

Kurze Antwort: „Ich bedanke mich, schreibe den Wunsch auf und arbeite dann seine Wirkung auf den Termin, die Kosten und das Risiko für den Go-live heraus. Ich biete Optionen an: es nach dem Go-live umsetzen, es gegen etwas gleich Großes tauschen oder den Termin verschieben. Der Kunde entscheidet schriftlich über den Change Request.“

Die ausführliche Antwort: An späten Änderungen scheitern Projekte, deshalb sollte der Änderungsprozess am Anfang vereinbart und auch für kleine Änderungen genutzt werden, damit er normal ist und keine Konfrontation. Sag Ja zum Bedarf und sei klar über den Preis, es jetzt zu tun. Eine kurze Liste mit Punkten für die Zeit nach dem Go-live zeigt dem Kunden, dass sein Wunsch nicht vergessen ist.

Schwache Antwort: „Ich nehme es einfach mit auf; der Kunde ist König.“ Nachfrage: „Der Kunde sagt, das sei keine Änderung, es sei immer so gemeint gewesen.“ Erklär, wie die freigegebenen Anforderungen das klären.

Wie schreibst du ein Angebot oder eine Leistungsbeschreibung, die ein Kunde unterschreiben kann?

Worauf sie achten: dass du aus einem Gespräch eine klare, sichere Zusage machen kannst.

Kurze Antwort: „Ich gebe das Ziel des Kunden in seinen Worten wieder, beschreibe dann das Vorgehen in Phasen mit dem, was jede liefert, die Rollen auf beiden Seiten, den Zeitplan, die Annahmen und was nicht zum Umfang gehört. Der Preis folgt daraus. Bevor es hinausgeht, liest jemand, der nicht in den Meetings war, ob es sich missverstehen lässt.“

Die ausführliche Antwort: Die Pflichten des Kunden zählen so viel wie deine: Zugänge, Daten, Leute für Workshops und Tests, Entscheidungen in einer festen Frist. Die meisten Streitfälle kommen von einer fehlenden Annahme, also schreib sie auf. Ein Angebot verkauft auch das Team, also nenne, wer die Arbeit machen wird und was diese Leute vorher gemacht haben.

Schwache Antwort: „Das schreibt der Vertrieb; ich liefere nur.“ Nachfrage: „Der Kunde will den Preis vor der Analyse.“ Sprich über eine Spanne, eine bezahlte Analysephase oder eine erste Phase zum Festpreis.

Daten, Integration, Tests und Go-live

Wie planst du eine Datenmigration von einem alten System auf eine neue Plattform?

Worauf sie achten: dass du Daten als eigenen Workstream behandelst, mit Verantwortlichen und Prüfungen.

Kurze Antwort: „Ich vereinbare mit dem Kunden, welche Daten umziehen, aus welchen Systemen und wie weit zurück, und wem jedes Objekt gehört. Wir bereinigen die Daten zuerst im alten System, ordnen die Felder zu und fahren mehrere Probeladungen mit Prüfungen von Anzahlen und Summen. Der Fachbereich nimmt jede Probeladung ab, damit die letzte Ladung eine Wiederholung ist und kein erster Versuch.“

Die ausführliche Antwort: Offene Posten wie unbezahlte Rechnungen oder offene Aufträge brauchen die meiste Sorgfalt, weil das Geschäft am ersten Tag davon lebt. Gleiche mit SQLIn 6 % der Anzeigen für IT-Berater gefragt (Stand 05.11.2026).Die Daten des Kunden selbst abfragen, um eine Migration zu prüfen, Summen abzugleichen und eine Frage im Workshop zu beantworten. oder den eigenen Werkzeugen der Plattform ab, nicht durch einen Blick auf ein paar Datensätze. Plane, was danach mit dem alten System geschieht: nur noch lesbar, archiviert oder abgeschaltet.

Schwache Antwort: „Der Kunde exportiert eine Datei, und wir importieren sie.“ Nachfrage: „Die Probeladung zeigt Kunden mit drei verschiedenen Adressen.“ Sag, wer entscheidet, welche stimmt.

Wie planst du die Tests, und wer sollte was testen?

Worauf sie achten: ein Testvorgehen, das zum Risiko passt, mit den Anwendern im Boot.

Kurze Antwort: „Zuerst testet das Projektteam jede eingerichtete Funktion und jede Schnittstelle. Dann laufen End-to-End-Tests über ganze Prozesse, etwa Order to Cash, mit realistischen Daten. Zum Schluss testen die Anwender ihre tägliche Arbeit im Abnahmetest (User Acceptance Test) und geben sie ab. Fehler kommen in eine einzige Liste, etwa in Jira, mit einer Priorität, die mit dem Kunden vereinbart ist.“

Die ausführliche Antwort: Schreib die Testfälle aus den Anforderungen, damit jede Anforderung einmal getestet wird. Anwender finden andere Probleme als Berater, also plane ihre Zeit früh ein; sie haben ihr Tagesgeschäft. Vereinbare vor dem Teststart, was als bereit für den Go-live gilt, zum Beispiel keine offenen Fehler der höchsten Priorität.

Schwache Antwort: „Wir testen am Ende, wenn Zeit bleibt.“ Nachfrage: „Die Anwender melden ständig Change Requests als Fehler.“ Erklär, wie du sie sortierst.

Führ uns durch ein Cutover-Wochenende und die ersten Wochen nach dem Go-live.

Worauf sie achten: Planung auf die Stunde, ein Weg zurück und Unterstützung danach.

Kurze Antwort: „Der Cutover ist der Wechsel vom alten auf das neue System. Wir folgen einem Plan mit jedem Schritt, seinem Verantwortlichen und seiner Uhrzeit, mindestens einmal geprobt: das alte System einfrieren, letzte Datenladung, Prüfungen, Abnahme, Freigabe für die Anwender. An festen Punkten fällt eine Go/No-Go-Entscheidung, mit einem Plan für den Rückfall. Nach dem Go-live behebt die Hypercare, eine Zeit mit zusätzlicher Unterstützung, Probleme schnell.“

Die ausführliche Antwort: Die Hypercare dauert meist ein paar Wochen: tägliche Calls, ein klarer Weg für Probleme, Berater nah bei den Anwendern und eine Liste offener Punkte mit Verantwortlichen. Sie endet mit einer vereinbarten Übergabe an den eigenen Support des Kunden. Der erste Monatsabschluss oder der erste große Auftragstag nach dem Go-live ist die echte Probe, also plane, dabei zu sein.

Schwache Antwort: „Wir schalten Montagmorgen um und schauen mal.“ Nachfrage: „Um zwei Uhr nachts schlagen die Datenprüfungen fehl.“ Sag, wer entscheidet und auf welcher Grundlage.

Wie bindest du die neue Plattform an ein System an, das der Kunde nicht ändern kann?

Worauf sie achten: praktisches Denken in Schnittstellen und klare Verantwortung.

Kurze Antwort: „Zuerst finde ich heraus, was das alte System bieten kann: Dateien, eine Sicht auf die Datenbank, eine Schnittstelle oder nichts als eine Bildschirmmaske. Dann vereinbaren wir die Daten, die Richtung, den Takt und wer die Schnittstelle überwacht, wenn sie ausfällt. Wenn sich das alte System nicht ändern lässt, passiert die Arbeit in der neuen Plattform oder in einer Zwischenschicht, die der Kunde schon nutzt.“

Die ausführliche Antwort: Jede Schnittstelle braucht einen Verantwortlichen auf jeder Seite, eine Fehlerbehandlung, einen Weg, Daten erneut zu senden, und ein Monitoring, das jemand tatsächlich liest. Teste sie mit echten Mengen. Kläre früh mit der IT des Kunden, ob Echtzeit wirklich nötig ist, denn eine nächtliche Datei ist einfacher zu betreiben.

Schwache Antwort: „Die Schnittstellen regeln die Entwickler.“ Nachfrage: „Aufträge kommen manchmal doppelt an.“ Sprich darüber, wie die Schnittstelle sicher wiederholbar wird.

Wie stellst du sicher, dass die Anwender geschult sind und der Kunde das System nach der Übergabe betreiben kann?

Worauf sie achten: dass du eine funktionierende Organisation hinterlässt, nicht nur ein funktionierendes System.

Kurze Antwort: „Ich schule zuerst die Key User, in ihren eigenen Prozessen und Daten, und sie helfen, die anderen zu schulen. Die Anleitungen sind kurz und nach Aufgaben aufgebaut. Vor der Übergabe nimmt das Supportteam des Kunden Anrufe an, während wir daneben sitzen, und wir vereinbaren eine Liste offener Punkte mit Verantwortlichen und Terminen.“

Die ausführliche Antwort: Ein System, das der Kunde nicht betreiben kann, kommt als unbezahlter Support zurück. Plane den Wissenstransfer von Anfang an: Die Leute des Kunden arbeiten beim Customizing mit, schreiben Teile der Dokumentation und fahren selbst einen Testzyklus. Miss es, zum Beispiel am Anteil der Tickets, die der Kunde in der letzten Woche der Hypercare allein löst.

Schwache Antwort: „Wir schicken am Ende die Dokumentation.“ Nachfrage: „Der Key User des Kunden kündigt eine Woche vor dem Go-live.“ Sag, was du tust.

Cloud und Sicherheit

Ein Kunde will ein System in die Cloud verlegen. Welche Fragen stellst du zuerst?

Worauf sie achten: dass du beim geschäftlichen Grund anfängst, nicht bei einem Anbieter.

Kurze Antwort: „Warum: Kosten, Tempo, ein Rechenzentrum am Ende seiner Lebensdauer oder eine neue Fähigkeit. Welche Systeme und Daten, wie sie voneinander abhängen und welche Ausfallzeit das Geschäft hinnimmt. Welche Cloud der Kunde schon nutzt, AWS, Azure oder Google Cloud, und welche Skills sein Team hat. Dann, welche Regeln für die Daten gelten und wer das System danach betreibt.“

Die ausführliche Antwort: Ein System unverändert umzuziehen geht schnell, kann im Betrieb aber mehr kosten; es umzubauen dauert länger und spart später. Die eigenen Werkzeuge des Anbieters und die Lizenzen des Kunden prägen den Plan. Hol Cloud- und Sicherheitsspezialisten früh dazu und lass den Verantwortlichen im Fachbereich mitentscheiden, denn die Cloud-Rechnung landet in seinem Budget.

Schwache Antwort: „Alles geht in die Cloud; das ist billiger.“ Nachfrage: „Die Finanzabteilung fragt, warum die monatliche Rechnung höher ist als beim alten Rechenzentrum.“ Erklär, worauf du schaust.

Wie bringst du Sicherheit und Datenschutz von Anfang an in ein Projekt?

Worauf sie achten: dass Sicherheit Teil des Designs ist und keine Schranke am Ende.

Kurze Antwort: „Ich lade die Sicherheits- und Datenschutzleute des Kunden zum ersten Design-Workshop ein. Wir vereinbaren Rollen und Zugriffe, welche personenbezogenen Daten das System hält und warum, wo sie gespeichert werden und was protokolliert wird. Das werden Anforderungen wie alle anderen, und sie werden vor dem Go-live getestet.“

Die ausführliche Antwort: Bei Rollen und Zugriffen beginnen die meisten Probleme: zu viele Leute mit zu viel Zugriff, weil es im Test schneller ging. Folge den eigenen Richtlinien des Kunden und in der EU den Regeln der DSGVO (englisch GDPR) zu personenbezogenen Daten; nenne die offenen Fragen, statt zu raten. Das ist eine Zusammenfassung, keine Rechtsberatung.

Schwache Antwort: „Sicherheit ist Sache der IT-Abteilung des Kunden.“ Nachfrage: „Die Tester brauchen echte Kundendaten.“ Sprich über Maskierung und Testdaten.

Berichte, Auslastung und die Senior-Stufen

Wie berichtest du den Status eines Projekts, das schlecht läuft?

Worauf sie achten: Ehrlichkeit, frühe Warnung und ein Plan.

Kurze Antwort: „Ich sage es früh und klar: was spät ist, warum, was es für den Termin und die Kosten bedeutet und was ich vorschlage. Ein Statusbericht, der bis zur letzten Woche grün zeigt, zerstört Vertrauen. Ich bringe dem Lenkungsausschuss Optionen und eine Empfehlung, nicht nur das Problem.“

Die ausführliche Antwort: Halte den Statusbericht kurz und jede Woche gleich aufgebaut: Fortschritt gegen den Plan, die wichtigsten Risiken mit Verantwortlichen, nötige Entscheidungen und das verbrauchte Budget. Nenne Risiken, solange sie noch Risiken sind. Im Beratungshaus sagst du es deiner Führungskraft, bevor der Kunde es hört, damit die Firma helfen kann.

Schwache Antwort: „Ich lasse ihn auf Gelb und hoffe, dass wir aufholen.“ Nachfrage: „Der Projektleiter des Kunden bittet dich, den Bericht für den Vorstand grün zu lassen.“ Sag, was du tust.

Wie hältst du als Senior-IT-Berater, Principal IT Consultant oder Manager in der IT-Beratung die Balance zwischen Auslastung, Kunde und Team?

Worauf sie achten: dass du das Geschäft der Beratung ebenso verstehst wie das Handwerk.

Kurze Antwort: „Die Auslastung ist der Anteil der Arbeitszeit, der Kunden in Rechnung gestellt wird, und ein Beratungshaus lebt davon. Ich halte sie gesund, indem ich Leute früh auf Projekte plane, aber ich schütze Zeit für Weiterbildung und für Angebote, denn das nächste Projekt hängt davon ab. Bei der Qualität kommt der Kunde zuerst; bei der Verteilung der Arbeit das Team.“

Die ausführliche Antwort: Als Senior-IT-Berater führst du einen Workstream und coachst Junior-Berater. Ein Principal IT Consultant ist der Experte, nach dem Kunden namentlich fragen, und gestaltet Lösungen über Projekte hinweg. Ein Manager in der IT-Beratung führt Projekte und Kunden: Budgets, Besetzung, Angebote und die Beziehung zur Führung des Kunden. Rechne mit einem Fall: Zwei Kunden brauchen in derselben Woche deine beste Beraterin.

Schwache Antwort: „Die Auslastung ist das Problem der Partner.“ Nachfrage: „Dein Team ist voll verplant, und ein neues Angebot ist fällig.“ Erklär, wie du es besetzt.

Dein Lebenslauf für diese Fragen

Jedes Projekt in deinem Lebenslauf lädt zu den Fragen oben ein: welche Plattform, welche Phase, was du mit dem Kunden entschieden hast, was live gegangen ist. Gib jedem Projekt eine Zeile, die eine davon beantwortet, bevor sie gestellt wird:

Prüfe deinen Lebenslauf mit der kostenlosen Bewertung an einem Job als IT-Berater, den du willst; die Fragen, die sie dünn findet, sind die, die du mit einem echten Projekt üben solltest.