IT-Strategie, die nicht in der Schublade landet: Was wirklich hineingehört

Dieser Beitrag richtet sich an alle, die eine Strategie beauftragen, verabschieden oder anschließend umsetzen müssen: Sekretäre und Schatzmeister (skarbnik) in Ämtern, Vorstände und Geschäftsführer kommunaler Unternehmen (spółka komunalna), Geschäftsführer und Finanzvorstände von Unternehmen sowie IT-Leiter, die wollen, dass das Dokument ihnen endlich in der Budgetdiskussion hilft. Über typische Fehler in Strategien von Kommunalverwaltungen (JST) habe ich bereits gesondert im Beitrag IT-Strategie in JST: die häufigsten Fehler geschrieben. Hier konzentriere ich mich darauf, was im Dokument selbst stehen sollte.

Warum Strategien in der Schublade landen

Aus dem, was ich in öffentlichen und privaten Organisationen gesehen habe: Eine Strategie ist inhaltlich selten schlecht. Sie landet in der Schublade, weil sie sich bei der ersten konkreten Entscheidung nicht anwenden lässt.

• Sie beginnt mit einer Vision, nicht mit einer Bestandsaufnahme. Niemand hat geprüft, welche Systeme, Verträge und Abhängigkeiten bereits bestehen, sodass der Plan bei der ersten Beschaffung an der Realität vorbeigeht.
• Sie beschreibt Ziele, aber keine Reihenfolge. Alles ist wichtig, also ist nichts das Erste.
• Es fehlt das Geld. Ohne Verknüpfung mit dem Budget leben Strategie und Finanzplan getrennt voneinander.
• Sie ändert nichts an der Art des Einkaufs. Weitere Systeme werden weiterhin so gekauft wie zuvor – auf Basis von Anbieterangeboten statt eigener Standards.
• Es fehlt ein Verantwortlicher. Das Dokument wurde per Beschluss oder Vorstandsentscheidung angenommen, und damit endete sein Leben.
• Sie ist in IT-Sprache geschrieben. Vorstand und Rat (rada) finden darin keine Antworten auf ihre Fragen: wie viel, wozu, was passiert, wenn wir nichts tun.

Sieben Elemente einer Strategie, die tatsächlich genutzt wird

1. Ist-Zustand. Ein Systemregister mit Verantwortlichem, Vertrag, Lizenz, Kosten und Support-Ende, eine Prozess- und Schnittstellenlandkarte, ein Risikoregister. Ohne das ist jeder weitere Punkt Raterei. Dies ist Aufgabe einer Inventarisierung.
2. Zielarchitektur. Ein einfaches Bild davon, wie sich Register, Prozesse, Schnittstellen und Zugriffsrechte zueinander verhalten. Es geht nicht um technische Schaubilder, sondern um die Antwort auf die Frage, welche Systeme zentral sind und welche sie unterstützen, wo Daten entstehen sollten und welche Systeme diese Daten übernehmen sollten.
3. Standards. Einige Regeln, die bei jeder Beschaffung gelten: wie Berechtigungen vergeben werden, wie die Benutzeroberfläche für Mitarbeitende aussehen soll, wie Anforderungen dokumentiert werden, welche Datenrechte wir haben müssen, welche Sprache (welchen Standard) wir zur Beschreibung von Prozessen verwenden, wie wir den Ausstieg aus einer Zusammenarbeit absichern.
4. Roadmap mit Trennung zwischen Pflicht und Investition. Getrennt aufgeführt das, was wir tun müssen, weil es das Gesetz oder ein Vertrag verlangt (in Ämtern etwa ein System der EZD-Klasse – elektronisches Dokumenten- und Vorgangsmanagementsystem, KSeF – das polnische nationale E-Rechnungssystem, e-Doręczenia – der polnische E-Zustelldienst), und das, was wir tun, weil es sich lohnt. Mit Reihenfolge und Begründung. Beispiel: Eine nach Abruf aus KSeF gespeicherte Rechnung kann zur Akte genommen werden, sollte aber gemäß den Vorschriften eine fachliche Freigabe, eine formal-rechnerische Prüfung durchlaufen und schließlich automatisch im Finanz- und Buchhaltungssystem gebucht werden.
5. Budget mit Trennung zwischen Investition und Betrieb. Die Betriebskosten steigen mit jedem neuen System und sollten sichtbar sein, bevor die Kaufentscheidung fällt. Mehr dazu im Beitrag über die Gesamtbetriebskosten (TCO). Beachten Sie: Die Einführung ist in der Regel eine einmalige Investition (CAPEX), aber aus Sicht von Budget, Betriebskontinuität und Sicherheit sind es u. a. Service und Updates (OPEX), die sich Jahr für Jahr wiederholen.
6. Beschaffungsgrundsätze für Systeme. Wann eine Inventarisierung oder Analyse vor dem Kauf erforderlich ist, wer das Angebot begutachtet, welche Klauseln im Vertrag stehen müssen. Einen Teil davon habe ich im Beitrag über SWZ (Leistungsbeschreibung) ohne Vendor-Lock-in beschrieben.
7. Verantwortlicher und Überprüfungsrhythmus. Eine konkrete Person auf Führungsebene sollte die Strategie und die Gesamtbetriebskosten überprüfen, mindestens einmal jährlich im Rahmen der Budgetplanung, unter Einhaltung eines klaren Grundsatzes der Regelmäßigkeit dieser Überprüfungen.

Ein Praxisbeispiel

Die Stadtwerke „Wodociągi Miejskie“, ein Unternehmen einer mittelgroßen Gemeinde, bereiteten den IT-Beschaffungsplan für das kommende Jahr vor. Zunächst beantragte die IT-Abteilung den gleichzeitigen Austausch der Büro-PCs, die Anschaffung eines neuen Überwachungssystems sowie die Modernisierung der Netzwerkinfrastruktur. Die Geschäftsführung bat jedoch darum, aufzuzeigen, welche Ausgaben mit Blick auf die Kontinuität der Wasserversorgung am dringendsten seien.

Das Unternehmen begann mit einer Inventarisierung: Es erfasste Geräte, Software, Netzwerkverbindungen und Serviceverträge und ordnete sie anschließend konkreten Prozessen zu – von der Kundenbetreuung bis zur Steuerung der Wasseraufbereitungsanlagen. Dabei stellte sich heraus, dass ein Teil der Geräte, die die Kommunikation mit den Anlagen vermittelten, kurz vor dem Ende des Supportzeitraums stand und die Dokumentation der Verbindungen nicht alle Standorte abdeckte. Gleichzeitig konnte der Großteil der Büro-PCs weiterhin ohne wesentliche Auswirkung auf kritische Dienste im Einsatz bleiben.

Auf dieser Grundlage wurde die Beschaffungsreihenfolge geändert. Zunächst wurde die Absicherung und Ordnung der Verbindungen zu den technischen Anlagen sowie der Austausch der Geräte vorgesehen, deren Ausfall die Überwachung der Wasserversorgung hätte beeinträchtigen können. Anschließend wurde eine Ergänzung der Datensicherung und Überwachung geplant. Der Austausch eines Teils der Büro-PCs wurde auf einen späteren Zeitpunkt verschoben.

Vor der Geschäftsführung begründete die IT-Abteilung das Budget nicht mehr mit der allgemeinen Aussage, „die Geräte seien alt“. Sie zeigte den Zusammenhang: konkretes Infrastrukturelement → unterstützter Prozess → Folge eines Ausfalls → vorgeschlagene Beschaffung. Dadurch konnte die Geschäftsführung die Ausgaben stufenweise genehmigen und dem Aufsichtsrat erklären, warum die Infrastruktur für die Betriebskontinuität Vorrang vor den für Mitarbeitende sichtbareren Bürogeräten erhielt.

Wann ein unabhängiger Berater nötig ist

Eine Strategie lässt sich mit eigenen Kräften schreiben, wenn es in der Organisation jemanden gibt, der dafür Zeit hat und das Gesamtbild überblickt. Externe Unterstützung ist hilfreich, wenn der Ist-Zustand nicht dokumentiert ist, wenn die Strategie als Grundlage dienen soll, um das Budget gegenüber dem Rat (rada), dem Eigentümer oder der Zentrale zu verteidigen, wenn mehrere regulatorische Pflichten gleichzeitig anstehen oder wenn Vorstand und IT die Prioritäten unterschiedlich sehen und jemand gebraucht wird, der die eine Perspektive in die andere übersetzt.

Ich erstelle eine Digitalisierungsstrategie und Zielarchitektur auf Basis einer Inventarisierung: mit Roadmap, Standards, Beschaffungsgrundsätzen und einem Budget, das sich verteidigen lässt.