Transferaufgaben zum Beratungsprozess

Fast jedes Wort des Auftrags ist interpretationsbedürftig. Das ist typisch für Aufträge, die aus einer Leitungsrunde heraus formuliert werden: Sie beschreiben ein Gefühl von Handlungsbedarf, aber noch keinen prüfbaren Auftrag.

Die zentrale Vorentscheidung steckt in „KI-gestützte Lösung“: Die Amtsleitung legt die Technologie fest, bevor geklärt ist, welches Problem gelöst werden soll. Das ist ein klassischer lösungsorientierter Auftrag – die Lösung sucht sich ihr Problem.

• Verengung der Analyse: Organisatorische Ursachen (unklare Zuständigkeiten, umständliche Formulare, fehlende Terminvergabe) geraten aus dem Blick, weil sie nicht „KI-fähig“ sind.
• Verlust der Ergebnisoffenheit: Eine Beratung, die nur noch klären darf, wie KI eingesetzt wird, kann nicht mehr neutral beraten.
• Weitere implizite Annahmen: Technik ist der Hebel für Bürgernähe; vier Wochen reichen für eine Entwicklung; die Beratung selbst soll entwickeln.
• Rechtliche Folgen werden ausgeblendet: Für KI-Anwendungen sind u. a. Datenschutz-Folgenabschätzung (Art. 35 DSGVO), die Anforderungen der EU-KI-Verordnung und die Beteiligung des Personalrats zu prüfen – das passt nicht in vier Wochen Entwicklung.

Nicht-Ziele schützen den Auftrag vor Ausweitung (Scope Creep) und nehmen Ängsten die Grundlage. Sie gehören ausdrücklich in den Auftrag:

• Es wird keine produktive KI-Anwendung entwickelt oder in Betrieb genommen.
• Es wird kein Produkt und kein Anbieter ausgewählt; Beschaffungsentscheidungen folgen erst nach der Bewertung.
• Es erfolgt keine verwaltungsweite Reorganisation; betrachtet werden ausgewählte Leistungen.
• Es wird keine Personalbedarfs- oder Stellenabbauplanung erstellt (wichtig für Personalrat und Beschäftigte).
• Es werden keine vollautomatisierten Einzelfallentscheidungen gegenüber Bürgerinnen und Bürgern konzipiert (vgl. § 35a VwVfG, Art. 22 DSGVO).
• Die Beratung trifft keine Entscheidungen; die Entscheidung über die Umsetzung bleibt bei der Amtsleitung.

1. 1

   Abgestimmter Beratungsauftrag

   Woche 1

   Ziele, Nicht-Ziele, Gegenstand, Rollen, Kennzahlen und Termine – schriftlich von der Amtsleitung bestätigt.

2. 2

   Ist-Analyse und Problemlandkarte

   Woche 1–2

   Prozessaufnahme der ausgewählten Leistungen mit Kennzahlen, Medienbrüchen und Ursachen; inklusive Stakeholderanalyse.

3. 3

   Bewertete Handlungsoptionen

   Woche 3

   Organisatorische, prozessuale und technische Optionen, bewertet nach Nutzen, Aufwand, Risiken und Muss-Kriterien (Datenschutz, KI-VO, Barrierefreiheit).

4. 4

   Entscheidungsvorlage mit Empfehlung

   Woche 4

   Empfohlenes Pilotvorhaben mit Zielwerten, Aufwand, Zeitplan, Risiken und nächsten Schritten; Präsentation und Übergabe an die Amtsleitung.

Die drei Sichtweisen werden den drei Dimensionen zugeordnet: Die Amtsleitung blickt auf den fachlichen Prozess als Ganzes, die Beschäftigten auf die Organisation der Zusammenarbeit, die IT auf die technische Infrastruktur.

Grundlage ist die Einfluss-Betroffenheits-Matrix. Die Einstellung entscheidet innerhalb eines Feldes über die Art der Ansprache: Kritische Stakeholder mit hohem Einfluss brauchen mehr Beteiligung, nicht weniger.

Bewertet wird auf einer Skala von 1 (sehr ungünstig) bis 5 (sehr günstig). Rechtliches Risiko und Betriebsfähigkeit gelten zusätzlich als Mindestanforderung: Wer hier mit 1 bewertet wird, scheidet unabhängig von der Summe aus.

Gewichtet ergibt sich für A ein Nutzwert von 3,1 und für B von 4,4. Der Abstand wirkt eindeutig – er entsteht aber fast vollständig aus den drei „weichen“ Kriterien. Verschieben Sie die Gewichte und beobachten Sie, wie schnell sich das Ergebnis dreht.

Ein Kriterium ist operationalisiert, wenn festgelegt ist, was gemessen wird, wie gemessen wird und welcher Messwert zu welcher Punktzahl führt. Das fehlt hier bei allen Kriterien:

• Innovationsgrad, Zukunftsversprechen, Präsentationsqualität: keine Messgröße, reine Einschätzung der bewertenden Person.
• Umsetzbarkeit: unklar, ob Zeit, Personalaufwand, Integrationsaufwand oder Risiko gemeint ist.
• Anschaffungskosten: als einziges Kriterium messbar, aber unklar, wie Euro-Beträge in Punkte übersetzt werden.
• Skala 1 bis 5: keine Beschreibung der Skalenstufen, keine Angabe, wer bewertet hat und auf welcher Datengrundlage.

Muss-Kriterien (K.-o.-Kriterien) werden vor der Gewichtung geprüft. Wer sie nicht erfüllt, scheidet aus – egal, wie viele Punkte er sonst sammelt. Es fehlen u. a.:

• Interessen der Beratung oder Anbieternähe: Kriterien wie Präsentationsqualität begünstigen Anbieter, mit denen die Beratung zusammenarbeitet oder bei denen Folgeaufträge winken.
• Prestige- und Imageinteresse der Leitung: Ein hoch gewichteter Innovationsgrad passt zu einem gewünschten „Leuchtturmprojekt“.
• Nachträgliche Rechtfertigung: Die Matrix kann gebaut worden sein, um eine bereits getroffene Vorentscheidung für B zu legitimieren.
• Vermeidung der Kostendiskussion: Mit 10 % Kostengewicht fällt nicht auf, dass B deutlich teurer ist.
• Fehlende Perspektiven: Interessen der Beschäftigten (Bedienbarkeit), der IT (Betrieb) und der Bürgerinnen und Bürger kommen gar nicht vor.

Stufe 1: Muss-Kriterien (erfüllt / nicht erfüllt) gemäß Teilaufgabe 3. Nur Varianten, die alle Muss-Kriterien erfüllen, werden in Stufe 2 bewertet.

Stufe 2: Gewichtete Soll-Kriterien mit festgelegter Messgröße:

Maßstab ist die Unterscheidung zwischen Beratung (analysieren, empfehlen, befähigen), zulässiger Umsetzungsbegleitung (unterstützen, vorbereiten, moderieren – unter Steuerung der Verwaltung) und operativer Verantwortung (entscheiden, anweisen, freigeben, nach außen vertreten). Operative Verantwortung gehört zur Verwaltung, weil sie dort demokratisch legitimiert und rechtlich verantwortet wird.

1. 1

   Konflikt beschreiben

   Schritt 1

   Es handelt sich um einen Sachkonflikt (Ziel- und Beurteilungskonflikt), nicht um einen Beziehungskonflikt: Geschwindigkeit und Entlastung stehen gegen Qualität und Rechtssicherheit. Verschärft wird er durch den Zeitdruck der Amtsleitung, die den Konflikt nicht entscheidet, sondern nach unten weitergibt.

   Die Beratung beschreibt den Konflikt neutral und gibt ihn beiden Parteien zur Bestätigung zurück.

2. 2

   Interessen und Annahmen erfassen

   Schritt 2

   Nach dem Harvard-Konzept wird zwischen Positionen (was gefordert wird) und Interessen (warum es gefordert wird) unterschieden.

   Akteur	Position	Interesse	Zu prüfende Annahme
   Fachamt	Alles automatisch, 24 h	Entlastung, Rückstände abbauen, zufriedene Antragsteller	Alle Anträge sind gleich gut automatisierbar
   IT	Vollautomatisierung zu riskant	Stabiler Betrieb, keine Fehlentscheidungen, Haftung vermeiden	Die Datenqualität ist durchgängig unzureichend
   Amtsleitung	Schnell umsetzen	Sichtbarer Erfolg, politische Erwartungen erfüllen	Schnell und vollständig ist zugleich möglich

3. 3

   Daten- und Informationsbedarf bestimmen

   Schritt 3

   • Fallzahlen je Antragsart und heutige Bearbeitungsdauer
   • Anteil vollständiger und fehlerfreier Anträge; typische Fehlerarten
   • Welche Entscheidungen sind gebunden, welche enthalten Ermessen oder Beurteilungsspielraum?
   • Rechtsgrundlage: Ein vollständig automatisierter Verwaltungsakt ist nach § 35a VwVfG nur zulässig, wenn eine Rechtsvorschrift ihn erlaubt und weder Ermessen noch Beurteilungsspielraum besteht; zusätzlich Art. 22 DSGVO
   • Welche Datenquellen und Prüfregeln liegen vor, wie zuverlässig sind sie?
4. 4

   Handlungsoptionen entwickeln

   Schritt 4

   • O1 Vollautomatisierung aller Anträge (Position des Fachamts)
   • O2 Automatische Vorprüfung: Vollständigkeit und Plausibilität werden automatisch geprüft, die Entscheidung trifft ein Mensch (Human in the Loop)
   • O3 Segmentierte Dunkelverarbeitung: einfache, gebundene Fälle mit guter Datenqualität vollautomatisch, alle übrigen in der Sachbearbeitung
   • O4 Erst Datenqualität verbessern: Pflichtfelder und Prüfungen bereits im Antragsportal, danach schrittweise Automatisierung
5. 5

   Folgen und Risiken bewerten

   Schritt 5

   Option	Tempo	Rechtsrisiko	Qualität	Aufwand
   O1 Vollautomatisierung	hoch	sehr hoch	gering	hoch
   O2 Vorprüfung	mittel	gering	hoch	mittel
   O3 Segmentierung	hoch für einfache Fälle	gering bis mittel	hoch	mittel
   O4 Datenqualität zuerst	zunächst gering	gering	langfristig sehr hoch	mittel

6. 6

   Entscheidung vorbereiten

   Schritt 6

   In einem gemeinsamen Termin mit Fachamt, IT und Amtsleitung wird eine Entscheidungsvorlage vorgestellt. Empfohlen wird die Kombination aus O2, O3 und O4 als Stufenplan:

   1. Sofort: automatische Vorprüfung für alle Anträge, Verbesserung der Eingabeprüfung im Portal.
   2. Pilot: Dunkelverarbeitung für eine einfache, gebundene Antragsart; Zielwert z. B. 80 % dieser Fälle in 24 Stunden.
   3. Ausweitung auf weitere Antragsarten nur nach messbarem Nachweis von Fehlerquote und Datenqualität.

• Definition der Statusfarben: Ab welchen Abweichungen gilt gelb oder rot? Ohne Schwellenwerte ist „grün“ eine Meinung.
• Auswirkung der Terminverschiebungen auf den kritischen Pfad und den Endtermin
• Kostenprognose bis Projektende (Estimate at Completion) und Deckung im Haushalt
• Liste der offenen Anforderungen mit Priorität, Ursache und Auswirkung auf Abnahme und Betrieb
• Testnachweise: Testabdeckung, Fehler nach Schweregrad, Ergebnis der letzten Testzyklen
• Risikoregister mit Bewertung und Maßnahmen
• Gründe der fehlenden Beteiligung der Fachseite und verfügbare Kapazitäten
• Trend: Entwicklung der Kennzahlen über die letzten Berichtszeiträume

1. Nach welchen Kriterien haben Sie den Status als „grün“ bewertet?
2. Welche Auswirkungen haben die verschobenen Meilensteine auf den Go-live-Termin?
3. Wodurch sind die Mehrkosten von 15 % entstanden, und wie entwickeln sie sich bis zum Projektende?
4. Welche Anforderungen sind offen, und bis wann werden sie mit welchen Ressourcen umgesetzt?
5. Welche Tests wurden durchgeführt? Legen Sie Testprotokolle und Fehlerstatistiken vor.
6. Welche Risiken sehen Sie, die bislang nicht berichtet wurden?
7. Was benötigen Sie von der Fachseite, um den Plan einzuhalten?

Angemessen ist Rot. Jede Abweichung für sich würde mindestens Gelb rechtfertigen; zusammen betreffen sie alle Dimensionen des magischen Dreiecks (Zeit, Kosten, Qualität und Umfang). Eine Kostenüberschreitung von 15 % liegt über üblichen Toleranzen von etwa 10 %, und ohne Testnachweise ist die Qualität nicht belegt. Das Projekt kann die Ziele ohne Eingriff der Leitung voraussichtlich nicht erreichen.

Erforderlich ist sofort Stufe 2: Der Lenkungskreis muss über Budget, Termine und Umfang entscheiden – das kann die Projektleitung nicht allein. Stellt sich heraus, dass die bewilligten Haushaltsmittel nicht ausreichen, ist Stufe 3 einzuleiten, weil dann über- oder außerplanmäßige Mittel bzw. ein politischer Beschluss nötig werden.

Vorzubereiten ist eine Entscheidung des Lenkungskreises über die Fortführung des Projekts auf neuer Grundlage. Dazu gehören:

• Ein unabhängiges Projekt-Review als Grundlage (kurzfristig, z. B. zwei Wochen)
• Neue Planungsgrundlage (Re-Baselining) mit realistischen Terminen und Kosten oder Reduktion des Umfangs
• Verbindliche Testnachweise als Voraussetzung für weitere Zahlungen an den Dienstleister
• Freistellung und feste Zuordnung von Personal der Fachseite
• Neue Statusdefinition mit Schwellenwerten und unabhängiger Berichterstattung
• Als Rückfallposition: Unterbrechung des Projekts, falls das Review keine tragfähige Fortführung ergibt

Das Projekt wird überarbeitet: Das Quality Gate gilt als nicht bestanden, der Pilotstart wird verschoben, bis die beiden Sicherheitsprüfungen durchgeführt und kritische Befunde behoben sind und die Betriebsorganisation mindestens für den Pilot steht. Für die Nacharbeit wird ein fester Termin für ein erneutes Gate gesetzt.

• Sicherheit ist ein Muss-Kriterium. Ein Pilot arbeitet mit echten Daten und echten Nutzenden; Sicherheitslücken lassen sich im Nachhinein nicht „zurückholen“.
• Versprechen sind keine Nachweise. Die Zusage des Dienstleisters verschiebt das Risiko auf die Verwaltung. Ein Gate prüft Nachweise, keine Absichten.
• Positive Nutzertests und dokumentierte Muss-Anforderungen zeigen, dass das Projekt grundsätzlich tragfähig ist – deshalb weder Pause noch Abbruch.
• Dokumentiert heißt nicht umgesetzt: Für das erneute Gate ist nachzuweisen, dass die Muss-Anforderungen auch getestet sind.

Die vier Bestandteile entsprechen dem Muster Gegeben – Wenn – Dann – Gemessen an. So wird jedes Kriterium zu einem Testfall, den beide Vertragsparteien gleich verstehen.

45 Minuten reichen nicht, um Wissen zu erheben – sie reichen aber, um vorbereitete Ergebnisse zu bestätigen und Verantwortliche festzulegen. Deshalb wird der Abschluss in drei Teile zerlegt. Das Wissen der ausscheidenden Person wird nicht im Workshop, sondern vorab in einem eigenen Termin gesichert.

• Wissensinterview mit der ausscheidenden Person (60–90 Minuten, durch die Projektleitung): laufende Aufgaben, Ansprechpersonen, Stolpersteine, Ablageorte, nicht dokumentierte Absprachen. Ergebnis: eine Übergabenotiz.
• Abschluss-Onepager als Entwurf: Ziele und Zielerreichung, offene Punkte, Risiken.
• Lessons-Learned-Abfrage vorab: drei Fragen, schriftlich an alle Teammitglieder.

1. 1

   Einstieg und Ziel

   0–3 min

   Ziel: Ergebnisse bestätigen, Offenes übergeben, Verantwortliche festlegen. Kein neues Sammeln.

2. 2

   Wichtigste Projektergebnisse

   3–10 min

   Durchgang durch den Onepager: Ziel für Ziel als erreicht, teilweise erreicht oder nicht erreicht markieren.

3. 3

   Nicht erreichte Ziele und offene Risiken

   10–20 min

   Für jedes offene Ziel und jedes Risiko: Wie geht es weiter? Ins Folgeprojekt, in die Linie oder bewusst verwerfen?

4. 4

   Übergabe und Wissen der ausscheidenden Person

   20–28 min

   Die ausscheidende Person stellt ihre Übergabenotiz vor; Nachfolgende bestätigen die Übernahme. Übergabe an Betrieb und Folgeprojekt.

5. 5

   Lessons Learned

   28–38 min

   Vorab gesammelte Antworten werden geclustert; per Punktabfrage die drei wichtigsten Erkenntnisse für das Folgeprojekt auswählen.

6. 6

   Verantwortlichkeiten und Ablage

   38–45 min

   Maßnahmenliste mit Wer, Was, Bis wann; Speicherort aller Ergebnisse festlegen und Abschluss erklären.

• Ergebnisprotokoll (eine Seite) innerhalb von zwei Arbeitstagen an alle Beteiligten und die Amtsleitung
• Formale Übergabe der offenen Punkte an die Projektleitung des Folgeprojekts
• Lessons Learned werden im Kick-off des Folgeprojekts erneut aufgerufen

Die Unterscheidung geht auf Argyris und Schön zurück; das Deutero-Learning auf Bateson. Je weiter außen die Schleife, desto tiefer greift das Lernen in die Organisation ein.

• Transfer als Übergabe von Dokumenten verstanden: Übertragen wurde nur explizites Wissen. Das Erfahrungswissen der Beratung – wie man Störungen erkennt, was man in welcher Reihenfolge tut – blieb bei ihr.
• Zu spät: Der Transfer fand erst am Projektende statt, statt das Projekt zu begleiten.
• Kein eigenes Tun: Die Beschäftigten haben die Lösung nie selbst betrieben; Zuhören in einer Präsentation erzeugt keine Handlungskompetenz.
• Unklare Empfänger: Es war nicht festgelegt, wer die Lösung künftig betreibt und welche Kompetenzen diese Personen brauchen.
• Kein Nachweis: Ein Abnahmekriterium für den Wissenstransfer fehlte; also wurde der Transfer auch nicht geprüft.
• Sicherheitsproblem: Eine Liste von Zugangsdaten ersetzt kein Berechtigungs- und Betriebskonzept.

Das SECI-Modell von Nonaka und Takeuchi beschreibt Wissensentstehung als Spirale zwischen implizitem und explizitem Wissen. Im Fall wurde fast nur die Kombination bedient:

Unzureichend waren vor allem Sozialisation und Internalisierung, teilweise auch die Externalisierung.

Der Bericht ist umfangreich, aber nicht entscheidungsreif. Er beschreibt, was möglich wäre, nicht was die Kommune tun sollte. Der Zweck einer Beratung – die Auftraggeberin entscheidungsfähig zu machen – ist damit verfehlt. Als Bestandsaufnahme und Ideensammlung ist er verwertbar; als Strategie ist er in der vorliegenden Form nicht abnahmefähig.

1. Keine Priorisierung: 84 gleichrangige Maßnahmen sind keine Strategie, sondern eine Liste. Abhängigkeiten und Reihenfolge fehlen.
2. Keine Betriebsfolgen: Personalbedarf, laufende Kosten und Auswirkungen auf den IT-Betrieb sind unbekannt; eine Wirtschaftlichkeitsbetrachtung ist so nicht möglich.
3. Keine Abnahmekriterien: Weder Bericht noch Maßnahmen sind prüfbar; Erfolg lässt sich später nicht messen.
4. Keine Entscheidungsempfehlung: Die Verantwortung für die Auswahl wird an die Amtsleitung zurückgegeben, ohne ihr eine Grundlage zu geben.
5. Zielarchitektur zu allgemein: Kein Bezug zur vorhandenen IT-Landschaft und zur konkreten Leistung; der Weg vom Ist zum Soll fehlt.
6. Technologieempfehlungen ohne Herleitung: Ohne Bewertung von Alternativen drohen Vorentscheidungen und Anbieterbindung.
7. Nutzersicht fehlt: Wie sich die Leistung für Bürgerinnen, Bürger und Beschäftigte verbessert, bleibt offen.

1. 1

   Nachbesserung einfordern

   2 Wochen

   Bericht nur unter Vorbehalt annehmen. Auf Grundlage des Vertrags verlangt die Kommune eine Priorisierung, eine Bewertung der Betriebsfolgen für die Top-Maßnahmen und eine klare Empfehlung.

2. 2

   Priorisierungsworkshop

   1 Tag

   Mit Fachbereich, IT, Personalrat und Datenschutz werden die Maßnahmen geclustert und nach Nutzen, Aufwand, Risiko und Abhängigkeiten bewertet. Ergebnis: eine erste Umsetzungsstufe mit fünf bis zehn Maßnahmen.

3. 3

   Entscheidungsvorlage erstellen

   3 Wochen

   Für die erste Stufe werden Kosten, Betriebsfolgen, Abnahmekriterien und Verantwortliche ermittelt und der Amtsleitung zur Entscheidung vorgelegt.

Gate-Verantwortung: Amtsleitung. Entscheidungsoptionen: Freigabe, Freigabe mit Auflagen, Nacharbeit, Stopp. Ohne bestandenes Gate beginnt keine Umsetzung.

• Eigenes Kernteam: Beschäftigte der Verwaltung arbeiten in jeder Phase mit (Tandems), statt nur Ergebnisse zu empfangen.
• Strukturierte Ablage: Bericht, Entscheidungen und Begründungen in der E-Akte; ein Entscheidungslog macht nachvollziehbar, warum etwas entschieden wurde.
• Wissenstransfer als Vertragsleistung mit überprüfbarem Abnahmekriterium (vgl. Aufgabe 13).
• Lessons-Learned-Kreislauf: Erkenntnisse zentral auswerten und im Kick-off folgender Vorhaben verbindlich prüfen.
• Kompetenzaufbau: Schulungen in Anforderungs- und Vertragsmanagement, damit die Verwaltung Beratung künftig selbst steuern und abnehmen kann.