ENSOFT-Logo
Startseite Hintergrundwissen Prüfmethoden Grundsätze

Wie die meisten Spezialgebiete hat auch die Datenerfassung einige grundsätzliche Regeln und Abläufe, die gemeinsam die Grundlage der Arbeit darstellen. Einige davon werden nachfolgend kurz dargestellt. Ein Teil dieser Informationen läßt sich ohne weiteres auf jede Art von Dateneingabe anwenden (vorausgesetzt, daß die programmiertechnischen Mittel zur Verfügung stehen). Andere Überlegungen aber sind zwar innerhalb der Datenerfassung selbst äußerst wichtig, auf sonstige Anwendungen aber kaum übertragbar (siehe nachfolgend unter „Optimierungsextremismus“). Deutlich wird aber zumindest, wo noch Reserven liegen könnten.

 

Sicherheit oder Effizienz oder beides

Ein Merkmal professioneller Datenerfassung ist die Minimierung des Eingabeaufwandes (und der Kosten), ein anderes die Prüfung der eingegebenen Daten. Da die meisten Prüfmethoden auf der Redundanz der einzugebenden Daten (= Informations-Überschuß) beruhen, hat man programmtechnisch oft die Wahl zwischen genauer Prüfung der eingegebenen Daten oder automatischer Generierung von Daten bei gleichzeitiger Einsparung von Eingabearbeit.

Ein typisches Beispiel ist der Zusammenhang zwischen Postleitzahl und Ortsnamen. Man könnte im Interesse hoher Sicherheit beide Informationen eingeben lassen und anhand einer Tabelle die Übereinstimmung prüfen. Man könnte aber auch anhand der Postleitzahl automatisch den Ortsnamen generieren und dabei den Eingabeaufwand minimieren - bei fast totalem Verzicht auf Prüfungen. Dieses Beispiel wird unter „Tabellenprüfungen“ genauer erklärt.

Ein vernünftiges Gleichgewicht zwischen Eingabeoptimierung und Sicherheit zu finden, ist nicht immer einfach und setzt einige Erfahrung voraus. Manchmal hilft auch Erfahrung nichts und man muß akzeptieren, daß die endgültige Programmierung erst nach dem Ersteinsatz fertiggestellt werden kann.

 

Optimierungs- Extremismus

Darüber hinaus wird in der professionellen Datenerfassung nicht nur um jeden einzelnen Tastenanschlag „gekämpft“, sondern es wird sogar über die Lage der Tastenfunktionen auf der Tastatur im Verhältnis zu den Händen nachgedacht.

So bevorzugen Datentypistinnen z.B. als Feldende-Taste nicht die mit der linken Hand zu bedienende Tab-Taste, sondern die Enter-Taste. Nicht nur ist die Enter-Taste sowohl auf der Haupt-Tastatur, als auch auf der numerischen Tastatur verfügbar, sondern es wird dabei auch die linke Hand entlastet, die meist mit den zu erfassenden Belegen hantieren muß.

Ein anderer, schon recht extremer Fall von Optimierung ist der „überlagerte numerische Block“. Dabei wird per Software ein zusätzlicher Ziffernblock simuliert, der auf der Haupt-Tastatur „über“ den Tasten „9UIOJKLM,.“ liegt und in numerischen Felder automatisch aktiviert wird.

Dabei wird vor allem bei Eingabe von gemischt Alpha- und numerischen Daten zusätzlich Zeit gewonnen.

 

Ein Sicherheits- Problem: Mäuse

Da falsche Daten im allgemeinen unerwünscht sind, wird die Eingabe als falsch erkannter Daten üblicherweise vom Programm abgelehnt (das ist ja der Kern des Themas „Eingabeprüfung“). Die klassische Reaktion des Erfassungsprogramms ist dabei

  • Anzeige der Art des festgestellten Eingabefehlers (möglichst blinkend und mit gleichzeitigem akustischem Signal).
  • Sperre der Tastatur gegen weitere Eingaben so lange, bis eine vorgegebene Quittungstaste betätigt wurde.
  • Rückkehr des Cursors in das Feld, in dem die fehlerhafte Eingabe festgestellt wurde, zum Zweck der Korrektur.

Falls es sich um ein Programm handelt, das ohne Maus und ähnliche Positionierungsmöglichkeiten arbeitet, kann auf diese Weise garantiert werden, daß nur Daten eingegeben werden können, die gemäß den Programmvorgaben fehlerfrei sind. Bei Verwendung einer Maus könnte der Anwender aber Felder und somit auch Prüfungen über-springen.

Fehlerfreiheit könnte dann nur sichergestellt werden, wenn man sämtliche Prüfungen an das Ende der Eingabe (vor der Übernahme der Eingaben in eine Datei) verlegt. Diese Philosophie entspräche aber der EDV-Steinzeit, als man noch brav einen ganzen Bildschirm ausfüllte, um erst dann zu erfahren, daß bereits die erste Eingabe falsch war und man vielleicht sogar den Beleg von Anfang an hätte beiseite legen sollen. Das Grundprinzip, Fehler sobald wie möglich festzustellen, sollte keinesfalls durchbrochen werden.

Es soll hier nicht verschwiegen werden, daß man trotz Verwendung einer Maus programmtechnisch sowohl Sicherheit, als auch frühzeitige Fehlerwarnungen erzeugen kann. Allerdings - wie bei Radio Eriwan - nur „im Prinzip“. Man muß eben nur die gleichen Prüfungen sowohl nach Verlassen eines Eingabefeldes, als auch nach Fertigstellung der Eingabe durchführen. Freilich ergeben sich dabei eine Menge praktischer Probleme.

Um nicht zukünftig doppelte Routinen warten zu müssen (mit sehr bösartigen Fehlermöglichkeiten), wird man versuchen, die Fehlerprüfungen in Unterroutinen zu verlegen. Diese Unterroutinen enthalten dann oft nur eine einzige Abfrage (z.B. Abfrage eines Feldinhaltes auf Untergrenze), deren Ergebnis dann noch dazu als Rückgabewert interpretiert werden muß. Der Gesamtaufwand solcher Programmierung wird schnell unwirtschaftlich, sodaß man zu Recht sagen kann: Datenerfassung und Mäuse vertragen sich nicht!

 

"Harte" oder "weiche" Prüfung oder beides?

In der Praxis ergeben sich immer wieder Fälle, in denen eine Prüfung nicht „sicher falsch“ ergibt, sondern nur „wahrscheinlich falsch“. Ein typischer Fall wäre die Angabe, daß jemand in einer Woche 90 Überstunden gemacht hätte. Sehr wahrscheinlich ist diese Angabe falsch, aber ganz sicher kann man nicht sein, da eine Woche immerhin insgesamt 168 Stunden umfaßt.

Prüfungen, die „wahrscheinlich falsch“ als Antwort bekommen können, kann man zu vielen Eingaben durchführen, aber die Frage ist, was man mit der Antwort machen soll. Eingaben, die „sicher falsch“ sind, kann ein Programm ablehnen, aber was mit „wahrscheinlich falschen“ Eingaben zu tun ist, scheint im Rahmen der strengen Computerlogik unklar zu sein. Häufig wird daher in solchen Grenzfällen auf Prüfungen überhaupt verzichtet.

Besser ist aber die sogenannte „weiche“ Prüfung. Dabei wird die Prüfung selbst so durchgeführt, wie sie die jeweilige Eingabe erfordert, aber die Reaktion des Programms ist anders, nämlich:

  • Anzeige der Art des festgestellten Eingabefehlers (möglichst blinkend und mit gleichzeitigem akustischem Signal).
  • Sperre der Tastatur gegen weitere Eingaben so lange, bis eine vorgegebene Quittungstaste betätigt wurde.
  • Normale Fortsetzung der Eingabe mit dem nächsten Feld.

Falls der Anwender einen Eingabefehler festgestellt hat, muß er die fehlerhafte Eingabe korrigieren. Andernfalls kann die Eingabe normal fortgesetzt werden. Die „weiche Prüfung“ ist sehr hilfreich, sofern die Bediener guten Willens sind und tatsächlich ihre Eingaben entsprechend der Fehlernachricht überprüfen. Man darf sicherlich zu Recht annehmen, daß Personen, die Computer als Hilfsmittel für ihre Arbeit verwenden, dabei guten Willens sind und einen Hinweis des Computers auf mögliche Fehler positiv aufnehmen. Gegen böswilliges Beibehalten fehlerhafter Eingaben hilft diese Methode nicht - allerdings helfen sämtliche üblichen Fehlerprüfmethoden nicht gegen wirkliche Böswilligkeit.

Andererseits erlaubt aber das Konzept der „weichen Prüfung“ eine Verbesserung der Datenqualität in solchen Fällen, in denen eine „harte Prüfung“ nicht möglich ist. Je nach Anwendung erweisen sich die weichen Prüfungen als wichtige Waffen im Kampf gegen die Eingabefehler. Insbesondere die „Statistische Prüfung“ und die „Delta-Prüfung“ sind nur als weiche Prüfungen sinnvoll einzusetzen.

 

Prüfung auf der richtigen Ebene

Man kann bei der Erfassung von Daten Prüfungen auf mehreren Ebenen durchführen, nämlich

  • auf „Zeichenebene“
    (z.B. keine Eingabe von Buchstaben in einem numerischen Feld)
  • auf „Feldebene“
    (z.B. Feldinhalt zu hoch, zu niedrig, Feld nicht leer, usw.)
  • auf „Feldgruppen-Ebene“
    (z.B. PLZ muß zu Ort passen)
  • auf „Satz-Ebene“
    (z.B. Rechnungssumme muß zu Einzelposten passen)
  • auf „Satzgruppen-“/„Dateiebene“
    (Summe der Ausgaben und Einnahmen muß zu Kassenstand passen)

Grundsätzlich sollten Prüfung und Fehlermeldung so früh wie möglich erfolgen. Ein positiver Fall wäre, daß die Eingabe einer nicht existierenden Postleitzahl sofort, nach Beenden des Eingabefeldes, festgestellt und gemeldet würde. Schlecht wäre die Meldung dieses Fehlers - der eventuell den ganzen Beleg unbrauchbar machen könnte - erst nach Beendigung des ganzen Datensatzes (auf „Satzebene“).

In der Zeit der Datenerfassung am Hauptrechner (mit „dummen“ Terminals) war dieses Vorgehen leider der Normalfall.

In jedem Fall erlaubt die sofortige Prüfung und Meldung ein wesentlich effizienteres Arbeiten, weil weder das fehlerhafte Feld im Beleg (dort hat man ja gerade hingeschaut), noch das fehlerhafte Feld im Bildschirm (dort blinkt der Cursor) gesucht werden muß. Auf „höherer“ Ebene gilt im Prinzip das gleiche, nur daß es dort eben darum geht, daß man den Beleg noch zur Hand hat, oder daß ein Beleg-“Stapel“ noch verfügbar ist, wenn man die Fehlermeldung bekommt.

Prüfungen auf der jeweils passenden Ebene sind natürlich in Dialogprogrammen aller Art genau so wichtig wie bei der reinen Datenerfassung. Der Unterschied zwischen Einhaltung und Nichteinhaltung der jeweils passenden Ebene kann große Bedeutung haben. Wird bei telefonischer Bestellannahme eine Bestandprüfung sofort (auf „Feldebene“) durchgeführt, dann kann man sich bei einem Artikel, der gerade nicht im Lager ist, für eine Alternative entscheiden.

Erfolgt die Bestandprüfung erst bei Generierung der Lieferlisten, so erfährt man erst bei Lieferung, daß der Artikel nicht verfügbar war und - ja, und was? Entweder wird der Artikel nachgeliefert, so-bald er verfügbar ist, oder man bestellt ihn bei einem anderen Lieferanten. Schön ist beides nicht und die Entscheidung, wo man in Zukunft wieder bestellen wird, ist einfach: dort, wo „auf Feldebene“ geprüft wird.

So trivial diese Regel der „Prüfung auf der richtigen Ebene“ scheint, so komplex ist die Realisierung. Ein System, das dialogorientierte Programmierung unterstützt, muß mit dem entsprechenden knowhow des Programmierers zusammentreffen, um zum Erfolg zu kommen.