Risikomanagement und Softwareentwicklung

Transkript

1 Risikomanagement und Softwareentwicklung Edmund-Gerhard Schrümpf EDconsult und FH der Wirtschaft CAMPUS02 Graz/Österreich Schlüsselworte: Risikomanagement, Softwareentwicklung, COSO, Kernrisiken Einleitung Bedingt durch die Wirtschaftsereignisse in letzter Zeit habe die meisten Unternehmen erkannt, dass Risikomanagement ein absolutes MUSS zum Überleben in der Krise ist. Sowohl Gesetze als auch Abschlussprüfer fordern eine entsprechende Risiko-Vorsorge. Oftmals werden die Risiken im Unternehmen ordentlich analysiert, bewertet und gut verwaltet. Besonders wird die IT durchleuchtet, stellt sie doch eine lebensnotwendige Infrastruktur im Unternehmen dar. Jede Komponente, jede Störungsmöglichkeit wird berücksichtigt. Dies ist eine notwendige, aber auch umfangreiche Arbeit. Allerdings zeigen die IT-Audits des Referenten, dass zwei Bereiche hier zu kurz kommen: Das Software-Projekt als Risikofaktor Die Risiken des Softwarebetriebes sind meist gut abgedeckt, aber jene direkt in Software- Projekten werden oftmals vernachlässigt. Hier gibt es einige Standardrisiken, die so alt sind wie die EDV und trotzdem immer wieder Projekte zum Scheitern bringen. Dies scheint an der Dynamik der Projekte zu liegen mit ihren temporären Organisationsformen. Risikovermeidung durch Softwaregestaltung Die Software ist ein Teil der Infrastruktur mittels der die Unternehmensprozesse abgewickelt werden. Dabei wird auf effizient gestaltete Abläufe Wert gelegt, besonders wenn sie dem häufigsten abzuwickelnden Normalfall entsprechen. Aber in der Sonderfallabwicklung stecken große Risiken, da diese selten völlig sauber implementiert sind. Ebenso ist der Beitrag der Software an den internen Kontrollen hoch, aber viel zu wenig systematisch. Der Beitrag zeigt für beide Problembereiche anhand von Beispielen die Risiken auf und empfiehlt Vorgehensmethoden, um diese zu reduzieren. 1 Das Software-Projekt als Risikofaktor Software Projekte können Auswirkungen auf das gesamte Unternehmen haben und bei einem umfangreichen Misserfolg dessen Existenz gefährden:

2 1.1 Einleitendes Beispiel Ein typisches Projekt zur Erstellung/Anpassung und Einführung von komplexen, betrieblichen Verwaltungssystemen aus der Praxis des Sachverständigen soll die realen Probleme aufzeigen. Die Größenordnungen lassen sich beliebig skalieren, ohne dass sich die Problematik verändert: Beispiel Neues ERP-System Es soll das gesamte ERP-System eines Unternehmens ersetzt werden. Die Schätzung des Anpassungsaufwandes für den pauschalierten Leistungsumfang lautete 1 Personenjahr (PJ) in 6 Kalendermonaten (KM) abzuwickeln. Diese war wesentlich zu niedrig angesetzt, da seit zwei Jahren der Fertigstellungsaufwand trotz laufender Arbeiten immer noch mit dem ursprünglichen Kennzahlen (1 PJ und 6 KM) gemeldet wird. Allerdings wurden in der Zwischenzeit schon 4 PJ geleistet. 1.2 Situation Die Lage sieht für beide Projektpartner Auftraggeber (AG) und Auftragnehmer (AN) ungünstig aus: AG: wartet seit 2 Jahren auf die Nutzung der neuen Software; den 4 PJ des AN stehen laufende Arbeitszeiten für Spezifikation, Rückfragen und Test bei AG gegenüber. AN: hat für einen Auftrag für 1 PJ und einen Gesamtaufwand von mindestens 5 PJ, davon 80% nicht verrechenbar. 1.3 Schrecken und Ende Für beide Partner wird dieses Projekt zum unternehmensweiten Risiko, sodass sich die Frage stellt, das Projekt weiterzuführen oder abzubrechen. Hierzu einige Argumente: Der AG benötigt die neu geplanten Unternehmensprozesse dringend um die Effizienz zu steigern. Wird das bisherige Projekt in absehbarer Zeit fertig gestellt, so wäre dies die beste Lösung. Allerdings ist unklar, ob der AN das Projekt finanziell überlebt bzw. in Zukunft die notwendige Servicequalität in der Wartung erbringen will und kann. Wird das Projekt abgebrochen, müsste der AG ein neues Projekt starten. Mit Ausschreibung, Partnerauswahl und neuem Durchlaufen der Projektphasen dauert dies ebenfalls mindestens 1 KJ. Finanziell ist kaum zu erwarten, dass der AN die bisherigen Zahlungen rückabwickeln kann. Daher ist der bisherige Aufwand frustriert (verloren) und es kommen die neuen Projektaufwendungen dazu. Der AN hat den unverrechenbaren Aufwand bereits investiert und den Ertrag daraus verloren. Der Verlust ist in Relation zum Eigenkapital bzw. zum Gewinn eines Durchschnittsjahres zu beurteilen.

3 Im laufenden Projekt besteht die Möglichkeit, die Zusatzleistungen zu verrechnen. Bringt der AN das Projekt gut zu Ende, hat er einen Wartungskunden mit komplex angepasster Software, die er bestens kennt und somit Erträge erwirtschaften kann. Das Projekt könnte abgebrochen werden. Dann wären alle Aufwendungen verloren und über den bereits abgerechneten Anteil sowie die Restzahlungen würde ein Streit ausbrechen. Statt einem guten Wartungskunden entsteht ein unzufriedener Ex-Kunde mit möglichen Folgewirkungen (Publicity, Rechtsstreit, Lizenz-Rückabwicklung, Schaden, ). Offensichtlich wäre die beste Lösung, das Projekt umgehend fertigzustellen und einen zufriedenen Kunden langfristig zu betreuen. 1.5 Die Kernrisiken im Software-Projekt Warum kommt es in Software-Projekten zu solchen Situationen? Diese Frage wurde in Rahmen von Forschungsarbeiten an der FH der Wirtschaft Campus02 in Diplomarbeiten untersucht und die aktuelle Literatur dazu aufgearbeitet. Diese Kernrisken sind nahezu bei allen Software-Projekten vorhanden, dies belegen viele empirische Untersuchungen. Diese Kernrisken sind auch in einem überwiegenden Ausmaß die Ursache für gescheiterte Projekte: Unklare bzw. sich laufend ändernde Projektziele und Anforderungen an die Software Nicht korrekter Zeitplan Hohe Mitarbeiterfluktuation im Projektteam Schwankende Leistungsfähigkeit der Mitarbeiter Mangelnde Unterstützung durch das Top-Management Organisatorische Änderungen im Projektumfeld Relevanz der betroffenen Geschäftsprozesse 2 Risikovermeidung durch Softwaregestaltung Es ist Aufgabe des Softwaredesigns, die Unternehmensprozesse möglichst robust abzubilden und deren Ordnungsmäßigkeit sicherzustellen. 2.1 Einleitende Beispiele Beispiel Materialwirtschaft In einem Industrieunternehmen wird die Materialwirtschaft mit einer Materialbuchhaltung und einem Produktionsplanungs- und steuerungssystem (PPS) abgewickelt. Die ca Materialien werden mengenmäßig zwar genau verwaltet, allerdings gibt es Probleme mit der als individuell dazu programmierten, gleitenden Durchschnittspreisermittlung. Wenn sich der Lagerstand dem Nullbestand nähert und zeitverschobene Buchungen erfolgen, entstehen unrealistische Preise. Durch unterschiedliche Beschaffung in Kleinmengen, Großmengen, als kostenloses Mustermaterial oder mittels teurer Eilbestellung schwanken die Einstandspreise der Rohmaterialien stark.

4 Die Preise sind vertraulich, daher werden die Durchschnittspreise nirgends in der Produktion angezeigt. Die Bewertung der erzeugten Produkte erfolgt genau nach Stückliste mit (unrichtigem) Durchschnittspreis. Die Erzeugungskosten sind durchgehend unsichtbar, die Überraschung kommt bei der Inventurbewertung. Da es in dem umkämpften Markt lebensnotwendig gewesen wäre, exakt zu kalkulieren, dies aber unter anderem dadurch unmöglich war, Beispiel Artikelsortiment Das jeweilige Artikelsortiment einer Filiale im Lebensmitteleinzelhandel wird durch Auswerten von bis zu 40 Artikel-, Filial- und zeitbezogenen Tabellen ermittelt. Es fehlen immer wieder Artikel-Datensätze in den Filialen, was zu Störungen des Geschäftsbetriebes führt (z.b. an der Kassa). Dies ist ein typisches Phänomen, da bei vielen Schnittstellen nicht überwacht wird, ob alle Datensätze übertragen worden sind. SQL-Joins neigen dazu, spurlos Datensätze zu verlieren, wenn irgendeine Bedingung im Join nicht erfüllt ist. Es ist daher unbedingt notwendig, mit einem zweiten, möglichst einfachen Statement Kennzahlen zu ermitteln, die dann zu Vollständigkeitsprüfung verwendet werden können. 2.2 Ursache: Idealannahme Es wird in der Entwicklung weitgehend vom Idealfall, vollständigen und korrekten Daten ausgegangen. Niemand rechnet z.b. mit den bei einer Datenqualitätserhebung für BASEL II gefundenen 5 bis 8 % inkonsistenten Kundendaten in einer Bank. Es ist in den Spezifikationen und im Softwaredesign darauf Rücksicht zu nehmen, dass Fehler auftreten. Robuste Software muss diese Fehler zumindest aufzeigen können. Besser wäre es noch, dem Anwender eine Behebung vorzuschlagen. Im obigen Beispiel Artikelsortiment wurde eine eigene Erklärungskomponente entwickelt, die dem Anwender verständlich aufzeigt, warum ein Artikel im Sortiment nicht berücksichtigt ist. Im konkreten Fall ist dies oft auf terminliche Intervall-Überlappungen und Terminlücken zurückzuführen, die durch unterschiedliche Zuständige gewartet werden. 3 Aktuelles Risikomanagement Einleitend bietet es sich an, die aktuellen Definitionen im modernen Risikomanagement darzustellen. Aktueller Anlass sind die in den Bilanzierungsrichtlinien geforderte Beurteilung und Darstellung der Risiken in Unternehmen. Es sollen hier zwei weltweit anerkannte Rahmenwerke als Grundlage für die weiteren Ausführungen dienen: COSO (Committee of Sponsoring Organizations of the Treadway Commission) hat 2004 das COSO ERM - Enterprise Risk Management Framework veröffentlicht, um das ursprünglich 1992 publizierte erste Modell zu erweitern. Es wird daher als zweites Modell COSO II

5 genannt. Darin werden die Definitionen und Handlungsanleitungen für ein unternehmensweites Risikomanagement dargestellt ( Auf COSO II baut ein weiteres Rahmenwerk für die Auditierung der betrieblichen Informationsverarbeitung auf, CobiT (Control Objectives for Information and Related Technology). Es wurde 1993 vom internationalen Verband der IT-Prüfer (Information Systems Audit and Control Association, ISACA) erstmals herausgegeben und ist das international anerkannte Framework zur IT-Governance. Seit 2000 betreut die Weiterentwicklung des Rahmenwerks das IT Governance Institute, wobei unlängst die Version 4.1 herausgegeben wurde ( Definition von Enterprise Risk Management Enterprise Risk Management behandelt Risiken und Chancen zur Schaffung und Erhaltung von Unternehmenswert. Es wird wie folgt definiert: Enterprise Risk Management ist ein Prozess, ausgeführt durch Überwachungs- und Leitungsorgane, Führungskräfte und Mitarbeiter einer Organisation. angewandt bei der Strategiefestlegung und innerhalb der Gesamtorganisation, gestaltet um die Organisation beeinflussende mögliche Ereignisse zu erkennen und um hinreichende Sicherheit bezüglich des Erreichens der Ziele der Organisation zu gewährleisten. Diese Definition umfasst somit folgende wesentliche Elemente. Enterprise Risk Management Ist ein Prozess, der fortlaufend ausgeführt wird und sich über die gesamte Organisation erstreckt Wird ausgeführt durch Mitarbeiter auf allen Hierarchiestufen Wird angewendet bei der Festlegung der Strategie Wird angewendet in allen Teilen des Unternehmens, in allen Ebenen und Einheiten und betrachtet das organisationsweite Risikoportfolio Ist gestaltet um mögliche Ereignisse zu identifizieren, die Einfluss auf die Organisation haben und die Risiken so zu steuern, dass sie innerhalb der Risikobereitschaft der Organisation liegen Ist in der Lage, hinreichende Sicherheit für die Unternehmensleitung und das Überwachungsorgan des Unternehmens zu gewähren Ist auf die Zielerreichung in einer oder mehreren getrennten, sich aber überschneidenden, Kategorien ausgerichtet - es ist ein Werkzeug zur Erreichung eines Ziels, nicht ein Ziel als solches. 3.1 Was ist eigentlich Risiko? Die folgenden Definitionen entstammen COSO II und beziehen sich auf die unternehmensweite Risikosicht:

6 Definition Ereignis: Ein Ereignis ist eine Begebenheit oder ein Vorfall mit internen oder externen Auslösern, welches die Zielerreichung beeinflusst. Ereignisse können negativen Einfluss, positiven Einfluss, oder beides haben. Ereignisse mit negativer Auswirkung stellen Risiken dar, solche mit positiven Auswirkungen Chancen. Definition Risiko: Risiko ist die Möglichkeit, dass ein Ereignis mit negativen Auswirkungen auf die Zielerreichung eintritt. Demzufolge ist Risiko die Wahrscheinlichkeit des Auftretens eines Ereignisses. Man unterscheidet davon die möglichen Auswirkungen. 3.2 Der Weg zum Risikomanagement COSO II enthält ein praxisorientiertes Vorgehensmodell, um mit 8 Komponenten ein Risikomanangement einzuführen und zu betreiben. Im sog. COSO-Würfel stellt diese die erste Dimension dar und deckt den Zyklus von (1) Umfeld bis (8) Überwachung ab. Die Zielkategorien von strategisch bis zur Konformität stellen die zweite Dimension dar und die hierarchischen Ebenen die dritte Dimension.

7 4 Sechs Schritte zum Risikomanagement Betrachtet man die 8 Komponenten des COSO II, so sind die ersten beiden Rahmenbedingungen, die unternehmensweit festzulegen sind: 1. Internes Umfeld für die Risikobasierte Unternehmensführung 2. Zielvorgabe unter Unsicherheit für strategische, operative, Reporting- und Konformitäts-Ziele Die weiteren Komponenten 3 bis 8 nach COSO beziehen sich auf diese Grundlage. Um dafür einen praxiserprobten Ansatz anzubieten, werden für die operativen Tätigkeiten 6 Prozesse vorgestellt. Übergeordnete Sicherungsmaßnahmen, das Berichtswesen und die unternehmensweite Überwachung sind darin nur rudimentär abgedeckt und müssen gesondert regelt werden.

8 Die sechs Prozesse 1. Risikomanagementplanung 2. Risikoidentifikation 3. Qualitative Risikoanalyse 4. Quantitative Risikoanalyse 5. Risikobewältigungsplanung 6. Risikoüberwachung und steuerung Prozess 1: Risikomanagementplanung Es ist eine klare und eindeutige Struktur die Voraussetzung für transparente und den standardisierte Beurteilung der Risiken: Einheitliche Vorgehensmethode für alle Projekte, differenziert nach Schwerpunkten Organisatorische Festlegung der Rollen und Verantwortlichkeiten Budgetierung stellt Ressourcen des Risikomanagements sicher Zeitliche Planung der Risikoprozesse während des Projektlebenszyklus Gliederung in R-Kategorien /R-Wahrscheinlichkeiten /R-Auswirkungen Im Risikostrukturplan (Risk Breakdown Structure, RBS) werden die Risikokategorien und Unterkategorien dargestellt. Risikowahrscheinlichkeit Relative Skalierung mit Wahrscheinlichkeitswerten von sehr unwahrscheinlich bis fast sicher oder Absolute Skalierung mit Werten von 0,1 bis 0,9 Risikoauswirkung Die Auswirkungsskala reflektiert die Bedeutung von Auswirkungen auf jedes Projektziel Relative Skalierung für Auswirkungen mit gestaffelten Beschreibungen wie sehr niedrig, niedrig, mäßig, hoch und sehr hoch oder Numerische Skalierung mit linearen Werten (z. B. 0,1, 0,3, 0,5, 0,7, 0,9) Nichtlineare Skalierung (z. B. 0,05, 0,1, 0,2, 0,4, 0,8) wird eingesetzt, um Bedrohungen mit großen Auswirkungen zu vermeiden Prozess 2: Risikoidentifikation Die Risikoidentifikation bestimmt, welche Risiken das Projekt beeinflussen können, und dokumentiert deren Eigenschaften. Die Risikoidentifikation läuft als iterativer Prozess, der in den einzelnen Phasen des Projektes die spezifischen Risiken aufdecken soll. Ausgangsbasis dazu ist der Risikostrukturplan. Es kommen unterschiedliche Identifikationsmethoden zum Einsatz. Im Risikoregister werden die identifizierten Risiken katalogisiert.

9 Der Risikostrukturplan (RBS) stellt die generelle Checkliste dar, die unterschiedlich gegliedert ist, um alle Risiko-Aspekte abzudecken. Es wird zwischen den "Kernrisiken" bei SW-Entwicklungsprojekten, analytischen Risiken und empirischen Risiken unterscheiden. Eine weitere Gliederung ist nach der primären Umgebung und Verantwortlichkeit nach Auftraggeber, Auftragnehmer und Durchführung sinnvoll. Das Risikoregister katalogisiert die identifizierten Risiken und Maßnahmen im konkreten Projekt. Im Sinne der "lernenden Organisation" oder TQM fließen neue Erkenntnisse als Aktualisierung der Risikokategorien wieder in die Vorgaben ein. Das Risikoregister enthält die Liste identifizierter Risiken, die Liste der möglichen Bewältigungsmaßnahmen, die Grundursachen von Risiken und die aktualisierten Risikokategorien. Zum Beispiel hier Risiken beim Auftraggeber (AG) AG.1) Umfeld Gesetzeslage Geschäftsusancen Politische Situation AG.2) Bonität des AG AG.3) Durchsetzbarkeit von Vertragsbedingungen Gerichtsstand Währungsrisiko Schätzrisiko... andere AG.4) Steigende Anforderungen an die Software AG.5) Abänderung der Projektziele AG.6) KernR: Hohe Relevanz der betroffenen Geschäftsprozesse AG.7) KernR: Organisatorische Änderungen im Projektumfeld Prozess 3: Qualitative Risikoanalyse Die qualitative Risikoanalyse beinhaltet Methoden zur Priorisierung der identifizierten Risiken für weitere Maßnahmen wie die quantitative Risikoanalyse und die Risikobewältigungsplanung Die Risikowahrscheinlichkeit stellt das Auftreten des jeweiligen spezifischen Ereignisses dar. Die Risikoauswirkung bildet die potenzielle Auswirkung auf ein Projektziel wie z. B. Zeit, Kosten, Inhalt und Umfang oder Qualität ab. Die Wahrscheinlichkeit und Auswirkung sind für jedes identifizierte Risiko zu bewerten. Prozess 4: Quantitative Risikoanalyse Die quantitative Risikoanalyse wird für die prioritären Risiken durchgeführt, da sie das Projekt beeinflussen.

10 Die im Risikoregister enthaltenen, wichtigsten Risiken werden numerisch bewertet. Dafür sind die Eintrittswahrscheinlichkeit und Auswirkung zu ermitteln. Es können verschiedene Szenarien (optimistisch und pessimistisch) durch Befragung, Simulation und empirische Ermittlungen festgelegt werden. Prozess 5: Risikobewältigungsplanung Die Risikobewältigungsplanung das Entwickeln von Strategien und Festlegen von Maßnahmen, die die Bedrohungen verringern. Die Methoden zur Risikobewältigung sind Vermeidung, Vermindern, Teilen bzw. Übertragen oder Akzeptieren. Prozess 6: Risikoüberwachung und -steuerung Die laufende Risikoüberwachung und -steuerung beschäftigt sich sowohl mit der Verfolgung von identifizierten Risiken, als auch mit dem Identifizieren neuer Risiken. Neueinstufung von Risiken Risikoaudits Abweichungs- und Trendanalyse Überwachung von Metriken und Indikatoren Analyse der Reserven Statusberichte/Besprechungen Stop/Go - Entscheidungen treffen Für angepasste Risikostrukturpläne, weiterführende Literatur und einen Gedankenaustausch senden Sie mir bitte eine . Kontaktadresse: Edmund-Gerhard Schrümpf, dipl.ing. TU, CMC, (CISA) beeideter, gerichtlich zertifizierter Sachverständiger und Lektor an der FH der Wirtschaft CAMPUS02 Hofgasse 7 A-8010 Graz Österreich Telefon: Fax: edmund.schruempf@edconsult.eu Internet: bzw.