Fabio SteyerEN

DATA ANALYTICS · AUTOMATISIERUNG · KI-ANWENDUNG

Dreitausend Belege.Niemand prüft sievon Hand.

Also habe ich es nachprüfbar gemacht.

Ich bin Fabio. Bei einem Bauunternehmen habe ich rund 3.000 Rechnungen und Angebote automatisiert abgeglichen. Jetzt suche ich die nächste Aufgabe zwischen Daten und Betrieb.

Projekte ausprobierenKontakt aufnehmen

Berlin / remote · feste Vollzeitstelle

≈ 3.000
Belege im betrieblichen AbgleichBetriebliche Erfahrung · nicht öffentlich
4 / 4
eingebaute Abweichungen gefundenÖffentlich nachrechenbar
104
Tests in fünf Python-ProjektenÖffentlich nachrechenbar

01 / ARBEITSWEISE

Vom gewachsenen Ablaufzum prüfbaren Ergebnis.

Erst verstehen, wo ein Ablauf hakt. Dann entscheiden, welcher Schritt ein Skript braucht, welcher ein Sprachmodell und welcher besser in menschlicher Hand bleibt.

  1. 01

    Verstehen

    Belege, Ausnahmen und Übergaben lesen. Nicht nur den vorgesehenen Ablauf.

  2. 02

    Entscheiden

    Feste Zahlenformate mit Regeln prüfen. Sprachmodelle dort einsetzen, wo Sprache die Aufgabe ist.

  3. 03

    Nachweisen

    Fehler gezielt einbauen, Ergebnisse vergleichen und Grenzen offenlegen.

  4. 04

    Betreiben

    Eine Lösung zählt, wenn sie im Tagesgeschäft funktioniert. Bei Cavator waren das rund 3.000 Belege.

02 / ÖFFENTLICHE PROJEKTE

Nicht nur beschreiben.Ausprobieren.

Fünf Python-Projekte mit erfundenen Daten und diese Seite selbst. Die ersten beiden Beispiele sind vereinfacht und laufen direkt in Ihrem Browser, die übrigen zeigen gemessene Läufe.

PYTHON · PDFPLUMBER · PYTEST

Rechnungen gegen Angebote prüfen

Ein Lieferant schickt ein Angebot und rechnet später dagegen ab. Ob die Rechnung dem entspricht, was vereinbart war, prüft bei dreistelligen Positionszahlen niemand Zeile für Zeile.

4 / 4Abweichungen erkannt. Keine Fehlalarme.
Entscheidungen, Ergebnis und Grenzen

Der Ansatz

Beide Dokumente werden aus PDF ausgelesen, die Positionen einander zugeordnet und jede Abweichung mit ihrer Auswirkung in Euro gemeldet. Ein Generator erzeugt die Testbelege selbst und protokolliert, welche Abweichungen er eingebaut hat. Dadurch lässt sich die Erkennungsleistung messen statt behaupten.

Das gemessene Ergebnis

4 von 4 eingebauten Abweichungen erkannt, 0 Fehlalarme, 20 Tests. Drei der sieben Testfälle enthalten bewusst keine Abweichung: Ein Einheitenwechsel und eine Teillieferung über zwei Rechnungen sind keine Fehler. Ein Prüfer, der sie meldet, wird nach zwei Wochen nicht mehr gelesen.

Was das nicht zeigt

Keine echten Lieferantenbelege. Die erzeugten PDFs sind aufgeräumter als die Wirklichkeit. Kein OCR für Scans, keine proprietären Händlerformate, keine ERP-Anbindung.

Code und Messwerte auf GitHub
01 / BELEGABGLEICHErfundene Daten
AngebotA-001

Montagewinkel · Pos. 01

120 × 2,00 €
Vereinbart240,00 €
RechnungR-001

Montagewinkel · Pos. 01

120 × 2,20 €
Berechnet264,00 €
24,00 € zu viel berechnet

120 Stück × 0,20 € Preisdifferenz. Dieselbe Position, ein anderer Preis.

Vereinfachtes Rechenbeispiel. Hier werden keine PDFs verarbeitet oder Daten übertragen.

PYTHON · STANDARD LIBRARY

Gleichzeitige Schreibzugriffe ohne Server koordinieren

Mehrere Prozesse arbeiten am selben Dateibaum. Es gibt nur Dateien, keinen Datenbankserver, der Sperren vergibt. Ohne Absprache überschreibt der langsamere Prozess stillschweigend, was der schnellere gerade gespeichert hat.

14 → 0Verlorene Einträge im dokumentierten Vergleichslauf.
Entscheidungen, Ergebnis und Grenzen

Der Ansatz

Wer schreiben will, deklariert vorab die Dateien samt der Hashes, die er vorgefunden hat, und holt eine globale Freigabe. Nach dem Schreiben prüft der Koordinator, ob ausschließlich deklarierte Dateien verändert wurden, und schreibt Vorher- und Nachher-Hash in ein Journal. Eine Lücke in dieser Kette beweist, dass jemand außerhalb des Verfahrens geschrieben hat.

Das gemessene Ergebnis

Derselbe Arbeitsauftrag, vier Prozesse, zwanzig erwartete Schreibvorgänge: ohne Koordination 14 verloren und 18 Kettenlücken, mit Koordination 0 und 0. Kein Lauf meldet dabei einen Fehler. Genau das macht diese Fehlerklasse teuer. 18 Tests.

Was das nicht zeigt

Kein verteiltes System: ein Rechner, ein Dateisystem. Kein Lock-Manager: Eine globale Freigabe serialisiert alles, was bei seltenen Schreibvorgängen richtig und bei vielen falsch ist. Die Prüfung auf undeklarierte Änderungen hasht den ganzen Baum und skaliert nicht auf Hunderttausende Dateien.

Code und Messwerte auf GitHub
02 / GLEICHZEITIGE ZUGRIFFEVier Prozesse
Ageschrieben
Bgeschrieben
Cgeschrieben
Dgeschrieben
data.jsonGespeicherte Einträge
1 von 4 Einträgen bleibt.

Alle lesen denselben alten Stand. Jeder überschreibt die Einträge der anderen.

Vereinfachter Ablauf: vier Prozesse, je ein Eintrag. Kein echter Mehrprozesslauf im Browser.

PYTHON · REGEX · STANDARD LIBRARY

Texte automatisch auf Floskeln prüfen und umschreiben lassen

Ein Text, der nach Schablone klingt, wird überflogen, egal ob Anschreiben, Angebot, Bericht oder Produkttext. Die Muster, die diesen Eindruck erzeugen, sind wenige und lassen sich benennen. Die Gegenüberstellung „nicht X, sondern Y", der Gedankenstrich mitten im Satz, Floskeln, fünf gleich lange Sätze hintereinander.

36 / 36Eingebaute Muster in Testsätzen erkannt. Keine Fehlalarme.
Entscheidungen, Ergebnis und Grenzen

Der Ansatz

Ein fester Satz aus 17 Regeln findet diese Muster zuverlässig und immer gleich. Für die Umschreibung holt das Werkzeug Vorschläge von zwei KI-Modellen verschiedener Hersteller ein, eines ohne jede Vorgeschichte des Textes, das zweite als Gegenprobe. Jeder Vorschlag wird einzeln eingesetzt und nur behalten, wenn die Regeln danach nicht mehr Befunde zählen als vorher. Die Modelle schlagen vor, die Regeln entscheiden.

Das gemessene Ergebnis

Geprüft an 50 erfundenen Testsätzen, darunter 18 unauffällige, bei denen kein Werkzeug anschlagen darf: 36 von 36 eingebauten Mustern gefunden, 0 Fehlalarme, 29 automatische Tests. Ein englischer Beispieltext geht durch das Verfahren von 6 Befunden auf 0. Der deutsche behält eine Warnung, weil die Umschreibungen alle Sätze gleich lang gemacht haben, und das Werkzeug sagt das auch.

Was das nicht zeigt

Kein Detektor für KI-Texte, und durch Umkehrung wird auch keiner daraus. Die Regelliste beruht auf eigener Beobachtung, nicht auf Literatur. Die mitgelieferten Modellantworten sind gekennzeichnete Platzhalter; echte Läufe brauchen zwei API-Schlüssel.

Code und Messwerte auf GitHub
03 / TEXTPRÜFUNGErfundener Beispieltext
  1. 1Regelprüfung17 Regeln, immer gleich
  2. 2Vorschlag 1KI-Modell ohne Vorwissen
  3. 3Vorschlag 2Modell eines anderen Herstellers
  4. 4Regelprüfungbehält nur, was besser ist
vorherFAIL 6 · WARN 4

Ich suche nicht irgendeine Stelle, sondern eine, in der die Abläufe noch entstehen.

Gefunden: Gegenüberstellung „nicht X, sondern Y“
nachherFAIL 0 · WARN 0

Ich suche eine Stelle, in der die Abläufe noch entstehen.

Vorschlag 1, von der Regelprüfung bestätigt

Ein Satz aus dem englischen Beispieltext, hier übersetzt. Die Zähler stammen aus dem gemessenen Lauf über den ganzen Text. Zwei Runden, fünf Vorschläge übernommen, keiner verworfen.

PYTHON · STANDARD LIBRARY · THREADS

Arbeit, die von selbst weiterläuft, ohne dass jemand sie anstößt

In einer kleinen Organisation bleibt vieles liegen, weil jemand es anstoßen müsste: Listen abarbeiten, Zahlen zusammentragen, Ergebnisse festhalten. Sollen geplante Läufe das nachts von selbst erledigen, während tagsüber Menschen an denselben Dateien arbeiten, braucht es drei Dinge. Eine Regel, wer gerade woran darf. Eine Übergabe, damit am nächsten Morgen sichtbar ist, was passiert ist. Und eine Grenze für das, was ein Lauf nie ohne Menschen tun darf.

12 / 12Aufgaben abgearbeitet oder vorgelegt, ohne dass jemand einen Lauf begleitet.
Entscheidungen, Ergebnis und Grenzen

Der Ansatz

Jeder Lauf nimmt sich ein Projekt nach dem anderen vor, sperrt es kurz für sich und arbeitet die offenen Aufgaben ab; ein Projekt, an dem gerade jemand sitzt, wird übersprungen und beim nächsten Lauf erledigt. Zum Schluss fasst ein Abschlussschritt zusammen, was alle Läufe getan und gefunden haben, als Übergabe für die nächste Person. Was unumkehrbar ist, etwa Senden, Veröffentlichen, Löschen oder Bezahlen, legt ein Lauf nur vor; ein Mensch entscheidet, ein späterer Lauf führt aus und hält fest, wer freigegeben hat.

Das gemessene Ergebnis

Zwei geplante Läufe und eine Person gleichzeitig auf demselben Beispiel mit 12 Aufgaben in drei Projekten, einmal ohne und einmal mit Protokoll, danach aus den Dateien gezählt. Mit Protokoll: alle 12 Aufgaben abgearbeitet oder zur Entscheidung vorgelegt, keine doppelt, 8 Befunde in der Übergabe, die Änderung der Person erhalten, 0 unumkehrbare Aktionen ohne Freigabe. Ohne Protokoll: Aufgaben doppelt erledigt, die Änderung der Person überschrieben, keine Übergabe, 8 unumkehrbare Aktionen ohne Freigabe. 16 automatische Tests.

Was das nicht zeigt

Die Aufgaben sind Attrappen; eine erledigen heißt eine Zeile anhängen. Wann ein Lauf startet, bestimmt ein Zeitplaner außerhalb, der nicht mitgeliefert ist. Ein Rechner, kein Netzwerk, kein Sprachmodell. Zwei Entwurfsfehler, die erst der Vergleichslauf sichtbar gemacht hat, stehen offen in der README.

Code und Messwerte auf GitHub
04 / ARBEIT OHNE ANSTOSSErfundene Beispielorganisation
Zwei Läufe und eine Person, gleichzeitigohne Protokollmit Protokoll
Aufgaben abgearbeitet oder vorgelegt1212
Befunde in der Übergabe08
Änderung der Person erhaltenneinja
Aufgaben doppelt erledigt7–120
Unumkehrbare Aktionen ohne Freigabe80

Ablauf oben nachgestellt aus dem Vergleichslauf im Repository, Aufgaben und Projekte wie dort. Die Tabelle ist aus den Dateien gezählt; wie viele Aufgaben ohne Protokoll doppelt erledigt werden, hängt vom Zeitpunkt ab.

ASTRO · GSAP · NODE TEST

Diese Website, mit KI-Werkzeugen in sechs Arbeitstagen gebaut

Eine Seite wie diese hätte vor wenigen Jahren Wochen gekostet: Gestaltung, zwei Sprachen, Bewegung, Rechtstexte, Tests. Mit KI-Werkzeugen als Mitarbeiter geht das in Tagen, wenn man weiß, was man will, die Entscheidungen selbst trifft und jedes Ergebnis nachprüft. Diese Seite ist der Beleg dafür, samt Commit-Verlauf.

6Arbeitstage vom leeren Repository bis zu dieser Seite mit sechs Projekten.
Entscheidungen, Ergebnis und Grenzen

Der Ansatz

Erst ein schriftlicher Entwurf, dann der Code, von KI-Werkzeugen geschrieben und von mir abgenommen. Drei Gestaltungsvarianten an einem Tag auf einer Codebasis gebaut, im Browser verglichen, eine gewählt. Automatische Tests laufen gegen die fertige Seite und prüfen unter anderem, dass die Datenschutzerklärung beschreibt, was die Seite wirklich tut. Statisch ausgeliefert, ohne Tracking und ohne fremde Dienste; beim Besuch verlässt keine Anfrage diese Adresse.

Das gemessene Ergebnis

Über 30 Commits an 6 Arbeitstagen, live seit dem zweiten Tag. 8 Seiten in zwei Sprachen, 0 Anfragen an Dritte, 10 Tests gegen den fertigen Build, Barrierefreiheit 100 im Lighthouse-Lauf gegen die Live-Adresse. Die Texte dieser Seite sind mit dem Werkzeug aus dem dritten Projekt geprüft.

Was das nicht zeigt

Sechs Arbeitstage heißt nicht sechs volle Tage am Stück; sie liegen über zwei Wochen verteilt. Kein Backend, kein Formular, keine Nutzerdaten. Das Repository enthält Bewerbungstexte und ein Foto und steht deshalb ohne freie Lizenz. In Suchmaschinen ist die Seite absichtlich nicht zu finden; sie ist nur über den geteilten Link erreichbar.

Code und Messwerte auf GitHub
05 / DIESE WEBSITEMit KI gebaut, von mir abgenommen
  1. 11.09.Gerüst und Gestaltung
  2. 12.09.live, Rechtstexte, Lighthouse
  3. 14.09.Auslieferung über Actions
  4. 15.09.Feinschliff
  5. 16.09.drei Varianten, Bewegung
  6. 22.09.sechs Projekte
6
Arbeitstage, verteilt über zwei Wochen
30+
Commits, live seit dem zweiten Tag
3
Gestaltungsvarianten an einem Tag
10
Tests gegen den fertigen Build
0
Anfragen an Dritte beim Besuch
100
Barrierefreiheit im Lighthouse-Lauf
tests/site-build.test.mjs10 / 10
  • Kopf- und Fußzeile auf jeder Seite gleich
  • genau eine Hauptüberschrift je Seite
  • Datenschutzerklärung beschreibt, was die Seite tut
  • keine Platzhalter, keine Ersatzzeichen im Build

Alle Zahlen stammen aus dem Repository dieser Seite, die Arbeitstage aus den Commit-Daten. Dort lässt sich beides nachrechnen.

PYTHON · CSV · STANDARD LIBRARY

Bestellvorschlag aus den Zahlen des Kassensystems

Eine Bar bucht jeden Verkauf im Kassensystem und zählt einmal pro Woche die Regale. Bestellt wird trotzdem mit Notizblock im Keller. Wie viel von was reicht bis zur nächsten Lieferung, und in wie vielen Kisten? Vier Lieferanten, vier Formulare, jede Woche.

10 / 10Eingebaute Engpässe bestellt, Gebindezahl exakt. Keine unnötige Bestellung.
Entscheidungen, Ergebnis und Grenzen

Der Ansatz

Das Werkzeug nimmt, was das System schon weiß, Verkäufe je Tag und die letzte Zählung, und rechnet je Artikel den Bestand heute, den Tagesverbrauch der letzten zwei Wochen und den Bestand am Liefertag. Fällt der unter das Minimum, wird in ganzen Gebinden bis zum Zielbestand bestellt. Artikel ohne Verkäufe werden gelistet statt bestellt, ein Lieferant unter Mindestbestellwert wird gemeldet statt aufgefüllt. Dazu eine Zählliste in Regalreihenfolge für die nächste Inventur.

Das gemessene Ergebnis

Erfundene Bar mit 33 Artikeln und 4 Lieferanten. Ein Generator baut vier Wochen Verkäufe und protokolliert, was er einbaut. Ergebnis: 10 von 10 Engpässen bestellt, Gebindezahl 10 von 10 exakt, 0 unnötige Bestellungen, 3 von 3 Grenzfällen unangetastet, 2 von 2 Artikel ohne Verbrauch gelistet, 1 Lieferant unter Mindestbestellwert gemeldet. 21 Tests, darunter einer, der zeigt, dass die Prüfung durchfallen kann.

Was das nicht zeigt

Kein echter Kassenexport; die Dateien sind nur so geformt. Kein Versand, die Bestellung endet als Datei je Lieferant, weil das Versandskript an der Bar begonnen und nie fertig wurde. Kein Forecast, ein Zwei-Wochen-Schnitt glättet Wochenenden und Ereignisse. Kein SQL, damals nicht und hier nicht.

Code und Messwerte auf GitHub
06 / BESTELLVORSCHLAGErfundene Bar
  1. 1Zählenletzte Zählung minus Verkäufe seitdem
  2. 2VerbrauchVerkäufe der letzten 14 Tage
  3. 3ReichweiteBestand am Liefertag
  4. 4Gebindeganze Kisten bis zum Ziel
Cola 0,33 · Keller A2bestellen
Bestand heute
40
6 je Tag × 2 Tage
− 12
am Liefertag
28
Minimum
48
bis Ziel 144 fehlen
116
Kisten à 24
5
Bestellung je Lieferant4 × CSV + TXT
  • Getraenke Nord3 Pos.268,80 €
  • Brauerei Falkenau3 Pos.767,20 €
  • Spirituosen Hensel3 Pos.564,00 €
  • Bar Bedarf Kruse1 Pos.112,00 €unter Mindestbestellwert 150 €

Zahlen aus dem Lauf über die mitgelieferten Beispieldaten: 10 von 10 Engpässen bestellt, 0 unnötig, 1 Lieferant gemeldet. Versendet wird nichts; die Bestellung endet als Datei.

03 / HINTERGRUND

Physik hat mich gelehrt,genauer hinzusehen.

Mein B.Sc. in Physik ist abgeschlossen. Die Masterarbeit an der TU Berlin schreibe ich berufsbegleitend. Aus der wissenschaftlichen Datenauswertung bringe ich die Gewohnheit mit, eine Aussage gegen Daten zu prüfen.

Im Betrieb habe ich gelernt, dass ein guter Prototyp noch keine gute Übergabe ist. Bei Cavator ging es um echte Belege, Ausnahmen und Menschen, die mit dem Ergebnis weiterarbeiten mussten.

Werdegang, Foto und Belege

04 / KONTAKT

Welcher Ablauf verdienteinen zweiten Blick?

Ich suche eine feste Vollzeitstelle in Datenanalyse, Prozessautomatisierung oder in einer technischen Rolle mit Kundenkontakt. Berlin oder remote.

steyerfabio@gmail.com
LinkedIn ↗GitHub ↗Berlin, Deutschland