Allgemeine Informationen zu Störungen

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. → Ticket im Service Desk + Anruf auf der Störungshotline erforderlich
Störung Prio 2	Das Gesamtsystem ist wesentlich beeinträchtigt. Elementare Funktionen sind nicht bzw. nur mit extremen Performanceeinbußen verfügbar. → Ticket im Service Desk + Anruf auf der Störungshotline erforderlich
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. → Ticket im Service Desk erforderlich
Fehlermeldung	Geringe Beeinträchtigung des Systems oder lediglich eine Beeinträchtigung von neuen, im Zuge der letzten beiden Releases eingespielten ergänzenden Funktionen. → Ticket im Service Desk erforderlich

Ein Teilsystem ist kein einzelnes Feature oder eine einzelne Teilfunktion, sondern eine zentrale Funktion zu gesamten "Sichten" bzw. "Bereichen" einer Anwendung.

PRINT NGEN (Redaktion/Blattplanung/Schnittstellen)
Teilsystem: Zentrale Sichten oder zentrale Schnittstellen, wie z. B. der Export an die Druckerei (es gibt zwar die Umgehungslösung, die Druck-PDFs herunterzuladen und auf anderem Weg an die Druckerei zu schicken, nichtsdestotrotz hat die Störung eine direkte Auswirkung auf die Produktion).
Kein Teilsystem: Nichtverfügbarkeit einer Formatierungsauswahl im Editor. Das ist ein normaler Bug und kein Ausfall eines "Teilsystems".

PRINT NGEN (Werbemarkt)
Teilsystem: Zentrale Sichten oder zentrale Schnittstellen, wie z. B. fehlerhafte/nicht funktionale Fakturierung.
Kein Teilsystem: Einzelner Berechnungsfehler in einem Auftrag/Anzeige. Das ist ein normaler Bug und kein Ausfall eines "Teilsystems".

CREATE
Teilsystem: Zentrale Sichten oder zentrale Schnittstellen, wie z. B. der grundsätzliche Editor oder die Beitrags-API zwischen PRINT NGEN und CREATE.
Kein Teilsystem: Nichtverfügbarkeit einer Formatierungsauswahl im Editor. Das ist ein normaler Bug und kein Ausfall eines "Teilsystems".

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.

Werktags eingegangene Tickets werden schnellstmöglich bearbeitet.

Störungsmeldungen erfolgen entweder pro-aktiv per PEIQ-Monitoring oder reaktiv durch Kund:innen.

Störungen der Prioritäten 1 & 2 müssen 24/7 von den definierten Key-Usern über die telefonische Störungshotline gemeldet werden. Zusätzlich muss ein entsprechendes Ticket im Service Desk aufgegeben werden, dessen Ticket-ID im Telefonat genannt wird. Der/die Mitarbeiter:in der Störungshotline leitet dann die Entstörung ein.

Von 23 Uhr bis 6 Uhr kann die Störungshotline durch eine automatisierte Störungsaufnahme besetzt sein. Um die vereinbarten Entstörzeiten zu gewährleisten müssen Key-User ihre Erreichbarkeit benennen, um bei der Entstörung zu unterstützen.

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.

Priorität 1	siehe Vertrag
Priorität 2	siehe Vertrag
Priorität 3	siehe Vertrag

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:

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.

PRINT NGEN und CREATE Knowledge Base