FireAdministration/docs/AUFWANDSSCHAETZUNG.md

Aufwandsschätzung

Schätzung je Phase, daneben der tatsächliche Aufwand aus dem Devlog. Stand: 4. September 2026.

Wie hier gerechnet wird

Es stehen bewusst zwei Größen nebeneinander, weil sie Verschiedenes aussagen:

Größe	Bedeutung
Sitzungszeit	Wie lange Claude tatsächlich gearbeitet hat. Das ist die Zahl, die im Devlog steht, und die Grundlage für die Planung der nächsten Sitzung.
Vergleichsaufwand	Was eine einzelne Person mit diesem Stack für dasselbe Ergebnis gebraucht hätte, in Personentagen zu 8 Stunden. Das ist die Zahl, die gegenüber der Wehr etwas bedeutet — sie beantwortet „was wäre das sonst wert gewesen".

Der Vergleichsaufwand ist eine Schätzung, keine Messung. Er unterstellt jemanden, der den Stack kennt, die Feuerwehr-Fachlichkeit aber erst klären muss — also Recherche zu DGUV-Fristen, FwDV 3 und FwDV 7 einschließt.

Faktoren, die in die Schätzung eingehen:

• Fachlichkeit — wie viel muss geklärt werden, bevor gebaut werden kann?
• Sicherheitsbezug — Atemschutz und Prüfnachweise brauchen mehr Tests und mehr Sorgfalt als eine Adressliste.
• Fremdsysteme — Gotenberg, Nominatim, tileserver-gl, Ollama, RFID-Leser. Jedes ist eine eigene Fehlerquelle.
• Offline und Echtzeit — die teuersten Anforderungen im ganzen Projekt.

Übersicht

Phase	Inhalt	Vergleichsaufwand	Sitzungszeit geschätzt	Sitzungszeit tatsächlich
0	Fundament	12–16 PT	—	1:00 h
1	Stammdaten	10–14 PT	2,5–3,5 h	2:05 h
2	Wartung und Prüfung	18–24 PT	4,5–6 h	2:25 h
3	Einsätze und Übungen	12–16 PT	3–4 h	2:10 h
4	Kiosk-PWA mit Offline	16–22 PT	4–5,5 h	3:00 h
5	Atemschutz (FwDV 7)	14–18 PT	3,5–4,5 h	2:40 h
6	Kartenmodule	14–18 PT	3,5–4,5 h	2:50 h
7	Benachrichtigungen und Termine	10–13 PT	2,5–3,5 h	3:10 h
8	Lokale KI	9–12 PT	2,5–3 h	3:40 h
9	Kassenverwaltung	8–11 PT	2–3 h	offen
	Summe	123–164 PT	28–37 h

123–164 Personentage entsprechen etwa 6 bis 8 Monaten Vollzeitarbeit einer einzelnen Person. Zum Vergleich: eine kommerzielle Feuerwehrverwaltung kostet je nach Umfang 500 bis 2.500 Euro im Jahr, dauerhaft, mit den Daten beim Anbieter.

---

Phase 0 — Fundament

Vergleichsaufwand: 12–16 PT · Tatsächlich: 1:00 h Sitzungszeit

Baustein	PT
Monorepo, Werkzeuge, TypeScript, Tailwind, shadcn	1,5
Docker Compose, Dockerfile, Traefik, Healthchecks	2,5
Prisma-Schema der Basismodelle	2,0
Row Level Security samt Rollen- und Rechtekonzept in Postgres	2,5
Auth.js mit OIDC, lokalem Login und Terminal-Anmeldung	3,0
storage, audit, warteschlange, Integrationsschnittstellen	2,0
Basis-Layout, Anmeldeseite, Übersicht, Dark Mode	1,5
Seed, Vitest, Playwright, Dokumentation	1,5

Das Teuerste war nicht der sichtbare Teil, sondern die Mandantentrennung. RLS so aufzusetzen, dass Migrationen, Seed und Anmeldung funktionieren und die Anwendung trotzdem nichts Fremdes sieht, verlangt zwei getrennte Datenbankzugänge und ein sauberes Verständnis davon, wann welcher greift. Wer das nachträglich einbaut, zahlt ein Vielfaches.

Phase 1 — Stammdaten

Vergleichsaufwand: 10–14 PT · Tatsächlich: 2:05 h Sitzungszeit (1:15 h Hauptteil, 0:50 h Nachtrag)

Baustein	PT
Modelle: Standort, Geraeteraum, Geraetetyp, Qualifikation	1,5
Fahrzeug und Geraet um DIN-Typisierung und Lebensdauer erweitern	1,5
Tabellen mit Sortierung, Filter, Volltextsuche, Spaltenauswahl	3,0
QR-Code je Gerät, Etikettenbogen als PDF (65 Etiketten, DIN A4)	1,5
QR-Scan im Browser über die Kamera	1,0
CSV-/Excel-Import mit Spaltenzuordnung und Vorschau	2,5
Gerätehistorie aus dem Audit-Log	1,0
Massenbearbeitung und Tastaturbedienung	1,0

Der Import ist der Posten, der erfahrungsgemäß aus dem Ruder läuft. Jede Wehr bringt eine andere Excel-Datei mit, und die Vorschau vor dem Übernehmen ist kein Komfort, sondern die Bedingung dafür, dass die Wehr dem Ergebnis traut.

Rückblick. Die Schätzung hat gut getroffen — mit einer Verschiebung: Der Import war teurer als angesetzt (deutsche Datumsformate, Semikolon-CSV, Windows-1252, Excel-Seriennummern, Dubletten in der Datei), die Tabellen dagegen billiger, weil Sortierung und Blättern serverseitig laufen und keine Tabellenbibliothek nötig war. Nicht eingeplant war die Zeitzonen-Falle in der Fristenrechnung; sie hätte in Phase 2 deutlich mehr gekostet, wenn sie erst dort aufgefallen wäre.

Das zunächst offen gebliebene Formular zum einzelnen Anlegen von Geräten wurde als Nachtrag ergänzt — geschätzt waren 0,5 PT, tatsächlich 0:50 h Sitzungszeit. Die Hälfte davon ging für zwei Dinge drauf, die nichts mit dem Formular zu tun hatten: eine Server/Client-Grenze, die stillschweigend undefined liefert, und Datumsfelder, die sich in Chromium nicht automatisiert füllen lassen.

Phase 2 — Wartung und Prüfung

Vergleichsaufwand: 18–24 PT · Tatsächlich: 2:25 h Sitzungszeit — die aufwendigste Phase

Baustein	PT
Modelle: Vorlage, Checklistenpunkt, Termin, Prüfung, Ergebnis, Mangel, Rückruf	3,0
Fristen-Dashboard mit Gruppierungen	2,5
Nächtlicher BullMQ-Job: Termine erzeugen, Status setzen, erinnern	2,5
Prüfungs-Wizard mit Fotoupload je Checklistenpunkt	3,5
Unterschrift auf Canvas, Touch und Maus	1,5
PDF-Protokoll über Gotenberg mit Fotos und Signatur	3,0
Unveränderlichkeit und Korrekturprotokolle mit Verweis	1,5
Lebensdauerüberwachung und Aussonderungsvorschlag	1,5
Rückrufe, externe Wartung, Mängel-Workflow	2,5

Hier entsteht der eigentliche Wert: die Software wird zum Nachweis gegenüber der Unfallkasse. Das heißt aber auch, dass jeder Fehler teuer ist. Die Unveränderlichkeit abgeschlossener Protokolle ist der Kern — und der Grund, warum der Audit-Log schon in Phase 0 append-only ist.

Rückblick. Deutlich unter der geschätzten Sitzungszeit, und das aus einem Grund, der sich benennen lässt: die Fristenrechnung aus Phase 1 war schon da und musste nur exportiert werden. Wäre sie hier entstanden — samt der Zeitzonen-Falle, über die Phase 1 gestolpert ist —, sähe die Zahl anders aus.

Teurer als gedacht war das, was zwischen den Bausteinen liegt. Drei Beispiele:

• Die Reihenfolge beim Abschluss einer Prüfung ist nicht beliebig. Unterschriften und Mängel müssen vor dem Statuswechsel entstehen, denn danach lässt die Datenbank am Protokoll nichts mehr zu. Derselbe Stolperstein traf auch den Seed, der die Beispielprüfung zunächst fertig anlegen wollte.
• Die Protokollnummer muss unter einer Sperre vergeben werden. Aufgefallen ist das erst, weil die E2E-Tests Desktop und Tablet gleichzeitig prüfen ließen — zwei Prüfer, die im selben Moment abschließen, sind im Gerätehaus kein konstruierter Fall.
• Das PDF entsteht zwischen zwei Datenbanktransaktionen, nicht in einer. Fotos aus MinIO holen und Gotenberg rendern lassen dauert länger, als eine offene Transaktion warten darf.

Billiger als angesetzt war das Unterschriftenfeld: Pointer-Events decken Finger, Stift und Maus in einem ab, und mehr als Skalierung auf die Pixeldichte und touch-action: none braucht es nicht.

Phase 3 — Einsätze und Übungen

Vergleichsaufwand: 12–16 PT · Tatsächlich: 2:10 h Sitzungszeit

Baustein	PT
Modelle: Einsatz, Einsatzfahrzeug, Einsatzkraft, Material, Lagemeldung, Übung	2,0
Schnellerfassung mit Nachtragen	1,5
Geocoding über self-hosted Nominatim mit Rückfallweg	1,5
Personalauswahl nach Verfügbarkeit und Qualifikation	2,0
Stärkeberechnung nach FwDV 3	1,0
Einsatzbericht als PDF, Jahresexport für die Gemeinde	2,0
Statistik: Kategorien, Eintreffzeiten, Beteiligung, Auslastung	2,5
Externes Portal mit signiertem QR-Link, ohne Login, rate-limited	2,0

Das externe Portal für Fremdwehren ist sicherheitsrelevant: ein Zugang ohne Anmeldung, der zeitlich begrenzt und mengenbegrenzt sein muss. Der Aufwand steckt weniger in der Funktion als in der Absicherung.

Rückblick. Die Schätzung lag richtig darin, wo der Aufwand steckt — nur nicht in welcher Reihenfolge.

Billiger als gedacht war das Portal. Der Grund liegt in Phase 0 und 2: die Mandantentrennung, das Hashen von Geheimnissen und die Ablage von Dateien gab es schon, und der Zugang war am Ende ein Datensatz mit Hash, ein Zeitfenster und ein Zähler in Redis. Was blieb, war die Frage, was das Portal nicht zeigen darf — und die ist fachlicher Natur, nicht technischer.

Teurer war die Statistik. Nicht das Rechnen, sondern die Entscheidung, welche Zahl gilt: der Durchschnitt der Eintreffzeiten sagt nichts, weil ein einzelner Einsatz auf der Autobahn ihn verschiebt. Es zählt der 80-Prozent-Wert, weil die Gemeinde danach fragt — und das steht in keinem Pflichtenheft, das muss man wissen.

Zwei Dinge fielen erst beim Tun auf:

• Koordinaten müssen doppelt liegen. Prisma kann den PostGIS-Typ nicht lesen; ohne die Dezimalgrade daneben wäre jede Anzeige eine Rohabfrage geworden. Ein Trigger hält beides zusammen.
• Der Nummernkreis war schon zweimal da (Prüfprotokolle, jetzt Einsätze und Übungen). Beim dritten Mal wurde daraus ein eigener Baustein — die passende Gelegenheit war genau diese, keine früher.

Phase 4 — Kiosk-PWA

Vergleichsaufwand: 16–22 PT · Tatsächlich: 3:00 h Sitzungszeit

Baustein	PT
Eigenes Kiosk-Layout, 64px-Ziele, hoher Kontrast, kein Hover-Zwang	2,0
Anmeldung per RFID (WebHID), PIN und QR vom Handy	2,5
Wizards: Wartung, Fahrtenbuch, Mangel, Inventur, Wäsche, Anwesenheit	4,0
Hallen-Monitor mit DWD-Wetterwarnung	2,0
Service Worker, App-Shell und Stammdaten offline	3,0
IndexedDB-Outbox mit Idempotenzschlüssel und Synchronisation	4,0
Konfliktbehandlung und Konfliktliste für den Administrator	2,0
Playwright-Tests für den Offline-Fall	1,5

Offline-Fähigkeit mit schreibenden Aktionen ist die technisch schwierigste Anforderung des ganzen Projekts. Eine Outbox ist schnell gebaut; dass sie unter Verbindungsabbruch, Doppelklick und parallelem Zugriff von zwei Terminals nichts verliert und nichts doppelt schreibt, ist die eigentliche Arbeit. Die Idempotenzschlüssel sind dafür der Schlüssel, nicht die Synchronisation.

Rückblick. Der Satz oben hat sich bestätigt, nur anders als gedacht. Die Outbox selbst war in einer halben Stunde geschrieben und mit zwölf Unit-Tests belegt. Zwei Stellen kosteten die Zeit, und keine davon steht in der Aufstellung:

• Der Zeitgeber, der nie ablief. Die Warteschlange hatte einen Wiederholungstakt von 20 Sekunden — und der wurde bei jedem Rendern neu aufgezogen, weil das Mutationsobjekt von React Query in den Abhängigkeiten stand. Alles sah richtig aus, alle Unit-Tests waren grün, und der liegen gebliebene Vorgang wäre im Gerätehaus trotzdem liegen geblieben. Gefunden hat das nur der Playwright-Test, der context.setOffline(true) setzt und dann wartet. Die 1,5 PT für „Playwright-Tests für den Offline-Fall" waren der bestangelegte Posten der Phase.
• Die Frage, wann ein Vorgang aus der Warteschlange darf. Nicht „wenn erfolgreich", sondern „wenn er beim Server angekommen ist" — dazu gehört auch „bereits verarbeitet" und „in der Konfliktliste". Diese Unterscheidung ist die ganze Idempotenz; ohne sie kreist ein Vorgang für immer.

Billiger als angesetzt war die Anmeldung per RFID: die Aufstellung nennt WebHID, gebraucht wurde es nicht. Handelsübliche Leser geben die Kartenkennung als Tastatureingabe aus. Ein Zuhörer auf dem Fenster, der am Anschlagstempo erkennt, dass da keine Hand tippt, ersetzt eine ganze Geräteschnittstelle.

Billiger war auch der Service Worker — 80 Zeilen von Hand, ohne Workbox. Die Regeln sind einfach, solange man sie sich traut aufzuschreiben: Seiten aus dem Netz mit Ausweichseite, lesende Abfragen aus dem Zwischenspeicher mit Nachladen, schreibende überhaupt nicht anfassen. Eine Bibliothek hätte hier mehr Fragen aufgeworfen als beantwortet.

Teurer war die Terminaloberfläche selbst. Nicht die Kacheln, sondern die Zustände dahinter: Wer schon eingecheckt ist, sieht „Gehen" statt „Kommen". Wer mit einem Fahrzeug unterwegs ist, sieht „Fahrt beenden". Wer keine Rechte für die Inventur hat, sieht die Kachel nicht. Jede dieser Verzweigungen ist trivial — sechs davon in einem Schirm, der ohne Nachdenken bedienbar bleiben soll, sind es nicht.

Phase 5 — Atemschutz nach FwDV 7

Vergleichsaufwand: 14–18 PT · Tatsächlich: 2:40 h Sitzungszeit

Baustein	PT
Modelle: Atemschutzeinsatz, Trupp, Druckmessung, G26, Belastungsübung	2,0
Truppanlage per RFID, Eingangsdruck	1,5
Serverseitig autoritative Timer, Socket.IO-Verteilung	3,5
Rückzugsdruck-Berechnung, Ampel, akustischer Alarm	2,0
Erinnerung zur Druckabfrage im Intervall	1,0
Mayday-Knopf mit Protokolleintrag	1,0
Lückenloses PDF-Protokoll am Einsatz	1,5
G26.3-Fristen, Belastungsübungen, Tauglichkeitsampel	2,0
Tests: Reload und Verbindungsabbruch überstehen	2,0

Der Aufwand liegt nicht in der Funktion, sondern im Beweis, dass sie hält. Ein Timer, der einen Reload überlebt, ist Pflicht — deshalb muss die Zeit serverseitig geführt werden und der Browser nur anzeigen. Diese Phase bekommt den höchsten Testanteil im Projekt.

Rückblick. Der Satz stimmt, aber die Schlussfolgerung war die falsche. Die Aufstellung veranschlagt 3,5 PT für „serverseitig autoritative Timer" — als wäre ein Timer zu bauen. Gebraucht wurde das Gegenteil: kein Timer. Wer die Zeit als Zeitstempel in die Datenbank schreibt und jede Ansicht selbst rechnen lässt, hat nichts, was einen Reload nicht überlebt. Der teuerste Posten der Schätzung war der billigste der Umsetzung, weil die richtige Entscheidung ihn auflöst statt ihn zu lösen.

Auch Socket.IO fiel weg. Es geht nur in eine Richtung — der Server meldet eine Änderung, der Browser holt den Stand über den Weg, den es ohnehin gibt. Ein Route Handler mit Server-Sent Events ist siebzig Zeilen und braucht kein verändertes Deployment.

Teurer war das, was in keiner Zeile der Aufstellung steht: die Frage, was passiert, wenn nichts passiert. Ein abgerissener Ereignisstrom meldet sich nicht — EventSource schweigt einfach. Eine Anzeige, die deshalb weiter „Verbunden" behauptet, ist gefährlicher als eine, die gar nichts anzeigt: sie lässt einen alten Stand wie einen aktuellen aussehen. Aufgefallen ist das nur, weil der E2E-Test das Netz gekappt und danach nachgesehen hat — die 2,0 PT für „Tests: Reload und Verbindungsabbruch überstehen" waren wieder der bestangelegte Posten der Phase.

Billiger als gedacht war die Tauglichkeit. Nicht das Rechnen — die Entscheidung, nicht zu sperren. Damit entfielen alle Sonderfälle, die eine Sperre nach sich zieht: Übersteuern, Begründungspflicht, Freigabe durch wen. Was bleibt, ist ein Satz neben dem Namen, und der ist im Einsatz mehr wert.

Phase 6 — Kartenmodule

Vergleichsaufwand: 14–18 PT · Tatsächlich: 2:50 h Sitzungszeit

Baustein	PT
MapLibre GL, tileserver-gl, MBTiles fürs Ausrückegebiet	2,5
Hydranten mit PostGIS, Cluster, Filter, Umkreissuche	3,0
Import aus GeoJSON und Stadtwerke-CSV	1,5
Objekte und Feuerwehrpläne nach DIN 14095, Volltextsuche	3,0
Lagekarte mit taktischen Zeichen nach FwDV 102 als SVG-Set	3,5
Echtzeit-Sync der Lagekarte zwischen Geräten	2,0
Wasserförderung: Höhenprofil, Druckverlust, Verstärkerpumpen	2,5

Das SVG-Set für die taktischen Zeichen ist Fleißarbeit, aber unvermeidbar — fertige Sets sind selten frei verwendbar. Die Wasserförderungsberechnung ist Physik mit klaren Formeln und deshalb gut testbar.

Rückblick. Beide Sätze stimmen. Das Zeichenset war Fleißarbeit — 22 Zeichen als SVG-Pfade, keine davon schwierig, alle zusammen eine Stunde. Und die Wasserförderung war tatsächlich der am besten testbare Teil des ganzen Projekts: 21 Tests, die alle etwas über die Physik aussagen statt über den Code.

Dabei fiel auf, dass die Beiwerte im ersten Wurf um den Faktor zehn danebenlagen — aufgefallen ist es nur, weil die Tests gegen die Tabellenwerte der Ausbildung prüfen und nicht gegen das, was die Funktion gerade ausrechnet. Ein Test, der die eigene Implementierung bestätigt, hätte hier fröhlich grün gemeldet.

Billiger als angesetzt war die Umkreissuche. 3,0 PT für „Hydranten mit PostGIS, Cluster, Filter, Umkreissuche" — davon entfiel der Löwenanteil auf eine einzige SQL-Abfrage mit ST_DWithin und einen GiST-Index. PostGIS war seit Phase 0 im Container; genutzt wurde es erst jetzt.

Teurer war die Frage, was passiert, wenn es keine Karte gibt. Eine MBTiles- Datei des Ausrückegebiets ist hunderte Megabyte groß, gehört niemandem außer der Wehr und kann nicht im Repository liegen. Das heißt: der Normalfall beim ersten Start ist eine Karte ohne Hintergrund — und sie muss trotzdem etwas taugen. Aus dieser Anforderung kam der leere Stil mit Hinweis, die Erkennung eines nicht erreichbaren Servers und die Zusicherung im E2E-Test, dass genau das ehrlich angezeigt wird. In der Aufstellung steht davon keine Zeile.

Phase 7 — Benachrichtigungen und Termine

Vergleichsaufwand: 10–13 PT · Tatsächlich: 3:10 h Sitzungszeit

Baustein	PT
Kanalabstraktion: E-Mail, Telegram, ntfy, Web-Push	2,5
Vorlagen mit Platzhaltern, je Ereignis und Rolle	2,0
Abonnements je Person	1,0
Kalender mit Serienterminen und Selbstanmeldung	3,0
ICS-Feed je Person mit Token	1,5
Digitaler Dienstausweis mit signiertem QR und Prüfseite	2,0

Das Grundgerüst der Kanalabstraktion stand bereits aus Phase 0 (lib/integrations/), das hat etwa einen Personentag gespart.

Die einzige Phase bisher, die über der geschätzten Sitzungszeit liegt — und zwar an einer Stelle, die in der Aufstellung nicht vorkommt. „Kalender mit Serienterminen" klingt nach einer Datumsrechnung; teuer war die Entscheidung gegen eine Regel und für ausgeschriebene Termine, und dann die Kalenderarithmetik dahinter: setMonth(+1) auf dem 31. Januar ergibt den 3. März, der 29. Februar existiert in vier von fünf Jahren nicht, und ein Übungsabend muss über die ganze Serie auf demselben Wochentag bleiben. Das sind drei Tests, die man erst schreibt, wenn man den Fall kennt.

Die 1,5 PT für den Feed waren dagegen zu hoch angesetzt, weil sie CalDAV unterstellen. ICS ist ein Textformat; der ganze Erzeuger sind hundertsechzig Zeilen samt Maskierung und Zeilenumbruch nach 75 Oktetten.

Phase 8 — Lokale KI

Vergleichsaufwand: 9–12 PT · Tatsächlich: 3:40 h Sitzungszeit

Baustein	PT
lib/ai/ mit OpenAI-kompatiblem Client, abschaltbar	1,0
Diktat: Aufnahme im Browser, faster-whisper, Transkript	2,5
Berichtsassistent mit Übernehmen/Verwerfen	2,0
Wiki mit pgvector, semantische Suche, RAG mit Quellenangabe	3,5
Belegerfassung über ein Vision-Modell, immer bestätigen	2,0

Der Client aus Phase 0 (lib/integrations/llm.ts) war bereits vorhanden — er konnte allerdings nur Text und musste um Einbettungen und Bilder erweitert werden.

Die Kennzeichnungspflicht war mit „kostet wenig Zeit" zu günstig eingeschätzt. Sie kostet wenig, wenn man sie als Abzeichen an einer Ansicht versteht. Als Zusicherung — eigener Datensatz je Ausgabe, unveränderlich, genau eine Entscheidung, Trigger und REVOKE dahinter, zwei Protokollansichten — ist sie ein guter halber Personentag, der in der Aufstellung gar nicht vorkommt.

Zwei weitere Posten fehlen in der Schätzung:

Das eigene Postgres-Image. pgvector und PostGIS gibt es nicht zusammen; es gibt kein offizielles Image mit beidem. Ein Dockerfile, ein Neubau, ein Neustart des Dienstes — eine halbe Stunde, aber sie stand nirgends.

Der Betrieb ohne Modell. Der größte Einzelposten dieser Phase, und in der Aufstellung steht davon keine Zeile. Eine Wehr setzt FLORIAN auf, lange bevor sie über eine Grafikkarte nachdenkt — also muss jede Ansicht ohne Modell vollständig benutzbar bleiben und ehrlich sagen, was fehlt. Das sind vier verschiedene Hinweise an vier Stellen, eine zweite Suche, die immer funktioniert, und vierzehn E2E-Tests, die genau diesen Zustand absichern.

Phase 9 — Kassenverwaltung

Vergleichsaufwand: 8–11 PT — am 03.09.2026 ergänzt

Baustein	PT
Modelle: Konto, Kategorie, Buchung, Beitragssatz, Beitrag, Rechnung, Abschluss	2,0
Buchungsmaske mit Kategorievorschlag, Beleg als Datei	1,5
Beitragslauf, Mahnstufen, Zahlungsabgleich aus CAMT.053 oder MT940	2,5
Rechnungen mit Nummernkreis und PDF	1,0
Kassenabschluss mit Zeitraumsperre und Prüfbericht	1,5
Auswertungen und Exporte	1,5

Der Zahlungsabgleich ist der unsichere Posten: CAMT.053 ist gut spezifiziert, MT940 dagegen je nach Bank unterschiedlich ausgelegt. Falls die Hausbank nur MT940 liefert, kommt ein halber bis ganzer Tag für die Eigenheiten dazu.

Die Unveränderlichkeit festgeschriebener Buchungen kostet hier fast nichts — das Muster steht seit Phase 0 mit dem Audit-Log-Trigger und lässt sich übernehmen.

---

Was hier nicht drin ist

Betrieb und Einführung. Datenübernahme aus der Altsoftware, Schulung der Wehr, Sicherungskonzept, Monitoring: nach Erfahrung noch einmal 15 bis 25 Prozent des Entwicklungsaufwands.