Vendor-Lock-in entsteht selten durch böse Absicht. Er wächst still: durch fehlende Exportformate, undokumentierte APIs, Betriebswissen, das nur der Dienstleister hat. Die Prävention beginnt vor der Unterschrift.

Was in jeden Vertrag gehört

Datenexport in offenen, dokumentierten Formaten ist keine Kür. Sie ist Pflicht — nicht „auf Nachfrage irgendwie“, sondern mit Schema, Testverfahren und Liefertermin bei Kündigung.

API-Versionierung und SLAs für Breaking Changes. Wer das nicht vertraglich sichert, erfährt beim nächsten Update, dass die eigene Integration still gebrochen wurde.

Hosting- und Subprozessor-Transparenz ab Vertragsunterzeichnung — nicht erst wenn die Aufsicht fragt. Cloud-Standorte und Unterauftragnehmer gehören ins Pflichtenheft.

Übergabepaket bei Kündigung: Zeitplan, Datenlieferung, Qualitätskriterien. Das verhandelt sich vor Vertragsabschluss — nicht im Streitfall.

Standardformate wie CSV, OGC oder DCAT schlagen proprietäre Alles-aus-einer-Hand-Versprechen. Im Einkauf mag das Gegenteil billiger aussehen. In Jahr vier nicht mehr.

Exit-Übungen, bevor es wehtut

Ein jährlicher Test-Export und -Import in eine neutrale Umgebung kostet einen halben Tag. Er zeigt, ob die Exportklausel im Vertrag auch wirklich funktioniert.

Automatische Backups allein sagen nichts. Restore-Tests sagen alles. Wer nicht regelmäßig prüft, ob die Wiederherstellung im vereinbarten Zeitfenster klappt, hat kein Backup — er hat eine Hoffnung.

Integrationscode muss im eigenen Repository liegen, nicht nur beim Dienstleister. Sonst ist beim Wechsel das technische Know-how weg.

Monitoring lose koppeln: Je proprietärer das Dashboard, desto stärker die emotionale Bindung — und desto höher der wahrgenommene Wechselschmerz.

Open Source als Druckventil — aber realistisch

Open Source reduziert Lizenzrisiko. Es reduziert nicht das Integrationsrisiko. Budgetieren Sie beides.

Community-Gesundheit prüfen: Wer pflegt den Code aktiv? Wie schnell werden Sicherheitslücken geschlossen? Gibt es eine realistische Roadmap? Eine verwaiste Open-Source-Lösung ist teurer als ein gepflegtes kommerzielles Produkt.

Dual-Vendor-Fähigkeit als Ziel: Zumindest theoretisch einen zweiten Integrator benennen können. Das ist keine Übung in Misstrauen — es ist Verhandlungsposition.

Ein 14-Tage-Pilot mit kleinem Scope zeigt Lock-in-Risiken früh. Was sich im Test nicht exportieren lässt, lässt sich im Betrieb nicht exportieren.

Wie Sie den Stadtrat überzeugen

Das Bild funktioniert ohne Fachbegriffe: „Wir wollen in fünf Jahren noch wählen können, welcher Anbieter liefert — wie ein Supermarkt, der nicht vom einzigen Bäcker abhängt.“

Zeigen Sie die Kostenkurve: Frühe Investition in offene Standards vermeidet eine spätere Großmigration. Die Kurve ist oft umgekehrt J-förmig — billiger Einstieg, teures Ende.

Jeder Vertrag braucht eine verständliche Managementzusammenfassung. Juristendeutsch ohne Kurzfassung führt dazu, dass Entscheider unterschreiben, ohne die Implikationen zu kennen.

Lock-in ist kein IT-Risiko. Es ist ein Haushaltsrisiko. Das ist die Sprache, in der Stadtrat und Kämmerei entscheiden.

Erster Schritt

Inventarisieren Sie Ihre drei kritischsten Systeme. Für jedes: Können Sie heute die Daten vollständig exportieren? Gibt es einen dokumentierten Plan B? Wenn nicht — das ist die Verhandlungsaufgabe für die nächste Vertragsverlängerung.

Weiterführende Quellen

• Interoperable Europe — Europäischer Rahmen für Datenportabilität und Interoperabilität
• Bitkom — Leitfaden Open Source in der öffentlichen Verwaltung
• CKAN — Open-Source-Datenportal für öffentliche Daten (Referenzplattform)

Das ist kein Betriebsmodell. Es ist ein Ausfall in Zeitlupe.

Smart-City-Projekte scheitern seltener am Start als im zweiten und dritten Jahr. Dann, wenn das Projektbudget aufgebraucht ist, das Interesse der Politik nachlässt und die wenigen, die das System kennen, in Urlaub fahren.

Vom Projektbudget zum laufenden Etat

Go-live ist der erste Tag des Betriebs — kein Abschluss. Wer das im Haushalt nicht abbildet, merkt es im zweiten Jahr: Zertifikate ablaufen lassen, keine Testumgebung mehr, Monitoring-Lizenz nicht verlängert.

Konkrete Betriebsposten, die in den Haushalt gehören:

• Personal für Second-Level-Support — benannt, budgetiert
• Wartungsverträge mit Dienstleistern
• Testumgebungen — separat vom Produktivsystem
• Monitoring-Lizenzen und -Werkzeuge
• Schulungsbudget für neue Mitarbeitende

Übersetzen Sie das in Bürgersicht: Ein nicht erreichbares Formular ist dasselbe wie ein geschlossener Schalter. Der Unterschied: Der geschlossene Schalter hat ein Schild. Das offline-Formular hat keins.

Service Level: Kleine Ziele, große Wirkung

Ein Service Level Agreement muss keine Bibliothek sein. Zwei bis drei messbare Ziele reichen für den Anfang:

• Kritische Dienste innerhalb von vier Stunden wiederhergestellt (werktags)
• Erstkontakt bei Störung innerhalb von 30 Minuten
• Monatliche Verfügbarkeit der Kernformulare über 99 Prozent

Diese Ziele müssen alle kennen — auch samstags, wenn eine Störung über soziale Medien bekannt wird und der verantwortliche Techniker im Dunkeln tappt.

Politische Kommunikation bei Störungen braucht eine Standardformel: „Es gab eine Störung. Ursache war X. Maßnahme ist Y. Behoben bis Z.“ Kurz, sachlich, ohne Schuldzuweisung.

KPIs, die wirklich zählen, messen Bürgererfahrung: erfolgreiche Transaktionen, Abbruchquoten, Wartezeiten. Nicht nur Servergrün.

Wissenssicherung: Betrieb lebt in Runbooks, nicht in Köpfen

Drei Seiten pro kritischem Dienst reichen oft: Wie kommt man rein? Wo liegen die Logs? Was sind typische Fehlerbilder? Wer wird im Fehlerfall angerufen?

Ohne diese Dokumentation ist jeder Urlaub einer Schlüsselperson ein ungeplanter Systemurlaub.

Zwei Maßnahmen verhindern dieses Muster systematisch:

Paarbearbeitung: Incidents werden immer von zwei Personen bearbeitet — eine zuständig, eine lernend. Das verteilt Wissen ohne Schulungstag.

Quartals-Lieferantengespräch: Fester Termin, feste Agenda: Sicherheitsupdates, Roadmap, Abhängigkeiten. Nicht nur bei Vertragsverlängerung.

Backup-Tests sind Pflicht. Wer sie nur auf Papier hat, scheitert beim ersten echten Restore. Ein Test pro Quartal kostet zwei Stunden und spart eine Krisenwoche.

Politische Führung ohne Mikromanagement

Der Stadtrat braucht keine Portnummern. Er braucht Klarheit über drei Fragen: Wie hoch ist das aktuelle Risiko? Was kostet der Betrieb nächstes Jahr? Welche technischen Schulden haben wir?

Ein jährlicher Betriebsbericht auf zwei bis drei Seiten reicht. Er schützt vor Überraschungen vor Wahlen. Transparenz über Schulden ist keine Schwäche — sie ist Steuerungsgrundlage.

Priorisierung ist ein politischer Akt. Nicht alles kann gleichzeitig stabil sein. Eine sichtbare Roadmap — was wird dieses Jahr gesichert, was wird verschoben — reduziert Erwartungsdruck.

Konkrete Schritte für stabile Systeme

• Alle produktiven Dienste inventarisieren: fachlicher Eigentümer und Kostenstelle je System
• Minimal-SLA je bürgersichtbarer Anwendung definieren und intern üben
• Runbooks und Zugriffskonzepte dokumentieren; Paarbearbeitung bei Incidents einführen
• Betriebskosten als feste Zeile im Haushalt verankern
• Jährlichen Betriebsbericht mit KPIs und Schuldenstand politisch besprechen

Weiterführende Quellen

• KGSt — Digitale Kommune: Steuerung und Betrieb
• Bitkom — Smart City: Leitlinien und Praxisberichte
• Normenkontrollrat — Gutachten zur Verwaltungsdigitalisierung