Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

08.11.1991 - 

Dem europäischen Bilanzrecht angemessen

US-Software lichtet den deutschen Fibu-Dschungel

Modulare Finanzberichts-Systeme nach dem sogenannten General-Ledger-Konzept machen in den Vereinigten Staaten nun bereits in vierter Generation Karriere. Da lokale Finanzbuchhaltungen künftig den EG-Berichtsanforderungen genügen müssen, geht Peter Rump* davon aus, daß diese US-Produkte auch in Europa zum Durchbruch kommen werden. Damit ginge die Ära der lokalen Finanzbuchhaltungen zu Ende.

Ohne Unterlaß werben Deutschlands Softwarehäuser damit, "kommerzielle Standard-Software" zu entwickeln. Das Gütesiegel soll den Tausenden von Programmen, die hiermit gemeint sind, vor allem durch das Wort "Standard" verliehen werden. Dabei war es für Kenner der Branche - und dazu gehören auch viele leidgeprüfte Anwender - noch nie zweifelhaft, daß nur ein geringer Teil der Standard-Pakete auch wirklich einem "Standard" zuzuordnen sind oder gar selbst einen solchen etablieren.

Daß es in puncto Systemoffenheit, Migrationsfähigkeit und Kompatibilität von kommerziellen Standardanwendungen aus deutschen Softwarehäusern nur selten Zukunftsweisendes zu vermelden gibt, läßt sich am eindrucksvollsten im Bereich der Finanzbuchhaltungs-Software (Fibu) aufzeigen. Zahlreiche Softwarehäuser - manche mit weniger als einem halben Dutzend Mitarbeitern - arbeiten an "Standard"-Fibu-Paketen, die zwar den derzeit gültigen deutschen Rechtsvorschriften genügen, jedoch weder im Hinblick auf die zukünftige europäische Rechtsentwicklung noch hinsichtlich internationaler Funktionsanforderungen als "standardisiert" gelten können.

Die Unausgereiftheit hiesiger Fibu-Software wird noch augenfälliger, wenn man an die "Weiterentwicklungen" der Systemprogrammierer in den Unternehmen denkt: Sie sind mit der Anpassung der eingekauften Fibus beschäftigt und müssen diese solange umschreiben, bis die betriebsintern gewachsenen, nichtelektronisierten Buchhaltungs- und Berichtsanforderungen ohne Einschränkungen auf EDV-Ebene abgebildet werden können.

Derartige Customizing-Bestrebungen sind in vielen Fällen sogar durchaus begrüßenswert: Warum auch sollten in einem prosperierenden Unternehmen bestehende Strukturen, auf denen der Erfolg des Hauses basiert, nur deshalb geändert werden, weil sonst die neue Finanzbuchhaltungs-Software nicht funktionieren würde? Aus dieser Überlegung heraus erscheint auch nicht mehr die bloße Tatsache, daß Unternehmen die eingekaufte Finanzsoftware an ihre individuellen Bedürfnisse anpassen wollen, als das eigentliche Problem.

Die wirkliche Brisanz liegt vielmehr im Wie der Anpassung: Denn erst dann, wenn das Customizing als Systemfunktion in die Software integriert ist und sich damit ein systemfremdes Umprogrammieren der Applikationen erübrigt, entwickeln sich "Standard"-Fibus im Anpassungsprozeß nicht unweigerlich zu Insellösungen.

Seit die ersten Fibu-Pakete in den 60er Jahren entwickelt wurden, beantworten Management-Etagen das Ob und Wie der Fibu-Anpassung auf zwei grundsätzlich unterschiedliche Weisen - das allerdings nur hinter vorgehaltener Hand. Die einen glauben ihren Mitarbeitern eine Veränderung althergebrachter Entscheidungs- und Ablaufstrukturen nicht zumuten zu können. Um den "sozialen Frieden" zu wahren, wird an der Software solange herummanipuliert, bis sie sich einigermaßen geräuschlos in die vorhandenen Gegebenheiten einfügt. Damit ist gleichsam die stabilitäts- und sicherheitsfixierte Haltung gekennzeichnet.

Der andere Managertypus hingegen sieht den Einzug von rechnergestützten Finanzbuchhaltungen als Chance, verkrustete Betriebsstrukturen aufzubrechen und effizienzorientierte Umstrukturierungen vornehmen zu können, ohne sich den Widerstand und Unmut großer Teile der Mitarbeiterschaft zuzuziehen. "Erzwungen" werden die Änderungen dann von dem neuen "Standard", den die Software setzt.

Die direkten Folgen beider Vorgehensweisen liegen auf der Hand: Im ersten Fall wird die Software noch stärker unternehmensbezogen individualisiert, das Kompatibilitätsniveau sinkt weiter. Im zweiten Fall bleibt die Programmstruktur zwar weitgehend unbeschadet, dies jedoch auf Kosten von Organisationsveränderungen, die zumindest kurzfristig das Betriebsklima massiv beeinträchtigen und damit hohe unternehmerische Reibungsverluste erzeugen können.

Erste Fibus waren allzu eindimensional

Doch damit nicht genug: Die ersten Fibus, mit denen in den Unternehmen die Elektronisierung des Rechnungswesens eingeleitet wurde, erwiesen sich schon nach wenigen Jahren als allzu eindimensional. Finanzdaten ließen sich nur auf Kontoebene speichern. Zusätzliche Aufschlüsselungen nach Produktgruppen, Kostenstellen, Regionen, Projekten etc. waren nicht verfügbar. Innerhalb der Finanz- und Anlagenbuchhaltung wurden lediglich die geforderten Berichte im Rahmen der Steuergesetzgebung des landesspezifischen Berichtswesens produziert.

Der zunehmenden Anforderung, detaillierte Berichtsstrukturen zu entwickeln, konnten diese frühen Buchhaltungsprogramme damit nicht genügen. Ihr Mangel an individuellen Auswertungen führte dazu, daß bis heute - je nach eingesetztem Datenbankmanagement-System - zahlreiche universell einsetzbare Reporting-Tools wie Culrit, FMS der Easy Trive verwendet werden müssen, um die herkömmlichen Fibus zu brauchbaren Finanzberichts-Systemen auszubauen.

Ihre Architektur führt allerdings oftmals dazu, daß reportfähige Daten redundant gespeichert werden müssen und nur durch periodische Extrahierungszyklen aktualisiert werden können. Deshalb zeigen Ad-hoc-Abfragen und bedarfsorientierte Berichte zumeist auch lediglich den Aktualitätsstatus des letzten Extraktionsdatums - in der Regel das vergangene Monatsende.

Neue Ansätze aus dem angloamerikanischen Raum

Zumindest in den DV-Abteilungen der Großunternehmen waren über lange Jahre genügend Programmier-Ressourcen verfügbar, um Entwicklungen im Bereich Kostenrechnung und Finanzberichtswesen inhouse durchführen zu können. Doch vor allem im Bereich der Kostenrechnung vermochten die Module, auf deren Basis Inhouse-Entwicklungen stattfanden, schon bald nicht mehr den steigenden Anforderungen an die Qualität der Analysedaten zu genügen.

Zunehmend setzte sich in den Management-Etagen die Erkenntnis durch, daß langfristige strategische Unternehmensplanung nicht mehr mit herkömmlicher Kostenrechnung erfolgen konnte, sondern moderner Verfahren der Investitions- und Finanzrechnung bedurfte. Vor allem im angloamerikanischen Raum wurden diesbezüglich zahlreiche neue Ansätze wie Target-costing, Activity-based-costing (a-b-c), Benchmarking sowie verschiedene Profit-Center-Konzepte entwickelt.

All diese Konzepte haben eines gemeinsam: Sie sind in den ursprünglichen Kostenrechnungs-Programmen nicht abbildbar. Sie ergänzen das traditionelle Berufsbild des Kostenrechners durch vielfältige Controlling-Funktionen zur Unterstützung und Kontrolle der strategischen Unternehmensplanung.

Mit der Entscheidung für Inhouse-Programmierungen sind zudem unter der Hand auch deren Folgeprobleme absehbar: Die Eigenentwicklungen erweisen sich nämlich in dem Maße, in dem sie grundsätzlich auf einen alten Software-"Kern" aufbauen, als zunehmend technologisch rückständig. Darüber hinaus wird das DV-Berichtswesen durch jahrelange Inhouse-Entwicklungen derart unternehmensspezifisch individualisiert, daß Datentransfers und Berichtsabgleiche in multinational tätigen und vielfach untergliederten Unternehmenskomplexen nur noch durch Mehrfacherfassung der Berichtsdaten zu leisten sind.

Die Probleme wachsen durch die zwischenstaatlichen Bestrebungen, eine Vereinheitlichung der Buchführungsrichtlinien im Hinblick auf den europäischen Binnenmarkt zu erreichen. Die vierte und siebte Richtlinie der EG-Kommission haben hier eindeutige Maßstäbe gesetzt. Sie sind mittlerweile auch in Form des neu geschaffenen dritten Buches des Handelsgesetzbuches (HGB) und geänderter Bilanzrichtlinien in die deutsche Gesetzgebung eingegangen.

Insbesondere für Aktiengesellschaften und GmbHs haben sich dadurch zahlreiche fiskalisch bindende Berichtsanforderungen neu ergeben, die in ihrer Tendenz die Berichtsanforderungen des "General Ledger"-Konzeptes (GL) der angloamerikanischen Staaten widerspiegeln. Eine bedeutsam Neuerung ist dabei vor allem der Bilanz-Anhang, der den im angloamerikanischen Recht erforderlichen "Notes to the Financial Statements" entspricht und insbesondere folgenden Vorschriften genügen muß:

- Aufgliederung der Umsatzerlöse nach Tätigkeitsbereichen sowie nach geografisch bestimmten Märkten;

- Angabe der stillen Reserven, die sich durch Abschreibungen nach steuerlichen Vorschriften oder durch das Unterlassen der Wertaufholung ergeben;

- Angabe der Unterschiedbeträge bei Anwendung der Gruppen- oder Durchschnittsbewertung oder eines Verbrauchs-Folgeverfahrens gegenüber dem Börsen- oder Marktwert des Bilanzstichtages.

Internationale Buchhaltungsprinzipien

Für Konzernabschlüsse ist neu, daß nun generell das Weltabschlußprinzip sowie der Grundsatz der einheitlichen Bewertung gilt. Der Konsolidierungskreis umfaßt nicht mehr nur die inländischen Unternehmen, sondern auch die ausländischen. Da auch die ausländischen Unternehmen mitkonsolidiert werden, mußte das Prinzip der Maßgeblichkeit des Einzelabschlusses aufgegeben werden. Für sämtliche, in den Konzernabschluß einbezogenen Abschlüsse sind nunmehr die für das Mutterunternehmen relevanten Bewertungsmethoden einheitlich anzuwenden.

Im übrigen fällt bei den Methoden der Kapitalkonsolidierung die bisherige deutsche Methode ersatzlos weg. Bindend ist jetzt die angelsächsische Methode, wodurch sich vor allem Änderungen in Gestalt der Konsolidierung bei Interessenzusammenführung, der Quotenkonsolidierung und der Equity-Methode für die assoziierten Unternehmen ergeben.

Angesichts der neuen Gesetze und Regularien sind die deutschen Unternehmen mit Blick auf den Europäischen Binnenmarkt gezwungen, die international gebräuchlichen Buchhaltungsphilosophien zu integrieren. Das wird nicht einfach sein: Die eigenentwickelten oder lokalen Fibu-Pakete sind oftmals so rückständig, daß eine Implementierung neuer Bilanzierungs- und Berichtsformen systemsprengende Eingriffe erfordern würde.

Hinzu kommt, daß die eingeführten Buchhaltungsprogramme meistens nur auf speziellen Hardware- und Betriebssystem-Plattformen lauffähig sind, die mit heterogenen Installationen in ausländische Niederlassungen, Tochterunternehmen oder Joint-venture-Firmen kaum verbunden werden können.

Die Entwicklung der europäischen Richtlinien im Finanzberichtswesen könnte vor allem den US-Anbietern von "General Ledger"-Softwarepaketen verbesserte Marktzugangschancen eröffnen. Im Gegensatz zur deutschen, "horizontalen" Ablauforganisation im Finanzbereich sind die Organisationsstrukturen von US-Firmen "vertikal" in den Bereichen Controlling, Kosten- und Kontoanalyse angesiedelt. Dementsprechend haben die US-Softwarehäuser das General Ledger als zielorientiertes Berichtswesen an die Spitze ihrer Informationshierarchien gesetzt. Die GL-Hierarchien werden auf operativer Ebene durch die sogenannten Nebenbücher, die in nebeneinander liegenden, separaten Modulen vorliegen, mit journalisierten Informationen versorgt. Die Nebenbücher sind über Batch-Schnittstellen mit dem General Ledger verbunden und stellen den Buchungsstoff in Form von Journalen zur Verfügung.

Das GL bietet neben den traditionellen Funktionen einer Sachkontenbuchhaltung die Möglichkeit der Kosten- und Erlösumlage, verwaltet Planzahlen im Rahmen der Budgetierungsfunktion und erlaubt die Konsolidierung einzelner Unternehmensbereiche und Mandanten.

Jeder Teilbereich der operationalen Ebene (Kreditoren, Debitoren etc.) kann durch ein Einzelpaket abgedeckt werden, das als Komponente die offene Integration anderer Softwaremodule in Form eines Clusters erlaubt. Auch Eigenentwicklungen und Pakete von Drittanbietern können auf diese Weise integriert werden - ein Aspekt, der besonders von Banken und Versicherungen geschätzt wird, da sowohl Front- und Back-office-Systeme beziehungsweise Policenverwaltung und Fakturierungssysteme einfach in das GL integriert werden können.

Im GL selbst werden sämtliche Informationen aus allen Funktionsbereichen auf unterschiedlichen Verdichtungsebenen gespeichert. Diese sind vom Benutzer definiert und vom Kontierungs- beziehungsweise Buchungsschlüssel abhängig. Der komplette Datenbestand ist ebenfalls unter Enduser-Kontrolle und kann im Rahmen von Reporting- oder Abfrage-Tools angezeigt werden.

Inzwischen hat bereits die vierte Generation von GL-Software-Paketen Marktreife erlangt. Diese modularen Finanzberichts-Systeme präsentieren sich als "Standard"-Lösungen, die erstmals Standards nicht zu Lasten von Kompatibilität oder betriebswirtschaftlicher Effizienz setzen. Hierzu stellen sie ein universell einsetzbares, generelles Finanzbuchhaltungs-Konzept bereit, das je nach individuellen Unternehmensbedürfnissen ausgefüllt wird ohne daß dabei die Grundstrukturen umprogrammiert würden.

Die GLs der 4. Generation erlauben eine sehr flexible Kontokodierung, durch die der Benutzer in die Lage versetzt wird, ein breites Spektrum von Datenelementen für die spätere Informationsaufbereitungs-Analyse bereitzustellen. Dabei werden die Daten entsprechend eines Mehrbuchkonzeptes in unterschiedlich perspektivierter Weise als Finanz- und Statistikdaten gespeichert und können dann in verschiedensten Kombinationen und Verdichtungen zur Erstellung von Einzelberichten oder mehreren Berichtszyklen genutzt werden.

Akzeptanz-Probleme für deutsche SW-Häuser

Dies schließt ein, daß Daten über eine flexible Schnittstellen-Anbindung aus Logistik- sowie Produktionsplanungs- und -steuerungssystemen eingespielt und dann mehrdimensional ausgewertet werden. Wichtig dabei ist, daß im GL neben der Verwaltung aktueller, finanzbuchhalterischer Werte gleichermaßen Planzahlen, Budgets und statistische Werte vorgehalten werden.

Solange deutsche Finanzbuchhaltungssysteme keine potentiell unbegrenzten Analysemöglichkeiten in Abhängigkeit von den organisatorischen Unternehmensstrukturen bieten, können echte Profit-Center-Konzepte in hiesigen Großunternehmen nicht verwirklicht werden. Da die lokalen Fibus den EG-Berichtsanforderungen nur unzureichend genügen und in internationalen Netzen eine Inselrolle einnehmen, müssen viele deutsche Softwarehäuser bei ihren Buchhaltungs-Paketen mit wachsenden Akzeptanz-Problemen rechnen.

Dies wird den amerikanischen Softwarehäusern mit ihren General-Ledger-Konzepten nicht automatisch zugute kommen: Erst wenn sie den deutschen Buchhaltern und Finanz- Managern zu zeigen vermögen, wie sich ihre Philosophie des "Financial Information Centre" unterm Strich rechnet, wird sich der deutsche Fibu-Dschungel lichten.