SNAG Blog

Ein guter Teil der Software, die heute bei Banken, Leasingunternehmen, Versicherungen und anderswo eingesetzt wird, wurde von Laien erstellt, die keinerlei IT-fachliche Ausbildung besitzen. Diese Programme sind undokumentiert, ungetestet, sind durch keinerlei Freigabeprozess gelaufen und oft ist nur ein einzelner Mitarbeiter in der Lage sie zu bedienen und zu warten. Dennoch bilden sie vielfach das Rückgrat bei der Unterstützung geschäftskritischer Prozesse.

Was sich wie die Bankrotterklärung der IT anhört, hat einen allseits bekannten Namen: Tabellenkalkulation. Tabellenkalkulationen versetzen Nicht-IT-User in die Lage, Daten zu verarbeiten und dazu eine komplexe Logik aufzubauen – mit all dem Nutzen, den das stiften kann – und mit all den Problemen die das aufwirft. Die komlexe Logik kann sich in Makros verbergen, aber auch „konventionelle“ Sheets beinhalten oft komplexe Abhängigkeiten, die durchaus mit „echter“ Software zu vergleichen sind. Somit lässt sich hier auch von „Sheet-Programmen“ sprechen.

Problem: Tabellenkalkulations-Sheets entstehen mit unklaren Anforderungen
Da Sheet-Programme in der Regel von demjenigen entwickelt werden, der sie später auch benutzen wird, könnte auf den ersten Blick die Qualität der Anforderungen nicht besser sein. Wer sollte besser als der Nutzer wissen, was gebraucht wird? Tatsächlich entwickeln sich Sheet-Programme oft aus Augenblickslösungen, die immer wieder auf neue Anforderungen erweitert werden, weil die Daten „schon so schön aufbereitet“ sind. Im Ergebnis ist letztlich unklar, was das Programm tut, welche Sonderfälle doch nicht abgedeckt sind, welche noch manuelle Nacharbeit erfordern und welche Aufbereitung der Daten als gegeben angenommen wird.

Problem: Tabellenkalkulations-Sheets werden nicht getestet
Der Entwickler eines Sheet-Programms ist alles in einer Person: Architekt, Entwickler, Tester und (oft einziger) User. Eine Arbeitsmappe, mit der Zahlen des letzten Monatsabschlusses verarbeitet werden, wird nur mit diesen Zahlen geprüft – und dann für alle Folgemonate eingesetzt.

Problem: Tabellenkalkulations-Sheets enthalten Fehler
Experten schätzen, dass etwa 4% aller Formeln in Sheets Fehler aufweisen. Das gilt auch für Sheets, die von erfahrenen Usern erstellt wurden. Das liegt nicht nur daran, dass Sheet-Programme oft durch Copy-Paste erstellt und weiterentwickelt werden. Tabellenkalkulationen fehlt einfach vieles von dem, was die Informatik in den letzten vierzig Jahren entwickelt hat, um Softwareentwicklung effektiver und weniger fehleranfällig zu machen. Zum Beispiel wird in der Regel eine „Speicherzelle“ referenziert – und eben keine Variable.

Problem: Tabellenkalkulations-Sheets werden eingesetzt, aber nicht in Betrieb genommen
Software, gerade wenn sie kritische Prozesse unterstützt, benötigt eine entsprechende Infrastruktur. Klare Verantwortlichkeiten und Prozesse, Dokumentation, Einbindung in Notfallpläne und Datensicherung fehlen bei handgestrickten Tabellenkalkulations-Lösungen.
Weiter ist oft nicht sichergestellt, dass nur Mitarbeiter mit entsprechenden Rechten auf das Sheet zugreifen und Daten einsehen oder verändern können. Ein Kennwort, das das Sheet selbst vor Änderung schützt, wird spätestens dann zur Falle werden, wenn der Ersteller nicht oder nicht mehr greifbar ist.

Fazit:
Die umfangreichen Möglichkeiten von Tabellenkalkulationen und die Tatsache, dass viele Fachanwender gut in diese Lösung eingearbeitet sind, machen es zu einem flexiblen und mächtigen Werkzeug. Wo diese Macht über das vertretbare Maß hinaus genutzt wird, wird die Landschaft der Tabellenkalkulations-Lösungen jedoch zum Problem. Auch in rechtlicher Hinsicht entsprechen diese Lösungen keinerlei Standard.
Für die IT sollte das geballte Auftreten von Tabellenkalkulations-Lösungen in kritischen Prozessen ein Alarmzeichen sein, dass wichtige Anforderungen von den IT-Lösungen nicht abgedeckt werden. Sie stattdessen Software-Laien zu überlassen kann keine dauerhafte Lösung sein.

Für die Umsetzung eines Projekte ist der Einsatz eines definierten Vorgehensmodells hilfreich. Dieses definiert Regeln und Leitlinien für die Begleitung der Wertschöpfungskette von der Projektinitialisierung bis zum Produktionseinsatz. Im Rahmen des Projektprozesses müssen unterschiedlichste interne und externe Einflussfaktoren Berücksichtigung finden - sprich es muss offen sein für die Integration von Erfahrungen und Erkenntnisse.

Neben den traditionellen Methodiken wie z.B. Wasserfall-Modell, RUP/UML wurden in der letzten Zeit des öfteren agile Methoden empfohlen und verwendet. Diese werden häufig als mögliche Gegenkonzepte zum klassischen SW-Engineering verstanden. Aber gerade die agilen Methodiken definieren das systematische Vorgehen im Umgang mit den Kernaufgaben der Projektmethodik: regelmäßige Retrospektiven, fortlaufende Integration und hohe Flexibilität im Verlauf des Projektprozesses. Insofern sind agile Methodiken weniger ein Gegenkonzept zum klassischen SW-Enginieering, sondern eher dessen konsequente Weiterentwicklung - sie sind aus der Praxis entstanden.

Bei der Auswahl der geeigneten Methodik sollte deshalb die Art des Projektes und dessen Umfeld im Vordergrund stehen. Aber egal welche Methodik zum Einsatz kommt: das Spannungsfeld aus Budget / Zeit / Lösung bleibt die große Herausforderung für den Projektmanager...

Funktionsfähiges Risikomanagement gehört mit zu den Grundpfeilern eines jeden guten Projektmanagements. Doch zeigt sich die Tragfähigkeit jenseits alltäglicher Risiken erst spät, im Zweifelsfall zu spät.

Ist die Governance reagibel und agil, sind Entscheidungsprozesse gängig? All das muss sich unter Umständen ad hoc beweisen. Gut, wenn dann die Räder nahtlos ineinander greifen, schlecht, wenn es knirscht.

Dann doch lieber prüfen, wenn es ‚risikolos’ möglich ist.

Ideen aus dem Qualitätsmanagement a’la fault-injection bieten sich dabei an. Mal bewusst SMEs ausgewechselt, mal gezielt an den Requirements gerüttelt oder ein Constraint invalidiert – Kein Rasten, kein Rosten!

Wir berichteten über die anstehenden Änderungen im Bilanzrechtsmodernisierungsgesetz (BilMoG) an dieser Stelle im S&N-Blog.

Dem Jahreswirtschaftsbericht 2009 der Bundesregierung (siehe "hier") kann nun auf der Seite 36 entnommen werden, dass die Inkraftsetzung des BilMoG für das Frühjahr 2009 erwartet wird.