Projekt: 30-Tage-IT-Bestandsaufnahme für eine Kommune
In vier Wochen entsteht kein perfektes CMDB-Projekt, aber eine belastbare Sicht auf kritische Services, Systeme, Owner, Abhängigkeiten, Backup/Restore, Monitoring und die wichtigsten offenen Risiken.
Projektidee · von Christian Hoberg · veröffentlicht 23.09.2026 · 8 Min. Lesezeit
ProjektideeBestandsaufnahme30 TageKommunal-IT
FrageFehlt euch ein belastbarer Überblick, bevor das nächste größere IT-Projekt startet?
ProblemInventare, Monitoring, Backuplisten und Wissen einzelner Administratoren zeigen oft jeweils nur einen Ausschnitt. Für Entscheidungen fehlt die gemeinsame Service-Sicht.
Erster SchrittMit den zehn bis zwanzig wichtigsten Services beginnen und pro Service Owner, Nutzer, Kernsysteme, Abhängigkeiten und Wiederherstellung erfassen.
ZielEin kompaktes IT-Service- und Risikoregister als Grundlage für die nächsten Projekte.
Aufwandca. 3–5 Personentage verteilt
Zeitraum30 Tage
VoraussetzungenZugang zu vorhandenen Inventaren, Monitoring/Backup und Ansprechpartnern der wichtigsten Fachbereiche
Ergebnispriorisierte Service-/Systemübersicht mit Ownern, Abhängigkeiten, Restore-/Monitoring-Status und nächsten Maßnahmen
1. Kritische Services auswählen
Nicht mit jedem Switchport und jedem Drucker starten. Zuerst werden die Dienste erfasst, deren Ausfall Verwaltung, Kommunikation oder zentrale Fachprozesse spürbar stoppt.
2. Systeme und Abhängigkeiten verbinden
Je Service werden Server/Cloud-Dienste, Netzwerk, Identität, Datenbanken, Zertifikate, Backup und externe Abhängigkeiten grob zugeordnet. Ziel ist Verständlichkeit, nicht perfekte Modellierung.
3. Betriebssicherheit sichtbar machen
Für jeden Service werden Owner, Monitoring, letzte Restore-Prüfung, Support/Lifecycle und bekannte Single Points of Failure markiert. Unbekannt ist dabei ein zulässiger und wichtiger Status.
4. Drei bis fünf nächste Vorhaben ableiten
Die Bestandsaufnahme endet nicht mit einer Tabelle. Aus den sichtbar gewordenen Risiken werden wenige konkrete Maßnahmen für die nächsten 90 Tage abgeleitet und einem Owner zugeordnet.
Wenn Security, Lifecycle, Fachverfahren, Support und neue Projekte gleichzeitig drängen, braucht es keine weitere Wunschliste, sondern eine einfache Reihenfolge nach Risiko, Wirkung und Betriebsfähigkeit.
Statt noch mehr Hostchecks aufzubauen, werden zehn wichtige Verwaltungsservices mit Abhängigkeiten, Nutzerwirkung, Alarmweg und einem echten Fehlerfall als End-to-End-Monitoring modelliert.
Nicht jede alte Plattform ist automatisch ein Notfall. Kritisch wird technische Schuld dort, wo Wissen, Wiederherstellung, Support oder sichere Änderungen nicht mehr belastbar funktionieren.
Backups allein machen eine Kommune noch nicht handlungsfähig. Entscheidend ist, welche Verwaltungsleistungen zuerst zurückkommen, wie Teams ohne Standard-IT kommunizieren und wer den Wiederanlauf steuert.