Anforderungen an einen DV-gestützten

Controlling-Arbeitsplatz

 

 

 

 

 

 

Diplomarbeit

 

 

 

 

 

 

eingereicht bei

 

 

 

 

 

 

Lehrstuhl für Wirtschaftsinformatik

Entwicklung betrieblicher Informationssysteme

Prof. Dr. Andreas Oberweis

Fachbereich Wirtschaftswissenschaften

Johann Wolfgang Goethe-Universität

Frankfurt am Main

 

 

 

 

von

 

 

 

 

Jörg Denfeld

Alt Seulberg 76a

61381 Friedrichsdorf

Tel.: 06172/13244

e-mail: denfeld@stud.uni-frankfurt.de

Matrikel-Nr.: 1109324

10. Fachsemester

 

Inhaltsverzeichnis

 

Abbildungsverzeichnis

1 Einleitung

1.1 Problemstellung

1.2 Vorgehensweise

2 Charakterisierung der zur Anwendung kommenden Controlling-Konzeption

2.1 Begriffsdefinition

2.2 Aufgaben und Methoden

2.3 Informationsbedarf

2.4 Anforderungen an die DV-Unterstützung

2.4.1 Betriebswirtschaftliche Anforderungen

2.4.2 Informationstechnische Anforderungen

2.5 Die Kostenrechnung als wichtiges operatives System für das Controlling

2.5.1 Bedeutung der Kostenrechnung für das Controlling

2.5.2 Relative Einzelkosten- und Deckungsbeitragsrechnung (REDR)

2.5.3 Der General Ledger-Ansatz

2.5.4 Beurteilung

3 Das Data Warehouse-Konzept

3.1 Einführung und Begriffsdefinition

3.2 Komponenten

3.2.1 Die Datenbasis

3.2.2 Transformationsprogramme

3.2.3 Archivierungssystem

3.2.4 Metadatenbanksystem

3.3 Organisationsformen

3.4 Auswertung des Datenbestandes

3.4.1 Data Warehouse und OLAP

3.4.2 Star- und Snowflake Schema

3.4.3 Data Mining

3.5 Nutzenpotentiale

4 Controlling auf Basis eines Data Warehouse

4.1 Die Datenbasis des Data Warehouse als Grundlage für das Controlling

4.2 Auswertungsmöglichkeiten

4.3 Präsentationsmöglichkeiten

4.4 DV-Unterstützung für die Controlling-Aufgaben

4.4.1 Planung

4.4.1.1 Strategische Unternehmensplanung

4.4.1.2 Operative Ergebnisplanung

4.4.2 Kontrolle

4.4.2.1 Automatische Top-down-Navigation

4.4.2.2 Bottom-up-Analyse

4.4.3 Koordination

4.4.3.1 Budgetierung

4.4.3.2 Pretiale Lenkung

4.4.3.3 Interessenkonflikte und Koordination

4.4.4 Systemgestaltende Aufgaben des Controlling

4.5 Integration der Kostenrechnung

5 Zusammenfassung

Literaturverzeichnis

 

Abbildungsverzeichnis

 

Abbildung 1: Gliederung des Führungssystems der Unternehmung

Abbildung 2: Entscheidungsdimension und Verdichtungsgrad.

Abbildung 3: Komponenten eines Data Warehouse

Abbildung 4: Zentrales Data Warehouse mit zentralem

DV-Bereich

Abbildung 5: Zentrales Data Warehouse auf Basis verteilter

operativer Systeme

Abbildung 6: Dezentrales Data Warehouse

Abbildung 7: Star Schema

Abbildung 8: Snowflake Schema

Abbildung 9: Ablauf der strategischen Planung

Abbildung 10: Ablauf der Top-down-Navigation

Abbildung 11: Datenmustererkennung in der Ergebnisrechnung

Abbildung 12: Gründe für einen Koordinationsbedarf

Abbildung 13: Integration der Kostenrechnung in das Data

Warehouse-Konzept

 

1 Einleitung

1.1 Problemstellung

Die heutigen Märkte sind geprägt durch eine hohe Dynamik und einen harten globalen Wettbewerb. Vor diesem Hintergrund der umkämpften und dynamischen Märkte hat die Komplexität des unternehmerischen Planen und Handelns stark zugenommen. Dies erfordert von Unternehmen schnelle und flexible Reaktionen auf Änderungen der Rahmenbedingungen. Dadurch hat auch die Bedeutung der Information und der Informationssysteme im Unternehmen zugenommen. Information ist zu einem wichtigen Wettbewerbsfaktor geworden. Eine gute Informationsversorgung im Unternehmen kann zu Wettbewerbsvorteilen gegenüber Konkurrenten führen.

Für die Informationsversorgung der Unternehmensführung trägt das Controlling die Hauptverantwortung. Der Controller hat die Aufgabe, alle relevanten Informationen zur Steuerung des Unternehmens der Unternehmensleitung bedarfsgerecht zur Verfügung zu stellen. Dabei ist die typische Ausgangssituation im Unternehmen dadurch gekennzeichnet, daß die notwendigen Daten in der Regel im Überfluß verfügbar sind. Das Problem besteht jedoch in einer entscheidungsorientierten Selektion, Verknüpfung und Aufbereitung der Daten, so daß sie den Anforderungen des Managements gerecht werden.

Ein neuer Lösungsansatz, um die Datenflut im Unternehmen zu beherrschen, ist das Data Warehouse-Konzept. Das Data Warehouse dient als zentrales Datenlager des Unternehmens. In ihm werden die Daten aus den operativen Systemen des Unternehmens sowie aus externen Informationsquellen gesammelt und aufbereitet. Die Daten im Data Warehouse sollen so für dispositive, strategische Zwecke genutzt werden. Das Data Warehouse kann zu einem Wettbewerbsvorteil führen, da durch die Konsolidierung, Transformation und Integration operativer Daten, eine konsistente Sicht eines Unternehmens generiert wird. Es wird so eine Verbesserung der Produktivität der Entscheidungsträger im Unternehmen erreicht.

 

 

1.2 Vorgehensweise

Das Ziel dieser Arbeit ist die Überprüfung der Eignung des Data Warehouse-Konzepts für die DV-Unterstützung des Controlling. Zu Beginn der Arbeit wird der Begriff des Controlling präzisiert. Nach einer allgemeinen Begriffsdefinition folgt die Beschreibung der Aufgaben des Controlling. Es werden dann Methoden benannt, die zur Lösung dieser Aufgaben herangezogen werden können. Im folgenden wird aus den Aufgaben des Controlling der Informationsbedarf des Controllers hergeleitet. Um diesen Informationsbedarf zu befriedigen, muß das Controlling durch die Datenverarbeitung unterstützt werden. Die Anforderungen an die DV-Unterstützung des Controlling werden deshalb im darauffolgenden Abschnitt beschrieben. Hierbei wird eine Unterscheidung in betriebswirtschaftliche und informationstechnische Anforderungen getroffen. Abschnitt 2 endet mit der Beschreibung zweier Ansätze zur Gestaltung der Kostenrechnung, der relativen Einzelkosten- und Deckungsbeitragsrechnung sowie des General Ledger-Ansatzes.

In Abschnitt 3 wird das Data Warehouse-Konzept vorgestellt. Es ist ein möglicher Ansatz, um die Anforderungen des Controlling an die DV-Unterstützung zu erfüllen. Zunächst erfolgt hierbei eine allgemeine Darstellung des Konzepts. Danach werden die Komponenten des Data Warehouse genauer beschrieben und mögliche Organisationsformen des Data Warehouse dargestellt. Weiterhin wird auf Methoden zur Auswertung des Datenbestandes eingegangen. Es werden das OnLine Analytical Processing und das Data Mining vorgestellt. Abschnitt 3 schließt mit der Darstellung von möglichen Nutzenpotentialen des Data Warehouse-Konzepts.

Der Schwerpunkt der Arbeit liegt in Abschnitt 4. Hier wird untersucht, inwieweit das Data Warehouse-Konzept ein geeigneter Ansatz für die DV-Unterstützung des Controlling ist. Zu diesem Zweck werden die in Abschnitt 2 formulierten Anforderungen den in Abschnitt 3 beschriebenen Eigenschaften des Data Warehouse gegenübergestellt. Zu Beginn wird untersucht, welche Controlling-Anforderungen die Datenbasis des Data Warehouse erfüllt. Danach werden die Auswertungs- und Präsentationsmöglichkeiten, die im Rahmen des Data Warehouse-Konzept bereitstehen, den diesbezüglichen Anforderungen des Controlling gegenübergestellt. Nach dieser allgemeinen Darstellung wird analysiert, welchen Beitrag das Data Warehouse zur Erfüllung der Controlling-Aufgaben leistet. Hierbei werden für die Aufgabenfelder Planung, Kontrolle und Koordination Lösungsmöglichkeiten für Teilbereiche dieser Aufgabenfelder aufgezeigt. Im Bereich der Planung werden die Aspekte der strategischen Unternehmensplanung und der operativen Ergebnisplanung dargestellt. Für den Bereich der Kontrolle werden Unterstützungsmöglichkeiten der Abweichungsanalyse vorgestellt. Im Rahmen der Koordination werden die Budgetierung und das Konzept der pretialen Lenkung in Hinblick auf DV-Unterstützungsmöglichkeiten untersucht. Zudem wird beschrieben, welchen Beitrag das Controlling bei der Ausgestaltung des Data Warehouse leisten muß.

Die Arbeit schließt mit einer Zusammenfassung der Ergebnisse und einer Beurteilung der Einsatzmöglichkeiten des Data Warehouse für das Controlling.

 

2 Charakterisierung der zur Anwendung kommenden Controlling-Konzeption

2.1 Begriffsdefinition

Am Anfang dieser Arbeit soll zunächst der Begriff "Controlling" inhaltlich beschrieben und abgegrenzt werden. Ausgangspunkt ist die koordinationsorienierte Controlling-Konzeption. Hierbei versteht man unter Controlling die Koordination des Führungsgesamtsystems zur Sicherstellung einer zielgerichteten Lenkung.

Abbildung 1 zeigt die Bestandteile des Führungssystems.

entnommen aus Küpper S.15 Abb. I-7

Abbildung 1: Gliederung des Führungssystems der Unternehmung

Dabei soll das Controlling drei Funktionen erfüllen:

 

  1. Anpassungs- und Innovationsfunktion
  2. Zielausrichtungsfunktion
  3. Servicefunktion

 

Unter der Anpassungs- und Innovationsfunktion ist die Koordination der Unternehmensführung mit ihrer Umwelt zu verstehen. Die Zielausrichtungsfunktion gibt die Ziele vor, die mit der Koordination verfolgt werden sollen. Die Servicefunktion soll für die Bereitstellung geeigneter Methoden und Informationen über zweckmäßige Verfahren sorgen, um eine Koordination der Führungsteilsysteme zu erreichen.

Bei dieser Konzeption steht die Koordinationsaufgabe im Vordergrund. Diese Begriffsdefinition ist jedoch für den Rahmen dieser Arbeit zu eng gefaßt, denn in der Praxis hat der Controller nicht nur Koordinationsaufgaben, sondern auch die Aufgabe Planung und Kontrolle durchzuführen, und gerade dies soll durch eine geeignete DV-Konzeption unterstützt werden. Dabei ist unter Kontrolle eine spezifische Funktion im Führungsprozeß zu verstehen. Die Kontrolle stellt bestimmte Sollgrößen den tatsächlich realisierten Größen gegenüber. Die Differenz wird als Abweichung bezeichnet. Planung bedeutet, daß zukünftige Aktionen im voraus aufeinander abgestimmt werden. Dazu ist die abgestimmte Festlegung mehrerer voneinander abhängiger Entscheidungsvariablen nötig. Eine Durchführung von Planung und Kontrolle bedeutet eine Erweiterung der Servicefunktion des Controllings gegenüber der koordinationsorientierten Konzeption. Grundsätzlich dient das Controlling dann zur Erfüllung von zwei Aufgabenklassen:

  1. Systemgestaltende Aufgaben,
  2. Systemnutzende Aufgaben.

Die systemgestaltenden Aufgaben umfassen alle Tätigkeiten, die zur Schaffung und Betreuung einer Infrastruktur zur Informationsversorgung bei Planung, Kontrolle und Koordination dienen. Die systemnutzenden Aufgaben verwenden die Informationen aus der vom Controlling gestalteten Infrastruktur, um Koordination, Planung und Kontrolle durchzuführen.

Somit kann Controlling als die systematische Informationsbeschaffung und Informationsverarbeitung zur Koordination, Planung und Kontrolle für eine zielbezogene Steuerung des Unternehmens angesehen werden. Es ist eine rechnungswesen- und vorsystemgestützte Systematik zur Verbesserung der Entscheidungsqualität auf allen Führungsstufen des Unternehmens.

 

2.2 Aufgaben und Methoden

Um die sehr allgemeine Definition des Controlling zu veranschaulichen, werden im folgenden die Hauptaufgaben und Methoden des Controlling kurz beschrieben. Darauf aufbauend wird der Informationsbedarf des Controllers hergeleitet.

Zu den Hauptaufgaben zählen:

 

 

Dabei wird unter Planung die Festlegung mehrerer voneinander abhängiger Entscheidungsvariablen verstanden. Kontrolle ist der Vergleich von tatsächlich realisierten Größen mit Sollgrößen, die durch die Planung festgelegt wurden. Unter Koordination ist die Abstimmung der Führungsteilsysteme zu verstehen. Schließlich muß das Controlling, um diese Aufgaben erfüllen zu können, auch die richtigen Informationen bereitstellen.

Methoden, die für die Planung verwendet werden, sind u.a. sukzessive Planabstimmung und simultane Planungsmodelle. Bei der sukzessiven Planabstimmung werden die Einzelpläne der Unternehmensbereiche stufenweise aufeinander abgestimmt. Simultane Planungsmodelle dagegen erfassen Interdependenzen bereits bei der Planerstellung in den einzelnen Bereichen. Für die Kontrolle bieten sich die Abweichungsanalyse und verschiedene Überwachungsinstrumente an. Zu den Überwachungsinstrumenten zählen beispielsweise die Revision und die Zertifizierung. Für die bereichsübergreifende Koordination kommen besonders Budgetierungssysteme, Kennzahlen- und Zielsysteme sowie Verrechnungs- und Lenkpreissysteme in Frage. Ein Kennzahlen- und Zielsystem stellt alle Kennzahlen und Ziele sowie deren Beziehungen untereinander dar. Zur Unterstützung der Informationsaufgabe kommen Berichtssysteme, die Investitionsrechnung, die Kosten- und Erlösrechnung, die Informationsbedarfsanalyse sowie integrierte Systeme der Erfolgsrechnung zum Einsatz.

Diese Aufzählung, die keinesfalls den Anspruch auf Vollständigkeit erhebt, zeigt, daß die Aufgaben des Controlling sowohl auf operativer, taktischer als auch auf strategischer Ebene angesiedelt sind. Daraus ergibt sich ein sehr heterogener Informationsbedarf. Dieser entsteht dadurch, daß je nach Entscheidungssituation der Entscheidungsträger Information aus unterschiedlichen Quellen, in unterschiedlichen Verdichtungsgraden benötigt. Im folgenden Abschnitt wird der Informationsbedarf genauer untersucht.

 

2.3 Informationsbedarf

Zur Heterogenität des Informationsbedarfs, der auf die vielfältigen Aufgaben des Controlling zurückzuführen ist, kommt hinzu, daß die Komplexität des unternehmerischen Planens und Handelns, aufgrund umkämpfter und dynamischer Märkte immer weiter zunimmt, und damit der Informationsbedarf weiter ansteigt. Diese Entwicklung ist unter anderem auf die zunehmende Globalisierung des Wettbewerbs zurückzuführen.

Information dient im operativen Bereich als vierter Produktionsfaktor und kann auf strategischer Ebene zum Wettbewerbsfaktor werden, wenn es gelingt, eine aktuelle, konzentrierte, aber dennoch umfassende Informationsversorgung zu gewährleisten. Eine zeitnahe Informationsbereitstellung über alle wichtigen Erfolgssteuerungsgrößen ist die Grundvoraussetzung, um auf negative oder ungewollte Entwicklungen im Unternehmen rechtzeitig und angemessen reagieren zu können. Dabei liegt das Problem nicht darin, Daten zu finden bzw. zu generieren. Die vielfältigen operativen Systeme in den Unternehmen liefern eine riesige Menge von Daten. Es besteht eher das Problem, die steigende Datenflut sinnvoll zu nutzen. Also die richtige Information, zur richtigen Zeit am richtigen Ort zur Verfügung zu stellen.

Um dieses Problem zu lösen, bedarf es eines effektiven Informationsmanagements, bei dem zunächst der Informationsbedarf ermittelt und Informationspfade festgelegt werden müssen. Dabei bezeichnet ein Informationspfad die horizontale und vertikale Verteilung der anzusprechenden Informationssysteme. Durch einen Informationspfad wird also beschrieben, wie die Datenquellen auf den unterschiedlichen Unternehmensebenen verteilt sind. Unter horizontaler Verteilung ist die Anordnung der Datenquellen auf einer Hierarchieebene des Unternehmens zu verstehen, während der vertikalen Verteilung eine Betrachtung entlang der Unternehmenshierarchie zugrunde liegt.

Der Informationsbedarf für das Controlling besteht nicht nur aus internen Unternehmensdaten, auch externe Daten spielen eine immer größere Rolle. Auf der operativen Ebene werden Daten aus allen operativen Systemen des Unternehmens benötigt, um die Kontrollaufgaben erfüllen zu können. Diese operativen Daten sind jedoch für Entscheidungen auf taktischer bzw. strategischer Ebene unzureichend. Um hier gute Entscheidungen treffen zu können, muß das Controlling im Rahmen seiner Informationsaufgabe auch Informationen über erfolgskritische Kennzahlen, Kundenverhalten, Markttrends und Wettbewerber bereitstellen. Auch für die Planungs- und Koordinationsaufgaben müssen externe Datenquellen miteinbezogen werden. Zudem müssen die Daten aus den operativen Systemen so verdichtet und weiterverarbeitet werden, daß sie den Entscheidungsträgern einen möglichst guten Gesamtüberblick verschaffen.

Zusammenfassend läßt sich feststellen, daß die für ein umfassendes Controlling nötigen Informationen aus verschiedenen internen und externen Datenbeständen beschafft werden müssen. Außerdem sollten die Daten in verschiedenen Verdichtungsgraden vorliegen, um so für die unterschiedlichen Entscheidungsdimensionen (von strategisch bis operativ) eine geeignete Informationsbasis zu bilden. Abbildung 2 zeigt den Verdichtungsgrad der Daten für verschiedene Entscheidungsdimensionen.

entnommen aus Reichmann, S.153, Abb. 1.

Abbildung 2: Entscheidungsdimension und Verdichtungsgrad.

Aus dem so charakterisierten Informationsbedarf können nun Anforderungen an eine geeignete DV-Unterstützung des Controlling formuliert werden.

 

2.4 Anforderungen an die DV-Unterstützung

2.4.1 Betriebswirtschaftliche Anforderungen

Aus den Aufgaben und dem Informationsbedarf ergeben sich betriebswirtschaftliche Anforderungen für eine DV-Unterstützung des Controlling. Zum einen ergeben sich Anforderungen an die Datenbasis. Sie sollte folgende Eigenschaften erfüllen:

Die Verfügbarkeit eines integrierten Datenbestandes ist erforderlich, weil das Zusammensuchen aus den unterschiedlichen, heterogenen Datenquellen einen zu hohen Aufwand verursacht. Außerdem ist nur so ein schneller und flexibler Zugriff auf die Daten möglich. Multidimensionale Sichten auf den Datenbestand erlauben eine Analyse aus unterschiedlichen Perspektiven und erleichtern betriebswirtschaftliche ad hoc Abfragen. Die Aktualität des Datenbestandes ist erforderlich, um eine zeitnahe Berichterstattung zu gewährleisten. Unterschiedliche Verdichtungsebenen werden benötigt, um den unterschiedlichen Informationsbedürfnissen der Nutzer zu entsprechen.

Die betriebswirtschaftlichen Anforderungen betreffen aber nicht nur die Datenbasis, sondern auch das betriebliche Berichtswesen. Es sollte deshalb eine individuelle Gestaltung von Berichten, aber auch die Vorgabe von Standardberichten möglich sein. Zur individuellen Gestaltung des Berichtswesens gehört auch ein Dialogberichtswesen mit Drill-Down-Möglichkeiten, um so auf detaillierte Datenbestände schnell zugreifen zu können. Ein Berichtssystem sollte nach folgenden Grundsätzen aufgebaut werden:

Die Entscheidungsorientiertheit des Berichtssystems führt dazu, daß das Berichtssystem nur solche Informationen liefert, die auch benötigt werden. Um organisationskonform zu sein, muß ein Berichtssystem Leistungs- und Ergebnisverantwortung den richtigen Organisationseinheiten zuordnen. Dies ermöglicht Management by Objectives. Strategiekonform ist ein Berichtssystem, wenn es Instrumente besitzt, die den Grad der Verwirklichung strategischer Ziele darstellen können. Abschließend muß ein geeigneter Kompromiß zwischen der Verfügbarkeit von Berichten und deren Genauigkeit gefunden werden, wobei hier auf die Verfügbarkeit besonders geachtet werden sollte.

Neben dem Berichtswesen gibt es noch weitere Auswertungsmethoden, die in eine DV-Unterstützung des Controlling miteinbezogen werden sollten. Folgende Möglichkeiten sollten hier geboten werden:

Zeitreihenanalysen generieren automatisch abhängige Planwerte. Die Eingabe von Grenzwerten erleichtert die Kontrollfunktion mit Hilfe von color coding. Auch die Warnfunktion dient zur Unterstützung von Abweichungsanalysen (siehe auch color coding). Die Simulation auf Basis von Standardberichten erleichtert Planung und Prognose von Absatzzahlen, Gewinn, etc..

Neben den Auswertungsmöglichkeiten sollte die DV-Unterstützung auch für ausgereifte Präsentationsmöglichkeiten sorgen. Dadurch werden Ergebnisse anschaulich und leicht verständlich. Zudem sollte ein System benutzerfreundlich gestaltet sein. Es wird so eine leichte Erlernbarkeit und eine vereinfachte Dateneingabe erreicht. Eine automatische Konsolidierung dezentraler Ergebnisse ist ebenfalls eine wünschenswerte Eigenschaft. Als letzte betriebswirtschaftliche Anforderung an die DV-Unterstützung des Controllings ist die Integration der Kostenrechnung zu nennen, auf die in Abschnitt 2.5 noch näher eingegangen wird.

 

2.4.2 Informationstechnische Anforderungen

Die betriebswirtschaftlichen Anforderungen führen dann zu Anforderungen an die informationstechnische Umsetzung. Hier kann zwischen Anforderungen an die allgemeine Architektur, an die Datenbank, die Auswertungswerkzeuge und die Präsentation unterschieden werden.

Die Architektur sollte sich durch Änderungsflexibilität und Ausbaufähigkeit auszeichnen, um eine schnelle Reaktion auf geänderte Strukturen und Abläufe sowie auf steigende Anwenderzahlen möglich zu machen. Zudem sollten leistungsfähige Schnittstellen für den Datenimport und Datenexport bereitgestellt werden. Damit wird die Integrität der Daten sichergestellt und eine flexible Nutzung der Daten gewährleistet. Eine Client-Server-Architektur ist eine weitere Möglichkeit, um einen effektiven und schnellen Informationszugriff zu gewährleisten.

An die Datenbank werden folgende Anforderungen gestellt:

Ein adäquates Datenmodell ist nötig, um zu einer korrekten Abbildung der betrieblichen Zusammenhänge zu gelangen. Ein Datenbankmanagementsystem verwaltet nicht nur die Daten, sondern sorgt mit einem zuverlässigen Sicherheits- und Zugriffskonzept auch für die Konsistenz des Datenbestandes. Eine Datenbank ist dann konsistent, wenn sie den Regeln und Restriktionen des abgebildeten Realitätsausschnitts entspricht. Durch den Entwurf von Datenbankabfragen und der Auslagerung eines Teils der Datenbank können Antwortzeiten minimiert werden.

Für die Auswertung der Daten sollten Berichtsgeneratoren zur Verfügung stehen. Diese dienen dazu, Berichte und Kennzahlen möglichst einfach in standardisierter oder individueller Form zu erzeugen. Zudem sollte zur Unterstützung der Berichterstattung ein Formelgenerator bereitgestellt werden. Die Existenz einer Methodenbank ist für die Auswertung ebenfalls sehr hilfreich. Eine Methodenbank ist analog zu einer Datenbank eine Sammlung von Methoden und Benutzungshilfen für diese Methoden.

Die Präsentation sollte durch ausgereifte Grafikfunktionen unterstützt werden, um so die Verständlichkeit der Ergebnisse zu erhöhen. Eine grafische Benutzeroberfläche erhöht zudem die Benutzerfreundlichkeit.

 

2.5 Die Kostenrechnung als wichtiges operatives System für das Controlling

2.5.1 Bedeutung der Kostenrechnung für das Controlling

In den vorangegangenen Abschnitten wurden die Aufgaben des Controlling beschrieben. Dieser Abschnitt beschäftigt sich mit der Kosten- und Leistungsrechnung. Die Kosten- und Leistungsrechnung ist der zentrale Datenlieferant des Controlling, weil transparente und plausible Kosten- und Leistungsinformationen eine zentrale Voraussetzung für ein erfolgreiches Controlling sind. Die Kosten und Leistungsinformationen sind insbesondere notwendig für operative Planung und Kontrolle.

Die Kosten- und Leistungsrechnung bezeichnet eine Menge von Rechnungsverfahren, die für einen bestimmten Leistungserstellungskomplex und einen bestimmten zeitlichen Horizont Werteverzehr und Werteentstehung unter definierten Wertbemessungshypothesen erfassen. Das Problem der Ausgestaltung der Kosten- und Leistungsrechnung liegt darin, daß Vereinfachungen und Annahmen gemacht werden müssen, um die komplexen Zusammenhänge im Unternehmen mit vertretbarem Aufwand darstellen zu können. Somit ist die Kosten- und Leistungsrechnung eine spezifische Lösung des Problems des optimalen Komplexionsgrades eines Entscheidungsmodells.

Um Kosten und Leistungen zu ermitteln, kommen Kostenrechnungssysteme zum Einsatz. Kostenrechnungssysteme sind konkrete Lösungen des Problems des optimalen Komplexionsgrades über die Ausgestaltung der Kostenrechnung. Hierunter fallen beispielsweise die in der Praxis weitverbreitete Grenzplankostenrechnung, die Prozeßkostenrechnung sowie die relative Einzelkosten- und Deckungsbeitragsrechnung.

Die Anforderungen an solche Kostenrechnungssysteme steigen durch eine hohe Unternehmensdynamik. Die Kosten- und Leistungsrechnung muß dann eine Vielzahl von Auswertungsmöglichkeiten zulassen. Ihre Komplexität darf aber nicht so groß werden, daß eine flexible Anpassung nicht mehr oder nur unter erheblichem Aufwand möglich ist. Die Komplexität der Kosten- und Leistungsrechnung besteht zum einen darin, wie detailliert Zahlungen erfaßt werden, zum anderen wie kompliziert die Verfahren zur Ermittlung der Kosten und Leistungen sind. Zu diesen Verfahren zählen die Kostenschlüsselung, die Trennung von fixen und variablen Kosten usw.. Um eine dynamikadäquate Kostenrechnung zu erhalten, sollte sie sich aus einer wenig differenzierten Basisrechnung und relativ unabhängig voneinander existierenden Kostenrechnungen für bestimmte Informationsbedürfnisse im Unternehmen zusammensetzen. Diese Trennung von Grundrechnung und Auswertungsrechnungen geht auf Schmalenbach zurück. Sie ist insbesondere in Verbindung mit Datenbanken eine sinnvolle Vorgehensweise. Eine Datenbank kann nämlich die Daten einer Grundrechnung so verwalten, daß sie für vielfältige Auswertungen genutzt werden können. Dies bedeutet, daß die durch ein Datenbankmanagementsystem erreichte Datenunabhängigkeit für die Abbildung der Grundrechnung genutzt wird. Die Datenbank stellt dann die Daten in Form der Grundrechnung zweckneutral dar. Es können verschiedene Auswertungen auf diesen Datenbestand erfolgen, zum Beispiel durch das Anlegen von Benutzersichten.

Im folgenden werden nun zwei Ansätze dargestellt, die auf einer Trennung zwischen Grundrechnung und Auswertungsrechnungen basieren und unter dem besonderen Gesichtspunkt der DV-Unterstützung der Kostenrechnung konzipiert wurden. Es handelt sich zum einen um die von Riebel entwickelte relative Einzelkosten- und Deckungsbeitragsrechnung. Sie ist in wesentlichen Elementen in der Standardanwendungssoftware R/2 und R/3 von SAP enthalten.

Zum anderen wird das Konzept des General Ledgers vorgestellt. Es wird in den angelsächsischen Ländern als zentrales Rechnungswesensystem eingesetzt. Dieses Konzept liegt dem Rechnungswesen-Modul von Oracle Applications zugrunde.

 

2.5.2 Relative Einzelkosten- und Deckungsbeitragsrechnung (REDR)

Das Ziel der REDR ist eine Selektion der relevanten Daten für eine konkrete Entscheidungssituation aus einem zweckneutralen Datenbestand. Die REDR ist für die Unterstützung sämtlicher betrieblicher Entscheidungen konzipiert. In der REDR sind Entscheidungen als die eigentlichen Erfolgsquellen des Unternehmens anzusehen. Um Entscheidungen monetäre Konsequenzen zuzurechnen, benötigt man Bezugsobjekte. Bezugsobjekte können Produkteinheiten, Fertigungsaufträge, Bestellvorgänge usw. sein. Zwischen Entscheidungen und Bezugsobjekten besteht eine enge Beziehung, da Entscheidungen zur Entstehung oder Vernichtung bestimmter Bezugsobjekte führen. Bei der Ermittlung von Kosten und Erlösen wird vom Identitätsprinzip ausgegangen. Dieses besagt, daß Kosten und Erlöse auf die Entscheidungen zurückzuführen sind, von denen sie ausgelöst wurden. Es läßt sich dann eine entscheidungsbezogene Hierarchie von Bezugsgrößen erstellen. Auf der untersten Ebenen stehen hier in der Regel die Produktionsmengen der Kostenträger.

Die REDR beruht auf der Trennung von Grundrechnung und Auswertungsrechnungen. Die Grundrechnung ist eine vieldimensionale Beschreibung von Bewegungsdaten. Sie gliedert sich in die Grundrechnung der Kosten, Erlöse und Potentiale auf. Diese Grundrechnungen stellen Datenspeicher dar. Sie sollen für alle denkbaren Auswertungen entscheidungsrelevante Informationen bereitstellen und können daher als zweckneutral bezeichnet werden. Die Zweckneutralität bedeutet, daß verschiedene Wertansätze parallel in der Grundrechnung gehalten werden müssen, und neben den Werten auch die Mengen in der Grundrechnung mitzuführen sind. So kann die Bewertung in die Auswertung verlagert werden. Die Grundrechnung der Kosten ist eine kombinierte Kostenarten-, Kostenstellen- und Kostenträgerrechnung. Die Kosten sind nach den Bezugsgrößen und nach weiteren Merkmalen gegliedert. Die Grundrechnung der Erlöse gliedert die Erlöse, Erlösschmälerungen und Erlösberichtigungen nach den für die Planung und Kontrolle des Absatzes relevanten Merkmalen. Die Grundrechnung der Potentiale bildet die betrieblichen Kapazitäten und deren Beanspruchung durch die einzelnen Entscheidungsvariablen ab.

Bei der Erfassung der Daten werden Mengen, Zeiten, Kosten und Erlöse mit allen Merkmalen versehen, die für die verschiedenen Auswertungen benötigt werden. Für die unterschiedlichen Rechnungsziele sind jeweils eigene Auswertungsrechnungen vorzunehmen. Diese Auswertungen werden dadurch erleichtert, daß aus den verschiedenen Gruppierungsmöglichkeiten der Bezugsgrößen unterschiedliche Einblicke in die Kosten- und Erlösstruktur des Unternehmens möglich sind.

 

2.5.3 Der General Ledger-Ansatz

Der General Ledger ist mit dem deutschen Hauptbuch zu vergleichen. Im Hauptbuch werden alle Geschäftsvorfälle nach sachlichen systematischen Gesichtspunkten aufgezeichnet. Im Gegensatz zum Hauptbuch zeichnet sich der General Ledger durch einen höheren Informationsgehalt aus. Der Hauptunterschied zum deutschen Hauptbuch ist, daß eine Abspaltung von Kreditoren und Debitoren in Nebenbüchern stattfindet. Zudem werden die unterschiedlichsten Auswertungen durch detailliertere Informationen ermöglicht. Zu diesen detaillierteren Informationen gehören auch die für die Kostenrechnung erforderlichen Mengenangaben. Hinzu kommt noch, daß eine Trennung zwischen externem und internem Rechnungswesen in der für den deutschsprachigen Raum bekannten Form nicht erfolgt. Der General Ledger-Ansatz verfolgt ein generisches Konzept. Die Grundlage des Konzepts ist eine relativ einfache Basisstruktur, die vielfältig angepaßt werden kann. Hier können Buchungspositionen mit beliebigen Informationselementen ausgestattet werden. Diese Ausgestaltung entspricht dem Gedanken einer Grundrechnung, auf die dann die unterschiedlichen Auswertungen erfolgen können.

Durch den General Ledger können benötigte Objektypen, wie zum Beispiel Kostenstellen oder Kostenarten, anwenderbezogen frei definiert werden. Und es wird die Möglichkeit geboten, das System an den Wertefluß der Unternehmung anzupassen. Hinzu kommt, daß das System flexibel ist und schnell neue Anforderungen erfüllen kann. Durch die Flexibilität des Systems ist eine Anpassung an lokale Besonderheiten in internationalen Konzernen möglich, ohne dabei die Konsolidierung der lokalen Einheiten zu erschweren.

 

2.5.4 Beurteilung

Beide Systeme, der General Ledger-Ansatz und die REDR, bieten durch ihre Konzeption einen hohen Grad an Flexibilität bezüglich der Auswertung der Kosten- und Leistungsinformationen. Zusätzlich ermöglichen sie eine flexible Anpassung der Kosten- und Leistungsrechnung. Beide Konzepte sind eigentlich Meta-Modelle für Kostenrechnungssysteme. Ihr Abstraktionsgrad liegt eine Stufe über dem der "gängigen" Kostenrechnungssysteme, wie zum Beispiel der Grenzplankostenrechnung. Auf Basis der REDR oder des General Ledgers können verschiedene Kostenrechnungssysteme, wie z.B. die Grenzplankostenrechnung oder die Prozeßkostenrechnung verwirklicht werden. Es besteht sogar die Möglichkeit unterschiedliche Rechnungssysteme parallel zu nutzen. Dies erfordert allerdings eine detaillierte Datenerfassung. Um also die vielfältigen Auswertungsrechnungen nutzen zu können, müssen zahlreiche Einzelmerkmale der Daten aufgenommen und gespeichert werden. Hierdurch entstehen jedoch nicht geringe Kosten, die nur zu rechtfertigen sind, wenn die Flexibilität des Systems auch tatsächlich in Anspruch genommen wird.

Die große Flexibilität bei der Auswertung der Kosten- und Leistungsinformationen wird allerdings durch eine hohe Komplexität des Kostenrechnungssystems erkauft. Zwar gehören Anpassbarkeit und Ausbaufähigkeit zu den positiven Eigenschaften der REDR und des General Ledger-Ansatzes. Jedoch muß die Frage gestellt werden, ob Anpassungen auch mit einem vertretbaren Aufwand durchgeführt werden können. Die hohe Komplexität der Systeme erhöht den Aufwand auf jeden Fall.

Zusammenfassend kann festgestellt werden, daß durch eine Trennung von Grundrechnung und Auswertungsrechnung eine hohe Flexibilität bezüglich der Auswertung von Kosten- und Leistungsinformationen erreicht werden kann. Hierbei kommt dem Einsatz von Datenbanken eine wesentliche Bedeutung zu. Datenbanken bieten die Möglichkeit, die erforderlich Datenbasis zu verwalten. Zudem unterstützen Datenbankmanagementsysteme eine flexible Auswertbarkeit der Daten. Hier sei insbesondere auf die Möglichkeit von OLAP-Auswertungen hingewiesen, auf die in Abschnitt 3 noch näher eingegangen wird. Die flexible Auswertbarkeit der Daten führt jedoch zu einem erhöhten Aufwand. Zum einen ist die Datenerfassung umfangreicher und detaillierter, zum anderen ist die Verwaltung des Kostenrechnungssystems aufwendiger. Ob die dadurch entstehenden Kosten zu akzeptieren sind, hängt vom Nutzen der erweiterten Auswertungsmöglichkeiten für das einzelne Unternehmen ab.

 

3 Das Data Warehouse-Konzept

3.1 Einführung und Begriffsdefinition

In den meisten Unternehmen existieren heute eine Vielzahl von operativen DV-Systemen. Hierzu gehören Systeme zur Lohnbuchhaltung, zur Produktionsplanung und -steuerung, zur Lagerhaltung und zur Kostenrechnung. Hinzu kommen noch Kunden- und Lieferantendatenbanken. Diese Vielzahl von operativen Systemen in einem Unternehmen bringt Probleme mit sich. Besonders für die Managementunterstützung stellen die operativen Systeme keine geeignete Datenbasis dar. Ist zum Beispiel ein Kunde auch gleichzeitig Lieferant, wird aber in der Kunden- und in der Lieferantendatenbank mit unterschiedlichem Namen geführt, führt dies dazu, daß nicht erkannt werden kann, ob von einem Unternehmen mehr gekauft oder mehr an das Unternehmen verkauft wird. Zudem bilden die Daten in den operativen Systemen den Betrieb funktionsspezifisch ab. Zum Beispiel wird durch das Lagerhaltungssystem die Lagerhaltung abgebildet. Für die Lösung von Managementaufgaben ist eine objekt- oder themenbezogene Betrachtungsweise sinnvoll. Von Interesse ist hier nicht die Abbildung eines Funktionsbereichs, sondern die Information über bestimmte Unternehmensobjekte. Eine typische Fragestellung ist, welcher Gewinn mit einem bestimmten Produkt, in einer bestimmten Region mit verschiedenen Kundengruppen im letzten Jahr erzielt wurde. Diese Fragestellung kann nur gelöst werden, wenn Daten aus verschiedenen operativen Systemen zusammengeführt werden. Diese Synthese muß so erfolgen, daß verschiedene Formate der gleichen Datenfelder in den operativen Systemen vereinheitlicht werden. Zudem muß die Datendarstellung sich auf den späteren Verwendungszweck beziehen und daher objekt- oder themenbezogen sein. Da die Auswertungen sich nicht nur auf aktuelle Daten beziehen, müssen auch historische Daten gespeichert werden. Um solchen Anforderungen gerecht zu werden, wurde das Data Warehouse-Konzept entwickelt.

Ein Data Warehouse ist eine Sammlung von subjekt-orientierten, integrierten, nicht-volatilen und zeitorientierten Daten zur Unterstützung von Managemententscheidungen. Das Data Warehouse-Konzept beruht auf einer strikten Trennung zwischen operativen und entscheidungsunterstützenden Daten und Systemen.

Unter der Subjektorientierung der Daten eines Data Warehouse ist zu verstehen, daß die Daten themenorientiert oder aufgabenbezogen zusammengeführt werden. Ziel ist es, unternehmensbestimmende Sachverhalte aus Managementsicht darzustellen. Ein integrierter Datenbestand bedeutet, die Struktur- und Formatvereinheitlichung der Daten aus den operativen Systemen, um so eine konsistente Datenbasis im Data Warehouse zu erhalten. Dabei ist unter Konsistenz zu verstehen, das mögliche Inkonsistenzen im Datenbestand, die durch die Datenhaltung in verschiedenen operativen Systemen entstanden sind, im Data Warehouse beseitigt werden. Dies bedeutet, daß der Datenbestand konsistent ist, wenn er den Regeln und Restriktrionen, die für den abgebildeten Realitätsausschnitt gelten, entspricht. Die Nicht-Volatilität der Daten bedeutet, daß die im Data Warehouse gespeicherten Daten nach der fehlerfreien Übernahme aus den operativen Systemen und gegebenenfalls notwendigen Korrekturen in der Regel nicht mehr geändert werden. Dies führt dazu, daß alle erstellten Auswertungen und Analysen reproduzierbar sind, insofern die Daten nicht im Laufe der Zeit gelöscht bzw. verdichtet wurden. Die Zeitorientierung der Daten bedeutet, daß den Daten aus den operativen Systemen Zeitmarken hinzugefügt werden. So können auf Basis der Daten Auswertungen durchgeführt werden, die Informationen über die Entwicklung des Unternehmens zur Erkennung von Trends liefern. Der abgebildete Zeithorizont kann in einem Data Warehouse je nach betrieblichen Anforderungen bis zu zehn Jahre betragen. Darunter ist zu verstehen, daß die Daten über einen Zeitraum von zehn Jahren im Data Warehouse aufbewahrt werden.

Das Data Warehouse-Konzept ermöglicht folglich eine durchgängige, konsistente und Endbenutzer-orientierte Bereitstellung von Informationen für computergestützte Managementunterstützungssysteme.

 

3.2 Komponenten

Ein Data Warehouse besteht aus der eigentlichen Datenbasis, geeigneten Transformationsprogrammen, die die Daten aus den operativen Systemen in das Data Warehouse überführen, einem Archivierungssystem und einem Metadatenbanksystem. Abbildung 3 zeigt den Aufbau eines idealtypischen Data Warehouse.

angelehnt an Mucksch S.91

Abbildung 3: Komponenten eines Data Warehouse

Die einzelnen Komponenten werden im folgenden näher beschrieben.

 

3.2.1 Die Datenbasis

Die Datenbasis ist der Kern des Data Warehouse. Sie enthält aktuelle und historische Daten und Informationen aus allen betroffenen Unternehmensbereichen in unterschiedlichen Verdichtungsstufen. Die Daten des Data Warehouse sind aus den operativen DV-Systemen des Unternehmens ausgegliedert.

Eine Ausgliederung der Daten aus dem Bereich der operativen Systeme verursacht einen erhöhten Aufwand. Der vermehrte Aufwand entsteht insbesondere dadurch, daß eine weitere Datenbank betrieben werden muß. Neben den Hardwarekosten erhöht sich auch der Personalaufwand, da das Data Warehouse gepflegt und verwaltet werden muß. Es sprechen jedoch folgende Gründe für eine Ausgliederung:

Die unterschiedlichen Verwendungszwecke erklären sich dadurch, daß die operativen Systeme auf eine möglichst effiziente Verarbeitung des Tagesgeschäftes ausgerichtet sind. Hier muß eine hohe Zahl von Transaktionen auf wenige Datensätze erfolgen, während bei den entscheidungsunterstützenden Systemen der Schwerpunkt auf der effizienten Verarbeitung einer hohen Zahl von Datensätzen und einer flexiblen Anpassung an den heterogenen Informationsbedarf der Entscheidungsträger liegt. Der Unterschiedlichkeit der Datenstrukturen liegt zugrunde, daß die Datenstrukturen operativer Systeme an den betriebswirtschaftlichen Abläufen und Funktionen orientiert sind. Im Data Warehouse dagegen ist eine Ausrichtung an den für das Management interessanten Objekten erforderlich. In operativen Systemen ist die Systembelastung regelmäßig, während sie bei entscheidungsunterstützenden Systemen eher unregelmäßig ist. Erfolgt nun keine Trennung zwischen operativem und entscheidungsunterstützendem System, kann dies zu Überlastung der Systeme und zu verlängerten Antwortzeiten führen.

 

 

 

 

Bei der Gestaltung der Datenbasis sind folgende Aspekte zu berücksichtigen:

Unter Granularität wird der Detaillierungsgrad der Daten verstanden. Eine niedrige Granularität liegt vor, wenn die Daten sehr detailliert vorliegen. Mit steigendem Verdichtungsgrad steigt auch die Granularität. Die Granularität wirkt sich auf die Verarbeitungsgeschwindigkeit von Datenbankanfragen, den benötigten Speicherplatz und die Flexibilität des Data Warehouse aus. In einem Data Warehouse sollte eine mehrstufige Granularität vorliegen, um so einen Kompromiß zwischen betriebswirtschaftlichen und technischen Anforderungen zu erzielen. Aus technischer Sicht sollte die Granularität hoch sein, um Speicherplatz zu sparen und Antwortzeiten zu verringern. Die Antwortzeiten werden kürzer, weil weniger Daten verarbeitet werden müssen. Dagegen sollte aus betriebswirtschaftlicher Sicht die Granularität gering sein, damit detaillierte Auswertungen und Analysen durchgeführt werden können. Eine mehrstufige Granularität kann erreicht werden, indem der Verdichtungsgrad der Daten mit zunehmendem Alter erhöht wird. Es werden dabei aktuelle Daten sehr detailliert zur Verfügung gestellt, während ältere detaillierte Daten archiviert werden und dem Endbenutzer nur noch in verdichteter Form online zur Verfügung gestellt werden. Zur Erreichung der mehrstufigen Granularität wird die rollende Summierung verwendet. Hierbei werden Tagesdaten am Ende der Woche verdichtet, am Ende des Monats werden dann die Wochendaten wiederum verdichtet usw.. Die Zeitintervalle und Verdichtungsstufen sind hierbei nach unternehmensindividuellen Anforderungen festzulegen.

Bei der Partitionierung wird der gesamte Datenbestand des Data Warehouse in mehrere kleine, physisch selbständige Teile mit redundanzfreien Datenbeständen aufgeteilt. Datenbestände sind dann redundanzfrei, wenn die Schnittmenge zweier oder mehrerer Datenbestände leer ist. Es wird dadurch eine Vereinfachung in bezug auf Restrukturierung, Reorganisation, Datensicherung und Monitoring der Datenbestände erreicht. Dies ist jedoch mit einem erhöhten Aufwand bei der Erstellung des Datenmodells, der Übernahme von Daten aus den operativen Systemen und der Durchführung von Auswertungen, die auf Daten verschiedener Partitionen zugreifen, verbunden. Dieser erhöhte Aufwand ist darauf zurückzuführen, daß die Verwaltung eines partitionierten Datenbestandes wesentlich komplexer ist, da nicht nur die Daten innerhalb einer Partition konsistent zu halten sind, sondern auch Wechselwirkungen zwischen den Partitionen zu berücksichtigen sind. Neben der Partitionierung aus DV-technischer Sicht kann die Partitionierung auch aus betrieblicher Sicht vorgenommen werden. Eine Unterscheidung erfolgt hierbei zwischen horizontaler und vertikaler Partitionierung. Bei horizontaler Aufteilung werden die Daten auf verschiedene Tochter- und das Mutterunternehmen oder auf verschiedene Zeiträume aufgeteilt. Die Datenstrukturen der Partitionen sind hier identisch. Bei der vertikalen Partitionierung werden die Daten nach Sachverhalten oder Unternehmensbereichen untergliedert. Die Partitionierung ist als Verteilung der Daten auf der Mikroebene der Datenbank anzusehen. Im Gegensatz zu einer verteilten Datenbank, sind die Daten hier nicht zwangsläufig geographisch verteilt.

Bei der Modellierung der Daten für das Data Warehouse ist nicht nur auf deren Granularität und physische Partitionierung zu achten, sondern es müssen auch Performancegesichtspunkte berücksichtigt werden. Durch die Denormalisierung wird eine Reduktion der Datenbankzugriffe, die im Rahmen einer Auswertung und Analyse anfallen, angestrebt. Damit wird eine Entlastung der verwendeten Hard- und Software und eine Verbesserung des Antwortzeitverhaltens erreicht. Durch die Denormalisierung ergeben sich Redundanzen im Datenbestand. Diese Redundanzen erfordern einen höheren Aufwand, die Integrität und Konsistenz der Datenbasis herzustellen, als dies in normalisierten Datenbeständen der Fall ist.

Die Denormalisierung kann auf verschiedene Weisen erfolgen, führt aber immer dazu, daß die Relationen des Data Warehouse nicht mehr in dritter oder einer höheren Normalform vorliegen. Eine Möglichkeit der Denormalisierung ist das physische Zusammenlegen von Relationen, so daß die Zugriffe auf die Datenbank minimiert werden. Die Minimierung der Zugriffe tritt deshalb ein, weil nun keine einzelne Datensätze gelesen oder geschrieben werden, sondern auf ganze Datenblöcke, bestehend aus mehreren Datensätzen, zugegriffen wird. Eine andere Möglichkeit der Denormalisierung besteht darin, redundante Daten zuzulassen. Hiermit wird erreicht, daß die benötigten Datenbankzugriffe, um eine Information zu erhalten, reduziert werden. Außerdem können Relationen weiter aufspalten werden, wenn innerhalb der Relation Attribute enthalten sind, für die stark divergierende Zugriffswahrscheinlichkeiten gelten. Die Aufteilung der Relationen kann dann so erfolgen, daß eine Relation nur Attribute mit hoher Zugriffswahrscheinlichkeit für eine bestimmte Abfrage enthält. Damit ist es möglich, mit einem Datenbankzugriff eine größere Zahl von Datensätzen zu erfassen als bei einer nicht aufgespaltenen Relation. Dies führt zu einer Verminderung der Datenbankzugriffe. Darüber hinaus bietet sich die Möglichkeit an, ein "kreatives" Profil anzulegen. Dies ist eine Zusammenstellung von den Endbenutzer interessierenden Daten. Im Unterschied zu einer Benutzersicht im Relationenmodell wird die Zusammenstellung der Daten auch physisch gespeichert.

 

3.2.2 Transformationsprogramme

Transformationsprogramme dienen zur Übernahme von unternehmensinternen und -externen Daten. Die Transformationsprogramme stellen die einzige Schnittstelle des Data Warehouse zu den operativen Systemen und den unternehmensexternen Datenquellen dar. Sie müssen folgenden Funktionsumfang besitzen:

Bei der Datengewinnung zum Aufbau der Datenbasis des Data Warehouse muß zwischen der Gewinnung unternehmensinterner und -externer Daten unterschieden werden. Die unternehmensinternen Daten werden aus den operativen DV-Systemen des Unternehmens gewonnen. Die Übernahme der Daten aus den operativen Systemen in das Data Warehouse beansprucht die DV-technischen Ressourcen sehr stark, deshalb sollte auf ein effizientes Übernahmeverfahren geachtet werden. Eine Möglichkeit der Datenübernahme besteht darin, nur Datensätze aus den operativen Systemen zu übernehmen, deren Zeitmarke jünger als das Datum der letzten Datenübernahme in das Data Warehouse ist. Hierzu müssen die Datensätze bei Änderungen von den Anwendungsprogrammen mit Zeitmarken versehen werden. Eine weitere Alternative lautet, alle Änderungen der operativen Datenbestände in einer separaten Datei zu protokollieren. Diese Datensätze werden im Rahmen der Datenübernahme verarbeitet und nach deren Abschluß gelöscht. Analog zu diesem Verfahren ist es möglich, auch das Revisions- oder Logfile der operativen Datenbanken anstatt der separaten Datei zu verwenden. Das Logfile dient dazu, alle Änderungen auf den Datenbestand zu protokollieren, um im Falle eines Systemfehlers, die Datenbank wieder in einen konsistenten Zustand versetzen zu können. Das Logfile enthält jedoch mehr Informationen, als für eine Datenübernahme in das Data Warehouse erforderlich sind. Damit erfordert die Datenübernahme auf Basis des Logfiles mehr Zeit und Ressourcen, als dies bei der Datenübernahme auf Basis einer separaten Datei der Fall wäre. Weiter besteht die Möglichkeit, nach jeder Datenübernahme den Inhalt der operativen Datenbank in einer Before-Image-Datei zu sichern und vor der nächsten Datenübernahme den Inhalt in einer After-Image-Datei zu sichern. Dann werden Before- und After-Image-Datei sequentiell verglichen und die Änderungen in das Data Warehouse überführt. Nach erfolgter Übernahme wird die After-Image-Datei zur Before-Image-Datei. Dieses Verfahren ist jedoch sehr aufwendig und sollte nur zur Anwendung kommen, wenn die anderen beschriebenen Verfahren nicht genutzt werden können.

Unternehmensexterne Daten sind für viele Auswertungen und Analysen wichtig, da erst ein Vergleich zwischen unternehmensinternen und -externen Daten zu aussagekräftigen Ergebnissen führt. Unternehmensexterne Daten liegen in unterschiedlichster Form als Zahlen, Texte, Bilder, Ton- und Videosequenzen vor. Insbesondere die letztgenannten Daten lassen sich nur schwer in ein Datenbanksystem integrieren. Daher werden sie in Abhängigkeit ihrer Nutzungshäufigkeit in digitalisierter Form als separates Dokument im Data Warehouse gespeichert, oder in ihre ursprünglichen Form belassen und in Archiven abgelegt.

 

3.2.3 Archivierungssystem

Das Archivierungssystem deckt die Bereiche Datensicherung und Datenarchivierung ab. Die Datensicherung dient dazu, das Data Warehouse im Falle eines System- oder Programmfehlers wiederherzustellen, d.h. in einen konsistenten Zustand zu versetzen. Die Datenarchivierung wird durch den Verdichtungsprozeß der Daten im Data Warehouse notwendig. Hierbei werden Daten je nach Verdichtungsstufen und Verdichtungsfrequenzen ausgelagert und auf externen Datenträgern archiviert, um so das Datenvolumen zu reduzieren und damit eine Performancesteigerung des Data Warehouse zu erreichen.

 

3.2.4 Metadatenbanksystem

Im Metadatenbanksystem werden Informationen über die Data Warehouse-Komponenten gespeichert und verwaltet. Metadaten sind Daten über Daten. Das Metadatenbanksystem soll den Benutzern ein schnelles und sicheres Auffinden der benötigten Daten und Informationen ermöglichen. Es sorgt somit, trotz des Umfangs und der Vielfalt von Informationen im Data Warehouse, für die nötige Transparenz. Unter Transparenz ist zu verstehen, daß die Herkunft der Daten und ihre Verdichtung und Aufbereitung aufgrund der Informationen im Metadatenbanksystem jederzeit nachvollziehbar sind. Einschränkend muß angemerkt werden, daß im Zeitablauf Detaildaten verdichtet und gelöscht werden, so daß der Ursprung der verdichteten Daten nicht mehr nachvollzogen werden kann. Das Metadatenbanksystem erleichtert zudem die Verwaltung des Data Warehouse, da die Metadaten auch Informationen für die Systemverwaltung des Data Warehouse enthalten.

Folgende Informationen sind im Metadatenbanksystem gespeichert:

Außerdem kann mit Hilfe geeigneter Werkzeuge für das Metadatenbanksystem eine Unterstützung bei der Suche nach bestimmten Informationen erfolgen. Damit ist das Metadatenbanksystem ein Schlüsselkomponente für die Akzeptanz des Data Warehouse durch die Nutzer, weil es einen Überblick über die im Data Warehouse enthaltenen Daten verschafft.

 

3.3 Organisationsformen

Grundsätzlich gibt es die Möglichkeit, ein Data Warehouse zentral oder dezentral zu organisieren. Aus Anwendersicht ist in jedem Fall, unabhängig ob nun ein zentrales oder dezentrales Data Warehouse existiert, eine Client/Server-Architektur von Vorteil. Eine Client/Server-Architektur ist gekennzeichnet durch eine Arbeitsteilung von Clients und Servern. Ein Client ist ein Rechner auf dem Anwendungsprogramme betrieben werden, die Abfragen an eine Datenbank stellen. Die Datenbank wird auf einem anderen Rechner betrieben, dem Server. Auf diesem werden dann die Anfragen bearbeitet und die Resultate an den Client übermittelt. Im Falle des Data Warehouse dient ein Datamart als Datenbankserver, auf den die Anwender als Clients zugreifen. Die Client/Server-Architektur ist die architektonische Grundlage eines Data Warehouse. Mit ihr können die Anforderungen nach beliebiger Skalierbarkeit des Data Warehouse und hoher Performance bei großen Datenmengen erfüllt werden. Zudem läßt sich durch die Client/Server-Architektur ein verteiltes Data Warehouse leichter realisieren, da neue Server und oder neue Clients dem Netz hinzufügt werden können. Damit kann ein verteiltes System schrittweise aufgebaut und erweitert werden. Ein verteiltes System ist dadurch gekennzeichnet, daß seine Hardware- und Softwarekomponenten räumlich verteilt und über lokale und Weitverkehrsnetze miteinander verbunden sind.

Für Unternehmen, die einen zentralen DV-Bereich besitzen, ist die Einrichtung eines zentralen Data Warehouses sinnvoll, da so die vorhandene DV-Infrastruktur und die Erfahrungen der Mitarbeiter des zentralen DV-Bereichs genutzt werden können. Abbildung 4 zeigt ein zentrales Data Warehouse mit einem zentralen operativen DV-Bereich. Die Datamarts, die hier als Datenbankserver fungieren, können auf dem gleichen Rechner liegen wie die Datenbasis des zentralen Data Warehouse. Sie können jedoch auch auf andere Rechner verteilt sein.

Abbildung 4: Zentrales Data Warehouse mit zentralem DV-Bereich

Ein zentrales Data Warehouse hat gegenüber einem dezentralen Data Warehouse folgende Vorteile:

Nachteile der zentralen Organisationsform sind

Auch für verteilte operative Systeme kann ein zentrales Data Warehouse sinnvoll sein. Die Verteilung der operativen Systeme erfordert jedoch den Einsatz von geeigneten Transformationsprogrammen. Diese Programme überführen die Daten aus den operativen Systemen, denen meist unterschiedliche Datenmodelle zugrunde liegen, in das zentrale Data Warehouse. Abbildung 5 zeigt ein zentrales Data Warehouse auf Basis verteilter operativer Systeme.

Abbildung 5: Zentrales Data Warehouse auf Basis verteilter operativer Systeme

Eine dezentrale Organisationsform des Data Warehouse ist insbesondere dann sinnvoll, wenn für die gesamte DV ein Wechsel von zentralem zu verteilten Systemen erfolgt oder geplant ist. Mit der Verteilung des Data Warehouse wird seine Flexibilität, Verfügbarkeit und Performance erhöht. Hinzu kommt eine leichtere Skalierbarkeit der Größe des Data Warehouse. Es besteht nämlich die Möglichkeit, neue Datenbankserver bereitzustellen und so die Kapazität des Data Warehouse zu erhöhen. Bei einem zentralen Datenbankserver kann es hingegen eher zu Kapazitätsengpässen kommen. Eine dezentrale Organisation ist jedoch nur dann sinnvoll, wenn die operativen Systeme bereits verteilt sind. Denn dann existiert bereits die nötige Infrastruktur sowie Erfahrungen der Mitarbeiter, die für die Gestaltung eines dezentralen Data Warehouse notwendig sind. Abbildung 6 zeigt den Aufbau eines dezentralen Data Warehouse. Hier ist es sinnvoll, die Datamarts nicht auf den selben Rechnern zu installieren auf denen auch die verteilte Datenbasis liegt, da ein Datamart auch auf mehrere Teile der verteilten Datenbasis zugreifen kann. Wenn also die Datamarts auf anderen Rechner liegen als die verteilte Datenbasis des Data Warehouse, gelangt man zu einer Verteilung auf zwei Ebenen. Zum einen ist die Datenbasis des Data Warehouse verteilt, zum anderen auch die Datamarts, die als Datenbankserver für die Clients fungieren.

Abbildung 6: Dezentrales Data Warehouse

Im Rahmen von dezentral organisierten Data Warehouses wird auch verstärkt die Intranet-Technik zum Einsatz kommen, da sie einen bequemen Zugriff auf die verteilten Datenbestände erlaubt und zudem die Skalierbarkeit eines Data Warehouse erleichtert.

Allgemein kann festgestellt werden, daß die Struktur des Data Warehouse vom Aufbau und der Organisation des Unternehmens, der vorhandenen DV-Infrastruktur und der Planung über die zukünftige Entwicklung des DV-Bereichs abhängt.

 

3.4 Auswertung des Datenbestandes

Im Data Warehouse werden Daten unterschiedlichsten Typs gespeichert. Neben numerischen Daten können auch Texte, Bilder, Sprache etc. verwaltet werden. Erst die Auswertungsmöglichkeiten für die Datenbasis machen die Daten im Data Warehouse wertvoll. Im folgenden werden zwei Auswertungskonzepte betrachtet. Zum einen OnLine Analytical Processing (OLAP) und zum anderen das Data Mining.

 

3.4.1 Data Warehouse und OLAP

Die Auswertung und Analyse von Daten ist eine der Schlüsselkomponenten im Data Warehouse. OLAP (OnLine Analytical Processing) ist ein Technikkonzept, das eine mehrdimensionale Sicht auf Daten und damit schnellere und komplexere Anfragen zur Entscheidungsunterstützung ermöglicht. Es ist ein Teilaspekt des Data Warehouse-Konzepts, da es sich nur mit der multidimensionalen Darstellung von numerischen Daten beschäftigt, während der Data Warehouse-Ansatz auch alle übrigen Daten miteinbezieht. Dem Endanwender soll durch OLAP ein konsistenter Kennzahlenbestand zur Verfügung stehen, an den er selbständig ad hoc Abfragen stellen kann, die dann Ausgangspunkt für betriebswirtschaftliche Analysen und Berichte sind. Es soll ihm also ermöglicht werden, beliebige Ausschnitte aus einem multidimensionalen Datenwürfel zu betrachten. Dies wird mit Hilfe von Funktionalitäten wie "Drill down", "Roll up" und "Slice and Dice" ermöglicht. Unter "Drill down" bzw. "Roll up" ist zu verstehen, Daten auf einer höheren bzw. niedrigeren Verdichtungsstufe darstellen zu können. Unter "Slice and Dice" wird das Herausschneiden von Scheiben aus einem Datenwürfel bzw. die Auswahl bestimmter Bereiche im Datenwürfel verstanden.

Um OLAP zu ermöglichen, muß ein System verschiedene Anforderungen erfüllen. Als Erster formulierte Codd zwölf Regeln, die die OLAP-Fähigkeit eines Informationssystems garantieren sollten. Diese Regeln wurden immer wieder erweitert, so daß derzeit ca. 50 Regeln existieren. Diese Regeln wurden von Pendse und Creeth unter dem Akronym FASMI (Fast Analysis of Shared Multidimensional Information) zusammengefaßt:

Das OLAP-Konzept eröffnet dem Endbenutzer die Möglichkeit, schnell auf umfangreiche Datenbestände zuzugreifen und assoziativ durch diese zu navigieren.

Die OLAP-Funktionalität läßt sich mit Hilfe von Datamarts auf Basis eines Data Warehouse verwirklichen. Ein Datamart ist ein Ausschnitt aus dem Data Warehouse, der auf den Informationsbedarf eines bestimmten Nutzerbereichs, z.B. einer Fachabteilung, ausgerichtet ist. In einem Datamart liegen die Informationen vorverdichtet für einen bestimmten Verwendungszweck vor. Ein Datamart ist also ein "kleines Data Warehouse", das für einen ganz bestimmten Verwendungszweck erstellt wird. Im Gegensatz zu einer Sicht in einer relationalen Datenbank ist die Datenhaltung eines Datamarts physisch und nicht nur logisch wie bei der Benutzersicht. Ein Datamart kann unterschiedlich ausgestaltet werden. Eine Gestaltungsmöglichkeit ist es, ihm die OLAP-Funktionalität zugrunde zu legen. Datamarts müssen jedoch nicht OLAP-fähig sein. Sie können auch so gestaltet sein, daß sie als Grundlage für das Data Mining dienen.

In der Regel wird ein Data Warehouse nicht auf Basis der OLAP-Technik realisiert. Denn das Data Warehouse ist für eine große Menge von Daten ausgelegt, während ein Datamart wesentlich weniger Daten enthält. Außerdem ist der flexible Zugriff auf die Daten im Data Warehouse begrenzt, während ein Datamart speziell für einen flexiblen Zugriff auf die Daten angelegt werden kann. Zudem sind die Daten im Data Warehouse bis zu zehn Jahre alt, während im Datamart ein wesentlich kürzerer Zeithorizont abgebildet wird. Zwischen dem Data Warehouse-Konzept und OLAP in Form eines Datamarts besteht eine ergänzende Beziehung. Das Data Warehouse stellt eine breite Datenbasis zur Verfügung. Aus dieser Datenbasis können die Daten in einen Datamart überführt werden. Dort werden die Daten mit Hilfe von multidimensionalen Datenstrukturen dargestellt. Die OLAP-Technik erlaubt dann eine schnelle Auswertung der themenbezogenen Datenbestände eines Datamarts. Die Verbindung von Datamart und Data Warehouse hat auch den Vorteil, daß auf die detaillierteren Daten des Data Warehouse bei Auswertungen im Datamart zurückgegriffen werden kann, ohne daß eine große Menge von Daten im Datamart gespeichert werden muß.

 

3.4.2 Star- und Snowflake Schema

Multidimensionale Datenstrukturen lassen sich auch in relationalen Datenbanken darstellen. Dabei kommen die Modellierungsansätze Star- und Snowflake Schema zum Einsatz. Das Star Schema beruht auf einer Klassifikation der Daten in zwei Gruppen, Faktdaten und Dimensionsdaten. Die Faktdaten sind die Kerndatenelemente. Sie stehen im Mittelpunkt der Analyse und sind meist quantitativer Natur. Dimensionsdaten sind deskriptiver Natur und beschreiben die Geschäftsdimensionen. Faktdaten und Dimensionsdaten werden in Tabellenform gespeichert. Im Zentrum steht die Fakttabelle. Um sie herum sind die Dimensionstabellen angeordnet. Für jede Dimension gibt es eine Tabelle. Die Dimensionstabellen sind nur mit der Fakttabelle über Beziehungen verknüpft. Zwischen den Dimensionstabellen dagegen bestehen keine Beziehungen. Abbildung 7 zeigt den Aufbau des Star Schemas.

angelehnt an Mucksch S.191

Abbildung 7: Star Schema

Im Star Schema lassen sich keine Hierarchien innerhalb der Dimensionen abbilden. Dies bedeutet, daß sich verschiedene Aggregationsstufen nicht darstellen lassen. Zur Abbildung der hierarchischen Struktur der Dimensionen kann das Star Schema um weitere Verdichtungstabellen erweitert werden. Es wird dann als Snowflake Schema bezeichnet. Hier enthält jede Dimensionstabelle ein Schlüsselattribut für jede Ebene der Dimensionshierarchie. Die Schlüssel verknüpfen die Dimensionstabelle mit der zentralen Faktentabelle und mit den Attributtabellen, die die deskriptiven Informationen über die Dimensionselemente enthalten. Abbildung 8 zeigt ein Beispiel für ein Snowflake Schema.

angelehnt an Mucksch S.199

Abbildung 8: Snowflake-Schema

 

3.4.3 Data Mining

Nachdem im vorangegangenen Abschnitt ein Auswertungskonzept vorgestellt wurde, bei dem der Benutzer durch den Datenbestand navigieren kann, um interessante Informationen aus den Datenbeständen zu extrahieren, wird im folgenden eine Technik betrachtet, bei der ein Data Mining-System aktiv nach Trends und Verhaltensmustern sucht.

Gegenstand des Data Mining ist es, aus großen Datenbeständen versteckte Informationen, Trends und Vorhersagen abzuleiten und sogar Zusammenhänge zu erkennen, an die vor der Analyse gar nicht gedacht wurde. Dabei wird versucht mit Hilfe von Data Mining, Muster in Datenbeständen zu identifizieren, Unterschiede zwischen Gruppen von Datensätzen zu erkennen, die charakteristischen Attribute der Gruppen zu bestimmen, repräsentative Beispiele für Datenzusammenhänge zu finden oder Gleichungen für numerische Variablen auf Basis des Datenbestandes zu erzeugen. Die Ergebnisse solcher Analysen sind mit Angaben über ihre Eintrittswahrscheinlichkeit (Verläßlichkeit) in einer verständlichen Form darzustellen. Üblicherweise geschieht dies mit Hilfe von Wenn-Dann-Regeln. Ein Beispiel für eine Wenn-Dann-Regel ist: "Wenn Artikelgruppe = Fahrräder, dann Deckungsbeitrag = niedrig, mit Sicherheit = 86%".

Folgende Methoden können beim Data Mining zur Anwendung kommen:

Die Clusteranalyse teilt eine gegebene Menge von Objekten in Gruppen auf. Dabei werden die Cluster so gebildet, daß die Ähnlichkeit der Objekte in den Clustern möglichst groß und die Ähnlichkeit der Objekte in verschiedenen Clustern möglichst gering ist. Beim konzeptionellen Clustern werden die Cluster nicht durch die Aufzählung der in den Clustern befindlichen Objekte beschrieben, sondern durch Begriffe, die einzelnen Objekten über Regeln zugeordnet werden.

Die Bayes-Verfahren gehen auf das Theorem von Bayes über bedingte Wahrscheinlichkeiten zurück. Sie versuchen, die Klassenbildung so vorzunehmen, daß die bedingte Wahrscheinlichkeit dafür, daß die Klassenbildung unter der Bedingung der vorliegenden Daten der tatsächlichen Datenstruktur entspricht, möglichst groß wird.

Bei der Entscheidungsbaum- und Regelinduktion wird versucht, aus einer gegebenen Menge von Objekten, deren Klassenzugehörigkeit bekannt ist, eine Regel abzuleiten, die ein neues Objekt in eine vorhandene Klasse einteilt.

Bei Rough Sets wird davon ausgegangen, daß durch eine Vergröberung der Datenbeschreibung die Mustererkennung erleichtert werden kann. Durch die Vergröberung entsteht jedoch ein Informationsverlust, der die Klassifikation erschwert. Es muß dann ein Kompromiß gefunden werden, der zu aussagekräftigen Ergebnissen führt.

Zu den statistischen Verfahren gehören vor allem Regressionsanalysen, Varianzanalysen und Diskriminanzanalysen. Die Regressionsanalyse dient zur Ermittlung statistischer Abhängigkeiten zwischen Merkmalen. Ziel der Regressionsanalyse ist die funktionale Beschreibung und Quantifizierung der Abhängigkeit einer endogenen Variable von exogenen Variablen. Die Varianzanalyse untersucht die Wirkung von Faktoren auf eine oder mehrere metrisch skalierte Ergebnisvariablen. Die typischen Aufgaben der Varianzanalyse sind die Schätzung der mittleren Effekte und Wechselwirkungen von verschiedenen Ausprägungen der Faktoren auf die Ergebnisvariablen und die Abschätzung des Gesamteinflusses eines Faktors oder einer Gruppe von Faktoren auf die Ergebnisvariablen. Die Diskriminanzanalyse ist ein statistisches Trennverfahren zur Bestimmung der Unterschiedlichkeit a priori definierter Gruppen. Außerdem dient sie zur Trennung von Gruppen durch eine Kombination von Merkmalen und zur Einordnung von Objekten mit unbekannter Gruppenzugehörigkeit in die Gruppen.

Mit Hilfe von neuronalen Netzen können langfristig gültige Zusammenhänge und Regelmäßigkeiten gefunden und modelliert werden. Genetische Algorithmen dienen dazu, automatische Näherungen mathematischer Formeln aus Rohdaten zu gewinnen. Sie orientieren sich bei der Suche nach diesen Formeln an den Prinzipien der Zeugung und des Aufbaus von biologischen Populationen.

Bei der Auswertung mittels Data Mining können folgende Ergebnistypen erzeugt werden:

Zeitreihenmuster geben über Entwicklungen im Zeitablauf Auskunft. Klassifikationen ergeben sich durch die Zuteilung von Daten zu bereits bestehenden Gruppen. Cluster sind Ergebnis einer Einteilung der Daten in Gruppen.

Abschließend kann festgestellt werden, daß das Data Mining eine wichtige Methode zur Auswertung der Daten im Data Warehouse ist, da automatisch nach Mustern im Datenbestand gesucht wird. Damit ist das Data Mining insbesondere für die Analyse großer Datenbestände geeignet, da die Suche nach Besonderheiten erleichtert wird.

 

3.5 Nutzenpotentiale

Nachdem in den vorangegangen Abschnitten das Konzept des Data Warehouse vorgestellt wurde, soll noch kurz auf den möglichen Nutzen des Data Warehouse eingegangen werden.

Die Nutzenpotentiale des Data Warehouse-Konzepts lassen sich in technische und betriebswirtschaftliche Nutzenpotentiale untergliedern. Zu den technischen Nutzenpotentialen gehören:

Durch die Trennung von operativen und entscheidungsunterstützenden Daten und Systemen sind die operativen Systeme nicht mehr durch Datenanalysen und aufwendige Abfragen belastet. Außerdem wird durch die Trennung die Komplexität der operativen Systeme verringert. Hinzu kommt, daß durch multidimensionale Datenstrukturen und verschiedene Verdichtungsstufen die Antwortzeiten verkürzt werden und ad hoc Reporting möglich wird.

Zu den betriebswirtschaftlichen Nutzenpotentialen zählen:

Durch ein Data Warehouse ist eine qualitativ und quantitativ bessere Informationsversorgung möglich. Dies führt zu verbesserten Entscheidungen.

Durch die neuen Auswertungsmöglichkeiten, die ein Data Warehouse ermöglicht, können unternehmensinterne und -externe Trends früher entdeckt werden. Durch das rechtzeitige Erkennen von Trends können geeignete Maßnahmen des Unternehmens erfolgen und so eine Verbesserung der Wettbewerbsfähigkeit erreicht werden.

Die Kundenzufriedenheit und der Kundenservice wird durch die Bereitstellung von umfassenden Kundendaten im Data Warehouse verbessert, da auf die Bedürfnisse der Kunden besser eingegangen werden kann.

 

4 Controlling auf Basis eines Data Warehouse

Im nun folgenden Abschnitt soll untersucht werden, wie eine DV-Unterstützung des Controlling auf Basis eines Data Warehouse aussehen kann. Dabei werden die Anforderungen aus Abschnitt 2 den Eigenschaften des Data Warehouse, die in Abschnitt 3 beschrieben wurden, gegenübergestellt. Zudem werden DV-Unterstützungsmöglichkeiten für die Hauptaufgabenbereiche des Controlling, Planung, Kontrolle und Koordination vorgestellt, sowie die systemgestaltenden Aufgaben im Rahmen des Data Warehouse-Konzepts beschrieben. Am Ende des Abschnitts steht ein Architekturvorschlag zur Integration der Kosten- und Leistungsrechnung.

 

4.1 Die Datenbasis des Data Warehouse als Grundlage für das Controlling

Durch das Data Warehouse wird eine integrierte Datenbasis geschaffen. Sie dient als Grundlage für alle späteren Auswertungen. Der Transformationsprozeß der Daten von den operativen und externen Informationsquellen in das Data Warehouse ermöglicht zudem eine Bereinigung von Fehlern und einen Abgleich der Daten der verschiedenen Systeme. Es entsteht so ein integrierter Datenbestand auf Basis der heterogenen Datenquellen des Unternehmens. Das Data Warehouse erfüllt also die betriebswirtschaftliche Forderung nach einem integrierten Datenbestand. Der Controller muß so keine Daten aus den operativen Systemen zusammensuchen. Er wird dadurch von Formatvereinheitlichungen und Konsistenzüberprüfungen entlastet.

Eine weitere Forderung des Controlling an die Datenbasis ist die Unterstützung verschiedener multidimensionaler Sichten auf den Datenbestand. Um diese Forderung zu erfüllen, muß gewährleistet sein, daß zumindest auf einen Teil der Datenbasis des Data Warehouse mit Hilfe von OLAP zugegriffen werden kann. Dies kann dadurch erreicht werden, daß ein Datamart erzeugt wird, dessen Datenbasis nach einem multidimensionalen Datenmodell verwaltet wird.

Die Forderung nach der Verfügbarkeit von aktuellen Daten zu jedem Zeitpunkt wird vom Data Warehouse-Ansatz nur bedingt erfüllt. Da hier eine Trennung von operativen und entscheidungsunterstützenden Systemen vorgenommen wird, hängt die Aktualität der Daten von der Aktualisierung des Data Warehouse ab. Unter der Datenaktualität ist zu verstehen, daß alle Daten aus den operativen Systemen, die für eine bestimmte Entscheidung benötigt werden, auch im Data Warehouse zur Verfügung stehen. Die Aktualisierung der Daten des Data Warehouse erfolgt in der Regel täglich, d.h. am Ende eines Tages werden die Daten der operativen Systeme in das Data Warehouse überführt. Dies führt dazu, daß die Daten im Data Warehouse im schlechtesten Fall einen Tag alt sind. Auf eine zeitpunktgenaue Aktualität der Daten wird also zugunsten einer aufbereiteten Darstellung verzichtet. Die Daten müssen nicht bereits zu ihrem Entstehungszeitpunkt in den operativen Systemen auch in das Data Warehouse überführt werden.

Auch die Forderung nach der Bereitstellung und Verdichtung der Daten auf beliebigen Verdichtungsstufen ist zwar im Data Warehouse möglich, wird aus Performance-Gründen jedoch nur teilweise erfüllt. Dieser Konflikt zwischen hoher und niedriger Granularität wurde bereits in Abschnitt 3 beschrieben.

Im folgenden werden die technischen Anforderungen dem Technikkonzept des Data Warehouse gegenübergestellt. Die erste Anforderung ist die Verfügbarkeit eines adäquaten Datenmodells für das Unternehmen bzw. für die abzubildenden Unternehmensbereiche. Diese Anforderung wird durch die Subjektorientierung des Data Warehouse besonders gut erfüllt. Die Daten werden hier themenorientiert oder aufgabenbezogen zusammengestellt. Die Forderung nach einem modernen Datenbankmanagementsystem zur Verwaltung der integrierten Datenbasis ist im Rahmen des Data Warehouse selbstverständlich. Zudem ist der schnelle und flexible Zugriff auf die Daten ein Ziel, das mit dem Data Warehouse-Konzept verfolgt wird. In diesem Zusammenhang ist insbesondere auf die Funktion der Datenbasis als Grundlage für OLAP-Auswertungen hinzuweisen. Die freie Strukturierbarkeit der Datenbank in bezug auf Auswertungsebenen und Verdichtungen ist ebenfalls eine Grundfunktionalität des Data Warehouse. Unterstützt wird diese freie Strukturierbarkeit durch die Gestaltung von Datamarts.

Somit kann festgestellt werden, daß das Data Warehouse-Konzept die Anforderungen, die an eine geeignete Datenbasis zur Unterstützung des Controlling gestellt werden, weitgehend erfüllt. Die Abstriche hinsichtlich der Datenaktualität und beliebiger Verdichtungsstufen der Daten im Data Warehouse sind eher von untergeordneter Bedeutung, da der Verzicht auf Datenaktualität zu einer Entlastung der operativen Systeme führt und die Reduzierung der Verdichtungsstufen zur Verringerung des Datenvolumens im Data Warehouse und damit zu dessen Performanceverbesserung beiträgt.

Tabelle 1 faßt die Ergebnisse zusammen.

 

 

Anforderungen an die Datenbasis aus Sicht des Controlling

Eigenschaften der Datenbasis des Data Warehouse

Integrierte Datenbasis als Grundlage für dispositive Auswertungen.

Integrierte Datenbasis durch Transformation der Daten aus den operativen Systemen.

Unterstützung multidimensionaler Sichten auf die Datenbank.

Multidimensionale Sichten mit Hilfe von Datamarts und OLAP.

Verfügbarkeit von aktuellen Daten zu jedem Zeitpunkt.

In der Regel wird nur eine Tagesaktualität aufgrund der aufwendigen Transformationsprozesse erreicht, um die operativen Systeme nicht unnötig zu belasten.

Bereitstellung und Verdichtung der Daten auf beliebigen Verdichtungsstufen.

Beliebige Verdichtungsstufen lassen sich aus Performancegründen nur bedingt realisieren, können aber unternehmensindividuell festgelegt werden.

Verfügbarkeit eines adäquaten Datenmodells.

Objekt- und themenbezogene Bereitstellung der Daten.

Modernes Datenbankmanagementsystem.

Basis des Data Warehouse ist ein modernes Datenbankmanagementsystem

schneller und flexibler Zugriff auf die Daten.

Durch Partitionierung und OLAP wird ein schneller und flexibler Zugriff ermöglicht.

freie Strukturierbarkeit der Datenbank in bezug auf Auswertungsebene und Verdichtungsstufen.

Verdichtungsstufen und Auswertungsebenen können im Data Warehouse unternehmensindividuell festgelegt werden.

Tabelle 1: Die Datenbasis des Data Warehouse für das Controlling

 

4.2 Auswertungsmöglichkeiten

Die Anforderungen an die Auswertungsmöglichkeiten der Unternehmensdaten aus Sicht des Controlling sind sehr vielfältig. Durch die Anwendung von OLAP und Data Mining sind aber auch die Auswertungsmöglichkeiten des Datenbestandes im Data Warehouse sehr groß.

Für das Berichtswesen wird gefordert, daß sowohl Standardberichte als auch individuelle Berichte erstellt werden können. Hier soll die Möglichkeit des Drill-Downs auf detaillierte Datenbestände bestehen. In Verbindung mit diesen betriebswirtschaftlichen Anforderungen an das Berichtswesen können die technischen Anforderungen der Existenz eines Berichts- und Formelgenerators gesehen werden. Das Data Warehouse-Konzept unterstützt das Berichtswesen hier in vielerlei Hinsicht. Es bietet durch OLAP die geforderten Drill-Down Möglichkeiten. Außerdem unterstützt das Metadatenbanksystem das schnelle Auffinden von gewünschten Daten und ein selbständiges Navigieren durch den Datenbestand. Hinzu kommt, daß die integrierte Datenbasis den Einsatz von Berichts- und Formelgeneratoren vereinfacht, da die Daten im Data Warehouse schon in einem einheitlichen Format vorliegen. Die Formatvereinheitlichung sollte so erfolgen, daß kein Verlust an Genauigkeit entsteht. Dies bedeutet, daß beispielsweise Währungsumrechnungen exakt durchgeführt werden müssen. Neben der Formatvereinheitlichung und der Konsistenz der Daten ist auch ihre Verfügbarkeit und Genauigkeit im Data Warehouse ein positiver Aspekt für das betriebliche Berichtswesen. Durch die unternehmensindividuelle Gestaltung der Granularität der Daten im Data Warehouse können die Berichtsanforderungen bezüglich der Genauigkeit der Daten leicht erfüllt werden. Hier besteht jedoch der Konflikt zwischen technischen und betriebswirtschaftlichen Anforderungen. Um den Datenbestand nicht zu groß werden zu lassen und einen schnelleren Zugriff auf die Daten zu ermöglichen, sollte die Granularität der Daten erhöht werden. Dies verringert dann jedoch ihre Genauigkeit. Es besteht also ein Konflikt zwischen Verfügbarkeit und Genauigkeit der Daten. Durch die unternehmensindividuelle Gestaltungsmöglichkeit des Data Warehouse kann das Unternehmen selbst bestimmen, auf welchen Aspekt, Verfügbarkeit oder Genauigkeit, mehr Wert gelegt werden soll.

Die Ermöglichung von Zeitreihenanalysen ist eine weitere Forderung, die an die DV-Unterstützung des Controlling gestellt wird. Hier ist die Datenbasis des Data Warehouse eine geeignete Grundlage. Im Gegensatz zu den operativen Systemen, die nur aktuelle Daten enthalten, werden im Data Warehouse auch historische Daten gespeichert. Der abgebildete Zeithorizont im Data Warehouse kann bis zu zehn Jahren betragen. So können leicht Zeitreihenanalysen auf Basis der historischen Daten des Data Warehouse durchgeführt werden. Wenn die Zeitreihenanalysen auf Daten mit einem hohen Detaillierungsgrad durchgeführt werden sollen, muß auch auf externe Datenträger zurückgegriffen werden, da ältere Daten nur in sehr verdichteter Form im Data Warehouse direkt zur Verfügung stehen. Dies erhöht allerdings den mit den Analysen verbundenen Aufwand. Aber die Datenbasis allein reicht nicht aus.

In einer Methodenbank sollten eine Vielzahl von Methoden abgelegt sein, um Zeitreihenanalysen auf Daten mit verschiedenen Annahmen über den Zusammenhang der Daten durchführen zu können. Die Durchführung und Auswertung von Abweichungsanalysen kann insbesondere durch OLAP und Data Mining-Techniken unterstützt werden. Auf diesen Aspekt wird im Abschnitt 4.4.3 genauer eingegangen.

 

4.3 Präsentationsmöglichkeiten

Die Präsentation der Ergebnisse ist eine wichtige Funktion. Denn schließlich sollen auf Basis der Ergebnisse Entscheidungen getroffen werden. Dazu muß dem Entscheidungsträger das Ergebnis in verständlicher Form präsentiert werden. Denn unabhängig von der Größe der Datenbasis oder der Geschwindigkeit heutiger Rechner, am Ende dieser Kette steht das menschliche Gehirn mit seiner begrenzten Aufnahme- und Verarbeitungsfähigkeit. Ziel der Präsentationsprogramme muß es sein, die Informationen so zu präsentieren, daß sie von den Anwendern leicht aufzunehmen sind. Eine übersichtliche und leicht verständliche Präsentation der Ergebnisse wird durch geeignete Anwendungsprogramme, die auf die Datenbasis des Data Warehouse aufsetzen, unterstützt. Hierbei werden folgende Visualisierungsmöglichkeiten von Anwendungsprogrammen angeboten:

Zudem sorgen OLAP und ein gut gegliedertes Metadatenbanksystem für einen guten Benutzungskomfort.

 

4.4 DV-Unterstützung für die Controlling-Aufgaben

Dieser Abschnitt beschäftigt sich mit den DV-Unterstützungsmöglichkeiten für die Hauptaufgaben des Controlling Planung, Kontrolle und Koordination. Im Bereich der Planung wird die Unterstützung der strategischen Unternehmensplanung und der operativen Ergebnisplanung untersucht. Bei der Kontrolle werden Möglichkeiten der Abweichungsanalyse beschrieben. Bei der Koordination wird der Aspekt der DV-Unterstützung für die Ermittlung von Verrechnungspreisen und der Erstellung von Budgets untersucht. Am Ende wird auf die systemgestaltenden Aufgaben des Controlling im Rahmen des Data Warehouse-Konzept eingegangen.

 

4.4.1 Planung

4.4.1.1 Strategische Unternehmensplanung

Unter Planung ist die Festlegung mehrerer voneinander abhängiger Entscheidungsvariablen zu verstehen. Bei der strategischen Unternehmensplanung steht die Schaffung und Pflege von Erfolgspotentialen im Vordergrund. Durch das rechtzeitige Erkennen von Risiken und Chancen soll mit dem Instrument der strategischen Unternehmensplanung die Existenz eines Unternehmens langfristig gesichert werden. Der Ausgangspunkt der strategischen Planung ist die Analyse externer und interner Einflußfaktoren eines Unternehmens. Zu den externe Einflußfaktoren gehören beispielsweise gesetzliche und ökonomische Umweltbedingungen. Interne Einflußfaktoren sind zum Beispiel Unternehmensstandorte und die Finanzsituation. Nach der Analyse dieser Einflußfaktoren werden strategische Ziele formuliert. Diese beschreiben die zukünftige Stellung des Unternehmens als Ganzes. Sie bilden die Grundlage für die Formulierung von Strategien, dem nächsten Schritt der strategischen Unternehmensplanung. Die Strategien legen Maßnahmen und Ressourcen fest, um die strategischen Ziele zu erreichen. Da die Komplexität und Unsicherheit der Umwelt zu Risiken in der strategischen Planung führt, müssen die strategischen Pläne kontinuierlich hinsichtlich deren Tragfähigkeit und Realisierbarkeit überprüft werden. Abbildung 9 zeigt den Ablauf der strategischen Planung.

Abbildung 9: Ablauf der strategischen Planung

Die Datenverarbeitung kann die strategische Unternehmensplanung in vielerlei Hinsicht unterstützen. Durch die Speicherung und das schnelle Abrufen großer Datenmengen wird die Leistungsfähigkeit der strategischen Unternehmensplanung erhöht. Das Vorhandensein der Daten und ihre systematische Sammlung und Aufbereitung im Data Warehouse führt dazu, daß keine Daten vergessen werden. Durch die themenorientierte Darstellung der Daten im Data Warehouse wird ein systematisches Vorgehen bei der Analyse unterstützt. Weiterhin ermöglicht die DV-Unterstützung durch ihre Schnelligkeit eine rasche Wirkungsanalyse durch Simulation und reduziert damit die Unsicherheit der strategischen Planung. Außerdem können Strategien schneller angepaßt werden, und der Einsatz von komplexen Modellen ist möglich. Eine ständige Verbesserung und Anpassung der verwendeten Modelle kann ebenfalls durch Computerunterstützung erzielt werden. Es bestehen jedoch auch Gefahren durch den Einsatz der Datenverarbeitung. Hierzu gehört der unkritische Einsatz von computerunterstützten Modellen und Unterdrücken der für den Planungsprozeß notwendigen Kreativität und Intuition durch den DV-Einsatz. Auch auf einen erhöhten Programmieraufwand durch Anpassung des DV-Systems als Reaktion auf eine hohe Unternehmens- und Umweltdynamik ist zu achten. Außerdem muß vor Scheingenauigkeiten bei Modellrechnungen gewarnt werden.

Bei der DV-Unterstützung für die strategische Unternehmensplanung liegt der Schwerpunkt auf der Informationsbeschaffung und -speicherung, sowie der Informationsaufbereitung. Der Data Warehouse-Ansatz hat gerade auf diesen Gebieten seine Stärken. Er bietet für die strategische Unternehmensplanung eine breite Datenbasis mit historischen Daten, die für die Prognose wichtig sind. Zudem sind die für die Umweltanalyse wichtigen externen Daten im Data Warehouse enthalten. Außerdem liegen die Daten im Data Warehouse in verschiedenen Verdichtungsstufen vor. Damit kann auch auf aggregierte Daten zurückgegriffen werden. Diese sind für die strategische Unternehmensplanung besser geeignet als die detaillierten Daten des Data Warehouse. Das Data Warehouse ist also aufgrund seiner breiten und integrierten Datenbasis eine geeignete Grundlage für die strategische Unternehmensplanung.

Neben dieser Datenbasis sollten noch DV-gestützte Rechenmodelle für die Unternehmensplanung, sowie geeignete Werkzeuge zur Datenanalyse (zum Beispiel OLAP) bereitgestellt werden. Da die Unternehmensplanung regelmäßige Abstimmungen zwischen den Managern verlangt, sollte zur Verbesserung der Kommunikation ein e-mail-System oder Group-Ware-System vorhanden sein.

 

4.4.1.2 Operative Ergebnisplanung

In diesem Abschnitt werden DV-Unterstützungsmöglichkeiten für die operative Ergebnisplanung dargestellt. Die Ergebnisplanung soll das Ergebnis eines Unternehmens für den Planungszeitraum festlegen. Dabei werden Plan-Absatzmengen, Plan-Preise, Plan-Rabatte, Plan-Erlösschmälerungen, Plan-Herstellkosten und Plan-Fixkosten festgelegt. Dies geschieht im Rahmen einer Ergebnisrechnung, die zum Ziel hat Ergebnisquellen des Unternehmens aufzudecken. Die Planung und Kontrolle des Periodenergebnisses erfolgt hierbei durch eine sinnvolle Untergliederung der Leistungen und Kosten. Die Ergebnisrechnung basiert auf der Kosten- und Leistungsrechnung. Dabei sollte die Kosten- und Leistungsrechnung so gestaltet sein, daß eine Trennung von Grundrechnung und Auswertungsrechnung gegeben ist. Hier sei auf die relative Einzelkosten- und Deckungsbeitragsrechnung und den General Ledger-Ansatz in Abschnitt 2.5 hingewiesen. Um eine gute Ergebnisplanung zu ermöglichen, muß die Datenbasis, neben der Trennung von Grund- und Auswertungsrechnung, folgende Anforderungen erfüllen:

Die Datenbasis sollte einheitlich und konsistent sein, da für die Planung funktionsübergreifende Informationen benötigt werden. Außerdem ist eine flexible Strukturierungs- und Aggregierungsmöglichkeit erforderlich, um Ad-hoc-Lösungen von Ergebnisplanungsproblemen zu ermöglichen. Die Einbeziehung unterschiedlicher interner und externer Daten muß möglich sein. Die Daten müssen problemlos in Methoden und Modelle der Ergebnisrechnung eingesetzt werden können. Und schließlich sollte der Benutzer sich nicht um DV-technische Details bezüglich der Bereitstellung der Daten kümmern müssen.

Ebenso wichtig wie die Datenbasis sind die Modelle der Ergebnisrechnung und Methoden für die Ergebnisplanung. Unter Modellen der Ergebnisrechnung sind konkrete Ausprägungen der Auswertungsrechnung zu verstehen wie beispielsweise die Grenzplankostenrechnung. Die Methoden, die für die Ergebnisplanung verwendet werden, sollten in einer Methodenbank abgelegt werden. Dabei stellen sich folgende Anforderungen an die Methodenbank:

Zur Unterstützung der Planung sollte die Methodenbank Methoden enthalten, die den Einsatz und die Entwicklung neuer Planungsmodelle unterstützen. Außerdem sollten Prognose- und Planungsrechnungen zur Verfügung stehen, die die Erlös- und Kostenplanung vereinfachen.

Wenn die Anforderungen der Ergebnisplanung, insbesondere die Anforderungen an die Datenbasis, betrachtet werden, kann auch hier der Data Warehouse-Ansatz eine Lösungsmöglichkeit bieten. Denn das Data Warehouse stellt eine konsistente Datenbasis der Unternehmensdaten dar. Es werden hier zudem Daten aus internen und externen Datenquellen zusammengeführt. Außerdem bietet das Data Warehouse einen flexiblen Zugriff auf die Daten. Ein Problempunkt ist jedoch wieder die Granularität der Daten. Denn die geforderten flexiblen Strukturierungs- und Aggregierungsmöglichkeiten der Kosten- und Leistungsrechnungsdaten sind zwar auf Basis der REDR oder des General Ledger Ansatzes zu realisieren. Jedoch müssen die Daten aus Performancegesichtspunkten vorverdichtet werden, so daß die Ad-hoc-Lösungsmöglichkeiten von Ergebnisplanungsproblemen begrenzt werden. Diese Problem ist jedoch nicht so schwerwiegend, da es durch den Vorteil aufgewogen wird, daß im Data Warehouse auch historische Daten verwaltet werden. Diese sind für Prognosezwecke sehr wertvoll.

Abschließend ist festzuhalten, daß der Integration von Daten aus der Kosten- und Leistungsrechnung beim Aufbau eines Data Warehouse eine zentrale Rolle zuteil wird. Dabei sollte diese auf einer strengen Trennung von Grund- und Auswertungsrechnung beruhen, um eine möglichst flexible Auswertbarkeit der Daten zu gewährleisten. Es gilt dann, diese Flexibilität auch im Data Warehouse zu verwirklichen. Auch eine Methodenbank sollte den Anwendern auf den Clients zur Verfügung stehen. Die Methodenbank kann dann die Datenbasis des Data Warehouse nutzen.

 

4.4.2 Kontrolle

Kontrolle ist der Vergleich von tatsächlich realisierten Größen mit Sollgrößen, die durch die Planung festgelegt wurden. Die Abweichungsanalyse ist ein wesentlicher Bestandteil der Kontrolle. Es werden im folgenden DV-Unterstützungsmöglichkeiten für die Abweichungsanalyse vorgestellt.

Das Vorgehen der Abweichungsanalyse entspricht der Suche nach Auffälligkeiten im Datenbestand des Data Warehouse. Die Automatisierung dieser Suche soll das Controlling von Routineaufgaben entlasten. Damit ergibt sich mehr Zeit für anspruchsvolle, interpretatorische Aufgaben. Außerdem wird das Self-Controlling gefördert, da der Informationsabruf erleichtert wird.

Bei der Automatisierung der Abweichungsanalyse kann man grundsätzlich zwei Ansätze unterscheiden. Zum einen die Top-down-Navigation und zum anderen die Bottom-up-Analyse. Die Top-down-Navigation hat ihren Ausgangspunkt in Auffälligkeiten bei Kennzahlen auf hoher Aggregationsebene. Sie versucht, diese Auffälligkeiten auf Kennzahlen auf niedrigen Aggregationsebenen zurückzuführen. Sie läuft also den Aggregationspfad der Kennzahlen von oben nach unten durch, um die Quelle der Abweichungen zu identifizieren, daher der Name "Top-down-Navigation". Die Bottom-up-Analyse setzt dagegen auf der untersten Aggregationsebene an und versucht dort Muster zu erkennen und Regeln abzuleiten. Im Unterschied zur Top-down-Navigation ist die Analyserichtung hier gerade umgekehrt, daher auch die Bezeichnung "Bottom-up-Analyse".

 

4.4.2.1 Automatische Top-down-Navigation

Einordnung

Unter der automatischen Top-down-Navigation sind Auswertungsheuristiken zu verstehen, in denen das typische Vorgehen eines Controllers bei der Abweichungsanalyse nachgebildet wird. Dabei wird so vorgegangen, daß Entwicklungen auf hoher Aggregationsebene durch sukzessiven Drill-Down auf einzelne betriebswirtschaftliche Objekte zurückgeführt werden. Als Beispiel kann ein Umsatzrückgang auf einen Kunden oder ein Produkt zurückgeführt werden. Man folgt also im Datenbestand enthaltenen Bezugsobjekthierarchien. Eine Bezugsobjekthierarchie stellt den Aggregationspfad von Bezugsobjekten dar. Es gibt drei Typen von Bezugsobjekthierarchien:

Eine Kostenstellenhierarchie entsteht dadurch, daß Basiskostenstellen zu übergeordneten Kostenstellen zusammengefaßt, und diese ebenfalls wieder aggregiert werden. Eine natürliche Hierarchie entsteht durch hierarchische Abhängigkeiten zwischen Ausprägungen verschiedener Merkmale der Controlling-Objekte. Ein Beispiel hierfür ist die Zugehörigkeit eines Artikels zu einer Artikelgruppe. Mehrdimensionale Hierarchien sind dadurch gekennzeichnet, daß hier eine mehrdimensionale Aggregation wünschenswert ist. Zum Beispiel ist es in der Kostenstellenrechnung sinnvoll, die Kosten nach Kostenstellen und nach Kostenarten zu aggregieren.

Die Bezugsobjekthierarchien und die damit verbundenen Kennzahlen können im Data Warehouse unabhängig vom Ausführungszeitpunkt auf Vorrat angelegt werden. Sie können aber auch erst bei Bedarf mit Hilfe von OLAP berechnet werden. Die erste Möglichkeit erfordert sehr viel Speicherplatz. Hier werden nämlich alle Kennzahlen im Data Warehouse gespeichert, unabhängig davon, ob sie tatsächlich für eine konkrete Abfrage benötigt werden. Das bedeutet, daß beispielsweise nicht nur der Umsatz oder Deckungsbeitrag eines Artikels im Data Warehouse gespeichert wird, sondern auch der Umsatz oder Deckungsbeitrag der Artikelgruppe. Es entstehen so sehr viele Umsatz- bzw. Deckungsbeitragskennzahlen entlang dieser natürlichen Hierarchie der Artikel. Besonders bei mehrdimensionalen Hierarchien, bei denen es ausgehend von einer Kennzahl mehrere Aggregationspfade gibt, entstehen eine Vielzahl von Kennzahlen, die dann auch entsprechend viel Speicherplatz benötigen. Der OLAP-Ansatz dagegen setzt ein komplizierteres Datenmodell voraus. Das Datenmodell muß ermöglichen, daß die verschiedenen Kennzahlen zum Ausführungszeitpunkt schnell erzeugt werden können. Dies erfordert eine mehrdimensionale Sicht auf die Daten und damit den Einsatz multidimensionaler Datenmodelle. Hier gibt es, wie in Abschnitt 3.4.1 beschrieben, zwei Realisierungsmöglichkeiten. Zum einen die physische Multidimensionalität im Rahmen einer multidimensionalen Datenbank, oder die virtuelle Multidimensionalität mit Hilfe des Star- und Snowflake Schema.

Ziel der automatischen Top-down-Navigation ist es, alle wichtigen in den betrieblichen Datenbeständen enthaltenen Informationen rechtzeitig zu erkennen.

 

Konventionelle Analyse-Methoden

Eine Filterung von Controlling-Daten kann mit verschiedenen Methoden erreicht werden. Zunächst werden konventionelle Analyse-Methoden vorgestellt. Darunter ist eine personelle, computergestützte Auswertung von Abweichungen zu verstehen. Hier ist als erste Möglichkeit das Festsetzten von Schwellen zu nennen. Die populärste Form hierbei ist die Festlegung von starren Schwellen, die sich auf Abweichungskennzahlen beziehen. Hier werden Toleranzkorridore festlegt; liegt eine Abweichung außerhalb eines gewissen Bereichs, gilt sie als Ausnahme und kann je nach Höhe der Abweichung unterschiedlich farbig markiert werden, um dann eine weitere Analyse zu ermöglichen. Diese Vorgehensweise ist jedoch mit einigen Schwierigkeiten behaftet. Grundsätzlich besteht ein Problem darin, den richtigen Toleranzbereich festzulegen. Dieser ist nämlich von der konkreten Entscheidungssituation abhängig. Er hängt unter anderem von dem Nutzen einer weiteren Auswertung der Abweichung und den damit verbundenen Kosten ab. Die Festlegung von prozentualen Grenzwerten kann hierbei als besonders kritisch angesehen werden. Zudem können Abhängigkeiten zwischen verschiedenen Schwellen nur schwer modelliert werden. Hier können variable Schwellen eine Verbesserung bringen. Die Höhe der Schwellenwerte hängt von einem Kontextfaktor ab. Beispielsweise kann man saisonale Schwankungen dadurch abbilden, daß man einen Basiswert für die Toleranzgrenze mit Hilfe eines saisonabhängigen Multiplikators entsprechend anpaßt. Die dargestellten starren und flexiblen Schwellen entsprechen dem Konzept des "Exception Reporting".

Neben den Schwellen sind Hitlisten eine weitere Analysemöglichkeit. Da die Planungsunsicherheit auf sich schnell verändernden Märkten groß ist, treten selbst bei geschickter Filterung sehr viele Ausnahmen auf. Um nun die begrenzte Analysekapazität des Controllers bestmöglich zu nutzen, sollten Hitlisten zum Einsatz kommen. Diese zeigen zum Beispiel die zehn größten Soll-Ist-Abweichungen an.

Eine weitere Hilfe zur Analyse von Abweichungen sind Streuungsmaße. Bei mehrdimensionaler Sicht auf die Grunddaten gibt es unterschiedliche Analysehierarchien, die von oben nach unten durchwandert werden können, um die Ursachen für übergeordnete Abweichungen zu finden. Um nun das richtige Aufspaltungsmerkmal zu wählen, können Streuungsmaße eingesetzt werden. Diese geben für jede Aufspaltungsdimension an, wie stark einzelne Werte im Durchschnitt vom Mittelwert abweichen. Gewählt wird dann die Aufspaltungsdimension, bei der die Streuung am größten ist.

Auch OLAP kann als Analyse-Methode herangezogen werden. Allerdings bietet OLAP keine Filtermechanismen an, sondern ermöglicht eine interaktive Datenanalyse.

 

Autonome Analyseverfahren

Die bisher beschriebenen Methoden bieten dem Controller Hilfestellung für die Auswertung der Datenbestände. Im folgenden werden Methoden beschrieben, die weitgehend automatisch den Datenbestand untersuchen. Hier gibt es zwei grundsätzliche Tendenzen. Zum einen aktive Informationssysteme und zum anderen autonome Analysealgorithmen.

Aktive Informationssysteme stellen eine Plattform zur Formulierung von Ausnahmekriterien zur Verfügung, die das System dann automatisch überwacht. Hierbei kann zum Beispiel die Trigger-Technik in Datenbanken verwendet werden. Ein Trigger ist ein Ereignis, bei dessen Eintreten, ein Verarbeitungsprozeß in einer Datenbank ausgelöst wird.

Bei den autonomen Analyseverfahren wird zwischen Top-down-Analysen und Bottom-up-Analysen unterschieden. Die Top-down-Analysen basieren auf objektbezogenen verdichteten Daten. Die Bottom-up-Analysen versuchen Muster in gleichförmig vorverdichteten oder unverdichteten Datenbeständen zu erkennen und zu beschreiben. Die Bottom-up-Vorgehensweise entspricht der Vorgehensweise des bereits vorgestellten Konzept des Data Mining. Deshalb kommen auch die Methoden des Data Mining bei der Bottom-up-Analyse zum Einsatz.

Die Top-down-Navigation versucht das menschliche Vorgehen bei der Suche nach Auffälligkeiten in Objekthierarchien nachzubilden. Dabei kommen automatische Navigationsfilter zum Einsatz. Systeme zur Top-down-Navigation bestehen aus zwei Kernmodulen, dem Navigationsfilter und der Objektanalyse. Der Navigationsfilter bestimmt einen Weg durch die Bezugsobjekthierarchien. Ziel ist hierbei die Erforschung von Abweichungsursachen. Die Navigation läßt sich vom Anwender durch die Festlegung von Grundeinstellungen steuern. Die Objektanalyse bezeichnet eine Sammlung von betriebswirtschaftlichen Methoden, mit denen die Controlling-Objekte auf dem Analysepfad untersucht werden. Hierbei werden Zusammenhänge zwischen verschiedenen Kennzahlen untersucht und Zusammenhänge zu übergeordneten oder benachbarten Objekten hergestellt. Abbildung 10 zeigt den Ablauf der Top-down-Navigation.

angelehnt an Hagedorn S.24

Abbildung 10: Ablauf der Top-down-Navigation

Zunächst werden die Kennzahlenwerte des aktuellen Controlling-Objekts auf Grundlage der Basisdaten berechnet. Die Bestimmung des Controlling-Objekts erfolgt dabei mit Hilfe des Navigationsfilters. Die Objektanalyse untersucht die Kennzahlenwerte und übergibt die Resultate der Ergebnispräsentation. Diese werden dann sofort angezeigt oder gespeichert, um am Ende der Analyse in gebündelter Form dargestellt zu werden. Der Navigationsfilter legt dann das nächste zu untersuchende Controlling-Objekt fest oder beendet die Analyse, wenn kein nützlicher Analyseweg mehr verbleibt. Das heißt, die Analyse ist beendet, wenn es keinen Weg mehr durch die Bezugsobjekthierarchie gibt, der die Abweichungsursache weiter erklärt.

 

4.4.2.2 Bottom-up-Analyse

Bei der Bottom-up-Analyse werden die einzelnen Datensätze als Punkte in einem mehrdimensionalen Raum betrachtet. Dies entspricht auch der Vorgehensweise des Data Mining. Deshalb kommen bei der Bottom-up-Analyse auch die Methoden des Data Mining zum Einsatz. Die Lage der Punkte ergibt sich aus den Merkmalsausprägungen, die in den Datensätzen enthalten sind. Dieser datengetriebene Ansatz der Datenmustererkennung beschränkt sich nicht auf die Analyse fest installierter Hierarchien. Er versucht selbständig Strukturen innerhalb der Betriebsergebnisdaten zu finden. Das Data Mining verzichtet auf Annahmen darüber, was eine Ausnahme ist und versucht hypothesenfrei neue Erkenntnisse über Datenbestände zu gewinnen. Dabei läßt sich die Datenmustererkennung in der Ergebnisrechnung als Suche in einem hochdimensionalen Raum interpretieren. Die Lage der Punkte wird durch die in den Datensätzen enthaltenen Merkmalsausprägungen bestimmt. Abbildung 11 verdeutlicht dies.

entnommen aus Bissantz S.50

Abbildung 11: Datenmustererkennung in der Ergebnisrechnung

Die markierte Ballung in der Abbildung stellt eine Gruppe von Datensätzen mit ähnlichen Attributwerten dar. Sie stellen ein Muster in den Daten dar. Diese Ballung von Datensätzen besagt, daß Artikelgruppe C an Kundengruppe 4 mit 23 bis 35 Prozent höherem Deckungsbeitrag als geplant verkauft wurde.

Die Verfahren, die zur Datenmustererkennung herangezogen werden, sind in Abschnitt 3.4.2.2 beschrieben. Besonders geeignet für das Ergebniscontrolling ist die Clusteranalyse. Ziel der Clusteranalyse ist es, aus einer heterogenen Gesamtheit von Objekten homogene Teilmengen zu identifizieren. Die Clusteranalyse hat nur geringe Anwendungsvoraussetzungen. Es können Datensätze verarbeitet werden, deren Tupel metrisch oder nominalskaliert sind. Es können aber auch Datensätze, die Tupel beider Skalierungen enthalten, in die Analyse miteinbezogen werden. Dabei ist unter einer Skala für Datenbestände eine Meßlatte zu verstehen, auf der die Ausprägungen der Tupel abgetragen werden. Eine Vielzahl von existierenden Varianten der Clusteranalyse ermöglicht eine große Flexibilität in bezug auf die Einsatzmöglichkeiten. Zudem ist die Clusteranalyse leicht nachvollziehbar.

 

4.4.3 Koordination

Im Rahmen der Koordinationsaufgabe des Controlling werden nun zwei Koordinationskonzepte und deren DV-Unterstützungsmöglichkeiten vorgestellt. Es handelt sich um die Budgetierung und um das Konzept der pretialen Lenkung.

 

4.4.3.1 Budgetierung

Unter Budgetierung ist die Aufstellung, Vorgabe und Kontrolle von Budgets zu verstehen. Ein Budget ist ein formalzielorientierter, in wertmäßigen Größen formulierter Plan, der einer Entscheidungseinheit für eine bestimmte Periode mit einem bestimmten Verbindlichkeitsgrad vorgegeben wird. Budgets können je nach Unternehmensorganisation als Kosten-, Gewinn-, Investitionsbudgets u.ä. vorkommen. Mit der Budgetierung sollen folgende Vorteile erzielt werden:

Die Koordinationsfunktion kann ein Budget nur dann erfüllen, wenn durch seine Erstellung der Koordinationsbedarf sinkt bzw. wegfällt.

Koordinationsbedarf entsteht durch sachliche und personelle Gründe.

angelehnt an Ewert/Wagenhofer S.404

Abbildung 12: Gründe für einen Koordinationsbedarf

Der sachliche Koordinationsbedarf entsteht durch

Ein Ressourcenverbund liegt dann vor, wenn die Maßnahmen in einem Bereich von den möglichen Maßnahmen in einem anderen Bereich abhängen. Beispielsweise kann der Vertrieb nur so viele Produkte absetzen, wie auch von der Produktionsabteilung hergestellt wurden. Ein Erfolgsverbund liegt vor, wenn der Erfolgsbeitrag einer Maßnahme davon abhängt, welche anderen Maßnahmen parallel dazu durchgeführt wurden. Beispielsweise hängt der Preis für einen Rohstoff von dessen Abnahmemenge ab, und diese hängt wiederum vom Bedarf in zwei verschiedenen Produktionsbereichen ab. Damit sind die Ergebnisfunktionen beider Bereiche über den Rohstoffpreis miteinander verbunden. Dies ist dann der Erfolgsverbund. Unter einem Risikoverbund ist die stochastische Abhängigkeit zwischen Maßnahmen verschiedener Bereiche zu verstehen. Zum Beispiel sind die Deckungsbeiträge zweier Bereiche risikobehaftet und korreliert. Der Risikoverbund führt erst in Verbindung mit bestimmten Risikopräferenzen der Entscheidungsträger zum Koordinationsbedarf. Ein Bewertungsverbund liegt vor, wenn die subjektive Wertschätzung der Ergebnisse vom bisherigen Ergebnisniveau abhängt. Beispielsweise wird ein Gewinn in einem Bereich in Abhängigkeit des erzielten Gewinns in einem anderen Bereich bewertet.

Personeller Koordinationsbedarf entsteht durch das gleichzeitige Vorliegen von asymmetrischer Informationsverteilung und Interessenkonflikten. Asymmetrische Informationsverteilung liegt vor, weil Informationen im Unternehmen unterschiedlich verteilt sind. Die Bereichsmanager sind in der Regel besser über ihren Bereich informiert als die Unternehmensleitung. Gäbe es keine Interessenkonflikte zwischen Zentrale und Bereichsmanager, könnte die Informationsasymmetrie durch eine wahrheitsgemäße Berichterstattung der Bereichsmanager an die Zentrale abgebaut werden. Da jedoch die Berichterstattung und die Ressourcenallokation an die Bereiche zusammenhängen, werden auch die Interessen des Bereichsmanagers tangiert. Der Bereichsmanager ist zum Beispiel an einer hohen Ressourcenzuteilung interessiert, um seine Position zu stärken, oder weil damit für ihn nicht-pekuniäre Vorteile entstehen. Er berichtet deshalb einen überhöhten Bereichsgewinn, um ein höheres Investitionsvolumen oder andere Vergünstigungen zu erhalten.

Die Budgetierung ist nun ein möglicher Lösungsansatz, um die beschriebenen Koordinationsprobleme in den Griff zu bekommen. Im Rahmen der Budgetierung sollte auf drei Prinzipien Wert gelegt werden: Kommunikation, Partizipation und Flexibilität. Ein gutes Kommunikationssystem ist für die Budgetierung wichtig, weil nur so Informationen aus den Teilbereichen eines Betriebes für die Budgetplanung bereitgestellt werden können. Die Partizipation von Mitarbeitern bei der Erstellung der Budgets erfüllt zwei Funktionen. Zum einen werden die partizipativ erstellen Budgets eher akzeptiert, als Budgets, die ohne Partizipation der Mitarbeiter, d.h. von der Zentrale, erstellt wurden. Zum anderen gelangt die Unternehmensleitung durch die Partizipation der Mitarbeiter zu realistischen Budgets, da die Mitarbeiter besser über die Verhältnisse in ihren Bereichen informiert sind als die Unternehmensleitung oder eine zentrale Planungs- bzw. Controlling-Abteilung. Außerdem werden Mitarbeiter durch die partizipative Ermittlung der Budgets motiviert. Im Rahmen der partizipativen Ermittlung von Budgets muß darauf geachtet werden, daß Budgetvorgaben weder zu schwer noch zu leicht zu erreichen sind. Bei zu leichten Budgetvorgaben werden die Mitarbeiter nicht motiviert und können sich Ineffizienzen erlauben, ohne Budgetvorgaben zu verletzen. Zu schwere Budgetvorgaben demotivieren den Mitarbeiter, da die geforderten Vorgaben nicht erreichbar sind.

Die geforderte Flexibilität von Budgetsystemen kann dadurch erreicht werden, daß Budgetvorgaben ständig auf ihre Richtigkeit überprüft und falls sich die Rahmenbedingungen ändern, auch die Budgetvorgaben geändert werden müssen.

Um eine gute Budgetierung zu ermöglichen, werden

benötigt. Historische Unternehmensdaten liefern oft Hinweise für zukünftige Unternehmensentwicklungen und sind Grundlage für die Budgetplanung. Um Budgets festzulegen, müssen die zukünftigen Absatzchancen des Unternehmens geschätzt werden. Hierzu sind Marktdaten, d.h. Daten über Konkurrenten, neue Produkte usw. und interne Daten, die die Absatzentwicklung beeinflussen, z.B. Informationen aus Forschung und Entwicklung, erforderlich. Daten über Kapazitäten und Ressourcen und deren derzeitige Verwendung sind notwendig, um durch die Budgetierung eine effiziente Verwendung der Unternehmensressourcen zu gewährleisten.

Für die Budgetierung ist demnach eine große Menge von Daten erforderlich. Um diese Datenmenge zu bewältigen, ist eine DV-Unterstützung unabdingbar. Die Datenbasis des Data Warehouse ist besonders geeignet als Grundlage für Budgetierungsentscheidungen,. denn sie enthält neben aktuellen integrierten internen Unternehmensdaten sowohl historische Daten als auch externe Unternehmensdaten. Auf Basis dieser Daten können mit geeigneten Auswertungsmethoden die notwendigen Informationen für die Festlegung von Budgets gewonnen werden.

Eine wichtige DV-unterstützte Auswertungsmethode sind "Wenn-Dann-Analysen". Sie beantworten Fragen wie zum Beispiel "Wie ändert sich der Gewinn in diesem Jahr, wenn die Produktion von Produkt A um 100 Einheiten gesteigert wird und gleichzeitig von Produkt B 50 Einheiten weniger hergestellt werden?". Durch die DV-Unterstützung können solche Analysen schnell und flexibel durchgeführt werden. Die erzeugten Resultate dienen als Grundlage für die Anpassung von Budgets.

Für die Vorhersage von Absatzmengen, die als Basis für die Budgetierung fungieren, kommen aufgrund der Unsicherheit der zukünftigen Absatzmengen insbesondere computergestützte Simulationsmodelle zum Einsatz. Diese ermöglichen einen schnellen Überblick über mögliche zukünftige Entwicklungen. Um eine optimale Ressourcenallokation im Unternehmen durch die Budgetierung zu erreichen, kann die lineare Programmierung zum Einsatz kommen. Die DV-Unterstützung erlaubt hier die Verwendung von komplexen Modellen mit einer großen Anzahl von Variablen.

Eine wichtiges Werkzeug im Rahmen der Budgetierung sind Tabellenkalkulationsprogramme. Mit ihnen können Simulationen durchgeführt werden und Lineare Programmierungsmodelle gelöst werden. In der Regel bieten sie Schnittstellen zur Datenbasis des Data Warehouse, so daß diese genutzt werden kann.

Abschließend kann festgestellt werden, daß die Budgetierung mit Hilfe von Auswertungswerkzeugen wie Tabellenkalkulationsprogrammen und der Datenbasis des Data Warehouse schnell und flexibel durchgeführt werden kann.

 

4.4.3.2 Pretiale Lenkung

Das Konzept der pretialen Lenkung dient zur Koordination des innerbetrieblichen Güter- und Leistungsaustausches. Dabei erfolgt die Koordination über Verrechnungspreise. Ausgangspunkt für die pretiale Lenkung ist ein dezentral organisiertes Unternehmen, dessen einzelne Bereiche eigenverantwortlich handeln und zum Ziel haben, ihren Bereichsgewinn zu maximieren.

Das Kernproblem der pretialen Lenkung besteht darin, Verrechnungspreise zu ermitteln, bei denen die Bereiche ihren Bereichsgewinn genau dann maximieren, wenn sie die Mengen herstellen bzw. verarbeiten, die auch den Gesamtgewinn des Unternehmens maximieren. Verrechnungspreise dienen jedoch nicht nur zur Koordination und Lenkung des Güter- und Leistungsaustauchs. Sie sind auch Grundlage für die Erfolgsermittlung und Beurteilung der einzelnen Bereiche. Zwischen der Koordinationsfunktion und Erfolgsermittlungsfunktion der Verrechnungspreise besteht in der Regel ein Zielkonflikt, da die Verrechnungspreise auch den Bereichsgewinn beeinflussen. Durch die Vorgabe von Verrechnungspreisen wird das Entscheidungsproblem aus Sicht des Bereichsmanagers verzerrt. Er maximiert auf Basis des Verrechnungspreises seinen Bereichsgewinn. Dieser ist in der Regel jedoch keine geeignete Beurteilungsgröße für die Leistungsfähigkeit der Abteilung, da die Bereichsgewinne durch die Verrechnungspreise verzerrt werden und damit die Erfolgsbeiträge der Bereiche nicht adäquat widerspiegeln. Die Ausnahme bilden hier marktorientierte Verrechnungspreise.

Es gibt drei unterschiedliche Verrechnungspreistypen:

Marktorientierte Verrechnungspreise erfüllen sowohl die Koordinationsfunktion als auch die Erfolgsermittlungsfunktion. Damit sind Marktpreise die ideale Basis für Verrechnungspreise. Ein Problem der Marktpreise liegt darin, daß es oft keinen oder keinen einheitlichen Marktpreis für das Zwischenprodukt gibt. Ist dies der Fall, müssen Verrechnungspreise auf eine andere Art ermittelt werden.

Eine weitere Möglichkeit der Verrechnungspreisermittlung sind kostenorientierte Verrechnungspreise. Ermittelt man die Verrechnungspreise auf Basis von Grenzkosten, erfüllen sie die Koordinationsfunktion. Das Dilemma hierbei ist jedoch, daß die Zentrale gleichzeitig mit den optimalen Verrechnungspreisen auch die optimale Menge kennt und damit eine Vorgabe des Verrechnungspreises überflüssig ist. Die Zentrale kann gleich die optimale Menge den Bereichen vorgeben. Ein weiteres Problem besteht darin, daß die zugerechneten Gewinne auf Basis von Grenzkosten-orientierten Verrechnungspreisen nicht die Erfolgsbeiträge der Bereiche adäquat widerspiegeln. Außerdem können die Bereiche die Rahmenbedingungen, die für die Verrechnungspreisbildung maßgeblich sind, beeinflussen. Dies führt dazu, daß die Bereiche die Verrechnungspreise in ihrem Sinne manipulieren können. Verrechnungspreise als Verhandlungsergebnis führen nur zufällig zur optimalen Steuerung des Güter- und Leistungsaustauschs und damit zur Gewinnmaximierung des Unternehmens, da sie vom Verhandlungsgeschick der einzelnen Bereiche abhängen.

Trotz der aufgezeigten Schwächen ist die pretiale Lenkung ein geeignetes Konzept zur Koordination des innerbetrieblichen Güter- und Leistungsaustauschs. Es dient zur Komplexitätsreduktion der Koordination einzelner Bereiche. Auf Basis von Verrechnungspreisen sollen die Mengenentscheidungen in den einzelnen Teilbereichen relativ einfach dezentral getroffen werden. Eine Vereinfachung wird allerdings nur dann erreicht, wenn die Verrechnungspreise nicht anhand eines Totalmodells zentral ermittelt werden, sondern nur grob geschätzt werden. Dies führt dann zwar zur Verfehlung des Optimums, aber auch zur erheblichen Komplexitätsreduktion des Koordinationsprozeßes. Die pretiale Lenkung führt insbesondere dann zu akzeptablen Ergebnissen, wenn die für die Höhe der Verrechnungspreise relevanten Rahmenbedingungen von den einzelnen Bereichen nicht beeinflußt werden können oder wenn eine Orientierung an Marktpreisen möglich ist.

Es stellt sich die Frage, inwieweit das Konzept der pretialen Lenkung durch den Einsatz der Datenverarbeitung unterstützt werden kann. Allgemein kann festgestellt werden, daß durch den Einsatz der Datenverarbeitung auch komplexere Entscheidungsprobleme gelöst werden können. Im Rahmen der Koordinationsproblematik des innerbetrieblichen Güter- und Leistungsaustauschs kann idealistisch gefordert werden, daß ein Totalmodell aufgestellt und mit Hilfe der DV auch gelöst wird. Dazu müßte eine optimale Informationsversorgung der Zentrale durch die dezentralen Einheiten gewährleistet sein. Die optimale Informationsversorgung könnte durch den Aufbau eines Data Warehouse erreicht werden. Der Zentrale würden so alle Information aus den dezentralen Bereichen zur Verfügung stehen. Sie könnte das Totalmodell lösen und die optimalen Mengen den Bereichen vorgeben. Diese Vorstellung ist jedoch wenig realistisch. Das Konzept der pretialen Lenkung dient ja unter anderem dazu, die Zentrale zu entlasten. Die Zentrale soll weder detaillierte Informationen aus den dezentralisierten Bereichen einholen müssen, noch soll sie ein Totalmodell aufstellen und lösen müssen.

Dennoch wird die Tendenz einer DV-Unterstützung im Bereich der pretialen Lenkung deutlich. Der Zentrale ist es nun möglich mit Hilfe der im Data Warehouse befindlichen unternehmensexternen und -internen Informationen, eine genauere Schätzung der Verrechnungspreise vorzunehmen. Die externen Daten der Datenbasis des Data Warehouse liefern Informationen über Konkurrenten und Marktverhältnisse, so daß aus diesen Informationen Marktpreise geschätzt werden können. Diese dienen dann als Grundlage für die Verrechnungspreise. Außerdem enthält die Datenbasis des Data Warehouse Informationen über Herstellungskosten und Kapazitäten der Unternehmensbereiche. Aus diesen Informationen können ebenfalls Verrechnungspreise abgeleitet werden. Der Vorteil des Data Warehouse besteht insbesondere darin, daß diese unterschiedlichen Informationen in einer Datenbasis zusammengeführt sind, und sie leicht abgerufen werden können. Die Daten im Data Warehouse können also Aufschluß über veränderte Rahmenbedingungen geben, die für die Verrechnungspreisfestlegung von Bedeutung sind. Außerdem ermöglichen die verbesserten Kontrollmöglichkeiten im Data Warehouse, Manipulationen oder Fehlinformationen der einzelnen Bereiche schnell aufzudecken. Denn mit Hilfe von OLAP und Data Mining-Techniken können Abweichungsanalysen schnell und detailliert auf der Datenbasis des Data Warehouse durchgeführt werden. Dies ermöglicht das frühzeitige Erkennen von Ineffizienzen und Manipulationen. Besonders Analysen, die auch historische Daten mit einbeziehen, helfen Manipulationen und Fehlinformationen schnell aufzudecken, da der Entscheidungsträger sich auffällige Veränderungen gegenüber historischen Daten von den dafür verantwortlichen Mitarbeitern erklären lassen kann.

 

4.4.3.3 Interessenkonflikte und Koordination

Wie bereits erwähnt ist ein Grund für das Entstehen von Koordinationsbedarf das gleichzeitige Auftreten von asymmetrisch verteilten Informationen und Interessenkonflikten. Hier kommt auch eine DV-Unterstützung der Koordination an ihre Grenzen. Sie kann zwar dazu beitragen, die verteilten Informationen zusammenzuführen. Zur Erfüllung dieser Aufgabe kommt ein Data Warehouse zum Einsatz. Das Zusammenführen von Informationen ist jedoch wertlos, wenn diese bewußt durch die Informationslieferanten im Unternehmen verfälscht werden. Die Manipulation von Informationen ist aufgrund der Interessenkonflikte der Personen im Unternehmen ein gängiges Problem. Lösungsansätze liefert hier die Agency-Theorie. Hier sei insbesondere auf Ansätze zur wahrheitsgemäßen Berichterstattung hingewiesen.

Es kann also festgestellt werden, daß der Einsatz der DV zum Abbau der Informationsasymmetrie beitragen kann. Eine DV-Unterstützung der Koordination ist aber nur dann erfolgreich, wenn es Anreizsysteme oder ähnliche Mechanismen im Unternehmen gibt, die eine wahrheitsgemäße Berichterstattung der Informationslieferanten gewährleisten.

 

4.4.4 Systemgestaltende Aufgaben des Controlling

Nachdem in den vorangegangenen Abschnitten die Nutzung des Data Warehouse für die Erfüllung der Controlling-Aufgaben im Vordergrund stand, soll in diesem Abschnitt kurz dargestellt werden, welchen Beitrag das Controlling beim Aufbau eines Data Warehouse leisten kann bzw. muß.

Im Rahmen der systemgestaltenden Aufgabe ist das Controlling für die Schaffung und Betreuung einer Infrastruktur zur Informationsversorgung zuständig. In Verbindung mit dem Aufbau eines Data Warehouse sollte das Controlling die relevanten Unternehmensobjekte bestimmen, die im Data Warehouse abgebildet werden. Zudem sollten Verdichtungspfade und hierarchische Beziehungen der Objekte durch das Controlling beschrieben werden. Außerdem müssen der DV-Abteilung Vorschläge unterbreitet werden, wie aus betriebswirtschaftlicher Sicht die Granularität der Daten im Data Warehouse sowie die Aktualisierungsintervalle zu gestalten sind. Das Controlling hat zudem die Pflicht auf die thematische Gestaltung von Datamarts einwirken. Auch bei der Entscheidung über die Einbeziehung externer Datenquellen in das Data Warehouse ist ein Mitwirken der Controlling-Abteilung sinnvoll.

Zusammenfassend läßt sich feststellen, daß das Controlling nicht nur ein Hauptnutzer der Daten des Data Warehouse ist, sondern auch wesentlich an seiner Ausgestaltung beteiligt ist.

 

4.5 Integration der Kostenrechnung

In den vorangegangen Abschnitten ist deutlich geworden, daß zur Aufgabenerfüllung des Controlling Kosten- und Leistungsinformationen eine wichtige Rolle spielen. In diesem Abschnitt soll nun ein Vorschlag gemacht werden, wie die Kosten- und Leistungsrechnung in ein Data Warehouse integriert werden kann, um so die Vorteile dieses Konzepts zu nutzen.

Ausgangspunkt ist das operative Kosten- und Leistungsrechnungsystem. Dieses sollte aus einer Grundrechnung bestehen, wie sie im Rahmen der REDR oder des General Ledger vorgeschlagen wird. Die Daten der Grundrechnung werden in das Data Warehouse überführt. Die Datenbasis des Data Warehouse enthält somit die aktuellen sowie historische Daten der Grundrechnung. Die Auswertungsrechnungen werden mit Hilfe von Datamarts realisiert. Je nach Rechnungsziel kann ein Datamart Informationen auf Basis der Grenzplankostenrechnung, der Prozeßkostenrechnung oder der Lebenszykluskostenrechnung bereitstellen. Dazu werden die Daten der Grundrechnung im Rahmen der Transformation von der Datenbasis des Data Warehouse in die Datamarts unterschiedlich aggregiert und hierarchisch angeordnet. Es werden je nach Rechnungsziel auch unterschiedliche Bezugsgrößen und Kostenschlüssel verwendet. Die so vorverarbeiteten Daten im Datamart können mit Hilfe von OLAP schnell und flexibel ausgewertet werden.

Die Ausgestaltung der Datamarts nach unterschiedlichen Rechnungszielen wird nun an einem Beispiel verdeutlicht. Als unterschiedliche Rechnungsziele sollen die kurzfristige Produktionsprogrammplanung und die strategische Kalkulation betrachtet werden. Die Produktionsprogrammplanung dient zur Ermittlung des gewinnoptimalen Produktionsprogramms bei gegebenen Kapazitäten. Die strategische Kalkulation hat zum Ziel die langfristigen Produktkosten zu ermitteln. Diese sind für strategische Entscheidungen, wie die Aufnahme eines neuen Produktes in das Produktionsprogramm, wichtig. Für die kurzfristige Produktionsprogrammplanung muß die Kostenrechnung die variablen Kosten der Produkte liefern, um so deren Deckungsbeiträge ermitteln zu können. Diese Informationen liefert die Grenzplankostenrechnung. Im Rahmen der strategischen Kalkulation werden Vollkosteninformationen benötigt. Diese Informationen liefert die Prozeßkostenrechnung. Um also diese beiden Rechnungsziele verfolgen zu können, muß in einem Datamart die Grenzplankostenrechnung verwirklicht sein und in einem anderen Datamart die Prozeßkostenrechnung. Beide Rechnungen können nun durch die Transformation der Daten der Grundrechnung in den Datamarts verwirklicht werden.

Im Rahmen der Grenzplankostenrechnung ist die Beschäftigung die maßgebliche Kosteneinflußgröße. Es wird eine Trennung von variablen und fixen, d.h. vom Grad der Beschäftigung abhängigen bzw. unabhängigen, Kosten vorgenommen. Die fixen Kosten sind für die kurzfristige Produktionsprogrammplanung irrelevant und werden nicht in den Datamart überführt. Die variablen Kosten werden nun in Einzel- und Gemeinkosten unterteilt, je nachdem ob sie einer Produkteinheit direkt zurechenbar sind oder nicht. Die Einzelkosten werden den Produktkosten direkt zugerechnet, während die Gemeinkosten im Rahmen einer Kostenstellenrechnung mit Hilfe von Kalkulationssätzen den Produkten zugerechnet werden. Die Grundrechnungsdaten der Datenbasis des Data Warehouse werden also im Datamart nach den Regeln der Kostenstellenrechnung den Produkten zugerechnet. Dabei erfolgt diese Zurechnung nach einer vorgegebenen Kostenstellenhierarchie und Kostenschlüsseln. Im Datamart sind so die relevanten variablen Kosten für die Produktionsprogrammplanung enthalten.

Für die strategische Kalkulation bilden die Kosteninformationen der Prozeßkostenrechnung eine geeignete Entscheidungsgrundlage. Im Gegensatz zur Grenzplankostenrechnung ist die Prozeßkostenrechnung eine Vollkostenrechnung. Es erfolgt deshalb keine Trennung von variablen und fixen Kosten. Im Rahmen der Prozeßkostenrechnung werden Prozesse identifiziert und diesen werden Kosten zugeordnet. Zwar basiert die Prozeßkostenrechnung auf der Einteilung des Unternehmens in Kostenstellen, jedoch werden andere Beziehungen zwischen den Kostenstellen abgebildet und auch andere Bezugsgrößen als im Rahmen der Grenzplankostenrechnung verwendet. Dies bedeutet, daß ganz andere Informationen aus der Grundrechnung gewonnen werden und im Datamart für die strategische Kalkulation bereitgestellt werden. Im Datamart für die strategische Kalkulation stehen langfristige Produktvollkosten, während im Datamart für die kurzfristige Produktionsprogrammplanung die variablen Produktkosten zur Verfügung gestellt werden. Abschließend kann festgestellt werden, daß die für die spezifischen Rechnungsziele erforderlichen Kosteninformationen durch unterschiedliche Auswahl und Schlüsselung von Daten der Grundrechnung in einem Datamart bereitgestellt werden können.

Abbildung 13 verdeutlicht den Architekturvorschlag.

Abbildung 13: Integration der Kostenrechnung in das Data Warehouse-Konzept

 

5 Zusammenfassung

Das Data Warehouse-Konzept spiegelt die veränderte Rolle der Datenverarbeitung in den Unternehmen wider. Während in der Vergangenheit der Datenverarbeitung die Rolle der Automation von Geschäftsabläufen zukam, hat sie heute die Aufgabe des Informationslieferanten. Information ist zu einem wichtigen Wettbewerbsfaktor in einem globalen Wettbewerb geworden. Das Data Warehouse stellt diese überlebensnotwendigen Informationen den Unternehmenseinheiten zur Verfügung. Durch das Data Warehouse-Konzept entsteht aus der Datenflut der verschiedenen operativen Systeme eines Unternehmens eine konsistente Informationsbasis. Das Controlling nutzt diese Informationsbasis für Planung, Kontrolle und Koordination und wirkt auch bei der Ausgestaltung des Data Warehouse mit. Controlling und Data Warehouse tragen also wesentlich dazu bei, aus der Datenflut im Unternehmen entscheidungsrelevante Informationen zu generieren, um einem Unternehmen ein erfolgreiches Bestehen auf umkämpften Märkten zu sichern. Die Arbeit zeigt auf, daß durch den Einsatz von Data Warehouses für das Controlling eine entscheidende Verbesserung der Informationsversorgung und -verarbeitung im Unternehmen erzielt wird.

Die Datenbasis des Data Warehouse ist eine ideale Grundlage zur Unterstützung der Controlling-Aufgaben. Als zentraler Datenspeicher des Unternehmens erleichtert sie die Arbeit des Controlling erheblich, da durch die integrierte Datenbasis Inkonsistenzen in den operativen Systemen bereits behoben sind und damit bei der Analyse durch das Controlling nicht mehr berücksichtigt werden müssen. Auch die Auswertungsmöglichkeiten des Datenbestandes eines Data Warehouse tragen zur Unterstützung des Controllers bei. Insbesondere durch OLAP und Data Mining wird er von Routineaufgaben entlastet und hat mehr Zeit für spezielle Auswertungen. Auch bei der Präsentation der Ergebnisse erfährt der Controller durch Visualisierungstechniken eine gute Unterstützung.

Im Bereich der Planung sind besonders die historischen Daten des Data Warehouse eine ideale Grundlage für Prognose und Simulation. Die Kontrollaufgabe des Controlling wird durch Data Mining und OLAP unterstützt. Die Auswertungsmöglichkeiten von Abweichungen sind durch OLAP und Data Mining sehr flexibel und teilweise automatisiert. Im Rahmen der Koordination liegt der positive Aspekt des Data Warehouse-Konzepts im Abbau der Informationsasymmetrie. Die Informationsasymmetrie kann jedoch nur dann abgebaut werden, wenn die Entscheidungsträger ihre Informationen wahrheitsgemäß weitergeben. Um dies zu erreichen, muß ein geeignetes Anreizsystem geschaffen werden. Eine isolierte DV-Unterstützung führt zu keiner Verbesserung der Koordination.

Es kann also feststellt werden, daß das Controlling einen großen Nutzen aus der Existenz eines Data Warehouse zieht. Das Controlling hat jedoch auch eine Aufgabe beim Aufbau eines Data Warehouse. Die Controlling-Abteilung sollte bei allen betriebswirtschaftlichen Gestaltungsaspekten des Data Warehouse mitwirken. Insbesondere sollte hier auch auf eine Integration der Kosten- und Leistungsrechnung geachtet werden, um die Flexibilität der Auswertungsmöglichkeiten zu erhöhen.

Das Data Warehouse-Konzept wird im Bereich des Controlling zu Veränderungen führen. Der Abbau der Informationsasymmetrie und die damit verbundene Verfügbarkeit einer integrierten Datenbasis im ganzen Unternehmen führt zur Tendenz des Self-Controlling. Dies bedeutet, daß die Unternehmensbereiche ihre Planung und Kontrolle selbst durchführen, indem sie die benötigten Informationen aus der Datenbasis des Data Warehouse abrufen. Das Controlling muß nur noch die geeigneten betriebswirtschaftlichen Methoden den Bereichen zur Verfügung stellen. Die Durchführung von Planung und Kontrolle wird dann immer weniger Aufgabe des Controlling sein, sondern sich mehr in die einzelnen Bereich verlagern. Dadurch wird das Controlling jedoch nicht überflüssig. Der Controller kann sich viel intensiver um die Abstimmung der einzelnen Unternehmensbereiche und -funktionen widmen. Dies entspricht der koordinationsorientierten Sicht des Controlling. Die Hauptfunktion des Controlling ist die Koordination des Führungsgesamtsystems. Dabei werden die systemgestaltenden Aufgaben des Controlling immer mehr an Bedeutung gewinnen. Das Controlling trägt somit die Verantwortung dafür, daß die benötigten Informationen und Methoden den Entscheidungsträgern im Unternehmen zur Verfügung stehen. Um dieser Verantwortung gerecht zu werden, muß das Controlling sich aktiv an der Gestaltung des betrieblichen Informationssystems und insbesondere des Data Warehouse beteiligen. In einer solchen Rolle besetzt das Controlling die Schlüsselschnittstelle zwischen Datenverarbeitung und Entscheidungsträgern im Unternehmen.

 

Literaturverzeichnis

 

Bauer, Sabine/Winterkamp, Tiemo: Relationales OLAP versus Mehrdimensionale Datenbanken in: Data Warehouse und Management Informations Systeme, Hrsg. Uwe Hannig, Stuttgart, 1996, S.45-53.

 

Behme, Wofgang: Das Data Warehouse-Konzept in: WISU Heft 2/98, S.148-150.

 

Berson, Alex/Smith Stephen J.: Data Warehousing, Data Mining and OLAP, New York u.a., 1997.

 

Behme, Wolfgang/Mucksch, Harry: Informationsversorgung als Wettbewerbsfaktor in: Das Data-Warehouse-Konzept, Hrsg. Harry Mucksch/Wolfgang Behme, Wiesbaden, 1997, S.4-25.

 

Bissantz, Nicolas: CLUSMIN Ein Beitrag zur Analyse von Daten des Ergebniscontrollings mit Datenmustererkennung (Data Mining) Dissertation in: Arbeitsberichte des Instituts für mathematische Maschinen und Datenverarbeitung (Informatik), Band 29, Nr.7, 1996.

 

Chamoni, Peter/Zeschau, Dietmar: Management-Support-Systems und Data-Warehousing in: Das Data-Warehouse-Konzept, Hrsg.: Harry Mucksch/Wolfgang Behme, Wiesbaden, 1996, S.47-83.

 

Daum, Jürgen H.: Integration des MIS in Anwendungen für das operative Controlling und die Konzernrechnungslegung in: Data Warehouse und Management Informations Systeme, Hrsg. Uwe Hannig, Stuttgart, 1996, S. 89-94.

 

Ewert, Ralf/Wagenhofer, Alfred: Interne Unternehmensrechnung, Zweite überarbeitete Auflage, Berlin, 1995.

 

Fellersmann, Matthias: Kosten- und Leistungrechnung im Rahmen eines effektiven Informationsmanagement in: Kostenrechnungspraxis, Heft 3/96, S.174-178

 

Fritz, Burkhard/Kusterer, Frank: Konzeption und Ausgestaltung eines kennzahlen- und berichtsorientierten Führungsinformationssystems unter Windows in: DV-gestütztes Unternehmenscontrolling, Thomas Reichmann (Hrsg.) München 1993, S.151-166.

 

Gilmozzi, Stefan: Data Mining - Auf der Suche nach dem Verborgenen in: Data Warehouse und Management Informations Systeme, Hrsg. Uwe Hannig, Stuttgart, 1996, S.159-171.

 

Grob, H. L: Positionsbestimmung des Controlling, in: Rechnungswesen und EDV, Kundenorientierung in Industrie, Dienstleistung und Verwaltung, 17. Saarbrücker Arbeitstagung 1996, Hrsg: A.-W. Scheer, Heidelberg 1996, S.137-158.

 

Hagedorn, Jürgen: Die automatische Filterung von Controlling-Daten unter besonderer Berücksichtigung der Top-down-Navigation (BETREX II), Dissertation in: Arbeitsberichte des Instituts für mathematische Maschinen und Datenverarbeitung (Informatik), Band 29, Nr.7, 1996.

 

Hagedorn, Jürgen/Bissantz, Nicolas/Mertens, Peter: Data Mining (Datenmustererkennung): Stand der Forschung und Entwicklung in: Wirtschaftsinformatik, Heft 6, 1997, S.601-612.

 

Hansen, Wolf-Rüdiger/Peschel, Frank D.: Gabler Lexikon Innovative Informationsverarbeitung, Wiesbaden, 1995.

 

Heinrich, Lutz J./Roithmayer, Friedrich: Wirtschaftsinformatik-Lexikon, 5.Auflage, München, 1995.

 

Holthuis, Jan: Multidimensionale Datenstrukturen -Grundkonzepte, Funktionalität, Implementierungsaspekte- in: Das Data-Warehouse-Konzept, Hrsg. Harry Mucksch/Wolfgang Behme, Wiesbaden, 1996, S.165-204.

 

Hoitsch, Hans-Jörg/Schmitz, Hans: Konzepte für den Datenbankeinsatz in der Kostenrechnung in: Kostenrechnungspraxis: Zeitschrift für Controlling, Heft 1, 1995, S.29-35.

 

Hornung, Karlheinz/Reichmann, Thomas/Baumöl, Ulrike: Informationsversorgungsstrategien für einen multinationalen Konzern in: Controlling Zeitschrift für erfolgsorientierte Unternehmenssteuerung Heft 1/97, S.38-45.

 

Inmon, W. H.: Building the Data Warehouse, Second edition, New York, 1996.

 

Jahnke, Bernd/Groffmann, Hans-Dieter/Kruppa, Stephan: On-Line Analytical Processing (OLAP) in : Wirtschaftsinformatik Heft 3, 1996, S.321-324.

 

Klingler, Bernhard F./Wullenkord, Axel: EDV-gestützte Konzernkostenrechnung in: Controlling Zeitschrift für erfolgsorientierte Unternehmenssteuerung, Heft 4, 1992, S.204-211.

 

Küpper, Hans-Ulrich: Controlling - Konzeption, Aufgaben und Instrumente -, 2. aktualisierte und ergänzte Auflage, Stuttgart 1997.

 

Kudlich, Herman: Verteilte Datenbanken, Berlin, 1992.

 

Laux, Helmut: Erfolgsteuerung und Organisation 1, Berlin, 1995.

 

Laux, Helmut/Liermann, Felix: Grundlagen der Organisation, 3.Auflage, Berlin, 1993.

Lexikon der Statistik: Hrsg. Bernd Rönz/Gehard Strohe, Wiesbaden, 1994.

 

Moscove, Stephen A./Simkin, Mark G./Bagranoff, Nancy A.: Accounting Information Systems -Concepts and Practice for Effective Decision Making, 4th edition, New York, 1990.

 

Mucksch, Harry: Charakteristika, Komponenten und Organisationsformen von Data-Warehouses in: Das Date-Warehouse-Konzept, Hrsg. Harry Mucksch/Wolfgang Behme, Wiesbaden, 1996, S.85-116.

 

Mucksch, Harry/Holthuis, Jan/Reiser, Marcus: Das Data Warehouse-Konzept - ein Überblick in : Wirtschaftsinformatik, Heft 4, 1996, S.421-433.

 

Mus, Gerold/Hnaschmann, Rolf: Buchführung Grundlagen-Aufgaben-Lösungen, Wiedbaden, 1992.

 

Oehler, Karsten: Das General Ledger-Konzept in Rechungswesen und Controlling - Zeit für einen Wandel? in: Controlling Zeitschrift für erfolgsorientierte Unternehmenssteuerung, Heft 5, 1997, S.356-361.

 

Oehler, Karsten/Oeting, Klaus: Kostenrechnung und Controlling mit einer generischen Rechnungswesensoftware in: Controlling-Prozesse optimieren, Hrsg. Peter Horvath, Stuttgart, 1995, S.213-228.

 

Reichmann, Thomas: Controlling mit Kennzahlen und Managementberichten, 5.Auflage, München, 1997.

 

Reiser, Marcus/Holthuis, Jan: Nutzenpotentiale des Data Warehouse-Konzepts in: Das Data-Warehouse-Konzept, Hrsg. Harry Mucksch/Wolfgang Beheme, Wiesbaden, 1996, S.117-129.

 

Schlegel, Hans Bernd: Computergestützte Unternehmensplanung und -kontrolle, München, 1996.

 

Schmalenbach, E.: Kostenrechnung und Preispolitik, 7.Aufl., Köln, 1956.

 

Schweitzer, Marcel/Küpper, Hans-Ulrich: Systeme der Kosten- und Erlösrechnung, 6.Auflage, München, 1995.

 

Sinzig, Werner: Relative Einzelkosten- und Deckungsbeitragsrechung im SAP-System in: Kostenrechnungspraxis: Zeitschrift für Controlling, Heft 1, 1994, S.52-56.

 

Steinbichler, Georg: Das Berichtswesen im internationalen Unternehmen: Gestaltungsmöglichkeiten für das Controlling in: 5. Deutscher Controlling Congress -Tagungsband-, Hrsg. Reichmann, Thomas, Düsseldorf, 1990, S.140-150.

 

Wagner, Hans-Peter/Vogel, Christoph: Executive Information Systems -EDV-Unterstützung im Controlling- in : Controlling Zeitschrift für erfolgsorientierte Unternehmenssteuerung, Heft 4/96, S.228-235.

 

Weber, Hans Werner/Strüngmann, Uwe: Datawarehouse und Controlling -Eine vielversprechende Parnterschaft in: Controlling Zeitschrift für erfolgsorientierte Unternehmenssteuerung, Heft 1/997 S. 30-36.

 

Weber, Jürgen: Kostenrechnung-(s)-Dynamik - Einflüsse hoher unternehmensex- und -interner Veränderungen auf die Gestaltung der Kostenrechnung in: BFuP, 1995, S.565-581.