Risikomanangement in der Entwicklung

1
Berner Fachhochschule
Weiterbildung
MEDICAL TECHNOLOGY CENTER
Risikomanagement in F&E
Mario Klessascheck

2
Weiterbildung / MEDICAL TECHNOLOGY CENTER
Mario Klessascheck
Dipl. Ing. ET (TU), MAS Wing
Managing Partner
Experte, R&D und Innovation

3
Ziele für den Kurs
1. Sie kennen die Systematik hinter dem Thema und
verstehen die Zusammenhänge
2. Sie kennen die Gestaltungselemente und
Handlungsfelder
3. Sie können die Gestaltungselemente nennen und die
Risikostrategie nennen

4
Themen
1. Systematik Risikomanagement in F&E –
Kernelemente
2. Gestaltungsmerkmale und Methoden
3. Praktische Übung zum Thema Usability
Gestaltung:
Theorie, Showcases, Gruppenarbeit

5
Systematik
Risikomanagement in der Entwicklung

6

7

8
Kernelemente Risikomanagement
6 Handlungsfelder:
• Management
• Entwicklungsprozess (Drehscheibe)
• Methoden- und Vorgehensmodelle
• Richtlinien, Normen, Gesetze
• Entwicklungstools
• Aktivitäten in der Entwicklung

9

10
Corporate Footprint
• Vor allem wertorientierte Risiken
• Management und normative Ebene sind die Basis
• Management verantwortlich für das Risikomanagement
• Management muss:
Mitarbeiter befähigen/ausbilden
Infrastruktur zur Verfügung stellen
Ressourcen managen
Wissensmanagement fördern

11
Kognitive Ebene
• Vor allem wertorientierte Risiken
• Gestaltet das Lernen: Wissensgenerierung,
Wissensverarbeitung, Wissenserhalt
• Beinhaltet kreative Prozesse des Problemlösens
• Benötigt Kultur und Kommunikation (Management)
• Risikomanagement
• Methoden und Tools für Fehlervermeidung und
Entwicklung
• Schlüssel Ressourcen

12
Handlungsebene
• Wissen anwenden
• Complaint orientierte Risiken (technische Normen)
• Wichtigsten Risiken sind bekannt
• Setzt Wissen und Handlungskompetenz voraus
(Ausbildung)

13

14
Kreisprozess
• Management Thema
• Kontinuierliches Lernen auf allen Stufen
• Systematischer Wissenserhalt für neue Projekte
• Forderung von Norm ISO 13485
• Gestaltung individuell für jede Firma (abhängig von
Strategie und Zielen)

15

16
Anwendung Challenge Map
• Analyse und Visualisierung der Situation
• Markieren von Hotspots und Epizentren
• Risikoaspekte für eigene Situation beurteilen und
Abhängigkeiten zeigen
• Visuelle Entscheidungsgrundlage, schnell, nachvollziehbar
und verständlich

18
Quelle Christina Johner Institut

19
Systematik der Normen und Richtlinien

20
Risikomanagement Prozess EN ISO 14971

21
Normen und Richtlinien
• Produktnormen:
technische Normen mit Spezifikationen bezogen auf die
Sicherheit des Patienten und Anwenders,
Bsp. IEC 60601-1-2 EMV
• Prozessnormen:
Normen, die explizit Prozesse fordern und die Anforderungen an
den Prozess festlegen, Bsp. IEC 62304 SW
• Richtlinien:
Verbindliche Handlungsvorschriften
Werden von EU verordnet und müssen in nationales Recht
umgewandelt werden, Bsp. MDD und HMG,MPG

23
Beispiel: Entwicklungsprozess in der Medizintechnik

24
Gestaltungsmerkmale
• Phasen:
Ablaufgestaltung - organisiert den Prozess in verschiedene
strukturierte Abschnitte mit klar definierten Inhalten, Aktivitäten
und Resultaten
• Iterationen:
Schrittweiser Weg vom Problem zu Lösung (Risikozentriert)
• Begleitprozesse:
Unterstützen den Hauptprozess und übernehmen spezifische
Teile des Risikomanagements

25
Begleitprozesse
• Sind Gestaltungselemente die explizit in den Normen wie 62304,
14971 und der Richtlinie MDD gefordert werden.
• Die interne Ausgestaltung wird nicht vorgeschrieben. Verlangt
werden folgenden Aktivitäten:
KM – Konfigurationsmanagement:
• Dokumentiert und verwaltet die verschiedenen Produktversionen
über den gesamten Lebenslauf des Produktes.
• Stellt die Rückverfolgbarkeit der Anforderungen und
Designentscheide sicher.
PM – Projektmanagement:
• Erstellt den Projektplan und kontrolliert alle Aktivitäten während
der Entwicklungszeit.
• Budgetiert und plant die Iterationen

26
Begleitprozesse
QS - Kontinuierliche Qualitätssicherung:
• Die QM Abteilung muss die Resultate der Entwicklungsaktivitäten
überwachen und deren Konformität sicherstellen
• Ist verantwortlich für das Release Management und muss die
Vollständigkeit und Widerspruchsfreiheit der Dokumentation
prüfen
• Führt das Technical File/Device Master Record
SM - Safety Management:
• Verantwortlich für die Durchführung der Risikoanalyse und der
Dokumentation des Prozesses
• Muss die Wirksamkeit der Massnahmen überprüfen und
dokumentieren

27
Begleitprozesse
RM - Requirement Management:
• Grundvoraussetzung für erfolgreiche Projekte
• Erheben, Dokumentieren und Verwalten aller
Anforderungen, Änderungsmanagement führen
SI - System Integration and verification:
• Stellt sicher, dass separat entwickelte Module (intern, extern) der
Spezifikation entsprechen und im Systemkontext fehlerfrei
funktionieren.
• Muss zur Qualitätssicherung eine geeignete Verification Strategy
erarbeiten

29
Vorgehensmodelle
• Vorgehensmodelle strukturieren den Prozess in verschieden
Abschnitte mit klar definierten Aktivitäten und Resultaten
• Sind Schablonen die verschieden Ansätze und Strategien in
Bezug auf Risikomanagement und Steuerbarkeit eines Projektes
verfolgen
Etablierte Modelle:
• V-Modell
• Wasserfall
• Spiralmodell
• RUP
• Agile
• Prototyping

30
Kernanforderungen an den R&D-Prozess:
• Muss: das systematische Erkennen von Fehlern und Risiken
ermöglichen (Problemlösung)
• Muss: Ursachenanalyse ermöglichen und die Definition
geeigneter Massnahmen fordern, (CAPA, KVP)
• Muss: Erkenntnisse für weitere Projekte verfügbar und
anwendbar machen (IKM)
• Soll: Hauptprozess unterstützt verschiedene Vorgehensmodelle
in Abhängigkeit vom Produkt
• Soll: Verschiedene Entwicklungsphasen mit klaren Inhalten und
Aktivitäten beinhalten
• Muss: Verzahnung mit der übrigen Prozesslandschaft im
Unternehmen über eindeutig definierte Schnittstellen
• Muss: Kontinuierliche Performencemessung mit Massnahmen
ermöglichen (PDCA)

31
Iterationen
• Iteratives Vorgehen ist die Schrittweise Entwicklung des
Produktes.
• Das Ergebnis einer Iteration ist ein Inkrement.

32
Iterationen
http://sce.uhcl.edu/helm/RationalUnifiedProcess/process/workflow/manageme/co_phase.htm

33
Wasserfall
Vorteile:
• In Bezug auf Risiko keine
• Effizient für kleine Projekte
Nachteile:
• Systemfehler werden zu spät
erkannt
• Wirksamkeit risikomindernder
Massnahmen sind schwer prüfbar
• Reaktion auf ändernde
Anforderungen

34
V-Modell
Vorteile:
• Berücksichtigt Testen auf allen
Stufen
• Internationaler Standard der
Aspekte eines Entw.Prozesse regelt
Nachteile:
• Keine in Bezug auf Risiko
• Komplex und sehr formal

35
Rational Unified Process RUP
Vorteile:
• Aufteilung des Projektes in Phasen
und Meilensteine
• Unterteilung der Phasen in
Iterationen für bessere
Beherrschbarkeit der Risiken
• Anwenderzentrierte Entwicklung
• Starke Toolunterstützung
Nachteile:
• Keine in Bezug auf
Risikomanagement
• Schwer und komplex, Change
Management, grosse Projekte

37
Wege für die systematische Problemlösung
Verschiedene Methoden, Herangehensweisen:
• Aufgabe strukturieren und analysieren: Ordnung
• Abstraktes Abbild eines Aspektes einer Wirklichkeit:
Modelle
• Einheitliche prosafreie Darstellungsformen: Sprachen
• Domänenspezifische Entwurfs- und Designmethoden
• Hilfsmittel für den Design- und Entwurfsprozess: Tools

38
Wege für die systematische Problemlösung
Sprachen
Modelle
Ordnung
Aufgabe strukturieren
Design & Entwurfs-
methoden
Tools

39
Kandinskys “Roter Fleck”

40
Ursus Wehrli

41
Paul Klee, Fatbtafel Qu I, 1930

42
Ursus Wehrli

43
Ordnungskriterien für Anforderungen
Realisation durch: SW, HW oder Konstruktion
Funktionale oder nichtfunktionale Anforderungen
Kritisch für Qualität, kritisch für Safety
Seinen eigenen Stapel organisieren:
Schwein gehabt, das ist einfach (geringes Risiko)
Uuups, was ist denn das? (Anforderungen konkretisieren)
Wau, na die sind ja mutig (hohes Risiko!)
Mist, wie soll ich das allein machen? (Machbarkeit prüfen)
Na wer braucht denn so was? (priorisieren, selektieren)

44
Wesen der Modelle aus Sicht Risiko
• Abstraktion des Systems zu Fachmodellen die einen
spezifischen Aspekt herausgreifen
• Zeigen schnell potentielle Gefährdungen oder kritische
Anforderungen aus der Fachsicht
• Schaffen schnell ein gemeinsames Verständnis
• Verifikation ob Anforderungen richtig verstanden wurden
• Am Modell lässt sich die Implementierung sehr gut
überprüfen
Beispiele:
Funktionsmodelle, Datenmodelle, Zustandsmodelle, Designmodelle,
etc.

45
Modell einer Systemarchitektur
MCF 5235,
150MHz, BUS 75 MHz
uP, ucLinux
POWER
5VDC
3.3VDC
1.5VDC
Batterie
Ethernet
WLAN
Bluetooth
Audio
LCD
Keyboard
SD-Card
SpO2
Temperatur
NIBP
Isoliert
EKG
Flash
SDRAM
RTC I2C
RS-232
Terminal int.
BDM
SPI
I2C
PCI
BUS
RS-232
RS-422
RS-232
ETPU
ETPU
RS-232
ETPU

46
Modellsprachen
• Sprachen helfen einen Sachverhalt präziser zu formulieren,
• Verhindern Missverständnisse durch reine Prosa
General purpose Sprachen:
• Allgemeine Sprachen mit einem generalistischem Ansatz,
zum Bsp. C, UML, SysML, Anforderungen (must, should,
shall)
Domain spezifische Sprachen:
• Domain spezifische Sprachen beziehen sich auf einen
ganz bestimmten Fachbereich zum Bsp.: HTML, VHDL,
SPS, etc.

47
Beispiel UML-Diagramme

48
Beispiele für Entwurfs- & Designmethoden
• Objekt Orientierte Entwicklung (SW),
• Entwurfsmuster (SW),
• Modellgetriebene Entwicklung (SW),
• Testgetriebene Entwicklung (SW),
• HW-SW-Codesign,
• Designmethoden (Bsp. ereignis- oder zeitgesteuert)
• Prototyping (SW, HW, GUI)
• Anforderungsanalyse und Spezifikationen

49
Bsp: Designmethode in der Konstruktion
Integrierter Prozess Modellieren (analog) mit CAD (digital)
vermischen:
• 3D Modell erstellen: Emotionen spüren, Haptik,
Arbeitsergonomie testen – geht nicht am CAD
• Clay Modell bauen (Fahrzeugbau)
• Lego  NXT  Development kit  von dort in eigentliche
Entwicklung überführen

50
Entwicklungswerkzeuge - Tools
Integrated development environment (IDE)
• Unterstützen den Entwurfsprozess,
• Visualisieren Modelle,
• Führen formale Überprüfungen der Modelle durch
• Generieren funktionsfähigen Output
Beispiel:
• CASE Tools für Softwareentwicklung (Bsp. Microsoft
Developer Studio),
• CAD Tools in der Konstruktion (Bsp. Solid Works),
• EDA Tools für Hardware Entwicklung (Bsp. Altium
Designer)

51
„I don’t think you can design anything just by absorbing
information and then hoping to synthesise it into a
solution“
„What you need to know about the problem only
becomes apparent as you’re trying to solve it.“
- MacCormac, 1976

52
Einführung in die Norm ISO 62366 - Usability

53
Medizintechnik vor ca. 50 Jahren
http://www.uphs.upenn.edu/paharc/collections/gallery/departments/ICU.html

54
Moderne Intensivstation
http://www.mh-hannover.de/auf_intensivstation.html

55
Herausforderungen für den Anwender Bsp. IPS
• Schnell Handeln im Alarmfall
• Informationsverarbeitung von mehr als 50 Informationen
gleichzeitig (Alarme, Patient, Geräte, Messwerte, etc.)
• Plausibilität der Informationen checken um Fehler zu
erkennen
• Muss-Zustand der Geräte erkennen
• Nicht nur Patient muss gepflegt werden
• Alarme (technisch, vital) unterschiedlich für alle Geräte
• Patient beobachten, pflegen und therapieren
• Blitzschnell Zusammenhänge im System erkennen und
Entscheidungen treffen
• Geräte unterschiedlicher Hersteller (Bedienung, Alarme,
Handling)
• Viele Patienten gleichzeitig

56
„Alles sollte so einfach wie möglich gemacht
werden, aber nicht einfacher“
Albert Einstein

57
EN ISO 9241 Teil 11
Benutzbarkeit ist...
„... das Ausmaß, in dem ein Produkt, System oder
ein Dienst durch bestimmte Benutzer in einem
bestimmten Anwendungskontext genutzt werden
kann, um bestimmte Ziele effektiv, effizient und
zufriedenstellend zu erreichen.“

58
„... das Ausmaß, in dem ein Produkt, System oder
ein Dienst durch bestimmte Benutzer in einem
bestimmten Anwendungskontext genutzt werden
kann, um bestimmte Ziele effektiv, effizient und
zufriedenstellend zu erreichen.“
EN ISO 9241 Teil 11

59
Auszug aus MDD, Annex I (Essential Requirements)
„... to reduce, as much as possible, the risk of use
error due to the ergonomic features of the device
and the environment in which the device is
intended to be used (design for patient safety).“
„... to consider the technical knowledge, experience,
education and training and, where applicable, the
medical and physical conditions of intended users
(design for lay, professional, disabled or other
users).“

60
Auszug aus MDD, Annex I (Essential Requirements)
„... to reduce, as much as possible, the risk of use
error due to the ergonomic features of the device
and the environment in which the device is
intended to be used (design for patient safety).“
„... to consider the technical knowledge, experience,
education and training and, where applicable, the
medical and physical conditions of intended users
(design for lay, professional, disabled or other
users).“

61
ISO 62366: Eingliederung in das Regelwerk

62

63
Usability Aspekte
Design In (Usability)
• Gebrauchstauglichkeit setzt den Anwender in die Lage mit
dem Gerät effizient und effektiv zu arbeiten.
• Safety - Verhindern potentieller Gefahren
Design out (Use Errors)
• Fehler beim Gebrauch, die nicht nur dem Anwender
zugesprochen werden
Beispiele:
• Anwender weis nicht in welchem Zustand das Gerät ist
• Unklare Fehlermeldungen vom Gerät
• Mangelndes Feedback während der Interkation
• Arbeitsprozesse werden durch das Interface nicht
abgebildet

64
Process flowchart: IEC/ISO 62366

65
pddukupalegjanuary2012presentationbypollyshelton-120131040921-phpapp01

66
Usabilitymethoden
• Den verschiedenen Aufgabenbereichen
(Anforderungen, Konzept, etc. siehe Prozess) im
Usabilityprozess können verschiedene Methoden
zugeordnet werden
• Beispiele:
(Storyboards, LoFi-
Prototypen, Styleguids, Szenarien, Wireframes, Kontextan
alyse, Feldtests, Mock-up, etc.)
• Alle Methoden stellen den Anwender in den Mittelpunkt -
User centered design (Vorgehen wird in der ISO 62366
explizit verlangt)

67
Anforderungen aus Sicht des Risikos erfassen

68

69
Quellen für risikogetriebene Anforderungen
• Bestimmungsgemässer Gebrauch (intended use)
• Potentielle Schäden und Gefährdung im Gebrauch
feststellen
• Mögliche Ursachen aus Design, Funktion, Gebrauch,
Fertigung und Entsorgung erarbeiten
• Marktrecherche zu meldepflichtigen Vorkommnissen
durchführen (Swissmedic, BfArM)
• Essential Requirements aus den Richtlinien MDD, IVDD
und AIMDD
Aller Erkenntnisse in der Risikoakte erfassen und im Safety
Concept geeignete Massnahmen festlegen.

70

71
Bestimmungsgemässer Gebrauch/intended use
Um die Anforderungen an das System zu formulieren, ist es
unbedingt notwendig den „intended use“ festzulegen:
Inhalt:
• In welcher Umgebung wird das Produkt eingesetzt?
• Wer sind typische Benutzer?
• Welche Risiken durch Fehlbedienung existieren?
• Technische Beschreibung des Gerätes
• Vorhersehbarer nicht bestimmungsgemässer Gebrauch

72
http://p4.focus.de/img/gen/g/d/HBgdCgry_Pxgen_r_Ax354.jpg

73
http://www.social-impress.com/data/imagecache/watermark/lachjetzt-not-macht-erfinderisch.jpg

Risikomanangement in der Entwicklung

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (12)

Similar to Risikomanangement in der Entwicklung

Similar to Risikomanangement in der Entwicklung (20)

Risikomanangement in der Entwicklung

Editor's Notes