Praxisleitfaden 01 / 05
Fachverfahren modernisieren heißt nicht, funktionierende Verwaltungssoftware pauschal zu ersetzen. Es bedeutet, Veränderungen wieder kontrollierbar zu machen: durch belastbare Schnittstellen, nachvollziehbare Datenflüsse und einen Betrieb, den nicht nur eine einzelne Person versteht.
Die kurze Antwort für IT-Verantwortliche
Beginnen Sie nicht mit einer Produktentscheidung. Wählen Sie einen konkreten Engpass, kartieren Sie seine Abhängigkeiten und definieren Sie einen prüfbaren Zielzustand. Eine schrittweise Ablösung nach dem Strangler-Fig-Prinzip kann den Bestand weiter nutzbar halten, während einzelne Funktionen ersetzt werden. Das Architekturprinzip beschreibt Martin Fowler als Alternative zur vollständigen Neuentwicklung auf einen Schlag. [1]
Die Situation: digitaler Eingang, analoge Nacharbeit
Ein Antrag kommt online an. Eine Sachbearbeiterin überträgt Daten in das Fachverfahren, legt Anhänge im Dokumentenmanagement ab und pflegt den Bearbeitungsstand in einer separaten Liste. Das Portal ist modern; der Vorgang dahinter bleibt fragmentiert. Dieses beispielhafte Szenario zeigt, warum ein neues Frontend allein noch keinen durchgängigen Prozess schafft.
Das Ziel ist nicht eine möglichst moderne Technologieliste. Es ist eine Änderung, die ohne unkontrollierte Nebenwirkungen in Produktion gehen kann.
Wo Legacy-Modernisierung in Behörden festläuft
Versteckte Verträge zwischen Systemen
Eine nächtliche CSV-Datei, ein direkter Datenbankzugriff oder ein fest eingebautes Feldformat kann wichtiger sein als die offiziell dokumentierte API. Deshalb sollte die Bestandsaufnahme nicht bei Produktnamen enden. Sie muss Sender, Empfänger, Datenverantwortliche, Ausfallfolgen und fachliche Fristen erfassen. Auch manuelle Schritte gehören in die Architekturkarte.
Fehlende Trennung von fachlicher Logik und Technik
Eine Schnittstelle ist nur hilfreich, wenn ihre Bedeutung klar ist. Was bedeutet ein Statuswechsel? Welche Datumsangabe ist verbindlich? Wer darf eine Entscheidung zurücknehmen? Werden solche Regeln allein im Adapter nachgebaut, entsteht ein zweites, schlechter dokumentiertes Fachverfahren. Die fachliche Verantwortung muss im zuständigen System und Team bleiben.
Migration wird zu spät geplant
Ein erfolgreicher Import ist noch kein erfolgreicher Umzug. Zählwerte, Summen, Referenzen, Anhänge, Berechtigungen und Aufbewahrungsregeln müssen zusammenpassen. Bereits im ersten Arbeitspaket sollten deshalb ein Testdatenbestand, fachliche Vergleichsfälle und ein Verfahren für Abweichungen entstehen. Produktionsdaten werden dafür nur auf freigegebener Grundlage verwendet.
Diagnosefrage: Welche Änderung ist heute so riskant, dass sie trotz fachlichen Nutzens immer wieder verschoben wird? Genau dort beginnt die Priorisierung.
Die Lösung: schrittweise entkoppeln statt parallel alles neu bauen
Eine schmale, versionierte Integrationsgrenze
Definieren Sie zuerst einen einzigen Geschäftsvorgang: beispielsweise Antrag anlegen, Dokument zuordnen oder Bearbeitungsstatus lesen. Beschreiben Sie Anfrage, Antwort, Berechtigung, Fehlerfall und Versionswechsel. Ein Adapter übersetzt zwischen diesem Vertrag und dem Bestandsverfahren. Neue Anwendungen müssen die internen Tabellen des Altverfahrens dann nicht mehr kennen.
FIT-Connect ist ein konkretes Beispiel für standardisierte Übermittlung zwischen Onlinediensten und Verwaltungssystemen. Seine Eignung ist am jeweiligen Anwendungsfall zu prüfen; es ersetzt weder die fachliche Validierung noch die interne Integrationsarchitektur. [2]
Genau ein führendes System je Datum
Legen Sie fest, wo ein Datum verbindlich geändert wird. Unkoordinierte Schreibzugriffe in Alt- und Neusystem erzeugen Widersprüche. Für den Übergang eignen sich je nach Bestand Ereignisse, kontrollierte Exporte oder ein nachweisbar konsistenter Migrationslauf. Veränderungen benötigen stabile IDs, Wiederholbarkeit ohne Doppelanlage und nachvollziehbare Verarbeitungsergebnisse.
Austauschbarkeit schließt Betrieb und Wissen ein
Quellcode allein reicht nicht. Zum Übergabepaket gehören Build-Anleitung, Konfiguration, Berechtigungskonzept, Abhängigkeiten, Monitoring und ein getesteter Wiederanlauf. Sicherheitsprüfungen werden in die Entwicklung integriert; der NIST-SSDF bietet dafür einen etablierten Rahmen. [3] Ein neuer Dienstleister sollte das System anhand der Unterlagen aufbauen können, ohne auf informelles Wissen des bisherigen Teams angewiesen zu sein.
Von der Bestandsaufnahme zum ersten produktiven Schritt
1. Einen begrenzten Auftrag definieren
Wählen Sie nicht die gesamte Behördenlandschaft, sondern einen Vorgang mit erkennbarem Engpass. Fachbereich, IT-Betrieb, Informationssicherheit und Datenschutz vereinbaren Umfang, Testdaten, Entscheidungsverantwortung und Abnahme. Die erste Lieferung besteht aus einer Abhängigkeitskarte, einem Risikoregister und einer nachvollziehbaren Entscheidung zwischen Stabilisieren, Entkoppeln und Ablösen.
2. Die Schnittstelle unter realistischen Bedingungen prüfen
Testen Sie Normalfälle und die unangenehmen Varianten: dieselbe Nachricht zweimal, ein fehlender Anhang, ein abgelaufenes Zertifikat, ein Timeout nach erfolgreicher Speicherung. Ein technischer Fehler darf nicht unbemerkt einen fachlichen Doppelvorgang erzeugen. Kontrakttests und fachliche Vergleichsfälle werden Teil der automatisierten Auslieferung.
3. Kontrolliert in den Betrieb wechseln
Beginnen Sie mit einem begrenzten Nutzerkreis oder einer klar abgegrenzten Vorgangsart. Ein lesender Parallelvergleich kann Ergebnisse prüfen, ohne zwei schreibende Systeme zu schaffen. Vor der Umschaltung stehen Verantwortliche, Wartungsfenster und Rückfallplan fest. Achtung: Ein Software-Rollback macht bereits geschriebene Fachinformationen nicht automatisch rückgängig. Dafür braucht es eigene Korrektur- und Abgleichverfahren.
Vier Abnahmetests, die mehr sagen als eine Demo
Fachliche Gleichheit: Die vereinbarten Referenzfälle liefern korrekte Ergebnisse. Wiederholbarkeit: Erneut zugestellte Nachrichten erzeugen keine ungewollten Doppelvorgänge. Wiederanlauf: Ein Wiederherstellungstest erreicht die vereinbarten Ziele. Übernahme: Ein zweites Team kann Deployment und Betrieb nachvollziehen.
Erst danach wird die nächste Funktion herausgelöst. So entsteht eine Modernisierungsfolge mit Entscheidungspunkten statt ein unbefristeter Parallelbetrieb.
Wirtschaftlichkeit: die Kosten der Änderung sichtbar machen
Vergleichen Sie nicht nur Projektangebote. Berücksichtigen Sie Bestandspflege, Lizenzen, Schnittstellenkosten, Parallelbetrieb, Datenbereinigung, Testaufwand, Schulung und spätere Übergabe. Eine neue Plattform kann billiger wirken, solange diese Positionen außerhalb der Kalkulation bleiben.
Ein illustratives Rechenbeispiel, keine Kundenzusage: Bei 12.000 Vorgängen pro Jahr entsprechen vier eingesparte Minuten manueller Übertragung 800 Arbeitsstunden. Werden zusätzlich 200 Stunden für Qualitätskontrolle und Ausnahmebearbeitung gebraucht, bleiben rechnerisch 600 Stunden Kapazität. Das ist noch keine Budgeteinsparung. Ob tatsächlich Zeit frei wird, muss ein Pilot im Fachbereich zeigen.
Was in eine Leistungsbeschreibung gehört
Beschreiben Sie Ergebnisse statt pauschal eine Wunschplattform: dokumentierte Schnittstellen, Datenexport mit Metadaten, Testfälle, Rechte an Arbeitsergebnissen, Betriebsunterlagen und Unterstützung beim Anbieterwechsel. Legen Sie fest, welche Nachweise mit der Abnahme übergeben werden und wie Änderungen am Datenmodell behandelt werden.
Öffentliche Beschaffung verlangt Wettbewerb und Gleichbehandlung; mittelständische Interessen sind nach § 97 GWB zu berücksichtigen. Daraus folgt kein Anspruch eines bestimmten KMU auf Beauftragung. Die konkrete Verfahrensgestaltung bleibt Aufgabe der Vergabestelle. [4]
Nächster Schritt mit Insight42
Lassen Sie den kritischsten Modernisierungsengpass eines Fachverfahrens technisch einordnen. Insight42 verbindet Cloud-, Daten- und Automatisierungsleistungen mit technischer Umsetzung. [5] Ein sinnvoller Einstieg ist ein abgegrenzter Check mit Abhängigkeitskarte, Schnittstellenentwurf und priorisiertem Umsetzungsplan. Umfang und Ergebnisse werden vor Beauftragung vereinbart.
Kontakt: support@insight42.com. Nennen Sie Verfahren, Engpass und gewünschten Zielzustand. Bitte keine personenbezogenen Vorgangsdaten, Zugangsdaten oder vertraulichen Unterlagen in die erste Nachricht aufnehmen.
Häufige Fragen zur Fachverfahrensmodernisierung
Müssen wir das bisherige Fachverfahren ersetzen?
Nicht zwangsläufig. Wenn fachliche Eignung, Wartung und Sicherheitsniveau tragfähig sind, kann eine gezielte Entkopplung ausreichen. Eine Ablösung wird sinnvoller, wenn grundlegende Anforderungen nicht mehr wirtschaftlich oder zuverlässig erfüllt werden können. Der Vergleich sollte anhand konkreter Optionen und Folgekosten erfolgen.
Was tun, wenn der Hersteller keine API anbietet?
Zuerst unterstützte Import-, Export- oder Integrationswege und die vertraglichen Rechte prüfen. Ein direkter Datenbankzugriff oder Oberflächen-Roboter ist kein gleichwertiger Ersatz für eine stabile Schnittstelle. Solche Übergangslösungen brauchen dokumentierte Grenzen und einen Ablösepfad.
Ist Open Source automatisch souverän?
Nein. Der verfügbare Quellcode kann Wahlfreiheit verbessern. Ohne betreibbare Artefakte, Dokumentation, Rechteprüfung und alternative Betriebskompetenz bleibt jedoch eine praktische Abhängigkeit bestehen. Entscheidend ist, ob eine Übernahme tatsächlich gelingt.
Woran erkennen wir einen sinnvollen ersten Auftrag?
Er liefert eine fachlich prüfbare Verbesserung, ohne den gesamten Bestand umbauen zu müssen. Umfang, Verantwortliche, Abnahme und Rückfallweg sind klar. Ein kleines Vorhaben ist nicht automatisch risikoarm; seine Abhängigkeiten müssen trotzdem verstanden werden.
Fazit: Modernisierung wird dann souverän, wenn Daten, Wissen und Betrieb übertragbar werden. Nicht das Alter einer Anwendung entscheidet, sondern die Fähigkeit, sie kontrolliert zu verändern.
Quellen und fachliche Referenzen
[1] Martin Fowler: Strangler Fig
[2] FITKO: Was ist FIT-Connect?
[3] NIST: SP 800-218, Secure Software Development Framework 1.1
[4] Gesetze im Internet: § 97 GWB
[5] Insight42: Leistungsprofil
Quellenstand: 27.09.2026. Rechenbeispiele und Diagramme dienen der Erläuterung.