Transparenz als Grundlage der Glaubwürdigkeit

Posted on 9. Januar 2012 by akoppel

Von Sergej P. Koroljow gibt es die bekannte Aussage “Kompliziert bauen kann jeder”. Genau genommen hatte er gesagt “Die Genialität einer Konstruktion liegt in ihrer Einfachheit. Kompliziert bauen kann jeder.” Koroljow war sozusagen der Vater der russischen Raumfahrt. Tatsächlich gilt diese Aussage noch heute, denn es ist zumeist kein Problem, einen komplizierten Sachverhalt auch kompliziert wiederzugeben. Die Schwierigkeit liegt darin, einen komplizierten Sachverhalt so aufzubereiten, dass er auch von normal Sterblichen verstanden werden kann. In der Programmierung bedeutet das, dass die erste Version eines Programmes zumeist ein Erscheinungsbild und eine Funktionalität hat, die wirklich nur von den Leuten verstanden wird, die’s programmiert haben. Die eigentliche Arbeit beginnt jedoch erst dann. Denn dieses komplexe Software-Gebilde muss in eine Form gebracht werden, dass ein Anwender auch eine Chance hat, es zu verstehen, ohne zuvor eine Schulung im Umfang einer Doktorarbeit zu durchlaufen.

Ich sehe dass hier als wirklich stete Herausforderung an, denn überaus häufig müssen wir unser System immer aufs neue anwenderfreundlich  gestalten, damit es überhaupt bedienbar bleibt. Auf den ersten Blick sieht dass dann so aus, als ob der Leistungsumfang beschnitten wurde (oder von Anfang an gar nicht vorhanden war), tatsächlich ist jedoch sehr viel Arbeit hinein geflossen, die komplexen Vorgänge vor dem Anwender zu verbergen (oder sie erst in Form weiterer optionaler Möglicheiten freizugeben).

Der nächste Schritt wird die grafische Aufbereitung von Daten sein. Damit meine ich nicht irgendwelche einfachen Linien-, Torten- oder Balkendiagramme, sondern aussagekräftige Diagrammdarstellungen oder dreidimensionale Visualisierungen von Vorgängen. Ich denke, dass es für jeden Anwender hilfreich ist, wenn er sich den aktuellen Bearbeitungsstand grafisch anzeigen lassen kann, statt einfach auf Tabellen zu vertrauen.

Wir haben schon mehrere Ideen für entsprechende Auswertungen, freuen uns jedoch über jede Mail oder jeden Anruf frei nach dem Motto: “Was ich schon immer mal sehen oder wissen wollte”. Wie in unserer Firma üblich werden derartige Ideen natürlich zumeist kostenlos umgesetzt.

Posted in Datenanalyse | Tagged , | Leave a comment

Tips und Tricks in INVEP

Posted on 4. Januar 2012 by akoppel

Stetig erweitern wir unser Produkt um neue Funktionen, die dann zumeist nur den Anwendern bekannt sind, die sich genau diese Funktion gewünscht haben. Es ist jedoch schade, dass die Vielzahl an Hilfsfunktionen vor anderen Augen verborgen bleibt, schlicht weil niemand nachfragt (oder das aktuelle Handbuch liest). Wir haben daher auf der INVEP-Seite  einen neuen Bereich mit Tips & Tricks eingerichtet, in dem wir jeweils aktuelle Dinge herausstellen. Ein Besuch lohnt sich also immer mal wieder.

Wenn Sie eine Idee haben, so nehmen wir diese Idee in Zukunfts gerne auf. Senden Sie uns einfach eine Mail an support@akso.de oder schreiben Sie inen Kommentar hier im Blog.

Posted in Allgemein | Tagged , | Leave a comment

Computer haben eine endliche Genauigkeit

Posted on 4. Dezember 2011 by akoppel

In einer digitalen Welt, in der es heutzutage extrem einfach ist, selbst umfangreiches Zahlenmaterial zu verarbeiten passiert es schnell, dass man blind vertraut, wo man doch eigentlich Vorsicht walten lassen sollte.

Die Grundrechenarten erlernt man bereits in der Grundschule, und je nach Jahrgang sind dann verschiedene Hilfsmittel zur Berechnung hinzugekommen. Ich möchte jetzt nicht ausschweifend darauf eingehen, wie es war, mit Logarithmentafeln und Rechenschiebern zu rechnen. Es reicht aus, dass wir irgendwann angefangen haben, Taschenrechner zu verwenden. Ein Taschenrechner oder auch ein Tischrechner ist eine tolle Sache, man kann beliebige Kettenrechnungen durchführen und bekommt ein korrektes Ergebnis. Es gibt eine kleine aber magische Einschränkung: Man bekommt ein korrektes Ergebnis, sofern man die Rechengenauigkeit der Maschine nicht überfordert. Tatsächlich sind moderne wissenschaftliche Taschenrechner sogar extrem genau, da eine Vielzahl an Knowhow in die Eliminierung von Rundungsfehlern eingeflossen ist.

Als moderner, computeraffiner Mensch nutzt man keinen Taschenrechne mehr, sondern das ultimative Schweizer Messer mit dem Namen Excel. Excel ist ein gutes Werkzeug, jedoch gibt es ein seh großes ABER. Man muss in Excel extrem aufpassen, dass die durchgeführten Berechnungen nicht zu umfangreich werden, denn je nach Größe der Zahlen entstehen in Excel früher oder später extreme Rundungsfehler. Im Finanzmathematischen machen sich die Fehler sehr schnell nicht nur im Cent-Bereich bemerkbar.

Ich habe etwas mit Excel rumgespielt und eine leicht nachvollziehbare Tabelle erstellt, die im Ergebnis absuluten Unsinn liefert. Zum einfachen Nachvollziehen kann die Tabelle hier geladen werden. Ich habe die Tabelle auch noch als PDF-Datei ausgedruckt, das Dokument kann hier geladen werden. Was sagt uns die Tabelle anbetracht der Tatsache, dass Excel sich doch im täglichen Einsatz bewährt und vermeindlich richtig rechnet?

Tatsächlich ist es ganz einfach: Bedingt durch seine logische Struktur akkumuliert Excel Rundungsfehler. Diese Rundungsfehler machen sich bei Einzelberechnungen kaum bemerkbar, wirken sich jedoch bei aufwändgen Kalkulationen mit steter Weiterverwendung vorheriger Ergebnissse früher oder später stark aus.

Heißt das jetzt, dass man Excel nicht verwenden soll? Sicherlich nicht. Mann muss sich eben nur sehr bewust sein, welche Art von Berechnungen man mit Excel durchführt. Für aufwändige Kalkulationen mit vielen Folgeberechnungen ist es schlicht nicht geeignet.

Grundsätzlich ist das übrigens keine Schlamperei von Microsoft, sondern ein immanentes Problem der zugrundeliegenden Mikroprozessorarchitektur. Wenn man wirklich richtig rechnen will, dann gibt es dafür entsprechende Werkzeuge, aber eben nicht Excel.

Übrigens gehören Vergütungsberechnungen sowie Berechnungen von Quotenzahlungen genau in die Kategorie der Berechnungen, die aus obigen Gründen mit Excel nicht möglich sind. Wenn man sich die Mühe macht und die dergestalt erzeugten Ergebnisse mit den entsprechenden Werkzeugen (z.B. Mathematica) nachrechnet, dann merkt man schnell, dass die Ergebnisse falsch sind.

Wer noch eine andere Datei ansehen möchte, der kann hier eine weitere Excel-Datei zum spielen laden, mit der die Fehlerausbreitung aufgezeigt wird.

 

Posted in Buchhaltung, Datenanalyse | Tagged , | 1 Comment

Winkelfunktionen in der Finanzmathematik

Posted on 1. August 2011 by akoppel

Es ist schon erstaunlich, was man alles für die Auswertung von Buchhaltungsdaten braucht. Im Rahmen unserer Forensik-Tools müssen wir die Betrachtungen immer wieder auf eine neue mathematische Ebene heben. Wenn man sich Buchhaltungsdaten insolventer Firmen ansieht, dann sieht das auf den ersten Blick nicht groß anders aus als jede andere Buchhaltung auch, mit der Ausnahme natürlich, dass die Firma irgendwann insolvent geworden ist, die Buchhaltung also kollabiert. Eine magische Frage ist jedoch, ob man das auch schon sehr viel früher erkennen kann. Ist es möglich, aus der Art der Bewegungen auf den Konten zu einem frühen Zeitpunkt festzustellen, ob eine Firma in die Insolvenz gehen wird. Wenn diese Frage bejaht werden kann, dann ergeben sich damit höchst interessante Hebel, sowohl was die Insolvenzverschleppung angeht, als auch die Möglichkeit, Gelder aus vergangenen Geschäften zurückzufordern (siehe hierzu die diversen HGB- und BGB-Gesetze). Wie oben schon gesagt, kommt man mit einer “einfachen” Analyse der Finanzdaten nicht weiter – egal wie vollständig die Daten sind -, denn selbst umfangreiche Kontenausschläge oder eine stete Verminderung der Mittel ergeben keine ausreichende Information (solche einfache Betrachtungen wurden in der Vergangenheit hinreichend erfolglos durchgeführt).
Jede Firma hat ihren eigenen “Fluß” in Bezug auf die Finanzen. Daraus ergibt sich, dass weder einfache Statistik noch Merkmalssuchen zu einem Ergebnis führen. Der deutlich vielversprechendere Weg ist ist, diesen “Fluß” der Finanzen mathematisch darzustellen und dann den Punkt zu finden, an dem die Abweichungen auftreten. Hat man den oder die Punkte gefunden, ist der Mensch wieder gefragt, um festzustellen, was an den strategischen Stellen passiert. Um solche Betrachtungen anzustellen, müssen Steigungs- und Regressionsberechnungen durchgeführt werden. Tatsächlich landet man hierbei sehr schnell bei Berechnungen mit komplexen Zahlen oder – wenn man die komplexen Zahlen umgehen möchte – bei hyperbolischen Winkelfunktionen. Die sich daraus ergebenden Aussagen sind überaus vielversprechend. Es können so insolvenzrelevante Sachverhalte aufgezeigt werden, die bei einer “normalen Betrachtung der  Buchhaltung” schlicht unsichtbar bleiben. Beweisbar ist all das, die nun noch anstehende Aufgabe ist jedoch, dass Ganze so aufzubereiten, dass die zugrunde liegende Mathematik so leicht nachvollziehbar ist, dass im Streitfalle die Beteligten die Zusammenhänge nicht in Zweifel ziehen. Für den Verwalter ist das ein enormer Vorteil, da auf diesem Wege in erheblichem Maße die Masse erhöht werden kann – vorausgesetzt, die so aufgezeigten Sachverhalte werden durchgesetzt.
So kommen die Winkelfunktionen in die Finanzmathematik.

Posted in Allgemein, Buchhaltung, Datenanalyse | Tagged | 2 Comments

Wie vollständig ist vollständig oder was implementiert man

Posted on 25. Juli 2011 by akoppel

Ich hatte ja schon darüber geschrieben, dass wir einen recht guten BASIC-Interpreter in unserer Software eingebaut haben, mit dem man tatsächlich alles Steuern und umfangreiche Berechnungen durchführen kann. Nun zeigte sich, dass wir teilweise Matrix-Algebra benötigen, um verschiedene Auswertungen effizient zu ermöglichen. Selbstverständlich könnten wir auch verlangen, dass der Anwender alles von Hand programmiert, aber das ist wohl nicht der Sinn der Sache, viel besser ist es, wenn es spezielle Anweisungen und Funktionen als integralen Bestandteil der Sprache gibt, die so etwas übernehmen. Also haben wir angefangen, Matrix-Algebra-Funktionen in die Sprache einzubauen. Das ist natürlich ein immens weites Feld. Wer sich mal etwas näher damit beschäftigt hat wird wissen, dass die mathematische Verknüpfung von Variablen, Vektoren und Matrizen nicht nur starren Regeln folgt, sondern auch sehr viel Raum für Zulässigkeitsbetrachtungen und Implementierungsformen bildet.
Genau hier liegt dann das Problem. Tatsächlich brauchen wir nur sehr wenige Vektor- und Matrixoperationen für alle Auswertungen, die in unserem Fachbereich notwendig sind.
Hoch-komplexe Auswertungen würde man ohnehin mit anderen Werkzeugen als der von uns implementierten Programmiersprache erstellen. Die Schönheit der Vollständigkeit verlangt natürlich, alle Varianten einzubauen, selbst die, die nicht benötigt werden; die wirtschaftliche Betrachtung verbietet das jedoch.
Generell hat man immer wieder die Situation, dass die Frage aufgeworfen wird: “Wenn das schon vorhanden ist, warum dann nicht noch den kleinen Schritt gehen, um es vollständig zu machen?”. Was jedoch ist schon tatsächlich vollständig? Das liegt immer im Auge des Betrachters. Eine pragmatische Sicht ist zu sagen, dass vollständige Programme all das enthalten, was üblicherweise benötigt wird (das lässt natürlich Raum in Bezug auf die Betrachtung, was als “überlicherweise” zu bezeichnen ist). Damit wird die Vollständigkeit zu einem gleitenden Prozess. Es gibt also immer eine “aktuelle Vollständigkeit”, die sich durch neue Erkenntnisse oder Anforderungen in eine “Unvollständigkeit” wandeln kann, was dann wiederum mit sich bringt, dass Erweiterungen vorgenommen werden müssen, um wieder eine “aktuelle Vollständigkeit” zu erreichen.
Ich denke, dass dieser Ansatz vertretbar ist (und vor allem wirtschaftlich sinnvoll).

Posted in Allgemein, Programmerweiterungen, Programmieren an sich | 1 Comment

Mit Intelligenten Fehlermanagement kann man sich in den Fuß schießen

Posted on 8. Juli 2011 by akoppel

Ich kann ja nun persönlich auf 30 Jahre Softwareentwicklung zurückblicken, und was ich definitiv sagen kann ist, dass das Fehlermanagement deutlich komplizierter geworden ist. Ohne auf Details einzugehen ist es tatsächlich so, dass Softwaresysteme früher sehr viel deterministischer waren. Es gab erheblich weniger Möglichkeiten (auch in der Erfassung und der Bildschirmmaskensteuerung) und somit auch weniger denkbare Fehlerkonstellationen. Wenn eine Software so gebaut ist, dass nur eine Sache nach der anderen gemacht wird (d.h. auch eine Eingabe nach der anderen in einer definierten Eingabereihenfolge verarbeitet wird), dann hat man tatsächlich eine realistische Chance sämtliche denkbaren Fehlersituationen Stück für Stück zu berücksichtigen. Heutzutage hat man dagegen Systeme, die eine nahezu beliebige Erfassungs- und Eingabereihenfolge gestatten. Wenn nun einzelne Eingaben Abhängigkeiten untereinander aufweisen, so wird es richtig kompliziert, denn einerseits soll die Freiheit der Eingabe gewahrt bleiben, andererseits sollen Fehleingaben ausgeschlossen werden. Um der Sache noch eine Komplexitätsstufe hinzuzufügen, sollen häufig bereits während der Eingabe Jobs ablaufen, die die weitere Erfassung vereinfachen. Selbstverständlich dürfen unsinnige Eingaben oder Daten nicht zu einem Absturz führen, sondern die Programme müssen “intelligent” darauf reagieren. Tatsächlich ist es absolut unmöglich, bei jedem Eingabefeld sämtliche Kombinationen mit anderen Feldern zu berücksichtigen (alleine bei vier Feldern gibt es schon 32 Möglichkeiten), also werden nur als problematisch erkannte Szenarien berücksichtigt. Das führt jedoch sehr schnell zu Problemen, denn jeder erfahrene Programmierer weiß, dass es egal ist, wie viele Szenarien berücksichtigt werden, beim Kunden wird sofort eines auftreten, dass nicht berücksichtigt wurde. Der vorausschauende Entwickler baut also zusätzliche Schutzmechanismen ein, die dann greifen, wenn eine problematische Eingabe nicht erkannt wurde. Dann gibt’s noch Schutzmechanismen für die Schutzmechanismen. Das ganze führt dann zwar zu einem sehr stabilem Code, hat jedoch auch den überaus negativen Effekt, dass Fehler als solche gegebenenfalls nicht erkannt werden, dann zu Folgefehlern führen, die vielleicht auch nicht erkannt werden, weil die Software auch darauf noch “intelligent” reagiert und dann irgendwann  ein Fehler auftritt, der nicht mehr abgefangen wird, sozusagen als Folge der Folge der Folge. Und genau diesen letzten Fehler kann man dann nicht mehr analysieren, weil nicht mehr festzustellen ist, was eigentlich der ursprüngliche Auslöser war. Es ist dann schon fast Zufall, wenn der ursprüngliche Fehler dann doch irgendwann gefunden wird. In der Regel ist das dann eine Anwendereingabe, die irgendwie nicht sinnvoll war, mit der das Programm jedoch intelligent umgegangen ist (ohne wirklich intelligent zu sein).
Wenn man sich mal die verschiedenen Protokolle (egal von welchem Betriebssystem) ansieht, dann ist man bass erstaunt, wie häufig soetwas vorkommt.
Derartige Probleme lassen sich tatsächlich per se nicht lösen. Man kann nur versuchen ein Gesamtsystem so zu gestalten, dass die letzte Instanz so klein wie möglich ist und dafür sorgt, das selbst im schlimmsten Fall keine Daten zerstört werden. So eine Sicherheit ist wiederum nur mit modular aufgebauten Systemen erreichbar, sei es auf Betriebssystem-, Datenbank- oder Anwendungsebene.
Warum diese Blogeintrag? Wir hatten grade so einen Fehler. Ab und an (extrem selten) ist uns die umfangreiche und mit Eigenintelligenz ausgestattete Adresserfassung abgestürzt. Es gab zwar niemals eine Datenzerstörung, aber der Absturz an sich ist einfach ärgerlich für den Kunden, denn die Adresse muss neu erfasst werden. Da der Fehler so selten aufgetreten ist, und der tatsächliche Absturz in keinem Zusammenhang mehr mit dem ursprünglichen Fehler stand, hat es wirklich gedauert, bis der Fehler gefunden wurde, denn welcher Anwender ist schon in der Lage 100%ig zu beschreiben, was er genau eingegeben hat. Wie dem auch sei, wir haben’s gelöst und sind wieder etwas schlauer.

Anmerkung:
Es gibt diverse Verfahren wie Code Coverage und andere, die in dieser Konstellation jedoch nicht weiterhelfen…

Posted in Programmieren an sich | Tagged | 1 Comment

INVEP-Programmierhandbuch ist fertig (erstmal)

Posted on 5. Juli 2011 by akoppel

Nach einigen Tagen Arbeit ist die erste Version des INVEP-Programmierhandbuches nunmehr fertig. Die Sprachsyntax ist beschrieben und alles wurde nochmals gegengeprüft. Was jetzt natürlich noch fehlt ist das Korrekturlesen (aber das machen andere) sowie möglichst hilfreiche Beispiele einzufügen. Wie das jedoch mit den Beispielen immer so ist, man braucht halt Ideen. Wenn in der nächsten Zeit Anforderungen für Daten-Analysen oder Automatisierungen reinkommen, dann werden wir die ensprechenden Programme exemplarisch dem Handbuch zufügen. Der interessierte Leser kann sich den aktuellen Handbuchentwurf gerne von der INVEP-Internet-Seite laden Man findet das Handbuch im Bereich “Bibliothek -> Kurzhilfen und Dokumentation”. Über Feedback freuen wir uns.

Posted in Programmieren an sich | Tagged | Leave a comment

Neues ist häufig erstmal holprig

Posted on 5. Juli 2011 by akoppel

Bestandteil unseres Produktes INVEP ist eine extrem umfangreiche MS-Office-Anbindung. Das Pogramm ist sozusagen eine Brot- und Butter-Anwendung. Sie wird tagtäglich verwendet und es werden ständig tausende von Dokumenten damit erzeugt, ohne das irgend jemand darüber nachdenken muss, welch unglaublich umfangreiche Logik in solch einem Programm steckt. Im Laufe der letzten 10 Jahre wurde dieses Windows-Programm ständig fortentwickelt und gepflegt, so dass es auch heute noch auf alles PCs und mit allen Office-Versionen funktioniert. Denoch haben wir vor über einem Jahr beschlossen, dieses Programm technologisch auf neue Beine zu stellen, denn die Office-Anbindung ist das einzige Programm in unserem Portfolio, dass auf BASIC basiert. Um in der Zukunft gut gerüstet zu sein, sind wir dabei das gesamte Programm mit neuer Logik sozusagen von Grund auf neu zu entwickeln, diesmal jedoch in der in unserer Firma üblichen Sprache C bzw. C++. Dabei stellt sich heraus, dass man den Aufwand für derartige Neuprogrammierungen niemals zu niedrig ansetzen kann. Es ist wirklich eine immense Leistung, funktionierende Programme technologisch durch Neuentwicklungen zu ersetzen. Bis eine Neuentwicklung auch nur annähernd den Stand erreicht, den das “alte” Programm hat, vergeht immer sehr viel mehr Zeit, als man denkt. Selbst wir als erfahrene Softwareentwickler staunen immer wieder über neu auftretende Probleme, die wir dergestalt im alten Programm gar nicht kannten. Ich kann daher gut verstehen, warum es in der Softwareentwicklung sehr häufig passiert, das selbst uralte Programme einfach nur “neu eingekleidet” werden, um dann als neu verkauft zu werden, statt sie komplett neu zu entwickeln. Die Verlockung ist zweifelsfrei groß, dem gleichzutun, aber das machen wir eben nicht. Es gibt immer wieder Zeiten, wo in den sauren Apfel gebissen werden muss, eine Sache von Grund auf Neu zu machen und dabei alte Strukturen (bzw. alten Code) über Bord zu werfen. So lange wir es schaffen,  dass unsere Kunden von derartigen Neuentwicklungen nicht durch Bugs negativ belästigt zu werden, können wir eigentlich zufrieden sein, denn nichts ist nervtötender als sich anhören zu müssen, dass das tolle neue Programm weniger kann, als das alte etablierte Programm.

 

Posted in Allgemein, Programmieren an sich | Tagged | 1 Comment

Der Kampf mit den Programmen

Posted on 5. Juli 2011 by akoppel

Nun bin ich persönlich schon seit einigen Tagen dabei, das neue Programmiererhandbuch für die in INVEP integrierte Programmiersprache zu schreiben. Die ganze Arbeit betrachte ich irgendwie ambivalent. Einerseits macht so etwas Spaß, andererseits geht natürlich immens viel Zeit dabei drauf, so dass andere Dinge nicht ganz so schnell vorankommen. Glücklicherweise sind die Zeiten des Einzelkämpferdaseins ja schon sehr lange vorbei, so dass zu erledigende Dinge an andere Mitglieder des Teams deligiert werden können. Skuriel ist jedoch, dass ich in unserer Firma schon vor Jahren durchgesetzt habe, dass alle Literatur im Textsatzsystem Latex (nicht zu verwechseln mit dem “Gummimaterial”) geschrieben wird. Das hat immense Vorteile; unter anderem sieht das Layout einfach schöner aus. Tatsächlich schreibe ich jetzt jedoch zum ersten mal irgendendwas in Latex tatsächlich selbst. Was mir dabei gefällt ist, dass die Ergebnisse wirklich überzeugend sind, anstrengend empfinde ich jedoch, dass in Latex eigentlich nicht wirklich geschrieben sondern eher programmiert wird. Wie beim “normalen” Programmieren sucht man dann auch die Fehler im Dokument, wenn das Ergebnis nicht dem entspricht, was man erwartet oder der Latex-Compiler schlicht verweigert, das Dokument wegen syntaktischer Fehler in ein PDF zu verwandeln. Nunja, aller Anfang ist schwer, und schließlich muss ich in der Lage sein, Dinge auch selbst zu machen, die ich ansonsten von anderen erledigen lasse.
Was mich heute jedoch nervt sind die ständigen Abstürze des Latex-System MiTex. Irgendwie mag das System mich heute nicht, vielleicht liegt’s jedoch auch daran (wahrscheinlich sogar), dass ich so schlau war die aktuelle Beta-Version des Systems einzusetzen, statt auf die stabile, jedoch schon etwas ältere Standard-Version zurückzugreifen.
Wie dem auch sein, nachdem ich jetzt mal nachschauen werde, ob’s ein Programmupdate gibt, werde ich mich irgendwie durchkämpfen.

 

Posted in Allgemein | 1 Comment