Einführung eines Risikomanagements. Bewertung der Lean Management Prinzipien für die Produktentwicklung nach der Untersuchung auf Informationssicherheit


Masterarbeit, 2015

140 Seiten, Note: 1,5


Leseprobe


Inhaltsverzeichnis

Abbildungsverzeichnis

Abkurzungs- und Symbolverzeichnis

1 Einleitung
1.1 Ausgangslage
1.2 Gegenstand
1.3 Ziel

2 Grundlagen
2.1 LeanManagement
2.2 Informationssicherheit
2.2.1 IT-Grundschutz
2.2.2 ITIL/ISO/IEC 20000
2.2.3 ISO/IEC 27001
2.2.4 NIST
2.2.5 Common Criteria
2.2.6 SPICE
2.2.7 CobiT
2.3 Risikomanagement
2.3.1 ISO/IEC 27005
2.3.2 ISO/IEC 31000
2.3.3 NIST
2.3.4 Common Criteria
2.3.5 SPICE
2.3.6 CobiT
2.4 Rechtliche Grundlagen
2.4.1 Compliance
2.4.2 KonTraG
2.4.3 BilMoG
2.4.4 GDPdU, GoBS
2.4.5 S-Ox
2.4.6 COSO
2.4.7 BaselII,Solvency II
2.4.8 Kreditwesengesetz
2.5 Fazit der Grundlagen

3 Der Entwicklungsprozess
3.1 Konzeptphase
3.2 Projektdefinitionsphase
3.3 Produktdefinitionsphase
3.4 Realisierungskonzeptphase
3.5 Entwicklungsphase
3.6 Realisierungsphase
3.7 Prozessvalidierungsphase
3.8 Serienphase
3.9 Produktauslaufphase

4 Beschreibung der Lean Enablers
4.1 LeanPrinzip1:Wert
4.2 Lean Prinzip 2: Wertstrom abbilden
4.3 Lean Prinzip 3: Fluss
4.4 Lean Prinzip 4: Pull
4.5 Lean Prinzip 5: Perfektion
4.6 Lean Prinzip 6: Respekt fur den Menschen

5 Implementierung der Lean-Prinzipien
5.1 Auswahl der Varianten und Untervarianten
5.2 Kategorien von Verschwendung

6 Allgemeine Daten im Risikomanagement
6.1 Prozesse im Scope des Risikomanagement
6.2 Informationen im Risikomanagement
6.3 Rollenim Risikomanagement
6.4 Lokationen und Standorte im Risikomanagement
6.5 Peripherie
6.6 Software
6.7 AuswahlderLeanEnabler
6.8 Definition der Klassifizierung fur das Risikomanagement
6.8.1 Vertraulichkeit
6.8.2 Integritat
6.8.3 Verfugbarkeit
6.8.4 Datenschutz

7 Assetaufnahme fur das Risikomanagement
7.1 Ablauf der Klassifizierung
7.2 Gesprachsfuhrung mit den Prozess-Ownern

8 Eintrittswahrscheinlich und Schadensausmafi
8.1 Elementare Gefahrdungen gemaft IT-Grundschutz
8.2 Berechnung Risikowert der Prozesse
8.2.1 Eintrittswahrscheinlichkeiten fur Software-Anwendungen
8.2.2 Schadensausmaft fur jeden Prozess
8.3 Eintrittswahrscheinlichkeit und Schadensausmaft fur weitere Assets

9 Reporting
9.1 Report der Prozesse
9.2 Reports weiterer Assets
9.3 Report der Gefahrdungen

10 Auswertung fur die Informationssicherheit

11 Umsetzungsgrad der Lean Prinzipien
11.1 Erfassung der Maftnahmen zu den Lean Prinzipien
11.2 Berechnung des Umsetzungsgrades

12 Ableitung von Mafinahmen
12.1 Risikovermeidung
12.2 Risikoreduzierung
12.2.1 Risikodiversifikation/-konzentration
12.2.2 Risikotransformation
12.3 Risikoubertragung
12.4 Risikoakzeptanz

13 Handlungsempfehlung

14 Fazit und Ausblick

15 Literatur- und Quellverzeichnis
15.1 Internetquellen
15.2 Literaturquellen

Abbildungsverzeichnis

Abbildung 1: Beispiel fur die Auswahl der Varlanten und Untervarlanten

Abblldung 2: Verschwendungsarten zugeorndet zu den Lean Untervarlanten

Abbildung3: ErfassungAllgemeineAngaben: Prozesse imScope

Abblldung 4: Definition der Informationsarten

Abbildung 5: Rollenbenennung fur die allgemelnen Angaben fur das Risikomanagement

Abblldung 6: Lokatlonsbenennung fur die allgemelnen Angaben fur das Risikomanagement

Abblldung 7: Benennung der Standorte

Abblldung 8: Benennung der Peripherie fur die allgemelnen Daten

Abblldung 9: Benennung der Software fur den Standard-Arbeitsplatz

Abblldung 10: Benennung der Software

Abblldung 11: Assetaufnahme: Bezelchnung Prozess und Prozess-Owner

Abblldung 12: Klassifizierung der Verfugbarkeit und Integritat des Prozesses

Abblldung 13: Auswahl der prozessrelevanten Informationsarten

Abblldung 14: Klassifizierung der Vertraulichkeit und Datenschutzelnstufung der prozessrelevanten Informationsarten

Abblldung 15: Auswahl der prozessrelevanten Rollen

Abblldung 16: Hinzufugen der Lokatlonen und Standorte fur die Rollen

Abblldung 17: Auswahl der prozessrelevanten Peripherie

Abblldung 18: Hinzufugen der Lokatlon und Standort zur prozessrelevanten Peripherie

Abblldung 19: Verknupfung der Software zu verarbelteten Informationsarten

Abblldung 20: Ergebnls Verfugbarkeit und Integritat fur elnen Prozess

Abblldung 21: Ergebnls Vertraulichkeit und Datenschutz fur elnen Prozess

Abblldung 22: Ergebnls Software-Anwendungen

Abblldung 23: Berechneter Risikowertfur den Prozess je elementare Gefahrdung

Abblldung 24: Risikowert fur die Software-Anwendungen, die in dem Prozess elngesetzt werden

Abblldung 25: Sicherheitsniveau Standard-Arbeitsplatz

Abblldung 26: Sicherheitsniveau CAD-Programm

Abblldung 27: Auswahl der Risikorelevanz aller elementaren Gefahrdungen

Abblldung 28: Bewertung der Eintrittswahrscheinlichkeit fur die risikorelevanten Gefahrdungen

Abblldung 29: Auswahl der risikorelevanten Gefahrdungen fur elnen Prozess

Abblldung 30: Adaption der elementaren Gefahrdungen mlt den Sicherheitszielen gem. BSI-Standard 100-3

Abblldung 31: Angabe des SchadensausmaR der elnzelnen Gefahrdungen fur elnen Prozess

Abblldung 32: Risikowerte des Asset "Rolle"

Abblldung 33: Risikowert des Asset "Lokatlon"

Abblldung 34: Risikowert des Asset "Standort"

Abblldung 35: Reporting Prozesse

Abblldung 36: Reporting Rollen

Abblldung 37: Reporting Lokatlonen

Abblldung 38: Reporting Standorte

Abblldung 39: Risikowert der Gefahrdungen

Abblldung 40: Risikowerte der Gefahrdungen fur alle erfassten Assets

Abbildung 41: Abglelch der elementaren Gefahrdungen mlt den Controls der IS027001:2013

Abbildung 42: Auswahl der Lean Prlnzlplen mlt umgesetzten Matenahmen und dem Grad der Umsetzung

Abblldung 43: Matrix zwlschen den Lean Prlnzlplen, Varlanten und Untervarlanten mlt dem elementaren Gefahrdungen

Abblldung 44: Belsplel als Basls fur dle Ableltungvon Matenahmen

Abblldung 45: Matenahmen fur dle Behandlung von Rlslken

Abblldung 46: Reportlng Prozesse

Abblldung 47: Hochste Prlorltat ln der Auswertung der Rlslkowerte als Ergebnls aller Prozesse

Abblldung 48: Rlslkostrategle fur dle Ubertragungvon Rlslken

Abkurzungs- und Symbolverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Diese Abschlussarbeit verbindet die Vorgehensweise eines Risikomanagements mit den Prozessen im Bereich der Hardware-Entwicklung. Fur die Optimierung dieser Prozesse werden Standards des Lean Managements zugrunde gelegt und die Priorisie- rung fur weitere MaBnahmen dargestellt.

1.1 Ausgangslage

Die Einfuhrung der Methoden aus dem Bereich des Lean Management ermoglicht vielen Unternehmen die Optimierung der internen Prozesse durch Eliminierung von Verschwendung. Besonders fur Unternehmen, die intern vorhandene Ressourcen ef- fektiver einsetzen mochten, ist die Optimierung von Prozessen mit einer Reduktion von Kosten in der Produktion, in der Forschung und Entwicklung und allen administ- rativen Abteilung ein attraktiver Ansatz.

Gelaufig sind die Methoden des Lean Management vor allem aus dem Bereich der Produktion und Montage. Dazu gehoren die klassischen Methoden Kaizen, Six Sigma oder Kanban. In produzierenden Bereichen eines Unternehmens konnen wahrend der Einfuhrung besonders schnell Erfolge erzielt werden, indem einzelne Teilprozesse optimiert werden. Der Output, die Durchlaufzeit oder die Maschinenauslastung kon- nen schnell verbessert werden. Dies ist ein wichtiger Erfolgsfaktor fur die Einfuhrung von Lean Management.

In der Zwischenzeit ist die Auswahl an Vorgehensweisen zur Einfuhrung von Lean Management von verschiedenen Experten und Unternehmen ausgeweitet worden. Vor der Einfuhrung dieser Methoden ist es fur jedes Unternehmen wichtig, dass die unter- schiedlichen Vorgehensweisen genau betrachtet und fur das eigene Unternehmen aus- gewahlt werden.

Etliche Unternehmen in Deutschland und weltweit fuhren die Methoden des Lean Management ein. Zunachst wurden die einzelnen Prozesse im Bereich der Montage und Fertigung betrachtet und erste Ziele abgeleitet. Bereits nach den ersten Erfolgen wird deutlich, dass durch minimale Verbesserungen innerhalb der Prozesse groBe Er­folge erzielt werden konnen. Diese Erkenntnisse sollen auf alle Prozesse innerhalb des Unternehmens ubertragen werden. Dies ist jedoch nur mit einem groBzugig geplanten Einfuhrungsprojekt und gut ausgebildeten Multiplikatoren in allen Fachbereichen moglich.

Im Weiteren werden Untemehmen fokussiert, die eine eigene Forschungs- und Ent- wicklungsabteilung betreiben. Der Standort Deutschland ist dabei ein sehr attraktiver Standort, denn aufgrund des hier ausgebildeten Personals betreiben Untemehmen auch aus dem Ausland entsprechende Forschungs- und Entwicklungsbereiche in deut- schen Unternehmen. Die Forschung und Entwicklung beschaftigt sich im Sinne der Auftraggeber oder eigenen Unternehmen ausschliefilich mit der Weiter- und Neuent- wicklung von Produkten und Waren. Diese Abteilungen werden beschaftigt, um die Wettbewerbsfahigkeit auf dem Markt zu erhalten und ggf. einen Vorsprung zu erlan­gen.

In der folgenden Ausarbeitung werden die Prozesse aus dem Bereich einer Hardware- Entwicklung als Teilprozess in einer gesamten Forschungs- und Entwicklungsabtei- lung fur die Einfuhrung eines Risikomanagementsystems betrachtet.

Der Teilprozess innerhalb einer Hardware-Entwicklung ist schematisiert und das Risi- komanagement wird entsprechend darauf ausgerichtet.

Durch die Einfuhrung von Lean Management im Unternehmen werden gleichzeitig die relevanten Standards berucksichtigt und implementiert, um einen wirtschaftlich gunstigen Prozess ohne Verschwendung zu gestalten.

1.2 Gegenstand

In vielen Unternehmen werden die Methoden aus dem Lean Management vorwiegend in den produzierenden Bereichen eingefuhrt. Am Anfang der Einfuhrung von Lean Management steht oftmals das Bestreben, die Methoden aus den produzierenden Be- reichen auch in den administrativen Bereichen einzufuhren. Die gangigen Methoden wie Kanban oder Perfektion konnen in der Theorie fur die schlankere Produktion gut eingesetzt werden.

Fur die administrativen Bereiche gibt es wenig theoretische und praktische Ansatze, wie die Methoden aus dem Lean Management angewandt werden konnen. Hier gibt es verschiedene Ansatzpunkte in der Literatur:

- Lean Thinking, James P. Womack, Daniel T. Jones, Campus Verlag
- Kanban in der IT, Klaus Leopold, Siegfried Kaltenecker, Hanser Verlag
- Die Kata des Weltmarktfuhrers, Mike Rother, Campus Verlag
- Lean for Systems Engineering with Lean Enablers for Systems Engineering, Bohdan W. Oppenheim, Wiley Verlag

Der Fokus dieser Arbeit liegt im Bereich der Hardware-Entwicklung. In der Literatur wurden sogenannte Prinzipien beschrieben, die speziell fur den Entwicklungs-Bereich erforscht wurden. Dagegen wird das Thema Informationssicherheit immer mehr in Unternehmen etabliert. Die Anforderungen an Unternehmen aus verschiedenen Bran- chen werden durch Gesetze geregelt. Hierbei ist oft zu beobachten, dass Lean Ma­nagement und Informationssicherheit gegenlaufige Ansatze verfolgen, denn Lean Ma­nagement hat unter anderem das Ziel, Verschwendung zu eliminieren und Prozesse zu automatisieren wohingegen Informationssicherheit z.B. durch die Einfuhrung eines 4- Augen-Prinzips die Prozesse verlangsamen kann.

1.3 Ziel

Das Thema Risikomanagement ist fur jedes Unternehmen von Bedeutung und die Themen Informationssicherheit und Lean Management werden immer wichtiger, um den Standort fur Forschung und Entwicklung in Deutschland aufrecht zu halten.

Ziel dieser Ausarbeitung ist, ein aktives Risikomanagement auf den Forschungs- und Entwicklungsbereich zu ubertragen und die Anforderungen aus dem Bereich der In- formationssicherheit und dem Bereich des Lean Management mit einzubinden.

Nach der Durchfuhrung des Risikomanagements werden die Prioritaten und die Kriti- kalitat von den verarbeiteten Informationen auf die IT-Systeme ubertragen. Durch eine entsprechende Verknupfung der einzelnen Anforderungen aus der DIN EN/ISO 27001 konnen die nachsten Mafinahmen mit Fokus auf die Informationssicherheit abgeleitet werden. Abgeleitet aus dem Umsetzungsgrad der Lean Standards konnen ebenfalls Mafinahmen abgeleitet werden, die dazu beitragen, dass die Prozesse opti- miert, Verschwendung eliminiert und die Informationssicherheit erhoht wird.

Eine zusatzliche Verknupfung mit den Risikowerten aus dem Risikomanagement und den Prinzipien, Varianten und Untervarianten des Lean Management fur die System- und Produktentwicklung wird erarbeitet und der Umsetzungsgrad der einzelnen Prin­zipien berechnet.

Die Forschungs- und Entwicklungsbereiche sind nach der Durchfuhrung eines Risi- komanagements in der Situation, den Umsetzungsgrad fur die Eliminierung von Ver­schwendung ablesen zu konnen.

2 Grundlagen

Der Inhalt dieser Ausarbeitung basiert auf verschiedenen Kemthemen, die im Folgen- den naher beschrieben werden.

2.1 Lean Management

„Lean Management ist ein Begriff, der bis heute fur sehr viele kontroverse Diskussio- nen gesorgt hat. Lean Management wurde seit den 90er-Jahren von den Consultants als Kostensenkungsprogramm missbraucht, in vielen Unternehmensprogrammen und -projekten als Titel gefuhrt, von manchen vollkommen unbeachtet, von Toyota gar nicht genutzt (Begriff) und sehr oft falschlicherweise mit Kaizen in Konkurrenz ge- stellt. [...] Geht man von dem Unternehmen Toyota aus, so schauen wir auf einen bei- spielhaften Aufstieg eines Automobilherstellers, der heute die Weltspitze in der Au- tomobilindustrie erreicht hat. Dies wurde nicht durch Zukaufe von anderen Unter- nehmen/Marken erreicht, sondern durch die Nutzung des eigenen Leistungspotenzials des Unternehmens. Heute gilt Toyota als das Vorzeigeunternehmen fur eine Arbeits- weise und eine Unternehmensphilosophie und der Arbeitsweise der asiatischen Her- steller.[1]

„James P. Womack, Daniel T. Jones und Daniel Roos sind mit ihren Projektleitern John F. Krafcik und John P. MacDuffie die Erfinder des Begriffs „Lean Manage- ment“. Die Forscher, die am MIT im Rahmen des Forschungsprojekts International Motor Vehicle Program (IMVP) die Produktionssysteme der verschiedenen Autoher- steller untersucht haben, veroffentlichten am Ende eine Benchmark-Analyse, die in dem Buch „Die zweite Revolution in der Automobilindustrie“ dokumentiert ist. Die hier veroffentlichten Ergebnisse zeigen die gravierenden Unterschiede zwischen west- lichen und asiatischen (hauptsachlich japanischen) Herstellern und veranderten die Sichtweise innerhalb der gesamten Autoindustrie. Sie benennen das von ihnen beo- bachtete Prinzip Lean Management, das sich aus den Erfahrungen aus verschiedenen Unternehmen und Beobachtungen in der Praxis zusammensetzt.“[2]

„Lean Six Sigma ist der jungste Versuch, die Konzepte Lean Management und Six Sigma zu verbinden und von beiden das Beste einzusetzen. Dabei ist festzuhalten, dass dieses Konzept erst an seinem Beginn steht und sich noch in der Praxis beweisen muss.

Die Fulle der verschiedenen Gedankenrichtungen, welche die Historie von Lean Ma­nagement ausmacht, zeigt den wahren Ursprung und die Starke dieser Philosophie. Diese entstand nicht in einer Universitat oder auf einem Reifibrett, sondern wurde von vielen Experten von Weltrang systematisch entwickelt sowie in der Praxis erprobt und verfeinert. Der Familie Toyoda und Taiichi Ohno ist im Wesentlichen zu verdanken, dass diese verschiedenen Ideen unter einem Dach zu einem System zusammengefuhrt und konsequent umgesetzt worden sind. Dadurch konnten die verschiedenen Ansatze ihre volle Leistungsfahigkeit entwickeln und die Toyota Motor Corporation zu einem der weltgrofiten Unternehmen werden lassen.

Das Toyota-Produktionssystem wurde durch die besonderen Herausforderungen im Zeitraum der Entwicklung gepragt:

- Mangel an Rohstoffen (hohe Kosten),
- geringe Fertigungsmengen mit hoher Variantenvielfalt,
- Kapitalmangel,
- hohe Qualitatsanspruche.

Die heutigen Verdrangungsmarkte verlangen gerade vehement nach Erfullung dieser besonderen Anforderungen und spiegeln somit die Aktualitat und den Erfolg des Lean Management und der Lean-Unternehmen, angefuhrt von Toyota, wider. Toyota be- ginnt 1955 mit den ersten Auslieferungen auf dem amerikanischen Markt. Heute ist Toyota der grofite Autohersteller der Welt. Wahrend sich der Fuhrungsstil ublicher- weise nach einem Fuhrungswechsel in der obersten Leitung andert, indem neue Ak- zente gesetzt werden, verfahrt Toyota nach Dr. Demings Leitspruch „constancy of purpose“.“[3]

2.2 Informationssicherheit

Die Informationssicherheit ist fur Unternehmen von besonderer Bedeutung. Aufgrund der Enthullungen bezuglich der amerikanischen und britischen Nachrichtendienste in den Jahren 2013 / 2014 ist deutlich geworden, dass nicht nur Politiker, sondern auch gezielt einzelne Unternehmen ausspioniert werden.[4]

Zur Strukturierung der Managementaufgaben der IT-Sicherheit wurden in den letzten Jahren verschiedene Rahmenarchitekturen geschaffen. Zu nennen sind vor allem:

- Das vom Bundesamt far Sicherheit in der Informationstechnik (BSI) heraus- gegebene IT-Grundschutzhandbuch [...]
- Der Code of Practice for Information Securtiy der British Standard Institution (BS7799), der auch von der International Organisation for Standardizateion (ISO) als Norm ubernommen wurde [...]
- Das Security Handbook des National Institute of Standards and Technology [...]
- Die Common Criteria (ISO 15408) der International Organisation for Standar­disation zur Evaluation der IT-Sicherheit von Informationstechnik [...]

Diese Rahmenarchitekturen variieren stark in ihrer Anwendungsbreite und -tiefe.“[5]

Fur die Betreiber kritischer Infrastrukturen wird ab 2015 auch das IT- Sicherheitsgesetz von Bedeutung sein. Im Dezember 2014 wurde der Entwurf des Gesetzes durch die Bundesregierung beschlossen, so dass anzunehmen ist, dass das Gesetz im Laufe des Jahres 2015 in Kraft treten wird.[6]

Seit Beginn des Jahres 2015 wird eine VDS-Richtlinie in Anlehnung an die Vorge- hensweisen des IT-Grundschutz und der ISO 27001 fur kleine und mittelstandische Unternehmen erarbeitet. Ab Juni 2015 ist mit einer Fertigstellung zu rechnen.

Im Folgenden werden die relevanten Grundlagen beschrieben.

2.2.1 IT-Grundschutz

„In den IT-Grundschutz-Katalogen werden Standard-Sicherheitsmafinahmen fur typi- sche Geschaftsprozesse, Anwendungen und IT-Systeme empfohlen. Ziel des IT- Grundschutzes ist es, einen angemessenen Schutz fur alle Informationen einer Institu­tion zu erreichen. IT-Grundschutz verfolgt dabei einen ganzheitlichen Ansatz. Durch die geeignete Kombination von organisatorischen, personellen, infrastrukturellen und technischen Standard-Sicherheitsmafinahmen wird ein Sicherheitsniveau erreicht, das fur den normalen Schutzbedarf angemessen und ausreichend ist, um geschaftsrelevan- te Informationen zu schutzen. Daruber hinaus bilden die Mafinahmen der IT- Grundschutz-Kataloge nicht nur eine Basis fur hochschutzbedurftige IT-Systeme und Anwendungen, sondern liefern an vielen Stellen bereits hoherwertige Sicherheit.

Um den sehr heterogenen Bereich der Informationstechnik einschliefilich der Ein- satzumgebung besser strukturieren und aufbereiten zu konnen, verfolgt der IT-

Grundschutz das Baukastenprinzip. Die einzelnen Bausteine spiegeln typische Ablau- fe von Geschaftsprozessen und Bereiche des IT-Einsatzes wider, wie beispielsweise Notfall-Management, Client-Server-Netze, bauliche Einrichtungen, Kommunikations- und Applikationskomponenten. In jedem Baustein wird zunachst die zu erwartende Gefahrdungslage beschrieben, wobei sowohl die typischen Gefahrdungen als auch die pauschalisierten Eintrittswahrscheinlichkeiten berucksichtigt werden. Diese Gefahr­dungslage bildet die Grundlage, um ein spezifisches MaBnahmenbundel aus den Be- reichen Infrastruktur, Personal, Organisation, Hard- und Software, Kommunikation und Notfallvorsorge zu generieren.

Die Vorgehensweise nach IT-Grundschutz hilft dabei, Sicherheitskonzepte einfach und arbeitsokonomisch zu erstellen. Bei der traditionellen Risikoanalyse werden zu- nachst die Bedrohungen ermittelt und mit Eintrittswahrscheinlichkeiten bewertet, um dann die geeigneten SicherheitsmaBnahmen auszuwahlen und anschlieBend noch das verbleibende Restrisiko bewerten zu konnen. Diese Schritte sind beim IT- Grundschutz bereits fur jeden Baustein durchgefuhrt und die fur typische Einsatzsze- narien passenden SicherheitsmaBnahmen ausgewahlt worden. Bei Anwendung des IT- Grundschutzes reduziert sich die Analyse auf einen Soll-Ist-Vergleich zwischen den in den IT-Grundschutz-Katalogen empfohlenen und den bereits realisierten MaBnah- men. Dabei festgestellte fehlende und noch nicht umgesetzte MaBnahmen zeigen die Sicherheitsdefizite auf, die es durch die empfohlenen MaBnahmen zu beheben gilt. Erst bei einem signifikant hoheren Schutzbedarf muss zusatzlich eine erganzende Si- cherheitsanalyse unter Beachtung von Kosten- und Wirksamkeitsaspekten durchge­fuhrt werden. Hierbei reicht es dann aber in der Regel aus, die MaBnahmenempfeh- lungen der IT-Grundschutz-Kataloge durch entsprechende individuelle, qualitativ ho- herwertige MaBnahmen zu erganzen. Eine einfache Vorgehensweise hierzu ist im BSI-Standard 100-3 "Risikoanalyse auf der Basis von IT-Grundschutz" beschrieben.

Auch wenn besondere Komponenten oder Einsatzumgebungen vorliegen, die in den IT-Grundschutz-Katalogen nicht hinreichend behandelt werden, bieten diese dennoch eine wertvolle Arbeitshilfe. Die dann notwendige erganzende Analyse kann sich auf die spezifischen Gefahrdungen und SicherheitsmaBnahmen fur diese Komponenten oder Rahmenbedingungen konzentrieren.

Bei den in den IT-Grundschutz-Katalogen aufgefuhrten MaBnahmen handelt es sich um Standard-SicherheitsmaBnahmen, also um diejenigen MaBnahmen, die fur die je- weiligen Bausteine nach dem Stand der Technik umzusetzen sind, um eine angemes- sene Basis-Sicherheit zu erreichen. Dabei stellen die MaBnahmen, die fur die Zertifi- zierung nach ISO 27001 auf der Basis von IT-Grundschutz gefordert werden, das Mi­nimum dessen dar, was in jedem Fall vernunftigerweise an Sicherheitsvorkehrungen umzusetzen ist. Die als "zusatzlich" gekennzeichneten Mafinahmen haben sich eben- falls in der Praxis bewahrt, sie richten sich jedoch an Anwendungsfalle mit erhohten Sicherheitsanforderungen.

Sicherheitskonzepte, die auf IT-Grundschutz basieren, konnen kompakt gehalten wer­den, da innerhalb des Konzepts jeweils nur auf die entsprechenden Mafinahmen in den IT-Grundschutz-Katalogen verwiesen werden muss. Dies fordert die Verstandlichkeit und die Ubersichtlichkeit. Um die Mafinahmenempfehlungen leichter umsetzbar zu machen, sind die Sicherheitsmafinahmen in den IT-Grundschutz-Katalogen detailliert beschrieben. Bei der verwendeten Fachterminologie wird darauf geachtet, dass die Beschreibungen fur diejenigen verstandlich sind, die die Mafinahmen realisieren mus- sen.

Um die Realisierung der Mafinahmen zu vereinfachen, werden die IT-Grundschutz- Kataloge ebenso wie die meisten Informationen rund um IT-Grundschutz auch in elektronischer Form zur Verfugung gestellt. Daruber hinaus wird die Realisierung der Mafinahmen auch durch Hilfsmittel und Musterlosungen unterstutzt, die teilweise durch das BSI und teilweise auch von IT-Grundschutz-Anwendern bereitgestellt wer- den.

Da die Informationstechnik sehr innovativ ist und sich standig weiterentwickelt, sind die vorliegenden Kataloge auf Aktualisierbarkeit und Erweiterbarkeit angelegt. Das Bundesamt fur Sicherheit in der Informationstechnik aktualisiert auf der Grundlage von Anwenderbefragungen die IT-Grundschutz-Kataloge standig und erweitert sie um neue Themen.

Das BSI bietet allen Anwendern die Moglichkeit der freiwilligen, selbstverstandlich kostenfreien Registrierung an. Registrierte Anwender erhalten regelmafiig Informatio­nen uber aktuelle Themen des IT-Grundschutzes und der Informationssicherheit. Die Registrierung ist aufierdem die Grundlage fur die Anwenderbefragungen. Nur durch den standigen Erfahrungsaustausch mit den IT-Grundschutz-Anwendern ist eine be- darfsgerechte Weiterentwicklung moglich. Diese Bemuhungen zielen letztlich darauf, aktuelle Empfehlungen zu typischen Informationssicherheitsproblemen aufzeigen zu konnen. Mafinahmenempfehlungen, die nicht standig aktualisiert und erweitert wer­den, veralten sehr schnell oder mussen so generisch gehalten werden, dass sie ihren eigentlichen Nutzen, Sicherheitslucken zu identifizieren und die konkrete Umsetzung zu vereinfachen, verfehlen.“[7]

2.2.2 ITIL / ISO/IEC 20000

„Im Rahmen dieser Publikation wird das ITIL Framework als Quelle einer Good Prac­tice im Service Management erlautert. ITIL wird von Organisationen weltweit einge- setzt, um Fahigkeiten im Bereich des Service Management zu entwickeln und zu ver- bessern.. ISO/IEC 20000 bieten einen formalen und universellen Standard fur Organi­sationen, die fur ihre Service Management Fahigkeiten Audits und Zertifizierungen erhalten mochten. Wahrend es sich bei ISO/IEC 20000 um einen zu erreichenden und zu pflegenden Standard handelt, bietet ITIL einen Wissensgehalt, der zum Verstand- nis des Standards beitragt. [...] Der ITIL Kern umfasst funf Publikationen [...]. Jede der Publikationen bietet Leitlinien, die fur einen integrierten Ansatz in Ubereinstim- mung mit den Standardspezifikationen von ISO/IEC 20000 erforderlich sind:

- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Improvement

Jede der Publikationen behandelt Fahigkeiten, die sich direkt auf die Leistung eines Service Providers auswirken. Die Struktur des ITIL Kerns entspricht einem Lebens- zyklus. Der Lebenszyklus stellt sicher, dass Organisationen so strukturiert sind, dass sie ihre Fahigkeiten in einem Bereich ausnutzen konnen, um Erfahrungen und Verbes- serungen auf andere Bereiche ubertragen zu konnen. Der Kernbereich soll Service Management Fahigkeiten durch dauerhafte Grundsatze, Methoden und Hilfsmittel strukturieren, stabilisieren und starken. Damit werden Investitionen geschutzt und die erforderliche Basis fur Mafinahmen, Lernprozesse und Verbesserungen geschaffen.

Die ITIL Leitlinien konnen fur den Einsatz in unterschiedlichen Business- Umgebungen und organisatorische Strategien angepasst werden. Die Complementary Guidance bietet die Flexibilitat, um den Kerninhalt in den verschiedensten Umgebun- gen zu implementieren. Praktische Anwender konnen die Complementary Guidance bei Bedarf einsetzen, um den Kernbereich in einem bestimmten Business-Kontext veranzutreiben, ahnlich wie Autoreifen fur spezielle Fahrzeugtypen, Einsatzbereiche und StraBenverhaltnisse ausgewahlt werden. Somit soil die Bestandigkeit und Uber- tragbarkeit von Wissens-Assets gefordert und Investitionen in Service Management Fahigkeiten geschutzt werden.“8

„Das ISM muss innerhalb des gesamten Corporate Governance Frameworks betrach- tet werden. Die Corporate Governance umfasst eine Reihe von Verantwortungen und Practices, die von Aufsichtsrat und Geschaftsleitung mit dem Ziel wahrgenommen werden, eine strategische Richtung vorzugeben, das Erreichen von Zielen zu sichern, fur ein adaquates Risikomanagement zu sorgen und den effektiven Einsatz der Unter- nehmensressourcen sicherzustellen.

Die Informationssicherheit ist eine Management-Aktivitat innerhalb des Corporate Governance Frameworks, die die strategische Richtung von Sicherheitsaktivitaten vorgibt und das Erreichen von Zielen sichert. Daruber hinaus ermoglicht sie ein ada­quates Management der Sicherheitsrisiken und einen verantwortungsvollen Umgang mit den Informationsressourcen im Unternehmen. Zweck des ISM ist es, den Fokus auf alle Aspekte der IT-Security zu legen und alle IT Security Aktivitaten zu steuern und zu verwalten.

Der allgemein verwendete Begriff „Informationen“ umfasst die Datenspeicher, Da- tenbanken und Metadaten. Die Informationssicherheit verfolgt das Ziel, die Interessen der Personen, die sich auf Informationen verlassen, und die Systeme und Kommunika- tionseinrichtungen, die diese Informationen bereitstellen, vor Schaden durch fehlende oder unzureichende Verfugbarkeit, Vertraulichkeit und Integritat zu schutzen.

Fur die meisten Organisationen ist das Sicherheitsziel erreicht, wenn folgende Bedin- gungen erfullt sind:

- Informationen sind bei Bedarf verfugbar und brauchbar, und die Systeme, die sie bereitstellen, konnen Angriffe abwehren, Ausfalle verhindern oder bei Aus- fallen wiederhergestellt werden (Verfugbarkeit)
- Informationen werden ausschlieBlich von informationsberechtigten Personen uberwacht oder sind nur diesen zuganglich (Vertraulichkeit)
- Informationen sind vollstandig, genau und vor unberechtigten Anderungen ge- schutzt (Integritat)
- Business-Transaktionen und der Austausch von Informationen zwischen Un- temehmen oder Partnern sind vertrauenswurdig (Authentizitat und Nachweis- barkeit)

Die Priorisierung von Vertraulichkeit, Integritat und Verfugbarkeit muss im Zusam- menhang von Business-Prozessen betrachtet werden. In allererster Linie muss das Business vorgeben, was in welchem Mafie geschutzt werden muss. Um Effektivitat zu gewahrleisten, muss Sicherheit durchgehend fur einen Business-Prozess als Ganzes gelten und alle physischen und technischen Aspekte einschliefien. Sicherheit kann nur im Zusammenhang von Business-Bedurfnissen und -Risiken definiert werden.“[8]

2.2.3 ISO/IEC 27001

„Diese Internationale Norm wurde entwickelt, um ein Modell fur die Einrichtung, Umsetzung, Durchfuhrung, Uberwachung, Uberprufung, Instandhaltung und Verbes- serung eines Informationssicherheits-Managementsystems (ISMS) bereitzustellen. Die Einfuhrung eines ISMS sollte eine strategische Entscheidung fur eine Organisation sein. Die Gestaltung und Umsetzung eines ISMS hangen von den Bedurfnissen und Zielen, Sicherheitsanforderungen, eingesetzten Verfahren und der Grofie und Struktur der Organisation ab.“[9]

„Der Standard ISO 27001 definiert ein ISMS wie folgt:

„Teil des gesamten Managementsystems, der auf der Basis eines Geschaftsrisikoan- satzes die Entwicklung, Implementierung, Durchfuhrung, Uberwachung, Uberpru- fung, Instandhaltung und Verbesserung der Informationssicherheit abdeckt.“ [...]

Ein ISMS ist ein Teil eines allgemeineren, umfassenderen Management-Systems, das andere Teil der Organisation, moglicherweise die gesamte Organisation, und weitere Themen umfasst. [...]

Das ISMS baut auf der Einschatzung der Geschaftsrisiken auf. Ein ISMS sollte daher als ein Mittel verstanden werden, mit dem das Management einer Organisation auf erkannte Risiken im Geschaft der Organisation reagiert. [...]

Ein ISMS ist ein spezialisiertes System, in dessen Fokus die Wahrung der Informati­onssicherheit steht: Dort, wo der Verlust der Informationssicherheit zu signifikanten oder gar untragbaren Geschaftsrisiken fur die Organisation fuhren kann, ist der rechte Einsatzort eines ISMS. [...]

Ein Management-System schliefit folgende Bestandteile ein: die Organisationsstruk- tur, Verantwortlichkeiten, Planungsaktivitaten, Leitlinien und Regeln, Vorgehenswei- sen bzw. Praktiken, Prozesse, Verfahren und Ressourcen. [...]

Die Gesamtheit der Aktivitaten, ein ISMS einzufuhren und zu betreiben, wird als Pro- zess betrachtet. [...]

Da das ISMS durch die Erfordernisse und Ziele der Organisation - ihre Sicherheitsan- forderungen, die vorhandenen und zu schutzenden Geschaftsprozesse, ihre Grofie und Organisationsstruktur - bestimmt wird und diese sich mit der Zeit andern konnen, muss ein ISMS einerseits an die Bedurfnisse angepasst sein und sich andererseits mit den Bedurfnissen andern konnen. [...]

Prozesse lassen sich gut beherrschen und verbessern, wenn man einen bestimmten Zyklus von Aktivitaten auf sie anwendet. Dieser ist unter der Bezeichnung PDCA- Modell bekannt. [...]“n

Diese ISO-Norm gewinnt weltweit und branchenubergreifend immer mehr an Bedeu- tung. Viele Unternehmen in der Automobilindustrie und Medizintechnik verlangen z.B. die Zertifizierung auf Basis dieser Norm.

2.2.4 NIST

„NIST 800-Serie

[...] Das amerikanische National Institute of Standards an Technology (NIST) defi- niert in der NIST 800-Serie ebenfalls die Sicherheit von Informationssystemen. Es gibt verschiedene Veroffentlichungen, die den Rahmen fur die Entwicklung und Be- triebsfuhrung sicherer Informationstechnologie beschreiben. Diese umfassen allge- meine Mafinahmen bis hin zu Checklisten fur den Einsatz spezieller Systeme.

[...] Der Risk Management Guide for Information Technology Systems (NIST 800-30) erlautert den grundlegenden Ablauf von IT-Security Management anhand des IT- System-Lebenszyklus [Fufinote: Siehe NIST-Veroffentlichungen unter

www.nist.gov.] und verweist hinsichtlich der Detailauspragungen auf andere NIST- Standards wie beispielsweise NIST 800-27 Engineering Principles for IT-Security oder den NIST 800-14 Generally Accepted Principles and Practices for Securing In­formations Technology. Der NIST 800-14 hatte als Basis die Standards BS 7799 bzw. ISO 17799. [Fufinote: Vgl. ITGI, 2004, S. 43-45.] [...]“[10] [11]

2.2.5 Common Criteria

„ISO/IEC 15408 bzw. Common Criteria/ITSEC

[...] Im Zusammenhang mit dem IT-Risikomanagement bzw. dem IT-Security Ma­nagement wird vielfach der ISO Standard 15408 Security Techniques - Evaluation Criteria for IT-Security - genannt. Dieser ist der international Standard der soge- nannten Common Criteria (CC), die ein frei erhaltliches Werk far die Prufung und Bewertung von Informationstechnik sind. [Fufinote: Siehe www.commomcriteria.org oder www.bsi-bund.de/cc.] Die Common Criteria stellen eine Weiterentwicklung der europaischen Kriterien fur die Bewertung der Sicherheit von Systemen der Informati- onstechnik (ITSEC) dar. Sie erfolgte im Rahmen der Harmonisierung mit den gleich- artigen Standardisierungen der USA (Orange-Book - TCSEC) und Kanada (CTPSEC). [Fufinote: Vgl. BSI, 2005.]

[...] Die Common Criteria erweitern die ITSEC in der Form, dass alle ITSEC- Zertifizierungen dem ISO-Standard entsprechen. [Fufinote: Vgl. BSI, 2005.] Die Common Criteria ermoglichen die Bildung von sogenannten Schutzprofilen, in denen die Anforderungen an die Sicherheitsfunktionalitat und Vertrauenswurdigkeit definiert sind. Diese Schutzprofile sind zunachst implementationsunabhangig und konnen von Anwendern oder Wirtschafts- bzw. Interessenverbanden zur Definition spezifischer Schutzanforderungen an Produkttypen, wie beispielsweise den Chipkarten-Einsatz, genutzt werden. Anschliefiend konnen sie auf konkrete IT-Systeme, sogenannte Eva- luationsgegenstande (EVG), ubertragen werden. Die Vorgehensweise innerhalb der Common Criteria stellt eine vollstandige, konsistente und angemessene Anforde- rungssammlung sicher. Die Schutzprofile konnen zertifiziert werden und stehen allen interessierten Gruppen zur Verfugung. [...]“13

2.2.6 SPICE

„ISO/IEC 15504 bzw. SPICE

[...] Mitte der 1990er Jahre hat die Projektgruppe SPICE (Software Process Improve­ment Capability Determination), welche von der ISO/IEC beauftragt wurden, einen Standard zur Bewertung der Qualitat von Software-Entwicklungsprozessen zu erarbei- ten, ihre Projektergebnisse fertiggestellt. [Fufinote: Die Ergebnisse sind in der Pro- jektversion frei zuganglich; siehe www.sqi.gu.edu.au.] Diese wurden in den Standard ISO/IEC 15504 ubernommen und gliedern sich in zahlreiche Normen, wie z.B. die Qualitatsstandards ISO 9000 etc. und dem Software-Lebenszyklus-Standard 12207 ein. SPICE hat Mapping-Listen erstellt, um Prozesse aus SPICE anderen Standards zuordnen zu konnen. SPICE gewinnt in den letzten Jahren immer mehr an Bedeutung, da insbesondere die Automobilhersteller zumeist auf eine Zertifizierung der Zulieferer bestehen.

[...] [Fufinote: Vgl. SPICE, 1995] SPICE gliedert sich in 9 Teile, wobei jene fur die Prozessarchitektur, die Prozessratingstandards und fur die mogliche Toolunterstut- zung der Assessments normgebend sind. Die Prozessarchitektur ist 3-schichtig. Auf der obersten Ebene werden die Prozesse in

- Customer Supplier (Kundenunterstutzung),
- Engineering (Softwareerstellung),
- Project (Projektmanagement),
- Support (Supportprozesse fur die Softwareerstellung) und
- Organization (Prozesse zur Unterstutzung der Geschaftsziele) unterschieden. Diesen Prozessgruppen folgen dann zwei weitere, hierarchische Auf- teilungen. Die zweite Ebene beinhaltet bereits 35 Prozessgruppen. Durch diese Pro­zessarchitektur kann sichergestellt werden, dass alle fur eine angemessene Software- entwicklung relevanten Prozesse vorhanden sind. Diese werden in unterschiedlich ausfuhrbaren Assessments auf ihre Angemessenheit hinsichtlich der Ausgestaltung und der Prozessreife hin uberpruft. die Prozessreifeeinteilung basiert auf dem CMM- Modell [...].“14

2.2.7 CobiT

„CobiT

[...] [Fufinote: Vgl. ITGI, 2004, S. 8-15]. Ursprunglich wurde CobiT [...] von der ISACF [...] entwickelt. [...] CobiT soll die Einhaltung von IT-Governance unterstut- zen. Es hat den Anspruch, samtliche Belange des IT-Managements abzudecken. Dies bezieht sich sowohl auf den fachlichen Umfang als auch auf die unterschiedlichen, hierarchischen Ebenen. Als Grundlage fur CobiT haben unterschiedlichste Standards gedient.

[...] Das CobiT-Framework stellt einen Regelkreislauf dar, der die Anforderungen an die Informationen, die in den Geschaftsprozessen verarbeitet werden, und die IT- Ressourcen, die diese Verarbeitung bewerkstelligen, in den Mittelpunkt stellt. [...][12]

2.3 Risikomanagement

„Risiken sind untrennbar mit jeder unternehmerischen Tatigkeit verbunden und kon- nen den Prozess der Zielsetzung und Zielerreichung negativ beeinflussen. Sie resultie- ren ursachenbezogen aus der Unsicherheit zukunftiger Ereignisse - wobei dies regel- maBig mit einem unvollstandigen Informationsstand einhergeht - und schlagen sich wirkungsbezogen in der Moglichkeit negativer Abweichungen von einer festgelegten ZielgroBe nieder. Werden Risiken nicht rechtzeitig erkannt und bewaltigt, konnen sie die erfolgreiche Weiterentwicklung der Unternehmung gefahrden, sogar in Krisen im Sinn von uberlebenskritischen Prozessen einmunden (Unternehmenskrise).“[13]

2.3.1 ISO/IEC 27005

„Die ISO/IEC 27005 ist aus dem Teil 2 des bisherigen ISO/IEC 13335-2 hervorge- gangen. Der Standard enthalt Leitlinien fur ein systematisches und prozessorientiertes Risikomanagement, das gegebenenfalls auch die Einhaltung der Anforderungen an das Risikomanagements nach ISO/IEC 27001 unterstutzt. [...]

Ein Informationssicherheitsrisiko wird definiert als Potential, dass eine Bedrohung eine Schwachstelle eines Unternehmenswertes ausnutzt und dadurch zu einem Scha- den fur eine Organisation fuhrt. Zur systematischen Identifikation, Bewertung und Behandlung von Informationssicherheitsrisiken wird ein Prozess beschrieben, der als Ergebnis eine priorisierte Liste von Risiken hat, die anschlieBend kontinuierlich zu verfolgen sind.

Im Einzelnen definiert der Standard die folgenden wesentlichen Schritte beim Ma­nagement von Informationssicherheitsrisiken:

- Definition der Rahmenbedingungen (Context establishment)

Zur Definition der Rahmenbedingungen gehoren dann die Festlegung von Kriterien zur Bewertung und Akzeptanz von Risiken, die Abgrenzung des Betrachtungsberei- ches sowie die Etablierung einer Organisation fur das Risikomanagement.

- Identifizierung von Risiken (Risk identification)

Risiken werden identifiziert, indem alle Untemehmenswerte erfasst werden, die im Betrachtungsbereich liegen. Dabei ist darauf zu achten, dass Unternehmenswerte nicht nur Hardware und Software umfasst, sondern auch Geschaftsprozesse und Informati- onen.

Auch mussen alle relevanten Bedrohungen (Beispiel: Brand) sowie vorhandene Schwachstellen (Beispiel: fehlender Brandschutz) ermittelt werden. Weiterhin werden alle bestehenden oder bereits geplanten Sicherheitsmafinahmen identifiziert, da diese die Risiken beeinflussen, indem sie Eintrittswahrscheinlichkeiten oder Schadensaus- mafi reduzieren konnen.

Schliefilich sind die Konsequenzen zu ermitteln, die entstehen konnen, wenn eine Be- drohung auf eine Schwachstelle trifft. Als Konsequenzen werden unter anderem Ver- lust von Geschaftsvolumen oder Reputation genannt.

- Abschatzung von Risiken (Risk estimation)

Die Bewertung des Risikos kann auf der Grundlage verschiedener Einflussgrofien erfolgen wie Kritikalitat der Unternehmenswerte, Ausmafi von Schwachstellen oder Auswirkungen bekannter Sicherheitsvorfalle.

Grundsatzlich kann die Bewertung mit qualitativen (Beispiel: „niedring“, „hoch“, „selten“, „oft“), quantitativen (Beispiel: „10.000 €“, „85 Prozent“) oder hybriden Me- thoden erfolgen. In der Praxis wird fur einen Anwendungszweck eine Methode ge- wahlt, fur die hinreichendes Zahlenmaterial verfugbar ist und deren Aussagekraft dem Ziel der Risikobewertung angemessen ist.

Fur die Abschatzung von Risiken mussen zum einen die Konsequenzen bewertet wer­den, genauer gesagt, das Schadensausmafi bei Verletzung der Vertraulichkeit, Integri- tat oder Verfugbarkeit. Zum anderen muss die Eintrittswahrscheinlichkeit eines sol- chen Sicherheitsvorfalls bestimmt werden.

Schliefilich wird durch Kombination des Schadensausmafies und der Eintrittswahr- scheinlichkeit ein Risikoniveau bestimmt.

- Auswertung von Risiken (Risk evaluation)

Dieser Schritt ist im Standard zur Priorisierung der Risiken vorgesehen. Die Priorisie- rung kann beispielsweise dadurch erfolgen, dass Risiken fur Unternehmenswerte, die weniger wichtige Geschaftsprozesse unterstutzten, gering priorisiert werden.

- Behandlung von Risiken (Risk treatment)

Es ist zu entscheiden, ob ein Risiko reduziert, akzeptiert, vermieden oder ubertragen wird. Wahrend zur Reduzierung geeignete SicherheitsmaBnahmen definiert werden mussen, konnen Risiken, die die Akzeptanzkriterien fur Restrisiken erfullen, unbe- handelt bleiben. Ein Risiko kann vermieden werden, indem bspw. ein kritisches Sys­tem in einer geschutzten Umgebung aufgestellt wird, wo es besser gegen Naturkata- strophen geschutzt ist. Die Ubertragung von Risiken an Dritte kann uber Versicherun- gen oder durch geeignete Vertragsformulierungen erfolgen.

- Akzeptanz von Risiken (Risk acceptance)

Das Ergebnis der Risikobehandlung ist ein Plan, der fur jedes Risiko die entsprechen- den Handlungsempfehlungen aufzeigt. Die Leitungsebene einer Organisation kann entscheiden, Risiken zu akzeptieren, auch wenn diese nicht die Akzeptanzkriterien erfullen. Fur diese Falle wird eine formelle Risikoubernahme gefordert.

- Kommunikation von Risiken (Information security risk communication)

Informationen uber Risiken sollten mit Entscheidungstrager und weiteren relevanten Mitarbeitern ausgetauscht werden.

Wahrend die oben genannten Schritte der erstmaligen Identifizierung, Bewertung und Behandlung von Risiken dienen, definiert der Standard weitere Aktivitaten, um die Aktualitat der Ergebnisse und angewandten Methoden sicherzustellen.

- Uberwachung von Risiken und Risikomanagement

Risiken sind von geschaftlichen Anforderungen und technologischen Rahmenbedin- gungen abhangig und damit einem Anderungsprozess unterworfen. Daher mussen die Risiken, das heiBt auch Bedrohungen, Schwachstellen und weitere EinflussgroBen wiederkehrend auf Anderungen untersucht werden.

Ebenso ist der in der Organisation angewandte Ansatz fur das Risikomanagement re- gelmaBig auf Angemessenheit zu uberprufen.

2.3.2 ISO/IEC 31000

„Die ISO 31000:2009 bietet Prinzipien und allgemein gultige Leitfaden fur ein Risi- komanagement. Diese Norm kann offentlichen oder privaten Unternehmen, Beteili- gungen, Kooperationen oder einzeln eingesetzt werden. Die Anforderungen sind nicht auf einen Wirtschaftszweig spezifiziert.

Nach einer erfolgreichen Umsetzung sind Organisationen befahigt etliche MaBnah- men abzuleiten, inkl. Strategien und Entscheidungen, Prozessen, technische Funktio- nalitaten, Produkte, Services und Untemehmenswerte. Jede Art von Risiko wird er- fasst und bewertet.“[14]

Diese ISO-Norm wurde im Jahr 2013 veroffentlicht und gibt Ansatzpunkte far die Einfuhrung eines Risikomanagements.

2.3.3 NIST

„[...] Die NIST-Standards ermoglichen die Einhaltung eines hohen Sicherheitspoten- zials bezuglich der IT-Security. Sie unterstutzen damit das IT-Risikomanagement auf diesem Gebiet. Sie stellen bislang jedoch kein umfassendes IT-Risikomanagement dar.“[15]

2.3.4 Common Criteria

„[...] Die Common Criteria stellen eine Methode zur Definition von Sicherheitsanfor- derungen dar. Sie sind eine Unterstutzung zur Erreichung von IT-Security im Soft- wareentwicklungs- und Evaluationsprozess. Sie konnen als Mafinahme zur Risikore- duzierung verwendet werden, stellen fur sich aber kein IT-Risikomanagement dar. Samtliche Aspekte des IT-Managements sind in dieser Norm nicht berucksichtigt. [Fufinote: Vgl. ITGI, 2004, S. 36-39 sowie InitiativeD21, 2001]“[16]

2.3.5 SPICE

„[...] SPICE kann eingesetzt werden, um die eigenen Softwareentwicklungsprozesse auf ihre Qualitat hin zu uberprufen und daraus ggf. Prozessverbesserungen abzuleiten, die dann bei zukunftigen Softwareentwicklungsprojekten angemessen berucksichtigt werden, oder um die Softwareentwicklungsprozesse bei Dritten, wie zum Beispiel bei Zulieferern, auf ihre Qualitat hin zu testen. SPICE bildet einen wichtigen Standard hinsichtlich einer moglichen IT-Risikoreduzierungsmafinahme, stellt aber selbst kein Risikomanagement-Framework dar.“[17]

2.3.6 CobiT

[...]Das CobiT-Framework stellt kein dediziertes IT-Risikomanagement-Framework dar, unterstutzt jedoch durch seinen weitgefacherten Ansatz die Durchfuhrung des IT- Risikomanagements sehr gut. Die Anforderungen an die Informationen und die Res- sourceneinteilung konnen leicht den Anspruchen des IT-Risikomanagements zuge- ordnet werden.“[18]

2.4 Rechtliche Grundlagen

Die Einfuhrung und kontinuierliche Umsetzung eines Risikomanagements ist in ver- schiedenen Gesetzen fur Unternehmen vorgeschrieben. Hierbei wird verlangt, dass jedes Unternehmen ein Risikomanagement einfuhrt. Die genauen Vorgaben sind ge- setzlich nicht naher beschrieben oder definiert und konnen individuell in jedem Un­ternehmen eingefuhrt werden.

2.4.1 Compliance

„Der Begriff stammt aus der amerik. Finanzbranche und betraf fruher Bereiche mit hohem Risiko vom Insidergeschaften und Interessenkonflikten. In Deutschland entwi- ckelten sich Compliance-Strukturen seit den 1990er Jahren aufgrund gesetzgeberi- scher Vorgaben vor allen in den Banken und Versicherungen. [...]

Mittlerweile dienen Compliance-Strukturen und -Prozesse zunehmend auch Indust- rieunternehmen zur Pravention spezieller Unternehmensrisiken im Rahmen des Risi­komanagements. Aufgrund der steigenden rechtlichen Anforderungen an borsenno- tierte Unternehmen richten insbesondere grofie Industrieunternehmen zunehmend sog. Compliance-Abteilungen ein. I.d.R. sind Compliance-Abteilungen uber die Uberwa- chung der Einhaltung des Insiderhandelsverbots und das Fuhren von Insiderverzeich- nissen hinaus z.B. auch die Bereiche Kartellrecht, Korruptionspravention, Einhaltung umweltrechtlicher Anforderungen zugeordnet. Der Bereich Compliance umfasst dabei auch die Einhaltung eigener ethischer Verhaltenskodizes und anderer nicht- gesetzlicher Regelungen. Uberschneidungen und Beruhrungspunkte gibt es zumeist mit den Rechts- und Investor-Relations-Abteilungen (Investor Relations). Vergleich- bar detaillierte Vorgaben wie fur Kreditinstitute gibt es fur Industrieunternehmen nicht. Nach §91 II AktG hat der Vorstand jedenfalls geeignete Mafinahmen zu treffen, insbesondere ein Uberwachungssystem einzurichten, damit den Fortbestand der Ge- sellschaft gefahrdende Entwicklungen fruh erkannt werden.[19]

2.4.2 KonTraG

Das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich, kurz KonTraG, ist 1998 in Kraft getreten. Mit der Veroffentlichung des KonTraG sind verschiedene

Anderungen im Aktiengesetz und im Handelsgesetzbuch umgesetzt worden, die die Ermittlung, die Aufnahme in eine Berichterstattung sowie die Prufung dazugehoriger Risiken, die fur den Bestand eines Unternehmens gefahrlich sein konnen, beschrei- ben.[20]

„1. Begriff: Vom Deutschen Bundestag am 5.3.1998 beschlossenes und am 1.5.1998 in Kraft getretenes Artikelgesetz, das insbesondere im Handels- und Aktienrecht An­derungen vornahm.

2. Ziele und Inhalte: Mit dem KonTraG sollte die Corporate Governance in deutschen Unternehmen fortentwickelt werden. Zu den bedeutsamsten Neuregelungen gehorte die Erweiterung der Haftung von Vorstand, Aufsichtsrat und Wirtschaftsprufer. Akti- engesellschaften und Unternehmen, auf die die entsprechenden Bestimmungen des Aktienrechts Ausstrahlungswirkungen haben (z.B. bestimmte GmbH), wurden durch den neu eingefuhrten § 91 II AktG verpflichtet „geeignete MaBnahmen zu treffen, insbesondere ein Uberwachungssystem einzurichten, damit den Fortbestand der Ge- sellschaft gefahrdende Entwicklungen fruh erkannt werden“ konnen („Risikofruher- kennungssystem“). Die adaquate Funktionsweise des Risikofruherkennungssystems ist Teil der Sorgfaltspflicht des Vorstands (§ 93 I S. 1 AktG) und des Aufsichtsrats (§ 116 AktG). Daruber hinaus mussen Aussagen zu den Risiken des Unternehmens im Lagebericht veroffentlicht werden, und das Bestehen und der Betrieb des Risikofruh­erkennungssystems mussen vom Abschlussprufer gepruft werden.“[21]

2.4.3 BilMoG

„Im Jahre 2009 wurden durch das Bilanzrechtsmodernisierungsgesetz (BilMoG) wei- tere relevante Praszisierungen in das Handelsgesetzbuch und das Aktiengesetz einge- fuhrt. Die getroffenen Regelungen ahneln in ihrem Inhalt den Regelungen im weiter unten besprochenen Sarbanes-Oxley Act. Sie setzen die Anforderungen aus der 8.ten Kapitalmarktrichtlinie der EU (so genannte Euro S-Ox Richtlinie) um.“[22]

2.4.4 GDPdU, GoBS

„Eine allgemeingultige, gleichwohl weniger bekannte Verpflichtung zur Vorsorge ergibt sich aus den seit 1.1.2002 geltenden Grundsatzen zum Datenzugriff und zur Prufbarkeit digitaler Unterlagen sowie den Grundsatzen ordnungsgemaBer DV- gestutzter Buchfuhrungssysteme. Durch diese Vorschriften werden einerseits die

Rechte der Finanzverwaltung beim Zugriff auf unternehmenseigene elektronisch ge- speicherte Informationen geregelt und andererseits dem Unternehmen gewisse Sorg- faltspflichten bei der Verarbeitung, Vorhaltung und Bereitstellung dieser Informatio­nen auferlegt. Diese Vorschriften, die unabhangig von der Rechtsform eines Unter- nehmens gelten, fordern von den Unternehmen die Einrichtung eines internen Kon- trollsystems (IKS):

- Als IKS wird grundsatzlich die Gesamtheit aller aufeinander abgestimmten und miteinander verbundenen Kontrollen, Mafinahmen und Regelungen be- zeichnet, die die folgenden Aufgaben haben: Sicherung und Schutz des vor- handenen Vermogens und vorhandener Informationen vor Verlusten aller Art. [...]

Ein solches IKS schliefit offensichtlich ein vollstandiges Informationssicherheitsma- nagement-System (ISMS) ein.“[23]

2.4.5 S-Ox

„Fur Aktiengesellschaften, die an einer US-Borse notiert sind oder far Tochter dieser Unternehmen, ergeben sich ahnliche Forderungen aus dem amerikanischen Sarbanes- Oxley Gesetz (S-Ox), das anlasslich der Finanzskandale im Zusammenhang mit Wor- ldcom, Enron und der Wirtschaftsprufungsgesellschaft Arthur Anderson auf den Weg gebracht wurde und 2002 in Kraft trat.

Dieses Gesetz zielt hauptsachlich auf eine Wiederherstellung des Vertrauens in die Finanzberichterstattung und die damit in Zusammenhang stehenden Testate von Wirt- schaftsprufern ab. Zu Wiederherstellung des Vertrauens in deren unabhangiges Urteil sind die Wirtschaftsprufer fur Unternehmen, die unter dieses Gesetz fallen, von be- stimmten Beratungsfeldern ausgeschlossen (IT-Beratung) bzw. unterliegen diesbezug- lich Einschrankungen (IT-Sicherheitsberatung).“[24]

2.4.6 COSO

„Zur Definition der Anforderungen an die Finanzberichterstattung bzw. Buchfuhrung und deren sichere Verwahrung wird im amerikanischen Raum im Allgemeinen auf die unter dem Kurzel COSO (Committee of the Sponsoring Organizations oft he Tread­way Commission) bekannten Grundsatze zuruckgegriffen. COSO definiert quasi die

US-amerikanischen Grundsatze ordnungsgemaBer Rechnungslegung einschliefilich einiger Implikationen hinsichtlich der IT.

Aus den praktischen Erfahrungen mit der Umsetzung des Sarbanes-Oxley Gesetzes wird jedoch klar, dass die betroffenen Unternehmen in erheblichem MaB unnutzen Aufwand burokratischer Arbeit leisten.“[25]

2.4.7 Basel II, Solvency II

„Wenig konkretes zu IT- und Informationssicherheit findet sich auch in anderen Vor- gaben. Die Kapitaladaquanzrichtlinie fur Banken (Basel II) gilt zunachst einmal nur fur Banken. Das Pendant fur Versicherungen ist unter dem Namen Solvency II be- kannt und wird uber die EU-Richtlinie, nach der die EU-Staaten jeweils ihre Gesetze auszurichten haben, fur die betroffenen Unternehmen verbindlich. Im Jahre 2013 soll nach gegenwartigem Stand mit Basel III ein neues Regelwerk fur die Banken verbind- lich werden.

Allgemein wird im Zusammenhang mit solchen Vorgaben die Berucksichtigung der operativen Risiken gefordert, zu denen auch die IT-Risiken zahlen. Da Banken und Versicherungen auch die Risiken im Zusammenhang mit ihren Kunden zu berucksich- tigen haben, wirken die Forderungen dieser Gesetze mittelbar auf die Kreditnehmer, Versicherungsnehmer und die Dienstleister dieser Zielgruppen.“[26]

2.4.8 Kreditwesengesetz

„Ahnlich allgemein gehaltene Regelungen finden sich im Kreditwesengesetz. Von Bedeutung ist, dass die Banken und Versicherungen nicht mehr wie bisher einen ein- heitlichen Prozentsatz ihrer Eigenkapitalunterlegung fur die Absicherung der getatig- ten Risiken unterstellen durfen. Vielmehr mussen diese Institute in Zukunft eine filig- ranere interne Risikoermittlung durchfuhren. An Hand des ermittelten Risikos wird dann der verlangte Eigenkapitalanteil festgemacht. Hierbei wird auch eine Betrach- tung der operativen Risiken verlangt.“[27]

2.5 Fazit der Grundlagen

Aufgrund der Vielzahl der Regelungen, Normen, Best Practice-Ansatzen und gesetzli- chen Regelungen mussen die fur ein Unternehmen relevanten Grundlagen sorgfaltig gepruft und ausgewahlt werden.

In den folgenden Kapiteln bilden der IT-Grundschutz und die ISO 27001 die Basis fur die Erstellung des Risikomanagements bei gleichzeitiger Beachtung der Anforderun- gen an die Informationssicherheit. Diese Vorgaben sind fur die Mehrzahl der Unter- nehmen nicht verpflichtend.

Die gesetzlichen Grundlagen mussen entsprechend der Branche und der Unterneh- mensstruktur gepruft und ausgewahlt werden. Rechtlich bewertet muss ein Risikoma- nagement betreiben werden.

Die Anforderungen aus dem Bereich Lean Management sind nicht verpflichtend und vor der Einfuhrung sollten die entsprechenden Kapazitaten betrachtet werden.

3 Der Entwicklungsprozess

Der Prozess im Bereich der Forschung & Entwicklung besitzt eine hohe Dynamik, so dass sich Prozesse nur schwer darstellen lassen. Dies basiert insbe-sondere auf den unterschiedlichen Produkten, Produktanforderungen und Produkt-bandbreiten mit verschiedenen Varianten. Somit erklaren sich Anpassungen innerhalb des definierten Ablaufs.

Der Prozess der Entwicklung beschreibt die Moglichkeit, die aufeinander folgenden Schritte zu erfassen und transparent darzustellen. In immer mehr Unter-nehmen werden die Prozesse beschrieben, um technische und organisatorische Ablau-fe zu schematisieren. Der Entwicklungsprozess wird je Unternehmen unterschiedlich dargestellt werden. Fur das Risikomanagement ist es erforderlich, dass in einem Pro­zess definiert ist, welche Informationen, IT-Systeme, Verantwortlichkeiten und Schnittstellen betrachtet werden. Diese Angaben sollten in jedem Prozessschritt be­schrieben werden. Ein grofier Detaillierungsgrad ist nicht erforderlich.

Jedoch ist es moglich, eine grobe Struktur fur den Entwicklungsablauf zu definieren. Dennoch ist es durchaus sinnvoll, dass verschiedene Prozesse parallel gestartet wer- den, obwohl die vorherigen Meilensteine noch nicht erfolgreich abgeschlossen wur- den, z.B. kann die Erstellung des Lastenheftes beginnen, obwohl das Projekt nicht abschliefiend definiert wurde.

Insgesamt liegt der Fokus der hier beschrieben Phasen nicht in der sequentiellen Ab- arbeitung der Prozesse, sondern im Abschluss der einzelnen Meilensteine. Der erfolg- reiche Abschluss der einzelnen Meilensteine muss in der vorgegebenen Reihenfolge gewahrleistet sein.

3.1 Konzeptphase

In dieser Phase werden die Ideen der Kunden oder Mitarbeiter gesammelt und in ei- nem Ideenmanagementteam bewertet. Ist ein Trend erkennbar, werden diese Ideen konkretisiert. Aus einer Idee wird ein Projekt mit einem entsprechenden Portfolio formuliert und bewertet.

Meilenstein 0: Das neue Projekt wurde von den verantwortlichen Stellen im Unter- nehmen, oftmals die Geschaftsfuhrung oder der Vorstand, beschlossen und das Pro­jekt kann gestartet werden.

3.2 Projektdefinitionsphase

In dieser Phase entsteht aus der beschlossenen Idee ein Projektentwurf. Dieser Ent- wurf muss zeitlich und personell mit der Gesamtplanung aller Projekte abgestimmt werden. Nach dieser Abstimmung konnen die folgenden Prozesse gestartet werden. Meilenstein 1: Die Machbarkeitsanalyse und -planung ist freigegeben. Nach der er- folgreichen Projektplanung und -simulation wird das Projekt in die zukunftige Pla- nung aufgenommen.

3.3 Produktdefinitionsphase

Wahrend dieser Phase werden die Machbarkeitsstudien und Kompetenzprufungen begonnen. Alle erforderlichen Erkenntnisse zu diesem Zeitpunkt werden im Lasten- heft beschrieben.

Meilenstein 2: Das Lastenheft ist abgeschlossen und alle entsprechenden Anforderun- gen sind beschrieben

3.4 Realisierungskonzeptphase

Die Kompetenzprufungen werden in dieser Phase fortgesetzt. Da nun die konkreten Produktanforderungen umgesetzt werden sollen, werden zu diesem Zeitpunkt die Ge- sprache mit Entwicklungspartnern gefuhrt, die in ein Angebot oder Pflichtenheft um- gewandelt werden.

Meilenstein 2.1: Das Pflichtenheft bzw. das Angebot ist erstellt und unterzeichnet.

3.5 Entwicklungsphase

Zu Beginn der Entwicklungsphase werden Form und Funktion des Produktes entwi- ckelt. Sobald diese Produktentwicklungsphase abgeschlossen ist, werden die Pro- dukteigenschaften fixiert und durch Prototypen, Muster und zuvor vereinbarte Tests bestatigt, so dass die Produktanforderungen gemafi der Idee und Planung abgeglichen werden.

Meilenstein 3: Der erste Qualitatstest in Bezug auf die Produktanforderungen ist er- folgreich abgeschlossen.

3.6 Realisierungsphase

In dieser Phase wird die Produktentwicklung abgeschlossen. Das bedeutet, dass am Ende dieser Phase das Produkt durch einen Qualitatstest fertig gereift fur die Produk- tion ist.

Meilenstein 4: Das komplette Produkt inkl. der Zukauf- und Einzelteile als auch der benotigten Baugruppen ist serienreif. Alle erforderlichen Kompetenzprufungen sind abgeschlossen und das Produkt hat den zweiten Qualitatstest bestanden. Die vorher berechnete Erstauftragsmenge ist produziert worden.

3.7 Prozessvalidierungsphase

Ab diesem Zeitpunkt konnen die bisher entwickelten Produkte verkauft werden. Die internen Prozesse fur das Kundenauftragsgeschaft mussen ggf. noch angepasst werden und die einzelnen Produktionsstatten mussen entsprechend ausgestattet und geschult werden.

Meilenstein 5: Alle Produkte, Werkzeuge und Anlagen sind serienreif und konnen eingesetzt werden. Seitens der Forschung & Entwicklung wird der Projektbericht ab- geschlossen und archiviert.

3.8 Serienphase

Alle entwickelten Produkte konnen durch Kunden bestellt werden. Die Produktion ist soweit eingerichtet, dass alle Produkte entsprechend verarbeitet und versendet werden konnen. Das Entwicklungs-Team ist zu diesem Zeitpunkt nicht aktiv, es sei denn, es werden Produktmangel erkannt. Das Entwicklungs-Team ubernimmt die Produkt- uberarbeitung im Rahmen der Wertschopfungskette im Unternehmen. Die Produktion und deren Verantwortliche sind im Rahmen des taglichen Ablaufs an der Optimierung der Prozesse interessiert.

Meilenstein 6: Am Ende der Serienphase wird von der Geschaftsfuhrung oder dem Vorstand entschieden, dass Produkte in der Serienfertigung den Produktlebenszyklus beenden sollen. Es wird ein Produktauslaufplan vorgelegt und beschlossen.

3.9 Produktauslaufphase

Wahrend der Produktauslaufphase wird die zu produzierende Menge der Produkte stetig reduziert, die Werbemafinahmen werden eingeschrankt und zu einem vorher definierten Stichtag wird die Produktion beendet. Idealerweise werden die restlichen Produkte ausgeliefert, so dass der Bestand an Zukauf- und Einzelteilen, Baugruppen und fertigen Produkte vollstandig reduziert ist.

Meilenstein 7: Alle vorratigen Zukauf- und Einzelteile, Baugruppen und fertige Pro­dukte sind verkauft. Eventuell vorhandene Restbestande werden nach Freigabe ver- schrottet.

4 Beschreibung der Lean Enablers

In der Literatur werden die Lean Enablers in dem Buch „Lean for Systems Enginee- ring“ detailliert beschrieben. Insgesamt gibt es 6 Prinzipien, die in weitere Varianten und Untervarianten unterteilt werden. Immer nach dem gleichen Aufbau werden in Tabellen die Eigenschaften genannt und beschrieben. Im folgenden werden die fur den hier fokussierten Prozess der Hardware-Entwicklung betrachtet und im Anhang D abschliefiend beschrieben.

4.1 Lean Prinzip 1: Wert

„In Bezug auf eine erfolgreiche Bewertung muss in der ersten Phase jeder Entwick- lung folgendes enthalten sein:

Umfassende, komplette, eindeutige und detaillierte Kenntnis des Nutzens durch den Kunden.

Nicht nur die herkommlichen Anforderungen sind ausreichend, sondern auch die Be- durfnisse, der gesamte Zusammenhang, die Arbeitsprozesse, die Bedeutung, die Kompatibilitat und Vertraglichkeit sind fur das Verstandnis des Kunden wichtig.

Viele Entwickler haben den Drang, diese Phase ohne einen stabilen Arbeitsablauf zu durchlaufen, was in der Regel mit unvollstandigen oder falschen Anforderungen en- det, so dass dem nachfolgenden Entwickler Verschwendung zugemutet wird. Die fol­genden Varianten definieren die notwendigen Rahmenbedingungen, um einen Mehr- wert, und zwar den Mehrwert des Kunden, in der Entwicklung durch einen gereiften und effektiven Prozess voranzutreiben in

- der kompletten Erfassung der Kundenaussagen,
- deren Weitergabe innerhalb des Entwicklungs-Teams,
- das Team auf das Ziel zu richten,
- den Kunden und andere notwendigen Stakeholder in den Prozess einzubinden und
- mit ausreichender Breite und Tiefe spatere Verschwendung zu vermeiden.“[28]

Im Folgenden werden die wichtigsten Varianten und Untervarianten kurz beschrieben und auf den Einsatz innerhalb des Hardware-Entwicklungs-Prozesses auf ihre Bedeu­tung untersucht und bewertet. Fur die weitere Prozess-Analyse und Risikobewertung sind dann ausschliefilich die relevanten Varianten bedeutsam.

Die Bewertung der einzelnen Varianten wurden beispielhaft vorgenommen, um weite- re MaBnahmen im Anschluss darstellen zu konnen.

„Variante 1.1 - Folge allen Praktiken zur Erfassung und Entwicklung von Anforde- rungen aus dem INCOSE Handbuch.

Die Lean Varianten sind ein Prozess, der es ermoglicht in die traditionelle Entwick­lung die Lean Erkenntnisse hinzuzufugen. Wichtig ist es die entsprechenden Anforde- rungen in die etablierten Entwicklungsprozesse aufzunehmen und weiterzuentwi- ckeln.“[29]

„Variante 1.2 - Richte den Wert des Endproduktes oder Systems auf den Kunden auf

Diese Varianten definieren, welche Aktivitaten die Wertschopfungskette ausmachen und welche nicht. Der Fokus hierbei liegt allein darin, was der Kunde (extern oder intern) an Mehrwert definiert und was nicht.“[30]

„Untervariante 1.2.4 - Entwickle einen agilen Prozess, um sich andernde Kundenan- forderungen vorherzusehen, einzubeziehen und zu kommunizieren.

Die Erfullung des zugesicherten Auftrages bzw. Produktes, eine fixe Kostenplanung und Zeitplanung sind vorhanden. Liegezeiten und Nacharbeiten werden eliminiert.“[31]

„Untervariante 1.2.5 - Ignoriere keine potenziellen Konflikte mit den Interessen ande- rer Stakeholder und versuche einen Konsens zu finden.

Ein durchgehender Bearbeitungsfluss ohne Unterbrechungen, Wiederholungen und Nacharbeit ist moglich. Nacharbeit, Uberregulierung, Ist-Aufnahmen, Beforderungen und Wartezeiten werden eliminiert.“[32]

„Variante 1.3 - Beziehe den Kunden regelmaBig mit ein

Diese Variante betrachtet zwei kritische Punkte fur eine erfolgreiche Entwicklung: Die Grundgedanken des Kunden auf die Mitarbeiter zu ubertragen und den Kunden in den gesamten Entwicklungsprozess mit einzubinden. Diese Vorgehensweise reduziert Konflikte und Krisen. Eine bessere Kommunikationsbasis zwischen dem Entwickler- team und dem Kunden sorgen fur ein besseres Endergebnis fur den Kunden und ein Konsens wird fruher gefunden.“[33] „Untervariante 1.3.1 - Jeder, der am Programm mitarbeitet, muss eine klare Kun- denorientierung besitzen.

Die Mitarbeiter orientieren sich am Kundenwert. Fur die Stakeholder bedeutet dies weniger Frustration. Alle Arten von Verschwendung werden eliminiert. Im Allgemei- nen werden Konflikte und Krisen reduziert.“[34]

„Untervariante 1.3.2 - Schaffe regelmaBige und effektive Interaktionen mit internen und externen Kunden.

Eine gute Auffassung und ein gleichbleibendes Verstandnis der Entwicklungspramis- sen erhohen den Wert des Produktes. Die Fahigkeit die Anforderungen zu verstehen und die Bedurfnisse umzusetzen finden ohne Zeitverzogerung und Nacharbeiten statt. Vor allem Wartezeiten und Nacharbeiten werden eliminiert. Aber auch alle anderen Kategorien von Verschwendung inklusive Entwicklungsfehler.“[35]

„Untervariante 1.3.3 - Verfolge eine Architektur, die die Kundenanforderungen ein- deutig erfasst und sich an Anderungen anpasst.

Eine dynamische und ubertragbare Architektur sorgt fur eine sofortige Optimierung einer klaren Kundenvorstellung und der gesamten Entwicklung. Gleichzeitig werden Wartezeiten und eine nicht ausreichende Umsetzung der Anforderungen eliminiert.“[36]

4.2 Lean Prinzip 2: Wertstrom abbilden

„Das zweite Prinzip „den Wertstrom abbilden [...]“ setzt bei der Entwicklungsplanung an. Dieses Prinzip beinhaltet beide formellen Wertstrom-Aktivitaten, die formelle Planung der Tatigkeiten: die zugeschnittenen und terminierten Arbeitsschritte, die Stakeholder zu vernetzen und regelmaBig zu involvieren, Checklisten vorzubereiten, die Kommunikations- und Koordinierungs-Tools zu planen bis hin zur Darstellung einer Gesamtplanung.

Eine nachlassige Vorbereitung und Planung verursacht haufig mogliche Verschwen­dung. Um dies zu eliminieren werden hier Prinzipien vorgestellt, die eine hervorra- gende Programmvorbereitung [...] und Programmplanung [...] ermoglichen, inklusive:

- einer umfassenden Zeitplanung.

- Checklisten fur die Planung der einzelnen durchgefuhrten Entwicklungstatig- keiten ohne Verschwendung.

[...]


[1] Vgl. Lean Management, Pocket Power (2010a)

[2] Vgl. Lean Management, Pocket Power (2010b)

[3] Vgl. Lean Management, Pocket Power (2010c)

[4] Angelehnt an: Die Zeit (2013)

[5] Vgl. Krcmar, Helmut (2005)

[6] Angelehnt an: Bundesministerium des Inneren (2014)

[7] Vgl. Bundesamt fur Sicherheit in der Informationstechnik (2014a)

[8] Vgl. ITIL Service Design (2008b)

[9] Vgl. DIN-Taschenbuch 474, IT-Management (2012)

[10] Vgl. Kersten, Heinrich et. al. (2011a)

[11] Vgl. Seibold, Holger (2006a)

[12] Vgl. Seibold, Holger (2006d)

[13] Vgl. Gablers Wirtschaftslexikon (2015a)

[14] Angelehnt an: ISO (2013)

[15] Vgl. Seibold, Holger (2006a)

[16] Vgl. Seibold, Holger (2006b)

[17] Vgl. Seibold, Holger (2006c)

[18] Vgl. Seibold, Holger (2006d)

[19] Vgl. Gabler Wirtschaftslexikon (2015b)

[20] Angelehnt an: Kersten, Heinrich et. al. (2011b)

[21] Vgl. Gabler Wirtschaftslexikon (2015c)

[22] Vgl. Kersten, Heinrich et. al. (2011c)

[23] Vgl. Kersten, Heinrich et. al. (2011d)

[24] Vgl. Kersten, Heinrich et. al. (2011e)

[25] Vgl. Kersten, Heinrich et. al. (2011f)

[26] Vgl. Kersten, Heinrich et. al. (2011g)

[27] Vgl. Kersten, Heinrich et. al. (2011h)

[28] Angelehnt an: Oppenheim, Bohdan W. (2011a)

[29] Angelehnt an: Oppenheim, Bohdan W. (2011b)

[30] Angelehnt an: Oppenheim, Bohdan W. (2011c)

[31] Angelehnt an: Oppenheim, Bohdan W. (2011f)

[32] Angelehnt an: Oppenheim, Bohdan W. (2011g)

[33] Angelehnt an: Oppenheim, Bohdan W. (2011i)

[34] Angelehnt an: Oppenheim, Bohdan W. (2011j)

[35] Angelehnt an: Oppenheim, Bohdan W. (2011k)

[36] Angelehnt an: Oppenheim, Bohdan W. (2011l)

Ende der Leseprobe aus 140 Seiten

Details

Titel
Einführung eines Risikomanagements. Bewertung der Lean Management Prinzipien für die Produktentwicklung nach der Untersuchung auf Informationssicherheit
Hochschule
Technische Hochschule Köln, ehem. Fachhochschule Köln  (Fakultät 10)
Note
1,5
Autor
Jahr
2015
Seiten
140
Katalognummer
V311624
ISBN (eBook)
9783668161757
ISBN (Buch)
9783668161764
Dateigröße
3521 KB
Sprache
Deutsch
Schlagworte
Risikomanagement, Lean Management, ISO 27001, BSI IT-Grundschutz, Informationssicherheit, IT-Sicherheit, Lean Enabler
Arbeit zitieren
Verena Lang (Autor:in), 2015, Einführung eines Risikomanagements. Bewertung der Lean Management Prinzipien für die Produktentwicklung nach der Untersuchung auf Informationssicherheit, München, GRIN Verlag, https://www.grin.com/document/311624

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Einführung eines Risikomanagements. Bewertung der Lean Management Prinzipien für die Produktentwicklung nach der Untersuchung auf Informationssicherheit



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden