Zum Inhalt

Support-Verwaltung

Unter Administration > Ticket-Verwaltung (/v2/admin/tickets) werden die Konfigurationsoptionen des Support-Ticketsystems verwaltet.

Ticket-Verwaltung

Ticket-Kategorien

Kategorien klassifizieren Tickets thematisch:

  • z. B. Softwarefehler, Hardwareproblem, Feature-Anfrage, Allgemein
  • Frei konfigurierbar

Nicht die Kategorienverwaltung

Ticket-Kategorien liegen in einem eigenen Katalog und werden hier gepflegt, nicht unter Administration > Kategorien. Der dortige Baum trägt Hierarchie, Farben und Nummernzähler; Ticket-Kategorien sind flach und kommen ohne aus.

Ticket-Prioritäten

Prioritäten definieren die Dringlichkeit:

Priorität Typische Verwendung
Niedrig Verbesserungsvorschläge
Normal Standardanfragen
Hoch Dringende Probleme
Kritisch Systemausfälle

Die Risiko-Matrix kann die Priorität eines Tickets automatisch setzen (siehe unten).

Ticket-Typen

Typen klassifizieren die Art des Tickets:

  • Fehler (Bug)
  • Feature-Anfrage
  • Supportanfrage
  • Aufgabe

Risikobewertung

calServer bewertet jedes Ticket nach den Standard-Risikoregeln über bis zu drei gewichtete Bewertungsebenen. Jede Ebene ist eine eigene Liste; jede Stufe darin trägt ein numerisches Gewicht. Die Begriffe folgen dem Risiko-Vokabular der ISO 31000, auf das die ISO/IEC 17025 in Abschnitt 8.5 („Maßnahmen zum Umgang mit Risiken und Chancen") verweist:

Platzhalter Standardname In V1 Bedeutung
[Risk_1] Auswirkung Versionsliste Ergebnis eines Ereignisses, das die Ziele betrifft — gewiss oder ungewiss, qualitativ oder quantitativ beschreibbar
[Risk_2] Wahrscheinlichkeit Meilensteinliste Möglichkeit, dass etwas geschieht — muss nicht mathematisch beschrieben sein
[Risk_3] Ereignis Risiko-3-Liste Eintritt oder Veränderung einer bestimmten Kombination von Umständen; kann mehrfach eintreten und mehrere Ursachen wie Auswirkungen haben

Zwei Ebenen ergeben die klassische Risikomatrix (Auswirkung × Wahrscheinlichkeit), drei nehmen das Ereignis als weiteren Faktor auf.

Standardbewertung einrichten

Eine frische Installation hat leere Listen — ohne Skalen rechnet die Bewertung nichts. Der Tab Risiko-Formel bietet dafür Vorlage ansehen: Die Vorlage legt je Ebene eine Skala von 1 bis 5 an, dazu die Matrix mit den Bändern grün/gelb/orange/rot und die passende Formel. Optional auch die dritte Ebene.

Die Vorschau zeigt vorher genau, was entsteht. Vorhandene Einträge werden nie überschrieben: Trägt eine der Listen schon Daten, lehnt die Einrichtung ab und nennt die betroffene Ebene.

Mehr als die Skalen bringt ein Paket mit: dieselbe Bewertung plus Typen, Kategorien und Prioritäten, fertig für ein Labor nach ISO/IEC 17025. Siehe Einrichtung als Paket exportieren und importieren.

Ebenen umbenennen

Die Namen sind frei änderbar — im Tab Risiko-Formel direkt neben der jeweiligen Ebene. Gespeichert werden sie als Übersetzungen der Schlüssel Risk 1 / Risk 2 / Risk 3 in der Kategorie support; V1 liest dieselben Schlüssel, die Bezeichnung gilt also in beiden Generationen. Wer lieber in der Sprachverwaltung arbeitet, findet sie dort unter derselben Kategorie.

Risiko-Formel

Der Tab Risiko-Formel legt fest, wie die Gewichte verrechnet werden. Erlaubt sind die Platzhalter [Risk_1], [Risk_2], [Risk_3], Zahlen, die Operatoren + - * / und Klammern.

Formel Ergebnis
[Risk_1] * [Risk_2] Standard: Bewertung mit zwei Methoden
[Risk_1] * [Risk_2] * [Risk_3] Bewertung mit drei Methoden
[Risk_1] * [Risk_2] + [Risk_3] Ereignis als Zuschlag

Die Formel entscheidet auch, welche Auswahlfelder das Ticketformular anbietet: Kommt [Risk_3] nicht vor, wird die dritte Ebene weder abgefragt noch gerechnet — die Bewertung ist damit auf zwei Methoden reduziert.

Unvollständige Bewertung

Solange eine von der Formel genutzte Ebene am Ticket nicht ausgewählt ist, hat das Ticket keinen Risikowert. Erst wenn alle beteiligten Ebenen gesetzt sind, erscheint der berechnete Wert.

Risiko-Matrix

Der Tab Risiko-Matrix übersetzt den berechneten Risikowert in Farbe und Priorität. Jede Zeile deckt einen Einzelwert (5) oder einen Bereich (1-3) ab; die Reihenfolge bestimmt, welche Zeile bei Überschneidungen gewinnt.

Feld Bedeutung
Risikowert Einzelwert oder Bereich, z. B. 1-3
Farbe Kennzeichnung des Tickets in Liste und Detailansicht
Priorität Wird beim Speichern automatisch am Ticket gesetzt
Frist (Tage) Kalendertage, die ein Ticket in diesem Band zur Erledigung bekommt. Leer heißt: dieses Band setzt keine Frist
Vorwarnung (Tage) Wie viele Tage vor der Frist erinnert wird. Leer heißt: Erinnerung erst am Fälligkeitstag
Reihenfolge Auswertungsreihenfolge — die erste passende Zeile gewinnt

Der Risikowert wird bei jedem Aufruf neu berechnet. Eine geänderte Formel oder ein geändertes Gewicht wirkt damit sofort auf alle Tickets; die Priorität wird beim nächsten Speichern des Tickets nachgezogen.

Fristen

Trägt das getroffene Band eine Frist, bekommt das Ticket beim Speichern eine Fälligkeit. Sie zählt ab der ersten vollständigen Bewertung, nicht ab der Anlage: Ein Ticket, das drei Wochen unbewertet liegt, hätte sonst eine Frist, die bei der ersten Bewertung schon halb verbraucht ist.

Fall Verhalten
Bewertung unvollständig Keine Fälligkeit. Wer eine Ebene kurz leert, verliert seine Frist nicht
Neubewertung nach oben Die Fälligkeit rückt vor. Eine Verschärfung darf eine laufende Maßnahme beschleunigen
Neubewertung nach unten Die Fälligkeit bleibt. Eine Frist lässt sich nicht durch Herunterstufen wegdiskutieren
Von Hand gesetzt Bleibt stehen, auch über Neubewertungen hinweg. Die Änderung steht im Verlauf des Tickets
Wieder automatisch Die Fälligkeit wird beim nächsten Speichern erneut aus dem Band gerechnet

Gerechnet wird in Kalendertagen. Arbeitstage, Feiertage und Urlaubszeiten kennt calServer nicht, und die Fristen aus den DAkkS-Vorlagen („3 Monate", „1 Monat") sind Kalenderfristen.

In der Ticketliste steht die Fälligkeit als Ampel in der Spalte Fällig (rot überfällig, gelb innerhalb einer Woche), und der Filter Nur überfällige zeigt genau die Vorgänge, um die es in der Begutachtung geht.

Erinnerung und Eskalation

Der Lauf Fristen im Ticketsystem (Administration > Geplante Aufgaben, Vorgabe täglich 06:00) meldet zweierlei:

Ereignis Wann An wen
Erinnerung Vorwarnzeit des Bandes angebrochen, spätestens am Fälligkeitstag Bearbeiter, sonst die zugewiesene Gruppe des Tickets
Überschreitung Frist verstrichen, Ticket nicht abgeschlossen zusätzlich die eingestellte Eskalationsgruppe

Beides kommt als Meldung in die Glocke und, wenn der Mailversand eingerichtet ist, als Mail (Vorlagen Maßnahme fällig und Frist überschritten). Jede Überschreitung schreibt außerdem eine Zeile in den Verlauf des Tickets — in der Begutachtung ist „wir hätten gemeldet" ohne Beleg wertlos.

Jedes Ticket wird einmal erinnert und einmal gemeldet; ein zweiter Lauf am selben Vorgang bleibt still. Ändert sich die Fälligkeit, fällt der Stempel und die Erinnerung kommt zur neuen Frist erneut.

Zwei Einstellungen dazu stehen im Tab Risiko-Formel, Abschnitt Fristen:

Einstellung Bedeutung
Eskalationsgruppe Wird bei einer Überschreitung zusätzlich benachrichtigt. Ohne Auswahl bleibt die Meldung bei Bearbeiter und Ticketgruppe
Endstatus Ticket-Status, in denen ein Vorgang als erledigt gilt. Ohne Angabe mahnt der Lauf auch abgeschlossene Vorgänge an

Endstatus setzen

Der Endstatus ist die einzige Angabe, ohne die der Lauf sichtbar falsch liegt: aktiv/sichtbar am Status reicht dafür nicht — ein Endstatus ist aktiv und sichtbar, er bedeutet nur, dass nichts mehr zu tun ist. Der Trockenlauf sagt es deshalb ausdrücklich:

docker exec calserver-api-v2 php artisan tickets:send-due-reminders --dry-run

Risikomeldungen im Dashboard

Zwei Widgets werten die Bewertung aus (Dashboard > Widget hinzufügen > Support):

Widget Inhalt
Risiko-Matrix Zwei Ebenen als Heatmap: Auswirkung (Zeilen) gegen Wahrscheinlichkeit (Spalten), je Zelle die Ticketzahl in der Farbe der Risiko-Matrix
Überfällige Maßnahmen Zahl der offenen Tickets mit gerissener Frist. Der Klick führt in die gefilterte Liste
Bald fällige Maßnahmen Zahl der offenen Tickets, deren Frist in den nächsten sieben Tagen abläuft
Risiko-Ebenen Alle drei Ebenen plus Gesamtrisiko als Balken je Stufe; Ebenen, die die Formel nicht nutzt, erscheinen ausgegraut

Beide lassen sich je Widget auf Projekt, Kategorie und Ticket-Status einschränken. Nutzt die Formel [Risk_3], ist der Wert einer Matrix-Zelle nicht mehr eindeutig — die Zelle zeigt dann den höchsten Risikowert, den ihre Tickets tatsächlich erreichen.

Einrichtung als Paket exportieren und importieren

Über die Schaltfläche Paket oben rechts lässt sich die gesamte Einrichtung des Ticketsystems als Datei mitnehmen und anderswo wieder einspielen. Das Paket (calserver.ticket-config-package) trägt

  • die Ticket-Typen, Ticket-Kategorien und Prioritäten,
  • die Stufen aller Bewertungsebenen samt Gewicht, Farbe und Beschreibung,
  • die Risiko-Matrix mit ihren Bändern, der Prioritätszuordnung sowie Frist und Vorwarnzeit je Band,
  • die Risiko-Formel und die Bezeichnungen der Bewertungsebenen.

Nicht im Paket: die Tickets selbst und die Ticket-Status. Die Status liegen im gemeinsamen Statuskatalog und haben ihr eigenes Format — sie werden unter Statusverwaltung als Statuspaket ein- und ausgelesen.

Punkt Verhalten
Wiedererkennung Über den Titel je Liste, bei der Matrix über das Band (10-14). Ein zweiter Import derselben Vorlage legt keine Zwillinge an.
Bestehende behalten (Vorgabe) Vorhandene Einträge bleiben unverändert, fehlende werden angelegt.
Bestehende überschreiben Zusätzlich werden Gewichte, Farben und Beschreibungen aus dem Paket nachgezogen.
Formel und Ebenennamen Werden übernommen, solange sie noch auf der Werksvorgabe stehen. Eine selbst angepasste Formel bleibt stehen und wird nur beim Überschreiben ersetzt — der Bericht sagt in beiden Fällen, was passiert ist.
Priorität einer Matrixzeile Steht im Paket als Titel, nicht als ID. Gibt es die Priorität in dieser Installation nicht, bleibt die Zeile ohne Priorität und der Bericht nennt sie.
Fristen Kamen mit Dokumentversion 2. Ein älteres Paket ohne Fristen bleibt lesbar und löscht keine eingerichtete Frist — auch nicht beim Überschreiben.
Unbrauchbare Formel oder Bänder Der Import wird komplett abgelehnt, es wird nichts geschrieben.

Eigene Berechtigungen

Export und Import hängen an Ticketmanagement exportieren (support_config_export) und Ticketmanagement importieren (support_config_import). Wer die Ticket-Verwaltung bedienen darf, hat sie damit nicht automatisch: Ein Paket trägt Formel und Matrix und entscheidet damit über die Priorität jedes Tickets. Die Rechte werden keiner Rolle automatisch zugewiesen.

Das Archiv enthält ticket-config.json, ein manifest.json mit Prüfsumme je Datei und optional eine README.md. Weicht eine Prüfsumme ab oder liegt eine ungelistete Datei im Archiv, wird der Import abgelehnt. Wer eine Vorlage von Hand anpassen will, lädt statt des Archivs die reine ticket-config.json hoch.

Startvorlagen für DAkkS-Labore

Auf der Download-Seite des Vorlagen-Repos stehen in der Kategorie Ticketmanagement zwei fertige Einrichtungen für ein Labor nach ISO/IEC 17025 bereit. Beide bringen dieselben Kataloge mit — acht Vorgangsarten (Risiko, Chance, Abweichung, Beschwerde, Korrekturmaßnahme, Verbesserung, Auditfeststellung, Änderung), zwanzig Themenfelder entlang der Normabschnitte und vier Prioritäten — und unterscheiden sich nur in der Bewertung:

Vorlage Bewertung Wertebereich
Ticketmanagement (zwei Methoden) Auswirkung × Wahrscheinlichkeit 1 bis 25
Ticketmanagement (drei Methoden) Auswirkung × Wahrscheinlichkeit × Erkennbarkeit 1 bis 125

Dazu gehört das Statuspaket Status: Risiken, Chancen und Maßnahmen im Ticketsystem mit dem passenden Ablauf (Neu, Bewertet, Maßnahme geplant, In Umsetzung, Wirksamkeit prüfen, Abgeschlossen, Kein Handlungsbedarf), das unter Statusverwaltung eingespielt wird.

Nur eine der beiden Bewertungen einspielen

Die beiden Vorlagen tragen dieselben Kataloge, aber unterschiedliche Matrixbänder. Nacheinander importiert stünden acht Bänder in der Matrix, von denen sich die Hälfte überlappt.

Die Vorlagen bringen die Fristen je Band mit (90 / 30 / 7 Tage, das niedrigste Band ohne Frist) samt Vorwarnzeit. calServer rechnet daraus die Fälligkeit und meldet ihre Überschreitung — das ist mehr als ein Vorschlag im README.

Was die Vorlagen bewusst nicht leisten: Zuständigkeiten. Wer entscheidet, wer freigibt und was eine Sofortmaßnahme ist, steht in der Verfahrensanweisung; die READMEs der Pakete enthalten dazu einen Vorschlag, der sich in der Begutachtung erklären lässt. Auch Eskalationsgruppe und Endstatus sind kein Paketinhalt — sie hängen an den Gruppen und Status dieser Installation und werden einmalig in der Ticket-Verwaltung eingestellt.

Risiken und Chancen in einem System

ISO/IEC 17025 behandelt beide im selben Abschnitt (8.5) und verlangt für beide denselben Nachweis: erkannt, bewertet, entschieden, und bei Handlung wirksam geworden. Die Vorlagen führen sie deshalb im selben Ticketsystem, unterschieden über den Ticket-Typ. Die Bewertung funktioniert für eine Chance mit derselben Matrix, nur anders gelesen: Die Auswirkung ist dann der Nutzen, die Wahrscheinlichkeit die Sicherheit, mit der er eintritt, und ein hoher Wert heißt „einplanen" statt „abstellen".

Das ist eine Konvention des Labors, keine Rechenregel des Systems — sie gehört in die Verfahrensanweisung, damit sie einheitlich angewendet wird.