Die Fondsgesellschaften haben über die Jahre hinweg gelernt, dass die Transparenz der Fonds als ein wichtiger Entscheidungsfaktor für potenzielle Investoren gilt, dessen Wert sogar geschätzt werden kann. Aus diesem Grund stehen die beiden Stakeholder, die Fondsgesellschaft und der Investor, den neuen strengeren Bilanzierungsregeln sowie der Offenlegungspflicht gegenüber den Investoren positiv gegenüber, wenn auch diese zu neuen Anforderungen an das Finanzberichtswesen und damit zu neuem Aufwand führen. Insbesondere müssen jetzt die Jahresberichte die Beherrschungsverhältnisse innerhalb des Fonds korrekt wiedergeben. Sowohl die Bestände und Kontostände als auch die Cashflows und die Performance-Kennzahlen des Fonds müssen die Verhältnisse innerhalb aller Konsolidierungskreise abbilden. Diese Aufgabe der korrekten Abbildung ist besonders für die sogenannten Alternative Investments (AI) komplex. Diese Fonds bestehen oft aus wenig liquiden bis illiquiden Produkten, zum Beispiel gewerblichen Immobilien.
Komplexe Berichte
Fondsgesellschaften mit zahlreichen Niederlassungen in Steueroasen sind bei Hedgefonds im Bereich AI üblich, es werden oft sogenannte Master-Feeder-Konstrukte verwendet. Darüber hinaus wird die Transparenz der Beherrschungsverhältnisse durch das Fehlen eines geregelten Marktes für viele der im Fonds enthaltenen Assets erschwert. Sowohl die Tochtergesellschaften SPV (Special Purpose Vehicle) als auch die Master-Feeder-Beziehungen müssen jedoch in allen relevanten Finanzberichten berücksichtigt werden.
Die Erstellung dieser komplexen Berichte gehört zu den Aufgaben, die die technischen Möglichkeiten und Projektressourcen der Fondsgesellschaften häufig überfordern. Die Depotbank (Custodian) kann daher bei der Erstellung und Anpassung des Berichtswesens auf den aktuellen Stand der Anforderungen eine Schlüsselrolle spielen. Die Depotbank hat in der Regel einen Zugang auf die relevanten Finanzdaten vieler KAGs und sie verfügt über die notwendige Datenbasis sowie Infrastruktur, um das Finanzreporting inklusive komplexer Kennzahlenberechnungen anzubieten.
Die Reporting-Anwendung (Financial Reporting Application - FRA) erstellt vorwiegend Jahresberichte für Investoren und die Bankenaufsicht mithilfe der Fondsbuchhaltungsdaten. Dieses Reporting wird typischerweise von der Depotbank als Service für die Kapitalanlagegesellschaften angeboten. Durch Anbindung zahlreicher neuer Hedgefonds aus AI war der Anlass, die geforderte Konsolidierung innerhalb der FRA zu automatisieren.
Regulatorische Anforderungen
Der Standortwettbewerb zwischen Europa und den USA beschränkt sich nicht nur auf die naheliegenden Themen wie Handelsbeschränkungen, Steuern oder Subventionen. Auch die Rechnungslegungen stehen sich konkurrierend gegenüber. Amerika wirbt mit seinen US-GAAP1), die von der Idee der Vermittlung entscheidungsrelevanter Daten für den Investor getragen werden. Die Eigentümer sollen dabei ein möglichst korrektes Bild der tatsächlichen Vermögenslage bekommen. Deutschland stellt den US-GAAP dagegen die traditionellen Grundsätze ordnungsmäßiger Buchführung gegenüber, die im Handelsgesetzbuch (HGB) kodifiziert sind.
Seit Januar 2005 müssen kapitalmarktorientierte Unternehmen ihre Konzernabschlüsse nach den International Accounting Standards (IAS)/International Financial Reporting Standards (IFRS) erstellen und veröffentlichen. Unter den deutschen Spezialfondsanlegern dürften mittlerweile weit mehr als die Hälfte ihre Konzernabschlüsse IAS/IFRS-konform erstellen, da sie als kapitalmarktorientierte Unternehmen einzustufen sind. Von Spezialfondsinvestoren verlangen die IAS/IFRS eine deutlich aufwendigere Bilanzierung als das HGB.
Das International Accounting Standards Board (IASB) hat mit dem IFRS 10 einen neuen Standard zur Konsolidierung von Unternehmen (Umsetzung ab 2013) herausgegeben. Es legt fest, wann es sich bei Unternehmen nach internationalen Rechnungslegungsvorschriften um Tochterunternehmen handelt und diese damit im Konzernabschluss der Muttergesellschaft zu konsolidieren sind. Künftig ist ein einheitliches Konsolidierungskonzept auf alle Unternehmen gleichermaßen anzuwenden.
Vorliegen einer Beherrschung
Das in IFRS 10 kodifizierte einheitliche Konsolidierungskonzept gründet das Konsolidierungserfordernis ausschließlich auf dem Vorliegen von der sogenannten Beherrschung. Beherrschung liegt gemäß IFRS 10.710 immer dann vor, wenn die folgenden Kriterien kumulativ erfüllt sind:
- der Investor hat Entscheidungsmacht über das potenzielle Tochterunternehmen (power);
- der Investor ist durch seine Verbindung zum potenziellen Tochterunternehmen variablen Rückflüssen ausgesetzt beziehungsweise hat Rechte an diesen Rückflüssen (variable returns);
- der Investor hat die Möglichkeit, seine Entscheidungsmacht über das potenzielle Tochterunternehmen zu nutzen, um die Höhe der variablen Rückflüsse zu beeinflussen (link between power and returns).
Das einheitliche Konsolidierungskonzept schließt auch Zweckgesellschaften ein, für deren Konsolidierung bislang eine eigene Regelung galt. Zusätzlich zu Konsolidierungsvorgaben aus IFRS 10 kommen auf Unternehmen durch die gleichzeitige Veröffentlichung von IFRS 12 "Angaben zu Anteilen an anderen Unternehmen" auch umfangreiche Offenlegungspflichten zu.
Umsetzung: Depotbank als Vermittler
Die internationalen Rechnungslegungsvorschriften stufen Sondervermögen als Special Purpose Entities (Zweckgesellschaften) ein. Diese sind vom Anleger als solche zu konsolidieren, wenn er die wirtschaftliche Kontrolle über das Sondervermögen ausübt. Dies ist gegeben, wenn der Investor die Mehrheit an den Chancen und Risiken des Sondervermögens hält, unabhängig davon, ob es sich um einen Spezial- oder Publikumsfonds handelt. Dabei gibt es keine speziellen Konsolidierungsvorschriften für Investmentfonds, sondern es sind insbesondere die Vorschriften des IAS 32 und IAS 39 auf die Vermögensgegenstände des Fonds anzuwenden.
Auf die Depotbank kommt dabei eine besondere Aufgabe als Vermittler zwischen der KAG und den Investoren zu. Ihre Fondsbuchhaltungssysteme und das Reporting müssen der Empfehlung nach der transparenten Vermögensübersicht für die KAG und der der Investoren nachkommen. Entsprechend den Bilanzierungsregeln müssen konsolidierte Finanzberichte eines Fonds sowohl die Bilanzdaten als auch die operativen Ergebnisse der im Fonds konsolidierten Tochtergesellschaften darstellen. Dies gilt insbesondere für folgende Finanzberichte:
- Einnahme- und Überschussrechnung
- Aktiv-Passiv-Aufstellung
- Vermögensaufstellung
- Ertrags- und Aufwandsrechnung
- Asset Allokation
Die IT-Architektur der Depotbank im Beispielsprojekt unterstützte bislang in der Regel klassische öffentliche Fonds vorwiegend aus dem europäischen Raum, in dem komplexe Beherrschungsverhältnisse eher als Ausnahme gelten. Eine Analyse der neuen Konsolidierungsvorgaben hat klar gezeigt, dass die aktuell verwendete IT-Architektur angepasst werden muss, um den neuen fachlichen Anforderungen gerecht zu werden. Vor allem aber musste die Reporting-Anwendung für die Umsetzung der genannten Anforderungen weitgehend erweitert werden. Die Anforderungen wurden dagegen in mehreren Workshops und Detailanalysen erhoben und abgestimmt, bevor sie in eine IT-konforme Sprache als DV-Konzepte überführt werden konnten.
Die grundlegende architektonische Idee bestand darin, die konsolidierten Daten nicht in Buchhaltungssystemen zu replizieren, sondern zusätzliche Module zu entwickeln, die den Konsolidierungsprozess übernehmen würden. Diese Module sollten die Daten mithilfe standardisierter Schnittstellen zwischen der Fondsbuchhaltung und der Reporting-Anwendung austauschen. Neben dieser Neuentwicklung musste auch das hausinterne Reporting angepasst werden. Die Anwendung, die bisher nur die sogenannten "Stand-alone"-Berichte verarbeiten konnte, sollte nun in der Lage sein, das Datenmodell konsolidierter Fonds zu verstehen. Das Entwicklungsprojekt wurde nach dem Scrum-Ansatz durchgeführt. Die besondere Herausforderung bestand in langsam steigendem Detaillierungsgrad der Anforderungen, der globalen Projektstruktur und einem komplexen Testmanagement.
Erkenntnisse nicht nur auf Spezialfonds beschränkt
Obwohl die Erkenntnisse für die vorliegende Arbeit aus der Betreuung von US-amerikanischen Hedgefonds gewonnen wurden, sind sie nicht nur auf Spezialfonds beschränkt. Sie zeigen, welche Aufgaben aufgrund verschärfter Bilanzierungsregeln auf die Fondsbuchhalter, IT-Designer, Softwareentwickler und Anwendungsbetreuer zukommen.
Reporting-Anwendung: Vor der Umsetzung der Automatisierung wurden die konsolidierten Berichte auf Anforderung und vorwiegend manuell mithilfe von Excel-basierten Tools und Skripten erstellt. Dies war jedoch sehr zeitaufwendig, nicht skalierbar und enthielt kaum zu beseitigende systematische Fehler, etwa bei Rundungsdifferenzen. Die Benutzung hunderter Formeln unter Beachtung der Namenskonventionen überforderte die Berichtsersteller erheblich. Deshalb wurde entschieden, die konsolidierten Berichte aus dem bestehenden Reporting-System zu erstellen, das jedoch vorher erheblich erweitert werden musste. Anhand der abgestimmten Anforderungen wurden zuerst die für Berichtsversorgung notwendigen Daten ermittelt und kategorisiert. Am Anschluss daran musste die Frage nach den relevanten Datenquellen geklärt werden.
Die Analyse hat gezeigt, dass die Geschäftsdaten für das Reporting aus den hauseigenen Buchhaltungssystemen geliefert werden können. Die Lieferung der Daten umfasst: Transaktionsdaten, Kontostände, Kontogruppierungen für Bilanzpositionen, Investoren-Kennzahlen und Stammdaten der Fonds, Wertpapiere und Investoren.
Für die Übertragung der Daten wurden im Beispielprojekt Standardschnittstellen verwendet, die vorwiegend Textdateien bedienen. Darüber hinaus wurden an mehreren Stellen Datenbanklinks eingesetzt. Nach der Datenüberführung erfolgte der Schritt der Datenkonsolidierung, der in Abbildung 1 dargestellt wird.
Die eigentliche Reporting-Anwendung "Financial Reporting Application" (FRA), die als Frontend im Fokus der Architektur steht, besteht aus einer relationalen Datenbank, einem Portal und der hauseigenen Standardsoftware. Die FRA erfüllt mehrere Schlüsselfunktionen: Datawarehouse, BI und Historisierung, Darstellung in der Weboberfläche, Editierbarkeit der Daten in der Weboberfläche, Erstellung der kundenspezifischen Berichtsvorlagen sowie Erstellung der Berichte zum Beispiel als PDF-Dokumente.
In der Abbildung 2 wird die Architektur der Reporting-Anwendung zur Abbildung der Konsolidierung dargestellt. Deutlich erkennbar ist der modulare Aufbau.
Editierbarkeit der Geschäftsdaten
Neben den Transaktionsdaten können auch Wertpapier- und Fondsstammdaten an FRA manuell übertragen werden. Dies ist besonders dann sinnvoll, wenn Änderungen der Daten vorgenommen werden sollten, aber ein automatisierter Batchlauf aus den Buchhaltungssystemen nicht möglich war.
Die Editierbarkeit der Geschäftsdaten ist eine besondere Eigenschaft des Systems. Sie betrifft Berichtskomponenten, die angeliefert werden. Um eine schnelle Anpassung vorzunehmen, die aus diversen Gründen notwendig ist, können Portalnutzer in allen Bereichen einige Felder verändern. Um den gesamten Datenhaushalt abzugleichen, werden die veränderten Geschäftsdaten im Originalformat als Extrakte herausgezogen und an die Quellsysteme zurückgesendet.
Diese konzeptionellen Ansätze haben sich bei der Umsetzung als sehr erfolgreich erwiesen, was unter anderem daran lag, dass die Konsolidierung nicht in FRA durchgeführt werden musste, sondern in den drei Modulen stattfand: Konsolidierungsmodul (CC), Fair Value (FV) und Kennzahlenmodul (FiHi) (siehe Abbildung 1). Die Bestände, Kontostände und Transaktionen fließen über Schnittstellen als Eingangsdaten in den Prozess ein. Die konsolidierenden Module wurden alle mit der gleichen Standardschnittstelle ausgestattet, sodass die Reporting-Anwendung die Daten der konsolidierten Fonds als Textdateien einlesen konnte. Die bestehende Business-Logik in der Schnittstelle wurde deshalb beibe halten und musste auch nicht erweitert werden.
Der modulare Aufbau ermöglicht laufende Anpassungen für verschiedene Kunden, ohne direkt in die Buchhaltungssysteme eingreifen zu müssen. Die dadurch gewonnene Skalierbarkeit der Austauschbarkeit der Module gilt als ein großer Vorteil des Konzepts.
Erleichterte Wartung
Die Daten der konsolidierten "Master Fonds" werden aus den Konsolidierungsmodulen im gleichen Format und in der gleichen Struktur an die Reporting-Anwendung FRA übertragen wie in der bisherigen Lösung für "Stand-alone"-Daten aus der Buchhaltung. Jeder konsolidierte "Master Fonds" wird mit neuen Stammdaten in FRA abgelegt und wird unabhängig von den enthaltenen Einzelfonds sowie von dem nicht konsolidierten Master Fonds behandelt. Dies erleichtert die Wartung der FRA erheblich.
Entwicklungsprojekt: Die Erweiterungen wurden in einem Scrum-Entwicklungsprojekt umgesetzt, wobei der anfängliche Projektinhalt in zwölf sogenannte Sprints aufgeteilt wurde. Nach jedem Sprint fand eine Kundenpräsentation der ausgelieferten Softwaremodule statt. Anschließend wurden die ausgelieferten Funktionalitäten vom Kunden getestet und die gefundenen Defekte wurden generell zu neuen User Stories konzipiert. Noch vor dem Akzeptanz-Test wurden die ersten Systemtests durch das Tester-Team jeweils nach der Fertigstellung einer User Story durchgeführt. Die Ergebnisse dieser Tests wurden durch Business-Analysten verifiziert.
Auch nach jedem Sprint übernahm ein weiteres Tester-Team des Fachbereichs die Verantwortung für den Abnahmetest, dem anschließend der Integrationstest folgte. Diese agile Vorgehensweise stellte sicher, dass Abweichungen und Fehler rechtzeitig entdeckt werden konnten. Während der Projektlaufzeit fanden zusätzlich wöchentlich Integrationstests statt, in denen der Austausch zwischen den Modulen überprüft wurde. Besonders anspruchsvoll war die finale Projektphase, in welcher die Machbarkeitsstudie (Proof of Concept/POC) durchgeführt wurde. In dieser wurden die Berichtsvorlagen durch einen externen Dienstleister erstellt. Die Erstellung der geforderten Berichte aus POC wurde quasi zum finalen Abnahmetest.
Strukturiertes Release-Management als Herausforderung
Eine der Herausforderungen bestand im strukturierten Release-Management. Um eine geordnete Testvorgehensweise zu ermöglichen, musste der Release-Stand aller Module stets überwacht und aneinander abgeglichen werden. Die Besonderheit des Projekts war der Betrieb einer vorproduktiven Umgebung, die zwar den aktuellen Entwicklungsstand aufwies, gleichzeitig diente sie als Entwicklungsplattform für die produktiven Berichte und war deshalb viel strengeren Restriktionen als die übrigen Testumgebungen unterzogen. Hinzu kam noch die geforderte Anonymisierung der kundenspezifischen Daten, sobald diese die echte Produktionsumgebung verlassen haben.
Die Testdurchführung in einer agilen Projektumgebung gilt als besonders herausfordernder Aufgabenbereich eines Projektes. Leider werden aus diesem Grund gelegentlich gewisse methodische und organisatorische Abstriche gemacht, die im Umkehrschluss die Softwarequalität und fehlerfreie Abbildung der fachlichen Vorgaben beeinträchtigen können. Agile Entwicklungsweisen erzwingen generell die Suche nach optimalen Testansätzen, die je nach Projektausprägungen unterschiedlich gewählt werden sollten. Die Testerfahrungen aus dem Beispielprojekt deuteten darauf hin, dass ein Set der Testprinzipien die Testdurchführung erheblich erleichtern konnte. Zu den Grundsätzen des erfolgreichen Testmanagements gehören beispielsweise:
- eine frühzeitige Konzeptionierung der automatisierten und manuellen Testarten,
- zügige Migration der manuell durchgeführten Testfälle in das Portfolio der automatisierten Testfälle. Diese überwachen mithilfe entsprechender Testtools regelmäßig den aktuellen Stand der Software entlang der integrierten Prozessabbildung und verringern neben der Steigerung der Softwarequalität gleichzeitig den Testaufwand (Ressourcen und Testzeit).
- transparente und revisionssichere Releasepolitik und -planung. Sie sind die Voraussetzung für releaseorientierte Systemtests, die den Softwarezustand periodisch einfrieren und produktionsfähige Module in die Produktion übergeben. Dabei unterstützen die agilen Entwicklungsansätze nicht immer eine testfreundliche Releasepolitik. 2)
- rechtzeitige Koordination der produktiven Systemeinführung mit der Planung anderer abteilungsübergeordneter IT-affiner Aktivitäten.3) Ein relativ häufiger Fehler in der Testplanung besteht darin, dass keine Informationen über Updates, Patches und Releaseänderungen der über Schnittstellen angeschlossenen Systeme verfügbar sind/eingeholt werden. Dies kann in einer unbeabsichtigten Verzögerung der Testdurchführung enden.
Testerschulung unterschätzt
Die Nutzung eines Testmanagement-Tools (etwa HPQC, Solution Manager, Mantis) verbessert die Qualität und die Transparenz der Testaktivitäten, insbesondere bei einer größeren Anzahl der Testfälle. Die weit verbreitete und kosteneffizientere Nutzung von Excel-Sheets für das Testmanagement hingegen führt leider kaum zu Transparenz und Flexibilität im Testprozess insbesondere bei größeren Projekten.
Das Thema der Testerschulung wird in Tests komplexerer Systeme gelegentlich unterschätzt. Insbesondere bei mehreren Rollen im System (zum Beispiel Administrator, Editor, Prozessmanager), welche jeweils mit unterschiedlichen Aufgaben (inklusive Systemmasken) ausgestattet sind, sollte die Schulung und Einübung der Aktivitäten früh genug organisiert werden. Der häufigste Fehler in diesem Zusammenhang besteht darin, dass die Kontakte zwischen den Business-Analysen und Testmanagern zu der Fachabteilung, die das System nutzen wird, in der Praxis auf eine geringe Anzahl von Personen (ein bis zwei) eingeengt wird.
Dabei wird unterschwellig angenommen, dass diese zwei Personen das generelle Niveau der Systemkenntnisse widerspiegeln. Beim einem Integrationstest, an dem in der Regel mehrere Mitarbeiter der Abteilung teilnehmen, wird entsprechend festgestellt, dass ihre Kenntnisse leider zu gering sind, um die Tests in der geplanten Qualität entlang der getesteten Prozesse und gemäß der geplanten Zeit durchzuführen.
Eine häufig unterlassene Prüfung der Abschottung der Produktions- von der Testumgebung in der technischen Umgebung des externen Anbieters kann gelegentlich revisionsrelevante erstaunliche Erkenntnisse zutage bringen kann. Dabei sollte speziell die Gefahr überprüft werden, ob Daten aus der Testumwelt des Outsourcers die produktiven Bestände verunreinigen können beziehungsweise ob irgendwelche Interaktion zwischen der Test- und Produktionsumgebung stattfindet (zum Beispiel Rerouting der URL-Zugriffe). Die Depotbanken sind sich dieser revisionsrelevanten Anforderung bewusst und können bei Bedarf Informationen und Beweise für die strikte Trennung zwischen der Test- und Produktionsumgebung liefern.
Im Laufe der Umsetzung spielte ein weiterer Faktor eine wesentliche Rolle und musste als das Hauptrisiko erkannt werden: Performance.
Die Verarbeitung der konsolidierten Daten stellte eine enorme Herausforderung an die Performance der Anwendung. Die Datenextrakte mit Beständen, Kontoständen und Transaktionen enthielten nun weit mehr Datensätze als im Zustand vor dem Projekt. Infolgedessen musste festgestellt werden, dass die Berichtserstellung erheblich länger dauert als bisher. Die Anzahl der offenen Positionenbestände, erhöhte sich beispielsweise für eine bestimmte Berichtsperiode von 1 500 auf 20 000 Datensätze. Die Laufzeiten der Datenbankabfragen stiegen nicht einfach linear, sondern scheinbar potenziell und so erhöhte sich die Laufzeit des Aktiv-Passiv-Berichts von anfangs 30 Minuten auf 17 Stunden. Es wurden daher zahlreiche Maßnahmen eingeleitet, um die Performance zu verbessern. Dazu gehören:
- Optimierung der Datenbankabfragen: Hier erreichte man relativ schnell eine deutliche Verbesserung indem offensichtliche Design-Fehler behoben wurden wie mangelnde oder falsche Indizierung oder wiederholtes Abfragen des gleichen Datenbestandes innerhalb eines SQL-Statements.
- Verbesserungen der internen Spezialfunktionen der Reporting-Anwendung, wie die Anpassung des Summenrundens, um die Inkonsistenzen zu beseitigen.
- Schließlich mussten die Templates angefasst werden. Insbesondere dort, wo mehrfach in einer Vorlage dieselben Daten aufgerufen wurden.
- Es wurden auch typische infrastrukturelle Verbesserungen der eingesetzten Hardware und Standardsoftware vorgenommen.
Erhebliche Senkung der Laufzeiten bei der Berichterstellung
Dank diesen Maßnahmen konnten die Laufzeiten bei der Berichtserstellung erheblich gesenkt werden. Besonders hervorzuheben sind hier einfache Maßnahmen zur Optimierung der Datenbankperformance: Indizierung, Hinweise für den Oracle Optimizer (Hints) sowie Vermeidung wiederholter Abfragen.
Die Hauptbestandteile der Konsolidierungsvorgaben mündeten in mehreren fachlichen Teilbereichen, jeder mit einem eigenen Schwierigkeitsgrad. So wurden die Eigentumsverhältnisse zwischen verschiedener KAGs mithilfe von mehreren Regeln umgesetzt, die zum Teil sehr komplex sind. Speziell erwies sich die Ermittlung des Fair Value mit beiden Hauptvarianten (Marktpreis ermittelbar und Marktpreis nicht ermittelbar) als besonders herausfordernd. Bei der Ermittlung der Key Performance Indicators (vor und nach Gebühren) pro Tranche und Fondsklasse konnten die bestehenden Module entsprechend erweitert werden.
Die fachlichen Überlegungen wurden stets durch die Betrachtung des Datenmodells und der Stammdatenpflege kritisch begleitet, da die Umsetzung vieler Anforderungen auf direktem Wege zu kostspieligen Änderungen des Datenmodells führen würde. Auch einschneidende (vereinfachende) Änderungen in der Stammdatenpflege können neben den positiven Effekten auch Verluste in der Datenqualität und im Normallfall erhebliche Umsetzungs- und Datenpflegekosten generieren. Die Erkenntnisse aus der Projektarbeit lassen sich in wenigen positiven und negativen Punkten zusammenfassen:
Positive Aspekte
- Der modulare Aufbau der Konsolidierungseinheiten reduzierte die Komplexität, verbesserte die Skalierbarkeit und ermöglichte eine relativ unkomplizierte Umsetzung im gegebenen Zeitrahmen, ohne auf neue technologische Lösungen zuzugreifen.
- Die Erkenntnisse aus dem Erweiterungskonzept vereinfachte erheblich die Projektstruktur.
- Durch die Nutzung der bestehenden Komponenten war die Umsetzung verhältnismäßig günstig.
- Die Unstimmigkeiten zwischen den Modulen konnten stets schnell lokalisiert werden.
- Die Anforderungen an die Skills der Entwickler waren klar an die Funktionsweise eines Moduls gekoppelt. Deshalb konnten Teams im Laufe des Projekts öfter erweitert beziehungsweise verkleinert werden, ohne eine nennenswerte Verzögerung zu verursachen.
Negative Aspekte
- Der Austausch der Daten zwischen den Modulen erforderte eine sehr gute Koordination der Projektgruppen. Da sich die Inhalte der Dateien ständig änderten, kam es oft zu Dateninkonsistenzen zwischen den konsolidierenden Modulen und der Reporting-Anwendung. Analysen und Bereinigungsarbeiten führten nicht selten zu Verzögerungen.
- Das Testmanagement spielte eine überdurchschnittliche Rolle. Die notwendigen Integrationstests fanden gelegentlich aus Aufwandsgründen eher unkoordiniert statt, ohne stets alle Stakeholder zu involvieren.
Im Rückblick muss noch angemerkt werden, dass die Datenabstimmung unter den Modulen einen erheblichen Aufwand generierte. Sie wurde zwischen dem Fondsbuchhaltungssystem - Datenquelle, und den finalen Datentabellen im Frontend durchgeführt. Eine erweiterbare Reconciliation-Anwendung fehlte im Anfangsstadium, weshalb die Abstimmung stets manuell durchgeführt werden musste. Nach der Umsetzung der Reconciliation-Anforderungen reduzierte sich der Aufwand der Abstimmung auf ein verträgliches Maß und als Folge entspannte sich auch die Intensität der Projektaufgaben.
Fußnoten
1) "The purpose of consolidated financial statements is to present, primarily for the benefit of the owners and creditors of the parent, the results of operations and the financial position of a parent and all its subsidiaries as if the consolidated group were a single economic entity. There is a presumption that consolidated financial statements are more meaningful than separate financial statements and that they are usually necessary for a fair presentation when one of the entities in the consolidated group directly or indirectly has a controlling financial interest in the other entities." in http://www.fasb.org/cs/BlobServer?blobcol=urldata&blobtable=MungoBlobs&blobkey=id&blobwhere=1175820901468&blobheader=application%2Fpdf
2) "Das Tempo der Entwicklung und der Zwang der Einhaltung terminlicher Ziele machen eine vernünftige Releasepolitik häufig unmöglich. Änderungen in der Software/(-komponenten) werden oftmals nicht dokumentiert und können somit nicht nachvollzogen werden, was wiederum methodisches Testen nahezu unmöglich macht.", Praxistaugliche Testmethodik für agile Systementwicklung am Beispiel eines Treasury Systems, Dietmar Landgraf/Tadeusz Skolka, Zeitschrift für das gesamte Kreditwesen 6-2015, Seite 300.
3) Die Praxis liefert hierzu regelmäßig viele negative Beispiel, so kann zum Beispiel die Planung der Releaseänderung von Betriebssystemen, die mit dem Projekt nicht abgestimmt wird, die Produktivnahme des Systems entsprechend beeinflussen/verzögern, weil die Tests in der neuen Version des Betriebssystems wiederholt werden müssen.
