Nach einer gründlichen Voruntersuchung entschloß sich die Bayerische Hypotheken- und Wechsel-Bank mit Hilfe der HMT GmbH ein Hilfesystem für ihre OS/2-1.3-Anwendungen, die unter der Benutzeroberfläche Presentation Manager laufen, zu realisieren. Dabei wurden die meisten der beschriebenen Anforderungen realisiert. Auf Host-Seite existierte bereits ein leistungsfähiges Hilfesystem mit direkter Anbindung an das Data-Dictionary und zentraler Bereitstellung der Hilfetexte für alle Host-Anwendungen. Hilfetexte werden dabei in DCF, einem Dokumentenverwaltungssystem, erfaßt und in einer Datenbank zentral bereitgestellt.

Funktionen zur Verwaltung und Verknüpfung von Hilfetexten mit einer Anwendung standen damit bereits zur Verfügung und mußten nur noch um PC-spezifische Komponenten ergänzt werden. Auf PC-Seite gibt es die Information-Presentation-Facility (IPF) des Presentation-Managers. IPF ist ein System zur Erstellung und Darstellung von Dokumenten und Hilfetexten, das eine Programmierschnittstelle zur Integration von Hilfetexten in eine Anwendung anbietet. Bei Hilfeanfragen wird ein spezielles Fenster mit dem Hilfetext geöffnet.

Darin stehen eine Reihe von Funktionen wie Index, Inhalt etc. zur Verfügung. Die Benutzerschnittstelle von IPF kann als sehr gelungen bezeichnet werden. Leider gilt dies nicht für die Programmierschnittstelle. Für die richtige Beantwortung von Hilfeanfragen muß erheblicher Aufwand getrieben werden, da IPF nicht in der Lage ist, selbständig die richtige Verknüpfung zwischen Fenster, Fensterobjekt und Hilfetext in allen Situationen herzustellen.

Die in diesem Zusammenhang angebotene Schnittstelle weist erhebliche Fehler und Mängel auf. Sie mußte durch eine recht aufwendige eigene Schnittstelle ergänzt werden, um die einzelnen Programme von der Bearbeitung von Hilfeanfragen zu entlasten. Ein anderer Schwachpunkt ist die Form der Bereitstellung von Hilfetexten. Im Prinzip muß für jede Anwendung ein kompletter Satz von Dateien mit Hilfetexten bereitgestellt werden. Die Anforderung nach Redundanzfreiheit ist also nicht erfüllt - mit allen negativen Konsequenzen.

Als weiterer Schwachpunkt muß die Inkompatibilität zwischen DCF- und IPF-Syntax angesprochen werden, die besteht, obwohl beide Systeme syntaktisch große Ähnlichkeit haben. Wir mußten ein auf. wendiges Konvertierungsprogramm entwickeln, um in DCF erfaßte Texte in IPF-Texte umzuwandeln. Es ist ein großer Mangel, daß hier nicht für Kompatibilität gesorgt wurde. Weitere Schwierigkeiten bereiteten eine Vielzahl von Fehlern in IPF. Ein Support seitens IBM war praktisch nicht verfügbar.

Zusammenfassend kann bezüglich IPF gesagt werden, daß es zwar eine gute Anwendersicht präsentiert, daß aber die Programmierschnittstelle schlecht ist und Aspekte der Host-PC-Integration gar nicht berücksichtigt wurden. Leider sind diese Schwachpunkte von IPF auch in der neuen Version 2.0 von OS/2 nicht behoben.

Wolfhard von Thienen ist Mitarbeiter des Geschäftsbereiches Software-Entwicklung bei der HMT Informationssysteme GmbH in Grasbrunn bei München.

In modernen DV-Anwendungen spielen Ergonomie und Benutzerfreundlichkeit eine immer größere Rolle. Besonders PC-Anwendungen mit Fenster- und Maustechnik haben hier in den letzten Jahren Maßstäbe gesetzt. Ein wichtiger, aber leider oft vernächlässigter Aspekt der Benutzerfreundlichkeit, so Wolfhard von Thienen, ist eine leistungsfähige Online-Hilfe.

Anwendungen, die auf Großrechnersystemen laufen, sind fast immer mit einem leistungsfähigen Hilfesystem ausgestattet. Dabei hat sich die DV-Infrastruktur im Großrechnerbereich in der Regel über Jahre hinweg entwickelt. Das Hilfesystem ist in diese Infrastruktur in Form von Standards, Schnittstellendefinitionen und Werkzeugen integriert.

Im PC-Bereich herrscht dagegen eher ein Wildwuchs vor. jede Anwendung arbeitet mit einem eigenen Hilfesystem. Zwar haben sich gewisse Standards der Benutzerführung etabliert, so läßt sich etwa in den meisten Anwendungen über die F1-Taste eine Hilfemeldung aufrufen, doch bei der Gestaltung und beim Inhalt dieser Hilfen regiert ebenso das Chaos wie bei der Form der Speicherung von Hilfetexten, bei den Programmierschnittstellen etc.

Ein Unternehmen, das eine Vielzahl verschiedener DV-Anwendungen auf Host- und PC-Systemen einsetzt, muß sich deshalb grundsätzlich Gedanken darüber machen, wie ein konsistentes und möglichst leicht wartbares Hilfesystem für das Unternehmen zu realisieren ist. Auf jeden Fall sind solche Insellösungen zu vermeiden, die für jede Anwendung beziehungsweise jede Systemebene eigene und inkompatible Hilfen verwenden.

Hilfesysteme sind immer dreidimensional. Die Anwendersicht definiert, in welcher Form Hilfe-Funktionen präsentiert werden und wie ein Anwender damit kommuniziert. Hierzu gehören allgemeingültige Standards der Benutzerführung, die Form der Präsentation von Hilfe sowie inhaltliche und formale Aspekte. Dabei ist es notwendig dafür zu sorgen, daß die Anwendersicht in allen Programmen des Unternehmens immer die gleiche ist.

Drei Sichtweisen sind zu unterscheiden

Die logisch-abstrakte Sicht definiert, wie das Hilfesystem in das Datenmodell des Unternehmens zu integrieren ist. Zwischen den Objekten der Datenwelt und denen des Hilfesystems bestehen enge Beziehungen, die im Datenmodell ihren Ausdruck finden müssen.

Systeme und organisatorischen Maßnahmen, die notwendig sind, um ein funktionsfähiges Hilfesystem bereitzustellen und zu warten, definiert die technische Sicht. Hierzu gehören Programmierschnittstellen sowie Systeme und Werkzeuge, die notwendig sind, um das Hilfesystem zu verwalten. Weiterhin wird in der technischen Sicht die Integration des Hilfesystems in die Organisations- und Verwaltungsstruktur des Unternehmens festgelegt.

Selbstverständlich sind alle drei Sichten eng miteinander verzahnt und müssen eine sinnvolle Einheit bilden. Dennoch spiegeln sich bei der Formulierung von Anforderungen an ein, Hilfesystem die drei oben genannten Aspekte wider.

Aus Anwendersicht steht die Verwendung von Standards im Vordergrund. Host- und PC-Syteme sollten dabei weitgehend übereinstimmen. Die Standards haben unternehmensweit zu gelten, wobei bei der Formulierung von Unternehmensrichtlinien auf allgemeingültige Standards zurückzugreifen ist - sofern diese existieren.

Unabdingar ist auch, daß Anwender die Hilfefunktion durch einfache Aktionen (Tastendruck, Mausklick) aus jeder Situation heraus aufrufen können. Die Meldung muß klar und übersichtlich präsentiert werden, weshalb ein Hilfesystem über eine Vielzahl von Möglichkeiten der Textdarstellung verfügen sollte. Hierzu gehören unter anderem verschiedene Text. und Farbformate sowie Gliederung, Fußnoten und Grafik. Auf dem PC sollte die Hilfefunktion mit Fenstertechnik angeboten werden.

Die Fenster und Masken einer Anwendung sind die wichtigste Schnittstelle zwischen Anwender und Programm. Während die Masken einer herkömmlichen Host-Anwendung in der Regel nur einzeln auf den Bildschirm gebracht werden, lassen sich in einer modernen PC-Anwendung mehrere Fenster gleichzeitig öffnen.

Jede Maske und jedes Fenster repräsentiert einen oder mehrere Arbeitsschritte. In den Masken und Fenstern führt der Anwender alle Aktionen wie Eingaben, Auswahl und so weiter durch, die zu dem betreffenden Arbeitsschritt gehören.

Für jedes Objekt ein spezifischer Hilfetext

Wegen ihrer zentralen Bedeutung ist es daher nur natürlich, daß für jede Maske und jedes Fenster eine eigene Hilfe angeboten wird, in der der Anwender erfährt, welche Aufgaben er durchfuhren kann.

Für jedes Objekt eines Fensters beziehungsweise einer Maske, das der Anwender ansteuern kann, muß ein spezifischer Hilfetext verfügbar sein. Wählt der Anwender ein Objekt, zum Beispiel ein Eingabefeld, mit der Maus oder der Tastatur aus, so kann er dazu eine spezifische Hilfe anfordern.

Hilfetexte, die sich auf das gleiche Objekt beziehen, müssen inhaltlich identisch sein. Viele Objekte aus der Datenwelt eines Unternehmens treten innerhalb einer Anwendung sowie in unterschiedlichen Anwendungen mehrfach auf. Um den Anwender nicht jedesmal mit neuen Hilfetexten zu verwirren, müssen die Hilfetexte identisch sein.

Alle Hilfetexte sollten automatisch in eine Inhaltsliste aufgenommen werden. Der Anwender kann sich diese Liste anzeigen lassen und daraus Texte, die ihn interessieren, auswählen. Ebenfalls sollte es die Möglichkeit geben, bestimmte Begriffe in einen Index aufzunehmen. Dieser, kann ebenfalls angezeigt werden und der Anwender hat die Möglichkeit, aus der Liste einen Begriff auszuwählen und in den Hilfetext zu verzweigen, in dem dieser Begriff vorkommt und markiert ist. Der Index muß mehrstufig sein, das heißt er muß die Möglichkeit bieten, Indexbegriffe zu gruppieren und zu gliedern.

Bestimmte Begriffe sollten in einem Hilfetext markiert werden können. Wählt der Anwender diesen Begriff mit Maus oder Tastatur an, wird in einen anderen Hilfetext verzweigt, in dem weitere Informationen zu finden sind. Auf diese Weise läßt sich ein komfortables System untereinander vernetzter und sich ergänzender Hilfetexte schaffen.

Moderne PC-Software wird immer häufiger mit Lernhilfen ausgestattet. Zudem gibt es inzwischen für viele PC-Anwendungen regelrechte Lernprogramme, die mit entsprechender Software erstellt werden können (Computer Based Training). Lernhilfen und Lernprogramme dienen dazu, das Programm in eigener Regie interaktiv zu erlernen.

Der Aufwand, eine Lernhilfe oder ein Lernprogramm zu erstellen, ist allerdings trotz moderner Hilfsmittel recht hoch und kommt wohl nur dann in Frage, wenn die Anwendung für eine große Zahl von Benutzern vorgesehen ist - nur dann lohnt sich der große Aufwand.

Zu einem Hilfesystem gehört auch eine Schnittstelle zu einem Nachrichten- und Fehlersystem, damit zu jeder Nachricht beziehungsweise zu jeder Fehlermeldung ein Hilfetext angefordert werden kann. Darin können Informationen über die Ursache der Meldung stehen und Hinweise auf die zu ergreifenden Maßnahmen gegeben werden.

Schnittstelle zu externen Programmen schaffen

Hilfetexte sollten auf jeden Fall vom Anwender ausgedruckt und kopiert werden können, damit er sie auch außerhalb des Programms verwenden kann. Außerdem ist eine Schnittstelle zu externen Programmen von Vorteil, damit sich diese Programme aus dem Hilfesystem heraus aktivieren lassen. Existiert eine derartige Schnittstelle, so läßt sich das Hilfesystem eines Programms leicht um spezifische Zusätze erweitern. Denkbar wäre zum Beispiel der Aufruf eines Kommunikationsprogramms, mit dem der Anwender eine Frage zum Programm in einer Mailbox ablegen kann.

Der Benutzer sollte die Möglichkeit haben, eigene Hilfetexte zu erstellen beziehungsweise Hilfetexte mit Notizen zu versehen und aktiv mitzugestalten. Beispielsweise kann er eine Liste wichtiger Bedienungsinformationen erstellen, die es ihm ermöglicht, sich nach längerer Pause wieder schnell in das Programm hineinzufinden.

Hohe Anforderungen an die Hilfetexte

Sollen alle Vorteile eines Hilfesystems voll ausgeschöpft werden, so sind hohe Anforderungen an die inhaltlichen und didaktischen Qualitäten der Hilfetexte zu stellen. Zu diesem Zweck ist geschultes Personal - zum Beispiel ein technischer Redakteur - einzusetzen, das in der Lage ist, sich gründlich in den technischen und fachlichen Hintergrund einer Anwendung einzuarbeiten und diesen für den Anwender transparent zu machen.

Nur in Ausnahmefällen sollten mit dieser Aufgabe Personen betraut werden die direkt mit der Entwicklung der Anwendung zu tun hatten. Diese bringen in der Regel nicht genügend Distanz auf und haben Schwierigkeiten, sich in den Anwender hineinzuversetzen. Die Akzeptanz einer Anwendung hängt aber stark von der Benutzerfreundlichkeit ab, in der das Hilfesystem eine wichtige Komponente ist.

Hilfetexte sollten nicht funktionell, sondern objektbezogen definiert werden. Aus logischabstrakter Sicht hat Hilfe immer einen funktionellen und einen objektbezogenen Aspekt.

Hilfesystem in das Datenmodell integrieren

Diese beiden Gesichtspunkte ergeben sich unmittelbar aus der logisch-abstrakten Sichtweise des Datenmodells. Darin sind die Objekte, die für das Unternehmen von Bedeutung sind und über die es Daten speichern möchte als Entitäten definiert.

Weiterhin definiert das Datenmodell die Beziehungen, die zwischen den Entitäten bestehen. Dem Anwender werden diese Objekte im Rahmen einer DV-Anwendung präsentiert. Er kann sie hier auswählen, ihre Dateninhalte betrachten oder verändern. Wir haben es also einerseits immer mit dem Objekt selbst zu tun, andererseits damit, was der Anwender mit dem Objekt tun kann.

Redundanz wird vermieden

Der objektbezogene Aspekt ist statisch, der funktionelle situationsabhängig. Fordert der Anwender Hilfe an, so erwartet er einerseits eine Erklärung des Objektes mit dem er sich gerade beschäftigt, andererseits möchte er wissen, was er mit dem Objekt in seiner besonderen Situation machen kann.

Beschäftigen wir uns zunächst mit dem objektbezogenen Aspekt. Wie oben ausgeführt, sollten Hilfetexte in gleichen Objekten auch inhaltlich identisch sein.

Diese Anforderung ergibt sich zwingend aus der Notwendigkeit einer konsistenten Benutzerführung. Auch aus technischer Sicht entstehen erhebliche Vorteile.

Redundanz wird vermieden, die Erfassung, Verwaltung und Speicherung von Hilfetexten ist weniger kompliziert und auch die Programmierschnittstelle läßt sich einfach gestalten. Wird auf den Objektbezug verzichtet, so ergeben sich massive technische Probleme.

Wie sieht es nun mit dem funktionellen beziehungsweise situationsbezogenen Aspekt aus? Wir vertreten die These, daß auf situationsbezogene Hilfe gänzlich verzichtet werden kann und sollte. Funktionelle Aspekte ergeben sich zum Beispiel daraus, daß nur bestimmte Wertebereiche für die Eingabe erlaubt sind oder daß ein Objekt situationsbedingt verschiedene Stati annehmen kann. Beispielsweise kann eine Eingabe in ein bestimmtes Feld nicht vorgenommen werden, bevor ein anderes Eingabefeld zuvor gefüllt wurde.

Das Datenmodell muß fehlerfrei sein

In Host-Anwendungen sind die situationsbedingten Aspekte relativ gut überschaubar, da wir es hier in der Regel nur mit Eingabefeldern zu tun haben. Anders sieht es bei PC-Anwendungen aus, wo ein Objekt in den verschiedensten Formen dargestellt werden kann - zum Beispiel als Eingabefeld, als List-Box, als Radio-Button etc. Zusätzlich lassen sich die Abhängigkeiten der Objekte untereinander auf sehr komplexe Weise darstellen.

Soll auf eine situationsbezogene Hilfe verzichtet werden, so muß man sich allerdings an gewisse Regeln halten: Das Datenmodell hat fehlerfrei zu sein. Wenn der Eindruck ensteht, ein Objekt brauche in einem bestimmten Programm eine andere objektbezogene Hilfe als in anderen Anwendungen, dann liegt wahrscheinlich ein Fehler im Datenmodell vor und man muß ein neues Objekt mit eigenem Hilfetext definieren.

Allgemeine technische Aspekte der Bedienung einer Anwendung werden in der Regel durch eine Benutzerschulung abgedeckt. Es ist einleuchtend, daß nicht in jedem Hilfetext zu einem Objekt, das in Form einer List-Box dargestellt wird erklärt werden kann, wie diese zu bedienen ist.

Objektzustände und -abhängigkeiten werden im Hilfetext zum Fenster beziehungsweise zur Maske erklärt. Wir lassen also ausdrücklich bei Hilfetexten zu Fenstern und Masken funktionelle Aspekte zu. Dies ist einleuchtend, da Fenster und Masken im wesentlichen die funktionellen Aspekte einer Anwendung repräsentieren. Situationsbedingte Eingabe- und Bedienungsfehler sowie Bedienungshinweise müssen durch ein entsprechendes Fehler- und Nachrichtensystem abgedeckt werden. In den Hilfetexten zu diesen Fehlern und Nachrichten stehen dann weitergehende Erläuterungen.

In jedem Anwendungssystem sollte es Prompting-Mechanismen geben, die es gestatten, dem Anwender Werte zur Auswahl anzubieten. Dadurch werden Wertebereichsfehler automatisch verhindert. In PC-Anwendungen existieren derartige Systeme bespielsweise in Form von List-Boxen.

Ein anderes Problem, das besonders in PC-Anwendungen auftritt, sind Objekte in einem Fenster, die keine Beziehungen zu den Entitäten des Datenmodells haben. Hierzu gehören Steuerungselemente wie zum Beispiel der OK-Button oder das Menü des Fensters. Mit ihnen steuert der Anwender das Programm und bestimmt, ob und welches Fenster geöffnet Wird, weiche Einstellungen gelten und so weiter. Diese Objekte sind als wichtige Bestandteile eines Fensters mit einer entsprechenden Hilfe zu versehen.

Die Lösung dieses Problems kann zum Beispiel darin liegen, das Data-Dictionary um die Entität "Technisches Objekt" zu erweitern und alle derartigen Objekte unternehmensweit im Data-Dictionary zu definieren. Dadurch ist gewährleistet, daß zum Beispiel der OK-Button unternehmensweit immer die gleiche Bedeutung und den gleichen Hilfetext erhält.

Anforderungen aus technischer Sicht

Kommen wir zur technischen Sicht und damit insbesondere zur Schnittstelle zwischen Anwendungsprogrammen und dem Hilfesystem. Die ideale Programmierschnittstelle wäre natürlich ein System, das komplett selbständig abprüft, auf welchem Terminal, in welcher Anwendung, zu welchem Objekt gerade Hilfe angefordert wird und dann selbständig dafür sorgt, daß der richtige Hilfetext an die richtige Stelle geleitet und dort dargestellt wird. Solche Systeme sind mit entsprechendem Aufwand durchaus realisierbar.

Wir wollen uns hier aber mit einer etwas einfacheren Forderung begnügen: Abgesehen von einer Initialisierung beziehungsweise einer Anmeldung an das Hilfesystem dürfen keine Situationen auftreten, die im Zusammenhang mit Hilfe stehen und eine Bearbeitung durch das Anwendungsprogramm erforderlich machen. Mit anderen Worten: Das Hilfesystem muß eine Black-Box sein.

Damit dies funktioniert, muß selbstverständlich eine Verbindung zwischen Hilfesystem und Anwendung existieren, die definiert, zu welchem Objekt der Anwendung ein bestimmter Hilfetext gehört. Dies kann beispielsweise eine Tabelle sein, die die einzelnen Objekte der Anwendung mit den zugehörigen Hilfetexten über bestimmte Schlüssel verknüpft.

Voraussetzung ist, daß sowohl in der Anwendung als auch in den Hilfetexten eindeutige Schlüssel verwendet werden, die die Objekte beziehungsweise Hilfetexte identifizieren. Wenn man sich vergegenwärtigt, daß die Anwendung eines Unternehmens möglicherweise mehrere hundert Objekte verwendet, die von den Programmierern verwaltet und mit dem Hilfesystem verbunden werden müssen, so ist leicht einzusehen, daß hierfür ein entsprechendes Verwaltungssystem erforderlich ist. Andernfalls geht die Übersicht und Wartbarkeit schnell verloren.

Wird die Forderungen der Objektbezogenheit von Hilfetexten erfüllt, kann das System zur Verwaltung der Verknüpfungen über das Data-Dictionary wahrgenommen werden. Die Verknüpfungstabellen lassen sich automatisch aus dem Data-Dictionary erzeugen. Weiterhin können Hilfetexte und Anwendungsprogramme automatisch mit den von ihnen benötigten Schlüsseln versehen werden.

Redundanzen müssen eingeschränkt werden

Zur Erfassung und Bearbeitung von Hilfetexten muß es außerdem ein komfortables System geben. Ideal wäre, wenn zu diesem Zweck gängige Textverarbeitungsprogramme verwendet werden könnten. Auch ist ein System zu schaffen, durch das einzelne Hilfetexte von mehreren Anwendungen gemeinsam genutzt werden können.

Weiter oben haben wir die Objektbezogenheit von Hilfetexten erläutert. Es liegt nahe, jeden Hilfetext für ein Objekt auch nur einmal für alle Anwendungen des Unternehmens in einer gemeinsamen Datenbasis physikalisch bereitzustellen. Wird darauf verzichtet, entsteht eine erhebliche Redundanz mit allen damit verbundenen Problemen.

Eines dieser Probleme, das besonders im Zusammenhang mit PC-Anwendungen auftritt, ist das der Bereitstellung von Hilfetexten für die Anwendungen des Unternehmens. Großunternehmen, besonders Banken, stehen in einem ständigen Datenaustausch mit ihren Niederlassungen. Einige dieser Filialen sind über leistungsfähige Standleitungen mit der Zentrale verbunden, andere, zum Beispiel in ländlichen Gebieten, sind nur über relativ langsame DFÜ-Verbindungen erreichbar.

Hinzu kommt, daß Hilfetexte in der Regel recht umfangreich sind und die DFÜ-Mechanismen entsprechend belasten. Sollen die Anwendungen, die draußen in den Filialen laufen, mit Hilfetexten versorgt werden, so sind Redundanzen auf ein Minimum zu reduzieren, denn nur so lassen sich DFÜ-Engpässe vermeiden. Das kann auf zweierlei Weise geschehen:

1. Hilfetexte werden zentral auf dem Host in einer Datenbank bereitgestellt, und bei jeder Hilfeanfrage wird eine entsprechende Transaktion ausgelöst. Dadurch sind Hilfetexte immer in der gerade aktuellen Version sowohl für Host-Anwendungen als auch für PC-Anwendungen verfügbar. Nachteilig ist, daß bei jeder Hilfeanfrage eine Transaktion mit DFÜ ausgelöst wird.

2. Hilfetexte für PC-Anwendungen werden innerhalb jedes LAN bereitgestellt. Bei dieser Möglichkeit entfällt die Transaktion mit der Belastung der DFÜ-Mechanismen. Hilfetexte sind allerdings nicht immer in der aktuellsten Version verfügbar. Weiterhin müssen alle LANs jeweils mit einem kompletten Satz an Hilfetexten versorgt werden. Dies kann beispielsweise nachts oder an Wochenenden erfolgen. Hierfür müssen entsprechende Systeme entwickelt werden. -

Unbedingt erforderlich ist ein einfach zu bedienendes System zur Speicherung und Verwaltung von Hilfetexten. In einem größeren Unternehmen gibt es Anwendungen, die mehrere hundert oder sogar tausend Hilfetexte verwenden. Es muß daher ein System geben, mit dem die Hilfetexte des Unternehmens gespeichert und verwaltet werden können.

Aus der oben formulierten Anforderung der Objektbezogenheit von Hilfetexten folgt automatisch, daß Hilfetexte von Host- und PC-Anwendungen gemeinsam genutzt werden und für gleiche Objekte identisch sind. Es liegt nahe, für Host und PC jeweils gemeinsame Systeme der Bearbeitung, Speicherung und Verwaltung zu nutzen.

Wo liegen die Probleme des Anwenders?

Für den Schulungsbereich und die Software-Entwicklung ist es wichtig festzustellen, wo die Anwender im Umgang mit einem Programm Probleme haben. Einerseits kann durch entsprechende Schulungsmaßnahmen Abhilfe geschaffen werden, andererseits läßt sich die Anwendung selbst durch Änderungen verbessern. Ein wichtiger Hinweis kann durch die Untersuchung gewonnen werden, in welchen Situationen eine Hilfe besonders häufig angefordert wurde.

Alle Aspekte der Verwaltung des Hilfesystems sind organisatorisch in das Unternehmen zu integrieren. Dabei ist es erforderlich, das System so aufzubauen, daß es von den verschiedenen Organisationsbereichen bedient werden kann.