Support-Verwaltung¶
Unter Administration > Ticket-Verwaltung (/v2/admin/tickets) werden die Konfigurationsoptionen des Support-Ticketsystems verwaltet.
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:
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.
