Fachspezialisten brauchen mehr SW-technische Unterstützung, denn:

Planungssprachen werden dem User kaum gerecht

23.10.1987

Die meisten der heute verfügbaren Planungssprachen bieten noch wenig Unterstützung oder Führung des Users. Vom Fachspezialisten wird vielfach eine Auseinandersetzung mit dem System gefordert, die weit über das Maß des Zumutbaren hinausgeht. Bodo Rieger* gibt einen Überblick über den State-of-the-Art und zeigt Perspektiven für die Zukunft auf.

Zur Beseitigung von Softwarekrise, Anwendungsstau sowie Informations- und Know-how-Defiziten in Unternehmen werden immer neue Generationen von Soft- und Hardware angepriesen. Ein Vertreter der Software der vierten Generation sind die sogenannten Planungssprachen. Sie erheben den Anspruch, direkt vom Mitarbeiter in der Fachabteilung ohne Einschaltung von DV-Spezialisten und weitestgehend auch ohne DV-Kenntnisse zu einer "Programmentwicklung neuen Stils" eingesetzt werden zu können.

Um dies zu gewährleisten, werden immer attraktivere und leichter zu bedienende Benutzeroberflächen in die Produkte integriert. Dies reicht von hausbackener Menüsteuerung und oft überfrachteter Maskentechnik bis zur beliebten Window-Technik, dem Einsatz der obligatorischen Maus und Touch-Screen. Dabei wird übersehen, daß der sogenannte Endanwender neben dem handwerklichen Umgang mit dem Terminal indirekt auch noch andere Aufgaben übernehmen muß, die bisher vom Anwendungsprogrammierer oder Systemanalytiker erfüllt wurden. Hierzu gehören zum Beispiel Analyse und Strukturierung des Problems, Konzeption und Implementierung eines rechnergestützten Modells sowie dessen Validierung und Test. Heutige Planungssprachen bieten für diese Aufgabe leider noch wenig Support oder Führung des Benutzers.

Einer der wenigen bereits realisierten Beiträge zur Entlastung des Fachspezialisten von einem Teil dieser klassischen DV-Aufgaben ist in der Nichtprozeduralität zu sehen. Sie soll dem Benutzer weitestgehend die Spezifikation der Abarbeitungsreihenfolge bei der Modellberechnung abnehmen. Dies kann angesichts der typischen Charakteristika von Planungssprachen in verschiedenen Schwierigkeitsstufen geschehen, so daß das Prädikat "nichtprozedural" in dieser undifferenzierten Form als Qualitätsmerkmal von Planungssprachen wenig aussagekräftig ist. Daraus ergeben sich folgende Fragen:

Ä Was charakterisiert Planungssprachen?

Ä Wie läßt sich Nichtprozeduralität klassifizieren?

Ä Wodurch kann volle Nichtprozeduralität erreicht werden?

Planungssprachen werden häufig mit Decision-Support-Systemen (DSS) gleichgesetzt. Dies ist jedoch aus wissenschaftlicher Sicht falsch. Die Forschung bezeichnet DSS als parametrisierte, modellbasierte und rechnergestützte Systeme für jeweils eine konkrete Problemstellung. DSS können je nach Problemcharakteristika auf verschiedensten methodischen Modell-Ansätzen basieren, zum Beispiel linearer Optimierung, Simulation oder Tabellenkalkulation Aber auch wissensbasierte DSS gehören dazu (Expertensysteme).

Um die DSS-spezifische Anforderung schneller, flexibler Erstellung durch Fachspezialisten mit geringen DV-Kenntnissen zu ermöglichen, werden Entwicklungswerkzeuge, sogenannte DSS-Generatoren, angeboten. Diese sind durch die Integration ausgewählter Methoden und Funktionen auf ganz bestimmte Problemklassen spezialisiert. Einen Vertreter dieser DSS-Generatoren stellen Planungssprachen dar. Sie zeichnen sich unter anderem aus durch eine Spreadsheet-Grundstruktur mit den Dimensionen Variablen und Zeit; Mehrdimensionalität zur Vervielfältigung dieser Grundstruktur nach weiteren Kriterien; hierarchische Konsolidierung zur additiven, mehrstufigen Verknüpfung dieser Grundmodelle und automatische Währungskonvertierung.

Mit diesen quasi vordefinierten Modellstrukturen qualifizieren sie sich für eine Problemklasse, die in der OSS-Forschung als "Analysis Information System" und "Accounting Models" bezeichnet wird. Diese Strukturen sind insbesondere in multinationalen oder Mehrproduktunternehmen zu finden. Das Nutzungsprofil von mit Planungssprachen erstellten Decision-Support-Systemen ist charakterisiert durch:

Ä flexible Selektion entscheidungsrelevanter Grunddaten aus zumeist vorhandenen, oft inhomogenen operativen Systemen, zum Beispiel der Finanzbuchhaltung, Auftragsabwicklung, Produktionsplanung und -steuerung;

Ä analytische, zumeist in mehrere Stufen und nach mehreren Dimensionen aggregierende Auswertungen, zum Beispiel Umsatzanalysen nach Produkten und Regionen oder Kostenanalysen nach Kostenarten und Kostenstellen;

Ä flexible Alternativrechnungen zur Untersuchung von Änderungen bei beeinflußbaren Größen des unternehmenspolitischen Instrumentariums, zum Beispiel Dispositionsverfahren, Rabattpolitiken.

Die Anwendung von derartigen Planungssprachen direkt durch den Fachspezialisten kann durch weitere Merkmale wesentlich unterstützt beziehungsweise effizienter gestaltet werden. In diesem Zusammenhang soll besonders auf eine nichtprozedurale Modelldefinition und damit zusammenhängende Fragen eingegangen werden:

Dem Fachspezialisten darf nicht zugemutet werden, sich mit der prozedural richtigen Reihenfolge der Berechnungen, zum Beispiel von Kennzahlen oder Verrechungssätzen, herumzuschlagen. Dies ist angesichts der Möglichkeiten der Mehrdimensionalität ein durchaus ernstzunehmendes Problem. Als Beispiel hierfür kann die Kostenstellenumlage dienen (siehe Abbildung 1).

Das Grundmodell oder Spreadsheet beseht aus Kostenarten über die Zeit. Es wird durch eine echte dritte Dimension für jede Kostenstelle vervielfacht und hierarchisiert. Während die Konsolidierung bereits durch die Definition der Kostenstellenhierarchie abgedeckt ist wird die Berechnungslogik in den Grundspreadsheets durch zeilen- und spaltenverknüpfende Regeln abgebildet. Diese Regeln sind im Unterschied zu den klassischen PC-Spreadsheet-Paketen als differenzierbare Vektorregeln ausgelegt, so daß sich für beliebige Modellteile gesonderte Rechenregeln spezifizieren lassen.

Werden im gewählten Beispiel nun die Endstellenkosten der Hauptkostenstelle 1 gesucht, so müssen zuerst die primären Stellenkosten der abgebenden Hilfskostenstelle (1) berechnet und entsprechend dem anteiligen Verbrauchswert als sekundäre Stellenkosten (3) der Hauptkostenstelle belastet werden. Hierzu muß zuvor die Summe der Verbrauchsserte aller empfangenden Kostenstellen (2) ermittelt werden. Nach Berechnung der primären Stellenkosten der Hauptkostenstelle (4) können dann die gesuchten Endstellenkosten (5) ausgegeben werden.

Schwierige Formen der Nichtprozeduralität

Diese Berechnungskette ist durch Vorwärtsverweise über die Variablen und die Konsolidierungshierarchie, bei mehrperiodischer Betrachtung zusätzlich über die Zeitdimensionen charakterisiert. Das betriebswirtschaftlich gesehen noch recht einfache Beispiel vereinigt dennoch bereits verschieden schwierige Formen der Nichtprozeduralität. Diese lassen sich, bezogen auf die Modellbausteine von Planungsprachen, mit Hilfe von drei Kriterien allgemein in sechs Stufen klassifizieren, und zwar nach der Anzahl betroffener Modelldimensionen, der Art betroffener Modelldimensionen und dem betroffenen Dimensionsintervall (siehe Abbildung 2).

Im einfachsten Fall (1) läßt sich der Vorwärtsverweis durch Umsortieren ganzer Zeilen, Spalten oder Konsolidierungsstufen auflösen. Im Fall (4) reicht diese Sortierung wegen der vektoriellen Spezifikation der Regeln schon nicht mehr aus. Hier muß eine Regel mindestens zweimal interpretiert und angewendet werden. Im kompliztertesten Fall muß die Berechnung zusätzlich zwischen Spreadsheets hin- und herspringen oder die, durch iterative Neuberechnung ganzer Spreadsheets simulieren. Dies ist bereits im Beispiel der Kostenstellenumlage gegeben.

Ein über alle Modelldimensionen funktions- fähiger Mechanismus zur automatischen Ermittlung der richtigen Berechnungsreihenfolgen kann den Anwender insofern erheblich entlasten, als dieser nur noch die Logik überschaubarer Teilschritte der Berechnung (nichtprozedural) spezifizieren muß.

Gerade im hier betrachteten Problemkreis betriebswirtschaftlicher Anwendungen können gewollt simultane Gleichungen auftreten, zum Beispiel bei der innerbetrieblichen Leistungsverrechnung, wenn also im obigen Beispiel die abgebende Kostenstelle einen Teil ihrer Leistungen selbst verbraucht oder gleichzeitig Leistungen anderer, empfangender Kostenstellen erhält. Diese simultanen Gleichungen sollte die Planungssprache automatisch erkennen, zur Kontrolle melden und selbständig lösen. Die beschriebenen Schwierigkeitsstufen der Nichtprozeduralität sind dabei auf die Simultangleichungen übertragbar.

Je Abfrage nicht alle Werte berechnen

Wie erwähnt, zeichnet sich das Nutzungsprofil von Decision-Support-Systemen durch flexible und selektive Ad-hoc-Auswertungen auf häufig aggregiertem Niveau aus. Das heißt, daß einerseits je Abfrage nicht immer alle möglichen Werte des Modells berechnet werden müssen, und daß andererseits bei jeder Abfrage die jeweils aktuellsten Basiswerte verwendet werden sollten. Um die berechnete Datenmenge zu minimieren und den Benutzer von Steuerungssaßnahmen zu entlasten, kann ein "Pull-Prinzip" zur Berechnung hilfreich sein. Dahinter verbiryt sich der Gedanke, daß, ausgehend von den in den Auswertungen benötigten Ergebnisfeldern, quasi rückwärts nur die zu ihrer Ermittlung notwendigen Größen berechnet werden, und zwar auch nur dann, wenn sie entweder noch nicht vorhanden sind oder in die Berechnung eingehende Basiswerte seit der letzten Berechnung geändert wurden.

Leistungsfähige Komponente zur Berechnungssteuerung

Die beschriebenen Postulate erfordern in Planungssprachen eine leistungsfähige Komponente zur automatischen Berechnungssteuerung. Diese Komponente kann für einfache Fälle mit Sortier- und iterativen Algorithmen auskommen. Eine umfassendere, wenn auch vielleicht langsamere Lösung bietet der Rückgriff auf Methoden, die im Bereich der Künstlichen Intelligenz unter dem Begriff Schlußfolgerungsmechanismus (Inferenz) als Forward-Chaining und Backward-Chaining eingesetzt werden.

Die Künstliche Intelligenz ist ein schon recht alter Forschungszweig, der sich generell mit der rechnergestützten Nachahmung menschlichen Problemlösugsverhaltens beschäftigt und dessen Wurzeln in viele Disziplinen reichen. Zu seinen Arbeitsgebieten gehören so heterogene Bereiche wie Spracherkennung, Robotik, Theorem-Beweise oder Computer-Vision. Prominentestes Anwendungsgebiet der jüngsten Zeit sind die sogenannten Expertensysteme, oder genauer gesagt wissensbasierten Systeme, in denen das Fakten- und Erfahrungswissen von Experten gespeichert und für verschiedene Fragestellungen aus unterschiedlichsten Sichten flexibel angewendet werden kann. Dies wird, vereinfacht gesprochen, dadurch erreicht, daß im Gegensatz zu konventionellen DV-Programmen ein Teil der Logik, nämlich der problembezogene Teil, nicht fest in den prozeduralen Algorithmus eingebettet, sondern ähnlich wie Daten in einer Wissensbank gespeichert wird. Diese Wissensbasis kann dann mit einer Softwarekomponente zur Wissensakquisition leicht erweitert und gepflegt werden, ohne daß eine Programmierung im strengen Sinne erforderlich wäre. Zur Darstellung des Wissens wurden verschiedene Repräsentationsmechanismen entwickelt, von denen hier nur einfachste und intuitiv verständlichste, nämlich die sogenannten Produktregeln erwähnt werden. Sie weisen die Form "WENN Prämisse erfüllt, DANN führe Konklusion aus" auf.

Konfliktlösung bei konkurrierenden Regeln

Als fest programmierter Bestandteil von Expertensystemen verbleibt eine theoretisch weitgehend problemunabhängige Problemlösungskomponente. Diese enthält Methoden und Techniken zum Beispiel zur Mustererkennung, Konfliktlösung bei konkurrierenden Regeln sowie Suchstrategien und die bereits erwähnten Grundprinzipien des Schlußfolgerns. Expertensysteme beziehungsweise Entwicklungswerkzeuge hierfür bestehen somit mindestens aus Wissensbasis, Problemlösungs-, Wissensakquisitions- sowie Dialogkomponente.

Bei modernen Planungssprachen spielen im Augenblick lediglich die Inferenzmechanismen, insbesondere das Backward-Chaining eine Rolle. Beim Backward-Chaining (zielgetriebene Strategie) wird die Wissensbasis ausgehend vom Zielparameter nach Regeln durchsucht, deren Konklusionsteil den Zielwert liefert. Kann eine Regel nicht angewendet werden, weil ihre Prämisse nicht erfüllt ist, wird diese Prämisse zum Unterziel erklärt und hierfür eine anschließende Regel gesucht. Dies wiederholt sich solange, bis der Zielparameter bestimmt werden kann oder bis keine Regeln mehr anwendbar sind. Beim Forward-Chaining (datengetriebene Strategie) werden umgekehrt alle Regeln ausgeführt, deren Prämissen aufgrund von eingegebenen oder erschlossenen Fakten anwendbar sind.

Mit sehr einfacher Wissensbasis konfrontiert

Bei zellenweiser Anwendung der Rückwärtsverkettung in der Berechnungssteuerung können die gestellten Anforderungen bezüglich Nichtprozeduralität und Pull-Prinzip vollständig erfüllt werden. Damit wird eine Planullgssprache jedoch noch lange nicht zu einer Expertensystem-Shelle. Die "Problemlösungskomponente" sieht sich nämlich mit einer im Vergleich zu Expertensystemen sehr einfachen "Wissensbasis" konfrontiert. Die Vereinfachungen bestehen darin, daß der Anwender praktisch keine alternativen Berechnungsteilschritte spezifizieren kann und somit eine Konfliktlösungskomponente hinfällig ist. Auf der anderen Seite muß bei Berechnungsschleifen eine Prozedur zur Lösung simultaner Gleichungen angestoßen werden, eine Eigenschaft, die in Expertensystemen normalerweise nicht vorhanden ist.

In heutigen Planungssprachen werden die berechneten Ergebnisse intern in einer eigenen Ergebnis-Tabelle gespeichert, so daß sie bei späteren Abfragen nicht neu berechnet werden müssen. Bei Änderung der Eingabedaten muß nun natürlich dafür gesorgt werden, daß alle direkt und indirekt betroffenen Ergebniswerte gelöscht beziehungsweise für ungültig erklärt werden, damit bei Abfragen dieser Werte automatisch eine Neuberechnung ausgelöst wird. Dies kann durch einen speziell angepaßten Forward-Chainer realisiert werden.

Durch Anwendung dieser fundamentalen Schlußfolgerungsmechanismen kann somit erreicht werden, daß der Anwender sich weder bei Modelldefinition noch bei Ergebnisausgabe Gedanken über Reihenfolge und Steuerung der Berechnung machen muß. Er kann sich vielmehr voll auf die schrittweisen Beschreibungen seines Problems konzentrieren.

Angesichts der beschriebenen Vorgehensweise ist unmittelbar einsichtig, daß Berechnungen derartig nichtprozeduraler Modelle umso länger dauern, je "verkehrter" die Regeln sortiert sind, da sich im einfachsten Fall die Suche nach anwendbaren Regeln an der Eingabereihenfolge orientiert.

Erhebliche Sorgfalt bei Modellspezifikation

Ein Verzicht auf die Rückwärtsverkettung macht die Modelle zwar schneller, erfordert jedoch erhebliche Sorgfalt bei der Modellspezifikation, um richtige Ergebnisse zu erhalten. Er birgt zudem den Nachteil in sich, daß derartige prozedurale Modelle änderungsunfreundlicher werden, da sich die Berechnungen einer Zeile auf verschiedene Stellen der Spezifikation verteilen müssen. Man muß wieder von einem prozeduralen Programm sprechen.

Trotz Einsatz von Backward- und Forward-Chaining können derartig flexibel gesteuerte Planungssprachen keineswegs als Expertensysteme bezeichnet werden. Zum einen beschränken sie sich ausschließlich auf die Verarbeitung numerischer Werte in eindeutigen, sicheren definitorischen Zusammenhängen, zum anderen fehlen weitere charakteristische Merkmale, insbesondere eine leistungsfähige Erkl_RUngskomponente. Deren Funktion besteht darin, zu definierten Zeitpunkten innerhalb des Problemlösungsprozesses, regelmäßig dann, wenn Benutzereingaben bedarfsweise nachgefordert oder (Zwischen-)Ergebnisse ausgegeben werden, WHY- und HOW-Fragen an das System stellen zu können.

Aufbereitete Darstellungen

Die dadurch aktivierte Erkl_RUngskomponente liefert dann unter Rückgriff auf die Wissensbasis Erkl_RUngen, warum ein bestimmter Wert nachgefragt wird beziehungsweise wie bestimmte Werte ermittelt wurden. Im einfachsten Fall geschieht das durch aufbereitete Darstellungen der bisher angewendeten Regeln. Dadurch wird der Problemlösungsprozeß in allen seinen Einzelschritten unmittelbar transparent und nachvollziehbar.

Dieses Prinzip kann auch in Planungssprachen zukünftig aus mehreren Gründen von Nutzen sein:

Ä Die Ursachenforschung von "auffälligen" Ergebniswerten kann auch ohne genaue Kenntnis beziehungsweise aktive Einarbeitung in die Modellstruktur flexibel durchgeführt werden. Dies ist zum Beispiel relevant, wenn Entwickler und Anwender nicht dieselbe Person sind oder der Entwickler sich nach drei Monaten nicht mehr so recht erinnern kann, was er seinerzeit "programmiert" hat. Eine Dokumentation wird bei Planungssprachen leicht für überflüssig gehalten.

Ä Die Modellvalidierung wird wesentlich unterstützt, indem die einzelnen Berechnungsschritte zellenbezogen expliziert werden. Dies spielt gerade bei großen, konsolidierten und mit vielen Kennzahlen gespickten Modellen eine erhebliche Rolle. Eigene Erfahrungen im Einsatz von Planungssprachen haben immer wieder gezeigt, daß bei langen, durch Vorwärtsverweise geprägten Berechnungsketten kein Entwickler sich der Vollständigkeit seiner deskriptiven Spezifikation sicher sein kann. Daß diese Probleme schon bei kleinen Anwendungen auftreten können, dürfte das eingangs geschilderte Beispiel hinreichend verdeutlicht haben.

Probleme schon bei kleinen Anwendungen

Trotz der geschilderten, offensichtlichen Vorzüge des wissensbasierten Ansatzes darf daraus auf keinen Fall der Schluß gezogen werden, nunmehr alles in dieser Technik realisieren zu wollen. Dazu sind Planungssprachen viel zu sehr auf die Eigenheiten der speziellen Problemklasse zugeschnitten (Konsolidierung, Währungskonvertierung). Der Aufwand zu entsprechender Modellbildung in Expertensystemen wäre aufgrund fehlender vergleichbarer Modellierungskonstrukte viel zu hoch. Diese müßten dort erst mühsam selbst erzeugt werden. Andererseits würden dort verfügbare Konzepte durch die vergleichsweise simple Tabellenkalkulation überhaupt nicht gefordert. Die Vorzüge von Expertensystemen können sich erst voll entfalten, wenn auch wirkliche Probleme damit behandelt werden, für die die implementierten Konzepte erdacht wurden. Der hier hergestellte Bezug bestand lediglich darin, ausgewählte Methoden, die sowohl in Expertensysteme als auch bereits ansatzweise in Planungssprachen eingebaut wurden, in ihrer Wirkung und ihrer Bedeutung transparenter zu machen.

Integration vorantreiben

Insgesamt soll dafür plädiert werden, die begonnene Integration von in der Künstlichen Intelligenz bewährten Techniken in Planungssprachen zielstrebig weiter voranzutreiben. Anstatt alle Probleme mit einem Werkzeug bewältigen zu wollen, sollten die Vorteile beider Technologien durch Kombination von Decision-Support-Systemen, die je nach Problemstellung in der einen oder anderen Technik realisiert sind, synergetisch genutzt werden. Dies erfordert freilich offene Systeme und damit auch offene Decision-Support-System-Generatoren, eine Eigenschaft, in der Planungssprachen bereits heute den Expertensystemen um Längen voraus sind.

*Dr. Bodo Rieger ist wissenschaftlicher Mitarbeiter im Fachgebiet Systemanlage und EDV an der Technischen Universität Berlin.