Direkt zum Hauptinhalt

Release 24.04

Das Release 24.04 unserer ITSM-Suite metis wird am 20.04.2024 produktiv gesetzt. Im Folgenden haben wir die wichtigsten Neuerungen für Sie aufbereitet.


Für unsere Kunden relevante Sachverhalte

Zur Vermeidung von sporadischen Fehlern bitten wir Sie, einmalig den Browser-Cache zu löschen.
Löschen Sie am besten den Cache für die gesamte Zeit.

Plattform-Upgrade auf neueste Cherwell-Version

Wir werden in diesem Release die Plattform-Software auf die neueste Version des Herstellers aktualisieren. Dadurch profitieren wir von zahlreichen Bugfixes und Vorteilen. Zum einen können wir uns über einige behobene Fehler und generelle Architekturverbesserungen „im Unterbau“ freuen, die sich auch positiv auf die System-Performance auswirken. Zum anderen gibt es technologische Updates, unter anderem auch Sicherheitsupdates und neuere Versionen der Portalkomponenten. Das Portal ist damit zwar immer noch nicht so modern, wie wir es uns wünschen, aber zumindest ist es schneller und im Detail verbessert worden. In diesem Zuge haben wir die Darstellung der Portalseiten und Formulare vollständig überarbeitet, sodass diese kompakter und stimmiger sind.

Wie üblich mussten wir ein paar Wehrmutstropfen inkauf nehmen, beispielsweise hinsichtlich der Darstellung von Registern und Scrollbars im Portal. Diese sind nach wie vor nicht gut gelöst.

Die folgenden Screenshots geben Ihnen einen Überblick über das neue Design (zum Vergrößern anklicken):

bsp-portal-dashboard.png  erfassungsassistent.png  bsp-incident-neu.png bsp-incident-erfasst.png bsp-raster-portal.png bsp-genehmigung-erteilt.png bsp-genehmigung-abgelehnt.png

Überarbeitung der Berechnung von SLA-Zeiten

Bei Wandlungen von Tickets, also insbesondere wenn eine Serviceanforderung in einen Incident umgewandelt wird, gab es in der Vergangenheit häufig Situationen, in denen die SLA-Fristen nicht eingehalten werden konnten, weil diese rückwirkend anhand des Erstellt-Zeitpunkts des Tickets berechnet wurden. Dieses Vorgehen haben wir nun angepasst, sodass der Zeitpunkt der Umwandlung den Startschuss für die SLA-Berechnung gibt. Somit gelten die SLA-Fristen – konkret Reaktions- und Lösungszeit – also ab dem Zeitpunkt, zu dem das Ticket als Incident gespeichert wird. Diese Zeitpunkt heißt intern Aktivierungsdatum. Diese Veränderung ist im Sinne unserer Kunden, weil wir nun einerseits Anreize reduzieren, eine Umwandlung zu vermeiden, und andererseits eine realistische Zielsetzung erzeugen, die SLA-Fristen trotzdem einzuhalten.

Da dieser Mechanismus tief in die bestehende Logik für die SLA-Berechnungen eingreift, besteht leider die Gefahr, dass wir trotz intensiver Tests nicht alle Fälle in diesem komplexen Themenfeld fehlfrei adressiert haben. Insbesondere die Nachberechnung des Aktivierungsdatums für bestehende Tickets ist sehr aufwändig. Bei Auffälligkeiten melden Sie sich daher gerne beim Team ITSM.

Kunde/Mandant einer Meldung identifizieren

Im Serviceportal kann man nun zusätzliche Infos zur betroffenen Person und zur Kontaktperson aufrufen, indem man den Mauszeiger über die jeweiligen Namen bewegt. Daraufhin erscheint ein Info-Kästchen mit weiteren Informationen. Unter anderem ist dort in der zweiten Zeile der Kunde bzw. Mandant zu erkennen. Anhand des Kunden der betroffenen Person kann man so auch feststellen, auf welches Unternehmen ein Ticket läuft.

kundeninformation-meldung.png

Genehmigungen in Serie abarbeiten

IT-Koordinatoren werden im Portal automatisch zur nächsten offenen Genehmigung geleitet. Auf diese Weise können viele Genehmigungen der Reihe nach abgearbeitet werden, ohne zwischendurch springen zu müssen.

Weitere Informationen zu Anwendern sichtbar

IT-Koordinatoren, die Anwender im Portal aufrufen, erhalten nun zwei zusätzliche Register.

  • Im Register Mitarbeiter werden alle Personen aufgelistet, die laut unseren Daten dem aktuellen Anwender als Mitarbeiter zugeordnet sind. Das sind in der Regel die Personen, für die der Anwender als Vorgesetzter eingetragen ist. Dort tauchen aber auch externe Personen auf, denen für die der aktuelle Anwender zuständig ist. Diese Informationen beziehen wir aus den Active-Directorys unser Kunden, daher sind sie nicht bei allen Mandanten gepflegt.

  • Im Register Active Directory kann man zusätzliche technische Infos zum Anwender abrufen:

    • AD-Kontoname (SAMAccountName)
    • User-Principal-Name (UPN)
    • LDAP-DN
    • SNC-Name

    Diese Angaben sind nur gefüllt, wenn ein Active-Directory-Abgleich mit dem Kunden eingerichtet ist.

Weitere erwähnenswerte Punkte

  • Wir haben einen Fehler behoben, der auftrat, wenn man zuerst die Kontaktperson eines Tickets und anschließend die betroffene Person verändert hat.
  • Im Serviceportal werden für die Suche „meine geschlossenen Tickets“ nun auch die Tickets angezeigt, bei denen der aktuelle Anwender nur betroffene Person ist.
  • Die Tatsache, dass man den Bearbeitungsmodus im Portal aktivieren muss, ist nun noch deutlicher gekennzeichnet. Außerdem kann der Bearbeitungsmodus nun auch an Ort und Stelle durch Klick auf ein Stift-Icon aktiviert werden.
  • In E-Mails zum Anfordern von Kundenfeedback wird nun immer der items-Mitarbeiter eingetragen, der das Feedback angefordert hat. Bisher wurde standardmäßig immer der Ticketbesitzer eingetragen.
  • Abteilungen und Kostenstellen werden nun automatisch in metis angelegt, wenn diese vom Kunden über eine API an items gemeldet werden. In diesem Fall können wir die Richtigkeit der Daten unterstellen und diese ungeprüft weiterverarbeiten.

Für externe Dienstleister relevante Sachverhalte

Neuer metis-Client erforderlich

Ab Produktivsetzung des neuen metis-Release muss zwingend die neue Version 2023.3.0 des metis-Client verwendet werden.

Auf der Citrix-Farm wird dieser über Nacht automatisch bereitgestellt. Die lokalen Client-Installationen werden über das Unternehmensportal bzw. SCCM ausgerollt und sollten ebenfalls zu Montagmorgen zur Verfügung stehen.

Überarbeitung der Berechnung von SLA-Zeiten

Bei Wandlungen von Tickets, also insbesondere wenn eine Serviceanforderung in einen Incident umgewandelt wird, gab es in der Vergangenheit häufig Situationen, in denen die SLA-Fristen nicht eingehalten werden konnten, weil diese rückwirkend anhand des Erstellt-Zeitpunkts des Tickets berechnet wurden. Dieses Vorgehen haben wir nun angepasst, sodass der Zeitpunkt der Umwandlung den Startschuss für die SLA-Berechnung gibt. Somit gelten die SLA-Fristen – konkret Reaktions- und Lösungszeit – also ab dem Zeitpunkt, zu dem das Ticket als Incident gespeichert wird. Diese Zeitpunkt heißt intern Aktivierungsdatum. Diese Veränderung ist im Sinne unserer Kunden, weil wir nun einerseits Anreize reduzieren, eine Umwandlung zu vermeiden, und andererseits eine realistische Zielsetzung erzeugen, die SLA-Fristen trotzdem einzuhalten.

Da dieser Mechanismus tief in die bestehende Logik für die SLA-Berechnungen eingreift, besteht leider die Gefahr, dass wir trotz intensiver Tests nicht alle Fälle in diesem komplexen Themenfeld fehlfrei adressiert haben. Insbesondere die Nachberechnung des Aktivierungsdatums für bestehende Tickets ist sehr aufwändig. Bei Auffälligkeiten melden Sie sich daher gerne beim Team ITSM.


Kundenspezifische Themen

Dieser Abschnitt enthält Themen, die nur für einen Teil unserer Kunden relevant sind.

Themen speziell für den Kunden Münster

  • Das Feld SAP-Benutzername im Zusatzformular für die Verlängerung von Konten (derzeit für die Verlängerung von externen Personen relevant) wird nun mit dem SAP-Benutzernamen der betroffenen Person vorbelegt, wenn ein SAP-System zur Person vorhanden ist.
  • Das Zusatzformular für die Anlage externer Mitarbeiter wurde ergänzt um eine Angabe zum Remote-Zugriff via Citrix.
  • Wir haben einige Anpassungen in Bezug auf die Handhabung von Standard-Hardware vorgenommen:
    • Headsets werden nun in der CMDB gepflegt und bei Ausgabe und Rücknahme von Hardware berücksichtigt. Das betrifft zum einen das entsprechende Zusatzformular sowie den Laufzettel zur Hardware-Rückgabe.
    • Auf dem Laufzettel haben wir zudem die Angabe zum IT-Lagerraum korrigiert.
    • Auf dem Zusatzformular für Standard-Hardware war das Auswahlfeld für die Anzahl von Monitoren zu klein.