EVA-Prinzip im Supportfall

Manche Prinzipien sind so grundlegend und unvergänglich, dass sie in einer Vielzahl von Situationen weiterhelfen, darunter das EVA-Prinzip bei Anwendungsfehlern.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 3 Min.
Von
  • Michael Keller

Manche Prinzipien sind so grundlegend und unvergänglich, dass sie in einer Vielzahl von Situationen weiterhelfen, darunter das EVA-Prinzip bei Anwendungsfehlern.

Seit meinem letzten Blog ist einige Zeit vergangen. Der Sommer in Deutschland, sofern man ihn so nennen konnte, ist vorbei und der Herbst hält Einzug. Längste Zeit für einen neuen Beitrag im "well organized"-Blog.

Ich möchte heute an meinen Blogbeitrag "Vom Umgang mit Anwendungsfehlern" anschließen. Damals hatte ich über den Einsatz von Leitfragen zum Sammeln von Informationen im Fehlerfall geschrieben. Vorschläge für Leitfragen waren unter anderem: "Zu welchem Zeitpunkt ist der Fehler aufgetreten?" und "Wie lässt sich der Fehler reproduzieren?".

Bei der Beantwortung dieser Fragen und damit verbunden der Analyse des Problems in einem Prozess hilft überraschenderweise ein sehr altes Konzept der IT ein Stückchen weiter: Das EVA-Prinzip (Eingabe, Verarbeitung, Ausgabe). Im Englischen als "IPO model" bezeichnet (Input-Process-Output). Das Prinzip unterteilt eine Datenverarbeitung in die namensgebenden drei Teilschritte: Eingabe, Verarbeitung und Ausgabe.

An einem Beispiel könnte das wie folgt aussehen: Jemand gibt in einer Anwendung zur Auflistung von Produkten bei der Auswahl die Produktnummern 4711 und 4712 per Tastatur ein. Er bestätigt die Ausführung mit der Eingabetaste und erhält nach kurzer Zeit eine Liste auf dem Bildschirm. Allerdings enthält die Liste in der Spalte "Produktbeschreibung" nur kryptische Zeichen wie "®¯®à¾". Der Anwender hat aber eine verständlichen Beschreibung des jeweiligen Produkts erwartet - insbesondere weil er noch am Vortag mit diesen Produktnummern gearbeitet hat und die Produktbeschreibung in Ordnung war. Er vermutet daher die Fehlerursache im technischen Bereich und setzt sich zur Klärung mit seinem Support in Verbindung.

An diesem Beispiel lassen sich die drei Teilschritte gut nachvollziehen. Für die Mitarbeiterin im Support sind die Schritte je nach Berechtigung gut reproduzierbar. Ausgehend von der Bildschirmausgabe kann nun eine Analyse der Fehlerursache rückwärts erfolgen. Ist es wirklich die Ausgabe oder entsteht der Fehler bereits während der Verarbeitung? Beispielsweise könnte die Liste während der Verarbeitung fehlerhaft zusammengestellt werden oder die kryptischen Zeichen kommen sogar direkt von der Datenbank. Alles denkbare Ursachen.

Ändert man das Beispiel leicht ab und die Ausgabe erfolgt auf einem Drucker, ist das für die Mitarbeiterin im Support ein mehr als wertvoller Hinweis. Genauso ist ein Beispiel denkbar, in dem die Eingabe nicht per Tastatur, sondern per Barcode-Scanner erfolgt und die Produktnummern als kryptische Zeichen wie "®¯®à¾" angezeigt werden. Zur Verarbeitung beziehungsweise Ausgabe kommt der Anwender gar nicht erst.

Anhand der Beispiele sieht man die Möglichkeiten und Vorteile des EVA-Prinzips: Es verbindet verschiedene Aspekte in einer Abfolge und ist leicht verständlich. Damit ist es bestens geeignet, um schnell und einfach geschult und angewendet zu werden - auch wenn es nur eine sehr grobe Vorstellung bzw. Einteilung erlaubt. Eigenständige Verfeinerungen zur Verbesserung des Support-Ablaufs sind natürlich erlaubt.

Darüber hinaus spielt das EVA-Prinzip in vielen weiteren IT-typischen Situationen eine Rolle, was seinen Mehrwert als grundlegendes Prinzip noch verdeutlicht. Auch wenn man sich dessen im Alltag schon gar nicht mehr bewusst ist...


In diesem Sinne, bleibt strukturiert und gesund
euer Michael ()