Aufbau und Organisation eines 3rd Level Supports

www.ibsolution.de © IBsolution GmbH

Aufbau und Organisation von 3rd Level Support

16. April 2015

Matthias Arlt

IBsolution GmbH

IBsolution Webinar


Ihr vertrauensvoller Partner.

IBsolution GmbH - Webinar

Willkommen zum Webinar „ Aufbau und Organisation von 3rd Level Support“

Die Unterlagen und die Aufzeichnung finden Sie nach dem Webinar unter:

http://www.slideshare.net/IBsolutionGmbHhttp://www.youtube.com/IBsolution

Weitere Webinar-Termine:

28.04.2015 // Predictive Analysis / Infinite Insight (Überblick)

30.04.2015 // Identity Management: Integration von Cloud Diensten

05.05.2015 // AGIMENDO.process

Infos und Anmeldung sowie aktuelle Termine aufwww.ibsolution.de/veranstaltungen

Webinar - Aufbau und Organisation von 3rd Level Support2 16.04.2015

http://www.slideshare.net/IBsolutionGmbH

http://www.youtube.com/IBsolution


http://www.ibsolution.de/veranstaltungen



Chat Funktion für Fragen / Einstellungen

Teilnehmer sind während der Präsentation stumm geschaltet

Bitte nutzen Sie für Fragen die Chat-Funktion

Zum Ende des Webinars wird gesammelt auf die Fragen eingegangen

3 Webinar - Aufbau und Organisation von 3rd Level Support16.04.2015



Ihre Moderatoren

Matthias Arlt

4 Webinar - Aufbau und Organisation von 3rd Level SupportCZC16.04.2015



Unsere Beratungsschwerpunkte

BusinessIntelligence

Prozess-optimierung

TechnologieBeratung




Unser Spezialwissen

Bu

sin

ess

In

tellig

en

ce

Pro

zess-

op

tim

ieru

ng

Tech

no

log

ieB

eratu

ng

SAP IdM

SAP GRC Access Control

SAP NetWeaver SSO

SAP MDM

SAP MDGx

SAP BPM

SAP BO Data Services

SAP BO Information Steward

Web Dynpro Java

Web Dynpro ABAP

SAP NetWeaver Composition Environment

SAP Enterprise Portal

AGIMENDO

SAP Afaria

SAP HANA

SAP BI

SAP BW-IP und SAP BPC

SAP BO Reporting

SAP Analysis (MS Office & Web)

SAP Design Studio

SAP Lumira

SAP BusinessObjects Mobile

Identity und Access Management

Compliant Identity Management

Materialstammprozesse

Lieferantenstammprozesse

Kundenstammprozesse

Produktkatalog

Mobile Lösungen

Cloud Computing

Custom Development

BI-Strategie

Reporting und Analyse

Dashboards und Visualisierung

Konzernberichtswesen / Group Reporting

Unternehmensplanung / Rolling Forecast

Unternehmenssteuerung

Berechtigungen

Data Quality

Webinar - Aufbau und Organisation von 3rd Level SupportCZC7 16.04.2015



Unsere Standorte

Nordrhein-Westfalen

Neuss

Baden-Württemberg

HeilbronnBayern

München

Schweiz

Zürich Bulgarien

Sofia



1. Die Herangehensweise (Den richtigen Support definieren)

2. Die Support-Grundlagen (Support nach ITIL)

3. Service Level Agreements (SLA) und weitere Vertragsparameter

4. Kommunikation / Ticket System

5. Der Support Prozess

6. Verschiedene Support Modelle im Überblick

7. Fazit

8. Fragen und Feedback

AGENDA








7. Fazit


AGENDA



Die Herangehensweise

Was soll der Support beinhalten

Betriebsunterstützung

Time and Material Abrufauftrag (ggf. mit Weiterentwicklung)

„echter“ 1st, 2nd oder 3rd Level Support nach Standards / Support as a Service

Erwartung an Rahmenbedingungen (SLAs, Supportzeiten)

Für die richtigen Themen auf die richtige Art und Weise

Support für ein bestimmtes System (z.B. IdM System)

Support für die gesamte Architektur eines Fachthemas (z.B. alle Finanzprozesse inkl. der daran beteiligten Systeme wie Portal, CE-System, ERP)

Support für mehrere Themen / System

Den richtigen Support definieren





Was kann der Anbieter leisten

ausgehend von z.B. Firmengröße, Zielkunden und Ausrichtung, bspw.:

• Callcenter mit Fokus auf 1st Level Support

• Kleines Expertenteam mit Fokus auf 3rd Level

Wie viele Kunden / gleichartiger Support (Skaleneffekte)

Zu erwartende Datenmengen

Wie viele User / Concurrent User

Welche Datenmengen / Prozessinstanzen

Sonstige Rahmenparameter

Evtl. bestehende übergeordnete Support-Organisation beim Kunden

Evtl. bestehende SLAs

Budgetklärungen!






Sofern kein Erstsupport

Lernen aus der Vergangenheit…

• Anzahl von Problemen / Tickets

• Clusterung von Problemfällen (als Anhaltspunkt für die zu erwartenden Aufgaben)

…Einschätzen der Zukunft

• Prognosen aus anstehende Rollouts & Erweiterungen










7. Fazit


AGENDA



Die Support-Grundlagen

Incident Management

Sorgt für die schnellstmögliche Wiederherstellung des definierten Betriebszustands eines Service. Neben Störungen werden auch alle

Anfragen (Service Requests) der Anwender über das Service Desk erfasst

Problem Management

Ursachenforschung und Beseitigung von Störungen stehen im Mittelpunkt. Es werden dem Incident Management temporäre Lösungen

(Workarounds) zur Verfügung gestellt und endgültige Lösungen zu bekannten Fehlern (Known Errors) erarbeitet. Zudem

Störungsvermeidung (proaktives Problem Management)

Change Management

Es werden sämtliche Änderungen an der IT-Infrastruktur und ihrer Komponenten (Configuration Items) autorisiert und dokumentiert, um störende Auswirkungen auf den laufenden Betrieb so gering wie möglich zu halten

Configuration Managment

Die für das IT Service Management notwendigen Informationen über Infrastruktur und Services werden bereitgestellt. Änderungen

werden dokumentiert, die Aktualität der Informationen regelmäßig überprüft

Release Management

Verantwortet die Durchführung von Änderungen an der IT-Infrastruktur, so dass diese effektiv und nachvollziehbar durchgeführt

werden. Zu den Aufgaben gehören Planung, Überwachung und Durchführung von Rollouts in Abstimmung mit dem Change Management

Quelle: http://wiki.de.it-processmaps.com/index.php/Service_Support

Support nach ITIL (Kurze Erklärung und Abgrenzung)


http://wiki.de.it-processmaps.com/index.php/Service_Support






Die Support-Grundlagen

Quelle (vereinfacht): http://wiki.de.it-processmaps.com/images/pdf/Prozessuebersicht_service_support_itilv2.pdf

Support nach ITIL (Gesamtkontext)

15

IncidentManagement

ProblemManagement

ConfigurationManagement

ChangeManagement

ReleaseManagement

Webinar - Aufbau und Organisation von 3rd Level SupportCZC16.04.2015

http://wiki.de.it-processmaps.com/images/pdf/Prozessuebersicht_service_support_itilv2.pdf
























7. Fazit


AGENDA



Service Level Agreements (SLA)…

Service Level Agreement (SLA)

Der Begriff Service-Level-Agreement (SLA) oder deutsch Dienstgütevereinbarung (DGV) bezeichneteinen Vertrag zwischen einem IT-Dienstanbieter (Provider oder Dienstleister) und einem Auftraggeber, in dem wiederkehrende IT-Dienstleistungen hinsichtlich Leistungsumfang, Reaktionszeit und Schnelligkeit der Bearbeitung detailliert geregelt werden. Wichtiger Bestandteil ist hierbei die Dienstgüte (Servicelevel), die die vereinbarte Leistungsqualität beschreibt.

Quelle: http://wiki.de.it-processmaps.com/index.php/Service_Support

Was sind SLAs?








…und weitere Vertragsparameter (1)

18

Thema Bsp. Variante 1 Bsp. Variante 2 Bsp. Variante 3

Supportzeiten „Normale“ ArbeitszeitenWerktags (Mo-Fr)08:00 – 17:00 Uhr

„Erweiterte“ ArbeitszeitenWerktags (Mo-Sa)07:00 – 19:00 Uhr

24h BetriebJeden Tag (Mo-So)0:00 – 23:59 Uhr

Supportmeldung Anruf / Email an dedizierte Personen

Email durch Key-User an zentralen Postkorb Ticket im Ticketsystem

Reaktionszeit(en)(Prio sehr hoch / andere Prioritäten)

„Pauschal“ pro Ticket: 4h Je nach Ticketprio (einfach):Prio High – 2hPrio Low – 8h

Je nach Ticketprio (komplex):Prio 1 – 2hPrio 2 – 4h

Prio 3 – 9h usw.

Lösungsszeit(en)(Prio sehr hoch / andere Prioritäten)

Keine Vorgabe Je nach Ticketprio (einfach):Prio High – 3 Tage (für 90% der Tickets)Prio Low – 10 Tage (für 90% der Tickets)

Je nach Ticketprio (komplex):Prio 1 – 8h

Prio 2 – 2 Tage Prio 3 – 5 Tage usw.

Ansprechpartner / Personen Dedizierte Personen Dedizierte Ansprechpartner, „anonymes“ Supportteam

Vollständig „anonymes“ Supportteam mit Single Point of Contact (SPOC)

Leistungserbringung Remote Vor Ort Mischvariante

Enthaltene Leistungen (Proaktiv / Reaktiv)

Rein Reaktiv, nach Aufforderung des Kunden

Primär Reaktiv, minimale proaktive Aufgaben, etwa Auswerten von Log-Dateien

1 Mal pro Tag

Proaktive Monitoring-Aufgaben, evtl. weitere wiederkehrende Aufgaben sowie Reaktive Arbeit an Tickets

Zusatzleistungen keine Übernahme des Changemanagement für Support-Changes

Ausführliches Managementreporting / Auswertungen





…und weitere Vertragsparameter (2)

19

Thema Bsp. Variante 1 Bsp. Variante 2 Bsp. Variante 3

Vertragslaufzeit Keine definierte Laufzeit Kurze Mindestlaufzeit (3 Monate)

Lange Mindestlaufzeit (12 Monate)

Kündigungsfrist Monatlich kündbar 3 Monate zum Vertragsende, autom. Verlängerung um 12 Monate

1 Monate zum Quartalsende, autom. Verlängerung um 12 Monate

Supportmodell Bezahlung nach Aufwand Monatliche Grundgebühr mit einer definierten Ticketanzahl inklusive (darüber

hinaus additive Kosten)

„All inclusive“ basierend auf den SLAs

Definition von

Beistellleistungen des Kunden

Voraussetzungen und Rahmenbedingungen

Schnittstellen zu anderen Teams und Support-Einheiten

Klärung zu Zeitzonen

Wie passen Tickets aus anderen Zeitzone zu den definierten SLAs





Welche sinnvollen Mehrwerte werden angeboten

Etwa ein umfassende Qualitätsmanagement

Ein ausführliches Reporting

weitere Optionen…

…Zusatzleistungen

20

Beispiel für ein Support Reporting als Management Summary









7. Fazit


AGENDA



Kommunikation / Ticket System

Kommunikationsgrundlage

Dedizierter Ansprechpartner

Eine dem Kunden bekannte Gruppe von Supportmitarbeitern

Eine „anonyme“ Supportgruppe ggf. mit Single Point of Contact (SPOC)

Kommunikationsmöglichkeiten

Anruf (entweder dedizierte Person oder zentrale Rufnummer)

Mail (entweder dedizierte Person oder zentrale Rufnummer)

Ticket (im Ticketsystem entweder beim Anbieter oder beim Kunden)

Klare Empfehlung für Ticketsystem!

Kommunikation





Als Ticket versteht man die elektronische Form eines Anliegens (das meist vom IT-Nutzer gemeldet wird). Dies kann

eine Störung (Incident)

eine andere Anfrage (Service Request)

an den Servicedesk oder die Supporteinheiten (nach ITIL) enthalten

Quelle: http://de.wikipedia.org/wiki/Issue-Tracking-System

Festlegung der Verwendung des Ticketsystems

Problemdokumentation und –nachverfolgung in einer Projekttestphase

Problemdokumentation und –nachverfolgung im laufenden Betrieb

Aufgabendokumentation und-nachverfolgung (z.B. geplanter Serverneustart)

Dokumentation und Nachverfolgung von Änderungswünschen (Requests / Demands)

Ticket System (Aufgaben)


http://de.wikipedia.org/wiki/Issue-Tracking-System









Ticketsystem beim Anbieter mit „Schnittstelle“ zum Kunden

Kunden gibt Ticket von Hand auf

Ticket wird automatisiert durch techn. Schnittstelle zum Kunden aufgemacht

Bedeutet:

- Ticketsystem sucht Anbieter aus

- Gezielte Trainings beim Anbieter sind möglich

- Einfacher Know-How Transfer im Team des Anbieters, auch kundenübergreifend

- Schnittstelle zum Kunden / dessen Supportprozess muss definiert werden

Ticket System (Unterscheidung – Anbietersystem)





Ticketsystem beim Kunden

Es wird das jeweilige Ticketsystem beim Kunden verwendet

Bedeutung:

- Ticketsystem beim Kunden vorhanden (keine Kosten beim Anbieter)

- Entsprechende Kundenakzeptanz vorhanden

- Kein „Kommunikationsbruch“ zu anderen Kundeninfos / -tickets

- Entsprechende Einarbeitung des Anbieters muss thematisiert werden

- Einarbeitung neuer Supportmitarbeiter aufwendiger

Ticket System (Unterscheidung – Kundensystem)









7. Fazit


AGENDA



Der Support Prozess

Relevant für die Definition des Supportprozesses sind

Wo gibt es welche definierten Schnittstellen zu anderen Personen und Systemen

Was sind die Rechte und Pflichten innerhalb des Supportprozesses

Was sind die Mitwirkungspflichten des Kunden und die Ausschlüsse innerhalb des Vertrages

Welche Service Level Agreements (SLAs) liegen dem Prozess zu Grunde

Zentrale Festlegung der Zusammenarbeit

zwischen Anbieter und Kunde!




Der Support Prozess

28

Supportfall tritt ein

Prüfung u. Priorisierung des Vorgangs

durch Key-User desKunden und Ticket

an Anbieter

Bearbeitungdes Tickets

ggf. Rücksprache

mit Key-User

(Rückfragen,

Diskussion Lösungsvarianten)

Prüfungder Lösung

Ticket-eingang

Anbieter

BeginnBearbeitung

(Info an Kunde)

Anbieter

Rückmeldungder Lösung an Kunden

Schließen des Ticketsdurch denKunden

Reaktionszeit Bearbeitungszeit

„Management Attention“ bei Priorität „sehr hoch“ Meldungen

Ein Beispiel (Ticketprozessierung)

Webinar - Aufbau und Organisation von 3rd Level Support16.04.2015



Der Support Prozess

29

Bearbeitung und Verantwortungdes Anbieter

3rd Level Support

Qualitätsmanagement und Reporting

1st und 2nd Level Support

Change Prozess inkl. Tests, Transport usw.

Verarbeitung durch andere Support-Einheit

Meldungsverarbeitung beim

Softwarehersteller

Lösung bereitgestellt

(kein „Change“ notwendig)

Lösung bereitgestellt

(„Change“ notwendig)

Übergabe an anderes Team

Softwarefehler

Ticketerstellung Übergabe an 3rd Level Support

Beginn SLAs

Ein Beispiel (Schnittstellen in einem 3rd Level Support)









7. Fazit


AGENDA



Verschiedene Support Modelle im Überblick

Es ist von Vorteil, wenn der Anbieter bestimmte Leistungen als Pakete zusammenzufasst (etwa Monitoring oder ein nachgelagertes Reporting)

Zudem sollte der Anbieter verschiedene Pakete und Optionen zur Auswahl haben, aus denen der Kunde sich seine(n) passende(n) aussuchen und bei Bedarf umstellen kann

Für den Anbieter ist vorteilhaft, wenn er Pakete hat, welche sich für mehrere Kunden anwenden lassen um intern Synergien zu schaffen und Kosten zu optimieren (bessere Konditionen für Kunden möglich)

Optimal ist eine Matrix aus Leistungen (Inhalt) und Konditionen (SLAs)





Ganzheitlicher Support für eine fachliche Anwendung mit mehrere Modulen

Eingebettet in die Kundeninfrastruktur

Klare Abgrenzungen und Schnittstellen

Beispielmodell (Leistungen)

32

Infrastruktur(Netzwerk, Server usw.)

Betriebssystem Serv

ices

(Auto

m. Jo

bs,

Mail P

ostf

ächer,

Tele

fonnum

ern

usw

.)

Andere

Anw

endungen

(Sonstig

eKundensyste

me,

Dritta

nbie

ter

usw

.)

Anwedungs-server

Anwendungen

Fachliche Kernanwendung

MonitoringProaktiveSupport Aufgaben

ReaktiveSupport Aufgaben

Administration von Produktfehlern





Modell mit 2 Varianten aus

unterschiedlichen Servicezeiten und

unterschiedlicher Ticketanzahl inklusive

Basisservices in beiden enthalten

Beispielmodell (Konditionen)

33

BASIS SupportX.XX €/ Monat

Servicezeit

8.00 -17.00 CET

an Werktagen

Reaktionszeit 2 Stunden

Inkl. 25 Tickets / Monat

Beinhaltet 3rd Level Support

Monitoring & Proaktiver Support

(in beiden Paketen beinhaltet)

ERWEITERTER SupportY.YY €/ Monat

Servicezeit

7.00 -19.00 CET

an Werktagen

Reaktionszeit 2 Stunden

Inkl. 35 Tickets / Monat

Beinhaltet 3rd Level Support

Qualitätsmanagement und Reporting

(in beiden Paketen beinhaltet)

Z.ZZ € /

jedes

weiteres

Ticket

+









7. Fazit


AGENDA



Fazit

35

23.04.2015 Webinar - Performance bei der Anwendungsentwicklung

Strategische Ausrichtung des Anbieters wichtig / was kann er anbieten

Klare Definition von Kundenanforderungen (was ist das Ziel)

Definition der passenden Service Level Agreements elementar

Support in Pakete, evtl. als Matrix vorteilhaft

Auswahl der Kommunikation / des Ticketsystems sehr wichtig









7. Fazit


AGENDA



Haben Sie Fragen?

Fragen und Feedback




IBsolution GmbH - Webinar

Willkommen zum Webinar „ Aufbau und Organisation von 3rd Level Support“

Die Unterlagen und die Aufzeichnung finden Sie nach dem Webinar unter:

http://www.slideshare.net/IBsolutionGmbHhttp://www.youtube.com/IBsolution

Weitere Webinar-Termine:

28.04.2015 // Predictive Analysis / Infinite Insight (Überblick)

30.04.2015 // Identity Management: Integration von Cloud Diensten

05.05.2015 // AGIMENDO.process

Infos und Anmeldung sowie aktuelle Termine aufwww.ibsolution.de/veranstaltungen


http://www.slideshare.net/IBsolutionGmbH



http://www.ibsolution.de/veranstaltungen


IBsolution GmbH

Im Zukunftspark 8D-74076 Heilbronn

www.ibsolution.de

MATTHIAS ARLT

Technology

Aufbau und Organisation eines 3rd Level Supports