Warum Digitalisierung in Kommunen oft scheitert – und was stattdessen hilft

Veröffentlicht am

Digitalisierung in Kommunen ist selten ein Erkenntnisproblem – sondern ein Umsetzungsproblem. Ziele sind meist klar: kürzere Bearbeitungszeiten, weniger Medienbrüche, bessere Auskunftsfähigkeit, zufriedenere Bürgerinnen und Bürger sowie Entlastung der Mitarbeitenden. Trotzdem enden Projekte nicht selten in Verzögerungen, Mehrkosten oder Lösungen, die im Alltag nur teilweise angenommen werden.

1. Digitalisierung wird als IT-Projekt verstanden

Ein häufiger Fehler ist, Digitalisierung primär als „Systemeinführung“ zu behandeln: Software auswählen, Schnittstellen planen, Rollout durchführen. Technik ist wichtig – aber sie ist fast nie der Engpass. Der Engpass liegt meist in Abläufen, Verantwortlichkeiten, Entscheidungswegen und der Frage, wie die neue Lösung tatsächlich in die tägliche Arbeit passt.

Praktischer Gegenvorschlag: Formuliere zu Beginn nicht nur Anforderungen an die Software, sondern auch an den Prozess. Was soll im Alltag messbar besser werden? Welche Arbeitsschritte entfallen, welche entstehen neu – und wer übernimmt sie?

2. Prozesse werden digitalisiert, ohne sie zu verbessern

Wenn ein analoger Ablauf eins zu eins in eine Maske übertragen wird, bleibt er oft genauso langsam, nur eben am Bildschirm. Digitalisierung ist dann lediglich „Elektrifizierung“. Wirkliche Effizienz entsteht erst, wenn Entscheidungen, Prüfschritte und Zuständigkeiten überprüft und sinnvoll vereinfacht werden.

Praktischer Gegenvorschlag: Vor dem Tool kommt die Prozessskizze. Ein einfacher Workshop mit Fachbereich, IT und Organisation (1–2 Stunden) reicht häufig, um Doppelprüfungen, unnötige Schleifen und unklare Zuständigkeiten sichtbar zu machen.

3. Unklare Verantwortlichkeiten und zu viele Stakeholder ohne Mandat

In vielen Kommunen sind Projekte bereichsübergreifend. Das ist normal – aber ohne klares Mandat wird es zäh. Wenn niemand verbindlich entscheiden darf, sammeln sich offene Punkte an, bis der Zeitplan kippt. Oft entsteht dann Druck, „irgendwie live zu gehen“, und die Qualität leidet.

Praktischer Gegenvorschlag: Benenne eine Product-Owner-ähnliche Rolle mit echter Entscheidungskompetenz (fachlich) und eine technische Gegenrolle (IT/Architektur). Nicht als zusätzliche Hierarchie, sondern als klare Verantwortung.

4. Anforderungen sind zu groß, zu früh und zu starr

Große Lastenhefte vermitteln Sicherheit, erzeugen aber häufig das Gegenteil: Man versucht, die gesamte Komplexität am Anfang zu „erschlagen“. In der Realität ändern sich Prioritäten, rechtliche Rahmenbedingungen, personelle Ressourcen – und plötzlich passt das ursprüngliche Pflichtenheft nicht mehr.

Praktischer Gegenvorschlag: Plane in Inkrementen. Starte mit einem klar abgegrenzten Nutzenfall („Minimum Viable Service“), der in wenigen Wochen echte Entlastung bringt. Danach iterativ erweitern.

5. Akzeptanz wird erst am Ende adressiert

Schulungen kurz vor Go-Live sind wichtig, aber häufig zu spät. Wenn Mitarbeitende nicht frühzeitig einbezogen werden, entstehen Schattenprozesse („wir machen das parallel weiter wie früher“), die lange nach dem Rollout bestehen bleiben.

Praktischer Gegenvorschlag: Arbeite mit Pilotbereichen. Ein kleiner Kreis testet früh, gibt Feedback und wird später Multiplikator. Das reduziert Widerstände und erhöht die Qualität der Lösung.

Ein pragmatischer Ansatz: Organisation, Prozess und IT zusammen denken

In der Praxis hat sich ein einfaches Dreieck bewährt:

  • Organisation: Rollen, Mandate, Entscheidungswege, Ressourcen
  • Prozess: Ablauf, Schnittstellen, Prüfschritte, Zuständigkeiten
  • IT: System, Daten, Integration, Betrieb und Sicherheit

Wenn eines der drei Elemente fehlt, wird es teuer: Entweder wird Technik eingeführt, die niemand nutzt, oder Prozesse bleiben kompliziert, oder der Betrieb ist nicht nachhaltig.

Fazit

Digitalisierung in Kommunen scheitert selten an fehlendem Willen. Häufig sind es strukturelle Ursachen: unklare Mandate, unverbesserte Prozesse, zu große Anforderungen und zu späte Einbindung. Der beste Schutz gegen diese typischen Stolpersteine ist ein inkrementelles Vorgehen mit klarer Verantwortung – und der Mut, zuerst den Prozess zu verstehen, bevor Software „fertig geplant“ wird.

← zurück zum Blog