Skip to main content

Prozess 3: Problem

Bei einem Problem handelt es sich i.d.R. um die (mögliche) Ursache für (wiederkehrende) Störungen (Incident). Das Problem Management kümmert sich um die Identifizierung und Verwaltung dieser Ursachen. Ziele sind hierbei die dauerhafte Problemlösung und Vermeidung kostspieliger Störungen sowie Sicherung des Wissens über (bekannte) Probleme.

Ein Problem kann bspw. sein:

  • eine geänderte Konfigurationsdatei

  • Ursachen für einen beschädigten Datenbankeintrag

  • Softwarefehler

  • u.v.a.m.

Ablaufschema des Prozesses Problem

Liegt basierend auf den Richtwerten von ITIL®4 ein Problem vor, kann in KIX ein entsprechendes Prozessticket Problem angelegt werden. Das Problem Management in KIX verläuft dabei nach folgendem Schema:

Prozess-Problem.jpg

Abb.: Ablaufschema des Prozesses Problem

  1. Erfassen 

    Die Erfassung eines Problems kann auf verschiedenen Wegen erfolgen:

    • manuell: unter Verwendung der Ticketvorlage Problem

    • automatisiert: bei Verwendung der Ticketaktion Problem (Prozess: schwerwiegende Störung)

    Das erstellte Ticket erhält die Standardwerte für Priorität (normal) und Status (neu) und wechselt in den nächsten Prozessschritt Kategorisierung.

  2. Kategorisieren 

    Das Kategorisieren des Tickets hilft, das Problem zu bewerten und ihm eine Steuergröße zu geben. Am Ticket existiert dazu die Aktion Kategorisieren. Sie öffnet einen Dialog in dem u. a. Priorität, Auswirkungen und Fehlerkategorie bestimmt werden können. Die Auswirkungen richten sich nach der Art der Beeinträchtigung des Services. Die Fehlerkategorie dient der Einordnung des Problems in Themenbereiche.

    Wird die Kategorisierung mit OK beantwortet, erhält das Ticket den Status zugewiesen und wechselt in den nächsten Prozessschritt Diagnose.

  3. Diagnose 

    Die Diagnose dient dem Identifizieren des Problems und dessen Bestätigung bzw. Ablehnung. Am Ticket existiert dazu die Aktion Diagnose. Das Ergebnis der Diagnose wird im Feld Problemstatus angegeben.

    Ist dies erfolgt und die Diagnose mit OK bestätigt, erhält das Ticket mit dem Speichern den Status in Arbeit. Die Aktion Diagnose steht weiterhin am Ticket zur Verfügung, sodass Änderungen bspw. am Problemstatus oder Ergänzungen zu Symptom/Ursache vorgenommen werden können.

    Der Prozessschritt Diagnose kann bei vorhandener Lösung übersprungen werden. Verwenden Sie dann die Ticketaktion Lösung.

  4. Known Error 

    Ein Known Error ist ein Fehler mit bekannter Ursache. Für solche Fehler kann ein FAQ-Eintrag erzeugt werden. Dafür steht am Ticket die Aktion Known Error zur Verfügung. Sie erstellt anhand der im Ticket hinterlegten Informationen automatisch - ohne Dialog - einen FAQ Eintrag und verknüpft diesen mit dem Ausgangsticket.

  5. Lösung 

    Konnte das Problem gelöst werden oder existiert ein Workaround zum Problem, kann das Ticket geschlossen werden. Dies erfolgt unter Verwendung der Ticketaktion Lösung. Im sich öffnenden Dialog können u. a. angegeben werden:

    • Lösungsbeschreibung: z. B. durchgeführte Arbeiten, Hinweise zur Nichtdurchführbarkeit etc

    • Workaround: Beschreibung eines alternativen Vorgehens oder einer Behelfslösung.

      Ist ein Workaround angegeben, wird automatisch ein FAQ Eintrag erstellt.

    • Problemstatus: Der Problemstatus muss angegeben werden, wenn der Prozessschritt Diagnose übersprungen wurde.

    Ist der Problemstatus gesetzt und der Bearbeitungsstand der Lösung mit OK beantwortet, wird das Ticket direkt geschlossen. Der Prozessschritt der Akzeptanz entfällt.

    Abzweig zum Change Prozess 

    Wird am Ticket die Aktion Change erstellen bereitgestellt, ermöglicht dies einen Prozess-Abzweig zum Change Management. Die Aktion öffnet einen Dialog zum Anlegen eines neuen Artikels und erstellt parallel dazu ein weiteres Ticket vom Typ Change. Beide Tickets werden als Eltern-Kind-Beziehung miteinander verknüpft.

In diesem Abschnitt: