Monatsarchiv: April 2012

Chancen aus MaRisk und MaComp

Die Mindestanforderungen an das Risikomanagement (MaRisk) und die Mindestanforderungen an die Compliance-Funktion (MaComp) stellen hohe Anforderungen an Finanzdienstleiser. Die Einführung der MaRisk und der MaComp und deren kontinuierliche Sicherstellung erfordert Aufwände. Dennoch bieten die Ergebnisse nach deren Umsetzung auch erhebliche Chancen für die jeweiligen Institute.

Effiziente MaRisk und MaComp Compliance

Sowohl bei der Einführung als auch im Rahmen der permanenten Sicherung der MaRisk und MaComp sollten Institute das Rad nicht neu erfinden. Es gibt mitlerweise eine Vielzahl von Standards bzw. Best Practices für die Finanzwirtschaft, die große Teile der aus den MaRisk resultierenden Erfordernissen sehr effizient sicherstellen. Natürlich bleiben hierbei immer institutsspezifische Sonderfälle und -bereiche, die nicht abgedeckt werden. Dennoch gilt, dass es für über 90% der Anforderungen verlässliche Standards und Best Practices gibt. Hierbei sind insbesondere die folgenden drei Bereiche zu erwähnen:

  • Prozessdokumentation: Hier sollte auf jeden Fall auf etablierte Best Practices zurückgegriffen werden um die Entwicklungsaufwände in engen Grenzen zu halten. Internationale Standards, wie Business Process Modell and 2.0 von der (Object Management Group), die ARIS Methodik (eEPK, VKD, etc.) und das Tool ARIS der Software AG oder ein striktes Festhalten an einfachem UML kann die hier entstehenden Aufwände signifikant senken. Sofern man noch vor der Einführung steht, kann hierfür auch auf das TOGAF Framework zurückgegriffen werden. Insbesondere bei Änderungen (der MaRisk, Technologien oder anderer Best Practice Erfahrungen) ist daurch auch immer ein sicherer Migrationspfad sichergestellt. Bei Eigenentwicklungen kann in einem solchen Fall ein signifikanter Entwicklungsaufwand entstehen, der dann im Rahmen des operativen Geschäfts gestemmt werden muss.
  • Risk Management: Hier empfiehlt es sich in jedem Fall der Rückgriff auf den COSO Standard, da eine fallspezifische Prüfung und Umsetzung ansonsten sehr viel juristische Kenntnisse im operativen Betrieb verlangt. Der COSO Standard stellt eine ideale Grundlage zur einfachen Umsetzung z.B. in Form von Templates (zur Risiko- und Prüfdokumentation) oder standardisierten Prozessen (Risikoüberblick und Risikostrategien) bereit.
  • Compliance: Hier ist die Umsetzung der vom Bundesverband Deutscher Banken herausgegebenen Best Practice höchst empfehlenswert. Auch hier bedeutet eine eigenständige rechtliche Sicherstellung aller relevanten Anforderungen einen signifikanten Aufwand, der sich vermeiden lässt. Natürlich können und sollten basierend auf dieser Best Practice zusätzlich weitere institutsspezifische Vorgaben gemacht werden.

Chancen aus den MaRisk und MaComp

Nach der erfolgreichen Einführung und Umsetzung der MaRisk und MaComp bietet sich dem jeweiligen Institut und seinem Management ein erheblicher Mehrwert, der aber in vielen Fällen nicht erkannt oder realisiert wird. Laut PPI besteht beispielsweise bei 80% der Versicherer erheblicher Handlungsbedarf. So lassen sich nach einer erfolgten Dokumentation der risikorelevanten Prozesse viele management-relevante Informationen im Rahmen von Business Intelligence (BI) nutzen (z.B. „An welchen Stellen wird Kontakt zu einer anderen Institution / Behörde aufgenommen?“, „An welchen Stellen entstehen im Kundenkontakt relevante Bonitätsinformationen?“ oder „Welche Risiken treten im Kreditprozess auf, bzw. an welcher Stelle?„). Die Einführung von Best-Practices ermöglicht aber auch einen einfacheren Austausch und eine effizientere Zusammenarbeit mit anderen Marktteilnehmern. Sowohl auf der technischen Ebene ist eine Anbindung an third-party System wesentlich einfacher zu gestalten, als auch auf  fachlicher Ebene ist das Mapping der jeweiligen Fachbegriffe höher, was eine Abstimmung der Cooperation wiederum vereinfacht.

Fazit

Durch die MaRisk in das Managementsystem wird eine leistungsfähige, effiziente und dynamische Organisation geschaffen, die:

  • Sicherheit bei der Erfüllung interner und externer Forderungen gibt (dies schließt gesetzliche Anforderungen ein);
  • die Qualität der Produkte und Services erhöht;
  • die Kosten durch Fehlerminimierung reduziert;
  • dabei unterstützt, Doppelregelungen zu vermeiden;
  • klare Prozesse bereitstellt, deren Wirksamkeit und Effizienz messbar ist;
  • Risiken eng begrenzen;
  • systematisch Verbesserungspotenziale erkennen und nutzen lässt;
  • das Verantwortungsbewusstsein der Mitarbeiter stärkt;

Weiterführende Informationen

Weite Informationen zu den MaRisk und deren Umsetzung finden Sie hier.

Weiter Informationen zu COSO und dem IKS finden Sie hier.

Author: Dr. Levin Brunner
Dr. Brunner studierte an der TU München Informatik, promovierte in Computerlinguistik an der LMU im Bereich semantic Web und ist seit mehreren Jahren als Berater im Prozess- und Qualitätsmanagement tätig. Er hat sich in verschiedenen Projekten mit der Evaluation passender Best Practices und Standards beschäftigt und befasst sich intensiv mit den Themen Compliance, Business Intelligence sowie Knowledge und Information Management.

Advertisements

Scrum – Elemente des Projektmanagement

Scrum besteht aus diversen (erstaunlich strikt) definierten Elementen. Die wichtigsten sollen hier vorgestellt werden. Da Scrum ursprünglich aus der Softwareentwicklung kommt, sind evtl. einige der hier Verwendeten Begrifflichkeiten ebenfalls aus diesem Bereich (z.B. Entwicklerteam). Generell ist Scrum aber für alle Projekte einsetzbar. Die Elemente werden hier der Übersichtlichkeit halber in 3 Kategorien eingeteilt: Rollen, Prozesse, (Hilfs-)Mittel

Rollen:

  1. Product Owner (PO):
    Er ist der Auftraggeber / der Kundenvertreter. Er entscheidet (alleine), was im Rahmen des Projektes erreicht wird (Projekt-Endprodukt). Der PO unterteilt den Leistungsumfang in einzelne Anforderungen und koordiniert alle Stakeholder (Personen mit Interesse am Projektergebnis);
  2. Scrum Master:
    Der Scrum Master erfüllt eine ähnliche Rolle wie der Projektmanager, auch wenn dies nach akademisch-theoretischen Gesichtspunkten so nicht gesagt werden kann – darf – sollte. Im Gegensatz zu einem Projektmanager ist er ein gleichberechtigtes Team-Mitglied, das mit den drei Sonderaufgaben „Einhaltung der Scrum Regeln“, „Beseitigung externer Störfaktoren“ und „Reporting nach Außen“ betraut ist.
  3. Entwickler-Team:
    Das Umsetzungs- / Entwickler-Team besteht laut Scrum aus 5 bis 9 Personen, die die Umsetzung der Anforderungen erledigen. Sollte eine erheblich größere Anzahl an Teammitgliedern benötigt werden, kann jedes Teammitglied wiederum ein eigenes Scrum Projekt als aufsetzen („Scrum of Scrums“). Dabei sind die Teammitglieder des übergeordneten Scrum Projektes die Product Owner der untergeordneten Scrum Projekte.
  4. Scrum-Team:
    Das Scrum Team umfasst das Entwicklerteam, den Scrum Master und den Product Owner.
  5. Externe Rollen:
    Auch in Scrum gibt es natürlich weitere definierte Rollen, die aber nicht Teil des Scrum-Team sind wie z.B. „User“, „Käufer“, „Line Manager“ etc.

Prozesse:

Scrum Phasen

Die Pasen des Scrum

  1. Daily Scrum:
    Tägliches, maximal 15-minütiges Treffen, bei dem alle Teammitglieder ihre Vorschritte berichten (nur berichten NICHT diskutieren oder Ideen entwickeln, der Scrum Master muss diszipliniert auf die maximal 15 Minuten achten). Das Meeting soll im Stehen durchgeführt werden, um zu zeigen, dass es kurz und ungeregelt ist. Am besten findet es direkt vor dem Sprit Backlog statt. Folgende drei Fragen werden berichtet: Was ist seit gestern gemacht worden? Was wird bis morgen gemacht? Welche Hindernisse bestehen aktuell / auf was wird gewartet?
  2. Sprint Planning Meeting (SPM):
    Im SPM setzt sich das ganze Scrum-Team zusammen und der Product Owner erklärt die Anforderungen aus dem Product Backlog. Das Team wählt davon eine Sammlung von (den nach Möglichkeit höchstpriorisierten) Anforderungen aus, die innerhalb von max. 30 Tagen umsetzbar sind und nimmt diese auf den Sprint Backlog.
  3. Sprint Review Meeting:
    Nach dem Ablschluss eines Sprints setzt sich das Team zusammen und versucht aus den aufgetretenen Problemen und ergriffenen Chancen Verbesserungsvorschläge für zukünftige Sprints zu erarbeiten.

Mittel:

  1. Product Backlog (oder Produkt Liste):
    Priorisierte Liste von Anforderungen (sog. Items) an das Projekt-Endprodukt. Das Product Backlog ist allen Teammitgliedern jederzeit zugänglich und wird permanent aktualisiert.
  2. Sprit Backlog:
    Der Sprint Backlog enthält die Items, die im aktuellen Sprint abgearbeitet werden sollen.
  3. Impediment Backlog:
    Eine Liste aller Hindernisse, die die Mitglieder des Entwicklerteams für den Scrum Master pflegen, damit er diese Hindernisse lösen kann.
  4. Burndown Charts:
    Abgesehen von den Backlogs also den Listen legt Scrum zur Fortschrittsüberwachung wert auf die Burndown charts. Diese Charts zeigen den aktuellen Entwicklungsstand im Gesamtkontext an. Burndown Charts können sowohl innerhalb eines Sprints verwendet werden, als auch um die Entwicklung der Sprints im Gesamtprojekt darzustellen. Hier gibt es einige hübsch Burndown Charts.

Einen detailierteren und tieferen und sehr schönen Einblick in Scrum bekommt man hier.

Der Artikel wurde von TomQB veröffentlicht.

Scrum – Kurze Einführung

Scrum hat sich heute zu einem Standardvorgehen für das Projektmanagement entwickelt. Ursprünglich ist Scrum als Trend im Bereich der Softwareentwicklung(-sprojekte) entstanden.

Scrum ist der Innbegriff einer agilen  und iterativen Methode. Agil in diesem Zusammenhang bedeutet, dass die Methode zur Erreichung eines Ziels sofort viele, dynamische, kleine Einzelschritte umsetzt anstatt einen großen und umfassenden Projektplan zu erstellen. Iterativ bedeutet, dass das selbe Vorgehen in jedem einzelnen kleinen Schritt wieder angewendet wird, um das finale Ziel letztendlich zu erreichen.

Beispiel:
Praktisch bedeutet das, dass wenn ich z.B. eine Suchmaschine programmieren will, dann ist der erste Schritt, auf dem Bildschirm ein erstes Suchfenster anzuzeigen. Der erste Schritt ist dann schnell gemacht. Ein einfaches html-Formular reicht. Dann kann ich mich in einem zweiten Schritt darum kümmern eine Webseite suchbar zu machen. Im dritten Schritt zeige ich die Ergebnisse an. Und jetzt kann ich mich iterativ darum kümmern, noch eine Webseite zu durchsuchen, dann das Intranet, dann den Fileserver, dann kann ich zur Suche Facetten hinzufügen etc. Im Gegensatz zum klassischen Projektmanagement funktioniert bei Scrum die Suche aber schon extrem frühzeitig (ab Schritt 3 läuft die Suche permanent). Im Klassischen Projektmanagement wird das Projekt-Endziel (-Produkt)  ebenso erreicht, aber es liegt kein so großer Fokus darauf, dass während der Entwicklung das System schon läuft.

Wichtige Elemente (Rollen, Prozesse etc.) von Scrum werden hier erläutert.

Dieser Artikel wurde erstmalig hier veröffentlicht.

MaRisk als treibendes Compliance Thema im Finanzsektor

Da wir in den letzten Monaten und Jahren in mehreren Projekte im Finanzumfeld tätig waren und wir dabei immer wieder auf die MaRisk (Mindesanforderungen an das Risikomanagement) gestoßen sind, haben wir das Thema versucht in einem Flyer zusammenzufassen. Insbesondere da die MaRisk Compliance in den meisten Fällen einen hohen Umsetzungsaufwand mit sich bringt, haben wir ein prozessgestütztes Vorgehen entwickelt, das die Umsetzung der aktuellen Anforderung mit einem möglichst effizienten Vorgehen sicherstellt.

Dokumentation der MaRisk und einbindung in Prozessmanagement

Dokumentation der MaRisk und einbindung in Prozessmanagement

Unseren Flyer finden Sie hier:

http://www.q-4.biz/q4_MaRisk_Prozessmanagement-245.html

Die aktuellen MaRisk finden Sie hier:

http://www.bafin.de/cln_152/nn_721290/SharedDocs/Veroeffentlichungen/DE/Service/Rundschreiben/2010/rs__1011__ba__marisk.html?__nnn=true