Digitalisierung der öffentlichen Verwaltung: Wie können wir für bessere Software sorgen?

 Die Leser:innen des Teamworkblog sind wahrlich anderes gewöhnt als diesen Beitrag! Normalerweise werden sie mit motivierenden Erfahrungsberichten und erfolgreich erprobten Methoden rund ums Thema „Agilität“ versorgt. Hier ist es umgekehrt: der Autor teilt seine Ratlosigkeit mit und wirbt für Unterstützung. Das Thema: „Warum ist die Software in der öffentlichen Verwaltung so schlecht?“ und „Was könnten wir tun, damit es besser wird?“

Ich bin Mitglied des Forums Agile Verwaltung und als solches wende ich mich an die Leserschaft des Teamworkblog, von denen sicher viele über Erfahrungen in Projekten der Softwareentwicklung und der Softwareeinführung in Unternehmen verfügen. Einer der vielen Faktoren, warum die Bundesrepublik in puncto digitaler Verwaltung weit hinter Ukraine und Albanien rangiert /Anmerkung 1/, liegt nun gerade auf diesem Gebiet: die Software, die dem öffentlichen Dienst angeboten wird, ist in ihrer Mehrheit katastrophal schlecht. 

Der „Market for lemons“

Im Frühjahr 2022 ist ein Buch unter dem Titel „Träge Transformation“ erschienen /Anmerkung 2/. Darin machen sich Sascha Friesike und Johanna Sprondel Gedanken über die Gründe, warum Digitalisierungsprojekte in der deutschen Verwaltung so schleppend verlaufen. Als einen Faktor machen sie die schlechte Qualität der angebotenen Software aus: „Es wird mit Zitronen gehandelt (es entsteht ein ‚market for lemons‘).“ (Seite 14)

Das deckt sich mit meinen eigenen Projekterfahrungen. Ich bringe zur Veranschaulichung zwei Beispiele aus Projekten zur Einführung von Dokumentenmanagementsystemen. In beiden Fällen hatte die Verwaltung schon ein DMS-Produkt beschafft, und ich sollte nun die Einführung in den einzelnen Abteilungen begleiten.

Beispiel 1:

Das DMS hat ein Modul zur Verarbeitung von Eingangsrechnungen. Aus jeder Rechnung wird u.a. der Lieferant ausgelesen, über eine Schnittstelle mit der Kreditorenliste im SAP abgeglichen und die Rechnung in eine „Lieferantenakte“ abgelegt. Die Verwaltung hat keine „Lieferantenakten“, sondern bildet für jede Beschaffung einen „Beschaffungsordner“. Dazu gehört eine Beschaffungs-ID, die der Lieferant auch in die Rechnung aufnimmt.

Also soll das DMS-Programm auf den SAP-Abgleich verzichten und stattdessen in der Rechnung nach einer Beschaffungs-ID mit der Namensmaske BA####### suchen. Der Lieferantenvertreter kriegt sichtbar einen Schreck. „Das ist aber weit weg vom Standard! Das kann bei uns nur der Herr Meyerbeer. Er hat das Modul programmiert und ist der einzige, der den Code kennt. Und bevor der Herr Meyerbeer einen Termin frei hat …“

Am Ende vom Lied braucht der Herr Meyerbeer drei Personentage, um diese Moduländerung manuell im Code zu ändern, und das Projekt verzögert sich um 5 Wochen.

Beispiel 2:

In einer anderen Verwaltung soll das DMS in der Bauabteilung eingeführt werden (ein anderes Produkt als in Beispiel 1). Für jeden Bauantrag eines Bürgers soll ein Vorgang angelegt werden (das kann die Software) und diesem Vorgang der Antragsteller und die offizielle Flurstücksnummer als hinterlegt werden (kann die Software nicht). Das Programm sieht nur vor, dass der Anwender in der Verwaltung diese Metadaten händisch eintippt – mit vielfachen Fehlermöglichkeiten.

Die Mitarbeiter:innen wollen, dass das Programm ihnen zwei Listen anbietet – eine Liste der Grundstückeigentümer aus der Katastersoftware, eine Liste der Flurstücke aus dem GIS -, um schneller und vor allem fehlerfrei arbeiten zu können.

Wieder schlägt der Ansprechpartner der Softwarefirma die Hände über dem Kopf zusammen. Bei allen 2000 Installationen in Deutschland sei ja so ein exotischer Wunsch noch nie vorgekommen! Wieder der Satz „weit weg vom Standard“. Und das müsse man händisch programmieren. Und bei jedem Update des Programms werde dieser individuelle Code wieder überschrieben und müsse nachträglich wieder eingefügt werden. Und der Dokumentationsaufwand! Also das könnten sie auf keinen Fall.

Das Ende vom Lied: Der IT-Leiter der Verwaltung macht sich die Argumente des Herstellers zu eigen und verzichtet auf die Programmerweiterung. Die Mitarbeiter:innen tippen immer noch Daten wie „Frau Dr. Elisabeth von Schönbrunn-Neuenfels“ und „HM2405/8901“ in ihre Verschlagwortungsmasken ein.

Mangelnde fachliche Kompetenz…

Wie kommt es, dass Software, die schon in den 1990er Jahren nicht den minimalen Qualitätsstandards an Objektorientierung genügte, heute noch ganz vorne auf dem öffentlichen Markt liegt? Denn die beiden Beispiele stammen aus dem Kreis der circa 6 Produkte, die sich wie ein Oligopol diesen Markt in Deutschland aufteilen.

Kommen wir zurück zum Buch „Träge Transformation“. Friesike und Sprondel nennen als einen wichtigen Faktor die fehlende Expertise der Entscheider: „Jeder, der ein soziotechnisches System verändern will, braucht Expertise sowohl darüber, was genau das technische Problem ist, als auch darüber, wie genau der soziale Kontext aussieht, in dem eben dieses Problem angegangen werden soll. Oft werden solche Projekte jedoch von Menschen geleitet, denen eben diese Kompetenzkombination fehlt.“ (Seite 14)

Und ich kann aus meinen Projekten ergänzen: Die Führungskräfte, die das Budget freigeben und die Auswahlkriterien festlegen, haben nicht nur meist keine Fachkenntnis. Auch Leiter von IT-Abteilungen sind nur sehr selten Informatiker. Meist sind sie Verwaltungsjuristen. Sie wissen gar nicht, wie man Anforderungen an Software entwirft. Sie haben keinerlei Projekterfahrung.

Aber noch viel wichtiger: Sie haben keinerlei Visionen über eine „gute Arbeitsumgebung der Zukunft“. Sie wissen gar nicht, was die Mitarbeiter:innen brauchen. Sie wissen nicht, wie sich digitales Arbeiten von der Arbeit in den herkömmlichen Papierbergen und auf chaotischen Windows-Servern unterscheidet. Sie reden viel über „Workflows“, die alle Probleme regeln sollen. Aber Wissensprozesse kommen in der Verwaltung genauso häufig vor wie die stupiden Kfz-Zulassungen. Dass aber Workflows für Wissensarbeiten nichts taugen, haben sie noch nie gehört.

…. führt zu trägen Software-Herstellern

Wenn die Entscheider aber keine Produktqualität von den Herstellern fordern können, weil sie gar nicht wissen, was Qualität beinhaltet, dann gibt es keinen Wettbewerb und das System wird träge. Die DMS-Firmen machen den Verwaltungen ein X für ein U vor. „Am Markt zeigt sich dann schnell, dass es sich gar nicht lohnt, das funktionierende U anzubieten, weil ja doch immer wieder das günstigere X gekauft wird.“ (Seite 14)

Was können wir tun?

Uns vom Forum Agile Verwaltung schwebt Folgendes vor: Wir würden gerne progressive Verwaltungsleute (das sind unsere Mitglieder und Follower unseres Blogs) mit engagierten Softwareexpert:innen zusammenbringen. Und zwar am Beispiel Dokumentenmanagement-Software, einfach um uns zu fokussieren. Wobei die Softwareexperten nicht unbedingt DMS-Erfahrung mitbringen müssen. Sie müssen nur zuhören können und analysieren und Ideen spinnen.

Das gemeinsame Ziel müsste sein: Eine Beschreibung (Vision, Prüfkriterien, User-Storys…) für eine gute DMS-Software der Zukunft erstellen. So als eine Art Zertifizierungsmaßstab. Daran könnten sich dann Leute in der Verwaltung orientieren, die Entscheidungen für DMS-Beschaffungen treffen. Und natürlich die künftigen Anwender:innen in der Verwaltung können von ihren Entscheidern entsprechende Produkte fordern. Und schließlich die Software-Anbieter und ihre Entwickler erhalten eine Richtschnur, wenn sie ihre Produkte auf den Stand der heutigen Technik bringen wollen.

Würde es die eine oder den anderen unter den Lesern dieses Blogs reizen, sich an so etwas zu beteiligen? Dann schreibt mir doch bitte ganz konventionell eine E-Mail an wolf.steinbrecher{ätt]agile-verwaltung.org. Und wir vom Forum Agile Verwaltung organisieren ein erstes Treffen.

Anmerkungen

/1/ Wer sich für den aktuellen Stand der Digitalisierung in Staat und Verwaltung der BRD interessiert, findet einen hervorragenden Überblick im Podcast „Lage der Nation“. Dieser hat im August 2022 zwei ausführliche Folgen dem Thema „Digitalisierung der deutschen Verwaltung“ gewidmet. Es ist der bestrecherchierte, mir bekannte Beitrag zum Thema.

Folge 301 vom 11.08.2022: https://lagedernation.org/podcast/ldn301-keine-weiteren-fragen-digitalisierung-der-deutschen-verwaltung-teil-1/

Folge 302 vom 25.08.2022: https://lagedernation.org/podcast/ldn302-baustellen-loesungen-digitalisierung-der-deutschen-verwaltung-teil-2/

/2/ Friesike, Sascha; Sprondel, Johanna: Träge Transformation. Welche Denkfehler den digitalen Wandel blockieren. Reclam, 2022, 92 Seiten, ISBN: 978-3-15-014188-5