Anlage 7
zum Rahmenvertrag zwischen der Helaba (nachfolgend „Auftraggeber“ genannt) und [Bezeichnung des Auftragnehmers] (nachfolgend „Auftragnehmer“ genannt) vom TT.MM.JJJJ
Governance
Helaba Landesbank Hessen-Thüringen Girozentrale Neue Mainzer Straße 52-58 60311 Frankfurt
Inhaltsverzeichnis
3 Organisatorische Schnittstellen 3
Gegenstand dieser Anlage
Gegenstand der Anlage ist die Kopplung und Beschreibung der zwischen beiden Parteien bestehenden Schnittstellen, Prozesse und Verfahren, basierend auf einer Governance-Struktur mit ihren strategischen, funktionalen und operationalen Ebenen. Abläufe an den Schnittstellen und die Ausübung der Rollen werden – soweit möglich – in diesem Dokument verbindlich vereinbart.
Sollten darüber hinaus Vereinbarungen in den Anlagen zum Rahmenvertrag von den hier vereinbarten Regelungen abweichen (z.B. Ansprechpartner oder technische Schnittstellen), so gelten die spezifischen Vereinbarungen der entsprechenden Anlagen.
Der Anhang 7.1 Kommunikationsmatrix ergänzt als eigenständiges Dokument die vorliegende Anlage. Dort sind die Ansprechpartner der in dieser Anlage benannten Rollen namentlich benannt sowie Besetzung und Frequenz der relevanten Meetings und Jour Fixe aufgezeigt.
Technische Schnittstellen
Grundsätzlich nutzen die Vertragspartner die folgenden beim Auftragnehmer eingesetzten technischen Schnittstellen/Tools zur Kommunikations- und Ergebnisübergabe:
- Anforderungstool für Änderungsaufträge (aktuell REMUS)
- Ticketsystem (aktuell ITSM)
- Defect Management (aktuell MicroFocus ALM).
Leistungsspezifische technische Schnittstellen sind ggf. in den jeweiligen Anlagen vereinbart.
Organisatorische Schnittstellen
Die nachfolgenden organisatorischen Schnittstellen benennen die Rollen beim Auftraggeber als auch beim Auftragnehmer sowie die für eine angemessene Steuerung grundsätzlichen Meetings und Jour Fixe.
Rollen
Die Rollenbeschreibungen und -bezeichnungen sind jeweils interne Beschreibungen und Bezeichnungen des Auftragnehmers und des Auftraggebers und können sich nachträglich ändern. Beide Parteien sind jeweils einseitig für Ihren Bereich berechtigt Änderungen vorzunehmen mit der Maßgabe, die andere Partei darauf hinzuweisen. Die Rollenbesetzungen sind im Anhang 7.1 Kommunikationsmatrix aufgeführt.
Rollen beim Auftraggeber
Service Desk
Der Service Desk des Auftraggebers stellt Anfragen an den Service Desk des Auftragnehmers und wird über deren Bearbeitungsergebnis vom Service Desk des Auftragnehmers informiert. Anfragen von Mitarbeitern des Auftraggebers bündelt und kanalisiert der Service Desk des Auftraggebers an den Service Desk des Auftragnehmers und stimmt im Bedarfsfall das Bearbeitungsergebnis mit den Anfragenden ab.
Der Service Desk des Auftraggebers ist Empfänger von Betriebsstatusinformationen des Auftragnehmers und verteilt diese Informationen an alle Informationsempfänger beim Auftraggeber.
Incident Manager
Der Incident Manager des Auftraggebers überwacht und koordiniert die Störungsbehebung an Systemen und Anwendungen des Auftraggebers. Der Incident Manager ist Mitarbeiter im Infrastruktur & Providermanagement des Auftraggebers. Er ist die erste Eskalationsinstanz für Incidents.
Problem Manager
Der Problem Manager des Auftraggebers überwacht und koordiniert die Problemerkennung an Systemen und Anwendungen des Aufraggebers. Der Problem Manager ist Mitarbeiter im Infrastruktur & Providermanagement des Auftraggebers. Er ist die erste Eskalationsinstanz für Probleme.
Change Manager
Der Change Manager stimmt im Namen des Auftraggebers Änderungen an der Systemumgebung, die in seinem Verantwortungsbereich fallen, ab. Dies dokumentiert er im Workflowsystem des Auftragsgebers. Er stimmt Change-Anträgen zu oder lehnt diese ab. Der Change Manager ist Mitarbeiter im Infrastruktur & Providermanagement des Auftraggebers.
IT Service Manager
Der IT Service Manager ist die zentrale Instanz des Auftraggebers für die operative Steuerung- und Koordination der IT-Services und des Service-Desk. Der IT-Service-Manager ist Mitarbeiter im Infrastruktur & Provider-Management des Auftraggebers.
IT Providermanagement
Das IT Providermanagement ist die Kontroll- und Steuerungsinstanz des Bereichs IT des Auftraggebers für die ausgelagerten Leistungen. Dort werden alle Leistungs-, Steuerungs- und Kommunikationsbeziehungen zum Auftragnehmer gebündelt. Das IT Providermanagement übernimmt die gemäß MaRisk vorgeschriebene Überwachungs- und Steuerungsfunktion sowie die sogenannte „First Line of Defense“ zur Einhaltung der internen und externen Vorgaben. Das IT Providermanagement ist Empfänger der Berichte des Auftragnehmers. Im Rahmen der Governance unterstützt das IT Providermanagement ein aktives Schnittstellenmanagement und übernimmt das Management von Eskalationsfällen. Das IT Providermanagement ist Teil der Abteilung Infrastruktur & Provider-Management des Auftraggebers.
Einkauf
Der Einkauf ist die zentrale Stelle zur Beschaffung aller (IT-)Bedarfe und externen Beratungsleistungen des Auftraggebers. Er ist verantwortlich für die Verhandlung von kommerziellen Themen, insbesondere im Zusammenhang mit Änderungen der Anlage 5 Preis- und Mengenvereinbarung zum Rahmenvertrag.
Business Continuity Manager
Der Business Continuity Manager (BCM) des Auftraggebers ist verantwortlich für die Notfallvorsorge zur Sicherung der Geschäftsfortführung bei bankweiten Notfällen und Krisensituationen. Er legt die Rahmenvorgaben für das Business Continuity Management des Auftraggebers fest und unterstützt bei dessen Umsetzung.
IT Service Continuity Manager
Der IT Service Continuity Manager des Auftraggebers unterstützt den Auftragnehmer bei der Erstellung der erforderlichen Notfallhandbücher und der dazu erforderlichen, gemeinsam auszuführenden Wiederanlaufpläne. Der IT-Service Continuity Manager des Auftraggebers stimmt mit dem Auftragnehmer die Planung und Durchführung der beauftragten Notfallübungen ab und begleitet diese. Er nimmt die Dokumentation der Übungsnachweise des Auftragnehmers ab und ist für die Erstellung der eigenen Nachweise seitens des Auftraggebers verantwortlich.
Der IT Service Continuity Manager des Auftraggebers erhält die in seinen Verantwortungsbereich fallenden Berichte und Reports des Auftragnehmers und bewertet diese.
Informationssicherheitsbeauftragter (CISO)
Der CISO ist für die Umsetzung des ISMS Regelprozesses gemäß MaRisk AT 7.2 i.V.m. der Normreihe ISO 27000 zuständig. Im Fokus steht dabei die operative Steuerung und Weiterentwicklung des Informationssicherheits-Managements. Er verantwortet die relevanten Sicherheitsvorgaben und organisiert den Aufbau, die Durchführung und die Kontrolle der Umsetzung der Informationssicherheit für den Auftraggeber inklusive der Auslandsniederlassungen und Repräsentanzen. Darüber hinaus ist er auch für die Sicherheitsvorgaben sowie deren Überwachung bei wesentlichen Auslagerungen zuständig. Er arbeitet hierbei eng mit dem Datenschutzbeauftragten zusammen, insbesondere bei der Sicherstellung der sogenannten „technischen und organisatorischen Anforderungen“.
Datenschutzbeauftragter
Der Datenschutzbeauftragte des Auftraggebers wirkt auf die Umsetzung der geltenden Regelungen des BDSG und der DSGVO im eigenen Unternehmen hin. Er berät die verantwortlichen Stellen des Auftraggebers bei Fragen zum Datenschutz und überwacht die Einhaltung der datenschutzrechtlichen Vorgaben. Er ist direkter Ansprechpartner des Datenschutzbeauftragten des Auftragnehmers und berät sich mit diesem in Fragen des Datenschutzes im Rahmen des erteilten Auftrags.
Leitung IT-Notfallstab
Die Leitung IT-Notfallstab des Auftraggebers verantwortet den Gesamtablauf einer Krise. Dies beinhaltet die Bewertung der Ausmaße des Incident und der Ausruf der Krise bei Bedarf. Sie ist zuständig für die Bildung des Krisenstabs des Auftraggebers, die Koordination der Krisensituation sowie nach Krisenende für die Übergabe der Krisensituation an das Problem Management für eine Nachuntersuchung. Die Leitung IT-Notfallstab leitet den Krisenstab und kommuniziert mit dem Auftragnehmer.
Abteilungsleitung Anwendungsentwicklung ZV & Verbund-/Fördergeschäft
Die Abteilungsleitung Anwendungsentwicklung ZV & Verbund-/Fördergeschäft des Auftraggebers ist Ansprechpartner Rolle zu ergänzen des Auftragnehmers für den Informationsaustausch in Eskalationsfällen der Stufe 3.
Bereichsleitung IT
Die Bereichsleitung Informationstechnologie (IT) des Auftraggebers ist die Steuerungs- und Kontrollinstanz für die gesamte IT des Auftraggebers. Er ist Ansprechpartner Rolle zu ergänzen des Auftragnehmers für den Informationsaustausch in Eskalationsfällen der Stufe 4.
Rollen der Gruppe Anwendungsentwicklung Fördergeschäft des Auftraggebers
Gruppenleitung
Die Gruppenleitung Anwendungsentwicklung Fördergeschäft des Auftraggebers ist Ansprechpartner für Rolle zu ergänzen des Auftragnehmers für den Informationsaustausch und in Eskalationsfällen der Stufe 2.
IT Business Relationship Manager
Der IT Business Relationship Manager (IT BRM) treibt und überwacht den IT Anforderungsmanagement-Prozess der Gruppe AE Fördergeschäft, unterstützt bei der Umsetzungsplanung und involviert die zur Umsetzung notwendigen Einheiten. Er ist Ansprechpartner des Auftraggebers in Eskalationsfällen der Stufe 1.
IT-Systemverantwortlicher
Der IT-Systemverantwortliche ist für ein oder mehrere DV-Anwendungssysteme verantwortlich und unterstützt bei der Spezifikation einer IT-Anforderung an sein jeweiliges Anwendungssystem. Er berücksichtigt Abhängigkeiten zu anderen IT-Anforderungen bei seinem Anwendungssystem und macht Vorschläge für die Realisierung einer IT-Anforderung. Der IT-Systemverantwortliche hat den Überblick über die „Gesamtheit“ eines Systems.
Release Manager
Der Release Managern verantwortet für ein oder mehrere DV-Anwendungen das störungsfreie und termingerechte Rollout von qualitätsgeprüften und freigegebenen Softwarekomponenten.
Rollen beim Auftragnehmer
Bitte geben Sie analog zu den unter 3.1.2 genannten Rollen beim Auftraggeber die relevanten Rollen beim Auftragnehmer an, die als Ansprechpartner oder sonstige Involvierte dienen.
Meetings und Jour Fixe
Zur grundlegenden Steuerung der Erbringung der Services, zum gegenseitigen Informationsaustausch sowie zur Unterstützung der Zusammenarbeit stimmen sich der Auftraggeber und der Auftragnehmer regelmäßig in Meetings und Jour Fixen (nachfolgend “Meetings“) ab.
Im Folgenden sind die Struktur, Aufgaben und Geschäftsordnung der Meetings, die die Vertragspartner im Sinne der Gremienarbeit aktuell vereinbart haben, aufgeführt.
Die Vertragsparteien erkennen an, dass sich während der Laufzeit des Rahmenvertrages Umstände ergeben können, die eine Anpassung der aufgeführten Meetings erforderlich machen, und kommen überein, solche Änderungen vorzunehmen.
Besetzung und Frequenz der Meetings sind im Anhang 7.1 Kommunikationsmatrix aufgezeigt.
Übersicht der Meeting-Struktur
| Meeting | Inhalte der Meetings |
| Strategie- und Kosten- Meeting | Management Meeting, Strategische Themen, Kostenentwicklung, Qualitätsentwicklung |
| Status-Meeting | Management Meeting für Eskalationen, Qualitätsabweichungen, vertragliche Changes, Weiterentwicklung der gesamtvertraglichen Beziehung, etc. |
| Servicemeeting | Betriebsvorfälle von Bedeutung (Incidents, Changes, Problems) und deren Eskalationen |
| Change-Meeting | Abstimmung der Changes inkl. Prüfung von geplanten Änderungen, Abschätzung der Betriebsrisiken, Darstellung von Rückfallszenarien und Freigabe der Änderung. Führung des Änderungskalenders und Management von Notfalländerungen |
| Auftragsmeeting | Angebote, Aufträge, Rechnungen, Bestellabwicklung/Beschaffung |
| Release -Jour Fixe | Abstimmung zu geplanten Lieferungen für Anforderungen (REMUS-Aufträge) zum aktuellen Release |
| Steuerungs-Jour Fixe | Abstimmung zu aktuellen Themen aus dem Tagesgeschäft, sowie konkrete Themen aus der Prozessteuerung und Überwachung. |
| Kundenmanagement-Jour Fixe | Themen der übergreifenden Prozesssteuerung und Überwachung, Rechnungslegung, Budget und Faktura sowie Eskalationen aus dem Release- und Steuerungs-Jour Fixe |
| AE Management-Jour Fixe | Themen der mittel- und langfristigen Zusammenarbeit, Eskalationen |
Beschreibung der Meetings
Strategie- und Kostenmeeting
Im Rahmen des Strategie- und Kostenmeetings wird über Strategie, Kosten und Qualität der Leistungserbringung des Auftragnehmers beraten und es werden Beschlüsse über die Weiterentwicklung der strategischen Zusammenarbeit, der IT-Strategie, der Kosten sowie der Qualitäten gefasst. Das IT Providermanagement des Auftraggebers leitet das Meeting und erstellt ein Ergebnisprotokoll. Im gegenseitigen Einvernehmen kann das Meeting auch ohne Zusammenkunft der Teilnehmenden im Umlaufverfahren durchgeführt werden.
Status-Meeting
Im Status Meeting werden die erreichten Qualitäten in der Leistungserbringung (Einhaltung der Service Level) und dem Service (Qualität der Betreuung), die mittelfristige Strategie, die Kostenplanung sowie aktuelle und zurückliegende Eskalationen besprochen.
Weiterhin werden Änderungen am Vertragskonstrukt sowie die vorliegenden vertraglichen Change Requests zum Rahmenvertrag, seinen Anlagen zwischen den Vertragspartnern besprochen und Entscheidungen vorbereitet. Das IT Providermanagement des Auftraggebers leitet das Meeting, erstellt ein Ergebnisprotokoll und pflegt ein Auftragsbuch.
Servicemeeting
Im Servicemeeting besprechen die Vertragspartner offene betriebliche Themen (wesentliche Störungen offene Ursachenanalysen, anstehende Changes, aktuelle Sicherheitsvorfälle u. ä.) sowie eventuelle Eskalationen zu diesen auf der operativen Ebene.
Ergänzend werden mittelfristig bevorstehende Releasewechsel und Sonderaktionen (Migrationen, Jahresabschlüsse, Inbetriebnahmen, u. ä.) sowie die laufende Kapazitätsplanung besprochen. Der IT Service Manager des Auftraggebers leitet das Meeting und erstellt ein Ergebnisprotokoll mit Historie und fortgeschriebener Liste der besprochenen, offenen Punkte.
Change Meeting
Allgemeines Change Meeting für (technische) Changes des Auftraggebers, an dem alle wesentlichen Partner sowie Vertreter der einzelnen Fachabteilungen teilnehmen.
Ergänzend werden mittelfristig bevorstehende Sonderaktionen (Migrationen, Jahresabschlüsse, Inbetriebnahmen, u. ä.) sowie die laufende Kapazitätsplanung besprochen. Das Meeting wird vom Change Management des Auftraggebers geleitet.
Auftragsmeeting
Im Auftragsmeeting besprechen die Vertragspartner die Bestellabwicklung/Beschaffung, offene vertriebliche Themen (neue oder offene Anfragen zur Abgabe eines Angebotes, offene Angebote oder Vertragsverhandlungen, laufende Aufträge, u.ä.) sowie eventuelle Eskalationen zu diesen.
Release-Jour Fixe
Im Rahmen des Release-Jour Fixe werden die geplanten Lieferungen für Anforderungen (REMUS-Aufträge) zum aktuellen Release abgestimmt. Das Jour Fixe wird vom Release Manager des Auftraggebers geleitet.
Steuerungs-Jour Fixe
Im Rahmen des Steuerungs-Jour Fixe erfolgt die Abstimmung zu Themen aus dem Tagesgeschäft sowie konkrete Themen aus der Prozesssteuerung und Überwachung. Das Jour Fixe wird vom IT-Systemverantwortlichen des Auftraggebers geleitet.
Kundenmanagement-Jour Fixe
Im Kundenmanagement-Jour Fixe werden übergreifende Themen aus der Prozesssteuerung und -Überwachung und notwendige Prozessanpassungen im Sinne eines kontinuierlichen Verbesserungsprozesses abgestimmt. Darüber hinaus werden Themen der Rechnungsstellung sowie zur Faktura und Budget geklärt. Bei Bedarf werden Eskalationen aus dem Steuerungs- und Release-Jour Fixe behandelt, um eine Folgeeskalation an die zentrale Steuerung nach Möglichkeit zu vermeiden. Das Jour Fixe wird vom IT BRM AE Fördergeschäft des Auftraggebers geleitet.
AE Management-Jour Fixe
Im AE Management-Jour Fixe werden Themen der mittel- bis langfristigen Zusammenarbeit sowie eventuellen Eskalationen abgestimmt. Das Jour Fixe wird von der Gruppenleitung AE Fördergeschäft des Auftraggebers geleitet
Geschäftsordnung
Einladung
Die Einladung umfasst eine Tagesordnung mit Bezeichnung der zu besprechenden Sachverhalte oder Themenstellungen.
Protokoll
Zu jedem Meeting wird ein Ergebnisprotokoll durch den festgelegten Verantwortlichen für die Protokollerstellung erstellt und spätestens am fünften auf das Meeting folgenden Arbeitstag per E-Mail an alle Meeting Teilnehmer versandt.
Korrekturen und Anmerkungen der Meeting Teilnehmer gehen binnen fünf weiteren Arbeitstagen zu. Rückmeldungen, die nach dem Termin eintreffen, werden im Protokoll nicht berücksichtigt. Gehen in der Rückmeldefrist keine Rückmeldungen ein, gilt das Protokoll als angenommen.
Spätestens zehn Arbeitstage nach dem Meeting soll das endgültige Protokoll allen Meeting Teilnehmern vorliegen.
Zu Meetings mit wöchentlichem oder 14-tägigem Turnus bzw. mit operativem Bezug werden Protokolle in geeigneter Form, wie beispielsweise „Offene Punkte-Listen“ geführt.
Verfahren
Beschwerdemanagement
Beschwerden sind Äußerungen der Unzufriedenheit des Auftraggebers mit den Leistungen des Auftragnehmers oder mit der Bearbeitung von Anfragen durch den Auftragnehmer. Das Beschwerdemanagement des Auftragnehmers nimmt Beschwerden des Auftraggebers entgegen und führt - soweit möglich - eine Lösung im Interesse des Auftraggebers herbei.
Stellungnahmen
Bei Verletzungen von Service Levels und/oder im Falle wesentlicher Störungen können Stellungnahmen beim Beschwerdemanagement durch das IT Providermanagement des Auftraggebers angefordert werden.
In der Stellungnahme beantwortet der Auftragnehmer detailliert in der Regel die folgenden Fragestellungen:
- Welcher Einzelauftrag ist betroffen?
- Referenz auf das/die Incident Ticket(s)?
- Was ist genau passiert?
- Was war nach aktuellem Kenntnisstand die Ursache der Störung?
- Was wurde im konkreten Fall unternommen, um die Störung zu beheben?
- Welche Maßnahmen werden getroffen, um die Störung zukünftig zu vermeiden?
Der Auftraggeber behält sich vor, je nach Auswirkung des Ausfalls zusätzliche Fragen aufzunehmen resp. Fragen zu streichen.
Kundenzufriedenheitsumfrage
Die Kundenzufriedenheitsumfrage dient der Sammlung von Rückmeldungen und Aussagen der Kunden über die Qualität aller Leistungen des Auftragnehmers. Anlassbezogen bzw. auf Anforderung des Auftraggebers erhalten ein oder mehrere vom Auftraggeber zu benennende Mitarbeiter bzw. Mitarbeitergruppen die Aufforderung, eine Bewertung hinsichtlich der Qualität der vom Auftragnehmer erbrachten Leistungen abzugeben. Das Feedback wird vom Auftragnehmer zur kontinuierlichen Verbesserung der Services genutzt und an den Auftraggeber berichtet.
Eskalationsverfahren
Eine Eskalation ist der konstruktive Versuch eines der beiden Vertragspartner oder beider Vertragspartner gemeinsam, bestehende Differenzen auszuräumen, welche z.B. im Tagesbetrieb oder bei der Bearbeitung von Anfragen und Aufträgen entstehen.
Für solche Situationen vereinbaren die Vertragspartner das im Folgenden beschriebene Eskalationsverfahren im Sinne des Rahmenvertrages. Das Verfahren kann auch bei der Steuerung des Auftragnehmers durch den Auftraggeber im Rahmen seiner Weisungskompetenz gemäß den gesetzlichen Anforderungen eingesetzt werden. Die Entscheidung obliegt dem Auftraggeber.
Eine Eskalation auf nächst höherer Ebene erfolgt in der Regel in Absprache, mindestens jedoch unter gegenseitiger Information. Adressat der Eskalation ist die nächsthöhere Ebene des eigenen Hauses und des Vertragspartners.
Eskalationsstufen
Die Rollen gehen aus der Rollendefinition in Ziffer 3.1 hervor.
Übersicht Eskalationsstufen und –beteiligte:
| Stufe | Rolle Auftraggeber | Rolle Auftragnehmer | Gremium |
| 0 a) | IT-Systemverantwortlicher | zu befüllen | Tagesgeschäft |
| 0 b) | Jeweiliger Prozess Manager | zu befüllen | Tagesgeschäft |
| 1 | IT BRM AE Fördergeschäft | zu befüllen | Kundenmanagement-Jour Fixe |
| 2 | * Gruppenleitung AE Fördergeschäft * IT Providermanagement | zu befüllen | * AE Management-Jour Fixe * Status-Meeting |
| 3 | * Abteilungsleitung AE ZV & Verbund-/Fördergeschäft * IT Providermanagement | zu befüllen | Strategie- und Kosten-Meeting |
| 4 | Bereichsleitung IT | zu befüllen | Mgmt. Zirkel |
Eskalationsstufe 0 – operativer Betrieb
Die Eskalationsstufe 0 entspricht dem normalen operativen Tagesbetrieb. Die Partner auf der Stufe 0 sind der IT-Systemverantwortliche bzw. der jeweilige Prozessverantwortliche des Auftraggebers und Rolle zu ergänzen des Auftragnehmers.
Bearbeitungsfehler, Fehleinschätzungen und Missverständnisse werden soweit möglich, auf der Ebene 0 geklärt und ausgeräumt. Kann nach einer angemessenen Zeit keine Klärung der Differenzen erreicht werden, eskalieren die Partner einzeln oder gemeinsam auf die Ebene 1.
Eskalationsstufen 1 und 2 – operativ-funktionale Eskalation
Die Eskalationsstufen 1 und 2 sind operative, nichthierarchische Eskalationsstufen, die die partnerschaftliche Lösung von auf Ebene 0 nicht lösbaren Differenzen unterstützen und beschleunigen sollen.
Eskalationsstufen 3 und 4 – hierarchische Eskalation
Auf der Eskalationsstufe 3 soll eine konstruktive Klärung bestehender Differenzen herbeigeführt werden, um die partnerschaftliche Zusammenarbeit zu sichern und eine Eskalation auf oberster Ebene abzuwenden.
Die höchste Eskalationsstufe 4 bilden der Bereichsleiter IT des Auftraggebers sowie Rolle zu ergänzen des Auftragnehmers.
Grundsätzliche Regelungen
Differenzen, die auf der Ebene 1 innerhalb von 5 Arbeitstagen nicht gelöst werden können, eskalieren die Partner in Absprache miteinander oder unter gegenseitiger Information auf die Ebene 2. Die Partner können einvernehmlich entscheiden, den Eskalationsweg ohne Einhaltung der 5-Tagesfrist zu Ebene 2 zu beschreiten, sofern eine Problemlösung auf den Fachebenen als nicht realistisch betrachtet wird.
Die Partner auf der Ebene 2 treten innerhalb von 5 Arbeitstagen nach Eingang der schriftlichen Eskalation aus der Eskalationsstufe 1 zusammen und versuchen, die Differenzen zu lösen. Können die Partner die Differenzen innerhalb einer weiteren Frist von 5 Arbeitstagen nicht lösen, ist die dritte Ebene einzuschalten.
Vertragliche Eskalationen
Die Eskalation über Stufe 1 hinaus erfolgt erst nach Ablauf von 2 Wochen, sofern bis dahin keine Einigung erzielt werden kann. Die Partner können von dieser Frist einvernehmlich nach unten abweichen, sofern eine Einigung nicht innerhalb von 2 Wochen zu erzielen sein wird.
Eskalation von Beschwerden
Ist eine abschließende Bearbeitung einer Beschwerde nicht innerhalb von 10 Arbeitstagen möglich, wird die Beschwerde zur Klärung an die Eskalationsstufe 3 weitergegeben.
Anhänge
Weiterer Vertragsbestandteil ist:
Anhang 7.1 Kommunikationsmatrix
Unterschriften
Dieses Dokument wurde von den nachstehenden Unterzeichnern genehmigt.
| [Bezeichnung des Auftragnehmers] | Unterschrift - Name |
| Datum | |
| [Bezeichnung des Auftragnehmers] | Unterschrift - Name |
| Datum | |
| Helaba Landesbank Hessen-Thüringen Girozentrale | Unterschrift - Name |
| Datum | |
| Helaba Landesbank Hessen-Thüringen Girozentrale | Unterschrift - Name |
| Datum |