[Seite 1]
Anhang 19.2
Problem Management
zu Anlage 19 Servicemanagement
zum Rahmenvertrag vom TT.MM.JJJJ
zwischen
Landesbank Hessen-Thüringen Girozentrale
Neue Mainzer Straße 52 -58
60311 Frankfurt
- nachfolgend Helaba oder Auftraggeber genannt –
und
[Adresszeile 1: Vollständige Firmierung des Auftragnehmers]
[Adresszeile 2: Straße des Auftragnehmers]
[Adresszeile 3: PLZ und Stadt des Auftragnehmers]
- nachfolgend [Kürzel des Auftragnehmers] oder Auftragnehmer ge-
nannt –
– zusammen auch „Vertragspartner“, „Vertragsparteien“ oder „Parteien“
genannt –
Version 0.9
[Seite 2]
Anhang 19.2 – Problem Management
INHALTSVERZEICHNIS
1 Gegenstand .................................................................................................. 3
1.1 Abgrenzung des Dokuments .......................................................................... 3
1.2 Begriffsklärung ............................................................................................... 3
2 Leistungsbeschreibung .............................................................................. 3
2.1 Inhalte ............................................................................................................ 3
2.2 Reaktives Problem Management ................................................................... 4
2.3 Proaktives Problem Management .................................................................. 4
2.4 Priorisierung der Problem-Tickets .................................................................. 5
2.5 Leistungen und Verantwortlichkeiten ............................................................. 5
3 Prozesseinbindung und -schnittstelle ....................................................... 7
4 Reporting ...................................................................................................... 7
Seite 2 von 7
[Seite 3]
Anhang 19.2 – Problem Management
1 Gegenstand
Gegenstand dieses Anhangs zu Anlage 19 Servicemanagement des Rahmenvertrages ist die Beschreibung von Leistungen und wesentlichen Aufgaben des Auftragnehmers bei der Zusammenarbeit im Problem Management sowie die Definition erforderlicher Mitwirkungen durch den Auftraggeber.
1.1 Abgrenzung des Dokuments
Dieses Dokument beschreibt weder die internen Prozesse des Auftraggebers noch die des Auftragnehmers. Die Ausgestaltung der Prozesse des Auftraggebers verbleibt in der Hoheit des Auftraggebers ebenso wie die Ausgestaltung der Prozesse des Auftragnehmers in der Hoheit des Auftragnehmers verbleibt. Wechselseitige Ansprüche beschränken sich auf die Einhaltung bzw. Erfüllung der hier vereinbarten Abläufe, Schnittstellen und Rollen.
Die Regelungen dieses Anhangs stellen den grundlegenden fachlichen und prozessualen Rahmen für das Problem Management dar. Sie enthalten keine abschließende operative Aus- gestaltung der im Einzelfall anzuwendenden Prozesse, technischen Anforderungen oder be- trieblichen Abläufe.
Die für den jeweiligen Leistungsgegenstand maßgeblichen Detailregelungen – insbesondere operative Prozessschritte, Rollen, Schnittstellen, technische Spezifikationen und Dokumenta- tionspflichten – werden von den Vertragsparteien im Rahmen der Leistungsübernahme ge- meinsam konkretisiert und außerhalb dieses Anhangs in einem Prozesshandbuch (vgl. An- lage 19 Servicemanagement) festgelegt. Dieses Dokument präzisiert die vorliegenden Rah- menvorgaben und ist für beide Vertragsparteien verbindlich einzuhalten.
Für den vereinbarten Leistungsgegenstand nicht relevante Anforderungen dieses Anhangs finden keine Anwendung.
1.2 Begriffsklärung
Ein Problem wird definiert als die unbekannte Ursache, die einem oder mehreren (auch schwerwiegende) IKT-bezogenen Vorfällen (gemäß Art. 3 Ziff. 8 und 10 DORA) zugrunde liegt (nachfolgend „Incident“ genannt).
2 Leistungsbeschreibung
Ziel des Problem Managements ist es, die zugrunde liegenden Ursachen von Incidents zu identifizieren und zu beheben. Während beim Incident Management die schnelle Wiederher- stellung des Betriebs im Vordergrund steht, verfolgt das Problem Management einen syste- matischen und methodischen Ansatz, bei dem der Fokus auf der Analyse und nachhaltigen Beseitigung der eigentlichen Ursachen liegt.
Das Problem Management ist für die Steuerung eines Problems verantwortlich. Der Zustand- sübergang eines Problems führt durch die Phasen eines Problemlebenszyklus von der Erstel- lung bis zum Abschluss.
2.1 Inhalte
Die Inhalte des Problem Managements umfassen:
• Identifizieren, klassifizieren und priorisieren von Fehlern (Problems)
Seite 3 von 7
[Seite 4]
Anhang 19.2 – Problem Management
• Dokumentieren, analysieren und bewerten von Problems und deren nachhaltigen Be- hebung
• Durchführung von Ursachenanalysen und Ermittlung der zugrunde liegenden Ursache
• Ermittlung von möglichen Workarounds und Rückmeldung zum Incident Management
• Priorisierte, gesteuerte, wirkungsvolle und nachhaltige Behebung von Problems
• Maßnahmen zur ursächlichen Behebung werden über die zuständigen Prozesse wie z. B. Auftragsmanagement, Changemanagement abgewickelt
• Fortschrittsüberwachung während der Problembearbeitung
• Prüfung der Wirksamkeit der umgesetzten Problemlösungen (Post Implementation Re- view).
Beide Parteien haben einen internen Problem Management-Prozess. Sofern erforderlich, hat eine gemeinsame Problembearbeitung zu erfolgen. Auftraggeber und Auftragnehmer tau- schen in diesem Fall umfängliche Informationen über Inhalt (z.B. Eröffnung, Priorisierung, Mei- lensteine, Bearbeitungszustand, Root-Cause, usw.), Status und Lösung des Problems aus.
2.2 Reaktives Problem Management
Das reaktive Problem Management wird angestoßen, wenn Sachverhalte und Probleme er- kannt werden, die eine weitergehende Analyse und das Implementieren einer längerfristigen Lösung erfordern. Zum Beispiel kann das Problem Management einen Incident (bzw. eine Reihe zusammenhängender Incidents) aufgreifen, dessen zugrunde liegende Ursache im In- cident Management nicht behoben werden konnte. Damit soll verhindert werden, dass ähnli- che Incidents in Zukunft erneut auftreten.
Ein Problem-Ticket kann eröffnet werden, wenn:
• ein Incident mittels eines Workarounds gelöst wurde, die Ursache des Incidents jedoch unklar ist,
• gleichgeartete Incidents gehäuft auftreten,
• Incident-Wiederholungen vorliegen, die zu einer Anhäufung oder einem Trend führen,
• Infrastruktur- oder Service-Schwachpunkte aufgewiesen werden, die zu neuen Störun- gen führen können.
Ein Problem-Ticket muss eröffnet werden:
• nach einem IT-Notfall („schwerwiegende IKT-bezogene Vorfälle“ gemäß Art. 3 Ziff. 10 DORA),
• nach jeder wesentlichen Störung (z. B. Prioritäten 1 und 2).
2.3 Proaktives Problem Management
Beim proaktiven Problem Management handelt es sich um eine fortwährende Aktivität, mit der Fehlerquellen identifiziert werden sollen, sodass potenziell daraus resultierende Incidents erst gar nicht eintreten. Zum Beispiel analysiert das Problem Management bestimmte Daten wie
Seite 4 von 7
[Seite 5]
Anhang 19.2 – Problem Management
Incident Records und Logdateien, um Muster und Trends zu erkennen, die auf mögliche Prob- leme und Fehlerquellen hindeuten können.
Der Auftragnehmer erstellt proaktiv Analysen von Problem-Tickets.
Wenn ein Problem analysiert und diagnostiziert wurde, wird daraus beim Auftragnehmer intern ein „Known-Error-Record“ erstellt. Known-Error- und Workaround-Notizen werden im Prob- lem-Ticket hinterlegt und dem Auftraggeber unmittelbar nach Erfassung zur Verfügung ge- stellt.
Wenn möglich, stellt das Problem Management einen Workaround bereit – eine temporäre Lösung, mit der Incidents behoben werden können, solange im Problem Management noch eine dauerhafte Lösung entwickelt wird.
2.4 Priorisierung der Problem-Tickets
IT-Problem-Tickets werden nach Auswirkung und Dringlichkeit priorisiert, um die Bearbei- tungsreihenfolge zu bestimmen.
Es gelten die in Anhang 19.1 Incident Management beschriebenen Regelungen, insbeson- dere dieselbe Prioritätenmatrix.
Die Einschätzung von Dringlichkeit und Auswirkung nehmen Auftraggeber und Auftragnehmer jeweils intern vor. Bei Bedarf kann dazu eine Abstimmung stattfinden. Das Problem Manage- ment des Auftraggebers kann bei einer unterschiedlichen Einstufung einseitig die Priorität der Bearbeitung beim Auftragnehmer anheben lassen.
In Abhängigkeit von der Priorität sind Standard-Ziellösungszeiten für IT-Problem-Tickets im Rahmen der Leistungsübernahme von den Vertragspartnern zu definieren.
Sollte die Umsetzung der vollständigen Lösung aus fachlich vertretbarem Grund (nach Akzep- tanz durch den Auftraggeber) mehr Zeit in Anspruch nehmen und ein wirksamer Workaround sichergestellt sein, kann das IT-Problem-Ticket in den Status „Ausstehend“ gesetzt werden. Der Statusgrund ist im Aktivitäten-Log des IT-Problem-Tickets zu dokumentieren.
Bei Prioritätsänderungen wird die bereits verstrichene Lösungszeit als prozentualer Verbrauch der bisherigen Zielzeit ermittelt und im gleichen Verhältnis auf die Zielzeit der neuen Priorität angerechnet. Die verbleibende Restlaufzeit richtet sich nach der reduzierten Zielzeit.
2.5 Leistungen und Verantwortlichkeiten
Der Auftragnehmer verpflichtet sich, sämtliche Problem-Tickets fortlaufend, vollständig und nachvollziehbar zu dokumentieren. Alle relevanten Informationen, Statusänderungen, Analy- sen, Maßnahmen, Workarounds, Root-Cause-Analysen und Lösungen sind zeitnah im jewei- ligen Ticket zu erfassen und aktuell zu halten. Die Einträge müssen so gestaltet sein, dass sie jederzeit eine lückenlose Nachverfolgung des Bearbeitungsstandes und der getroffenen Maß- nahmen ermöglichen.
Im Folgenden sind die für das Problem Management notwendigen Leistungen, die durch die Auftragnehmer (AN) und den Auftraggeber (AG) zu erbringen sind, definiert. Dabei ist jeder Leistung eine Verantwortlichkeit gemäß RACI-Matrix aus Anlage 19 Servicemanagement zugeordnet.
Seite 5 von 7
[Seite 6]
Anhang 19.2 – Problem Management
| Leistungsbeschreibung | Ausprägung | AG | AN | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| IT-Problem erfassen | |||||||||||
| Identifizieren, Klassifizieren und Priorisieren von Feh- lern (Problems) durch den Auftragnehmer | I | R/A | |||||||||
| Identifizieren, Klassifizieren und Priorisieren von Feh- lern (Problems) durch den Auftraggeber | R/A | I | |||||||||
| Prüfen auf bereits bekannten Fehler (Known Error DB), Problem und ggf. Problem mit Known Error verknüpfen | C | R/A | |||||||||
| IT-Problem analysieren | |||||||||||
| Priorisierung des Problems prüfen | I/C | R/A | |||||||||
| Erfordernis für die Verbesserung eines Workarounds prüfen (einschließlich Notwendigkeit RfC für Work- around prüfen) | I | R/A | |||||||||
| Workaround entwickeln und umsetzen | I | R/A | |||||||||
| Root Cause Analyse durchführen | I | R/A | |||||||||
| Bearbeitung der IT-Problem-Tickets inklusive Rückfra- gen. Dokumentation im Ticket und (Zwischen-)Status- meldungen | I/C | R/A | |||||||||
| Annahme und Bearbeitung von Problems auch in Fäl- len, in denen unklar ist, in wessen Verantwortungsbe- reich die Ursache liegt. Dies umfasst die aktive Abstim- mung mit allen beteiligten Parteien, die Sicherstellung eines kontinuierlichen Informationsaustauschs sowie die Dokumentation aller relevanten Schritte und Ent- scheidungen im Problem-Ticket. Die Koordination endet erst, wenn die Zuständigkeit eindeutig geklärt und an den verantwortlichen Dienstleister übergeben wurde | C | R/A | |||||||||
| Gesamtkoordination und Steuerung der Problem-Ti- ckets, so bald mehr als ein externer Dienstleister des auslagernden Unternehmens beteiligt ist und unklar ist, welcher der externen Dienstleister für die Lösung ver- antwortlich ist | R/A | C | |||||||||
| IT-Problem beheben | |||||||||||
| Lösungsvorschlag entwickeln und prüfen | I/C | R/A | |||||||||
| Dokumentation der umzusetzenden Maßnahmen | I | R/A | |||||||||
| Erfassung einer Anforderung zur Initiierung eines RfC an das Change Management, falls die Lösung mittels eines Changes implementiert werden muss | gemäß Prozessschnittstelle | C | R/A | ||||||||
| Lösung umsetzen | I/C | R/A | |||||||||
| IT-Problem abschließen | |||||||||||
| Problem dokumentieren und abschließen | I | R/A |
Seite 6 von 7
[Seite 7]
Anhang 19.2 – Problem Management
| Leistungsbeschreibung | Ausprägung | AG | AN | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Known Error erstellen und mit Problem Ticket verknüp- fen | I | R/A | |||||||||
| Post-Implementation-Review (PIR) des Problem-Ti- ckets durchführen (Wirksamkeit der Lösung, Lessons Learned, vollständige Dokumentation Problem Ticket, Known Error) Nach Abschluss eines Problem-Tickets mit wesentli- cher Auswirkung (Priorität 1 und 2) ist ein Post Imple- mentation Review (PIR) durchzuführen und zu doku- mentieren. Der PIR umfasst die Überprüfung der Wirk- samkeit der umgesetzten Lösung, die Identifikation von Lessons Learned sowie die vollständige Dokumentation aller relevanten Erkenntnisse im Problem-Ticket. Die Ergebnisse des PIR sind dem Problem Management des Auftraggebers zur Verfügung zu stellen | I | R/A | |||||||||
| Proaktives IT Problem Management | |||||||||||
| Durchführung von definierten Analysen zur präventiven Erkennung von Problemen | I | R/A | |||||||||
| Eröffnung eines Problem Tickets und Zuführung zur Problemanalyse | I/C | R/A |
Tabelle 1: Problem Management RACI
3 Prozesseinbindung und -schnittstelle
Im Rahmen der Serviceerbringung arbeitet der Auftragnehmer eng mit dem Auftraggeber zu- sammen.
Die Einzelheiten der Zusammenarbeit werden im Zuge der Leistungsübernahme gemeinsam von beiden Parteien festgelegt, in konkrete Prozessschritte überführt und entsprechend doku- mentiert.
Die operative Zusammenarbeit erfolgt entweder über eine Toolschnittstelle oder durch ein On- boarding des Auftragnehmers in das System des Auftraggebers.
4 Reporting
Der Auftragnehmer stellt dem Auftraggeber die in Anlage 2 Berichtswesen definierten Ser- vice Level-Reports zum Problem Management in der vereinbarten Form bereit.
Seite 7 von 7