Artikel-Schlagworte: „Risk Management“
Audit, Control, and Security Professionals Exchange Munich
Audit, Control, and Security Professionals Exchange in Munich
Where? Hirschgarten München – http://www.hirschgarten.de/
When? Thursday, 12th of July 2012 6 p.m. /opening 05:30 p.m.
Organizer: Andreas Jensch & Jutta Staudach
Agenda:
Opening at 5:30 pm.
First 40 Minutes Seminar 6 p.m. till 6:40 p.m.
Topic: IT Governance
– IT Governance of IT vs. Corporate Governance of IT
– COBIT 4.1
– What’s new in COBIT 5 and why it’s now Governance in Enterprise IT
Speaker: Jutta Staudach / Jay Ranade
Ten Minutes Break
Second 40 Minutes Seminar 06:50 – 07:30
Topic:
IT Risk Management
– Information Risk Management and Compliance
– Business Continuity & Disaster Recovery
– Incident Management and Response
Speaker: Jay Ranade / Andreas Jensch
Afterwards get together in the Biergarten till 11 p.m.
Event itself is free of charge, food and drinks on self payer basis.
Presentation and Discussion on actual Audit, Control, and Security topics –
Please feel free to send me your favorites – jutta.staudach@rmpi-germany.de
If you want to attend please send me an email with Name, Surname and Phone Number – Thanks!
–
Best Regards / Mit freundlichen Grüssen / Salutation cordiales
Jutta Edith Staudach
CISA, CISM
Risk Management Professionals International, German Division
Director of Global Certification seminars
Risikomanagement Risk Management Industriestandards Industry Frameworks
IT Services: Capability Maturity Model (CMM)
IT Services CMM Website findet der geneigte Leser hier http://sites.google.com/site/itservicecmmwebsite/
Capability Maturity Model
aus Wikipedia, der freien Enzyklopädie
Capability Maturity Model (Reifegradmodell)® (kurz CMM®) ist ein Reifegradmodell zur Beurteilung der Qualität („Reife“) des Softwareprozesses (Softwareentwicklung, Wartung, Konfiguration etc.) von Organisationen sowie zur Bestimmung der Maßnahmen zur Verbesserung desselben.
CMM wurde Ende 2003 durch Capability Maturity Model Integration® (kurz CMMI®) ersetzt, um dem Wildwuchs diverser CM-Modelle (jede Entwicklungs-Disziplin entwickelte ein eigenes Modell) entgegenzuwirken und ein neues, modulares und vor allem vereinheitlichtes Modell zu erstellen.
Andere populäre Modelle sind ITIL für die Infrastruktur und Spice für Reifegradbestimmung und Assessment der Software-Prozesse.
COBIT
CoBit Website http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx
CobiT
aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Cobit)
CobiT (Control Objectives for Information and Related Technology) ist das international anerkannte Framework zur IT-Governance und gliedert die Aufgaben der IT in Prozesse und Control Objectives (oft mit Kontrollziel übersetzt, eigentlich Steuerungsvorgaben, in der aktuellen deutschsprachigen Version wird der Begriff nicht mehr übersetzt). CobiT definiert hierbei nicht vorrangig, wie die Anforderungen umzusetzen sind, sondern primär darauf, was umzusetzen ist.
Cobit ist nicht inkompatibel zu anderen Frameworks wie ITIL oder ISO 9000.
COSO
COSO Website findet der Leser hier http://www.coso.org/default.htm
Auszug aus Wikipedia
Das COSO-Modell (1992/94)
COSO hat 1992 einen heute von der SEC anerkannten Standard für interne Kontrollen, das COSO-Modell[1], publiziert. Dieses Kontrollmodell dient der Dokumentation, Analyse und Gestaltung des internen Kontrollsystems, beschränkt sich allerdings stark auf die Finanzberichterstattung.
Die Bestandteile des internen Kontrollsystems nach dem COSO-Modell sind:
* Kontrollumfeld
* Risikobeurteilung
* Kontrollaktivitäten
* Information und Kommunikation
* Überwachung
Das COSO ERM-Framework (2004)
Im Jahr 2004 hat COSO eine Ergänzung zu seinem ursprünglichen Modell, das COSO ERM – Enterprise Risk Management Framework veröffentlicht. Das COSO ERM fügt zusätzliche Elemente ein:
* Internes Kontrollumfeld
* Zielsetzung
* Ereignisidentifikation
* Risikobeurteilung
* Risikoreaktion
* Kontrollaktivitäten
* Information und Kommunikation
* Monitoring
IT Service Management ITSM
IT-Service-Management
aus Wikipedia, der freien Enzyklopädie
IT-Service-Management (ITSM) bezeichnet die Gesamtheit von Maßnahmen und Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen (GP) durch die IT-Organisation zu erreichen. ITSM beschreibt insofern den Wandel der Informationstechnik zur Kunden- und Serviceorientierung. Von Bedeutung ist die Gewährleistung und Überwachung der Business Services, also die für den Kunden sichtbaren IT-Services. Auf diese Weise können kontinuierlich die Effizienz, die Qualität und die Wirtschaftlichkeit der jeweiligen IT-Organisation verbessert werden.
Mit dieser Definition ist der Begriff in das folgende Umfeld einzuordnen:
* Business Service Management (BSM): Die Verbindung zwischen Prozessmanagement und ITSM.
* IT-Service-Management (ITSM): Methoden, die nötig sind, um die bestmögliche Unterstützung von Geschäftsprozessen (GP) durch die IT-Organisation zu erreichen.
* Prozessmanagement (auch Geschäftsprozessmanagement, GPM): Die Definition der Prozesse des Business, die durch die IT unterstützt werden.
* Serviceorientierte Architektur (SOA): Ein Managementkonzept für eine dienstorientierte Architektur der ICT.
Normen / Frameworks / Standards
Mit der BS 15000 existiert in Großbritannien eine Norm, mit der einzelne IT-Service-Management-Prozesse spezifiziert sind. Auf Basis des BS 15000 kann ein Unternehmen sein IT-Service-Management zertifizieren lassen. Die BS 15000 wurde im Dezember 2005 in die internationale Norm ISO/IEC 20000:2005 überführt. Daneben gibt es weitere Frameworks und Standards. Diese sind zum Teil firmenspezifische Vorgaben oder branchenorientierte Lösungen. Beispiele dafür sind:
* IT Infrastructure Library (ITIL)
* enhanced Telecom Operations Map (eTOM)
* Microsoft Operations Framework (MOF) von Microsoft
Von „http://de.wikipedia.org/wiki/IT-Service-Management“
National Institute of Standards and Technology (NIST)
Gegründet 1901
National Institute of Standards and Technology
aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von NIST)
National Institute of Standards and Technology
Das National Institute of Standards and Technology (NIST) ist eine Bundesbehörde der Vereinigten Staaten mit Sitz in Gaithersburg (Maryland) und in Boulder (Colorado). Der frühere Name der Behörde war von 1901 bis 1988 The National Bureau of Standards (NBS). Die Position des Behördenleiters (Director) wird derzeit von Patrick Gallagher besetzt.
Das NIST gehört zur technologischen Administration des Handelsministeriums und ist für Standardisierungsprozesse zuständig. Aus diesen ist der Verschlüsselungsalgorithmus DES wie auch AES hervorgegangen. Weiterhin werden die Federal Information Processing Standards (FIPS) veröffentlicht, die für US-Behörden gelten.
NIST-F1 ist der Name der NIST-Atomuhr, die zur Koordinierten Weltzeit beiträgt. Sie hat eine theoretische Abweichung von einer Sekunde in 60 Millionen Jahren.[3]
Das NIST gibt unter anderem auch die für massenspektrometrische Messungen heute unverzichtbare Sammlung zur Substanzidentifizierung durch das stoffspezifische Massenspektrum, die NIST/EPA/NIH Mass Spectral Library (Data Version: NIST 08, Software Version 2.0f) heraus.
Das deutsche Gegenstück ist die Physikalisch-Technische Bundesanstalt (PTB).
Das NIST hat im Jahr 2009 ein Budget von 819 Millionen US-Dollar (plus zusätzlichen 610 Millionen US-Dollar aus dem American Recovery and Reinvestment Act [4]) zur Verfügung [5][6]. Beim Institut sind 2.900 Mitarbeiter beschäftigt. Es beauftragte in den 1970er Jahren u. a. die Boulder-Gruppe mit der Messung der Lichtgeschwindigkeit und der Neudefinition des Meters.
PMBOK (PMI)
Project Management Body of Knowledge
aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von PMBOK)
Der Guide to the Project Management Body of Knowledge (PMBoK Guide) ist ein weit verbreiteter Projektmanagement-Standard und zentrale Referenz des US-amerikanischen Project Management Institute, von dem er auch herausgegeben und unterhalten wird.
In der Einführung bezeichnet sich das Werk als „Zusammenfassung des Wissens der Fachrichtung Projektmanagement“. Gemeint ist das Wissen über die Vorgehensweisen, die weithin als bewährte Praxis (PMBoK: „best practice“) anerkannt werden. Die beschriebenen Methoden sind auf Projekte aus verschiedenen Anwendungsbereichen anwendbar, dazu gehören u.a. Bauwesen, Software-Entwicklung, Maschinenbau und Automobilindustrie.
Der PMBoK Guide ist prozessorientiert, d. h. er verwendet ein Modell, nach dem Arbeit durch Prozesse erledigt wird. Ein Projekt wird durch das Zusammenspiel vieler Prozesse durchgeführt. Anhand der Prozesse strukturiert das PMBoK das gesammelte Methodenwissen. Für jeden Prozess werden Input, Output und Werkzeuge und Verfahren beschrieben.
Das American National Standards Institute (ANSI) und das Institute of Electrical and Electronics Engineers (IEEE)[1] erkennen das PMBOK als Standard an. Es wurde (neben Englisch) in elf Sprachen übersetzt.
Der PMBoK Guide ist die Basis für die Zertifizierungsprüfung zum Project Management Professional (PMP) und für die Eingangslevel-Zertifizierung Certified Associate in Project Management (CAPM).
Es werden insgesamt 42 Prozesse definiert (vierte Ausgabe), die in die folgenden fünf Prozessgruppen eingeordnet werden:
* Initiierung
Prozesse zur formalen Autorisierung des Projekts. Ergebnisse sind der Projektauftrag (Beauftragung des Projektleiters) und das vorläufige Scope Statement.
* Planung
Festlegung des Projekt-Umfangs (Ergebnis: Scope Statement) und Festlegung, wie in den einzelnen Wissensgebieten geplant wird (Ergebnis Projektmanagementplan als „Meta-Plan“), dazu Durchführung der Planung (Ergebnisse: Projektstrukturplan, Terminplan, Kostenplan, Beschaffungsplan, Risikoplan, …).
* Ausführung
Sicherstellen, dass die Aktivitäten ausgeführt werden, wie sie geplant wurden. Wichtigstes Ergebnis ist natürlich der eigentliche Liefergegenstand des Projekts. Auch Prozesse wie Qualitätssicherung, Projektteam aufbauen und Anbieter auswählen zählen zu dieser Prozessgruppe.
* Überwachung und Steuerung
Die zugehörigen Prozesse sammeln und bewerten Informationen zur Projekt-Performance entsprechend der Planung im Projektmanagementplan. Auch Risiko-Überwachung gehört zu dieser Prozessgruppe. Wichtige Ergebnisse sind Vorschläge für Korrekturmaßnahmen oder vorbeugende Maßnahmen.
Der Prozess Integrierte Änderungssteuerung regelt die Abwicklung von Änderungsanträgen (Change Requests, CRs).
* Abschluss
Die beiden Prozesse dieser Gruppe sind Vertragsbeendigung (besonders Verträge mit Kunden und Lieferanten) und Projektabschluss (dabei wird der Projektauftrag als geschlossen erklärt).
Eine Matrix ordnet jeden Prozess eindeutig einer Prozessgruppe und einem Wissensgebiet zu. Dabei wurde für jeden Prozess die Prozessgruppe gewählt, in der der größte Teil der Aktivitäten des Prozesses stattfindet.
Wissensgebiete
Der Abschnitt über die Wissensgebiete bildet den Schwerpunkt des PMBoK Guide. Jeweils ein Kapitel widmet sich einem Wissensgebiet. Alle 42 Prozesse werden detailliert beschrieben. Dabei werden für jeden Prozess Inputs, Outputs und Methoden und Werkzeuge beschrieben.
Die Wissensgebiete, denen die Einzelprozesse aus den Prozessgruppen jeweils eindeutig zugeordnet sind, heißen:
* Integrationsmanagement
Das Wissensgebiet Integrationsmanagement in Projekten umfasst die Prozesse und Vorgänge, die benötigt werden, um die verschiedenen Prozesse und Projektmanagementvorgänge in den Projektmanagementprozessgruppen zu identifizieren, zu definieren, zu kombinieren, zu vereinheitlichen und zu koordinieren. Im Projektmanagementkontext umfasst Integration Merkmale der Vereinheitlichung, Konsolidierung und Gliederung sowie integrative Aktionen, die entscheidend sind für den Abschluss von Projekten, die erfolgreiche Erfüllung der Anforderungen von Kunden und anderer Stakeholder und den Umgang mit Erwartungen.
* Inhalts- und Umfangsmanagement
Das Inhalts- und Umfangsmanagement in Projekten beinhaltet die erforderlichen Prozesse, um sicherstellen, dass das Projekt alle erforderlichen Arbeiten, aber auch nur diese, umfasst, um es erfolgreich zu beenden. Hierbei geht es vorrangig um die Definition und Steuerung dessen, was im Projekt eingeschlossen ist und was nicht.
* Terminmanagement
Zielt auf die Einhaltung des Zeitrahmens und sollte alle beteiligten Zielgruppen einbinden. Der Projektplan dient dabei v.a. auch als Kommunikationsmedium.
* Kostenmanagement
Zielt auf Budgeteinhaltung. Hierfür ist der Kostenverlauf zu erfassen. Gegebenenfalls sind Gegenmaßnahmen einzuleiten.
* Qualitätsmanagement
Erfordert Standardisierung von PM-Prozessen, Dokumentation der Arbeiten und Ergebnisse, sowie ein geeignetes Maßnahmenmanagement
* Personalmanagement
Personalmanagement in Projekten umfasst die Prozesse, die das Projektteam organisieren und managen. Das Projektteam besteht aus den Mitarbeitern, die zugewiesene Rollen und Verantwortlichkeiten haben, um das Projekt fertig stellen zu können.
* Kommunikationsmanagement
Kommunikationsmanagement in Projekten ist das Wissensgebiet, in dem die Prozesse angewendet werden, die für das rechtzeitige und sachgerechte Erzeugen, Sammeln, Verteilen, Speichern, Abrufen und Verwenden von Projektinformationen notwendig sind.
* Risikomanagement
Risikomanagement in Projekten umfasst die Prozesse bezüglich der Durchführung der Risikomanagementplanung, Identifizierung, Analyse, Maßnahmen sowie Überwachung und Steuerung bei einem Projekt; die meisten dieser Prozesse werden im Verlauf des Projekts aktualisiert. Ziele des Risikomanagements in Projekten sind die Steigerung der Wahrscheinlichkeit und der Auswirkungen positiver Ereignisse sowie die Verringerung der Wahrscheinlichkeit und der Auswirkungen von Ereignissen, die für das Projekt ungünstig sind.
* Beschaffungsmanagement
Beschaffungsmanagement in Projekten beinhaltet die Prozesse für den Kauf oder Erwerb der Produkte, Dienstleistungen und Ergebnisse, die von außerhalb des Projektteams für die Durchführung der Arbeit benötigt werden. Beschaffungsmanagement in Projekten umfasst das Vertragsmanagement und die Prozesse zur Änderungssteuerung, die zum Managen der von autorisierten Projektteammitgliedern ausgegebenen Verträge oder Bestellungen erforderlich sind. Beschaffungsmanagement in Projekten umfasst außerdem die Verwaltung aller Verträge, die von einer externen Organisation (dem Käufer) ausgegeben wurden, der das Projekt von der Trägerorganisation (dem Verkäufer) erwirbt, sowie die Verwaltung vertraglicher Verpflichtungen, die dem Projektteam durch den Vertrag auferlegt werden.
Die einzelnen Aufgabenfelder treten im Projektverlauf an verschiedenen Stellen auf.
Supply-Chain Operations Reference Model (SCOR)
5 Schlüsselbereiche und 3 Prozesse – mehr Details gibt es hier www.supply-chain.org
Zusammenfassung:
Jutta Staudach
Risikomanagement, Projektmanagementberatung Düsseldorf