Diverse Fragen zum Incident Management im ServiceNow - wie macht ihr das?

[Stefan_PxC]

Hallo ServiceNow-Community,

ich stelle mich ganz kurz vor, da das hier mein erster Beitrag in dieser Community ist.

Mein Name ist Stefan Schäfer, ich bin 30 Jahre alt und Service Desk Manager sowie Incident Manager bei der Phoenix Contact GmbH & Co. KG in Blomberg.

Wir betreuen effektiv ca. 8000 (interne) IT-User weltweit, allerdings überwiegend in Deutschland. Insgesamt haben wir über 15.000 Mitarbeiter weltweit.

Seit April diesen Jahres setzen wir sehr erfolgreich ServiceNow für das Incident Management ein (weitere Prozesse werden nach und nach überführt).

Im Laufe der vergangenen Wochen wurden immer wieder Fragestellungen an mich herangetragen, für die es scheinbar keine 100%-Lösung gibt.

Aus diesem Grund bin ich sehr daran interessiert, ob auch andere ServiceNow-User diese Fragestellungen haben/hatten und wie damit umgegangen wird.

íœber eine rege Teilnahme an dieser Diskussion würde ich mich sehr freuen. Los geht`s:

1) In welchen Status versetzt ihr den Incident, wenn für die Lösung des Incidents ein Termin mit dem User vereinbart wurde?

Hintergrund: Aktuell verwenden wir folgende Status:

New

Work In Progress

Awaiting Problem

Awaiting RFC

Awaiting User Info

Awaiting Vendor

Resolved

Intuitiv würde sich der Status "Awaiting User Info" anbieten, da in diesem Fall auch die SLA pausiert, was im beschriebenen Fall auch angemessen ist.

Der Status selbst ist für den Fall gedacht, dass weitere erforderliche Informationen beim User angefragt wurden und die Antwort noch aussteht. Es wäre also keine saubere Lösung.

Alternative: Der Incident bleibt im Status "Work in Progress". Nachteil: Die SLA pausiert nicht und wird gebrochen, obwohl mit dem User ein Termin vereinbart und akzeptiert wurde.

2) Umgang mit Incidents, wenn ein Problem erstellt und verlinkt wurde

Aus einem Incident resultiert ein Problem, dieses wird erstellt und mit dem Incident verlinkt.

Wie geht ihr damit um?

Incident schließen, wenn ein Workaround geschaffen wurde und der User erstmal zufrieden ist? Incident in den Status "Awaiting Problem", wenn kein Workaround möglich ist? Das ist mein derzeitiger Ansatz, um es pragmatisch zu halten...

3) Umgang mit Incidents, deren Lösung erst durch ein Release herbeigeführt werden kann (kein Workaround).

Ein Incident wird erstellt und es stellt sich heraus, dass kein Workaround möglich ist. Da es sich um eine eigenentwickelte Applikation handelt, ist eine Fehlerbehebung erst mit einem neuen Release möglich. Wartezeit beträgt einige Wochen (das Release selber wird in einem anderen System dokumentiert). Wie geht ihr damit um? User informieren und den Incident schließen, obwohl die Störung noch nicht behoben ist? Incident für viele Wochen aktiv lassen (SLA-Bruch).

4) High Priority Incident: Priorität nach Behebung der Störung zurücksetzen, damit die SLA innerhalb der Nachbearbeitungszeit (Dokumentation) nicht ungerechtfertigt gebrochen wird?

Beispiel: Incident mit Prio1, vereinbarte Lösungszeit: 2h

Nach 1,5h ist die Störung behoben, die User können wieder arbeiten. Die Lösung muss aber noch dokumentiert werden und das wird noch einige Stunden in Anspruch nehmen. Die SLA wäre dann nicht mehr erfüllt.

Setzt ihr in solchen Fällen die Priorität runter mit dem Nachteil, dass high priority incidents schlecht zu reporten sind. Oder setzt ihr das Ticket in den Status resolved und dokumentiert innerhalb der Zeit, die das Ticket noch nicht in den Status "Closed" gewechselt ist (bei uns sind das 5 Tage)?

Ich bin gespannt und hoffe auf regen Erfahrungsaustausch.

Vielen Dank und viele Grüße

Stefan Schäfer

[JanStrama]

Hallo Stefan,

willkommen in der ServiceNow Community.

Zuerst möchte ich eine kleine Randnotiz zu deiner Frage machen bevor ich auf die einzelnen Punkte eingehe:

Die Community ist stark international orientiert, daher würde ich dir empfehlen deine zukünftigen Fragen in englisch zu stellen, da du so weit schneller eine Antwort bekommst.

Nun zu deinen Fragen:

zu 1)

• Wir nutzen hier auch den "Awaiting User Info" Status. Wir haben hierzu einfach unseren Prozess so definiert das wir das für alle Aktionen (auch Termine) bei den der User involviert ist (auf ihn gewartet wird) dieser Status genutzt werden soll.
• Falls es bei euch den Bedarf gibt (z.B. Reporting / Monitoring der Service Qualität). Könntet ihr auch darüber nachdenken, einen zusätzlichen Status einzuführen der z.B. "Awaiting Agreed Appointment" heißt. Die SLA Bedingungn könnt ihr dann auch so anpassen das die SLA pausiert wird

zu 2) und 3)

• Grundsätzlich sollte der Incident geschlossen werden wenn ein Workarround da ist. Ziel ist, das die Störung die gemeldet wurde irgendwie umgangen /behoben wird
• Wenn die Lösung nicht direkt möglich ist bzw. kein Workarround vorliegt. Dann gehen wir so vor das wir den INC zwar schließen, den User aber auf den Change oder Problem record hinweißen und sie auch in die "Watchlist" dafür aufnehmen, so dass Sie weiterhin updates und infos zu Ihren Problemen erhalten. Wir verlinken die Incidents dann jeweils mit dem Change oder Problem über die "related Records".
• Dadurch fällt es uns leichter einen íœberblick über die Incidents und deren eigentlichen Cause zu halten als auch die Kommuniktation und die Arbeitslast zu verschlanken

zu 4)

• Grunsätzlich halte ich es für flash die Priorität nachträglich zu ändern, da so das Reporting komplett sinnlos wird.
• Meine empfehlung hier wäre die Dokumentation entweder im Status "Resolved" zu machen, bzw. wie auch bei 1) einen zusätzlichen Status einzuführen.
• Optional könntet Ihr auch Pflichfelder setzten die die Dokumentation erfassen/Validieren, die bei dem Status "Closed" auf "Mandatory gesetzt werden. Dadurch würde der Incident erst geschlossen werden, wenn diese gefüllt sind.

Ich hoffe ich konnte dir Damit weiterhelfen.

Viele Grüße

Jan

[Stefan_PxC]

Hallo Jan,

1000 Dank für Deine ausführliche Antwort und den Hinweis mit der Sprache. Ich bin davon ausgegangen, dass deutsch in der deutschen Community die Sprache der Wahl ist. Englisch ist aber auch ok.

Zu 1) Pragmatische Ansätze, darüber werde ich nochmal nachdenken. Wir haben eine "Priorität 4 (nach Vereinbarung)" die wir nun aktuell dafür verwenden.

Zu 2/3) So machen wir es aktuell auch, an die Watchlist im PR bzw. CR habe ich noch nicht gedacht - danke.

zu 4) Hier erfolgt die Dokumentation nun im Status "Resolved", die Idee ist mir auch kürzlich gekommen. Deine Empfehlung bestätigt, dass es wohl nicht ganz verkehrt ist. 😉

Vielen Dank nochmal und auf bald

Stefan