| Info |
|---|
Im Vergleich zur Projektphase, bei der ein intensiver persönlicher Austausch zentral und effektiv ist, ist der Betrieb in der Regel mit weniger Aufwänden in der Abstimmung und kleineren Anpassungen oder konkreten Fehlerbehebungen verbunden. Das Produkt “läuft”, man “produziert”, es muss nichts komplett neu konzipiert oder eingerichtet werden. Die Betriebsphase ist erreicht, sobald das Projekt abgenommen wurde und der “Go-Live” erfolgt ist. Über den Projektmanager wird auch informiert, ab wann sich berechtigte Ansprechpartner:innen für Meldungen den Betrieb betreffend an den Service Desk wenden können. |
Definition und Meldung von Störungen & Fehlermeldungen
Art | Definition |
Störung Prio 1 | Das Gesamtsystem ist mit allen wichtigen Funktionen nicht verfügbar und steht Enduser:innen auch unter Ausnutzung von Umgehungslösungen nicht mehr zur Verfügung. |
Störung Prio 2 | Das Gesamtsystem ist wesentlich beeinträchtigt. Elementare Funktionen sind nicht bzw. nur mit extremen Performanceeinbußen verfügbar. |
Störung Prio 3 | Das Gesamtsystem ist beeinträchtigt. Elementare Funktionen zur Nutzung des Systems sind verfügbar. Für ausgefallene (Teil-)Systeme* besteht eine Umgehungslösung. |
Fehlermeldung | Geringe Beeinträchtigung des Systems oder lediglich eine Beeinträchtigung von neuen, im Zuge der letzten beiden Releases eingespielten ergänzenden Funktionen. |
| Expand | ||
|---|---|---|
| ||
|
| Note |
|---|
Die Erst-Einordnung der Störung in die verschiedenen Prioritätsstufen erfolgt durch die Kund:innen unter angemessener Berücksichtigung (i) der Auswirkungen, die die Störung auf den Geschäftsbetrieb hat, und (ii) der Interessen von PEIQ. |
...
Bei einer Störungsmeldung wird mit der Diagnose der Störursache begonnen. Der Kunde bzw. die Kundin wird im angemessenen und notwendigen Umfang hierbei mitwirken. Soweit sich nach der Prüfung herausstellt, dass keine Störung der technischen Einrichtungen von PEIQ vorlag und der Kunde bzw. die Kundin dies bei zumutbarer Fehlersuche hätte erkennen können, sind PEIQ die durch die Überprüfung entstandenen Aufwendungen zu ersetzen.
Servicezeiten
PEIQ bearbeitet Störungen mindestens zu folgenden Zeiten (Servicezeiten):
Priorität 1 | Täglich, außer 23:00 bis 6:00 Uhr; ergänzend auch 23:00 bis 6:00 Uhr, soweit bereits am Vortag Priorität 1 Störungen gemeldet wurden und die Produktion dadurch beeinträchtigt war. |
Priorität 2 | Täglich, außer 23:00 bis 7:00 Uhr |
Priorität 3 | Mo. bis Fr. 8:00 bis 17:00 Uhr, außer an gesetzlichen Feiertagen |
Entstörzeiten
PEIQ bietet prioritätsabhängig das Leistungsmerkmal „Entstörzeit“. Die Entstörzeit wird bei von PEIQ zu vertretenden Störungen von Benachrichtigung durch Kund:innen oder Störungskenntnis bis Wiederinbetriebnahme der von der Störung betroffenen Betriebskomponente ermittelt. Unabhängig von der Entstörzeit gilt für die Störungshotline in der Regel eine maximale Reaktionszeit von 60-120 Minuten, je nach Vertrag, innerhalb der die Entstörung durch die Technik begonnen wird.
...
Sofern absehbar ist, dass sich eine Störung der Kategorie 1 oder 2 nicht innerhalb der in vorstehendem Absatz definierten Zeiträume beheben lässt, strebt PEIQ innerhalb der dort genannten Fristen eine Behelfslösung (Workaround) an. Die Bereitstellung des Workaround klassifiziert die Störung ggfs. in eine neue Prioritätenstufe. Für die Störungen der Priorität 3 gelten die angegebenen Reaktionszeiten innerhalb der dafür angegebenen Servicezeiten.
Ansprechpartner:innen im Service Desk
Die Ansprechpartner:innen im Service Desk sind entweder Key- oder Poweruser. Um die definierten Anforderungen zu erfüllen müssen sie mindestens die definierten Key-User Schulungen (oder ein Äquivalent dazu) durchlaufen haben und ein hohes Maß an Systemkenntnis mitbringen.
Sie müssen ausreichend Zeit mitbringen (Erfahrungswert ca. 1 FTE, abhängig von Projektgröße und Projektstatus), um die Tickets bearbeiten zu können, die interne Kommunikation zu übernehmen, Fehler vorab zu prüfen und auszusortieren und Funktionen zu testen.
Sie müssen die Befugnis haben, Aufwände freizugeben (mind. bis 1,5 PT, darüber hinaus interne Weiterleitung zur Freigabe).
Die Ansprechpartner:innen im Service Desk müssen Tests durchführen können, um neue Funktionen auf dem Testsystem abnehmen zu können, in engem Austausch zu den Kollegen stehen, um Probleme direkt adressieren zu können und vorab registriert werden, damit deren E-Mail-Adresse bekannt ist.
Für die operative Kommunikation sind alle Ansprechpartner:innen des Auftraggebers im Vertrag aufzulisten. Veränderungen sind umgehend zu kommunizieren, da nur die in dieser Liste autorisierten Ansprechpartner:innen berechtigt sind, Störungen, Fehlermeldungen, Änderungsanfragen und Feedback im Service Desk zu melden und Betriebsinformationen zu erhalten.
Bei Hinzuziehung oder Ersetzung der Ansprechpartner:innen informiert der Auftraggeber den Auftragnehmer schriftlich, sodass die entsprechenden Anpassungen in den Systemen vorgenommen werden können.
Kundenseitiger First-Level-Support
First-Level-Support für Endanwender:innen ist direkt vom Kunden durch die Ansprechpartner:innen im Service Desk zu leisten. Die erste Prüfung des Fehlers hat durch den kundenseitigen First-Level-Support zu erfolgen. Dies beinhaltet insbesondere die Reproduktion und Dokumentation - mit kurzen Screenvideos, ersatzweise Screenshots - von Fehlern. Es ist zu prüfen, ob Fehler nicht anhand der übermittelten Schulungsunterlagen oder Dokumentationen beantwortet werden können. Der First-Level-Support muss Anwenderfehler selbst entstören. Der First-Level-Support ist angehalten auch etwaige Umgehungslösungen zu identifizieren und dem Endanwender vorzuschlagen.
Für die Aufgabe von Tickets im Service Desk sind folgende Informationen mitzuliefern:
https://peiq.atlassian.net/wiki/spaces/PPSD/pages/538968073/Fehlermeldungen#NGEN-CLOUD
Bei Störungen der Priorität 1-3 bitte zusätzlich angeben:
Was genau ist durch das Problem in der Produktion gefährdet?
Gibt es evtl. einen Workaround, um den Fehler vorübergehend zu umgehen? z.B. manuelles Exportieren der PDF / Bearbeitung durch einen Kollegen, sollte es außerhalb der Servicezeiten zu einem Problem kommen, das ausschließlich einen Benutzer betrifft
Gibt es Störungsursachen, die bereits ausgeschlossen wurden? z.B. Verbindungsprobleme mit dem Internet
Erst-Einordnung der Prioritätsstufe durch Angabe in der Überschrift des Tickets (Freitext)
Bei Änderungsanfragen bitte zusätzlich angeben:
Änderungsanfragen werden für alle Benutzer gleich umgesetzt. D.h. über deren Umsetzung sollten sich (bestenfalls alle) Kollegen übereinstimmen und keiner sollte durch die Änderungsanfrage in seiner Arbeitsweise blockiert sein.
Sollte die Änderungsanfrage nur für einen bestimmten Teil der Lösung (z.B. Objekt) gelten, dies bitte deklarieren.
Bei involvierten Drittsystemen bitte zusätzlich beachten/angeben:
Vorab prüfen, auf welcher Seite der Fehler liegen könnte. Ist der Fehler schon im vorgelagerten System da / wurde der Export ins nachgelagerte System durchgeführt und sind dort Daten da / fehlerhaft oder hat der Export gar nicht stattgefunden?
Wurde ggfs. eine erste Prüfung durch den Lieferanten durchgeführt? Wenn ja: welche Ursachen wurden bereits ausgeschlossen?
Informationen zur Bearbeitung von Tickets:
Nach der Ticket-Aufgabe erhält der Key-User per E-Mail eine automatisierte Bestätigung der Meldung, zusammen mit einer Ticketnummer. Diese Ticketnummer ist beim Anruf der Störungshotline (Störungen Priorität 1 & 2) oder im Nachgang zum Anruf zu nennen, um Ticket und Anruf in Verbindung zu bringen.
Bei einigen Bearbeitungsschritten wird eine E-Mail als Status-Update an die hinterlegte E-Mail-Adresse geschickt.
Die Störungshotline leitet außerhalb der Geschäftszeiten gemäß einem Routing-Schema auf mobile Telefone des technischen Bereitschaftsdienstes weiter. Sofern diese mobilen Telefone im Zuge des Routings nicht erreicht werden können, dient als Fall-Back eine Sprachaufzeichnung (Voicemail). Bei Eintritt eines solchen Fall-Backs wird eine Alarmkette per SMS und E-Mail ausgelöst, die neben dem zuständigen Bereitschaftsdienst auch deren Vertreter und Vorgesetzte alarmiert.
Bitte Änderungsanfragen so frühzeitig wie möglich mitteilen. Für Änderungsanfragen wird kein garantiertes Umsetzungsdatum gegeben, sondern auf Basis der Release-Zyklen pro Anfrage vereinbart.
PEIQ behält sich vor, Tickets, bei denen wir in einem definierten Zeitraum keine Informationen seitens des Kunden erhalten haben, zu schließen.
Verwandte Seiten
| Filter by label (Content by label) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...