Session D-BWL
Betriebswirtschaftliches Controlling mit Visual FoxPro
Sebastian Flucke
ASCI CONSULTING GmbH
Vorbemerkung
Die technische Programmierung, also die Erstellung von Klassen, Masken, Menüs
usw. ist für den Foxpro-Programmierer tägliche Routine. Ebenso geübt sind die
meisten wohl im Umsetzen von inhaltlichen Programmiervorgaben im Rahmen von
Auftragsprogrammierung. Aber speziell im kaufmännischen Bereich gibt es ein
inhaltliches Gebiet, auf dem man seltener gefordert wird, nämlich den Bereich
des betriebswirtschaftlichen Controlling. Dabei kann man gerade als Datenbankprogrammierer
auf diesem Gebiet mit wenigen Handgriffen effektvolle Auswertungen erzeugen,
die sich bei einiger Übung in jede kaufmännische Applikation integrieren lassen.
Die Session zeigt auf, wie man mit Visual FoxPro inhaltlich anspruchsvolle
betriebswirtschaftliche Auswertungen vom einfachen Benchmarking bis zum komplexen
Analysen umsetzen kann. Neben der programmtechnischen Umsetzung werden die einzelnen
Verfahren auch inhaltlich kurz erläutert, insbesondere bezüglich der Eigenschaften,
die die zu untersuchenden Daten haben müssen.
Zunächst etwas graue Theorie
Zwei Aspekte des Controllings
Das betriebswirtschaftliche Controlling kann man unter zwei Aspekten
betrachten:
- der betriebswirtschaftlich-inhaltliche Aspekt:
- Unternehmens-Ziel
- Unternehmens-Philosophie
- Unternehmens-Struktur
- Umgebung des Unternehmens (Markt, Konkurrenten)
- der mathematisch-statistische Aspekt:
- Mittel und Methoden, um den betriebswirtschaftlich-inhaltlichen Aspekten
gerecht zu werden
- Einsatz dieser Methoden mit verschiedenen Zeithorizonten (kurz-, lang-
und mittelfristig)
Die vorliegende Session befaßt sich diesbezüglich mit der programmtechnischen
Umsetzung der mathematisch-statistischen Aspekte.
Die Nutzbarmachung von Daten
Dir für die betriebswirtschaftliche Analyse zu verarbeitenden Daten können
von unterschiedlicher Art sein:
- quantitative Daten:
- in Zahlen ausdrückbare Sachverhalte
- z.B. betriebswirtschaftliche Kennzahlen (Gewinn, Umsatz, Menge, Preis)
- qualitative Daten:
- qualitative Informationen wie "Produkt sieht gut aus" oder
"leichte Bedienbarkeit"
- quantifizierte qualitative Daten:
- Punktesystem zur Bewertung der Fahreigenschaften eines Kraftfahrzeugs
- Verkehrsregelverstoß - 5 Punkte in Flensburg
Bestimmte Aussagen über einen Sachverhalt haben dabei einen unterschiedlichen
Informationswert:
- DATEN "Zahlen" aus dem Unternehmen und dem Umfeld
- INFORMATIONEN unternehmensspezifisch relevante Daten
- KENNZAHLEN spezifisch verdichtete Informationen
Die Kunst besteht nun darin, Daten aufzunehmen, zu Informationen weiterzuverarbeiten
und zu Kennzahlen zu verdichten.
In der "einfachen" kaufmännisch orientierten Programmierung hat man
es normalerweise mit quantifizierten Daten zu tun, die in Gestalt diverser Kennzahlen
vorliegen, deren Bereitstellung und Analyse sich gut durch einfache softwaretechnische
Mittel unterstützen läßt.
Dabei existieren sehr unterschiedliche Quellen für Daten, Informationen und
Kennzahlen:
- unternehmensinterne Quellen
- Rechnungswesen
- Finanzbuchhaltung
- PPS-Systeme
- Warenwirtschaftssysteme
- unternehmensexterne Quellen
- Marktanalysen
- Handelsregister
- gesetzliche und ähnliche Regelungen
Damit befindet man sich sofort mitten in den fachlich-inhaltlichen Bereichen,
für die viele typische kaufmännische EDV-Anwendungen erstellt werden. Und gerade
bei der Programmierung dieser Applikationen werden oft genau die Daten gespeichert
und berechnet, die für Controlling-Auswertungen äußerst interessant sein können.
Die in diesem Zusammenhang zu verarbeitenden Daten, Informationen und Kennzahlen
werden im weiteren allgemein mit dem Begriff Daten bezeichnet.
Daten lassen sich einteilen in kumulierbar und nichtkumulierbar:
- Kumulierbare Daten sind Daten, die sich über zusammengehörige Objekte
oder Zeitstände durch einfache Summation zusammenfassen lassen:
Gewinn(Firma1) + Gewinn(Firma2) = Gewinn(Konzern)
Umsatz(01.95) + Umsatz(02.95) + Umsatz(03.95) = Umsatz(1.Quartal 95)
- Nichtkumulierbare Daten sind Daten, die nicht durch einfache Summation
zusammengefaßt werden können, z.B.:
Stückpreise
Kostensätze
Renditen
Nichtkumulierbare Daten lassen sich dabei über zusammengehörige Objekte oder
Zeitstände nur als "gewogenes arithmetisches Mittel" zusammenfassen!
Voraussetzung ist eine Gewichtung, die in die Zusammenfassungs-Formel mit einfließt,
wie das folgende Beispiel zeigt (es wird der Umsatz zur Gewichtung herangezogen):
ALLGEMEIN: Rendite = Gewinn / Umsatz
FALSCH: Rendite(Firma1) + Rendite(Firma2) = Rendite(Konzern)
( Gewinn(Firma1) + Gewinn(Firma2) )
RICHTIG: ----------------------------------- = Rendite(Konzern)
( Umsatz(Firma1) + Umsatz(Firma2) )
Betrachtet man die Kumulierbarkeit unter betriebswirtschaftlichem Aspekt,
so ergibt sich folgender Zusammenhang:
- kumulierbare Daten sind Mengengrößen, die quantitative Informationen beinhalten
(z.B. Umsatz, Stückzahl)
- nicht kumulierbare Daten beinhalten qualitative Informationen wie z.B. Renditen,
Kostensätze usw.
Die Auswertbarkeit von Daten
Ein wichtiger Aspekt bezüglich der Auswertbarkeit von Daten ist die inhaltliche
Homogenität:
- Inhaltlich homogene Gesamtheiten sind Mengen von Daten, die sich
in wesentlichen Merkmalen
- hinsichtlich der Ebene ihres Zeitbezuges (Tag, Monat, Jahr usw.)
- und hinsichtlich ihrer Zugehörigkeit zu einer bestimmten Hierarchie-Ebene
(Konzern, Unternehmen, Niederlassung, Filiale)
- nicht unterscheiden.
- Alle anderen Datenmengen sind im Sinne dieser Definition "inhaltlich
inhomogen".
Die Begriffe "kumulierbar" und "nicht kumulierbar",
" inhaltlich homogen" und " inhaltlich inhomogen"
sowie "qualitativ" und "quantitativ" werden
im weiteren Verlauf dieses Dokuments an diversen Stellen als Zulässigkeitskriterien
verwendet.
Außerdem müssen noch zwei weitere Probleme bezüglich der mathematischen Umsetzung
bestimmter Verfahren näher betrachtet werden, die bei der programmtechnischen
Umsetzung unbedingt zu beachten sind.
Fehlende Daten wegen "Division durch 0":
- In betriebswirtschaftlichen Berechnungen kommt es häufig zu Quotienten-Bildungen.
- Ist nun der Divisor einer Quotienten-Bildung numerisch 0, kann der Quotient
mathematisch nicht berechnet werden.
- Bei komplexeren Berechnungen kann sogar der Fall eintreten, daß sich ein
Divisor aus einer Differenzbildung heraus als 0 ergibt (z.B. bei Umsatz/(Umsatz-Gewinn)für
den Fall, daß der Umsatz gleich dem Gewinn ist).
- Bei den Datentypen Numeric, Float, Integer und Currency wird in diesem Fall
der Fehler "Numeric overflow. Data was lost (Error 39)" ausgelöst.
Man sollte sich dabei nicht durch die etwas verwirrende Beschreibung dieses
Fehlers irritieren lassen! Bei der gleichen Aktivität auf einem Feld des Typs
Double entsteht allerdings kein Fehler!
- Innerhalb von SQL-Selects kann es beim Datentyp Currency in dieser Konstellation
auch zu dem Fehler "Currency value is out of range (Error 1988)"
ausgelöst. Man sollte sich dabei ebenfalls nicht durch die etwas verwirrende
Beschreibung dieses Fehlers irritieren lassen!
- Für die Weiterverarbeitung solcher undefinierten Ergebnisse muß man eine
Entscheidung treffen:
- Sollen undefinierte Ergebnisse in die Berechnung nicht einbezogen
werden, muß dies durch eine entsprechende Programmkonstruktion gewährleistet
werden (z.B. mit einer entsprechenden WHERE-Klausel an dem SQL-Statement,
in welchem die Division enthalten ist).
- Wenn dieser Zustand sozusagen fortgepflanzt werden soll, bietet
sich an, solche Berechnungsergebnisse durch den Wert .NULL. zu ersetzen.
- Eine dritte Variante ist das Ersetzen des undefinierten Wertes durch
einen Wert, der die Stimmigkeit der weiteren Berechnungen gewährleistet.
Unvollständige Ausgangsdaten:
- Solche fehlenden Dateninhalte werden normalerweise durch .NULL. repräsentiert:
- .NULL. sollte also der Default-Wert solcher Datenbankfelder sein
(dies setzt voraus, daß .NULL.-Werte in der Definition der Tabellenstruktur
zugelassen sind).
- Wenn der Fall eintritt, daß ganze Datensätze wegen fehlender Werte nicht
existieren, dann entstehen beim JOIN in den auswertenden SQL-Select-Befehlen
ebenfalls automatisch .NULL.-Inhalte.
- Mit der ISNULL()-Funktion kann in den auswertenden SQL-Select-Befehlen geprüft
werden, ob die entsprechenden Werte vorhanden sind.
- Die Funktion NVL() kann genutzt werden, um die .NULL.-Daten bei der Weiterverarbeitung
automatisch durch einen anderen Wert zu ersetzen.
In jedem Fall muß unter inhaltlichen Aspekten entschieden werden, ob die Berechnung
bei fehlenden Ausgangsdaten überhaupt fortgesetzt werden darf.
Die Zulässigkeit mathematisch-statistischer Verfahren
Die Zulässigkeit mathematisch-statistischer Verfahren muß sehr sorgfältig geprüft
werden:
- Solche Verfahren sind aus mathematischer Sicht auf fast beliebige
Datenkonstellationen und -mengen anwendbar.
- Zulässigkeitsbeschränkungen existieren aus statistischer Sicht (meist
bei zu kleinen Datenmengen)!
- Außerdem existieren Zulässigkeitsbeschränkungen aus inhaltlicher Sicht
(bestimmte Verfahren sind für bestimmte inhaltliche Konstellationen unzulässig).
Außerdem sind die Einflußfaktoren auf die Bewertung der Ergebnisse mathematischer
Verfahren zu beachten:
- Verläßlichkeit der Ausgangsdaten
- Zulässigkeit der Kombination der Ausgangsdaten
- Zulässigkeit des gewählten Verfahrens aus statistischer Sicht
- Zulässigkeit des Verfahrens aus betriebswirtschaftlicher Sicht
- subjektive Interpretation der Ergebnisse
Dabei spielt die subjektive Interpretation der Ergebnisse eine entscheidende
Rolle. Selbst bei Vorliegen aller anderen Voraussetzungen entscheidet letztendlich
die subjektive Interpretation und Bewertung der Ergebnisse solcher Verfahren
über den positiven oder negativen Beitrag, den diese Ergebnisse zur Entscheidungsfindung
beitragen können.
Die Umsetzung betriebswirtschaftlicher Verfahren
Zu den Abbildungen
In den nachfolgenden Abschnitten dieses Dokuments werden zur inhaltlichen Erläuterung
der Thematik Screenshots verwendet, die aus technischen Gründen nicht in jedem
Fall mit den als Beispiel verwendeten Programm-Ausschnitten übereinstimmen.
Für die programmtechnische Umsetzung der Geschäftsgrafiken ist die Anwendung
eines entsprechenden ActiveX-Controls zu empfehlen (z.B. GraphicsServer
oder Flipper). Die technische Anbindung und programmseitige Ansteuerung
solcher Controls ist nicht Gegenstand dieser Session.
Hitlisten-Erstellung
Eine Hitliste ist eine einfache Sortierung, die in folgenden Fällen zum Einsatz
kommen kann:
- quantitative Daten bei homogenen Datenmengen, zum Beispiel:
- Umsatz aller Unternehmen eines Konzerns
- Monats-Umsätze eines Unternehmens über einen bestimmten Zeitraum
- qualitative Daten bei beliebigen Datenmengen, zum Beispiel:
- Rendite einer Filiale für Monats-, Quartals- und Jahresdaten
- Durchschnittspreis eines Produktes für verschiedene Filialen, Niederlassungen
und Unternehmen
Die programmtechnische Umsetzung dieser Hitlisten besteht in einer einfachen
Sortierung, z.B. mit der ORDER BY Klausel des SQL-Select-Befehls:
SELECT ;
Company, ;
MaxOrdAmt ;
FROM ;
Customer ;
ORDER BY ;
MaxOrdAmt
Die Sortierung kann dabei durchaus auch mehrstufig erfolgen, z.B. nach MaxOrdAmt
innerhalb des jeweiligen Postleitzahlenbereichs:
SELECT ;
PostalCode, ;
Company, ;
MaxOrdAmt ;
FROM ;
Customer ;
ORDER BY ;
PostalCode, ;
MaxOrdAmt
Auch Gruppierungen können mit einbezogen werden, z.B. Sortierung nach MaxOrdAmt
innerhalb einer Gruppierung nach Postleitzahlen:
SELECT ;
PostalCode, ;
Company, ;
SUM( MaxOrdAmt ) ;
FROM ;
Customer ;
GROUP BY ;
PostalCode ;
ORDER BY ;
PostalCode, ;
MaxOrdAmt
In jedem Fall ist die Interpretation einer Hitliste aber abhängig
- von der Sortierfolge (auf- oder
absteigend)
- vom betriebstwirtschaftlichen
Inhalt der sortierten Daten,
wie die folgenden Beispiel zeigen:
- absteigend sortiert nach Umsatz
- der Beste ist oben
- aufsteigend nach dem Gewinn
- der Beste ist unten
- absteigend sortiert nach Kosten
- der Beste ist oben
- aufsteigend sortiert nach Verlust - der Beste ist unten
Eine Sortierung kann aber durchaus auch nach einem kombinierten Kriterium sinnvoll
sein.
Hat man z.B. eine Filialen-Liste mit Gewinn und Umsatz, so kann man nach dem
Quotienten aus beiden sortieren und erhält eine nach der Rendite geordnete Tabelle:
SELECT ;
Company, ;
Profit / Turnover, ;
FROM ;
Customer ;
ORDER BY ;
2
Liegen bei den zu sortierenden Daten .NULL.-Werte vor, so landen sie ohne weitere
Vorkehrungen bei aufsteigender Sortierung am Anfang und bei absteigender Sortierung
am Ende der Sortierfolge!
Im Gegensatz dazu landen "********"-Daten (resultierend aus Division
durch 0) ohne weitere Vorkehrungen bei aufsteigender Sortierung am Ende und
bei absteigender Sortierung am Anfang der Sortierfolge!
Bei der Sortierung nach einem kombinierten Kriterium ist zu beachten, daß ggf.
erst durch die Kombination "********"-Daten entstehen können (z.B.
SELECT a / ( b – c )..., wenn b = c gilt)!
Struktur-Analysen
Unter Strukturanalysen versteht man eine Normierung unter
Verwendung der Prozentrechnung.
Als Berechnungsbasis wird die Summe aller Elemente der
jeweiligen Gruppe genutzt. Deshalb ist diese Analyse nur bei quantitativen
Daten in homogenen Datenmengen einsetzbar.
Das folgende Beispiel zeigt die Umsatz-Struktur bezüglich
der vier Absatzgebiete Inland, USA, Österreich und Großbritannien:
Die Ergebnisse einer Strukturanalyse könne auch sehr gut
grafisch dargestellt werden:
Als Ergebnis einer Strukturanalyse wird Anteil der Einzelelemente
an der Gesamtheit in zwei Schritten ermittelt:
* 1. Schritt: Ermitteln der Gruppensummen
SELECT ;
Product_Id, ;
SUM( Quantity ) Sum_Quant;
FROM ;
OrdItems ;
GROUP BY ;
Product_Id ;
INTO CURSOR ;
Sum1
* 2. Schritt:
SELECT ;
OrdItems.Product_Id, ;
OrdItems.Quantity / Sum1.Sum_Quant * 100.00 AS Percent;
FROM ;
OrdItems ;
INNER JOIN Sum1;
ON Sum1.Product_Id = OrdItems.Product_Id ;
ORDER BY ;
OrdItems.Product_Id
Eine zusätzliche Aussage liefert die Sortierung der Ergebnis-Menge nach dem
Anteil:
* 2. Schritt:
SELECT ;
OrdItems.Product_Id, ;
OrdItems.Quantity / Sum1.Sum_Quant * 100.00 AS Percent;
...
ORDER BY ;
OrdItems.Product_Id, ;
Percent
Wichtig bei einer Struktur-Analyse ist die Überprüfung der Zulässigkeit
dieses Verfahrens bzgl. der zu untersuchenden Daten:
Inhaltliche Zulässigkeit ist nur gegeben bei Vollständigkeit
der Daten für die zu untersuchende Gesamtheit (für eine Konzern-Struktur-Analyse
darf kein Unternehmen fehlen)!
Formale
Zulässigkeit ist nur gegeben, wenn die zu analysierenden Werte entweder alle
>=0 oder alle <=0 sind (ansonsten sind die berechneten Anteile
nicht interpretierbar).
Die formale Zulässigkeit
kann mit dem folgenden SQL-Select überprüft werden:
* Vorbereitung:
* Ermitteln, ob es Gruppen mit unzulässigen Vorzeichenwechseln gibt
SELECT ;
Product_Id, ;
SUM( SIGN( Quantity ) ) AS Sum_Sign, ;
SUM( ABS( SIGN( Quantity ) ) ) AS Count ;
FROM ;
OrdItems ;
HAVING ;
ABS( Sum_Sign ) <> Count ;
GROUP BY ;
Product_Id ;
INTO CURSOR ;
NotAllowed
IF _tally = 0
* keine Gruppen, die einen Vorzeichenwechsel enthalten
* also normale Verarbeitung
...
ELSE
* es existieren Gruppen, die einen Vorzeichenwechsel enthalten
...
ENDIF
Der Trick bei diesem SQL-Select besteht in der Benutzung der SIGN()-Funktion
und deren Vergleich mit der Anzahl der Sätze, wobei Sätze mit dem Wert 0 ausgeschlossen
bleiben.
Bei Bedarf kann man die in diesem Vorbereitungs-SQL-Select verwendete Funktionalität
mit negierter HAVING-Klausel auch in das SQL-Select des ersten Schrittes
integrieren:
* 1. Schritt: Ermitteln der Gruppenmaxima
SELECT ;
Product_Id, ;
MAX( Quantity ) AS Max_Quant, ;
SUM( SIGN( Quantity ) ) AS Sum_Sign, ;
SUM( ABS( SIGN( Quantity ) ) ) AS Count ;
FROM ;
OrdItems ;
HAVING ;
ABS( Sum_Sign ) = Count ;
GROUP BY ;
Product_Id ;
INTO CURSOR ;
Max1
In diesem Fall enthält das Ergebnis des ersten Schritts nur alle die Gruppen,
die formal zugelassen sind, was durch das INNER JOIN im Schritt 2 automatisch
weitergereicht wird.
Benchmarking
Benchmarking ist ein der Strukturanalyse ähnliches Verfahren, bei welchem aber
nicht die Summe aller Elemente der jeweiligen Gruppe als Berechnungsbasis
genutzt wird, sondern je nach betriebswirtschaftlichem Inhalt das Minimum
bzw. das Maximum. Deshalb ist diese Analyse nur bei homogenen
Datenmengen einsetzbar, wobei es keine Beschränkung auf quantitative Daten gibt,
sondern auch qualitative Daten zulässig sind.
Das folgende Beispiel ein Benchmarking der Umsatzerlöse der vier Absatzgebiete
Inland, USA, Österreich und Großbritannien, woraus deutlich wird, das die USA
und Österreich weit abgeschlagen sind.
Auch das Benchmarking läßt sich grafisch aufbereiten:
Ergebnis des Benchmarking ist die Relation des Einzelwertes zum Gruppen-Besten.
Dieses Verhältnis wird in zwei Schritten ermittelt, wobei die Sortierung nach
Percent die Aussage noch unterstützt:
* 1. Schritt: Ermitteln der Gruppenmaxima
SELECT ;
Product_Id, ;
MAX( Quantity ) Max_Quant;
FROM ;
OrdItems ;
GROUP BY ;
Product_Id ;
INTO CURSOR ;
Max1
* 2. Schritt:
SELECT ;
OrdItems.Product_Id, ;
OrdItems.Quantity / Max1.Max_Quant * 100.00 AS Percent;
FROM ;
OrdItems ;
INNER JOIN Max1;
ON Max1.Product_Id = OrdItems.Product_Id ;
ORDER BY ;
OrdItems.Product_Id, ;
Percent
Es ist in Abhängigkeit vom betriebswirtschaftlichen Inhalt natürlich eine analoge
Verfahrensweise mit der Funktion MIN() möglich.
Keinesfalls vernachlässigt werden darf aber die Überprüfung der Zulässigkeit
dieses Verfahrens bzgl. der zu untersuchenden Daten:
Aus Sicht der inhaltlichen Zulässigkeit
bestehen bzgl. der Vollständigkeit der Daten für die zu untersuchende
Gesamtheit keine Einschränkungen!
- Formale Zulässigkeit ist nur gegeben, wenn die zu analysierenden
Werte entweder alle >=0 oder alle <=0 sind (ansonsten
sind die berechneten Verhältnisse nicht interpretierbar).
- Die formale Zulässigkeit kann analog der Prüfung bei der Strukturanalyse
ermittelt werden.
Abweichungs-Analysen
Abweichungsanalyse Variante 1
Jede vergleichende Untersuchung ist eine Abweichungsanalyse (z.B. die Untersuchung
der Plan-Ist-Abweichung absolut und in %).
Die nachfolgende Abbildung zeigt die Analyse der Plan-Ist-Abweichung diverser
Betriebe einer Unternehmensgruppe:
Auch grafisch läßt sich die Abweichungsanalyse effektvoll darstellen:
Der programmtechnischer Hintergrund ist in den meisten Fällen eine einfache
Differenzbildung bzw. normale Prozentrechnung, die Informationen über die Über-
oder Unterschreitung des Vergleichswertes liefert:
SELECT ;
Target, ;
Current, ;
Current - Target AS Diff, ;
Current / Target * 100.00 AS Percent ;
FROM ;
Plans
Allerdings muß man diese Konstruktion gegen "Division durch 0" absichern.
Dies kann geschehen durch Ausschließen der betroffenen Datensätze:
SELECT ;
Target, ;
Current, ;
Current - Target AS Diff, ;
Current / Target * 100.00 AS Percent ;
FROM ;
Plans ;
WHERE ;
Target <> 0
Eine andere Variante ist die Umgehung der Berechnung für
den Fall "Target = 0":
SELECT ;
Target, ;
Current, ;
Current - Target AS Diff, ;
IIF( Target = 0, ;
0, ;
Current / Target * 100.00 ;
)
AS Percent ;
FROM ;
Plans
Eine weitere Spielart der letzeren Variante ist das Ersetzen der 0 in
der IIF()-Konstruktion durch .NULL..
Allerdings haben beide Varianten einen entscheidenden Nachteil: Trifft
der IF-Zweig der IIF()-Konstruktion bereits im ersten Datensatz zu, dann ensteht
bei der Verwendung von 0 eine einstelliges numerisches Feld und bei der
Verwendung von .NULL. wird der Laufzeitfehler "SQL: cannot
determine datatype of SQL Column (Error 1890)" erzeugt.
Abhilfe schafft hier die folgende Konstruktion:
* zunächst normales SQL ohne IIF(), um die richtigen Feldtypen anzulegen
SELECT ;
Target, ;
Current, ;
Current - Target AS Diff, ;
Current / Target * 100.00 AS Percent ;
FROM ;
Plans ;
INTO CURSOR ;
Temp1
IF _tally > 0
* Ergebnis-Sätze vorhanden
* -> Cursor erneut öffnen, um ihn beschreiben zu können
USE ( DBF() ) AGAIN IN 0 ALIAS Temp2
SELECT Temp2
REPLACE Percent WITH 0 FOR Target = 0
ENDIF
Diese Verfahrensweise benutzt die Verbindung von SQL-Statements mit "normalem"
FoxPro-Code unter Zuhilfenahme eines Tricks zum Beschreibbarmachen eines Cursors,
um den zutreffenden Feldtyp zu erzeugen.
Zu beachten ist allerdings, daß dies nicht mit Feldern vom Typ Currency funktioniert,
dort wird der Fehler "Currency value is out of range (Error 1988)"
erzeugt (ein Grund mehr, nicht mit diesem miserabel implementierten Datentyp
zu arbeiten)!
Als REPLACE-Befehl im obigen Beispiel kann natürlich auch ein
"REPLACE Percent WITH .NULL. FOR Target = 0"
verwendet werden, falls eines die Ursprungsfelder Target oder Current
Null-Werte unterstützt.
Die Abweichungsanalyse ist einsetzbar bei jeder Art von Daten.
Abweichungsanalyse Variante 2
Eine weitere Variante der Abweichungsanalyse dient der Ermittlung der datenseitigen
Homogenität einer Gruppe. Je mehr und je dichter die Ergebniswerte dieser
Analyse an 100% liegen, um so homogener ist die betreffende Gesamtheit.
Das folgende Beispiel zeigt die in der letzten Spalte die prozentualen Abweichungen
der Betriebe 1 bis 7 vom Durchschnitt der Gruppe.
Auch hierzu gibt es übersichtliche grafische Darstellungsmöglichkeiten:
Der Berechnungsalgorithmus dieser Variante ähnelt dem des Benchmarking, wobei
die Relationen der Einzelwerte nicht zum Bestwert, sondern zum Gruppendurchschnitt
gebildet werden:
* 1. Schritt: Ermitteln der Gruppendurchschnitte
SELECT ;
Product_Id, ;
AVG( Quantity ) Avg_Quant;
FROM ;
OrdItems ;
GROUP BY ;
Product_Id ;
INTO CURSOR ;
Avg1
* 2. Schritt:
SELECT ;
OrdItems.Product_Id, ;
OrdItems.Quantity / Avg1.Avg_Quant * 100.00 AS Percent;
FROM ;
OrdItems ;
INNER JOIN Avg1;
ON Avg1.Product_Id = OrdItems.Product_Id ;
ORDER BY ;
OrdItems.Product_Id, ;
Percent
Dieses Verfahren ist nur bei Daten zulässig, die im Sinne der Definition aus
Abschnitt "Die Auswertbarkeit von Daten" als "inhaltlich
homogen" zu bezeichnen sind.
Wachstums-Analysen
Wachstums-Analyse Variante 1
Eine einfache Form der Wachstums-Analyse ist der Vergleich zur Vorperiode (absolut
und in %).
Dabei wird der Algorithmus der Abweichungsanalyse Variante 1 auf etwas
andere Ausgangsdaten angewendet:
SELECT ;
Previous, ;
Current, ;
Current - Previous AS Diff, ;
Current / Previous * 100.00 AS Percent ;
FROM ;
TimeSeries
Alle Erweiterungen aus dem Abschnitt Abweichungsanalyse Variante 1
lassen sich auf diese Berechnung analog anwenden.
Die Wachtsumsanalyse Variante 1 ist bei jeder Art von Datenmengen einsetzbar
und liefert als Ergebnis Informationen darüber, in welche Richtung und in welcher
Größenordnung sich die betreffende Kennzahl über den betrachteten Zeitraum entwickelt
hat.
Betrachtet man dabei mehrere hintereinanderliegende Perioden, so erhält man
zusätzliche Tendenz-Aussagen.
Bei dieser Form der Wachstums-Analyse stellt man die Ergebnisse zweier Wachtsumsanalysen
der Variante 1 für zwei in Zusammenhang stehende Kennziffern gegenüber (z.B.
Umsatz und Nettogewinn vor Steuer).
Der folgende Programmquelltext zeigt das Prinzip der Ermittlung entsprechender
Werte:
SELECT ;
PreviousTurnover, ;
PreviousProfit, ;
CurrentTurnover, ;
CurrentProfit, ;
CurrentTurnover - PreviousTurnover AS DiffTurnover, ;
CurrentProfit - PreviousProfit AS DiffProfit, ;
CurrentTurnover / PreviousTurnover * 100.00 AS PercentTurnover, ;
CurrentProfit / PreviousProfit * 100.00 AS PercentProfit ;
FROM TimeSeries
Als Ergebnis erhält man Relationen der Wachstumskennziffern zueinander, die
Aufschluß über die Entwicklung eines Unternehmens geben können (wenn
z.B. der Umsatz schneller wächst als der Gewinn, dann sinkt die Rentabilität
des Unternehmens).
Ansonsten gelten alle Aussagen bezüglich der Wachtsumsanalyse Variante 1 analog
für die Variante 2.
Selektionen
Selektionen nach bestimmten Bedingungen sind eine einfache Form, bestehenden
Listen zu zusätzlichen analytischen Zwecken zu nutzen.
Programmtechnischer Hintergrund ist die Arbeit mit Filtern, der WHERE-Klausel
des SQL-Select-Befehls oder ähnlicher Mittel:
SELECT ;
Company, ;
MaxOrdAmt ;
FROM ;
Customer ;
WHERE ;
MaxOrdAmt < 5000
Bei kombinierten Selektionen werden mehrere Bedingungen miteinander verknüpft:
SELECT ;
Company, ;
MaxOrdAmt ;
FROM ;
Customer ;
WHERE ;
MaxOrdAmt < 5000 ;
AND ;
PostalCode > "10000"
Dabei können durchaus auch Relationen zwischen verschiedenen Kennzahlen einbezogen
werden:
SELECT ;
PreviousTurnover, ;
PreviousProfit, ;
CurrentTurnover, ;
CurrentProfit, ;
CurrentTurnover / PreviousTurnover * 100.00 AS PercentTurnover, ;
CurrentProfit / PreviousProfit * 100.00 AS PercentProfit ;
FROM ;
TimeSeries ;
WHERE ;
PercentProfit > PercentTurnover
Selektionen sind einsetzbar bei jeder Art von Datenmengen.
Ergebnis sind Untermengen der untersuchten Gesamtheit, die der vorgegebenen
Bedingung entsprechen.
Schlußbemerkung
Alle vorgestellten Verfahren und Methoden müssen im konkreten Einsatz sehr
sorgfältig auf die jeweiligen Bedingungen angepaßt werden. Außerdem kann die
Kombination verschiedener der Verfahren sinnvoll sein, um qualitativ hochwertige
Aussagen aus den zugrundeliegenden Daten ermitteln zu können. Viele der als
SQL-Statements aufgezeigten Verfahren lassen sich im konkreten Fall
mit wenig Aufwand auch als Views realisieren.
Bei weiterführendem Interesse kann zum Autor gern Kontakt aufgenommen werden
(E-Mail-Adresse: SFlucke@asci-consulting.com)
|