Winkelfunktionen in der Finanzmathematik

Publiziert am 1. August 2011 von 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.

2013.05.27 Addon
Over two years we have seen that several readers of this blog are non native german.
Possibly such entries are interesting for native english speakers. If this applies to, leave a short message. We may translate such blog entries to english.

Veröffentlicht unter Allgemein, Buchhaltung, Datenanalyse | Verschlagwortet mit | 2 Kommentare

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

Publiziert am 25. Juli 2011 von 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).

Veröffentlicht unter Allgemein, Programmerweiterungen, Programmieren an sich | 1 Kommentar

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

Publiziert am 8. Juli 2011 von 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…

Veröffentlicht unter Programmieren an sich | Verschlagwortet mit | 2 Kommentare

INVEP-Programmierhandbuch ist fertig (erstmal)

Publiziert am 5. Juli 2011 von 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.

Veröffentlicht unter Programmieren an sich | Verschlagwortet mit | Hinterlasse einen Kommentar

Neues ist häufig erstmal holprig

Publiziert am 5. Juli 2011 von 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.

 

Veröffentlicht unter Allgemein, Programmieren an sich | Verschlagwortet mit | 1 Kommentar

Der Kampf mit den Programmen

Publiziert am 5. Juli 2011 von 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.

 

Veröffentlicht unter Allgemein | 1 Kommentar

Handbücher wollen erstellt werden

Publiziert am 28. Juni 2011 von akoppel

Es ist ja fast ein Klassiker, da haben wir mächtigen Funktionen in INVEP eingebaut, und dann muss das ganze auch noch dokumentiert werden. Diesmal betrifft es unsere in INVEP integrierte Programmiersprache OBAS. OBAS ist ein Basic-Dialekt, der als integraler Bestandteil von INVEP extrem weitreichende Automatisierungen ermöglicht. Das haben wir natürlich nicht (nur) für uns eingebaut, sondern wir möchten unseren Kunden die Möglichkeit geben, sich ihr INVEP selbst anzupassen. Das geht natürlich nur, wenn die Möglichkeiten und Funktionen entsprechend gut dokumentiert sind. Also sind wir jetzt dabei das Handbuch zur Automatisierung mit INVEP zu schreiben. Wie üblich, machen wir das mit LaTex, da man solche umfangreichen Anleitungen nicht mit Word schreiben kann.
Die Frage, die sich dabei stellt ist allerdings, wie weit sollen wir überhaupt gehen. sicherlich gehört das eine oder andere Beispiel in die Dokumentation hinein. Insbesondere bei den wissenschaftlichen Funktionen stellt sich jedoch die Frage, ob wir wirklich die mathematischen Formeln die die Grundlage für die Berechnungen bilden, ebenfalls in’s Handbuch schreiben.
Wie dem auch sein, das INVEP-Programmierer-Handbuch wird wieder mal ein sehr umfangreiches Handbuch, da wir auch hier eine maximale Transparenz für den Anwender herstellen wollen.

Veröffentlicht unter Datenanalyse, Programmerweiterungen | Verschlagwortet mit , , | Hinterlasse einen Kommentar

Visualisierung von Arbeitsaufwänden

Publiziert am 16. März 2011 von akoppel

Arbeisaufwand in der Bearbeitung von InslvenzverfahrenIch habe mir mal die Arbeit gemacht, den Aufwand bei der Bearbeitung von Insolvenzverfahren zu visualisieren. Zur erzeugten Grafik kann man ziemlich viel sagen, ich überlasse die Interpretation jedoch dem geneigten Leser.
Die URL für die Mathematica-CDR-Datei ist:
http://www.invep.de/fileadmin/invep/Mathematica/INVEP_Aufwandsauswertungen.cdf
Um diese Datei anzuzeigen, braucht man den kostenlosen Mathematica-Player (von www.wolfram.com) oder eine Mathematica-Version (ab V6).
Viel Spaß beim Interpretieren.
Übrigens hat mein Hexa-Core-I7/960 unter Windows-7/64 rund 8 Stunden für die Berechnung der Grafik benötigt.

Veröffentlicht unter Datenanalyse | Verschlagwortet mit , , | 2 Kommentare

Übernahme von Buchungssätzen aus anderen Buchhaltungen

Publiziert am 3. März 2011 von rthiede

Kernfrage: sollte man Buchungssätze aus anderen Buchhaltungen übernehmen?

Antwort aus der Praxis: Schwierig, deshalb besser nicht….

Warum ist das so? Der Grund liegt darin, dass neben dem reinen Buchungssatz, der im allgemeinen mindestens zwei Konten enthält auch Beträge, ggf. Splitbeträge oder Steuerinformationen, die jede Buchhaltungssoftware anders löst, enthalten sind. In der Definition der Konten, die auch wieder in jeder Buchhaltungslösung anders ist, stecken weitere Verknüpfungen. Diese enormen potentiellen Verknüpfungsmöglichkeiten müssen durch das Import-Programm abgedeckt werden. Somit erklärt sich auch dem Programmierungslaien, dass hier komplexe Anforderungen vorliegen, die manchmal selbst mit Hilfe der Programmierer der anderen Buchhaltung kaum zu lösen sind. Noch schwieriger wird es, wenn diese Hilfe nicht gegeben ist.

Daher wird in der Praxis zu einem Stichtag die Summen- und Saldenliste übernommen und ab diesem Datum in der neuen Buchhaltung (nach-)gebucht. Somit erhält man einen sauberen „Schnitt“.

Veröffentlicht unter Buchhaltung | 1 Kommentar