Benutzer anlegen in ARIS

Im gesamten ARIS-Umfeld gibt es eine Vielzahl von anfallenden Aufgaben, welche erledigt werden müssen. Um auch die entsprechenden Personen berechtigen zu können, ist es unabdingbar an Hand eines Rollen-Konzeptes die Verantwortungen zu definieren. Hierbei hat es sich bewährt, zwischen einzelnen Benutzern und sogenannten Benutzergruppen (mehrere Benutzer) zu differenzieren. Man hat damit die Möglichkeit Aufgaben und Verantwortungen klar bestimmten Benutzern oder Benutzergruppen zuzuordnen. Erst dadurch wird eine reibungslose Handhabung mit einem BPM-Tool möglich

In folgendem Beitrag werden wir Ihnen erklären wie Sie in ARIS Benutzer anlegen können und was dabei zu beachten ist.

Nachdem Sie definiert haben, welche Rollen, bzw. Benutzer es geben soll (Rollen- bzw. Berechtigungskonzept) wechseln Sie in das Modul „Administration“. Nur dort können Sie Einstellungen zu den Benutzern vornehmen.

Wenn Sie mit einem Klick die entsprechende Datenbank markieren, sehen Sie im rechten Bildabschnitt alles was mit Benutzern zu tun hat.

Hier können Sie auch Benutzer anlegen.
Klicken Sie hierzu auf den Punkt .

Jetzt öffnet sich der so genannte Benutzer-Assistent. Dort müssen Sie Schritt für Schritt vorgehen.
Füllen Sie nach und nach die Punkte aus, bestätigen Sie jeweils mit weiter und klicken bei Schritt 6: „Eingaben bestätigen“ auf „Fertig stellen“.

1. Schritt: Benutzer anlegen
Hier können Sie den Benutzernamen vergeben, ggf. ein Kennwort anlegen und entscheiden ob der Benutzer ein Systembenutzer sein soll. Ein Systembenutzer hat alle Rechte.

2. Schritt: Benutzergruppenzuordnung
Hier können Sie dem Benutzer eine ggf. angelegte Benutzergruppe zuweisen, sofern das gewünscht ist. z.B. kann eine Benutzergruppe die „Systemverantwortlichen“ sein.

3. Schritt: Identifizierer
Der Identifizierer wird hauptsächlich dazu verwendet, um einzelne Datenbankinhalte mit einem schnellen Blick zuordnen zu können. Beispiele für Zuordnungen bei Modellen und Objekten:

• Zuordnung zu Referenzmodellen
• Zuordnung zu verschiedenen Teildatenbanken (z.B. anderer Standort etc.)

4. Schritt: Funktionsrechte
Mit Hilfe der Funktionsrechte stellen Sie Benutzern bestimmte Funktionalitäten zur Verfügung und konfigurieren damit deren funktionale Befugnisse.

Folgende Funktionsrechte gibt es:

• Anzeige Benutzerverwaltung
• Benutzerverwaltung
• Change Management
• Datenbankadministration
• Datenbankexport
• Methodische Änderungen
• Präfixverwaltung
• Schriftformatverwaltung
• Attributformatierung

5. Schritt: Methodenfilter
Alle in der Konfigurationsdatenbank enthaltenen Methodenfilter sind aufgelistet.

6. Schritt: Eingaben bestätigen
Hier sehen Sie noch einmal Ihre Eingaben und können diese final bestätigen.

Nun sehen Sie den angelegten Benutzer im rechten Bildabschnitt wie nachfolgend gezeigt.

Selbstverständlich ist uns bewusst, dass dieser Artikel in keinem ausreichenden Maße die Komplexität eines professionellen Benutzerkonzeptes erklärt. Das würde auch den Rahmen dieses Blogbeitrags sprengen. Wir haben jedoch ein Musterbenutzerkonzept in Word erstellt, welches Sie oder Ihre Firma natürlich bei uns anfordern können. Bitte nehmen Sie einfach Kontakt mit dem Autor auf.

Über den Autor:

Felix Hahn ist seit mehreren Jahren als Berater im Prozess- und Qualitätsmanagement mit ARIS und ibo 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, Business Process Management etc. Den Autor können Sie unter f.hahn@q-4.biz kontaktieren.

www.q-4.biz
Q-4 GmbH
Pariser Str. 50
81667 München

ARIS Reports und Makros importieren

Importieren von Reports (Berichten) oder Makros in ARIS

Sie möchten die Struktur Ihres Unternehmens kennen und verstehen? Sie wollen die Risiken und Schwachstellen in Ihrem Unternehmen identifizieren und ausmerzen. Sie wollen Ihre Modelle vergleichen? Oder wollen Sie  eine Übersicht automatisch generieren, wenn in Ihren Modellen etwas geändert wird?

Diese und andere Wünsche beschäftigen viele Führungskräfte. ARIS Reports (Berichte) und Makros können Ihnen durch die Darstellung der gewünschten Daten in einer grafischen Art und Weise helfen. Heute möchten wir Ihnen zeigen wie man ARIS Reports (Berichte) und Makros einrichtet und pflegt.

Um die Reports und Makros in ARIS nutzen zu können, müssen diese importiert werden. Hierzu ist es notwendig, dass Sie über einen ARIS Business Architekt verfügen, da zur Durchführung des Importes das Verwaltungsmodel (Administration) benötigt wird. Wenn Sie nur über den Business Designer verfügen, müssen Sie in jedem Fall Ihren ARIS Administrator bitten, Reports oder Makros zu installieren, da Sie dann nicht über die entsprechenden Module verfügen.

Bevor ein Report oder Makro verwendet werden kann, muss er in ARIS zur Verfügung gestellt werden. Die folgenden Screenshots zeigen, wie Sie einen Report oder Makro Schritt für Schritt importieren:

Im Modul Skripte kann man diesbezüglich Einstellungen vornehmen.

Klappen Sie die jeweilige Sektion auf und erstellen Sie eine neue Kategorie Namens „Reports & Makros“ (Sie können hier einen beliebigen Namen wählen), indem Sie bei Reports auf  „Neu“ klicken und dann auf „Kategorie“. Um ähnliche Reports bzw. Makros zusammenfassen und aus Gründen der Übersichtlichkeit werden diese Kategorien verwendet. Kategorien sind ähnlich wie Ordner auf Ihrer Festplatte.

Nun importieren Sie den benötigten ARIS Report oder Makro indem Sie per Rechtsklick auf die erstellte Kategorie die Option“Importieren“ auswählen.

Danach selektieren Sie den zu importierenden Bericht oder das benötigte Makro aus. Berichte und Makros werden in ARIS is .arx (Report) oder .amx (Makro) Dateien gespeichert. In unserem Fall „Hinterlegungsstruktur ermitteln.arx“, oder „Modell soll gespeichert werden.amx“

Nach der Auswahl der zu importierenden Datei wird ein weiteres Dialogfeld angezeigt. Dort setzen Sie, alle angebotenen Haken und bestätigen das Feld, indem Sie auf „Öffnen“ klicken. Hierbei wählen Sie externe Dateien aus, die ebenfalls importiert werden. Sollten Sie hierbei Zweifel haben, ob diese ebenfalls zu importieren sind, sollten Sie sich mit Ihrem ARIS Administrator in Verbindung setzen. Um die gewünschte Funktionalität des zu importierenden Reports jedoch sicherzustellen, ist ein Import dieser zusätzlichen Daten jedoch nötig.

Nun wurde der Report bzw. Makro importiert und kann eingeschränkt (nur vom Administrationsteam) verwendet werden. Um den Report bzw. Makro für alle Anwender bereitzustellen, müssen Sie noch die allgemeine Freigabe durchführen.

Der folgende Beitrag zeigt, wie Sie ein ARIS-Makro für alle Benutzer freigeben. Des Weitern zeigen wir Ihnen, wie Sie einen Report bzw. Makro in ARIS starten.

Über den Autor:

Felix Hahn ist seit mehreren Jahren als Berater im Prozess- und Qualitätsmanagement mit ARIS und ibo 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, Business Process Management etc. Den Autor können Sie unter f.hahn@q-4.biz kontaktieren.

www.q-4.biz
Q-4 GmbH
Pariser Str. 50
81667 München

Freigeben eines ARIS Reports bzw. Makros

In diesem Beispiel erläutern wir Ihnen, wie Sie in ARIS einen Report (Bericht) bzw. Makro für alle Benutzer freigeben. Um einen Report bzw. Makro in ARIS freigeben zu können, müssen Sie über einen ARIS Business Architekt verfügen. Sofern Sie nur über den Business Designer verfügen, müssen Sie in jedem Fall Ihren ARIS Administrator bitten, Reports oder Makros freizugeben.

Sollten Sie den Report bzw. Makro noch nicht auf Ihrem ARIS Server importiert haben, können Sie hier nachlesen, wie Sie einen Report bzw. Makro importieren können.

Zur Freigabe für alle Benutzer klicken Sie im Modul „Skripte“ mit einem rechtsklick auf die gewünschte Kategorie in dem sich der freizugebene Report bzw. Makro befindet (in unserem Beispiel „Reports & Makros“). Dann müssen Sie den Report bzw. Makro auswählen und markieren und per Rechtsklick die Eigenschaften öffnen.

Folgend müssen Sie den Haken bei „Für alle Anwender“ setzten und mit „OK“ bestätigen.

Jetzt ist der ARIS Report bzw. Makro bereit für den Einsatz.

Im folgenden Blogbeitrag erläutern wir Ihnen, wie Sie einen freigegebenen Marko bzw. Report starten können.

Über den Autor:

Felix Hahn ist seit mehreren Jahren als Berater im Prozess- und Qualitätsmanagement mit ARIS und ibo 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, Business Process Management etc. Den Autor können Sie unter f.hahn@q-4.biz kontaktieren.

www.q-4.biz
Q-4 GmbH
Pariser Str. 50
81667 München

Start eines Reports bzw. Makros in ARIS

Die folgenden Schritte zeigen, wie ein Bericht oder ein Makro in ARIS gestartet werden kann.

Wichtig ist hierbei zu Wissen, dass jeder Report über einen eigenen Kontext verfügt. Kontexte in ARIS können sein: Modelle, Objekte, Gruppen, Filter oder Datenbanken. Um einen Report bzw. Makro zu starten müssen sie den jeweiligen Kontext zum Start des Reports bzw. Makros selektieren.

In unserem Beispiel starten Sie einen Makro, der in einem Model-Kontext läuft. Hierzu selektieren Sie das Modell, welches Sie  auswerten möchten.

Dann wählen Sie im Kontextmenü den Menüpunkt „Auswerten“ -> „Start Bericht“ bzw. „Start Makro“ aus:

Folgend wird Ihnen der Report- bzw. Makro-Wizzard angezeigt. Wählen Sie den jeweilig zu startenden Report bzw. Makro aus.

Danach auf „Weiter“ klicken. Im folgenden Menü können Sie – sofern es im Report eingestellt ist – das Ausgabe Format wählen. Die hier von Ihnen gewählten Optionen beeinflussen das Verhalten des Reports bzw. Makros nicht, sondern spezifizieren nur dessen Ausgabeformart. Wählen Sie hier also Ihr favourisiertes Format und starten Sie den Report mit einem Klick auf „Fertig stellen“.

Nach der Erstellung des Reports oder Durchführung des Makros wird das Ergebnis angezeigt.

Über den Autor:

Felix Hahn ist seit mehreren Jahren als Berater im Prozess- und Qualitätsmanagement mit ARIS und ibo 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, Business Process Management etc. Den Autor können Sie unter f.hahn@q-4.biz kontaktieren.

www.q-4.biz
Q-4 GmbH
Pariser Str. 50
81667 München

DELA – Management im Bad Bank Umfeld mit EAM und Lean

Im Rahmen mehrerer Projekte im Umfeld des Management von Abwicklungsanstalten (engl. Deconsolidation Environment) wurden mehrere Kriterien identifiziert, die aus Management-Gesichtspunkten spezifisch adressiert werden müssen:

1. Eine Abwicklungsanstalt wird aus einer akuten Notlage heraus gegründet. In den ersten Monaten geht es deshalb darum, schnell und effizient die notwendigsten Strukturen aufzubauen und deren Betrieb zu überwachen. Das rasante Wachstum der sich entwickelnden Organisation gilt es effektiv zu steuern und zu überschauen.
2. Die Gründung einer Abwicklungsanstalt steht immer im Fokus der Politik und Öffentlichkeit. Tiefgreifende Vorgaben seitens der Politik greifen massiv in die Steuerungssysteme der sich bildenden Abwicklungsanstalt ein. Die Einhaltung und Erfüllung öffentlicher, politischer und rechtlicher Anforderungen haben somit oberste Priorität. Diese Situation führt sowohl zu einem exorbitanten Sofort-Aufwand als auch in der Folge zu einem erheblichen Erfüllungs-Nachfolgeaufwand. Planung und Steuerung müssen darauf ausgerichtet werden.
3. Dringendes Reputationsmanagement Auf der Kundenseite ist für die Abwicklungsanstalt selbst sowie auch insbesondere für die verbleibende Bank intensives Reputationsmanagement notwendig, um das Vertrauen der Marktteilnehmer wiederzuerlangen.
4. Regulatorische Compliance Die Abwicklungsanstalt ist in Teilen von der Erfüllung der MaRisk und Basel II / III Anforderungen befreit, die verbleibende Bank jedoch nicht.
5. Parallele Existenz zweier eng verbundener, dennoch selbstständiger Körperschaften (verbleibende Bank und Abwicklungsanstalt).

Auf Grund der meist sehr unübersichtlichen Situation in Verbindung mit hochgradig zeitkritischen Entscheidungssituationen ist ein hochgradig agiler Managementansatz von nöten. Dem Management wird mittels einer DELA (Deconsolidation Environment Lean Architecture) ein einfaches übersichtliches Werkzeug an die Hand gegeben, mit dem sowohl die verbleibende Bank, als auch die neu gegründete Abwicklungsanstalt überblickt und gesteuert werden kann.

Basis einer DELA ist ein 5-Ebenen Modell, das aus einer adaptierten Enterprise Architecture resutiert. Die fünf Ebenen sind:

• Risiko-Ebene
• Organisationsebene
• Geschäftsprozess-Ebene
• Service-Ebene
• System-Ebene

Innerhalb der einzelnen Ebenen wird das Lean Prinzip zur Reduktion der Aufwände und zur Maximierung der Effizienz (80-20 Grundastz) angewendet. Insbesondere durch die Vernetzung zwischen den einzelenen Ebenen werden hierbei wichtige Informationen schnell abrufbar. Die Formalisierung der Daten und die strukturierte Vorgehensweise ermöglichen einerseits einen schnellen Überblick und andererseits ebenso schnelle und detailierte Folgeabschätzungen. Damit ermöglicht die DELA dem Management ein sehr agiles Vorgehen und macht eine direkte und zeitnahe Ableitung von Maßnahmen aus der Geschäftsstrategie möglich.

Prozess-Reifegrad – Maturity Level im Vergleich

Da Prozessmanagement mittlerweile eine anerkannte Grundlage ist für Qualitätsmanagement, viele Compliace Themen, viele Bereiche des Risikomanagements und überhaupt gerne im Zusammenhang von Umstrukturierungen, Harmonisierungen und des Requirements Engineerings eingesetzt wird, wird jeder Manager auf die Frage „Betreibt Ihr Prozessmanagement?“ mit „Ja, natürlich.“ antworten.

Um diese – erstmal einfache – Antwort zu verifizieren und um eine Einschätzung des Grades der Umsetzung zu geben, dient die Bestimmung des Prozessreifegrads bzw. ein Maturity-Check für Prozesse.

In den letzten Jahren haben sich hierfür diverse Standards entwickelt. Hier ein kurzer Überblick über die bekanntesten Prozessreifegrad-Modelle:

1. CMMI – Capability Maturity Model Integration:
   CMMI ist kein einzelnes festdefiniertes Modell, sondern eine Sammlung von organisationseinheits-spezifischen Vorgehenssammlungen zur Bestimmung eines Prozessreifegrades (Maturitycheck). Entwickelt für die Reifegradbestimmung von Softwareentwicklungsprozessen ist CMMI heute in den Entwicklungsabteilungen der deutschen Automobilindustrie der Standard. Mittlerweile gibt es eine etwas breite Palette an Bereichen (Einkauf, Servicing, Projektmanagement, etc.) deren Reifegrad mit  den von CMMI gestellten Mitteln bestimmt werden kann. CMMI legt aber sehr starken wert auf eine fachlich-/ sachliche Auditierung des Prozesses. Dementsprechend können Prozesse, für deren Thema es keine „Vorlage“ gibt auch nicht auditiert werden. Eine konzernweite Einführung ist demnach nicht möglich (jeweils nur in den von CMMI abgedeckten Bereichen). Die Skala reicht hierbei von Reifegrad 1 – chaotische Organisation bis zum Reifegrad 5 – gelebte kontinuierliche Verbesserung. Die Standardisierungsorganisation ist die Carnegie Mellon Universität, Pittsburgh – USA;
2. PEMM – Process Enterprise Maturity Model:
   PEMM wurde Mitte der 90er Jahre am MIT unter der maßgeblichen Leitung von Prof. Michael Hammer entwickelt und stellt den genauen Gegensatz zu CMMI dar. PEMM ist zur generischen Prozessreifegradbestimmung auf jeglicher Art von Prozess geeignet und misst dementsprechend eher die Prozess-Awareness des Managements und ein strukturiertes Vorgehen im Sinne des Prozessmanagement. Ist sich das Management der Prozesse bewusst, sind die Process Owner auch Budget verantwortlich, werden Prozesse gelebt und in KPIs festgehalten etc. Die Reifegradskala reich bei PEMM von „0- Kein Prozess / Zufallsprinzip“ bis zu „4 – Prozesse werden gelebt und permanent optimiert und sind unternehmensweit und bis zu den Lieferanten / Kunden vernetzt“. Insbesondere in den USA ist PEMM weit verbreitet. Der Standard wird von dem von Prof. Hammer mit gegründeten Beratungsgesellschaft Hammer and Company definiert. Hier findet sich eine schöne, detailiertere Beschreibung von PEMM. Hier gibt es einen sehr rudimentäres PEMM online Assessment, das aber einen guten Eindruck von der Art der Fragestellung vermittelt.
3. ISO 15504 (SPICE):
   Ein auf die Software Entwicklung spezialisiertes Prozessreifegradmodell, das sich aus CMMI und Bootsrapping entwickelt hat und in Form einer ISO Norm im Rahmen eines Maturityaudits zertifiziert werden kann.
4. EDEN Reifegradmodell:
   Vom deutschen BPM-Club entwickeltes Vorgehen, das anhand von 158 Einzelkriterien, die in 9 Dimensionen zusammengefasst werden der mit ausführlichen Fragenkatalogen ähnlich zu PEMM auf die Management-Awareness und die Frage wie stark BPM im Unternehmen gelebt wird abzielt. Die Bewertungsstufen sind, Chaotisch, Ansatzweise, Fortgeschritten, Durchgängig,
   Gesteuert und Nachhaltig. EDEN ist ein kontinuierliches Vorgehensmodell, bei dem nicht nur der As-Is BPM-Status in den Reifegrad mit eingeht, sondern auch der angestrebte Erfolg. Wie PEMM ist EDEN sowohl auf Organisationsebene als auch auf Prozessebene einsetzbar und definiert in Anlehnung an den „Garten Eden“ die vier Matrix-Reifegrade „Sumpf – kein Prozess“ über „Wiese“ und „Feld“ bis zum „Garten – gelebte Prozesse“, die anhand von Punkteskalen 1-100 gemessen werden. Die Standardisierungsorganisation ist der BPM Maturity Model eden e.V.
5. 8 Omega / ORCA:
   Der 8 Omega-Maturity-Check ist ein einfacher – auch in Form eines Selbstassesment -durchführbarer Reifegradtest, mit dem man eine schnelle Übersicht über den aktuellen Prozesstatus erhalten kann. Ganz grundsätzlich werden nur 8 Multiple Choice Fragen, mit je 9 Antworten (Level 0-8) beantwortet. Die Fragen und Antworten sind natürlich sehr allgemein. Für eine erste Einschätzung des aktuellen Standes ist dieses Vorgehen aber sehr gut geeignet, da es ohne weitere Vorbereitung und Schulung kurzfristig durchgeführt werden kann. Entwickelt und definiert urde 8 Omega von der BPT-Group. Alle nötigen Informationen für einen Quick-Check finden sich in einem schönen Foliensatz (die Fragen und Antworten sind auf Seite 19)
6. BPMM – Business Process Maturity Model:
   Das Maturity Modell der OMG (Object Management Group). Der Standard ist ausserhalb der USA weitestgehend unbekannt, bietet aber auf Grund seiner hohen Transparenz (man kann ihn hier kostenlos downloaden) eine gute Grundlage für Firmen, die einen Standard auf die eigenen Bedürfnisse anpassen wollen. Der eigentliche Standard ist sehr umfangreich, das liegt aber u.a. daran, dass er auch den Vorgang der Zertifizierung in hohem Detail beschreibt. BPMM unterscheidet zwischen 30 verschiedenen Prozessklassen wie z.B. („Defect and Problem Prevention„, „Product and Service Deployment“ oder „Work Unit Configuration Management„) und passt die Reifegradprüfung dementsprechend an den zu Prüfenden Prozess an, generell ist BPMM aber dennoch ein generischer Standard (im Gegensatz zu CMMI), der keine fachliche Prüfung von Prozessen mit sich bringt. Es ist zwar möglich, den Standard an domänenspezifische Bedingungen anzupassen, die Anpassung muss jedoch vom Process Owner durchgeführt werden und gibt ihm damit lediglich die Möglichkeit ein sinnvolles Abweichen vom rigiden Standard für seinen Prozess zu begründen. Die Reifegrade reichen in BPMM von „1 – Initial“ bis „5 – Innovating„;

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.

Bei Fragen, Anregungen und Kommentaren können Sie sich auch gerne direkt an an Author Dr. Brunner wenden: brunner@q-4.biz

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 Notation 2.0 von der OMG (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.

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:

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.

Fahrplan für die Einführung von Wissensmanagement in KMUs

Generell ist die erfolgreiche Anwendung von Wissensmanagement in KMUs ist in zwei Phasen zu untergliedern. So muss im Rahmen eines Projekt das Thema eingeführt werden (Phase 1 Einführung von Wissensmanagement) und dann anschließend in in das tägliche Geschäft möglichst aller Mitarbeiter (operative Prozesse) eingebunden werden . Hierbei spricht man auch von der Operationalisierung des Wissensmanagements.

Die zwei Phasen des Wissensmanagements

Zur optimalen Einführung von Wissensmanagement in KMUs sollte in einem ersten Schritt ein (evtl auch im ersten Schritt vorläufiges) WiMa-Team gebildet werden, das die Einführung des Wissensmanagements fachlich begleiten kann. Wichtig ist hierbei, dass die Mitglieder des WiMa Teams folgende Bereiche abdecken:

• Ablaufverantwortliche der großen betroffenen Geschäftsbereiche (Process-Owner)
• Expertise im Bereich Prozessmanagement
• IT Expertise

Eines der Teammitglieder sollte entweder direkt aus dem Topmanagement stammen oder zumindest über sehr engen Kontakt dazu verfügen und Budget-Verantwortung haben (strategischer WiMa Leiter), ein weiteres, anderes Mitglied sollte mit der operativen Koordination betraut sein (operationeller WiMa Leiter) und hierfür auch ein definiertes Arbeitszeitkontingent zur Verfügung gestellt bekommen. Mitglieder des WiMa Teams können dem operationellen WiMa Leiter später für verschiedene Abschnitte und Aufgaben unterstützend zur Seite stehen (Workshopmoderatoren, IT-Spezialisten etc.). Mit dem WiMa-Team sollten dann in einem eintägigen Workshop die grundlegenden Rahmenbedingungen, die langfristigen Ziele des Wissensmanagements, einen Pilotbereich bzw. ein Schwerpunktthema zur Einführung und ein erster grober und visionärer Zeitplan entworfen und die Ergebnisse in einer WiMa-Roadmap dokumentiert werden.Wichtig ist hierbei die klare Unterteilung der Vorgehensweise in ein WiMa-Pilotprojekt und (evtl. mehrere) erweiterte WiMa-Projekte. Jedes Projekt sollte aber in sich schlüssig sein und präzise Benefits bieten, die eine Umsetzung erforderlich machen.

Anschließend muss die WiMa-Roadmap mit dem Topmanagement, idealerweise dem Unternehmer selbst abgestimmt werden.

Offizieller Startschuss für die Einführung sollte eine kurze (30 Minuten bis maximal 1 Stunde) WiMa Unternehmenspräsentation sein (auch als Telefonkonferenz möglich), an dem nach Möglichkeit alle Mitarbeiter des Unternehmens diese Roadmap und das WiMa-Team und dabei explizit den strategischen und den operationellen WiMa Leiter vorgestellt bekommen. Bei diesem Termin muss das Topmanagement seinen klaren Rückhalt für das Vorhaben und die agierenden Personen zum Ausdruck bringen.

Ab dieser Präsentation sollten der operationelle und der strategische WiMa Leiter einen gemeinsamen wöchentlichen Abstimmungstermin festlegen, damit der strategische WiMa Leiter und damit das Topmanagement jederzeit über den aktuellen Stand der Entwicklungen auf dem laufenden gehalten werden kann und Fehlentwicklungen, Spannungen und andere Probleme frühzeitig adressiert werden können.

Folgend muss vom WiMa-Team im Rahmen eines halbtägigen Pilot-Workshops zum WiMa Projektstart ein grobes Pilot-Konzept zur Einführung und Operationalisierung des Wissensmanagement in dem Pilotbereich bzw. dem Schwerpunktthema mit einem klar definierten, relativ kurzfristigen Ziel und einem konkreten Zeitplan spezifiziert werden. Es empfiehlt sich, den thematischen Bereich des Piloten als einen zusammenhängenden Pilot-Geschäftsprozess zu begreifen (z.B. der Umgang mit Wissen übder kundenspezifische Installationen, oder Verwaltung der Produktkataloge und zugehöriger Informationen der Zulieferer). Die aktuell bestehende Dokumentation sollte dabei für das Projekt als Nacharbeit des Pilot-Workshops zusammengetragen werden. Der operationelle WiMa Leiter ist mit der Ausarbeitung eines Umsetzungskonzeptes für diesen Piloten verantwortlich.

Der operationelle WiMa Leiter sollte hierfür eine 1-3 wöchige Pilot-Analysephase (je nach Komplexität) durchführen, im Rahmen derer er das zu verwaltende Wissen spezifiziert (Fachwissen, Methodenkenntnisse, Kundenwissen, Marktwissen Produktwissen etc.), die vom Wissemsnmanagement betroffenen Organisationseinheiten ermittelt (wer/wann wird Wissen aufgezeichnet, wer/wann wird Wissen abgerufen, etc.) und beteiligte und hilfreiche neue IT-Tools identifiziert.

Das Umsetzungskonzept für den Piloten muss der operationelle WiMa Leiter dem WiMa Team zur Abstimmung und zum Beschluss präsentieren. Der operationelle WiMa Leiter ist folgend auch für die Umsetzung dieses Konzeptes verantwortlich und muss vom strategischen WiMa Leiter dafür mit den nötigen Ressourcen (Zeit, Budget etc.) ausgestattet werden.

Eine der wichtigsten Aufgaben des operationellen WiMa Leiters ist es in den jeweiligen Umsetzungsphasen, das Wissensmanagement den beteiligten und umsetzenden Kollegen als hilfreich und entlastend und für den Einzelnen absolut förderlich darzustellen. Hierbei kann der Unterschied zum strategischen WiMa Leiter, der die Umsetzung „beauftragt“ hat durchaus dargestellt werden. Themen die in diesem Zusammenhang von Person zu Person unterschiedlich motivierend wirken können sind:

• Weiterbildung im Umgang mit den vorgesehenen Tools zum WiMa
• Kompetenzaufbau in angrenzenden Wissensbereichen
• Management des eigenen Wissens – auch privat anwendbar
• Gewinnen von Seniorität und Souveränität gegenüber den Kollegen (z.B. als Autor von Artikeln)
• Profilierung durch Verbesserungsanregungen, Weitergabe von „Guter Praxis“ an Kollegen („Also ich würde das ja so machen…“)

Die konkrete Umsetztung des Piloten erfolgt wiederum in zwei Schritten. Im ersten Schritt werden mit den beteiligten Organisationseinheiten WiMA-Prozessworkshops abgehalten, bei denen Teilprozesse des Pilot-Geschäftsprozesses mit WiMa-relevanten Elemente spezifiziert werden. Es geht dabei darum klar zu identifizieren, welches Wissen in welchen Aktivitäten verwendet wird, wo und wann dieses Wissen entsteht, wie dieses Wissen im Unternehmen vorliegt (im Kopf eines Mitarbeiters, in Schriftform, in einer Applikation), wie und welche Informationen ausgetauscht werden und um welches Wissen (Fachwissen, Kundenwissen etc.) es sich dabei handelt. Anschließend werden Wissensmanagement-Methoden in den Teilprozess integriert und der Pilot-Geschäftsprozess dadurch optimiert. Die Ergebnisse der WiMa-Prozessworkshops müssen in formellen Protokollen festgehalten werden. Insbesondere den Optimierungsvorschlägen und den zugrundeliegenden Problemen muss hierbei erhöhte Aufmerksamkeit geschenkt werden. Nachdem alle Workshops durchgeführt sind, werden im zweiten Schritt vom operationellen WiMa Leiter die Ergebnisse aller WiMa-Prozessworkshops zusammengefasst und die beschloßenen Maßnahmen sowie die zu ändernden Prozessabläufe in einer Präsentation zusammengefasst. Das WiMa Team erhält diese WiMa Decision-Präsentation zur Beschlussfassung.

Folgend werden die beschloßenen Masnahmen im Rahmen eines WiMa-Change Management-Projektes unter der Verantwortlichkeit des operationellen WiMa Leiters umgesetzt. Nach Abschluss der Implementierung ist der operationelle WiMa Leiter für die Erstellung passender WiMa-Anweisungen verantwortlich, deren Einhaltung die Umsetzung des Wissensmanagements im Rahmen des Tagesgeschäftes sicherstellt. WiMa Anweisungen können beispielsweise Leitfäden, Prozessbeschreibungen, Schritt-für-Schritt Anweisungen, Checklisten, etc. sein.

Im Rahmen eines Debriefings für das Pilotprojekt werden die WiMa Anweisungen dem WiMa Team vom operationellen WiMa Leiter vorgestellt und dem strategischen WiMa Leiter übergeben. Das Debriefing dient des weiteren dazu, eine „Manöverkritik“ durchzuführen und – ganz im Sinne des Wissensmanagements – die „Lessions Learned“ festzuhalten und Optimierungsvorschläge bei der WiMa Projektdurchführung selbst zu definieren.

Nach dem Debriefing wird vom operationellen WiMa Leiter ein Vorschlag für den Scope des / der folgenden erweiterte(n) WiMa Projekt(e) erstellt. Dieser Vorschlag wird vom WiMa Team überarbeitet und beschloßen. Die einzelnen erweiterten WiMa Projekte werden analog zum Pilotprojekt durchgeführt. Sofern mehrere erweiterte WiMa parallel durchgeführt werden sollen, sollte für jedes erweiterte WiMa Projekt ein eigener WiMa-Projektleiter definiert werden, der die Funktion des operationellen WiMa Leiters für das Projekt einnimmt und dem operationellen WiMa Leiter fachlich untergeordnet ist. Es hat sich als schwer durchführbar erwiesen, mehrere WiMa Projekte gleichzeitig und unabhängig operationell zu leiten.

Parallel zur SetUp der erweiterten WiMa Projekte erfolgt jetzt die Operationalisierung des Wissensmanagements für das Pilotprojekt. Die Verantwortung für die Verteilung und die Durchsetzung der Einhaltung der jeweiligen WiMa-Anweisungen trägt der strategische WiMa Leiter. Er ist bei der Operationalisierung im Lead. Die Vorgehensweise für diese Umsetzung ist sehr unternehmensspezifisch und erfordert in vielen Fällen auch politische Unterstützung des Topmanagements.

Es hat sich jedoch als sehr hilfreich erwiesen, wenn der strategische WiMa Leiter hierbei mit Stichproben auf unterster Ebene arbeitet. Er sollte sich also mit einzelnen in den WiMa-Anweisungen spezifizierten Details befassen und diese auf Systemebene prüfen. Bei der Prüfung im System kann der strategische Leiter natürlich auch durch den operationelle WiMa Leiter oder andere Helfer unterstützt werden. Im Falle von Fehlern, sollte aber der strategische WiMa Leiter den direkten Kontakt mit den umsetzenden Mitarbeitern suchen, den Fehler schnell und in Zusammenarbeit beheben und den Mitarbeiter auf die Wichtigkeit der Integration der jeweiligen WiMa Tasks aufmerksam machen. Auch hier sollten sich die oben beschriebenen Motivationsanreize als hilfreich erweisen.