|
Compliance und Risiko-Management für die Softwareentwicklung
Risiken
steuern
Unzulängliche Software kann
für Unternehmen ein großes Risiko darstellen. Dennoch ist ein systematisches
Risiko-Management in der Softwareentwicklung nur wenig verbreitet. Vor dem
Hintergrund der Compliance-Debatte werden die Unternehmen hier umdenken und
beispielsweise ein Frühwarnsystem für ihre Entwicklungsprojekte einführen
müssen.
oftware zu entwickeln ist riskant. Trotz des erheblichen Aufwands, der in der
Softwareentwicklung getrieben wird, nimmt die Zahl der erfolgreich beendeten
Projekte ab: zwischen 2002 und 2004 von 34 auf mittlerweile nur noch 28 Prozent.
Anders ausgedrückt: wer heute Software in Auftrag gibt, muss damit rechnen, dass
er nicht bekommt, was er bestellt hat – schlimmstenfalls gar nichts, denn 18
Prozent der Projekte scheitern ganz. In wenigen, Aufsehen erregenden Fällen wie
der Einführung der Autobahnmaut oder der ALG-II-Berechnung wird der Mangel
offenkundig, in der Regel werden Schäden in aller Stille beseitigt. Trugen
bisher vor allem die Auftraggeber die Risiken der Softwareentwicklung, so hat
sich der Wind seit einigen Jahren gedreht. Mittlerweile werden die Hersteller
unzulänglicher Software stärker in die Pflicht genommen, sei es durch erweiterte
Produkthaftung oder durch die immer weiter ausgedehnten Compliance-Regelungen.
Es wird immer teurer, wenn Software nicht funktioniert, und je mehr die
Unternehmen auf Software angewiesen sind, desto weniger verfängt der über
Jahrzehnte gepflegte Generalablass, Fehler wären bei Software nun mal
unvermeidlich. Mehr noch: Softwarehersteller, die große Projekte gegen die Wand
fahren, gefährden heute massiv ihren eigenen Fortbestand. Die Compliance-Politik
sorgt dafür, dass auch die Organe, also Vorstände oder Geschäftsführer dabei
nicht ungeschoren bleiben. Und sollte eine interne Entwicklungs-Abteilung
anhaltend unzulängliche Ergebnisse aufweisen, riskiert sie ohne großes
Federlesen outgesourced und offgeshored zu werden.
Natürlich birgt Softwareentwicklung immer Risiken, darin unterscheidet sie sich
nicht von anderen Tätigkeiten. Je wichtiger aber Software für die Durchführung
der Geschäftsprozesse in den Unternehmen ist, desto gravierender wirken sich
Fehler und Unzulänglichkeiten der Software auf das Unternehmen als Ganzes aus.
Mit einer unzulänglichen Textverarbeitungslösung kann man notfalls »irgendwie«
zurechtkommen, bei einem Logistik-System wird das nicht mehr gelingen.
Risiko-Management für die
Softwareentwicklung
Umso erstaunlicher ist es, wie wenig das Risiko-Management bisher in der
Softwareentwicklung oder anwenderseitig bei der Implementierung von
Applikationen verankert ist. Systematisch finden Risikoaalyse, -Bewertung,
-Controlling oder -Steuerung jedenfalls nur in Ausnahmefällen statt.
Bemerkenswert ist dabei auch, dass die etablierten Software-Lösungen für das
Risiko-Management, beispielsweise Risk-Management-Informationssysteme (RMIS),
ausgerechnet in der Softwarebranche selbst kaum verwendet werden.
Dabei hat sich die Lage in den letzten Jahren dramatisch verschärft. Der
Wettbewerb erzwingt oft sehr knappe Kalkulationen, so dass dann für einen
finanziellen Risikopuffer kein Spielraum mehr ist. Tritt das Risiko dann doch
ein, sind keine Mittel mehr vorhanden, um beispielsweise zur Schadensbegrenzung
die Ressourcen aufzustocken. So versäumen es Unternehmen immer wieder beim
Outsourcing von Entwicklungsprojekten entsprechende Risikoprämien zu
kalkulieren, die notwenig sind, um den dabei unvermeidlichen Kontrollverlust
auszugleichen. Vermeintliche Sparmaßnahmen können sich dann, zum Beispiel beim
Ausfall des Outsourcing-Partners, als teurer Bumerang erweisen.
Die Compliance-Debatte hat auch zu diesem Thema ein neues Kapitel eröffnet.
Bisher stellte sich erst hinterher heraus, wie groß das Risiko eines Projekts
war. Ging es schief, zahlte man Vertragsstrafen oder Schadensersatz und war
froh, mit einem blauen Auge davongekommen zu sein. Spektakuläre Fälle wie
Worldcom, Enron oder Parmalat haben gezeigt, dass eine derartige
Ex-Post-Betrachung nicht ausreicht, dass im modernen Business vielmehr in
kürzester Zeit kommerzielle und volkswirtschaftliche Schäden sich anhäufen
können, die hinterher nicht mehr zu beseitigen sind. Vorschriften wie Basel II,
Sarbanes-Oxley oder Solvency II versuchen daher vorher anzusetzen und
Risikosituationen im Entstehen schon zu erkennen: Sie wechseln von der
statischen Ex-Post- zu einer dynamischen Prozess-Analyse.
Das deutsche KonTraG (Gesetz zur Kontrolle und Transparenz im Unternehmen)
verpflichtet beispielsweise die Unternehmen explizit zu einem professionellen
Risiko-Management, das es erlaubt, die wesentlichen Risiken durch ein
Früherkennungssystem rechtzeitig zu identifizieren. Auch im KonTraG ist der
Durchgriff auf die Organe vorgesehen: Vorstände beziehungsweise Geschäftsführer
sind für die Einhaltung verantwortlich, die Aufsichtsräte müssen sich davon
überzeugen, dass ein Frühwarnsystem auch funktioniert.
Risikofaktoren der
Softwareentwicklung
Natürlich muss das Risiko-Management für die Softwareentwicklung voll und ganz
in das des ganzen Unternehmens eingebunden sein, sich also als Enterprise Risk
Management (ERM) verstehen. Wird beispielsweise die Liquidität des Unternehmens
knapp, so verliert auch die beste Risikostrategie der Entwicklung ihren
Handlungsspielraum. Dennoch gibt es eine Reihe typischer Risikofaktoren der
Softwareentwicklung, die in einem softwarespezifischen Frühwarnsystem zu
berücksichtigen sind.
Auswahl von Risikofaktoren:
1
Exogene Risikofaktoren
Risikofaktoren, die vom softwareherstellenden Unternehmen nicht beeinflusst
werden können
1.1
Gesellschaftliche Risiken
·
Gesetzliche Vorschriften,
Regularien, Auflagen, Steuern usw.
Es muss dabei nicht immer um große Gesetzesänderungen gehen. Werden
beispielsweise Brandschutzvorschriften neu gefasst, so kann vielleicht ein
Server nicht mehr wie vorgesehen aufgestellt und die gesamte Softwarearchitektur
muss überarbeitet werden
·
Sicherheit, Kriminalität:
Ein veränderte Sicherheitslage kann zu veränderten Anforderungen an die
Applikationen führen; andere Zugangskontrolle, bessere Verschlüsselung usw.
·
Natur, Umweltereignisse,
Katastrophen:
Muss in Risikozonen ebenfalls berücksichtig werden, zum Beispiel durch
Ausweich-RZ usw.
·
Technologische Entwicklung:
Zum Beispiel neue Kommunikationswege, neue Endgeräte, mehr Speicherkapazitäten
1.2
Geschäftliche Risiken
·
Marktsituation
Typische unternehmerische Risiken, Mitbewerb bringt preiswerteres oder besseres
Produkt auf den Markt; neue Standardlösungen machen beispielsweise
Eigenentwicklung überflüssig usw.
·
Wechselkurse
·
Anforderungen von Kunden:
Kunde wünscht zum Beispiel RFID einzusetzen
·
Support:
Zum Beispiel Auslaufen des Hersteller-Supports für die Zielplattform
·
Vertragliche Bindungen, Rechte,
Marken usw.
2
Endogene Risikofaktoren
Risikofaktoren, die vom
softwareherstellenden Unternehmen beeinflusst werden können
2.1
Risiken auf Unternehmensebene
·
Unternehmenspolitik:
Das Unternehmen beschließt zum Beispiel sich aus einem Markt zurückzuziehen
·
Finanzielle Mittel:
Risikostrategien kosten (fast) immer Geld
·
Personelle Ressourcen:
Zum Beispiel können bei generellem Einstellungsstopp keine zusätzlichen
Entwickler verpflichtet werden, um Termine doch noch einzuhalten
·
Abstimmung mit Fachbereichen:
Wegfall des Inputs, beispielsweise durch neue Mitarbeiter, kann das Requirement
erschweren oder unmöglich machen; und womöglich ein ganzes Projekt gefährden
·
Unterstützung durch das
Management:
Ist essentiell für alle Projekte, verabschiedet sich beispielsweise der
Vorstand, der das Projekt gestützt hat, so steht unter Umständen die weitere
Durchführung in Frage.
2.2
Risiken auf der Ebene der IT-, beziehungsweise der Entwicklungs-Abteilung
2.2.1
Technische Risiken
·
Infrastruktur
Wahl der richtigen Infrastruktur für Entwicklung und Laufzeitumgebung, wenn eine
Host-Landschaft keine mobilen Systeme unterstützt, kann die Softwareentwicklung
dafür keine Lösungen bereitstellen
·
Entwicklungswerkzeuge:
Programmiersprachen, IDEs usw.
Einer der wenigen Bereiche, in denen sich die Risikolage für die
Softwareentwicklung in den letzten Jahren verbessert hat. Durch den Einsatz von
plattformunabhängigen und gemischtsprachigen Entwicklungswerkzeugen hat sich das
Risiko bei Projektstart die »falsche« Programmiersprache oder Plattform gewählt
zu haben, vermindert. Dennoch können ungeeignete Tools verwendet werden.
2.2.2
Spezielle Risiken der Softwareentwicklung
·
Erfassung der Anforderungen
Werden Anforderungen nicht konsistent erfasst, so ist ein Scheitern des Projekts
fast vorprogrammiert
·
Change-Management und
Prozess-Steuerung über den gesamten Application Lifecycle:
funktioniert diese Steuerung nicht, so verläuft die Softwareentwicklung
unkontrolliert
·
Dokumentation:
Durch unzureichende Dokumentation sind die Prozessschritte nicht
nachvollziehbar, der Entwicklungsprozess ist damit nicht revisionssicher, es
kann dann beispielsweise die Abnahme scheitern
·
Bereitstellung IT-Ressourcen:
Zum Beispiel Performance, Plattenkapazität, RAM usw.
·
Personelle Ressourcen,
Verfügbarkeit von Know-how
·
Prioritätensetzung innerhalb
der Projekte
·
Interne Kommunikation:
Insbesondere wichtig bei geographisch verteilter Entwicklung
·
Kooperation und Kommunikation
mit Partnern, Dienstleistern externen Entwicklern, zum Beispiel bei teilweise
ausgelagerten Projekten
Das Risiko-Management muss ein System aufbauen, dass sämtliche Risikofaktoren
nicht nur statisch erfasst, sondern ständig ihre Veränderung beobachtet. Risiken
sind dynamisch und die Faktoren verändern sich während der Projektlaufzeit. Dann
ist eine Neubewertung der Risikosituation vorzunehmen, auf deren Grundlage
geeignete Maßnahmen zu ergreifen sind. Im Extremfall kann dies auch zu einem
kontrollierten Abbruch eines Projekts führen.
Moderne Ansätze in der Softwareentwicklung sind ohnehin prozessorientiert und
bilden so eine gute Voraussetzung für die Etablierung eines Risiko-Managements,
so beispielsweise das Konzept des Application Lifecycle Management oder Borlands
Software Delivery Optimization. Auch die Verfahrens- und Reifegrad-Modelle, wie
das V-Modell oder CMMI, betonen den Prozessaspekt und lassen sich so gut mit dem
Risiko-Management verbinden. Erreicht ein Unternehmen beispielsweise ein hohes
CMMI-Level, so können verschiedene Risiken anders bewertet werden.
In der Softwareentwicklung fehlt jedoch häufig ein entsprechendes
Problembewusstsein. Viele meinen, es genüge, die Risiken der Softwareentwicklung
ex-post und akzidentiell zu betrachten – etwa nach dem Motto, wenn das Kind in
den Brunnen gefallen ist, wird es schon schreien. Erst auf Basis eines
durchgängigen Risiko-Managements lässt sich auch eine aktive Risikopolitik
betreiben, die nicht nur Schäden frühzeitig erkennt, sondern gleich Vermeidungs-
oder Ausweichkonzepte entwickelt. Andernfalls könnte es dazu kommen, dass eine
möglichst perfekte Risikokontrolle in eine Angst-Strategie mündet, die den
Geschäftsbetrieb lähmt. Das geringste Risiko bestünde, wenn auf
Softwareentwicklung ganz verzichtet würde – es ist allerdings ein erhebliches
Risiko, wenn dann vernünftige Applikationen für die Weiterentwicklung des
Business fehlen.
Matthias Zieger
___________________________________________________________
Matthias Zieger
ist Technology Consultant bei Borland in Langen
Die Risikostrategie muss versuchen, die Risikofaktoren in den Akzeptanzbereich
zu bringen.
Prozessstruktur des Risiko-Managements
Stufen des Risiko-Management
·
Risikoanalyse
·
Risikoidentifizierung
·
Risikobewertung
·
Prüfen der
Handlungsalternativen
·
Risiko vermeiden
·
Risiko vermindern
·
Risiko begrenzen
·
Risiko selbst tragen
·
Risiko externalisieren
·
Entwicklung einer
Risikostrategie und deren laufende Kontrolle.
| 
Online-Artikel 20060506q Borland Compliance und Risk-Management
