Vous êtes sur la page 1sur 15

js29.06.

2011

((1)) Projektrisikomanagement und der Einfluss in der Life-Science-Industrie


((Vorspann)) Risikomanagement ist eine kritischer Erfolgsfaktor in jederjedem Projekt. DerDieser Beitrag beschreibt wie Risiken erkannt, gemindert und kommuniziert werdenknnen. Weiterhin wird dargestellt, wie Risikomanagement in der Life-Science-Industrie verwendet werden kann um den notwendigenwird, der Test-Aufwand fr Anwendungen festzulegen.bei Life-Science Anwendungen zu fokussier ((Vorspann Ende)) ((Kasten)) In diesem Beitrag erfahren Sie, - was Projektmanagement auszeichnet, - was Projektrisiken von Produktrisiken unterscheidet, - welche Bedeutung das Risikomanagement in der Life -Science-Industrie hat und - wie die Risikoanalyse helfen kann, den Testaufwand zu reduzieren. ((Kasten Ende)) ((Autoren)) JAMES GREENE, PMP, ARCONDIS AG, REINACH, SCHWEIZ STEFAN ADAMOVSKY, ARCONDIS GMBH, ESCHBORN , DEUTSCHLAND
Comment [MSOffice2]: Bitte im Artikel berprfen, ob ich die berschriftenhierarchien richtig zugeordnet ha be. Comment [MSOffice1]: Bitte fgen Sie hier noch einen Vorspann mit max. 300 Zeichen ein.

((2))Was ist Risiko?


Ein Risikoist definiert als ein wahrscheinliches zuknftiges Ereignis, das im Eintrittsfall Auswirkungen auf Ihr Unternehmen, Projekt oder ein Produkt hat, das aus Ihrem Projekt entsteht. Sehen wir uns zunchst das Wort wahrscheinlich an. Im Deutschen impliziert wahrscheinlich etwas, das aller Voraussicht nach eintreten wird. In der obigen Definition bedeutet wahrscheinlich aber lediglich, dass dieses Ereignis mit einem gewissen Grad an Wahrscheinlichkeit eintreten knnte. Die Frage Ist es mglich,dass ein Ereignis stattfindet? kann mit Ja oder Nein beantwortet werden; die Wahrscheinlichkeitwird dagegen in Prozent angegeben. Die Spanne reicht von e inem Prozent (hchst unwahrscheinlich, aber dennoch mglich) bis 99 Prozent (hchst wahrscheinlich, aber nicht sicher). Im Eintrittsfall hat ein Ereignis Auswirkungen auf Ihr Projekt oder Produkt. Wennein Ereignis keine Auswirkungen hat, dann stellt es kein Risiko dar.

Das Wort Auswirkung (ebenso das Wort Risiko ) wird hufig als negative Auswirkung interpretier. Im t Risikomanagement mssen aber sowohl Auswirkungen als auch Risiko als Konzepte mit entweder negativem oder positivem Potenzial gesehen werden. Stellen wir uns beispielsweise folgende Situation vor: Sie hren, dass die Unternehmensleitung das Produ kt-Portfolio berprft, da die Ressourcen auf die wichtigsten Projekte konzentriert werden sollen. Es besteht daher ein Risiko, dass Ihr Projekt eingestellt wird (eine negative Auswirkung). Wenn Ihr Projekt andererseits weitergefhrt wird, stehen Ihnen vermutlich zustzliche Ressourcen zur Verfgung, die von anderen eingestellten Projekten abgezogen werden knnen (eine positive Auswirkung fr Ihr Projekt).

((2))Risikomanagement
Wie kann man Unsicherheit managen? Wenn es mglich wre, eine Situation vollst dig zu n kontrollieren, wrde daraus kein Risiko entstehen. Risikomanagement bezieht sich deshalb auf: die systematische Identifizierung, Beurteilung, Priorisierung undDokumentation von Risiken, die Planung einer entsprechenden Reaktion auf jedes Risiko , die berwachung und berprfung des Umfelds, um festzustellen, ob ein Risiko eingetreten ist , ggf. Manahmen, um die negativen Auswirkungen zu reduzieren oder die positiven Auswirkungen zu maximieren.

Die meisten Methoden zur Risikoanalyse (auf diese werden wir im weiteren Verlauf des Artikels noch eingehen) beurteilen Risiken in drei Dimensionen. Zwei davon haben wir bereits erwhnt: Auswirkung und Wahrscheinlichkeit. Die dritte Dimension ist genauso wichtig:Feststellbarkeit. Wenn es schwierig oder gar unmglich ist, das Eintreten eines bestimmten Ereignissesfestzustellen, muss diesem Risikotyp hhere Prioritt gegeben werden als einem hnlichen Risiko (hinsichtlich Auswirkungen und Wahrscheinlichkeit), das sofort entdeckt wird. Nehmen wir eine Baustelle als Beispiel: Der Bauleiter muss mit drei mglichen Fehlern (Risiken) bei der Mischung von Beton rechnen. In allen drei Fllen hat der Bauleiter die Auswirkung und die Wahrscheinlichkeit gleich hoch bewertet.Die Risiken unterscheiden sich nur durch die Feststellbarkeit: Fehler 1 kann sofort erkannt werden, sodass diese Charge sofort entsorg werden kann. Fehler 2 t wird erst sichtbar, wenn der Beton getrocknet ist. Fehler 3 dagegen kann nicht festgestellt werden, bis der Beton unter Belastung versagtRisseentwickelt oder sogar zerreit(evtl. erst Monate oder Jahre spter). In diesem Beispiel wrde Fehler 3 die hchste Risiko-Prioritt erhalten, weil die Feststellbarkeit kaum vorhanden ist. Aufwendige vorbeugende Manahmen mssten getroffen werden, um zu verhindern, dass eine solche Fehlmischung verwendet werden kann. Fehler 2 wrdeebenfalls mit einer hohen Risiko-Prioritt bewertet. In diesem Fall muss der Bauleiter entscheiden ob vorbeugende Manahmen , (auf jeden Fall etwas hhere Kosten und Aufwand) oderKorrekturmanahmen (sehr hohe Kosten und Aufwand, falls dieses Risiko eintritt) vorgenommen werden. Da Fehler 1 dagegen sofort erkannt werden kann, knnen vorbeugenden Manahmen schnell in die Bauprozesse integriert werden. Dadurch ergibtsich dafr die geringste Risiko-Prioritt aller drei Risiken.

Comment [MSOffice3]: Was passiert dann genau? Brckelt oder bricht er?
Formatted: German (Germany)

((23)) Risikomanagement bei Projekten, Produkten und Unternehmen


Ein Projektmanager muss alle Risiken erkennen die den Lebenszyklus des Projekts betreffen: u. a. , Umfang, Zeitplan, Budget, Personal, Qualittsanforderungen, Vertrge, Einkauf, Kommunikation und das Zusammenspiel all dieser Faktoren. Gleichzeitig muss das Projektteam regelmig seine Projektleistungen (Arbeitsergebnisse) analysieren und nach Risiken suchen, die die Qualitt des Produkts beeintrchtigen oder dem Verbraucher des Produkts Schaden zufgen knnten. Auerdem gibt es Risiken, die Auswirkungen auf die Organisation haben knnen. Diese Unternehmensrisiken werden in der Richtlinie ISO 31000:2009 behandelt, einer internationalen Norm mit dem Namen Riskmanagement: Guidelines on principlesandimplementationofriskmanagement(Risikomanagement Grundstze und Leitlinien).Die Richtlinie stellt fest, dass Organisationen sich einer Vielzahl von Risiken gegenbersehen, die das Erreichen ihrer Ziele beeintrchtigen knnen. [ ] Alle Aktivitten einer Organisation sind mit Risiken verbunden. Risikomanagement untersttzt die Entscheidungsfindung, indem Un sicherheiten und ihre Auswirkungen auf das Erreichen von Zielen bercksichtigt werden und beurteilt wird, ob in diesem Zusammenhang Handlungsbedarf besteht. [1] ISO 31000:2009 beschreibt ein generisches Modell eines Risikomanagementsystems fr Unternehmen . Wie viele andere ISO-Managementsysteme ist auch die ISO 31000 eine Umsetzung des von Dr. W. Edwards Deming geprgten PDCA-Zyklus (Plan-Do-Check-Act, dt. Planen-Durchfhren-berprfenAgieren) [2].Unternehmen werden angehalten, einen Rahmen fr das Risiko management zu implementieren: Erstellen eines Rahmens fr das Risikomanagement(Plan) Implementieren des Risikomanagements (Do) berwachen und berprfen des Rahmens (Check) kontinuierliche Verbesserung des Rahmens (Act)
Abb. 1: ISO 31000, Modell zum Risikomanagement

Der Schritt Do , Implementieren des Risikomanagements, ist ein zyklischer Prozess. Folgende Bedingungen sind hierbei gegeben: Der Risikokontext ist definiert (es gibt interne und externe Risikoquellen) . Die Risiken sind identifiziert, analysiert und evaluiert. Manahmen zur Bewltigung (Minderung) fr jedes Risiko sind definiert . Die Umgebung wird berwacht, um festzustellen, ob die Risikoereignisse eingetreten sind und , um neue Risiken zu erkennen.

Risikokommunikation und Beratung laufen gleichzeitig und liefern finden gleichzeitig statt, sodass fr in jedemn Verfahrensschritt ein Beitrag vorliegtmit neue Information und Erkenntnisse.

Comment [MSOffice4]: Was ist denn hier mit Beitrag gemeint?

((23)) Risikomanagement in der Life-Science-Industrie


Unternehmen aus der Life-Science-Industrie (u. a.Nahrungsmittel, arzneilich wirksame Bestandteile, pharmazeutische Produkte) haben sich mit ganz spezifischen Herausforderungen zur Behandlung von Produktrisiken auseinanderzusetzen. Im Gesundheitswesen und der Life-Science-Industrie kann ein unerwartetes Ereignis zur Verletzung oder Krankheit und sogar zum Tod eines Patienten fhren. Das gilt auch fr andere groe Industriezweige, beispielsweise in der Luftfahrt oder Automobilindustrie. Die spezifische Herau sforderung im Gesundheitswesen und der Life-Science-Industrie liegt in der Natur der Produkte: Whrend ein Flugzeug oder Kraftfahrzeug vor der Lieferung an den Kunden getestet wird (jede Komponente wird gem einem streng definierten Qualittssystem hergestellt und kann getestet oder berarbeitet werden), ist es unmglich zu testen, ob eine bestimmte Tablette oder Injektion zum Zeitpunkt der Lieferung an den Patienten genau die richtige Menge des aktiven Inhaltsstoffes enthlt, frei von Verunreinigungen und steril ist. Dementsprechend gilt der Leitsatz, jede Prozess und System welche einen Einfluss auf das Produkt hat (und indirekt dann auf der Gesundheit des Konsument bzw. Patienten), muss nachweisen dass es die Einsatztauglichkeit (Englisch Fitness for use ) des Produkts nicht negativ beeintrchtigt. Dementsprechend gilt, dass fr jeden Prozess und jedes System mit Einfluss auf das Produkt(und damit auch auf die Gesundheit des Konsumenten bzw. Patienten) achgewiesen werden muss, dass die n Einsatztauglichkeit (Englisch: Fitness foruse ) des Produkts nicht negativ beeintrchtigt wird. Im Gesundheitswesen und der Life-Science-Industrie in Europa mssen dieRichtlinien fr Medizinprodukte in der Europischen Union. Band 4 Gute Herstellungspraxis Medizinprodukte fr Human- und Tierarzneimittel[3] erfllt werden. Annex 11: Computergesttzte Systeme definiert die Regelungen fr computergesttzte Systeme, die im Herstellungsprozess fr Medikamente verwendet werden, und beginnt mit folgendem Absatz: 1. Risikomanagement Risikomanagement ist ber den gesamten Lebenszyklus des computergesttzten Systems durchzufhren, wobei Patientensicherheit, Datenintegritt und Produktqualitt zu bercksichtigen sind. Im Rahmen eines Risikomanagementsystems sollten Entscheidung ber en das Ausma der Validierung und Kontrolle der Datenintegritt auf der Grundlage einer begrndeten und dokumentierten Risikobewertung des computergesttzten Systems getroffen werden. Zu einem computergesttzten System zhlt in diesem Kontext jede Kombination aus Hardware, Firmware, Software und Netzwerkkomponenten inklusive derverifizierten Funktionsweise und der entsprechenden Dokumentation.[4] Sowohl Annex 11 als auch der ISPE-Leitfaden GAMP 5 (GAMP 5: Ein risikobasierter Ansatz fr konforme GxP-computergesttzte Systeme) untersttzen einen risikobasierten Ansatz um nachzuweisen, dass dieder . Um den erforderlichen Aufwand zur Erreichung der Einsatztauglichkeit eines computergesttzten Systems festzustellen, wird der risikobasierte Ansatz in folgenden Bereichen genutztbestehtgewhrleistet ist:

Comment [MSOffice5]: Was soll hier festgestellt werden? Die Einsatztauglichkeit? Oder ob sich der Aufwand rechtfertigt? Verstehe den Satz nicht ganz

in Kliniken, in Laboren sowie bei der Herstellung und Verteilung von Nahrungsmitteln, Arzneimitteln oder Medizingerten .

Das Projektteam muss, theoretisch gesehen, nachweisen dass jedes Projektergebnis absolut Fehler- und Einwandfrei ist. Realistisch betrachtet ist kein Produkt zu 100% fehlerfrei. Der risikobasierteAnsatz dient dazu, eine hohe Qualitt und Zuverlssigkeit nachzuweisen,und zwar dort, wo es am wichtigsten ist: inbei den die Funktionen und Prozessschritten die der einene Einfluss auf demdas Produkt (und indirekt dann auf der Gesundheit des Konsument)haben knnen. Fr Projektmanager in diesen Branchen bedeutet dieses Risikomanagement natrlich eine groe Belastung. Gutes Projekt-Risikomanagement (unabhngig davon, in welcherBranche) beinhaltet folgende Aktivitten: Planen, wie das Risiko im speziellen Projekt behandelt wird. Plne sollten Aufgaben fr dasRisikomanagement, Verantwortlichkeiten, Aktivitten und Budget enthalten. Benennen eines Projektrisikobeauftragten, also eines Teammitglieds Dieser ist verantwortlich . fr das Management der Projektrisiken, das Erstellen und Pflegen des Projektrisikoregisters und der jeweiligen Kommunikationskanle, sodass jedes Teamm itglied Risiken melden kann, die es im Projekt vorhersieht. Vorbereiten von Plnen zur Risikominderung mit einer Beschreibung, wie jedes Risiko behandelt wird (proaktivgemindert, reaktiv gemindert oder einfach akzeptiert). Berichten geplanter und aufgetretener Risiken, Wirksamkeit der Manahmen zur Minderung und Reaktion, auerdem Aufwand des Risikomanagements.

Comment [MSOffice6]: Bitte ein Stzchen dazu, warum.

Comment [MSOffice7]: Sind das zwei verschiedene Behandlungsmglichkeiten? (Ich komme darauf weil im nchsten Punkt Minderung und Reaktion getrennt steht.

Normalerweise versteht man unter Projektrisiken Ereignisse, die sich auf die Projektplne auswirken, d. h. ein Ereignis, das sich auf Umfang, Zeitplan, Budget, Qualitt usw. des Projekts auswirkt. Selbst wenn ein katastrophales Ereignis eintritt und zum Abbruch des Projekts fhrt, kann dies zwar den Gewinn des Unternehmens beeintrchtigen, es ist aber keine Sache von Leben und Tod. In vielen Industriezweigen muss der Projektmanager im Rahmen der Entwicklung eines neuen Produkts auch eine Produktrisikoanalyse liefern. Eine Produktrisikoanalyse, hufig in Form einer FMEA (Fehler Mglichkeits- und Einflussanalyse), beurteilt, welche Risiken ein neuesProdukt fr den Kunden oder Verbraucher des Produkts mit sich bringen knnte. In traditionellen Fertigungsindustrien, z.B. der Luftfahrt oder Automobilbranche, kann die Produktrisikoanalyse Hunderte oder gar Tausende von mglichen Ereignissen auflisten. Jedes dieser Ereignisse wird beschrieben,inklusive einer Analyse der Auswirkung auf den Verbraucher, der Wahrscheinlichkeit des Eintretens und der Entdeckbarkeit des Eintrittsfalls. Die Analyse der Entwurfs- und Herstellungsrisiken ist eines der wichtigsten Projektergebnisse und muss auf jeden Fall in den Projektplnen bercksichtigt werden. Wie im Beispiel der Baustelle oben beschrieben, mssen die mglichen Feh bei der Betonmischung ler jeweils evaluiert werden und in Bezug auf die Auswirkung, Wahrscheinlichkeit und Entdeckbarkeit bzw. Feststellbarkeit bewertet werden. Im Beispiel wrden die Auswirkung und Wahrscheinlichkeit bei allen

drei Fllen gleich hoch bewertet. Die drei Flle unterscheiden sich lediglich durch die Entdeckbarkeit des Fehlers. Eine detaillierte FMEA-Analyse evaluiert die Kosten des Fehlereintritts inklusive der Kosten fr die Behebung des Fehlers. Die Kosten, um diesen Fehler zu verhindern (vorbeugende Manahmen) werden ebenfalls ermittelt, um daraus die effektivste Vorgehensweise selektieren zu knnen.

((2)) Risiken erkennen


Wie kann ein Projektrisikomanager alle potenziellen Risiken fr das Projekt und das Produkt feststellen? Zuerst einmal: Es gibt kein Wundermittel, mit dem alle Risiken sichtbar gemacht werden knnen.Mit wachsender Erfahrung wird es einfacher, die mit einem bestimmten Projekt/Produkt verbundenen Risiken festzustellen. Somit ist es am besten, einen erfahrenen Projektmanager in das Projekt einzubinden entweder als Berater oder als Mentor.Bei Projekten lsst sich auch gut aus der Vergangenheit lernen: In einer Organisation mit groer Erfahrung im Projektmanagement drften bereits viele Dokumente vergangener Projekte vorliegen, u. a. ein Projektrisikomanagementplan, Risikoregister, LessonsLearned sowie Dokumente zur Projektzusammenfassung. Im Fall einer Produktrisikoanalyse ist es blich, die Unterlagen von hnlichen Produkten bzw. Vorgngerprodukten zu analysieren und die allgemein blichen Sicherheitstests der Branche durchzufhren (z. B. Crashtest fr Fahrzeuge, Zertifizierungsprfungen fr Spielwaren oder Sicherheitsausrstung etc.). Selbst wenn es keine Quelle mit Erfahrungswerten gibt, wenn das Projekt in einer komplettneuen Umgebung eingefhrt wird oder das Produkt nicht einem Zertifizierungsverfahren unterliegt, gibt es Methoden, mit denen der Risikomanager und sein Projektteam mgliche Risiken erkennen knnen. Eine beliebte Methode beschreibt Edward De Bono in seinemBuch Das Sechsfarbendenken[5], wobei jeder Teilnehmer je nach der Hutfarbe, die er erhlt, eine bestimmte Rolle bernimmt. Es handelt sich um einenRollenspielansatz, der das Thema aus verschiedenen Perspektiven beleuchtet: y Weier Hut(Fakten und Informationen): Das Projekt bzw. Produkt wird aus der objektiven, tatsachenbasierten Perspektive beurteilt. Roter Hut (Gefhle und Emotionen): Das Projekt bzw. Produkt wird aus der emotionalen Perspektive beurteilt; Risiken werden aus dem Bauch heraus identifizier . t Schwarzer Hut (kritisches Urteil): Der schwarze Hut steht fr den Advocatus Diaboli , der die Situation unter der Annahme beurteilt, dass alles, was schiefgehen kann, auch schiefgehenwird. Gelber Hut (positives Urteil):Mi demgelben Hut betrachtet man die gesamte Situation mit der rosa Brille und sucht nach den mglichen Ereignissen, die fr das Projekt oder Produkt von Vorteil sein knnten. Grner Hut (Alternativen und Kreativitt):Mit demgrnen Hut schaut man ber den Tellerrand hinaus und denkt auf der Suche nach kreativen, alternativen Anstzen um die Ecke . Dieser Hut

ist besonders ntzlich bei der Entwicklung von Minderungslsungen zur Minimierung der Auswirkungen und/oder Wahrscheinlichkeit eines Risikos . y Blauer Hut (das groe Ganze): Man achtet auf das groe Ganze und sieht das Projekt bzw. Produkt aus 10 km Entfernung.

Die Methode des Sechsfarbendenkens bringt durch strukturiertes Brainstorming hufig weitere Perspektiven ins Spiel. Natrlich knnen Projekt- und Produktrisiken auch mit anderen Methoden (z.B. dem herkmmlichen Brainstorming im Team oder einerMindmap fr das individuelle Brainstorming erkannt und analysiert werden.

((2))Methoden der Risikoanalyse


Das Identifizieren und Erfassen von Ereignissen, die Auswirkungen auf Ihr Unterfangen haben, ist mit Sicherheit der wichtigste Schritt im Risikomanagement. Ein Risiko, das nicht identifiziert wurde, kann auch nicht behandelt werden. Aber es reicht nicht, die Risiken zu kennen: Sie mssen analyiert werden s und anschlieend muss ein Plan zum Risikomanagement entwickelt werden. Die Zrich Versicherung hat dazu eine Risikoanalysemethode entwickelt, die sogenannteZurichHazard Analysis(ZHA)[6]. In der ZHA wird jedes Risiko (oder jede mgliche Gefahr ) im Gefahrenkatalog aufgefhrt, zusammen mit den Ereignissen, die die Gefahr auslsen knnten, undden Auswirkungen im Eintrittsfall. Wahrscheinlichkeit und Schweregrad jeder Gefahr werden eingeschtzt und wiein Abb. 2 bewertet.
Abb. 2: ZHA-Bewertung

Diese beiden Dimensionen werden wie Abb. 3 zeigt, aufgezeichnet. Es wird eine Risikotoleranzgrenze , definiert und in das Diagramm eingetragen; dies stellt die Risikoscheu des jeweiligen Unternehmens e dar. Alle Gefahren ber dieser Grenze mssen gemindert werden (siehe Abb. 3, Risiko 1, 2 und 5). Jede dieser nicht vertretbaren Gefahren wird in einen Risikoverbesserungskatalog aufgenommen, ebenso die Korrekturmanahmen, die ergriffen werden, um die Wahrscheinlichkeit des Eintrttsfalls zu i verringern.

Abb. 3: ZHA-Risikoprofil

In einer Projektumgebung haben Projektsponsor und Projektmanager im Rahmen des Risikomanagementplans normalerweise zwei Risikoschwellen definiert: Risiken unterhalb einer ersten Schwelle ( niedrige Risiken ) werden ganz einfach akzeptiert; es werden keine Minderungsmanahmen geplant. Risiken ber der ersten Schwelle, aber unterhalb einer zweiten Schwelle ( mittlere Risiken ) mssen berwacht werden; im Eintrittsfall greift ein Manahmenplan zur Korrektur.Risiken ber der zweiten Schwelle ( hohe Risiken ) knnen beispielsweise vor der berwachung und Meldung eine aktive Korrekturmanahme erfordern.

Wie oben erwhnt, ist dieser zweidimensionale Ansatz fr eine Versicherungsgesellschaft adquat, da das Eintreten eines Ereignisses leicht zu erkennen ist. In der Life -Science-Industrie ist das eher selten der Fall. Man kann unmglich sagenfeststellen, ob eine bestimmte Tablette die richtige Menge Dosis des aktiven Inhaltsstoffs enthlt, ohne sie zu zerstren. Aus diesem Grund empfiehlt die ISPE(International Society forPharmaceutical Engineering) im GAMPLeitfaden eine dreidimensionale Risikoanalyse[4]. Die Risikoanalyse des GAMP-Leitfadens konzentriert sich auf die Auswirkungen auf Patientensicherheit, Pro duktqualitt und Datenintegritt (oder anderen Schaden) . Die GAMP-Risikoanalysemethode verwendet lediglich die Stufenniedrig, mittel oder hochzur Einschtzung von Auswirkung und Wahrscheinlichkeit. Diese beiden Faktoren definieren einen Risikokategorienwert. Dieser Wert wird dann mit dem Entdeckbarkeitsfaktor kombiniert und ergibt die endgltige Risikoprioritt, wie Abb. 4 zeigt.

Comment [MSOffice8]: Vielleicht ein anderes Beispiel whlen, da es oben schon verwendet wurde?

Abb. 4: GAMP-Risikoanalyse

Die GAMP-Methode wird oft fr Software-Entwicklungsprojekte in der Life-Science-Industrie verwendet, um das Risiko einer individuellen Funktion in einem Computersystem einzuschtzen. Die Risikoprioritt definiert den Umfang von Tests und Verifizierungen, die in diese bestimmte Funktion investiert werden sollten. Fr ein komplexes Produkt mit Hunderten oder Tausenden von Komponenten, z. B. ein Auto oder ein Flugzeug, stt die GAMP-Methode sehr bald an ihre Grenzen, da sie zuundifferenziertist. In diesem Modell gibt es lediglich drei mgliche Risikoprioritten(hoch, mittel oder niedrig). Hersteller komplexer Systeme brauchen jedoch mehr Detailgenauigkeit, damit die Prioritten fr eine Gruppe von Risiken und die Effektivitt ihrer Minderungsplne bestimmt werden knnen. In diesen Industriezweigen wird daher gemeinhin die FMEA (FehlerMglichkeits- und Einflussanalyse) [7] eingesetzt. In der FMEA-Methodologie werden Wahrscheinlichkeit und Auswirkung (aus der Sicht des Verbrauchers) auf einer Skala von 1 (sehr unwahrscheinlch) bis 10 (hchstwahrscheinlich) beurteilt. Die i Entdeckbarkeit des Eintrittsfalls wird von 1 (hchstentdeckbar) bis 10 (fast nicht entdeckbar) bewertet. Diese drei Werte werden miteinander multipliziert und ergeben eine Risikopriorittszahl (RPZ) zwische n 1 (kaum wahrscheinlich, minimale Auswirkung und sofort entdeckbar) und 1 .000 (hchstwahrscheinlich und kaum entdeckbar, mit katastrophalen Auswirkungen). Die FMEA-Analyse geht jedoch noch weiter, denn es werdenauerdem Korrektur- und Vorbeugemanahmen(CAPA: CorrectiveandPreventive Actions) zur Minderung des Risikos festgelegt. Wenn die Minderungsmanahmen definiert worden sind, wird das Risiko ein weiteres Mal analysiert, um zu sehen, wie dadurch die Risikopriorittszahl verndert wird. Dies ist deshalb ntig, weil sich viele Minderungsmanahmen nur auf eine oder zwei Dimensionen auswirken. Nehmen wir beispielsweise einen Landwirt, der Erdbeeren verkauft: Es besteht das Risiko, dass Dnger die Erdbeeren kontaminiert

und beim Verbraucher zu Magen-Darm-Problemen fhrt. Zur Minderung beschliet der Landwirt, die Erdbeeren vor dem Verpacken mit Wasser zu waschen. Diese Manahme verringert zwar die Wahrscheinlichkeit, dass der Verbraucher nach dem Verzehr einer verschmutzten Erdbeere erkrankt, aber nicht die Auswirkung, wenn es doch passiert, oder die Mglichkeit festzustellen, ob die Erdbeeren tatschlich verunreinigt waren. In diesem Beispiel wurde ein Risiko identifiziert (mgliche Kontamination), analysiert (Auswirkung = Erkrankung, Wahrscheinlichkeit > 25 %, Entdeckbarkeit niedrig), und eine vorbeugende Manahme definiert und umgesetzt (Waschen der Beeren vor dem Verpacken). Die revidierte Risikoanalyse wrde dieselbe Auswirkung (Erkrankung) und Entdeckbarkeit (immer noch niedrig, vielleicht sogar niedrigerals vorher) ergeben, aber die Wahrscheinlichkeit wurde erheblich reduziert (<1 %).

((2)) Risikobewltigung
Nach ISO 31000:2009 beinhaltet die Risikobewltigung die Wahl einer oder mehrerer Optionen zur Modifizierung der Risiken und die Implementierungdieser Optionen. Risikobewltigung involviert einen zyklischen Prozess Beurteilung der Risikobewltigung; Entscheidung, ob Restrisiken vertretbar sind oder nicht; Erstellen einer neuen Risikobewltigungsstrategie, wenn sie nicht vertretbar sind; und Beurteilung der Wirkung dieser Manahme. Dieser Prozess wird solange wiederholt, bis das verbliebene Restrisiko den Risikokriterien des Unternehmens entspricht. [1] Wie bereits erwhnt, legen viele Organisationen zwei Risikoschwellen fest und definieren die Risikoreaktionen entsprechend Risiken mit niedriger Prioritt werden einfach akzeptiert, Risiken mit mittlerer Prioritt werden evtl. berwacht (und es gibt einen Minderungsplan, der im Eintrittsfall greift), whrend Risiken mit hoher Prioritt aktiv gemindert werden. Mgliche Minderungsanstze sind beispielsweise:
y y y y y y
Comment [MSOffice9]: Was mir bei der folgenden Aufstellung nicht ganz klar ist: Inwiefern sind das Minderungsanstze, wenn zum Teil das Risiko ausgelst bzw. die Wahrscheinlichkeit des Eintritts erhht wird?

Vermeiden des Risikos: Eine Entscheidung, eine Aktivitt nicht zu beginnen bzw. nicht fortzufhren, die das Risiko auslsen knnte. Herbeifhren einer Gelegenheit: Eine Entscheidung, eine Aktivitt zu beginnen bzw. fortzufhren, die das Risiko vermutlich auslst oder vergrert. Beseitigen der Risikoquelle: Eine Manahme, um den Auslser zu eliminieren, sodass das Risiko nicht auftreten kann. ndern der Art und Grenordnung der Wahrscheinlichkeit: Eine Manahme, um die Wahrscheinlichkeit des Eintrittsfalls zu vergrern oder zu verringern. ndern der Konsequenzen: Eine Manahme, um die Auswirkungen des Ereignisses zu vergrern oder einzugrenzen. Teilen des Risikos mit anderen Parteien: Auslagern der Hochrisiko-Aktivitt an andere Organisationen oder Erwerb eines Versicherungsschutzes, um die Auswirkungen im Eintrittsfall zu begrenzen; und/oder Bewusste Entscheidung zur Beibehaltung des Risikos: Akzeptieren, dass die Aktivitt ein gewisses Risiko in sich birgt.

Diese Minderungsanstze schlieen einander nicht aus: Es ist blich, mehrere Manahmen zur Minderung eines Risikos zu ergreifen dennselbst dann bleibt oft noch ein Restrisikobestehen.

((2)) Risikokommunikation
Ein wichtiger (und hufig bersehener) Aspekt des Risikomanagements ist die Kommunikation. Besonders schwierig an der Kommunikation von Risiken ist es, der Zielgruppe jedes Risiko verstndlich darzustellen und die Beziehung zwischen verschiedenen Risiken zu veranschaulichen. Wenn Risiken innerhalb eines Projektteams besprochen werden, in dem jeder den gleichen Kenntnisstand zu den Eigenheiten des Projekts oder Produkts hat, werden die Risiken normalerweise in ein Risikoregister aufgenommen. Dies kann in Form eines Arbeitsblatt s oder einer einfachen Datenbank e auf einer Website fr das Team geschehen.

((3)) Bow-Tie-Diagramme
Wenn Risiken fr einen greren Personenkreis mit begrenztem Verstndnis der Projektziele oder Produktfunktionen dargestellt werden sollen, lsst sich das Ri iko zusammen mit den mglichen s Ursachen und Auswirkungen des Ereignisses mithilfe eines Bow -Tie-Diagramms (wrtlich: Fliege (Kleidungsstck)) veranschaulichen. Ein Bow-Tie-Diagramm entsteht durch Definition der folgenden Parameter: 1. 2. 3. 4. Ereignis, das verhindert oder verfolgt werden soll Bedrohungen oder Manahmen, die das Ereignis verursachen knnten Konsequenzen oder Vorteile des Eintrittsfalls Kontrollmechanismen zur nderung der Wahrscheinlichkeitoder Feststellbarkeit des Eintrittsfalls 5. Kontrollmechanismen zur Minderung oder Intensivierung der Auswirkungen des Ereignisses
Abb. 5: Struktur eines Bow-Tie-Diagramms

Der Eigentmer eines Kleinunternehmens knnte zum Beispiel erkennen, dass der Ausfall eines entscheidenden Gerts mglicherweise ernste Auswirkungen auf die Produktivitt seiner Angestellten hat. Das Risiko kann wie folgt dargestellt werden:
Abb. 6: Bow-Tie-Diagramm Ausfall der Kaffeemaschine

((2)) Risikobasierter Testansatz


Zum Abschluss dieser Errterung des Risikomanagements mchten wi aufzeigen, wie man sich mithilfe r des Risikomanagements beim Testen von Computer -Software auf das Wesentliche konzentriert und somit den erforderlichen Aufwand reduziert.

In der Life-Science-Industrie muss jedes computergesttzte System validiert werden, das zur Erfassung, Verarbeitung oder Speicherung von klinischen, Labor Herstellungs- oder Sicherheitsdaten verwendet -, wird, damit sicher ist, dass es fr den vorgesehenen Verwendungszweck geeignet ist und die aktuellen gesetzlichen Anforderungen erfllt. Diese Validierungsanforderung wird hufig alsNotwendigkeiteines 100%igen Tests interpretiert. Mit der Verffentlichung des GAMP-5-Leitfadens [4] im Jahr 2008 hat die ISPE gezeigt, dass Risikomanagement der Schlssel zur Definition des Testaufwands fr com putergesttzte Systeme ist. Wenn ein Life-Science-Unternehmen ein neues Computersystem implementiert, ist eine der ersten Projektaktivitten ein High-Level Risk Assessment (HLRA). Das HLRA bestimmt, ob das Computersystem einer gesetzlichen Regelberwachung unterliegt oder nicht. Wenn das System als nicht relevant beurteilt wird, sind (aus gesetzlicher Sicht) keine weiteren Schritte zur Validierung und Regelberwachung erforderlich. Wenn das Computersystem als GxP-relevant beurteilt wird (GxP ist eine allgemeine Bezeichnung fr Gute Praxis -Qualittsrichtlinien und -Bestimmungen), muss der Projektmanager verschiedene zustzliche Dokumentationsschritte im Lebenszyklus des Projekts einplanen. Zu diesen Dokumenten gehren u. a. der Validierungsplan (zu Beginn des Projekts erstellt, beschreibt Produktspezifikation und Aktivitten zur Verifizierung) und ein Validierungsbericht (am Ende des Projekts erstellt, beschreibt Produktprfverfahren und aufgetretene Abweichungen). Zwar gewinnen agile Entwicklungsmethoden im Bereich der Life Sciences immer mehr an Beliebtheit, trotzdem arbeiten die meisten Systementwicklungsprojekte immer noch mit dem seit ber 20Jahren verwendeten V -Modell. Ein typisches GxP-relevantes Systementwicklungsmodell sehen Sie in Abbildung 7.

Abb. 7: V-Modell

Ein Schlsselelement in diesem Modell ist das Element Risikoanalyse & Nachverfolgbarkeit in der Mitte der Abbildung. Auf der Spezifikationsseite beginnt das Projekt mit der Erfassung von Benutze und rGeschftsanforderungen an das neue Computersystem. DieseBenutzeranforderungen werden dann analysiert und in funktionale Spezifikationen bersetzt, die im System implementiert werden sollten. Diese wiederum werden im technischen Design oder Konfigurationsdokument genauer ausgefhrt,das als Richtlinie fr das Entwicklungsteam dient, das den tatschlichen Code erstellt. Im Idealfall wird jeder vom Programmierer erstellte Codeblock getestet undin die anderen Codeblocks integriert.Dann wird die gesamte Anwendung getestet. Die fertige Anwendung wirdanschlieendin einer produktionshnlichen Umgebung installiert und einer Reihe von Funktionstests unterzogen, mit denen verifiziert wird, dass jede in der Spezifikation beschriebene Funktion wie beschriebe umgesetzt wurde. n Schlielich testen einige Benutzer, obdie Anwendung die zu Projektbeginn formulierten Anforderungen

erfllt. Nach erfolgreichem Abschluss dieser Tests werden die Testergebnisse und alle Abweichungen im Validierungsbericht erfasst, der die Anwendung offiziell zur Verwendung freigibt. In der Realitt ist es jedoch so, dass bereits eine mig komplexe Anwendung Hunderte von Modulen enthalten kann, dazu Hunderte von Funktionen, die als Teil des Basissystems vorhanden sind, aber nicht zur Durchfhrung der GxP-relevanten Funktionen oder zur Verarbeitung bentigt werden. Eine Prfung aller dieser Funktionen wre unerschwinglich und wrde die Qualitt der Software nicht verbessern. An diesem Punkt kommen Risikobewertungen ins Spiel. Jede im Anfo rderungsdokument beschriebene Benutzeranforderung wird beurteilt im Hinblick auf die GxP -Relevanz und auf die potenzielle Auswirkung auf den ordnungsgemen Betrieb der Anwendung (z.B. die korrekte Verarbeitung von Daten), wenn die Anforderung nicht richtig umgesetzt wird oder nicht funktioniert. Eine Anforderung, die keine Auswirkungen hat, muss nicht unbedingt getestet werden. Dieser Prozess wird fr die in der Funktionsspezifikation aufgefhrten Funktionen und die in der fr Design- oder Konfigurationsspezifikation beschriebenen Module wiederholt.Nur diejenigen Spezifikationen werden intensiv getestet, die eine Auswirkung auf die Fhigkeit der Anwendung haben knnten, die Benutzeranforderungen zu erfllen. Andere Funktionen knnen getestet werden (viel e werden stillschweigend im Rahmen des Prfverfahrens getestet), die Testanforderungen sind jedoch viel niedriger. Gleichzeitig dienen diese detaillierten Risikoanalyse protokolle als Dokumentation fr die Nachverfolgbarkeit:Denn sie zeichnen die Beziehung einer bestimmten Benutzeranforderung zu einer bestimmten Funktion auf, die diese Anforderung erfllt, und von dort zu einem bestimmten Konfigurationselement oder Codemodul, das diese Funktion umsetzt. Gleichzeitig werden auch horizontale Beziehungen zwischen den vorgegebenen Anforderungen und dem Testfall bzw. Testverfahren zur Verifizierung der korrekten Umsetzung dokumentiert. Diese Nachverfolgungsmatrix ist spter im Produktlebenszyklus bei der Analyse des Risikos und der Auswirkungen einer gewnschten nderung von unschtzbarem Wert. Wenn beispielsweise eine Kundenanforderung gendert wurde und dies in einer neuen Version der Anwendung implementiert werden soll, zeigt die Nachverfolgungsmatrix, welche Funktionen und Codemod von dieser nderung ule betroffen sind und welche Testflle bzw. Testverfahren aktualisiert und/oder erneut ausgefhrt werden mssen.

Zusammenfassung
In diesem Artikel haben wir gezeigt, dass Risikomanagement auf jeder Stufe eines Unternehmens eine entscheidende Aktivitt ist. Projektrisiken, also jene Ereignisse, die sich auf die pnktliche, budgettreue und qualittskonforme Lieferung der Projektergebnisse auswirken knnen, sind nur ein Aspekt des Risikomanagements in Organisationen. Produktrisiken, die si h auf die Herstellung und Lieferung eines c Produkts auswirken knnen, mssen ebenso behandelt werden wie Risiken, die sich auf den Verbraucher auswirken knnen. Schlielich gibt es noch Geschftsrisiken, die das Fortfhren der Geschftsttigkeit eines Unternehmens beeintrchtigen knnen.

Comment [MSOffice10]: Streichen? Davon war im Artikel nicht ausfhrlich die Rede.

Alle diese Risiken mssen identifiziert, erfasst und analysiert werden .Daraufhin mssen geeignete RisikobewltigungsplnePlneentwickelt, berwacht und in einem fortlaufenden Zyklus kommuniziert werden. Wir haben verschiedene Methoden zur Identifizierung, Erfassung und Priorisierung von Risiken aufgezeigt, sowie Methoden zur grafischen Darstellung und Vermittlung von Risiken. Im Life-Science-Bereich ist Risikomanagement ein wesentlicher Bestandteil des n euesten GoodAutomated Manufacturing Practices Guide (GAMP 5), der mit einer detaillierten Analyse jeder Anforderung und Funktion eines computergesttzten Systems hilft, den Aufwand fr Prfung und Verifizierung auf die wichtigsten Bestandteile des Systems zu konzentrieren.

Comment [MSOffice11]: Zur Ausschaltung/Minimierung von Risiken?

Comment [MSOffice12]: Die Autorenvita fehlt noch

Literaturverzeichnis
[1] ISO International Organization for Standardization.Risk management Principles and guidelines on implementation. s. l.: ISO International Organization for Standardization, 2008. ISO 31000:2009. [2] Wikipedia Community. PDCA. Wikipedia.http://en.wikipedia.org/w/index.php?title=PDCA&oldid=427807898 (letzter Zugriff: 9.5.2011).

Comment [MSOffice13]: Bitte Angaben noch einmal auf Vollstndigkeit prfen und ggf. ergnzen.
Formatted: English (U.S.)

F r att d: English (U.S.)

C nt [MSOffic 14]: Heit das, dass der Verlag nicht bekannt ist?
F r att d: English (U.S.)

F r att d: German (Germany) F r att d: German (Germany) F r att d: English (U.S.) F r att d: English (U.S.)

F r att d: Font: 14 pt, German (Switzerland)

F r att d: Heading 1, Left

James Greene, PMP

Arcondis AG, Reinach, Schweiz Herr Greene ist als Diplom-Informatiker in verschiedenen Funktionen in der pharmazeutischen und Life Science Industrie seit 1990 ttig. Heute ist er Manager fr Computer System Validation bei der Arcondis AG in Reinach, Schweiz. Die Arcondis Gruppe ist ein Beratungs-Unternehmen fr die Life Science Branche und bietet hochwertige und anwendungsorientierte Dienstleistungen fr IT Qualitts- und -, Informationsmanagement an. Herr Greene ist als Projektleiter (PMP) undebenfalls Qualittsmanagement-Beauftragter (TV-QMB) zertifiziert. Zwischen 2001 und 2009 war er Verwaltungsratsmitglied beim der PMI (Project Management Institute) Switzerland Chapter und ist, seit

('

ber die Autoren

F r att d: German (Switzerland)

&

#""!



[9] US Food and Drug Administration. Part 820 Quality System Regulation. Code of Federal Regulations.21 Bde.,Silver Spring, MD, USA: US Department of Health and Human Serviceshier:Bd. 8., 2010.



[8] Brhwiler, Dr. Bruno;Romeike, Frank. Praxisleitfaden Risikomanagement.Berlin: Erich Schmidt, 2010.

nt [MSOffic 16]: Verlag und Ort?





[7] Failure Mode and Effects Analysis. 2006. DIN EN 60812.Analysetechniken fr die Funktionsfhigkeit von Systemen - Verfahren fr die Fehlzustandsart- und -auswirkungsanalyse (FMEA) (IEC 60812:2006); Deutsche Fassung EN 60812:2006. Berlin: Beuth Verlag, 2006.

nt [MSOffic 15]: Verlag und Ort?

[6] Zurich Insurance Company. Risk Topics The Zurich Hazard Analysis. Zurich Financial Services Ltd.December 1998. https://www.search.zurich.com/rep/d/gho/attachments/attachments_risktopics/rt_ch_19981101_en_c h-8_the_zurich_hazard_analysis.pdf (letzter Zugriff: 21.5.2011).

F r att d: English (U.S.)

[5] De Bono, Edward. Six Thinking Hats.s. l.: Back Bay Books, 1985.

F r att d: English (U.S.)

[4] ISPE. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems. s. l. Tampa, Florida, USA: ISPE, 2008.

%$ ('

[3] European Commission Health and Consumers Directorate-General. Medicinal Products for Human and Veterinary Use. Volume 4 - Good Manufacturing Practice.Brssel: European Commissions. n., 2010.

1996,Chefredakteur der Fachzeitschrift PM@CH The Swiss Project Management Review, welche 2-mal im Jahr erscheint.

Stefan Adamovsky

Arcondis GmbH, Eschborn, Deutschland Herr Adamovsky hat nach Studienaufenthalten an der Dualen HochschuleBaden-Wrttemberg Lrrach und der University ofCalifornia Santa Barbara einen Bachelor of Sciencein Wirtschaftsinformatik erworben. Bevor er 2009 in die internationale Life Science Beratung wechselte beschftigte er sich mit IT Management Themen. So war erunter anderem in IT Value Management, Business Process Management und IT Service Management Projekte eingebunden.Heuteuntersttzt Stefan Adamovsky als Consultant fr Computer System Validierung das Bro der Arcondis GmbH in Frankfurt-Eschborn. Als zertifizierter Computervalidierungsbeauftragterist er dabei schwerpunktmig in Compliance Management Projekten ttig. Herr Adamovsky ist ein Teilnehmer des MBA Programms an der University of Louisville (Kentucky, USA).

F r att d: German (Switzerland) F r att d: German (Switzerland) F r att d: German (Switzerland)

F r att d: German (Switzerland)

F r att d: Font: 11 pt, German (Switzerland) F r att d: Left

2 2 2 2 2 2

10 10 10 10 10 10