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.

Wachstums-Analyse Variante 2

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)