Serviceverträge
Ein Servicevertrag legt fest, welcher Service und welches SLA (Service Level Agreement) unter welchen Bedingungen am Ticket zur Verfügung steht.
Das Anlegen und Verwalten der Serviceverträge erfolgt im Modul 
.
Nachfolgend finden Sie Informationen zur administrativen Konfiguration der Serviceverträge. Eine detaillierte Beschreibung des Moduls und zur Anwendung von Serviceverträgen finden Sie unter: Servicekatalog Management.
Der Servicebaum im Explorer des Moduls enthält alle Assets der Assetklasse Service und listet diese hierarchisch auf. Wird ein neues Asset der Klasse Service angelegt, wird im Backend der Servicebaum neu aufbereitet.
Alternativ dazu kann der Servicebaum mittels Konsolenkommando neu aufgebaut werden. Starten Sie dazu unter das Kommando Console::Command::Maint::Service::UpdateServiceCatalog. Danach ist der Servicebaum aktualisiert.
Abb.: Aktualisierung Servicebaum via Konsole
Konfigurationsschlüssel |
|
Mit den o. a. SysConfig-Schlüsseln (Menü ) können Sie die im Dynamischen Feld Betroffene Services zur Auswahl stehenden Service-Assets steuern. Das Verhalten kann getrennt für das Agentenportal und für das Self Service Portal festgelegt werden.
Abb.: SysConfig-Schlüssel "service-contract-configuration"
Die Konfiguration wirkt sich generell auf das Dynamische Feld aus, ungeachtet dessen, ob das Feld im Ticket oder in den Konfigurationen von Vorlagen oder Aktionen eingebunden ist.
Konfigurationsparameter
Parameter | Beschreibung |
|---|---|
enabled | Aktivierung/Deaktivierung der Serviceverträge im Ticket.
|
singleSelection | Einfach- oder Mehrfachauswahl von Services am Ticket. Die zur Auswahl stehenden Services basieren auf der Konfiguration der Serviceverträge.
|
Hinweis
KIX Pro ermöglicht Ihnen im Menü die komfortable Anpassung von Vorlagen.
Wenn Sie Serviceverträge nutzen, ist die Änderung der Feldreihenfolge in der Standard-Vorlage (Default - New Ticket Template) nicht empfehlenswert, da dies zu unplausiblem Vorgehen bei der Ticketerstellung führen könnte.
Die initiale Feldreihenfolge resultiert aus der logischen Abfolge der Abhängigkeiten und dem Arbeitsfluss:
Die Auswahl von Kontakt, Organisation und Tickettyp beeinflussen die Services.
Daher stehen diese Felder oberhalb des Feldes Betroffene Services.
Die gewählte Priorität beeinflusst die möglichen SLA.
Daher ist die Priorität direkt oberhalb des Feldes SLA/Service Agreement angeordnet.
Muss die Feldreihenfolge dennoch geändert werden, beeinflusst dies nicht die Auswahlmöglichkeiten der Services und SLA am Ticket.
Betroffene Services: Es greifen die im Modul definierten Zuordnungen.
Default Services sind Services, an denen weder Organisation, Kontakt, Priorität noch Typ hinterlegt sind. Sie sind damit auch für jeden SSP-Nutzer verfügbar.
Wurden Services per Serviceverträge eingeschränkt, so können diese nur noch entsprechend ihrer Konfiguration (Kontakt, Organisation, Priorität und Typ) im SSP sowie im AP ausgewählt werden.
Betroffene Assets: Es gelten die Zuordnungen und Sichtbarkeiten entsprechend SysConfig-Schlüssel (s. auch: Sichtbarkeiten im SSP steuern).
Einem Asset der Klasse Service muss eine Kritikalität zugewiesen werden. Diese definiert die Systemrelevanz des Services.
Initial kann aus 4 Kritikalitätsstufen ausgewählt werden:
existenziell
geschäftskritisch
Unterstützungsprozess
keine/geringfügig.
Sie können diese Kritikalitätsstufen ändern oder weitere hinzufügen. Dies erfolgt im Admin Modul im Menü (s. auch: General Catalog).
Sie können Services inkl. deren Zuordnungen zu SLA-Kriterien via CSV-Datei im- und exportieren. Das ermöglicht Ihnen eine externe Massendatenpflege sowie den Transfer von Serviceverträgen von einer KIX 18 Testumgebung in eine KIX 18 Produktivumgebung bzw. von einer On-Premises-Installation in die KIX.Cloud.
Gehen Sie dazu vor wie unter Asset-Daten importieren beschrieben.
Ein Service ist post-produktiv, wenn er den Verwendungsstatus "Außer Dienst" oder "Inaktiv" hat (s. auch SysConfig-Einstellungen für Assets ). Dennoch können post-produktive Services teilweise verwendet werden:
Im Modul Asset: Post-Produktive Services sind - wie alle post-produktiven Assets - nicht sichtbar und können nur über die Komplexsuche gefunden werden.
Im Modul Service: Der Services-Baum enthält alle Services.
Post-produktive Services sind ausgegraut gekennzeichnet, können jedoch verwendet werden.
Im Ticket: Post-produktive Services werden ausgegraut angezeigt, sofern sie produktive/auswählbare Sub-Services besitzen. Sie können jedoch nicht ausgewählt werden.
Ausgewählt werden können produktive und pre-produktive Services und Sub-Services in Abhängigkeit der im Servicevertrag definierten Bedingungen.
Abb.: Post-produktive und produktive Services im Ticket