Zusammenfassung
Betroffene Ebenen und Bereiche Die Entwicklung und die Einführung von Risikomanagementsystemen gestalten sich aufgrund der Vielschichtigkeit sowie der mit dem Risikomanagement verbundenen Integration in Organisationsstrukturen und Unternehmensabläufe in der Praxis als sehr anspruchsvoll. Alle technischen und organisatorischen Ebenen und Bereiche können vom Risikomanagement betroffen sein: Hardware (z. B. Server, Netzwerk); System-Software (z. B. Datenbanken, Scheduler, Compiler); Anwendungssysteme (z. B. Versionsverwaltungssysteme, Finanzbuchhaltungssysteme, BI-Lösungen); Benutzersoftware (z.B. Daten, aktuarielle Werkzeuge, Kapitalmarktgeneratoren); Software-Anwendung (z.B. interne Modelle, Tabellenkalkulationsprogramme); Aufbauorganisation (z. B. Aktuare, Compliance-Funktion, interne Revision, Risikomanagementfunktion); Ablauforganisation (z. B. Risikokontrollprozess, Reporting); Management (z. B. strategische Planung, Leitlinien, Produktinnovationen, Kapitalanlagen); Unternehmenskultur (z.B. Risikokultur, Leitbild).
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Vgl. z. B. die Erläuterungen zu Pkt. 7.3.3 Nr. 1 MaRisk. Danach muss die unternehmensindividuelle Risikokultur von der obersten Hierarchieebene her systematisch nach unten vorgelebt werden. Als wesentlicher Bestandteil einer gelebten Risikokultur gilt die offene Kommunikation von Risiken, ohne dass den Betroffenen hierdurch Nachteile entstehen. Außerdem muss der direkte Vorgesetzte derart über alle wesentlichen Risiken in angemessener Weise informiert sein, dass er eine erste Steuerung der Risiken vornehmen kann.
- 2.
Die DIN 69901 definiert Projektmanagement als „Gesamtheit von Führungsaufgaben, ‐organisation, ‐techniken und ‐mittel für die Abwicklung eines Projekts“. Aus dieser eher technokratischen Sichtweise sollte nicht geschlossen werden, dass sich ein Projekt reibungslos „abwickeln“ lässt, wenn alle Bereiche des Projektmanagements ordnungsgemäß definiert und konsequent umgesetzt werden. Bei komplexen Softwareprojekten oder Change‐Projekten, wo unterschiedlichste Typologien der Führungs‐ und Organisationskultur bestehen, ist dies nicht notwendigerweise der Fall (siehe z. B. [BuWW03; SaGR07; FlBu11]).
- 3.
Die Werte in den Chaos Reports der Standish Group sanken kontinuierlich: 189 % (1994), 142 % (1996), 69 % (1998), 45 % (2000), 43 % (2002) [Stan03].
- 4.
Nach ONR 49000 (ISO 31000) Pkt. 3.2.23 ist Risikomanagement definiert als „Prozesse und Verhaltensweisen, die darauf ausgerichtet sind, eine Organisation bezüglich Risiken zu steuern“.
IDW PS 340, Tz. 4 definiert Risikomanagement als „die Gesamtheit aller organisatorischen Regelungen und Maßnahmen zur Risikoerkennung und zum Umgang mit den Risiken unternehmerischer Betätigung“.
Nach IIR Revisionsstandard Nr. 2 ist Risikomanagement ein „nachvollziehbares, alle Unternehmensaktivitäten umfassendes Regelungssystem, das auf Basis einer definierten Risikostrategie ein systematisches und permanentes Vorgehen mit folgenden Elementen umfasst: Identifikation, Analyse, Bewertung, Steuerung, Dokumentation und Kommunikation sowie die Überwachung dieser Aktivitäten“. (Deutsches Institut für Interne Revision (IIR): Prüfung des Risikomanagement durch die Interne Revision. IIR Revisionsstandard Nr. 2, www.diir.de/fileadmin/downloads/allgemein/Revisionsstandard_Nr._2.pdf. Abruf am 10.03.2014.)
Pkt. 1 Nr. 2 S. 2 MaRisk beschreibt Risikomanagement als „die Festlegung einer angemessenen Risikostrategie, die konsistent zu der gewählten Geschäftsstrategie ist, adäquate aufbau‐ und ablauforganisatorische Regelungen, die Einrichtung eines angemessenen internen Steuerungs‐ und Kontrollsystems, die Etablierung einer internen Revision und die Einrichtung von internen Kontrollen“.
Ebenso unterschiedlich sind die gesetzlichen Definitionen des § 64a Abs. 1 S. 4 VAG und des § 25a Abs. 1 S. 3 KWG. Der § 33 Abs. 1 WpHG inkludiert § 25a Abs. 1 KWG und erweitert die Vorgaben um besondere Organisationspflichten wie eine Compliance‐Funktion, ein Beschwerdemanagement sowie Sorgfaltspflichten bei der Anlageberatung zum Schutz und zur Wahrung von Kundeninteressen.
- 5.
Üblicherweise werden im Rahmen eines integrierten, ganzheitlichen Managementsystems Ertrags‐ und Risikosteuerung zusammen betrachtet (vgl. z. B. [Fört00; Chri06; CoHS12; KrWo12]). Dabei ist klar zwischen Ertrag und Verlust bzw. Chance und Risiko zu unterscheiden – ein Risiko ist kein Verlust, eine Chance ist kein Ertrag.
- 6.
Auch die MaRisk sehen Risikomanagement als Bestandteil der strategischen Unternehmensführung: Risiko ist „im Zusammenhang mit den Zielsetzungen zu interpretieren. Es sind sowohl negative als auch positive Zielabweichungen möglich. Negative Zielabweichungen realisieren sich zumeist als Verluste. Dennoch ist es Aufgabe eines guten Risikomanagementsystems, unternehmerische Chancen und Risiken zu handhaben“ (siehe die Erläuterungen zu Pkt. 5 Nr. 1 MaRisk).
- 7.
Die Risikoidentifikation hat bereits im strategischen Planungsprozess zu beginnen und ist auf das Gesamtrisikoprofil des Unternehmens abzustimmen (Pkt. 7.3.2.1 Nr. 2 MaRisk).
- 8.
D. h. aus Sichtweise der Entscheidungsträger steht das ursachenbezogene Risiko im Vordergrund (vgl. hierzu die Ausführungen in Abschn. 1.2).
- 9.
Die möglichen Ergebnisse werden durch stochastische Größen – d. h. durch bestimmte Wahrscheinlichkeiten – quantifiziert.
- 10.
Die ONR 49000 schlägt den Begriff des Szenarios vor. Nach ONR 49000, Pkt. 3.1.16 ist ein Szenario eine „konkrete und bildhafte Darstellung eines Risikos über mögliche Zusammenhänge von Ursachen und Abfolgen von Ereignissen oder Entwicklungen, die aufzeigt, wie sich Chancen bzw. Bedrohungen/Gefahren in einer Organisation oder in einem System verwirklichen lassen“.
- 11.
Allgemein stellt ein Risikoprofil die Beschreibung und Struktur einer Anzahl von Risiken dar (siehe ONR 49000, Pkt. 3.1.15).
- 12.
Gemäß ONR 49000, Pkt. 3.1.11 ist Risiko die Auswirkung von Unsicherheit auf Ziele. Die Quantifizierung des Risikos erfolgt durch eine Kombination von Wahrscheinlichkeit und Auswirkung, die Beschreibung über Szenarien, die Gefährdung sowie die Quellen bzw. Ursachen von Risiken.
- 13.
Versicherungsunternehmen müssen zur aufsichtsrechtlichen Erfüllung des Risikomanagements gemäß Pkt. 5 Nr. 2 MaRisk mindestens folgende Risikokategorien berücksichtigen: Versicherungstechnisches Risiko, Marktrisiko, Kreditrisiko, operationelles Risiko, Liquiditätsrisiko, Konzentrationsrisiko, strategisches Risiko, Reputationsrisiko.
Unter Solvency II hat das Risikomanagementsystem nach Art. 44 Abs. 2 RRL mindestens die Risiken abzudecken, die in die Berechnung der Solvenzkapitalanforderung im Sinne von Art. 101 Abs. 4 RRL einzubeziehen sind, sowie die Risiken, die bei dieser Berechnung nicht vollständig erfasst werden. Danach sind folgende Risikokategorien zu berücksichtigen: Nichtlebensversicherungstechnisches Risiko, lebensversicherungstechnisches Risiko, krankenversicherungstechnisches Risiko, Marktrisiko, Kreditrisiko, operationelles Risiko. Das operationelle Risiko umfasst auch Rechtsrisiken, schließt aber Risiken, die sich aus strategischen Entscheidungen ergeben, ebenso aus wie Reputationsrisiken (Art. 101 Abs. 4 RRL).
- 14.
In den MaRisk ist der Begriff Risiko explizit wirkungsbezogen definiert (siehe Erläuterungsteil zu Pkt. 5 Nr. 1 MaRisk), was insbesondere bei der Risikotragfähigkeit, der Limitierung und dem Risikokontrollprozess (Pkt. 7.3.1 und 7.3.2 MaRisk) zu berücksichtigen ist. In Solvency II wird ebenfalls ein wirkungsbezogener Risikobegriff zugrunde gelegt, was sich beispielsweise implizit aus Erwägungsgrund 64 RRL, Art. 101 Abs. 3 S. 4 RRL oder Art. 104 RRL ergibt (vgl. hierzu auch Art. 13 S. 1 Nr. 39 RRL).
- 15.
Siehe Erwägungsgründe 36, 63, 64 RRL und Art. 37, 45, 102, 110 RRL.
- 16.
Siehe beispielsweise Pkt. 5 Nr. 1 S. 4, Pkt. 7.1 Nr. 3, Pkt. 7.2.2.1 Nr. 1 und insbesondere Pkt. 7.3.1 Nr. 2 MaRisk.
- 17.
In Vektornotation ist die Varianz eines Risikoportfolios mit N näherungsweise linear abhängigen Risiken R = (R 1, …, R N) gegeben als Var PF = R T ⋅ C ⋅ R, wobei die N × N‐Matrix C die Varianz‐Kovarianz‐Matrix ist. Sie enthält in der Diagonalen die Varianzen Var ii = σiσi und in den restlichen Feldern die Kovarianzen Cov ij = ρijσiσj (ausgedrückt über die Korrelationskoeffizienten ρij).
- 18.
Siehe beispielsweise Erwägungsgründe 64, 65 RRL, Art. 121 Abs. 5 RRL sowie Pkt. 7.3.2.2 Nr. 2 MaRisk.
- 19.
Ein verbreiteter Fehler bei der Identifikation und Bewertung von Risiken basiert auf der Vorgabe, dass die Risikoeigner lediglich aufgefordert werden, die Risiken in ihrem Bereich zu benennen und eine Eintrittswahrscheinlichkeit sowie ein Schadenausmaß anzugeben. Man erhält dann entweder den häufigsten Wert oder den Erwartungswert samt Eintrittswahrscheinlichkeit zurück, aber nicht mit welcher Wahrscheinlichkeit eine bestimmte Schadenhöhe überschritten wird. Die so bestimmten Profile sind für eine ökonomische Bewertung ungeeignet und erfüllen die Anforderungen insbesondere von Solvency II nicht.
- 20.
Siehe Pkt. 7.3.1 Nr. 1 MaRisk.
- 21.
Gemäß der Art. 112 bis 126 RRL.
- 22.
Siehe Pkt. 7.3.1 Nr. 1 MaRisk und Art. 45 Abs. 1, Abs. 4 RRL. Die Vorgaben zu Solvency II sind bereits sehr konkret in aktuellen Dokumenten der EIOPA gefasst [EIOP13a].
- 23.
Die Ermittlung der Eigenmittel basiert auf einem Marktwertkonzept, sodass ein Übergang von der Buchwertsicht zu einer Marktwertsicht erfolgt, ähnlich wie es die International Financial Reporting Standards (IFRS) vorsehen. Die Unternehmen müssen sich also zwangsläufig mit den Bewertungsprinzipien von IFRS befassen [OeSB11].
- 24.
Siehe allgemein Art. 75 bis 81 RRL; für die Bonität Art. 75 Abs. 1 RRL.
- 25.
Siehe Art. 75, 77 RRL. Die Risikomarge CoCM (Cost‐of‐Capital‐Margin) ist bestimmt durch: \( CoCM=CoC\sum_{t\,{>}\,0}{EOF(t)\ DF(t)}\), wobei CoC der Kapitalkostensatz (Cost‐of‐Capital) ist, EOF(t) sind die im Jahr t benötigten Eigenmittel (Expected Own Funds), und DF(t) ist der zugehörige Diskontfaktor im Zeitintervall [0,t].
- 26.
In Art. 75 Abs. 1 Lit. a RRL findet sich nur die allgemeine Vorgabe, dass Vermögenswerte mit dem Betrag bewertet werden, „zu dem sie zwischen sachverständigen, vertragswilligen und voneinander unabhängigen Geschäftspartnern getauscht werden könnten“.
- 27.
Siehe Art. 76 Abs. 2 RRL.
- 28.
Siehe Art. 77 Abs. 1 RRL. Der beste Schätzwert entspricht gemäß Art. 77 Abs. 2 RRL dem Barwert des wahrscheinlichkeitsgewichteten Durchschnitts zukünftiger Zahlungsströme unter Berücksichtigung der risikofreien Zinskurve. Die zu addierende Risikomarge berücksichtigt gemäß Art. 77 Abs. 3 RRL die Kapitalkosten für die zur Übernahme der Verpflichtung notwendigen Eigenmittel.
- 29.
Siehe Art. 82 bis 84 RRL.
- 30.
Siehe Pkt. 7.2.2 Nr. 2 MaRisk, Spiegelstrich „Reservierung“. Die marktnahe Bewertung erfordert gemäß den MaRisk auch eine ausreichende Qualitätssicherung sowie klare Verantwortlichkeiten.
- 31.
Vgl. Art. 88 bis 91 RRL.
- 32.
Das Gegenparteiausfallrisiko trägt dem Risiko Rechnung, das sich aus einem unerwarteten Ausfall oder der Verschlechterung der Bonität von Gegenparteien und Schuldnern ergibt (Art. 105 Abs. 6 RRL).
- 33.
Die Solvency‐II‐Richtlinie enthält verschiedene Definitionen der SCR. Nach Art. 101 Abs. 3 S. 4 RRL entspricht die Solvenzkapitalanforderung „dem Value‐at‐Risk der Basiseigenmittel … zu einem Konfidenzniveau von 99,5 % über den Zeitraum eines Jahres“. Gemäß Erwägungsgrund 64 RRL sollte „die Solvenzkapitalanforderung bei dem ökonomischen Kapital angesetzt werden, das Versicherungs‐ und Rückversicherungsunternehmen halten müssen, um sicherzustellen, dass … diese Unternehmen mit einer Wahrscheinlichkeit von 99,5 % in den kommenden zwölf Monaten weiterhin in der Lage sein werden, ihren Verpflichtungen … nachzukommen“.
- 34.
Sei N t = A t − P t die Differenz zwischen den Aktiva A t und den Passiva P t zur Zeit t und DF(t) ein Diskontfaktor für das Zeitintervall [0,t]. Eine mögliche Interpretation des Art. 101 RRL wäre dann: SCR 0 = VaR 0,995(N 0 − DF(t)N 1). Falls DF r l ein stochastischer Diskontfaktor ist, der dem risikolosen Zins zur Zeit t entspricht, ist auch folgende Interpretation möglich [Flor11; OhLa09; ChNi12]: SCR 0 = VaR 0,995(N 0 − DF rl (t)N 1). Dabei kann der risikolose Zins durch verschiedenste Methoden ermittelt werden. Er kann aus theoretischen Modellen abgeleitet werden, oder er kann als Rendite von realen Bankkonten oder Rentenpapieren definiert werden.
- 35.
Gemäß Art. 128–129 RRL.
- 36.
Schwellenwerte und Limite sind Instrumente zur ökonomischen Risikosteuerung, die gewährleisten, dass die Risikotragfähigkeit eines Unternehmens bei der Umsetzung der Ziele aus der Geschäftsstrategie erhalten bleibt. Limite sind keine Kennzahlen, sondern gewissermaßen Indikatoren, die einen Bezug zwischen den quantifizierten Risiken, der Risikotragfähigkeit, dem Eingehen von Risiken sowie dem Nutzen von Chancen in bestimmten Unternehmenssituationen herstellen. Sie reduzieren die Komplexität bei Entscheidungen zur Optimierung des eigenen ökonomischen Chancen‐Risiko‐Profils unter Beachtung gesetzlicher Vorgaben sowie unternehmensindividueller Gegebenheiten. Limite sind bei Änderungen des Risikoprofils durch definierte Regeln konsistent anzupassen.
- 37.
Siehe Pkt. 7.3.1 Nr. 5 MaRisk sowie für Solvency II die Art. 44 Abs. 1 und 45 Abs. 1 S. 2 Lit. a RRL.
- 38.
Nach DIN 69901 ist ein Projekt ein Vorhaben, welches im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist. Nach ONR ISO 21500 wird ein Projekt dadurch bestimmt, dass es einmalig, terminlich determinierbar, komplex und abteilungsübergreifend ist und einen Beitrag zu den Zielsetzungen der durchführenden Organisation leistet. Nach PRINCE2 (Projects in Controlled Environments) [OGC09] ist ein Projekt eine für einen befristeten Zeitraum geschaffene Organisation, die mit dem Zweck eingerichtet wurde, ein oder mehrere Produkte in Übereinstimmung mit einem vereinbarten Business Case zu liefern.
- 39.
Vgl. hierzu Abschn. 3 der Verordnung über die berufliche Fortbildung im Bereich der Informations‐ und Telekommunikationstechnik (IT‐Fortbildungsverordnung – IT‐FortbV) vom 3. Mai 2002 (BGBl. I S. 1547). Gemäß § 11 Abs. 1 Nr. 1 IT‐FortbV ist ein Geprüfter IT‐Projektleiter nachweislich befähigt, „einmalige Vorhaben, die gekennzeichnet sind durch spezifische Ziele, zeitliche, finanzielle und personelle Begrenzungen sowie eine projektspezifische Organisation, in der Projekt‐ und Linienorganisation selbstständig und eigenverantwortlich zu leiten“. Er muss außerdem in der Lage sein, Prozesse zum „Erkennen und Begrenzen von Risiken“ durchführen zu können (§ 11 Abs. 2 Lit. e IT‐FortbV).
- 40.
Vgl. dazu die Ausführungen in Abschn. 1.2.
- 41.
Die IT‐FortbV folgt ebenfalls diesem Phasenmodell, verwendet jedoch den Begriff „Projektanbahnung“ anstelle von Projektinitiierung (§ 13 Abs. 2 S. 2 Nr. 1 IT‐FortbV) und umschreibt den Projektstart durch „Einrichten einer projektspezifischen Organisation, Rekrutieren des Projektpersonals sowie Auswählen der Arbeitsmittel, Festlegen von Standards und Konventionen“ (§ 11 Abs. 2 S. 1 Lit. c IT‐FortbV).
- 42.
Als Basis für eine Gap‐Analyse hinsichtlich der Konformität zu § 64a VAG i. V. m. MaRisk (VA) können die Checkliste in Anhang E.1 oder der MaRisk‐Prüfungsleitfaden des IIR [ReUn10] (www.diir.de/fileadmin/ak08/downloads/MaRiskLeitfadenFinal.doc, Stand Februar 2010, Abruf am 31.3.2013) dienen. Der Prüfungsleitfaden des DIIR berücksichtigt allerdings nicht die ebenfalls prüffähigen Punkte 1–3 der MaRisk (Zielsetzung, Anwendungsbereich, Compliance zu anderen Regelungen) sowie die Vorgaben zur internen Revision gemäß Pkt. 7.4 MaRisk. Zum IIR‐Prüfungsleitfaden existiert eine Vorlage als Tabellenkalkulation (MaRisk Basis Check: www.diir.de/file-admin/ak08/downloads/DIIRMaRiskBasisCheckfinal.xls, Stand Februar 2010, Abruf am 10.03.2014). Die Umsetzung als Tabellenkalkulation ist zwar ebenso wie der Prüfungsleitfaden nicht ganz vollständig und enthält kleinere Fehler und Schwächen bei einzelnen Zelleninhalten sowie bei der Aggregation, bietet aber aufgrund der Möglichkeit, Korrekturen und Erweiterungen selbst vorzunehmen, eine gute Ausgangsbasis für die Erstellung unternehmenseigener Werkzeuge – auch im Hinblick auf die Umsetzung von Solvency II.
- 43.
Version 1.4 des Modells ist über die Internetpräsenz der Beauftragten der Bundesregierung für Informationstechnik (BfIT) abrufbar: Das V‐Modell XT, www.cio.bund.de/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html (Abruf am 10.03.2014).
- 44.
Das V‐Modell XT eignet sich sehr gut für den Einsatz im Rahmen von komplexen Risikomanagementprojekten. Es ist ein flexibles Framework, das einen umfassenden, ausformulierten Katalog an Inhalten und integrierter Werkzeugunterstützung bietet. Siehe hierzu die umfangreiche Online‐Dokumentation unter http://ftp.tuclausthal.de/ pub/institute/informatik/v-modell-xt/Releases/1.4/V-Modell-XT-Gesamt.pdf (Abruf am 10.03.2014).
- 45.
Dies liegt daran, dass sich viele Rahmenbedingungen wie gesetzliche Vorgaben oder verfügbare Technologien im Umfeld des Risikomanagements vergleichsweise schnell ändern und die Projekte gewissermaßen Pioniercharakter besitzen.
- 46.
Kommunikation, Einfachheit, Feedback, Mut, Respekt.
- 47.
Menschlichkeit, Wirtschaftlichkeit, wechselseitiger Vorteil, Selbstähnlichkeit, Verbesserung, Vielfältigkeit, Reflexion, Fluss, Gelegenheit (wahrnehmen), Redundanz (vermeiden), Fehlschläge hinnehmen, Qualität, kleine Schritte, akzeptierte Verantwortung.
- 48.
Die Prinzipien lauten [Cock03, 199]: (1) Interaktive, direkte Kommunikation ist der günstigste und schnellste Kanal zum Austausch von Informationen; (2) übermäßiges Gewicht in der Methode ist kostspielig; (3) größere Teams benötigen schwerere Methoden; (4) kritische Projekte erfordern eine höhere Anzahl von Zeremonien; (5) die Zunahme von Feedbacks reduziert das Bedürfnis nach Zwischenergebnissen; (6) Disziplin, Fertigkeiten und Verständnis stehen Verfahren, Formalitäten und Dokumentation gegenüber; (7) in Aktivitäten ohne Flaschenhals ist Effizienz entbehrlich.
- 49.
Die Kritikalitätsstufen sind [Cock03, 204]: C (Comfort) – Auswirkung auf den Komfort der Benutzer; D (Discretionary Money) – Auswirkung auf den Verlust von Geldern innerhalb des Projektbudgets; E (Essential Money) – Auswirkung auf den Verlust von wesentlichen Geldern (für das Unternehmen bestandsgefährdend); L (Life) – Gefährdung von Menschenleben.
- 50.
Beispielsweise durch Change‐Management, Risiko‐Management oder Problem‐Management.
- 51.
Die Charakteristiken sind [High00]: missionsgesteuert, komponentenorientiert, iterativ, offen für Änderungen, risikogesteuert.
- 52.
Die Praktiken sind [High00]: Qualitätsprüfungen, Joint Application Development Sessions, Lessons learned Sessions, Beta‐Testing, Projektvision, Dokumentation der Projektdaten, Produktspezifikation.
- 53.
Die Prozesse sind: Gesamtmodell entwickeln; Feature‐Liste erstellen; Plan je Feature erstellen; Feature entwerfen; Feature umsetzen.
- 54.
Im Japanischen bedeutet: Kan – Signal, Ban – Karte.
- 55.
Im Japanischen bedeutet: Kai – Veränderung, Zen – zum Besseren.
- 56.
In der Praxis für den KVP verbreitet sind: tägliche Besprechungen zu Status, Problemen und Lösungen; unregelmäßige Sitzungen mit dem gesamten Projektteam, um nächste Ziele und die nächsten Schritte zu besprechen; Fehler‐Ursachen‐ oder Problem‐Quellen‐Analysen.
- 57.
Das Pull‐System basiert auf quantitativen Überlegungen zu Warteschlangenmodellen [LZGS84; Thon11]. Einfache Ein‐Kanal‐Systeme mit unendlichem Warteraum (sog. M/M/1‐Systeme [Kend53]) können durch die Ankunftrate λ, die Bedienrate μ und die Auslastung ρ = λ/μ beschrieben werden. Die mittlere Länge der nicht‐leeren Schlange mit den tatsächlich wartenden Aufträgen ist Ln = λ/(μ − λ). Die Schlangenlänge aller Aufträge ist Lq = ρ2/(1 − ρ) [Zimm08].
- 58.
Zur Steuerung werden typische Größen wie Warteschlangenlängen, Arbeitsdurchsatz und Bearbeitungszeiten gemessen.
- 59.
Dies betrifft z. B. die Definition von „fertig“ für jedes Teilergebnis; Festlegungen von Prioritäten und „wer darf was, wann, wie machen“ (Definition von Service Level Agreements – SLA) usw.
- 60.
Literatur
Anderson, D. J.: Kanban – Evolutionäres Change Management für IT‐Organisationen. dpunkt Verlag, Heidelberg 2011.
Baetge, J.; Jerschensky, A.: Frühwarnsysteme als Instrumente eines effektiven Risikomanagement und ‐Controlling. Controlling 11 (1999) 171.
Balzert, H.: Lehrbuch der Softwaretechnik: Softwaremanagement. Spektrum Akademischer Verlag, Heidelberg 2008.
Beck, K.: Extreme Programming Explained – Embrace Changes. Addison‐Wesley, Reading 2000.
Beck, K.: Embracing Changes with Extreme Programming. IEEE Computer 32 (1999) 10, S. 70.
Bergeron, F.; St‐Arnaud, J. Y.: Estimation of information systems development efforts: a pilot study. Information and Management 22 (1992) 239.
Boehm, B. W.: Software Engineering Economics. Prentice Hall, Englewood Cliffs 1981.
Boehm, B. W.: A Spiral Modell of Software Development and Enhancement. IEEE Computer 21:5 (1988) 61.
Boehm, B. W.: A Spiral Modell of Software Development and Enhancement. ACM SIGSOFT 13:8 (1988) 61.
Burger, A.; Buchhart, A.: Risiko‐Controlling. Oldenburg, München, 2002.
Bullinger, H.‐J.; Warschat, J. (Hrsg.): Forschungs‐ und Entwicklungsmanagement: Simultaneous Engineering, Projektmanagement, Produktplanung, Rapid Product Development. Teubner, Stuttgart 1997.
Bullinger, H.‐J.; Warnecke, H. J.; Westkämper, E. (Hrsg.): Neue Organisationsformen im Unternehmen: Ein Handbuch für das moderne Management. Springer, Berlin 2003.
Bundesamt für Wehrtechnik und Beschaffung (BWB): Entwicklungsstandard für IT‐Systeme des Bundes. BWB IT IS, Allgemeiner Umdruck Nr. 250/1, Koblenz 1997.
Christiansen, M; Niemeyer, A.: The fundamental definition of the Solvency Capital Requirement in Solvency II. Preprint Series 2012‐02. Fakultät für Mathematik und Wirtschaftswissenschaften, Universität Ulm 2012.
Chrisians, U.: Performance Management und Risiko: Strategieumsetzung mit risikoorientierter Balanced Scorecard, Wissensbilanzen und Werttreibernetzen. Berliner Wissenschafts‐Verlag, Berlin 2006.
Cockburn, A.: Agile Software Development. Addison‐Wesley, Reading 2002.
Cockburn, A.: Agile Software‐Entwicklung. mitp‐Verlag, Heidelberg 2003.
Coenenberg, A. G.; Haller, A.; Schultze, W.: Jahresabschluss und Jahresabschlussanalyse: Betriebswirtschaftliche, handelsrechtliche, steuerrechtliche und internationale Grundlagen – HGB, IAS/IFRS, US‐GAAP, DRS. Schäffer‐Poeschel, Stuttgart 2012.
Coldeway, J.: Agile Entwicklung Web‐basierter Systeme – Einführung und Überblick. WIRTSCHAFTSINFORMATIK 44 (2002) 237.
Deming, W. E.: Out of the crisis. MIT Center for Advance Engineering Study, MIT Press, Cambridge 1986.
Dröschel, W.; Wiemers, M. (Hrsg.): Das V‐Modell 97. Oldenburg, München 2000.
EIOPA: Leitlinien zur vorausschauenden Beurteilung der eigenen Risiken (basierend auf den ORSA‐Grundsätzen). 31. Oktober 2013, EIOPA‐CP‐13/09 DE.
EU: Richtlinie 2009/138/EG des Europäischen Parlamentes und des Rates betreffend die Aufnahme und Ausübung der Versicherungs‐ und der Rückversicherungstätigkeit (Solvabilität II). Amtsblatt der Europäischen Union L 335 vom 17.12.2009.
Faisst, U.; Buhl, H. U.: Integrated Enterprise Balancing mit integrierten Ertrags‐ und Risikodatenbanken. WIRTSCHAFTSINFORMATIK 47 (2005) 403.
Filipovic, D.: Multi‐level risk aggregation. Astin Bulletin 39 (2009) 565.
Flyvbjerg, B.; Budzier, A.: Why Your IT Project Might Be Riskier Than You Think. Harvard Business Review 89:9 (2011) 23.
Floreani, A.: Risk margin estimation through the cost of capital approach: Some conceptual issues. The Geneva Papers on Risk and Insurance – Issues and Practice 36 (2011) 226.
Floyd, C.: A Systematic Look at Prototyping. In: Budde, R.; Kantz, K.; Kuhlenkamp, K.; Züllighoven, H. (Eds.): Prototyping – An Approach to Evolutionary System Development. Springer, Berlin 1984, S. 1.
Forrester, J. W.: Industrial Dynamics. Pegasus Communications, Westford 1961.
Förterer, J.: Ertrags‐ und Risikosteuerung von Lebensversicherern aus finanzmarkttheoretischer Sicht: ein Ansatz zum Asset/Liability Management. Verlag Versicherungswirtschaft, Karlsruhe 2000.
Freeman, R. E.: Strategic Management: A Stakeholder Approach. Cambridge University Press, New York 2010.
Fuchs, S.; Ludwig, A.; Schmidt, K. D.: Zur Exaktheit der Standardformel. Zeitschrift für die gesamte Versicherungswissenschaft 102 (2013) 87.
Günther, B.; Bach, F.; Karau, T.; Drechsler, S.: Ableitung eines Limitsystems aus dem internen Risikomodell und der Einfluss des Allokationsverfahrens. Zeitschrift für Versicherungswesen 62 (2011) 359.
Ausschuss Betriebswirtschaft und Informationstechnologie, Gesamtverband der Deutschen Versicherungswirtschaft e. V. (Hrsg.): FAQ Solvency II – Betriebstechnische Hinweise. Band 40 der Schriftenreihe Betriebswirtschaft und Informationstechnologie des GDV, Berlin 2012.
Goldratt, E. M.; Cox, J.: The Goal: A Process of Ongoing Improvement. North River Press, Great Barrington 1984.
Grelck, M.; Stahl, D.: Umsetzung eines Solvency II‐Projektes. Versicherungswirtschaft 59 (2004) 249.
Hanser, E.: Agile Prozesse: Von XP über Scrum bis MAP. Springer, Heidelberg 2010.
Highsmith, J. A. III.: Adaptive Software Development Ecosystems: Problems Principles and Practices. Dorset House, New York 2000.
Höhn, R.; Höppner, S.: V‐Modell XT: Grundlagen, Methodik und Anwendungen, Springer Berlin 2008.
Imai, M.: Kaizen – Der Schlüssel zum Erfolg der Japaner im Wettbewerb. Ullstein, Berlin 2000.
Ishikawa, K.: What is Total Quality Control? The Japanese Way. Prentice Hall, Engelwood Cliffs 1985.
Jenkins, A. M.; Naumann, J. D.; Wetherbe, J. C.: Empirical investigation of systems development practices and results. Information and Management, 7 (1984) 73.
Kaplan, S.; Garrick, B. J.: On the quantitative definition of risk. Risk Analysis 1 (1981) 11.
Kendall, D. G.: Stochastic Processes Occurring in the Theory of Queues and their Analysis by the Method of the Imbedded Markov Chain. The Annals of Mathematical Statistics 24 (1953) 338.
Kerzner, H.: Projektmanagement: Ein systemorientierter Ansatz zur Planung und Steuerung. mitp‐Verlag, Heidelberg 2008.
Kloman, H. F.: Risk Management Agonists. Risk Analysis 10 (1990) 201.
Kieback, A.; Lichter, H.; Schneider‐Hufschmidt, M.; Züllighoven, H.: Prototyping in industriellen Software‐Produkten. Informatik‐Spektrum 15 (1992) 65.
Kolmogorov, A. N.: Grundbegriffe der Wahrscheinlichkeitsrechnung. Springer, Berlin 1933.
Kriele, M.; Wolf, J.: Wertorientiertes Risikomanagement von Versicherungsunternehmen. Springer, Heidelberg 2012.
Lay, W.: Risikobilanzierung unter Solvency II für deutsche Lebensversicherungsunternehmen aus aktuarieller Sicht. Zeitschrift für die gesamte Versicherungswissenschaft 100 (2011) 3.
Lüpschen, H.: A‐Process – Effektive Softwareentwicklung. Oldenburg, München 2002.
Lazowska, E. D.; Zahorjan, J.; Graham, G. S.; Sevcik, K. C.: Quantitative System Performance – Computer System Analysis Using Queueing Network Models. Prentice Hall, Englewood Cliffs 1984.
Malorny, C.: TQM umsetzen – der Weg zur Business Excelence. Schäffer‐Poeschel, Stuttgart 1999.
McNeil, A. J.; Frey, R.; Embrechts, P.: Quantitative Risk Management: Concepts, Techniques, Tools. Princeton University Press, Princeton 2005.
Nelson, R. B.: An Introduction to Copulas. Springer, New York 2006.
Oehlenberg, L.; Stahl, G.; Bennemann, C.: Von der Standardformel zum Internen Modell – ein Überblick über Solvency II. In: Bennemann, C.; Oehlenberg, L.; Stahl, G. (Hrsg.): Handbuch Solvency II. Schäffer‐Poeschel, Stuttgart 2011, S. 3.
Office of Government Commerce: Erfolgreiche Projekte managen mit PRINCE2®. The Stationery Office, Norwich 2009.
Ohlsson, E. and Lauzeningks, J.: The one‐year non‐life insurance risk. Insurance: Mathematics and Economics 45 (2009) 203.
Ohno, T.: Toyota Production System. Productivity, Portland 1988. (Japanischer Originaltext: Toyota seisan hoshiki. Diamond, Tokyo 1978).
Ohno, T.: Das Toyota‐Produktionssystem. Campus, Frankfurt/Main 1993.
Palmer, S. R.; Felsing, M.; Palmer, S.: A Practical Guide to Feature‐Driven Development. Pearson – Prentice Hall, London 2002.
Phan, D.; Vogel, D.; Nunamaker, J.: The Search for Perfect Project Management. Computerworld o. J. (1988) S. 95.
Rausch, A.; Broy, M.: Das V‐Modell XT: Grundlagen, Erfahrungen und Werkzeuge. dpunkt Verlag, Heidelberg 2008.
Reichardt, S.; Unmuth, A.: Leitfaden für eine Prüfung des Risikomanagements nach MaRisk in Versicherungsunternehmen. ZIR 45 (2010) 66.
Ricketts, I. W.: Software‐Projektmanagement kompakt. Springer, Heidelberg 1998.
Rising, L.; Janoff, N. S.: The Scrum Software Development Process for Small Teams. IEEE Software 17 (2000) July, S. 26.
Royce, W. W.: Managing the Development of Large Software Systems: Concepts and Techniques. Proc. of IEEE Western Electronic Show and Convention, WESCON, 26 (August 1970) 1. Nachdruck in: Proc. of the 9th Int. Conf. on Software Engineering, Monterey, CA, 1987, S. 328.
Sauer, S.; Cuthbertson, C.: The State of IT Project Management in the UK, Templeton College, Oxford 2003.
Sauer, C.; Gemino, A.; Reich, B. H.: The impact of size and volatility on IT project performance. Communications of the ACM 50:11 (2007) 79.
Saliger, E.: Betriebswirtschaftliche Entscheidungstheorie. Oldenburg, München 2003.
Schwaber, K.; Beedle, M.: Agile Software Development with Scrum. Prentice Hall, Englewood Cliffs 2002.
Schöneborn, F.: Strategisches Controlling mit System Dynamics. Physica‐Verlag Heidelberg, November 2003.
Senge, P.: The Fifth Dicipline – The Art & Practice of The Learning Organization. Currency Doubleday, New York 1990.
Spitczok von Brisinski, N.; Vollmer, G.: Pragmatisches IT‐Projektmanagement: Softwareentwicklungsprojekte auf Basis des PMBOK® Guide führen. dpunkt Verlag, Heidelberg 2010.
The Standish Group: Chaos Chronicles Version 3.0. West Yarmouth 2003.
Thonemann, U.: Operations Management – Konzepte, Methoden und Anwendungen. Pearson Studium, München 2011.
Tiemeyer, E. (Hrsg.): Handbuch IT‐Projektmanagement: Vorgehensmodelle, Managementinstrumente, Good Practices. Carl Hanser, München 2010.
Welge, M. K.; Al‐Laham, A.: Strategisches Management: Grundlagen – Prozess – Implementierung. Springer‐Gabler, Wiesbaden 2012.
Wegener, I.: Komplexitätstheorie: Grenzen der Effizienz von Algorithmen. Springer, Berlin 2003.
Wells, T. D.: Dynamic Software Development – Managing Projects in Flux. Auerbach Publications – CRC Press, London 2012.
Wieczorrek, H. W.; Mertens, P.: Management von IT‐Projekten: Von der Planung zur Realisierung. Springer, Berlin 2010.
Wintersteiger, A.: Scrum: Schnelleinstieg. entwickler.press, Frankfurt 2012.
Wolf, H.; Bleek, W.‐G.: Agile Softwareentwicklung – Werte, Konzepte und Methoden. dpunkt Verlag, Heidelberg 2010.
Womak, J. P.; Jones, D. T.: Lean Thinking: Ballast abwerfen, Unternehmensgewinn steigern. Campus, Frankfurt/Main 2004.
Womak, J. P.; Jones, D. T.: From Lean Production to the Lean Enterprise. Harvard Business Review (1994) March‐April, S. 93.
Womak, J. P.; Jones, D. T.: Lean Thinking. Simon & Schuster, New York 1996.
Wolf, H. (Hrsg.): Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen: Erfahrungsberichte aus der Praxis. dpunkt Verlag, Heidelberg 2012.
Wolle, B.; Müller, V.: Prozessorientiertes IT‐Qualitätsmanagement. HMD – Praxis der Wirtschaftsinformatik 40:232 (2003) 66.
Wolf, H.; Roock, S.; Lippert, M.: eXtreme Programming. dpunkt Verlag, Heidelberg 2005.
Zimmermann, H.‐J.: Operations Research: Methoden und Modelle. Vieweg, Wiesbaden 2008.
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
Copyright information
© 2014 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Wolle, B. (2014). Entwicklung von Risikomanagementsystemen. In: Risikomanagementsysteme in Versicherungsunternehmen. IT im Unternehmen. Springer Vieweg, Wiesbaden. https://doi.org/10.1007/978-3-8348-2309-0_3
Download citation
DOI: https://doi.org/10.1007/978-3-8348-2309-0_3
Published:
Publisher Name: Springer Vieweg, Wiesbaden
Print ISBN: 978-3-8348-1910-9
Online ISBN: 978-3-8348-2309-0
eBook Packages: Computer Science and Engineering (German Language)