

Führungskräfte in Unternehmen und öffentlichen Einrichtungen werden zunehmend aufgefordert, sich Gedanken darüber zu machen, wie gut die IT gemanagt wird. Als Reaktion darauf müssen Business Cases zur Verbesserung entwickelt und die entsprechende Ebene der Verwaltung und Kontrolle über die Informationsinfrastruktur erreicht werden. Auch wenn nur wenige argumentieren würden, dass dies keine gute Sache ist, so müssen sie doch das Kosten-Nutzen-Verhältnis und diese damit verbundenen Fragen berücksichtigen:
Es kann schwierig sein, aussagekräftige Antworten auf diese Fragen zu geben. Das IT-Management ist ständig auf der Suche nach Benchmarking- und Selbstbewertungsinstrumenten, da es wissen muss, was effizient zu tun ist. Ausgehend von den COBIT-Prozessen sollte der Prozessverantwortliche in der Lage sein, inkrementelle Benchmarks anhand dieses Kontrollziels durchzuführen. Dies entspricht drei Bedürfnissen:
Die Reifegradmodellierung für das Management und die Kontrolle von IT-Prozessen basiert auf einer Methode zur Bewertung der Organisation, so dass sie von einem Reifegrad von nicht vorhanden (0) bis optimiert (5) bewertet werden kann. Dieser Ansatz leitet sich aus dem Reifegradmodell ab, das das Software Engineering Institute (SEI) für den Reifegrad der Softwareentwicklungsfähigkeit definiert hat.
Anhand der Reifegradmodelle, die für jeden der 34 IT-Prozesse von COBIT entwickelt wurden, kann das Management diese identifizieren:
Um die Ergebnisse in Managementbriefings leicht nutzbar zu machen, wo sie als Mittel zur Unterstützung des Business Case für zukünftige Pläne präsentiert werden, muss eine grafische Darstellungsmethode bereitgestellt werden (siehe Abbildung).

Der Vorteil eines Reifegradmodell-Ansatzes besteht darin, dass es für das Management relativ einfach ist, sich in die Waagschale zu werfen und einzuschätzen, worum es geht, wenn eine verbesserte Leistung erforderlich ist.
Die Skala umfasst 0, weil es gut möglich ist, dass überhaupt kein Prozess existiert. Die Skala von 0-5 basiert auf einer einfachen Reifegrad-Skala, die zeigt, wie sich ein Prozess von einer nicht vorhandenen Fähigkeit zu einer optimierten Fähigkeit entwickelt. Am Ende jedes Prozesses wird die Leistung dieses Prozesses durch die Reifegradmodelle bewertet, mit denen die tatsächliche Leistung des Unternehmens für seine IT-Prozesse gemessen wird.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 17
Spannend finde ich die praktische Seite: wie Verantwortlichkeiten und Entscheidungen im Alltag nachvollziehbar bleiben. Reicht dafür zunächst ein kleiner Pilot oder braucht es sofort einen breiteren Ansatz?
Für mich wäre ein begrenzter Anwendungsfall der beste Einstieg. Dann sieht man relativ schnell, ob die Information tatsächlich zu einer anderen Priorität oder Entscheidung führt.
Ich würde außerdem festhalten, welche Annahmen hinter der Bewertung stehen. Ändern sie sich, sollte nicht einfach derselbe Status fortgeschrieben werden.
Beides gehört zusammen: ein überschaubarer Einstieg und eine klare Konsequenz bei Abweichungen. Ohne diese Konsequenz bleibt auch eine gute Kennzahl letztlich informativ statt steuernd.
Damit wird es für mich deutlich greifbarer. Vor allem die vorher festgelegte Entscheidungsfolge verhindert, dass der Pilot nur als zusätzlicher Bericht endet.
Den Punkt würde ich gern vertiefen. Welche Schritte eignen sich für einen Einstieg, ohne gleich das ganze Modell umzusetzen?
Ich würde mit einem konkreten Steuerungsproblem beginnen und dafür Ziele, Verantwortliche und einen überprüfbaren Ablauf festhalten.
Das erscheint praktikabel. Ich würde bei der praktischen Umsetzung trotzdem einen Termin für die erste gemeinsame Rückschau ergänzen. So würde die spätere Bewertung greifbarer. Dafür müsste kein zusätzlicher großer Prozess entstehen.
Wie wählt man aus einem umfangreichen Framework einen angemessenen Einstieg aus?
Für mich liegt der Schwerpunkt hier: Ausgangspunkt wären für mich Unternehmensziele und die wichtigsten Risiken. Alles gleichzeitig umzusetzen würde eher die Priorisierung verdecken.
Damit bin ich noch nicht ganz zufrieden. Wie würde man prüfen, ob die vorgeschlagene Lösung im Alltag tatsächlich eingehalten wird? Meine Ausgangsfrage bleibt: Wie wählt man aus einem umfangreichen Framework einen angemessenen Einstieg aus?
Welche Entscheidung müsste zu Messung von Zielerreichung und Kontrollwirkung zuerst fallen, wenn verschiedene Systeme dieselbe Information unterschiedlich abbilden?
Ich würde zunächst eine maßgebliche Quelle bestimmen und Abweichungen gezielt untersuchen, bevor Kennzahlen daraus abgeleitet werden. Das schafft eine begrenzte, überprüfbare Arbeitsgrundlage für die weitere Umsetzung. Bei Messung von Zielerreichung und Kontrollwirkung sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wie verhindert man, dass aus dem Governance-Rahmen eine reine Prüfliste wird? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Das ist ein wichtiger Punkt. Ich würde jedes ausgewählte Ziel mit einer Verantwortlichkeit und einer tatsächlichen Entscheidung verbinden. Sonst bleibt die Umsetzung auf der Dokumentationsebene. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern? Meine Ausgangsfrage bleibt: Wie verhindert man, dass aus dem Governance-Rahmen eine reine Prüfliste wird?
Interessant finde ich hier vor allem klare Entscheidungsrechte in der IT-Governance. Eine kleine, sauber ausgewertete Erprobung wäre dafür aussagekräftiger als eine breite Papierlösung.