Behördensoftware 1995 Kritik: Rückblick mit klarem Urteil

Stolz auf die Digitalisierung von Amtswegen? Wer glaubt, dass Behördensoftware 1995 irgendetwas mit Innovation zu tun hatte, der hat entweder nie damit gearbeitet – oder die Erinnerung erfolgreich verdrängt. In diesem Artikel gibt’s einen schonungslosen Deep Dive in den digitalen Sumpf deutscher Behörden anno 1995. Wir sezieren Technik, Prozesse, UX und Sicherheitsstandards – und das Urteil fällt klarer aus, als jeder Fördermittelantrag aus dieser Zeit. Willkommen beim Realitätsabgleich, den die IT-Lobby nie wollte.

• Warum Behördensoftware 1995 fast alles falsch machte – technisch, konzeptionell und organisatorisch
• Die größten technischen Schwächen: von Mainframes bis zu aufgedunsenen Client-Server-Monstern
• UX-Desaster als System: Usability war ein Fremdwort, Nutzerfreundlichkeit ein Betriebsunfall
• Datensicherheit, Datenschutz und Schnittstellen: eine Farce mit System
• Wie Behörden den digitalen Anschluss verpassten – und warum das bis heute nachwirkt
• Der Einfluss von politischen Lobbys, Ausschreibungen und IT-Dienstleistern auf das Scheitern
• Step-by-Step: Typische Fehlerketten bei Softwareeinführung in Behörden
• Lessons learned und die gefährliche Kontinuität des Versagens
• Warum ein ehrlicher Blick zurück Pflicht ist, um die digitale Zukunft nicht erneut zu verhauen

Wer 1995 in einer deutschen Behörde mit Software zu tun hatte, weiß: Das war kein digitales Zeitalter, sondern ein Digitalisierungsfeigenblatt erster Güte. Die bittere Wahrheit: Behördensoftware war damals ein Paradebeispiel dafür, wie man es nicht macht. Überteuerte Ausschreibungen, archaische Technik, fehlende Schnittstellen, Usability-Albträume und Sicherheitskonzepte aus der Zeit von BTX – all das war Standard und nicht Ausnahme. Dieser Artikel liefert nicht die weichgespülte Rückblende auf “Pioniergeist”, sondern eine ehrliche, tiefgründige und gnadenlose Kritik an Behördensoftware 1995. Damit niemand mehr behaupten kann, man hätte es nicht besser wissen können.

Behördensoftware 1995: Technische Rückständigkeit als Systemfehler

Reden wir nicht um den heißen Brei: Die technische Basis von Behördensoftware 1995 war eine Katastrophe. Während in der freien Wirtschaft bereits Client-Server-Architekturen, frühe Webanwendungen und relationales Datenbankmanagement den Ton angaben, war in deutschen Amtsstuben der Mainframe König – und das war selten ein Fortschritt, sondern meist ein Bremsklotz. COBOL, Natural, Adabas und Lotus Notes bestimmten das Bild. Modernisierung? Nur, wenn der Wartungsvertrag auslief oder die Hardware wortwörtlich abbrannte.

Die meisten Anwendungen liefen auf sogenannten Fat Clients – meist Windows 3.1 oder OS/2-Kisten, die über Token-Ring-Netzwerke notdürftig verbunden wurden. Daten wurden über proprietäre Protokolle wie SNA oder X.25 geschoben, und wehe, es gab einen Ausfall im Rechenzentrum. Backups? Klar, auf Bandlaufwerken, die so zuverlässig waren wie das Faxgerät im Nachbarbüro. Das Ergebnis: Regelmäßige Totalausfälle, Datenverluste und ein Support, der vor allem aus Schulterzucken bestand.

Was wirklich fehlte, waren offene Schnittstellen. Die wenigsten Anwendungen konnten miteinander sprechen. Wer etwa Daten zwischen Einwohnerwesen, Gewerberegister und Kassenbuchhaltung übertragen wollte, musste sich mit selbstgebauten Export-Import-Skripten begnügen – meist als CSV auf Diskette. Die Folge: Medienbrüche, Fehlerquellen und ein Aufwand, der jedem IT-Architekten die Tränen in die Augen treibt. Integration, Automatisierung, offene Standards? Fehlanzeige – weil niemand bereit war, die Systeme sauber zu dokumentieren oder gar abzulösen.

Die Auswirkungen dieser technischen Rückständigkeit waren dramatisch. Prozesse, die automatisierbar gewesen wären, blieben manuell. Fehler wurden zum Alltag, weil niemand die Systeme ganz verstand. Und jede Migration wurde zum Millionenprojekt, das Jahre dauerte und am Ende meist doch wieder nur eine kosmetische Verbesserung brachte. Wer 1995 auf “digitale Verwaltung” hoffte, bekam stattdessen einen Lehrpfad in Sachen Legacy-Desaster.

Usability-Hölle: Nutzerfreundlichkeit als Betriebsunfall

Wenn es einen Begriff gibt, der in der Welt der Behördensoftware 1995 nicht vorkam, dann ist es “Usability”. Die Benutzeroberflächen waren ein Verbrechen an der Mensch-Maschine-Interaktion. Graue Fenster, kryptische Kürzel, menügeführte Labyrinthe und Dialogboxen, die mit “OK” und “Abbrechen” alles gesagt zu haben glaubten. Wer als Sachbearbeiter auf Effizienz hoffte, wurde eines Besseren belehrt: Jeder Klick war ein Abenteuer, jeder Fehler ein Absturzrisiko.

Es gab keine einheitlichen Bedienkonzepte. Jede Fachanwendung hatte ihre eigene Philosophie, ihre eigenen Shortcuts und ihre speziellen Workarounds – oft nur dokumentiert im Kopf des einen Kollegen, der bald in Rente ging. Tooltips, Hilfetexte, Undo-Funktionen? Luxus, den man aus der Privatwirtschaft kannte, aber nie zu Gesicht bekam. Stattdessen: ellenlange Handbücher, die so unverständlich waren wie die Gesetzestexte, auf denen die Software basierte.

Das Onboarding neuer Mitarbeiter war ein Martyrium. Ohne wochenlange Schulungen und “Learning by Doing” war keine effiziente Arbeit möglich. Fehler wurden systematisch provoziert, weil die Software keine Fehlertoleranz kannte. Wer versehentlich im falschen Menü landete, durfte Daten neu eingeben, weil Rückgängig-Funktionen schlicht nicht vorgesehen waren. Nutzerfeedback? Gelangte selten bis zur Entwicklungsabteilung, weil Änderungsanträge bürokratisch im Sande verliefen. Die Folge: Frust, Arbeitszeitverschwendung und eine digitale Kultur, die Innovation schon im Keim erstickte.

Dieses UX-Desaster war kein Zufall, sondern die Folge von Ausschreibungen, bei denen der billigste Anbieter gewann – und der wusste, dass Nutzerfreundlichkeit kein Kriterium war. Hauptsache, das Lastenheft war formal korrekt abgearbeitet. Ob die Anwendung in der Praxis benutzbar war, interessierte niemanden – und so wurde aus Usability ein Betriebsunfall, den die Nutzer auszubaden hatten.

Datensicherheit, Datenschutz und Schnittstellen: Willkommen im digitalen Mittelalter

Wer glaubt, dass IT-Security in Behörden ein Thema war, hat sich geschnitten. 1995 waren Passwörter oft vierstellig und wurden auf Zetteln unter der Tastatur verwahrt. Zugriffskontrollen existierten, aber meistens nur auf dem Papier. Die meisten Systeme setzten auf proprietäre Authentifizierung, oft ohne Verschlüsselung. Datenübertragungen liefen im Klartext über Hausleitungen. Firewalls? Luxus, den man sich für “kritische Systeme” aufhob – der Rest durfte durchs LAN vagabundieren.

Das Thema Datenschutz wurde zwar hochgehalten, praktisch aber durch technische Unzulänglichkeiten konterkariert. Protokollierung? Ja, aber meistens so, dass niemand sie auswerten konnte. Löschkonzepte? Existierten, aber niemand war sich sicher, ob sie auch wirklich funktionierten. Die Folge: Datenlecks, versehentlich weitergegebene Personaldaten und ein Sicherheitsniveau, das im Vergleich zu heutigen Standards schlicht fahrlässig war.

Schnittstellen waren eine weitere Baustelle: Es gab sie kaum. Und wenn, dann waren sie so proprietär, dass nur der Hersteller selbst sie bedienen konnte. Datenexporte liefen oft über Disketten, später über ZIP-Drives oder Tape. Die Integration externer Systeme, etwa von Kommunen, Krankenkassen oder Landesämtern, wurde zum Albtraum. Formate wie EDIFACT, XÖV oder gar offene APIs waren Zukunftsmusik. Wer heute über “Interoperabilität” spricht, sollte sich vor Augen führen, dass Behörden 1995 von Datensilos lebten – und das gerne und aus voller Überzeugung.

Die Konsequenz: Ein Flickenteppich aus Einzellösungen, Insellösungen und Medienbrüchen, der jede Modernisierung zur Mammutaufgabe machte. Die technischen Schulden aus dieser Zeit belasten noch heute viele Behörden – und sind einer der Hauptgründe dafür, warum die Digitalisierung öffentlicher Verwaltung in Deutschland seit Jahrzehnten hinterherhinkt.

Politik, Ausschreibungen und Dienstleister: Das perfekte Rezept für IT-Versagen

Warum war Behördensoftware 1995 so schlecht? Weil das System es so wollte. Ausschreibungen wurden nach dem Prinzip “Wer am billigsten ist, gewinnt” vergeben. Funktionierende Lösungen wurden oft abgelehnt, weil sie nicht exakt den – meist fachfremd geschriebenen – Lastenheften entsprachen. Innovationen? Wurden als Risiko betrachtet. Wer eine moderne Architektur vorschlug, galt als Querulant. Die Folge: Stagnation als Systemmerkmal.

IT-Dienstleister, die sich auf Behörden spezialisiert hatten, lebten von Wartungsverträgen und Komplexität. Je undurchsichtiger die Lösung, desto länger die Bindung des Kunden. Proprietäre Standards wurden nicht nur toleriert, sondern gefördert – denn offene Schnittstellen hätten die Monopolstellung gefährdet. Behörden wurden so zu Geiseln ihrer eigenen Softwarelandschaft. Jeder Versuch, Systeme abzulösen, wurde zum Politikum, begleitet von Gutachten, Sub-Gutachten und jahrelangen Projektverzögerungen.

Die politischen Rahmenbedingungen taten ihr Übriges. Digitale Kompetenz in den Ministerien? Fehlanzeige. Projekte wurden von Juristen statt von IT-Architekten gesteuert. Kontrolle erfolgte über Kennzahlen wie “Anzahl der installierten Clients” statt über tatsächliche Produktivität oder Nutzerzufriedenheit. Wer als Entwickler auf Missstände hinwies, wurde als Bedenkenträger abgetan. Das Ergebnis: Ein digitaler Stillstand, der mit jedem Jahr schwerer zu überwinden war.

Und auch die Nutzer, also die Sachbearbeiter, hatten kaum Einfluss auf die Entwicklung. Änderungswünsche wurden nach dem Wasserfallprinzip gesammelt, priorisiert, verworfen und irgendwann vielleicht mal umgesetzt – wenn das Budget reichte. Agile Entwicklung? User-Centered Design? Das waren Fremdworte, die erst Jahrzehnte später Einzug hielten.

Step-by-Step: Typische Fehlerketten bei Software-Einführung in Behörden (1995-Edition)

• Lastenheft schreiben lassen: Meist von Fachabteilungen, die wenig Ahnung von IT-Architektur haben. Technische Anforderungen werden ignoriert, stattdessen wird jede Sonderlocke aufgenommen.
• Ausschreibung veröffentlichen: Nach VOL/A, mit Fokus auf Preis und Formalien statt auf Innovation oder Qualität. Anbieter passen sich an – und liefern das billigste technisch Machbare.
• Implementierung starten: Das System wird “customisiert”, bis es keiner mehr bedienen kann. Schnittstellen werden vergessen, Testdaten stammen aus den 80ern.
• Abnahme durch die Fachabteilung: Hauptsache, die Checkboxen im Pflichtenheft sind angehakt. Ob das System produktiv nutzbar ist, interessiert keinen.
• Produktivbetrieb: Nutzer werden notdürftig geschult, Bugs werden zu “Anwenderfehlern” erklärt, Support wird zur Blackbox.
• Wartung und Pflege: Updates kommen selten, kosten extra und beheben meist nur kosmetische Fehler. Jede Anpassung wird zum Großprojekt.
• Migrationsversuch nach Jahren: Die Software ist veraltet, Datenformate sind inkompatibel, Dokumentation gibt es nicht. Das Spiel beginnt von vorne – mit denselben Fehlern.

Lessons Learned & die gefährliche Kontinuität des Versagens

Was bleibt von Behördensoftware 1995? Eine lange Liste an Fehlern, die bis heute nachwirken. Der Drang zu proprietären Systemen, die Ignoranz gegenüber Usability, das Fehlen offener Schnittstellen und ein komplett verkorkstes Ausschreibungssystem – all das hat die Digitalisierung des Staates um Jahrzehnte zurückgeworfen. Wer heute noch auf Altlasten aus dieser Zeit trifft, weiß, dass jeder Versuch der Modernisierung gegen einen Berg historischer Fehlentscheidungen ankämpft.

Die größte Gefahr: Viele der damals etablierten Muster sind bis heute nicht verschwunden. Noch immer werden Ausschreibungen nach denselben Prinzipien durchgeführt. Noch immer fehlt es an technischer Kompetenz in der Steuerung. Noch immer haben Anbieter ein Interesse daran, Systeme möglichst undurchsichtig zu halten. Wer glaubt, die Probleme von Behördensoftware 1995 seien erledigt, irrt – sie sind nur besser versteckt. Ein kritischer Rückblick ist daher Pflicht, um nicht die Fehler der Vergangenheit zu wiederholen.

Fazit: Was 1995 schieflief – und warum Transparenz die einzige Rettung ist

Behördensoftware 1995 war der digitale Offenbarungseid eines Systems, das Digitalisierung als Kostenfaktor, nicht als Chance verstand. Die technische Rückständigkeit, die totale Missachtung von Nutzerbedürfnissen, das Versagen bei Datensicherheit und Interoperabilität – all das war kein Betriebsunfall, sondern strukturelle Konsequenz einer falsch gesteuerten Verwaltungs-IT. Wer die Digitalisierung des Staates heute ernst meint, muss die Fehler von damals schonungslos analysieren und echten Wandel zulassen.

Was bleibt, ist die Erkenntnis, dass Technologie allein kein Allheilmittel ist. Es braucht Mut zur Offenheit, zu ehrlicher Fehlerkultur und zu konsequenter Nutzerorientierung. Nur so wird aus digitaler Trägheit echte digitale Verwaltung. Und vielleicht, ganz vielleicht, verhindern wir so, dass die Behörden der Zukunft in zwanzig Jahren wieder Gegenstand eines solchen Artikels werden.