Eigene Anwendung

Bewerbungsmanager

Bewerbungs-CRM mit auswechselbarer KI — und einem Protokoll darüber, welche Daten sie je gesehen hat

Zustand: Produktiv
Stand: 12 KI-Funktionen · 80 von 84 Läufen lokal
Technik: Next.js / TypeScript · PostgreSQL mit Prisma · Ollama — KI-Anbieter austauschbar · Docker auf Unraid

Die Anforderung

Warum es gebaut wurde

Wer sich ernsthaft bewirbt, jongliert mit Dingen, die kein Formular fasst: Welche Fassung des Anschreibens ging an wen? Welche Anforderung aus der Anzeige habe ich noch nicht beantwortet? Was habe ich im letzten Gespräch zugesagt? Handelsübliche Werkzeuge lösen das mit einer Tabelle oder verlangen, dass man Lebenslauf und Anschreiben in die Cloud eines Anbieters lädt. Beides war für mich ausgeschlossen: Bewerbungsunterlagen sind die persönlichsten Daten, die ein Berufstätiger besitzt, und wer sie einem Sprachmodell übergibt, sollte wenigstens wissen, welche. Die Anforderung lautete deshalb: ein vollständiges Bewerbungs-CRM, dessen KI austauschbar ist — und das über jeden einzelnen KI-Lauf Rechenschaft ablegt.

Der Aufbau

Wie es aufgebaut ist

Kern ist ein Profil, das einmal gepflegt wird: berufliche Stationen, Projekte, Kompetenzen, Ausbildung, Zertifikate und eine Faktenbasis mit belegbaren Aussagen. Jede Bewerbung ist eine Akte darüber — Stellenanzeige, Analyse, Abgleich, Anschreiben mit Versionsverlauf, Unternehmensbriefing, Gesprächsvorbereitung, Dokumente mit Versandprotokoll. Darüber liegt eine Pipeline über die Stadien vom Entwurf bis zur Zusage. Ein zweiter Strang steht daneben, der mit der einzelnen Bewerbung nichts zu tun hat: Entwicklungsfelder wie IT-Führung, IT-Strategie oder Drittparteienmanagement, jeweils mit Stand, Begründung und Maßnahmen. Das Datenmodell umfasst 59 Tabellen — die Anwendung bildet den Vorgang ab, nicht eine Liste.

Der Ablauf

Von der Anzeige zum Gespräch

Anzeige erfassen
Link, eingefügter Text oder Datei. Das System liest die Stelle ein und legt eine Akte an.
Stellenanalyse
Die Anforderungen werden einzeln herausgearbeitet, dazu die Schlüsselbegriffe. Aus 9 Anzeigen entstanden so 138 benannte Anforderungen und 106 Begriffe.
Abgleich mit dem Profil
Jede Anforderung wird gegen das eigene Profil gehalten — Treffer, Teiltreffer, Lücke. Benannt wird auch, was nicht passt; eine Passung von 100 Prozent ist ein Warnzeichen, kein Ergebnis.
Unternehmensbriefing
Was das Unternehmen tut, woran es gerade arbeitet, was im Gespräch zur Sprache kommen dürfte — aus eigenen Notizen und der Anzeige.
Anschreiben
Entwurf auf Basis von Profil, Analyse und Abgleich, im hinterlegten Schreibstil. Dann Kritik am eigenen Entwurf, dann Redaktion. Jede Fassung bleibt erhalten und ist vergleichbar.
Gesprächsvorbereitung
Erwartbare Fragen aus der Anzeige, Antwortvorschläge aus der eigenen Faktenbasis, ein Briefing in Blöcken. 71 Fragen sind bisher entstanden.
Übungsgespräch
Das System stellt die Fragen und bewertet die Antworten — mit dem Verlauf der Simulation als Kontext, sodass Rückfragen möglich sind. Gute Antworten wandern in eine Antwortbibliothek und stehen bei der nächsten Bewerbung bereit.
Versand und Nachhalten
Welche Dokumente in welcher Fassung wohin gingen, wird protokolliert. Statuswechsel, Aktivitäten und Gesprächsnotizen hängen an der Akte.

Die Entscheidungen

Was bewusst so und nicht anders gelöst ist

Der KI-Anbieter ist eine Einstellung, keine Architekturentscheidung
Die Anwendung spricht mit einem lokalen Modell genauso wie mit einem externen Dienst. Eingerichtet ist ein Modell auf einem Rechner im eigenen Netz; 80 der bisher 84 KI-Läufe sind dort gelaufen. Das war kein Komfortwunsch: Wer Bewerbungsunterlagen verarbeitet, muss den Anbieter wechseln können, ohne die Anwendung neu zu bauen.
Jeder KI-Lauf sagt, was er übergeben hat
Zu jedem Lauf steht im Protokoll, welche Daten in die Anfrage eingegangen sind — „Stellenanzeige (4.098 Zeichen); Ergebnis der Stellenanalyse; Master-Profil; 5 berufliche Stationen; 7 Kompetenzen". Nicht „es wurden Daten verarbeitet", sondern welche. Erst das macht die Frage beantwortbar, ob ein Anbieter etwas gesehen hat, das er nicht sehen sollte.
Ein Datenschutzmodus, der wirklich etwas verhindert
Jeder Lauf trägt das Merkmal, ob er nur lokal laufen darf. Ist es gesetzt und steht kein lokales Modell bereit, wird der Lauf abgebrochen — er weicht nicht auf einen externen Dienst aus. Ein Schalter, der im Zweifel ausweicht, ist kein Schutz.
Fehlschläge werden gezählt, nicht versteckt
Von 84 Läufen sind 13 gescheitert, bei einer mittleren Dauer von 47 Sekunden. Das steht im Protokoll, weil ein lokales Modell auf gewöhnlicher Hardware langsamer und wackliger ist als ein Rechenzentrum — wer das verschweigt, baut die falschen Erwartungen.
Bewerben und Entwickeln sind zwei Dinge
Die Entwicklungsfelder hängen am Profil, nicht an einer Bewerbung. Eine Lücke, die in drei Anzeigen auftaucht, ist keine Absage — sie ist ein Hinweis darauf, woran zu arbeiten ist. Deshalb bleibt sie stehen, wenn die Bewerbung längst abgeschlossen ist.

Die Gestaltung

Wie es aussieht — und warum

Die Oberfläche folgt dem Vorgang, nicht dem Datenmodell: Wer eine Bewerbung öffnet, sieht ihren Stand und den nächsten sinnvollen Schritt, nicht 59 Tabellen. Die KI-Funktionen sitzen dort, wo die Arbeit anfällt — die Analyse an der Anzeige, die Kritik am Anschreiben, die Fragen an der Vorbereitung. Nichts davon läuft von selbst los: Jeder KI-Lauf wird ausgelöst, und vorher ist zu sehen, was übergeben wird.

Der Nachweis

Im Betrieb entstanden bisher 9 Stellenanalysen mit 138 herausgearbeiteten Anforderungen, 134 Abgleichspunkte, 71 Gesprächsfragen, 36 Briefingblöcke und eine Antwortbibliothek mit 17 Einträgen. 84 KI-Läufe sind protokolliert, jeder mit Anbieter, Modell, Dauer, Erfolg und der Angabe, welche Daten übergeben wurden. 80 davon liefen auf dem lokalen Modell.

Weiter