Wir unterstützten einen Auftraggeber bei einer .NET-Entwicklung zur Digitalisierung und Verteilung von Schriftgut in den Systemen eines öffentlichen Auftraggebers. Im Fokus standen Schnittstellen für die automatisierte Dokumentenverarbeitung, die Analyse und Behebung von Systemfehlern sowie qualitätssichernde Maßnahmen wie Code-Reviews und testgetriebene Entwicklung.
Ausgangslage
Ein Auftraggeber setzte das Vorhaben für einen öffentlichen Auftraggeber um. Gesucht war Unterstützung für eine Softwarelösung, mit der Schriftgut digitalisiert, verarbeitet und in bestehende Systeme verteilt werden konnte.
Die Aufgabe umfasste dabei nicht nur die Umsetzung technischer Anbindungen, sondern auch die Bearbeitung von Systemfehlern im laufenden Umfeld. Zudem galten behördliche Qualitätsstandards, die in der Entwicklung und Qualitätssicherung berücksichtigt werden mussten.
Lösung
Wir übernahmen im Zeitraum von April 2022 bis August 2022 die .NET-Entwicklung in einem Team mit 4 Personen. Der Schwerpunkt lag auf Schnittstellen und Datenverarbeitung für die automatisierte Dokumentenverarbeitung sowie auf der Analyse und Behebung von Systemfehlern nach ITIL v4.
Ergänzend führten wir Code-Reviews durch und arbeiteten mit TDD. TDD steht für testgetriebene Entwicklung und bedeutet, dass Anforderungen über Tests abgesichert und die Umsetzung daran ausgerichtet wird. So wurde die Umsetzung an den vorgegebenen Qualitätsstandards ausgerichtet.
Ergebnis
Geliefert wurden Entwicklungsleistungen für die Digitalisierung und Verteilung von Schriftgut in den Systemen eines öffentlichen Auftraggebers. Dazu gehörten Schnittstellen für die automatisierte Dokumentenverarbeitung sowie Beiträge zur Fehleranalyse und Fehlerbehebung im Systemumfeld.
Das Projekt lief von April 2022 bis August 2022 und wurde nach 5 Monaten abgeschlossen.
Technik
Im Projekt kamen folgende Technologien und Vorgehensweisen zum Einsatz:
- C# für Teile der Umsetzung in der .NET-Entwicklung
- Visual Basic für Arbeiten im vorhandenen technischen Umfeld
- Captiva Designer im Kontext der Dokumentenverarbeitung
- Artifactory zur Verwaltung von Artefakten, also von bereitgestellten Softwareständen und Paketen
- Git für die Versionsverwaltung, also die nachvollziehbare Verwaltung von Änderungen am Quellcode
- CI/CD für automatisierte Abläufe beim Bauen und Bereitstellen von Software
- ITIL v4 als Rahmen für die strukturierte Bearbeitung von Systemfehlern und Serviceprozessen
Warum .NET-Entwicklung für Dokumentenprozesse oft gut passt
In solchen Projekten geht es meist darum, eingehende Dokumente zuverlässig in digitale Abläufe zu überführen und an bestehende Fachverfahren oder Archive zu übergeben. Dafür müssen unterschiedliche Systeme zusammenspielen: Erfassung, Verarbeitung, Verteilung und häufig auch nachgelagerte Bearbeitung. Genau an dieser Stelle ist .NET-Entwicklung oft eine passende Grundlage, weil sich damit Fachlogik, Schnittstellen und Prüfprozesse in einer gemeinsamen technischen Umgebung abbilden lassen.
Wichtig ist dabei weniger ein einzelnes Werkzeug als eine saubere Struktur der Lösung. Dokumentenprozesse enthalten häufig viele Regeln: Welche Unterlagen werden wie erkannt, wohin werden Daten übergeben, welche Fehler müssen abgefangen werden und wie wird eine Nachbearbeitung ermöglicht. Wenn diese Logik unübersichtlich wächst, steigen Wartungsaufwand und Fehlerrisiko. Deshalb ist ein klarer Zuschnitt der Komponenten entscheidend. Schnittstellen sollten eindeutig beschreiben, welche Daten erwartet werden und wie mit unvollständigen oder fehlerhaften Inhalten umzugehen ist.
Für Auftraggeber mit öffentlichen Aufgaben spielt zudem Verlässlichkeit im laufenden Betrieb eine große Rolle. Systeme müssen nicht nur neue Fälle verarbeiten, sondern auch mit Ausnahmen umgehen können. Dazu gehören etwa unklare Eingangsdaten, technische Unterbrechungen oder Rückmeldungen aus angeschlossenen Systemen. Eine geeignete Architektur trennt daher Verarbeitungsschritte voneinander und macht Fehler nachvollziehbar. Das erleichtert den Betrieb und die spätere Weiterentwicklung.
Typisch ist außerdem, dass bestehende Anwendungen nicht vollständig ersetzt, sondern gezielt erweitert werden. Dann muss neue Software mit gewachsenen Strukturen zusammenarbeiten. Das spricht für einen pragmatischen Ansatz: zentrale Abläufe sauber modellieren, Anbindungen schrittweise aufbauen und Qualität früh absichern. Begriffe wie CI/CD oder TDD stehen dabei für fest verankerte Qualität im Entwicklungsprozess. CI/CD bezeichnet automatisierte Abläufe zum Prüfen und Bereitstellen von Software, TDD die testgetriebene Entwicklung über vorab definierte Tests.
Wer ein ähnliches Vorhaben plant, sollte deshalb nicht nur auf Funktionen schauen, sondern auf Wartbarkeit, klare Verantwortlichkeiten der Komponenten und nachvollziehbare Fehlerbehandlung. Gerade bei dokumentenbasierten Verfahren entscheidet diese Grundlage darüber, wie stabil ein System im Alltag arbeitet und wie gut es sich später an neue Anforderungen anpassen lässt.
Wie solche Projekte von der Anforderung bis zum Betrieb ablaufen
Bei Vorhaben rund um Dokumentenverarbeitung und Systemanbindungen ist ein schrittweises Vorgehen meist sinnvoll. Zu Beginn steht die fachliche Klärung: Welche Dokumente kommen ins System, welche Informationen müssen erkannt oder übernommen werden, welche Zielsysteme sind beteiligt und welche Randbedingungen gelten im Betrieb. Gerade in Umgebungen mit mehreren Beteiligten ist es wichtig, Zuständigkeiten früh festzuhalten. Sonst bleibt unklar, wer Fachregeln entscheidet, wer Schnittstellen beschreibt und wer Fehler im Betrieb bewertet.
Darauf folgt ein belastbares Konzept. Es beschreibt, wie Eingänge verarbeitet werden, an welchen Stellen Prüfungen stattfinden und wie technische und fachliche Fehler behandelt werden. In dieser Phase lohnt sich besondere Sorgfalt bei den Schnittstellen. Eine Schnittstelle ist die klar definierte Verbindung zwischen Systemen, über die Daten übergeben und Rückmeldungen ausgetauscht werden. Unklare Felddefinitionen, fehlende Regeln für Ausnahmefälle oder uneinheitliche Datenformate führen später oft zu aufwendiger Nacharbeit.
In der Umsetzung empfiehlt sich eine enge Abstimmung zwischen Fachseite, Betrieb und Entwicklung. So können Unklarheiten früh erkannt werden, bevor sie sich in mehreren Komponenten festsetzen. Parallel sollte Qualitätssicherung nicht erst am Ende beginnen. Reviews, also strukturierte Prüfungen des Quellcodes, helfen dabei, Fehlerquellen und unnötige Komplexität früh zu erkennen. Automatisierte Tests ergänzen diesen Schritt, indem sie wiederkehrend prüfen, ob wesentliche Abläufe stabil bleiben.
Auch der Übergang in den Betrieb braucht Vorbereitung. Typisch sind Fragen wie: Wie werden Störungen gemeldet, wie lassen sich Fehler eingrenzen, welche Protokolle werden benötigt und wer entscheidet über Prioritäten bei Korrekturen. Für viele Organisationen ist ein serviceorientierter Rahmen hilfreich, etwa wenn Störungen, Änderungen und Verantwortlichkeiten klar beschrieben werden.
Wir orientieren uns in solchen Vorhaben an einem klaren Ablauf: Anforderungen gemeinsam schärfen, ein tragfähiges Konzept erstellen, die Lösung umsetzen, qualitätssichern und anschließend den Übergang in den Betrieb begleiten. Wer ein ähnliches Projekt einordnen möchte, kann dafür den Projekt-Check nutzen oder ein unverbindliches Erstgespräch anfragen. So lassen sich Umfang, Risiken und offene Punkte meist früh strukturieren.
Typische Stolpersteine bei Dokumentenverarbeitung und Schnittstellen
Solche Systeme wirken auf den ersten Blick oft geradlinig: Dokumente kommen an, werden erkannt, verarbeitet und an andere Systeme übergeben. In der Praxis entstehen die Schwierigkeiten jedoch meist an den Übergängen. Unterschiedliche Datenstände, unvollständige Dokumente, uneinheitliche Benennungen oder fachliche Sonderfälle führen schnell dazu, dass ein Prozess nicht sauber durchläuft. Deshalb sollten Ausnahmen nicht als Randthema behandelt werden, sondern als fester Teil des Konzepts.
Ein häufiger Stolperstein ist die Unterschätzung bestehender Systemlandschaften. Gerade in größeren Organisationen sind Fachverfahren, Archivierung, Eingangsbearbeitung und nachgelagerte Prozesse eng miteinander verknüpft. Änderungen an einer Stelle können Rückwirkungen an anderer Stelle auslösen. Deshalb braucht es eine klare Sicht darauf, welche Daten führend sind, wann Informationen verbindlich werden und wie Korrekturen verarbeitet werden.
Ebenso wichtig ist die Betriebsfähigkeit. Ein System muss nicht nur fachlich richtig arbeiten, sondern auch beobachtbar und beherrschbar sein. Dazu gehören nachvollziehbare Meldungen, aussagekräftige Protokolle und ein definierter Umgang mit Störungen. Ohne diese Grundlagen wird die Fehlersuche im Alltag unnötig aufwendig. Begriffe wie ITIL v4 stehen hier für einen Rahmen, mit dem Serviceprozesse, Störungsbearbeitung und Zuständigkeiten strukturiert beschrieben werden können.
Auch Sicherheits- und Datenschutzthemen sollten früh eingeplant werden, gerade wenn Dokumente personenbezogene oder besonders sensible Informationen enthalten können. Welche Anforderungen im konkreten Fall gelten, sollte jedoch jeweils mit den zuständigen Fachstellen, der Informationssicherheit sowie dem Datenschutzbeauftragten oder rechtlich qualifiziert geprüft werden. Technisch bedeutet das typischerweise: Zugriffe begrenzen, Verarbeitungsschritte nachvollziehbar machen und Daten nur dort bereitstellen, wo sie gebraucht werden.
Für den späteren Betrieb ist zudem entscheidend, wie Änderungen eingespielt werden. Neue Fachregeln, Korrekturen und Erweiterungen sollten kontrolliert bereitgestellt werden können, ohne unnötige Risiken für laufende Abläufe zu erzeugen. Dabei helfen automatisierte Build- und Bereitstellungsprozesse sowie eine saubere Versionierung. Wer ein ähnliches Vorhaben plant, sollte deshalb nicht nur die eigentliche Funktion betrachten, sondern auch Hosting und Betrieb, Fehlerbehandlung, Nachvollziehbarkeit und die dauerhafte Pflege der Lösung mitdenken.
Häufige Fragen
Welche Faktoren beeinflussen die Kosten eines solchen Projekts?
Die Kosten hängen typischerweise davon ab, wie viele Systeme angebunden werden müssen, wie komplex die Dokumentenlogik ist und wie stark bestehende Anwendungen berücksichtigt werden müssen. Ebenfalls relevant sind Anforderungen an Qualitätssicherung, Betrieb, Fehlerbehandlung und Abstimmung mit mehreren Beteiligten. Für eine erste Einordnung eignet sich der Kostenrechner. Wenn bereits eine Beschreibung oder ein Lastenheft vorliegt, ist ein Projektsteckbrief meist der bessere nächste Schritt.
Wovon hängt die Projektdauer bei Dokumentenverarbeitung und Schnittstellen ab?
Die Dauer wird meist durch fachliche Klärungen, die Qualität der vorhandenen Schnittstellenbeschreibungen und die Abstimmung zwischen Auftraggeber, Fachseite und Betrieb geprägt. Auch Testmöglichkeiten in vorhandenen Systemen beeinflussen den Ablauf stark. Je früher Eingangsformate, Fehlerfälle und Verantwortlichkeiten geklärt sind, desto planbarer wird die Umsetzung. In ähnlichen Vorhaben ist daher eine frühe Strukturierung der offenen Punkte oft wichtiger als ein vorschneller Start in die Entwicklung.
Wie sollte man bei einem solchen Vorhaben vorgehen?
Bewährt hat sich ein Vorgehen, das Fachlichkeit, Technik und Betrieb zusammen betrachtet. Am Anfang stehen Anforderungen, Ziele und Randbedingungen. Danach folgt ein Konzept für Verarbeitung, Schnittstellen und Fehlerbehandlung. Erst darauf sollte die eigentliche Umsetzung aufbauen. Während der Entwicklung sind regelmäßige Abstimmungen und Qualitätssicherung wichtig. Zum Schluss braucht es einen geordneten Übergang in den Betrieb, damit Störungen, Änderungen und Zuständigkeiten sauber geregelt sind.
Welche Risiken werden bei solchen Projekten häufig unterschätzt?
Oft unterschätzt werden unklare Datenformate, Sonderfälle in Dokumentenprozessen und Abhängigkeiten zu bestehenden Systemen. Ebenfalls kritisch sind fehlende Regeln für den Umgang mit technischen Fehlern und fachlichen Ausnahmen. Wenn diese Punkte erst spät sichtbar werden, steigt der Abstimmungs- und Korrekturaufwand deutlich. Sinnvoll ist deshalb, Risiken früh zu benennen, Testfälle aus realistischen Eingangssituationen abzuleiten und die Beobachtbarkeit des späteren Betriebs von Anfang an mitzudenken.
Was muss der spätere Betrieb eines solchen Systems leisten?
Im Betrieb muss die Lösung Eingänge verarbeiten, Fehler erkennbar machen und Änderungen kontrolliert aufnehmen können. Dafür braucht es in der Regel klare Zuständigkeiten, aussagekräftige Protokolle und einen strukturierten Umgang mit Störungen. Auch Sicherheits- und Datenschutzfragen sollten für den jeweiligen Einsatzkontext geprüft werden; die rechtliche Bewertung sollten die zuständigen Stellen übernehmen. Technisch ist wichtig, dass Bereitstellungen nachvollziehbar bleiben und Anpassungen den laufenden Ablauf möglichst wenig beeinträchtigen.
