Scrum ist eine Teilmenge von Agile und repräsentiert ein Rahmenwerk für agile Entwicklungsprozesse, das sich durch seine Leichtgewichtigkeit und Anpassungsfähigkeit in der komplexen Produkt- und Softwareentwicklung als besonders effektiv erwiesen hat. Es hat sich aufgrund seiner Praxisnähe und Effizienz als das führende Prozess-Framework etabliert.

Unter einem "Prozess-Framework" versteht man eine Sammlung von Praktiken und Richtlinien, die, wenn sie eingehalten werden, sicherstellen, dass der Entwicklungsprozess im Einklang mit dem zugrunde liegenden Framework steht. Scrum zeichnet sich durch seine iterativen Entwicklungszyklen, bekannt als Sprints, aus, während andere Frameworks wie Extreme Programming (XP) eigene spezifische Praktiken wie Pair Programming vorschreiben.

Die Phase Service Strategy beschäftigt sich primär mit dem Verständnis der Unternehmensstrategie sowie der Synchronisation mit einer wettbewerbsfähigen IT und daraus abgeleiteten Kundenvorteilen. Die Herausforderung stellt die Integration der Informationstechnologie in die Geschäftsprozesse dar. Die IT wird nicht mehr nur Mittel zum Zweck, sondern als ein integraler Bestandteil zur Erreichung der Unternehmensziele gesehen. Ein zentraler Kerngedanke in dieser Phase ist die Wertschöpfung von IT-Services für das Business, die sich im Servicemanagement in die Begriffe "Utility" und "Warranty" aufteilen. Utility steht für die grundsätzliche Brauchbarkeit und Nützlichkeit von Services. Die Warranty zielt zusätzlich auf Gewährleistung, Verfügbarkeit und Zuverlässigkeit von IT-Dienstleistungen.

In diesem Zusammenhang wird in der Literatur der Service Lifecycle genannt, der in ITIL den Kerngedanken darstellt. Die Informationstechnologie darf die bereitgestellten Services nicht als einzelne und für sich abgeschlossene Prozesse verstehen, sondern muss einen fließenden Übergang von der Planung, der Inbetriebnahme bis zu den Änderungen der Komponenten und abschließend der Stilllegung sehen. Alte und nicht mehr benötigte Services dürfen nicht länger in Betrieb sein, sondern müssen aus ökonomischer Sichtweise außer Betrieb genommen werden. "Phasing out of services is part of Service Transition. This is to ensure that all commitments made to customers are duly fulfilled and service assets are released from contracts. [...] This is necessary because such services may cost a lot more to support and may disrupt economies of scale and scope."

Wer zum ersten Mal mit den MaRisk in Berührung kommt – den Mindestanforderungen an das Risikomanagement der BaFin – hat meist zwei spontane Reaktionen: Respekt vor dem Umfang und den Verweisen, und Skepsis, ob das wirklich mehr ist als eine Dokumentationspflicht für Prüfer. Genau hier lohnt sich der zweite Blick. MaRisk ist kein Selbstzweck und keine reine Compliance-Schablone. Hinter den Passagen verbirgt sich ein Betriebssystem für Banken, das darüber entscheidet, ob ein Institut gesteuert wird oder sich steuern lässt. Es beschreibt die Logik, nach der Entscheidungen nachvollziehbar getroffen, Risiken bewusst eingegangen und Überraschungen reduziert werden.

In diesem Artikel geht es darum, MaRisk wirklich zu verstehen – nicht aus der Perspektive der Paragraphen, sondern aus der Praxis: Wozu gibt es das Rundschreiben, wie ist es aufgebaut, wo liegt der Nutzen, wie lässt es sich wirksam leben? Dabei kommen wir ohne juristischen Zierat aus und übersetzen die Kerngedanken in Alltagssprache – mit Beispielen, knappen Strukturelementen und einem klaren Ziel: MaRisk als Hebel zu begreifen, nicht als Last.

Eine Strategie ist ein auf bestimmte Zeit ausgerichtetes Anstreben einer gewünschten Lage oder eines definierten Zieles. Leider gibt es in vielen Unternehmen keine schrift-lich fixierten Strategien. Meist sind diese nur der Unternehmensleitung bekannt, die Beschäftigten kennen unternehmensweite Strategien meist nicht.

Laut Kaplan/Norton ist jedoch gerade die Strategie der Ausgangspunkt für eine gute Balanced Scorecard. "Die Besten Balanced Scorecards spiegeln die Strategie einer Organisation wider.!"

Das COBIT-Rahmenwerk basiert auf folgendem Prinzip: Um die Informationen bereitzustellen, die das Unternehmen zur Erreichung seiner Ziele benötigt, muss das Unternehmen in IT-Ressourcen investieren und diese verwalten und steuern. Dazu muss es einen strukturierten Satz von Prozessen verwenden, um die Dienste bereitzustellen, die die erforderlichen Unternehmensinformationen liefern. Die Verwaltung und Kontrolle von Informationen sind das Herzstück des COBIT-Frameworks und tragen dazu bei, die Anpassung an die Geschäftsanforderungen sicherzustellen.

Die Verwaltung und Kontrolle von Informationen sind das Herzstück des COBIT-Frameworks und tragen dazu bei, die Anpassung an die Geschäftsanforderungen sicherzustellen. COBIT definiert IT-Aktivitäten in einem generischen Prozessmodell innerhalb von vier Domänen. Diese Domänen sind Planen und Organisieren (PO), Akquirieren und Implementieren (AI), Bereitstellen und Unterstützen (DS) sowie Überwachen und Bewerten (ME). Die Domänen entsprechen den traditionellen Verantwortungsbereichen der IT: Planen, Erstellen, Ausführen und Überwachen.
Um die IT effektiv zu verwalten, ist es wichtig, die Aktivitäten und Risiken innerhalb der IT zu kennen, die verwaltet werden müssen. Sie sind in der Regel den Zuständigkeitsbereichen Planen, Bauen, Betreiben und Überwachen zugeordnet. Innerhalb des COBIT-Rahmens werden diese Bereiche genannt: