Ticketregeln

Get Started. It's Free
or sign up with your email address
Rocket clouds
Ticketregeln by Mind Map: Ticketregeln

1. Ziele

1.1. Kein Ping-Pong

1.2. Kompetent und schnell die Probleme der Bank lösen

1.3. Nachhaltige Lösungen suchen, sonst Re-Open!

1.4. Ständig Verbesserungen anstreben

1.4.1. Neue Monitore

1.4.2. Bessere Doku

1.4.2.1. BHB

1.4.2.2. ResolveIT

1.4.3. Systemverbesserungen (Fehlermeldungen, etc.)

2. Irrläufer behandeln

2.1. Definition

2.1.1. Ticket ist uns zugeordnet, wir sind aber nicht lösungsverantwortlich

2.2. grundsätzlich

2.2.1. Vor Neuzuweisung des Tickets gründlich prüfen und nachweisen, dass andere die Lösungsverantwortung haben. Wenn möglich, korrekte Gruppe eintragen.

2.3. Zugewiesen von:

2.3.1. ASZ

2.3.1.1. Assign back

2.3.2. Endanwender

2.3.2.1. richtige Gruppe bekannt

2.3.2.1.1. selbst an richtige Gruppe zuweisen

2.3.2.2. richtige Gruppe unbekannt

2.3.2.2.1. medium/low

2.3.2.2.2. high

2.4. Ticket ist gerissen

2.4.1. Wenn nach Reißen eines Tickets klar ist, dass die Lösungsverantwortung jemand anderes hatte, wird das Ticket VOR SCHLIESSEN an diese Gruppe weitergeleitet

2.4.2. wenn nötig, BV einschalten

2.5. Sonderfall "Ankaufsprozess"

2.5.1. Prinzipiell unklar, ob Problem in Guardean oder SeeBeyond liegt

2.5.2. Deshalb bei verdächtigem Ticket Chidticket erstellen, an Guardean schicken, Masterticket an SeeBeyond

3. "suspenden"

3.1. Anwender, der Ticket aufgegeben hat, ist nicht erreichbar

3.2. Lösungszeit mit Anwender vereinbart

3.3. Beteiligte am Lösungsprozess nicht erreichbar

3.4. Zeit läuft weiter. BV rechnet diese aber heraus.

4. Experten hinzuziehen

4.1. Wenn Know-How fehlt, bei PIT oder Business Analyst nachfragen (--> 3rd Level Support). Zeit läuft dabei weiter! Anschließend, wenn sinnvoll, BHB aktualiseren

4.2. kein Weiterleiten des Tickets! Keine Gruppen für 3rd Level Support

5. Unterstützung anderer Gruppen anfordern

5.1. Child-Ticket erstellen

5.2. Lösungsverantwortung geht dabei NICHT an andere Gruppe über

5.3. Zeit läuft weiter

6. bearbeiten

6.1. Als Ergebnis des Tickets klar die Ursache der Störung und die Schritte zur Behebung dokumentieren

6.2. Alle Arbeitsschritte dokumentieren

6.2.1. Lieber zu viel als zu wenig

6.2.2. Ziel: Nachvollziehbare Bearbeitung

7. Prio ändern oder auf "Request" setzen

7.1. Nur zusammen mit Ticketersteller oder ausnahmsweise mit BV ändern

8. schließen

8.1. solved

8.1.1. Anwender kann weiterarbeiten. Anwender akzeptiert Workaround

8.2. not solved

8.2.1. prinzipiell nicht erfüllbar

8.2.1.1. Beispiele

8.2.1.1.1. Auskünfte, die Datenschutz verletzen

8.2.1.1.2. nicht durchführbare Datenänderungen

8.2.1.1.3. Störung wird in Problem weiterbearbeitet

8.2.1.2. Ticket auf "not solved" setzen

8.2.2. Problem Ticket

8.2.2.1. mit BV besprechen, ob Problem Ticket eröffnet werden kann

8.2.2.2. Kriterium: Analyse oder Lösung kann nicht kurzfristig bereitgestellt werden

8.2.3. Von Endanwender eingestellter Irrläufer mit Prio Low oder Medium

8.2.3.1. mit BV besprechen

9. Lösungszeit

9.1. Zeit läuft ab Ticketzuweisung nicht Annahme!

9.1.1. Annahme heißt nur: Innerhalb der Lösungsgruppe bearbeite ich dieses Ticket

9.2. Wie lange Ticket im Haus unterwegs ist, ist dabei egal

9.2.1. BV betrachtet nur die Zeit, in der das Ticket bei euch lag