GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
Für viele Unternehmen stellen Informationen und die Technologie, die sie unterstützt, ihr wertvollstes, aber oft am wenigsten verstandenes Kapital dar. Erfolgreiche Unternehmen erkennen die Vorteile der Informationstechnologie und nutzen sie, um den Wert ihrer Stakeholder zu steigern. Diese Unternehmen verstehen und managen auch die damit verbundenen Risiken, wie die zunehmende Einhaltung gesetzlicher Vorschriften und die kritische Abhängigkeit vieler Geschäftsprozesse von der Informationstechnologie (IT).
Die Gewissheit über den Wert der IT, das Management von IT-bezogenen Risiken und erhöhte Anforderungen an die Kontrolle über Informationen werden heute als Schlüsselelemente der Unternehmensführung verstanden. Wert, Risiko und Kontrolle bilden den Kern der IT-Governance.
Die IT-Governance liegt in der Verantwortung der Führungskräfte und des Vorstands und besteht aus der Führung, den Organisationsstrukturen und Prozessen, die sicherstellen, dass die IT des Unternehmens die Strategien und Ziele der Organisation aufrechterhält und erweitert.
Um die Geschäftsziele zu erfüllen, müssen Informationen bestimmten Kontrollkriterien entsprechen, die COBIT als Geschäftsanforderungen an Informationen bezeichnet. Ausgehend von den umfassenderen Qualitäts-, Treuhand- und Sicherheitsanforderungen werden sieben verschiedene, sich sicherlich überlappende Informationskriterien wie folgt definiert:
Organisationen sollten die Qualitäts-, Shareholder- und Sicherheitsanforderungen für ihre Informationen, wie für alle Vermögenswerte, erfüllen.
Das Management sollte auch die Nutzung der verfügbaren IT-Ressourcen, einschließlich Anwendungen, Informationen, Infrastruktur und Mitarbeiter, optimieren. Um diesen Verantwortlichkeiten gerecht zu werden und um ihre Ziele zu erreichen, sollte die Leitung den Status ihrer Unternehmensarchitektur für die IT verstehen und entscheiden, welche Governance und Kontrolle sie bieten sollte. Control Objectives for Information and related Technology (COBIT®) bietet gute Praktiken über einen Domänen- und Prozessrahmen und stellt Aktivitäten in einer überschaubaren und logischen Struktur dar. Die guten Praktiken von COBIT® stellen den Konsens der Experten dar. Sie sind stark mehr auf Kontrolle und weniger auf Ausführung ausgerichtet. Diese Praktiken tragen dazu bei, IT-gestützte Investitionen zu optimieren, die Bereitstellung von Dienstleistungen sicherzustellen und ein Maß zu liefern, anhand dessen man beurteilen kann, wann etwas schief läuft.
COBIT konzentriert sich auf das, was erforderlich ist, um eine angemessene Verwaltung und Kontrolle der IT zu erreichen, und ist auf einem hohen Niveau positioniert. COBIT wurde mit anderen, detaillierteren IT-Standards und guten Praktiken abgestimmt und harmonisiert.
COBIT fungiert als Integrator dieser verschiedenen Leitfäden und fasst die wichtigsten Ziele unter einem übergreifenden Rahmenwerk zusammen, das auch eine Verbindung zu Governance und Geschäftsanforderungen herstellt. Alle Komponenten von COBIT stehen in Wechselbeziehung zueinander und bieten Unterstützung für die Bedürfnisse der verschiedenen Zielgruppen in den Bereichen Governance, Management, Kontrolle und Sicherheit.
Prozessbeschreibungen von der tatsächlichen Verantwortung unterscheiden. Wählen Sie einen im Beitrag beschriebenen COBIT-4.1-Prozess und identifizieren Sie seine heutigen Entscheidungsinstanzen. Diese Gegenüberstellung zeigt, welche Gedanken übertragbar sind und wo eine historische Struktur angepasst werden muss.
Regulierung, Verantwortung und Steuerung werden als zusammenhängende Führungsaufgabe betrachtet. Die Managementperspektive stellt die Frage in den Mittelpunkt, wie aus regulatorischen Vorgaben handhabbare Entscheidungen, Zuständigkeiten und Steuerungsprozesse entstehen.
Von Dr. Markus Groß
COBIT ist ein FRamework und unterstützender Werkzeugsatz, der es Managern ermöglicht, die Lücke in Bezug auf Kontrollanforderungen, technische Fragen und Geschäftsrisiken zu überbrücken und dieses Kontrollniveau den Interessengruppen zu vermitteln. COBIT ermöglicht die Entwicklung klarer Richtlinien und bewährter Verfahren für die IT-Kontrolle im gesamten Unternehmen. COBIT wird kontinuierlich auf dem neuesten Stand gehalten und mit anderen Standards und Richtlinien harmonisiert.
„COBIT 4.1 im Detail“ setzt einen klaren historischen Ausgangspunkt. Die Ergänzung trennt diesen Anlass anhand von Rollenklarheit von den Fragen, die für Entscheidungen, Betrieb und Kontrolle weiterhin relevant sind.
Praktisch relevant wird „COBIT 41 im Detail“ dort, wo Verantwortung und Ergebnis zusammenkommen: Es ist zu klären, welche nächste Fähigkeit wichtiger ist als eine möglichst hohe Stufe. Beim Schwerpunkt „COBIT 41 im Detail“ geht es um ein Management- oder Governance-Framework und seine praktische Nutzung sowie um den Bezug zu „Anpassungstiefe“; zu entscheiden ist, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Wirkungsprüfung“), ohne das Framework zum Selbstzweck zu machen. Die Grenze der Betrachtung bleibt eindeutig: Ein Framework liefert Orientierung (hier bezogen auf „Prozessnutzen“); Verantwortung für Auswahl, Anpassung und Wirkung bleibt bei der Organisation. Für den nächsten Review wird vereinbart: Reife an beobachtbarer Praxis statt an Selbsteinschätzung festmachen. Die Dokumentation hält zwei Dinge fest – ein priorisierter Entwicklungsschritt mit messbarem Abschluss; zusätzlich sichtbar wird: Entscheidungsdauer, Ergebnisqualität, Nacharbeit, Rollenklarheit und nachweisbare Verbesserung. Aus den vorhandenen Kommentaren lässt sich besonders der Punkt „klare Zuständigkeiten und Entscheidungsrechte“ aufnehmen; die Umsetzung wird dabei an „Prozessnutzen“ gespiegelt. Aus der Perspektive „Anpassungstiefe“ entsteht daraus eine konkrete Rückfrage an die Umsetzung.
Der konkrete Nutzen von „Anpassungstiefe“ zeigt sich erst, wenn eine offene Annahme überprüft wird: Es ist zu klären, welches Arbeitsergebnis Ausführung und Ergebnis glaubhaft belegt. Beteiligt sind hier vor allem Management, Prozess- und Serviceverantwortliche, Projektteams, Governance-Funktionen und Revision; ihre Perspektiven treffen beim Aspekt „Arbeitsergebnis“ unmittelbar aufeinander; die Umsetzung wird dabei an „Wirkungsprüfung“ gespiegelt. Ein realistischer Belastungstest betrachtet den Fall, dass Terminologie und Prozessbilder wachsen (hier bezogen auf „Integration“), während Entscheidungen, Leistungen oder Kontrollen unverändert schwach bleiben. Für den nächsten Review wird vereinbart: Nachweise möglichst im normalen Prozess entstehen lassen; für „Auswahl der Praktiken“ ist das Ergebnis gesondert festzuhalten. Überprüfbar wird der Schritt durch folgendes Ergebnis: eine datierte Spur aus Soll, Ausführung, Ergebnis und Abweichung; der konkrete Prüfmaßstab wird aus „Integration“ abgeleitet. Relevant bleibt dabei: der Zusammenhang zwischen „Anpassungstiefe“ und „Arbeitsergebnis“. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Anpassungstiefe“ noch nachvollziehbar wäre.
Im Mittelpunkt von „Rollenklarheit“ steht weniger das Schlagwort als die damit verbundene Entscheidung: Es ist zu klären, wie Störungen, Rückfragen und Ausnahmen zur Verbesserung genutzt werden. Als belastbare Grundlage dienen Zielproblem, ausgewählte Praktiken, Rollenentscheidung, Arbeitsergebnisse, Abweichungen und Verbesserungsnachweise; für den Aspekt „Rollenklarheit“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Auswahl der Praktiken“ sollte deshalb ausdrücklich festhalten, welcher Baustein ein konkretes Organisationsproblem löst (hier bezogen auf „Auswahl der Praktiken“), ohne das Framework zum Selbstzweck zu machen. Für die belastbare Umsetzung gilt als Auftrag: Muster regelmäßig auswerten und Regeln gezielt anpassen; für den Aspekt „Methodenumfang“ wird daraus ein eigener Prüfschritt. Der Prüfpfad endet nicht beim Dokument; im Fokus steht dabei „Managementbedarf“. Als Verbindung zwischen Nachweis und Messung dienen: eine Änderung, deren Anlass und erwartete Wirkung dokumentiert sind; die beobachtbare Veränderung beim Aspekt „Kosten, Aufwand und eine faire Verteilung“. Aus den vorhandenen Kommentaren lässt sich besonders der Punkt „Kosten, Aufwand und eine faire Verteilung“ aufnehmen; die Bewertung erfolgt hier aus der Perspektive „Entscheidungsweg“. Aus der Perspektive „Auswahl der Praktiken“ entsteht daraus eine konkrete Rückfrage an die Umsetzung.
Für die belastbare Anwendung von „Verbesserungsschritt“ muss aus der Beobachtung ein prüfbarer Arbeitsauftrag werden: Es ist zu klären, ob eine dritte Person Entscheidung und Durchführung ohne mündliche Rekonstruktion versteht. Die alltagstaugliche Übersetzung für „Verbesserungsschritt“ lautet: Nur die für das Ziel erforderlichen Elemente werden übernommen und anhand beobachtbarer Ergebnisse weiterentwickelt – betrachtet im Kontext „COBIT 41 im Detail“. Damit wird zugleich die Grenze beim Aspekt „Methodenumfang“ sichtbar: Ein Framework liefert Orientierung (hier bezogen auf „Reifeentwicklung“); Verantwortung für Auswahl, Anpassung und Wirkung bleibt bei der Organisation. Im Regelbetrieb wird folgender Punkt verankert: Begründung, Zeitpunkt, Verantwortliche, Eingangsdaten und Ergebnis zusammenhalten; die Umsetzung wird dabei an „COBIT 41 im Detail“ gespiegelt. Der Prüfpfad endet nicht beim Dokument; der Prüfkontext ist hier „Anpassungstiefe“. Als Verbindung zwischen Nachweis und Messung dienen: einen reproduzierbaren Prüfpfad bis zur Quelle; Entscheidungsdauer, Ergebnisqualität, Nacharbeit, Rollenklarheit und nachweisbare Verbesserung. Der gewählte Weg sollte sich außerdem umkehren lassen, falls die Annahmen zu „Methodenumfang“ später nicht mehr tragen.
Als Abschluss für COBIT 41 im Detail genügen drei verbindliche Antworten zu Anpassungstiefe: Wer entscheidet über Rollenklarheit, woran wird Wirkung bei Verbesserungsschritt erkannt und welcher Auslöser führt zur erneuten Prüfung? Sind diese Punkte geklärt, wird aus dem historischen Impuls zu Arbeitsergebnis eine belastbare Arbeitsgrundlage.
| 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. |
Deine Bewertung hilft bei der Einordnung der Inhalte.
Interessant für dein Netzwerk? Teile den Beitrag direkt.
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.
Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern. Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.
Kommentare 36
Der Ansatz ist nachvollziehbar. Offen bleibt für mich, wie Transparenz, Verantwortung und praktische Nutzbarkeit zusammengebracht werden. Wo würdet ihr mit der Prüfung beginnen?
Ich würde zunächst einen konkreten Ablauf auswählen und dort Ausgangslage, Entscheidung und Ergebnis gegenüberstellen. Sonst bleibt die Bewertung leicht abstrakt.
Ein konkreter Fall hilft, aber die Zuständigkeit muss von Anfang an klar sein. Sonst ist zwar das Problem sichtbar, die notwendige Entscheidung bleibt aber liegen.
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.
Die Trennung zwischen Durchführung und Wirkung hilft. So könnte man klein anfangen, ohne die spätere Bewertung dem Bauchgefühl zu überlassen.
Das wirft eine praktische Frage auf. 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.
Welche Entscheidung müsste zu Zuständigkeit für Steuerungsentscheidungen zuerst fallen, wenn die Maßnahme bereits auf dem Papier abgeschlossen ist?
Ich würde die Umsetzung an einem konkreten Fall nachvollziehen und dabei das tatsächliche Ergebnis prüfen. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Zuständigkeit für Steuerungsentscheidungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wie verhindert ihr bei Zuständigkeit für Steuerungsentscheidungen, dass eine vorläufige Lösung ohne erneute Prüfung dauerhaft bestehen bleibt?
Ich würde einen festen Wiedervorlagetermin und eine klare Entscheidung über Fortführung oder Abschluss vorsehen. Wichtig ist, dass die Ausnahme nicht allein deshalb bestehen bleibt, weil niemand mehr nachfragt. Mit Blick auf Zuständigkeit für Steuerungsentscheidungen würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Dazu eine Rückfrage: Was ist aussagekräftiger: ein höherer Reifegrad oder eine nachweisbar bessere Entscheidung?
Ich würde den Reifegrad als Orientierung behandeln. Entscheidend bleibt für mich, ob sich Steuerung und Ergebnisse tatsächlich verbessern.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern? Meine Ausgangsfrage bleibt: Was ist aussagekräftiger: ein höherer Reifegrad oder eine nachweisbar bessere Entscheidung?
Für mich wäre eine kurze regelmäßige Überprüfung praktikabler als eine seltene große Überarbeitung. Änderungen im normalen Betrieb könnten dabei als Anlass dienen. Auf die Ausgangsfrage bezogen: Ich würde den Reifegrad als Orientierung behandeln. Entscheidend bleibt für mich, ob sich Steuerung und Ergebnisse tatsächlich verbessern.
Ja, so wird die Abwägung konkreter. Ich würde vor allem den Prüfanlass festhalten, damit die Lösung nicht unbegrenzt als gesetzt gilt. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen.
Wo würdet ihr bei Verknüpfung von Unternehmenszielen und IT-Zielen anfangen, wenn mehrere Fachbereiche unterschiedliche Prioritäten haben?
Mein Vorschlag wäre, zuerst die betroffene Entscheidung und deren Auswirkungen klären, bevor gemeinsame Kriterien festgelegt werden. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Verknüpfung von Unternehmenszielen und IT-Zielen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Dazu eine Rückfrage: Wie wählt man aus einem umfangreichen Framework einen angemessenen Einstieg aus?
Das ist ein wichtiger Punkt. Ausgangspunkt wären für mich Unternehmensziele und die wichtigsten Risiken. Alles gleichzeitig umzusetzen würde eher die Priorisierung verdecken.
Einverstanden, mit einer Einschränkung: Wenn die notwendige Information fehlt, funktioniert die Abwägung nicht. Woher sollte sie kommen?
Sind Governance und operatives Management im Alltag wirklich sauber trennbar?
Ich sehe darin vor allem eine Gestaltungsfrage. Die Aufgaben berühren sich natürlich. Trotzdem würde ich festhalten, wer die Richtung und Grenzen vorgibt und wer innerhalb dieser Grenzen umsetzt.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Der Umfang müsste zur Bedeutung der betroffenen Leistung passen. Weniger Detail kann vernünftig sein, solange die wesentlichen Entscheidungen und Abhängigkeiten nachvollziehbar bleiben. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Da kommen wir näher zusammen. Ein gemeinsamer Ablauf wäre überzeugender als zwei Verfahren, die im Ernstfall unterschiedliche Antworten geben. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Damit bin ich noch nicht ganz zufrieden. Wie würde man prüfen, ob die vorgeschlagene Lösung im Alltag tatsächlich eingehalten wird? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Der Gedanke zu klare Entscheidungsrechte in der IT-Governance ist plausibel. Ich würde früh klären, wer bei einem negativen Ergebnis tatsächlich entscheiden muss.
Bei klare Entscheidungsrechte in der IT-Governance würde ich nicht nur die Durchführung betrachten. Aussagekräftig wird es erst, wenn Wirkung und Abweichungen sichtbar bleiben.
Ich würde bei der Umsetzung mit klare Entscheidungsrechte in der IT-Governance beginnen. Hilfreich wäre eine vorher festgelegte Schwelle, ab der tatsächlich gehandelt wird.
Für klare Entscheidungsrechte braucht es aus meiner Sicht keine Vielzahl neuer Kennzahlen. Wenige klar interpretierbare Signale wären hilfreicher.
Wie würdet ihr bei Messung von Zielerreichung und Kontrollwirkung die wichtigsten Abhängigkeiten für die Umsetzung sichtbar machen?
Ich würde zunächst die wenigen Abhängigkeiten erfassen, deren Ausfall oder Verzögerung das Ergebnis tatsächlich gefährdet. Die Liste sollte eine Entscheidung ermöglichen und regelmäßig überprüft werden. Für Messung von Zielerreichung und Kontrollwirkung würde ich den ersten Prüfschritt bewusst klein halten.
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.
Ich würde jedes ausgewählte Ziel mit einer Verantwortlichkeit und einer tatsächlichen Entscheidung verbinden. Sonst bleibt die Umsetzung auf der Dokumentationsebene.