Anlage 5 Leistungsbeschreibung Support - lup-dataroom.com€¦ · o in den SAP ERP 6.0 Modulen SAP...

Anlage 5

Leistungsbeschreibung

Support

Helaba

Landesbank Hessen-Thüringen Girozentrale

Strahlenberger Straße 11

63067 Offenbach

Inhaltsverzeichnis

1 Präambel ....................................................................................................................... 3

2 Gegenstand ................................................................................................................... 4

2.1 Serviceobjekte.......................................................................................................................... 4

3 Leistungsbeschreibung ................................................................................................... 6

3.1 Allgemeine Leistungsbeschreibung ......................................................................................... 6

3.2 Übergeordnete Leistungsbeschreibung ................................................................................... 6

3.3 Service Desk (SPOC) ................................................................................................................. 6

3.4 Incident Management.............................................................................................................. 7

3.5 Problem Management ........................................................................................................... 14

3.6 Unterstützungsleistungen ...................................................................................................... 15

4 Vergütung .................................................................................................................... 16

Anlage 5 Leistungsbeschreibung Support Seite 3 von 16

1 Präambel

Der AN verpflichtet sich zur Erbringung der in dieser Leistungsbeschreibung beschriebenen Support-leistungen und den beschriebenen Unterstützungsleistungen und schuldet insoweit auch den ver-tragsgerechten Erfolg, die Helaba ist zur Entrichtung der vereinbarten Vergütung verpflichtet.

Dieses Dokument beschreibt den vom AN zu erbringenden Leistungsumfang, die Zuständigkeiten und

Schnittstellen, das geforderte Leistungsniveau (Service Level).

Der AN trägt die Erfolgsverantwortung für die vereinbarten Leistungen, insbesondere im Rahmen des Incident Management. Er haftet für die Leistungen seiner Subunternehmer und seiner Zulieferer wie für seine eigenen Leistungen.

Der AN wird seine Leistungen jeweils entsprechend dem aktuellen Stand der Technik und durch Pro-

zesse erbringen, die gemäß dem Qualitätsstandard ISO 9001 zertifiziert sind.

Im Falle von Unklarheiten oder Widersprüchen zwischen den einzelnen Vertragsdokumenten gilt folgende Rangordnung:

1. Leistungsbeschreibung

2. Einzelvertrag.

Im Folgenden werden Aufgaben und Verantwortlichkeiten des AN und der Helaba wie folgt definiert:

Ausprägung Beschreibung

R = Responsible Die jeweilige Partei ist für die Durchführung in vollem Umfang verant-

wortlich.

C = Consulted Die jeweilige Partei ist von der anderen Partei einzubinden und wirkt

beratend an der entsprechenden Aufgabe mit.

I = Information Die jeweilige Partei leitet an die jeweils andere Partei der Aufgabe ent-

sprechende Informationen zu. Dies kann z.B. eine Statusmeldung, eine

Abschlussmeldung oder eine sonstige Information sein.

S = Sign-Off Die jeweilige Partei muss die Ausführung der Aufgabe freigeben. Dies

impliziert, dass die jeweils andere Partei Informationen bereitstellen

muss, die eine Freigabe ermöglichen.


2 Gegenstand

Gegenstand der Leistungsbeschreibung Support ist die Beschreibung von Leistungen und wesentli-

chen Aufgaben im Umfeld der Fehler- und Störungsbehebung der IT Anwendungen der Öffentlichen

Förderung WIBank (ohne Agrarflächenförderung).

Die internen Prozesse bei der Vertragsparteien sind nicht Bestandteil dieser Vereinbarung. Die Sup-

port-Prozesse des AN orientieren sich an den Erkenntnissen der IT Infrastructure Library (ITIL) in ei-

ner aktuellen Fassung.

Die vom AN geschuldeten Leistungen im Rahmen des Supports der IT Anwendungen des Öffentlichen

Fördergeschäfts (ohne Agrarflächenförderung) werden zur einfacheren Handhabung und besseren

Lesbarkeit nachfolgend als „Service“ benannt. Darüber hinaus wird im Folgenden auf den Zusatz

„ohne Agrarflächenförderung“ bei den „IT Anwendungen des Öffentlichen Fördergeschäfts“ verzich-

tet, ist allerdings jederzeit inkludiert.

2.1 Serviceobjekte

Die vorhandenen IT Anwendungen der Öffentlichen Förderung dienen der Durchführung von ca. 250

Förderverfahren.

Die derzeitigen Anwendungssysteme der Öffentlichen Förderung stellen die Abwicklung der Förder-

verfahren der Wirtschafts-, Infrastruktur-, Wohnungs- und Städtebauförderung, sowie die investive

Agrarförderung in Hessen von der Antragstellung, der Prüfung der Fördervoraussetzungen, der Be-

rechnung der Förderbeträge, die Auszahlung und Verbuchung an die Antragsteller, das Berichtswe-

sen bis hin zum Rechnungsabschluss gegenüber der EU sicher.

Dazu gehören alle im Rahmen der Öffentlichen Förderung in Hessen angebotenen Maßnahmen, bei-

spielsweise die:

Abwicklung von Förderprogrammen der Europäischen Strukturfonds ELER / EGFL,

EFRE, ESF ,

Infrastrukturförderung,

Gründungs- und Wachstumsfinanzierung,

Innovationsförderung,

Wohnungs- und Städtebau,

Dorf- und Regionalentwicklung,

Gemeinschaftsaufgabe der regionalen Wirtschaftsstruktur.

Die IT Anwendungen der Öffentlichen Förderung umfassen, vereinfacht dargestellt, folgende Kom-

ponenten:

- Das Antragssystem ABAKUS (Aktuelles Förderbanken Antrags- und Kundensystem) als ein Add-On basierend auf den Lösungen von SAP, inklusive der Mittelbewirtschaftung, sowie

- ein SAP ERP 6.0 System mit den Modulen: SAP CML, SAP FI, SAP FSCM (SAP TRM) ge-gliedert in eine dreistufige Systemlandschaft (Entwicklungssystem, Testsystem und Produktionssystem.

- Diverse Portalanwendungen:


o ESF-Landesportal, o BiFi-Portal (Bildungsfinanzierung), o GuW Portal (Gründungs- und Wachstumsfinanzierung), o ABAKUS Kundenportal.

- Schnittstellen und Anbindung an spezifische „Randsysteme“ z.B. o zum dispositiven Berichtssystem „Infoportal“, o zum Landesreferenzmodell Hessen (LRM) und o zur Anwendung SEStERZ (Software für die Einkommens- und Strukturförderung)

im Rahmen des EGFL (Europäischer Ausrichtungs- und Garantiefonds für Land-wirtschaft).

Die nachfolgende Darstellung des Bebauungsplanes der Öffentlichen Förderung (ohne Agrarflächen-

förderung) vermittelt einen abschließenden graphischen Überblick.

Abbildung 1 - Zielbild Öffentliches Fördergeschäft


3 Leistungsbeschreibung

3.1 Allgemeine Leistungsbeschreibung

Vom AN wird erwartet, dass die Aufgaben vor Ort immer durch die gleichen Personen durchgeführt

werden. Begonnene Aktivitäten werden von denselben Ressourcen fertig gestellt. Etwaiger Personal-

austausch ist mit der Helaba vorab abzustimmen.

Die Fehlerbehebung und die damit verbundenen Programmanpassungen sind nur im Rahmen der in

der Helaba und in der Bankenkooperation gültigen Richtlinien zu entwickeln. Außerdem sind bei

Entwicklungen bzw. Anpassungen am System der Helaba entsprechende Softwaredokumentationen

zu erstellen. Dokumentationen müssen von Dritten nachvollziehbar sein. Darüber hinaus sind die

geltenden Verfahren der Helaba (im Zusammenhang mit Entwicklung, Change Management, Incident

Management) einzuhalten und zu dokumentieren.

Anpassungen am SAP- oder ABAKUS-Standard sind im Vorfeld mit der Helaba abzustimmen.

Der AN schuldet qualitätsgesicherte und getestete Lösungen.

Die gesamte Kommunikation mit der Helaba hat in deutscher Sprache zu erfolgen.

3.2 Übergeordnete Leistungsbeschreibung

Vom AN sind folgende Leistungen zu erbringen:

Second und Third Level Support o in den SAP ERP 6.0 Modulen SAP CML, SAP FI, SAP FSCM (SAP TRM), im ABAKUS (lo-

kale Funktionen) , insbesondere Mittelbewirtschaftung, o Fehlerbereinigung und Systemeinstellungen der v.g. Module und Anwendung

(Customizing), o des Schnittstellendesigns und -entwicklung, o in Formularen und Variablendesign, o für die Portale der Öffentlichen Förderung,

Durchführung von Entwicklertest im Rahmen der Fehlerbehebung,

Unterstützende und vorbereitende Tätigkeiten in Bezug auf das notwendige Transportver-fahren und Deployment.

3.3 Service Desk (SPOC)

Der AN stellt einen Mitarbeiter als Single Point of Contact (SPOC) für die Belange des Incident- und

Problem-Management in den Räumen der Helaba zur Verfügung.

Der Service Desk ist während der Servicezeit für die Ticketsteuerung und –verwaltung für die IT An-

wendungen des Öffentlichen Fördergeschäfts zuständig. Der AN trägt während der gesamten Lö-

sungs- und Bearbeitungszeit die Verantwortung für die Einhaltung der vereinbarten SLAs und KPIs.

Die Helaba stellt dem AN einen Raum, Arbeitsplätze, die technischen Hilfsmittel für die Helaba Work-

flow-Tools und die dafür notwendigen Accounts, inklusive Lizenzen in hinreichender Anzahl, zur Er-

füllung der jeweiligen Verpflichtungen unentgeltlich zur Verfügung.


3.3.1 Leistungen und Verantwortlichkeiten

Im folgenden Abschnitt sind die für das Service Desk des AN wesentlichen Leistungen definiert.

Leistungsbeschreibung Ausprägung Helaba AN

Annahme von Supportanfragen, die von der Helaba über-

mittelt werden

Innerhalb der

Serviceszeit

R

Untersuchung, Prüfung und Bearbeitung / Lösung der

Störungen/Supportanfrage sowie deren Dokumentation

Innerhalb der

Servicezeit

I R

Überwachende Begleitung der Abarbeitung der Support-

anfragen während der gesamten Bearbeitungsdauer (auch

eventuell eingebunder Dritter)

Innerhalb der

Servicezeit

I R

Information der Helaba über den Fortschritt / Bearbei-

tungsergebnisse falls die Lösung die KPI übersteigt

Innerhalb der

Servicezeit

I R

Wenn notwendig, Prüfung der gelösten Anfragen und

Abnahme durch die Helaba einholen, sowie bei Bedarf0

anschließend Supportanfrage auf Status „abgeschlossen“

setzen.

Innerhalb der

Servicezeit

I / C R

3.4 Incident Management

Vorrangiges Ziel des Incident Managements ist die schnellstmögliche Wiederherstellung des Service

innerhalb der vereinbarten Service Level im Falle einer Störung. Unter Incident Management werden

alle Aufgaben verstanden, die es der Helaba ermöglichen, die vereinbarte Leistung wieder zu bezie-

hen und in der Bearbeitung der Geschäftsprozesse fortzufahren. Aus dem Incident Management

erfolgt die eventuelle Übergabe von Aufgaben in das Problem- und Change Management.

3.4.1 Priorisierung von Störungsanfragen

Über die Einordnung von aufgetretenen Störungen oder Mängel in die entsprechende Priorität ent-

scheidet die Helaba, unter angemessener Berücksichtigung der Auffassung des AN. Die letzte Ent-

scheidung über die Einordnung in eine Priorität bleibt der Helaba vorbehalten.

Die Helaba legt folgende Klassifizierung zur Vergabe von Prioritäten zugrunde:

Priorität 1: „sehr dringend/sehr wichtig“ = Betriebsverhindernde Störung oder Mangel

Eine betriebsverhindernde Störung oder Mangel liegt vor,

a. wenn die Nutzung der IT Anwendungen der Öffentlichen Förderung beispielsweise aufgrund von Fehlfunktionen, falschen Arbeitsergebnissen oder Antwortzeiten unmöglich ist oder schwerwiegend eingeschränkt wird.

b. wenn die Störung oder der Mangel geeignet ist, die Geschäftstätigkeit der Helaba erheblich zu behindern oder behindert, die Sicherheit, Vertraulichkeit oder Integrität der Daten der Helaba erheblich zu gefährden oder gefährdet oder das Ansehen der Helaba in der Öffent-lichkeit zu schädigen oder schädigt.


c. wenn durch die Störung oder den Mangel exponierte, d.h. in besonderer Weise öffentlich-keitswirksamer Funktionen ausgefallen sind, Hackerangriffe, Virenbefall, die Ausspähung personenbezogener Daten oder der Verlust von Geschäftsdaten.

Priorität 2: „dringend/wichtig“ = Betriebsbehindernde Störung oder Mangel

Eine betriebsbehindernde Störung oder Mangel liegt vor,

d. wenn die Nutzung der IT Anwendungen der Öffentlichen Förderung beispielsweise aufgrund von Fehlfunktionen, falschen Arbeitsergebnissen oder Antwortzeiten zwar nicht unmöglich ist oder schwerwiegend eingeschränkt wird, die Nutzungseinschränkung(en) aber zugleich auch nicht nur unerheblich ist (sind).

Priorität 3: „weniger dringend/weniger wichtig“ = Sonstige Störung oder Mangel

Eine sonstige Störung oder Mangel liegt vor,

e. wenn die Nutzung der IT Anwendungen der Öffentlichen Förderung nicht unmittelbar und/oder nicht bedeutend/erheblich beeinträchtigt wird.

3.4.1.1 Bearbeitung von Priorität 1 Störungsmeldungen

Der AN wird umgehend nach Übermittlung der Störungsmeldung mit der Bearbeitung der Priorität 1

Meldung beginnen und die Helaba über die Bearbeitung informieren. Der AN wird der Helaba früh-

zeitig eine Indikation über die zu erwartende Lösungsdauer zukommen lassen.

Eine Störungs- oder Mangelmeldung der Priorität 1 wird auch nach Ablauf der Servicezeiten weiter

bearbeitet. Der AN hat, wenn zum Ende der Servicezeiten noch Störungs- oder Mangelmeldungen

der Priorität 1 nicht gelöst sind, sich mit der Helaba über das weitere Vorgehen abzustimmen und

gleichzeitig über den erwarteten Zeitpunkt zur Übergabe zum Test/Abnahme an die Helaba informie-

ren.

Eine Beendigung bzw. Unterbrechung der Bearbeitung einer Priorität 1 Störung ohne vorherige Ab-

stimmung mit der Helaba wird als Verletzung des vereinbarten Service Level gewertet.

3.4.1.2 Bearbeitung von Priorität 2 Störungsmeldungen

Übersteigt die Beseitigung von Störungen oder Mängel der Priorität 2 drei Arbeitstage, stellt der AN

der Helaba mindestens täglich ab dem vierten Störungstag schriftliche Statusberichte zu der laufen-

den Störungs- und Mängelbeseitigung zur Verfügung.

3.4.1.3 Bearbeitung von Priorität 3 Meldungen

Die direkte Korrektur einer Störungsmeldung der Priorität 3 ist für die Nutzung des Systems nicht

immer zeitnah notwendig. Sofern die Bearbeitung nicht zu dem im REMUS gewünschten Stichtag

erfolgen kann, ist eine Absprache mit der Helaba bezüglich Lösungs- und Übergabeterminen vorzu-

nehmen.


3.4.1.4 Zusätzliche Möglichkeiten der Störungs- und Mangelbeseitigung

Bietet der AN der Helaba zur Vermeidung oder Beseitigung von Störungen oder Mängeln „Patches“

(darunter werden Bugfixes, eine neue Programmversion oder Programmteile etc. verstanden) an, so

hat die Helaba diese (wenn und sobald es für sie zumutbar ist) zu übernehmen und gemäß den Instal-

lationsanweisungen des AN zu installieren.

Die Störungs- und Mangelbeseitigung in Form von Patches kann die Helaba ablehnen, wenn diese

nicht die gleiche Kompatibilität und Funktionalität wie das der ersetzte Programmteil aufweisen.

Die Beseitigung von Störungen und Mängel kann darüber hinaus auch in der Form von Handlungsan-

weisungen gegenüber der Helaba erfolgen. Die Helaba hat derartige Handlungsanweisungen zu be-

folgen, es sei denn, dies ist ihr nicht zumutbar.

Kann der AN eine Störung oder einen Mangel nicht innerhalb des vertraglich vereinbarten Zeitraums

beseitigen, stellt er der Helaba auf eigene Kosten, d.h. auf Kosten des AN, vorübergehend eine Um-

gehungslösung zur Verfügung (soweit dies für den AN wirtschaftlich zumutbar ist). Die Verpflichtung

des AN zur dauerhaften Störungs- und Mangelbeseitigung bleibt durch die Lieferung einer vorüber-

gehenden Umgehungslösung unberührt.

3.4.2 Servicezeit

In der Servicezeit werden im Falle von Störungen (Incidents) notwendige Maßnahmen eingeleitet

und die Störungen im Rahmen der vereinbarten Service Level behoben.

In dieser Zeit stehen seitens des AN qualifizierte und mit dem Service vertrauten Ansprechpartners

für Störungsbeseitigung, die Behandlung von Anforderungen der Helaba (Serviceanforderungen und

Changes) zur Verfügung. Die gilt im Übrigen ebenfalls für die erweiterte Servicezeit (Optionale Leis-

tung).

Für den Service gilt die folgende Servicezeit je Serviceklasse:

Serviceklasse

Zeit Produktiv Nicht produktiv

Servicezeit Mo - Fr*

7:00 h –

18:00 h**

Mo - Fr*

9:00 h –

16:00 h**

* Ohne hessische und bundesweite Feiertage .

** Lokale Zeit in Deutschland.

3.4.3 Lösungszeiten

Die Lösungszeit ist definiert als die Zeitspanne von der Übergabe der Störungsmeldung durch die

Helaba an den AN bis zur Lösung. Zur Berechnung der Lösungszeit werden nur die Servicezeiten ver-

wendet.


3.4.4 Rufbereitschaft und erweiterter Service

Eine Rufbereitschaft durch den AN wird als optionale Leistung angeboten. Bei Bedarf stellt die Helaba

eine schriftliche Anfrage mit den konkreten Anforderungen zur Rufbereitschaft. Der AN gibt kurzfris-

tig eine Rückmeldung, ob die geforderten Leistungen zur Rufbereitschaft erbracht werden können.

Für die Rufbereitschaft sind folgende Ausprägungen zu berücksichtigen:

a. Rufbereitschaft Montag bis Freitag 6:00 Uhr bis 21:00 Uhr

b. Rufbereitschaft Samstag bis Sonntag 6:00 Uhr bis 21:00 Uhr.

Als erweiterte Servicezeit sind folgende Ausprägungen zu berücksichtigen:

a. Erweiterte Servicezeit Montag bis Freitag 6:00 Uhr bis 21:00 Uhr,

b. Erweitere Servicezeit Samstag bis Sonntag 6:00 Uhr bis 21:00 Uhr.

Die jeweiligen Tätigkeiten werden in Abhängigkeit von der Anforderung der Helaba mit dem AN ab-

gestimmt.

3.4.5 Organisation und Prozesse

3.4.5.1 Organisatorische Anforderungen

Störungen werden durch die Helaba an den AN adressiert.

Der AN überwacht den Eingang der Störungsanfrage/Incidents selbstständig.

Für eine reibungslose Bearbeitung und Verfolgung von Störungsanfragen sind nachfolgende Prämis-

sen durch den AN einzuhalten:

Keine Störungs-, Incidentbearbeitung ohne Auftrag

o Das bedeutet, dass nur Unterstützung gewährleistet wird, wenn zu dem Vorgang eine

Störungsanfrage an den AN übergeben wurde.

o Eine nachträgliche Beauftragung / Übergabe ist nur im Ausnahmefall zulässig und mit

der Helaba im Voraus abzustimmen.

3.4.5.2 Berechtigungen

Für den Fall, dass die Beauftragung über ein Workflowttool der Helaba erfolgt, müssen entsprechen-

de Zugriffsberechtigung rechtzeitig initiiert werden. Um entsprechende Zugriffsberechtigungen ein-

richten zu können, sind der Helaba die für die Störungs-, Incidentbearbeitung relevanten Mitarbeiter

spätestens vier Wochen vor Leistungsaufnahme zu benennen bzw. während der Vertragslaufzeit mit

einer Vorlaufzeit von vier Wochen vor Beginn der Tätigkeiten anzumelden.

3.4.6 Leistungen und Verantwortlichkeiten

Durch den AN wird der Second- und Third Level Support übernommen. Erkennt der AN Störungen

und Mängel vor der Helaba wird der AN proaktiv die Helaba darüber informieren.


Im Folgenden sind die für das Incident Management wesentlichen Leistungen definiert.


Annahme einer Störungsanfrage Innerhalb der

Servicezeit

R

Soweit nicht bereits in vorgelagerten Prozessschritten

erfolgt:

Prüfung der Störungsanfrage auf formale Vollständig-

keit, Richtigkeit und Priorität

Innerhalb der

Servicezeit

R

Bearbeitung der Störungsanfrage/Incidents inklusive Rück-

fragen.

Wenn die Bearbeitung einer Störung wegen ausstehender

Mitwirkungsleistung der Helaba nicht fortgesetzt werden

kann (z. B. fehlende Informationen), wird die Bearbeitung

ausgesetzt und entsprechend kommentiert. Grund und

voraussichtliche Dauer der Unterbrechung werden doku-

mentiert und der Anfragende respektive der Melder der

Störung wird informiert.

Innerhalb der

Servicezeit

R

Prüfung historischer Störungsanfragen / Incidents zur Lö-

sungsfindung

Innerhalb der

Servicezeit

R

Soweit keine abschließende Lösung möglich ist, Imple-

mentierung eines Workaround

Innerhalb der

Betriebszeit

I R

Übergabe in das Problem Management, falls kein Work-

around / keine Lösung gefunden werden kann

Innerhalb der

Servicezeit

I R

Aktualisierung der Störungsmeldung Innerhalb der

Servicezeit

I R

Umsetzung der Lösung/Behebung der Störung/des In-

cidents und Transport/Deployment in das Testsystem ver-

anlassen

Innerhalb der Ser-

vicezeit oder nach

Abstimmung mit

der Helaba

I R

Falls sinnhaft und möglich, Durchführung eines Vorabtests

auf dem Testsystem und Dokumentation des Tests per

PDF bzw. Screenshots

Innerhalb der

Servicezeit

I R

Dokumentation der Lösungsmaßnahmen zur Störungsbe-

hebung in der zugehörigen Störungsanfrage

Innerhalb der

Servicezeit

I R

Einholen der Abnahme Innerhalb der Ser-

vicezeit

I R

Erstellung eines CRs (Change Requests), falls die Lösung Innerhalb der I R



mit der Durchführung eines Changes verbunden ist Servicezeit

Veranlassung des Transports/Deployments in das Produk-

tionssystem (Erstellung notwendiger Transportdokumen-

te)

Innerhalb der Ser-

vicezeit

C R

Weiterbearbeitung der Störungsmeldung auch in den Fäl-

len, in denen unklar ist, in wessen Verantwortungsbereich

die Ursache für die Störungsmeldung liegt.

Innerhalb der

Betriebszeit

C R

Gesamtkoordination und Steuerung der Entstörung in den

Fällen, in denen unklar ist, in wessen Verantwortungsbe-

reich die Ursache für die Störung liegt.

Innerhalb der

Servicezeit

R C

3.4.6.1 Kommunikation

Die Zuordnung der Störungsanfrage erfolgt an den durch den AN benannten Mitarbeiter / Mitarbei-

terin des Service Desk .

Der Service Desk des AN nimmt die Störungsanfrage „in Bearbeitung“ und prüft die Zuständigkeit.

Liegt die Lösungskompetenz beim AN, bleibt dieser über die gesamte Bearbeitungsdauer der Anfrage

deren zuständiger „Owner“. Falls der AN nicht zuständig ist, wird die Störungsanfrage/der Incident

an die Helaba zurück gegeben.

Ist die Lösung der Störungsanfrage unter Mitwirkung von Drittbeteiligten, wie Subunternehmer not-

wendig, koordiniert und überwacht der AN eigenverantwortlich den Lösungsvorgang.

Im Rahmen der Bearbeitung und Lösung der Störungsanfrage können Rückfragen im Hinblick auf die

Recherche zur spezifischen Fehlerkonstellation an den in der Störungsanfrage vermerkten fachlichen

Ansprechpartner erfolgen.

Die nachfolgende Prozessdokumentation visualisiert den Störungs-/Incident-Regelprozess zum Zeit-

punkt des Vertragsabschlusses.


Abbildung 2 - Regelprozess Störungsbearbeitung


3.4.7 Service Level und KPI’s

3.4.7.1 KPI - Definition

KPI Definition

Lösungszeit Zeitdauer von der Übergabe/Zuweisung der Störungsanfrage bis zur Übergabe

der Lösung zum Test und zur Abnahme

3.4.7.2 Service Level

Zur Bewertung der Störungsbeseitigung (Incident Management) wird der Service-Parameter „Lö-

sungszeit“ herangezogen.

Parameter Priorität Lösungszeit

Innerhalb Servicezeit

Service Level

Erfüllungsgrad

Lösungszeit

(maximal)

1 8 Stunden 85 % pro Monat

2 14 Stunden 90 % pro Monat

Bei Incidents der Priorität 1 werden die Arbeiten zur Wiederherstellung nicht unterbrochen, auch

wenn das Ende der Servicezeit erreicht ist.

3.4.7.3 Berichte

Sofern eine Analyse zur Überwachung und Einhaltung der Service Level bzw. KPI’s aus Sicht der Hela-

ba notwendig ist, wird der AN die hierzu benötigten Berichte und Analyse auf Basis vorhandener

Daten zeitnah in abgestimmter Form und terminlicher Absprache bereit stellen.

3.5 Problem Management

Die Analyse und die nachhaltige Vermeidung von Störungen (Incidents) stehen im Mittelpunkt des

Problem Managements. Hier werden dem Incident Management temporäre Lösungen (Work-

arounds) zur Verfügung gestellt und endgültige Lösungen bekannter Fehler (Known Error) erarbeitet.

Ziel ist es, Probleme im Verantwortungsbereich des AN zu identifizieren, transparent zu machen, den

Lösungsfortschritt zu begleiten und die Anzahl der Störungen / Incidents zu reduzieren. Das Problem

Management umfasst folgende wesentlichen Leistungsinhalte:

Problem-/Fehleridentifikation, -analyse , -verfolgung, -beseitigung, und -dokumentation

Klassifizieren der erkannten Probleme in Kategorien

Problemanalyse (reaktiv/aktiv)

Problemtracking (Verfolgen der Probleme)

Initiierung von Change Requests


Das Problem Management beinhaltet sowohl reaktives als auch proaktives Handeln zur Lösung und

Vermeidung von Problemen. Das reaktive Problem Management beschreibt den Ablauf von der Feh-

leridentifikation bis zur strukturellen Behebung durch das Change Management. Im proaktiven Prob-

lem Management werden Analysen von Störungen, Incident Daten, Trendanalysen sowie Ergebnisse

aufbereitet und Lösungen entwickelt, um Störungen bereits vor ihrem Auftreten zu verhindern.

Das Problem Management des AN wird aktiv, wenn:

ein schwerwiegender Störung / Incident auftritt, für den eine strukturelle Lösung gefunden

werden muss,

die Analyse der Störungs- / Incident Daten auf eine Anhäufung von Störungen / Incidents

hindeutet bzw. ein Trend erkennbar ist,

die Analyse / das Monitoring der IT-Infrastruktur Schwachpunkte nachweist, die zu neuen

Störungen / Incidents führen können.

Die primären Ziele des Problem Managements bestehen darin, dem Auftreten von (sich wiederho-

lenden) Störungen vorzubeugen und die Auswirkungen von Störungen, die nicht verhindert werden

können, minimal zu halten und einer Lösung zuzuführen.

3.6 Unterstützungsleistungen

3.6.1 Personaleinsatz

Der AN wird zur Leistungserbringung nur eigenes (dazu zählen auch das Personal der in Anlage 3

„Subunternehmer“ des Einzelvertrages genehmigte Unternehmen) zuverlässiges, gutbeleumdetes

Personal einsetzen. Der Einsatz dritter Personen durch den AN bedarf der Zustimmung der Helaba.

Der AN bestimmt in Eigenverantwortung die Art und Weise der Leistungserbringung. Der AN über-

nimmt die Ergebnisverantwortung für die Unterstützungsleistungen und ist grundsätzlich frei in der

Auswahl der Mitarbeiter, die für die Leistungserbringung eingesetzt werden.

Die Helaba hat das Recht den unverzüglichen Austausch einzelner vom AN eingesetzten Personen zu

verlangen, soweit sie das Vorliegen eines wichtigen Grundes nachweist, der den weiteren Einsatz der

betreffenden Person unzumutbar macht.

Soweit nicht anders vereinbart ist der Ort der Leistungserbringung der Sitz der Helaba.

Die vom AN in den Räumen der Helaba eingesetzten Personen unterliegen den Weisungen des AN

und sind dessen Erfüllungsgehilfen. Insbesondere erfolgen Anweisungen, durch die der Gegenstand

der von den eingesetzten Personen zu erbringenden Leistungen bestimmt wird, ausschließlich durch

den AN. Die vom AN eingesetzten Personen sind in der Einteilung ihrer Arbeitszeit grundsätzlich frei.

Der AN wird dafür Sorge tragen, dass der Arbeitszeitrahmen der Helaba eingehalten und der Arbeits-

ablauf bei der Helaba durch die eingesetzten Personen nicht beeinträchtigt wird.

Der AN stellt sicher, dass von ihm eingesetzte Personen, die Zugang zum Internet und Intranet der

Helaba haben, diese Einrichtungen ausschließlich im Rahmen ihrer Aufgaben nutzen. Er wird sie dar-

über unterrichten, dass eine Nutzung zu privaten Zwecken untersagt ist. Der AN wird der Helaba die

von diesen Personen unterzeichnete „Erklärung betreffend der Nutzung von Internet und Intranet“

vorlegen.


4 Vergütung

Die Leistungen des Support werden per Festpreis gemäß Preisblatt vergütet.

Anlage 5 Leistungsbeschreibung Support - lup-dataroom.com€¦ · o in den SAP ERP 6.0 Modulen SAP...

Documents

Transcript of Anlage 5 Leistungsbeschreibung Support - lup-dataroom.com€¦ · o in den SAP ERP 6.0 Modulen SAP...