BAIS Care
Für nicht geschäftskritische Systeme und planbare Änderungen.
- Servicezeit Mo–Fr 09:00–17:00 CET/CEST
- P1 Reaktion ≤ 4 Service-Stunden
- P2 Reaktion ≤ 1 Service-Tag
- P3/P4 planbar nach Aufwand
- Remote Support
- Monatliche Wartung nach Vereinbarung
Dieser SLA-Rahmen trennt Reaktionszeit, Wiederherstellungsziel, Wartung, Monitoring und Drittanbieterabhängigkeiten sauber voneinander. Verbindlich wird nur, was im jeweiligen Angebot oder Managed-Service-Vertrag ausdrücklich ausgewählt wurde.
Ein Projekt-Handover beinhaltet nicht automatisch laufenden Support oder Bereitschaft. Support, Monitoring, Wartung, Backup/Recovery, Verfügbarkeitsziele und Bereitschaft gelten nur bei ausdrücklich vereinbartem SLA bzw. Wartungsvertrag. Gesetzliche Mängelrechte bleiben unberührt.
Die konkrete Vergütung richtet sich nach Systemanzahl, Kritikalität, Monitoring-Tiefe, Drittanbieterabhängigkeiten und Bereitschaftsbedarf und wird im Angebot ausgewiesen.
Für nicht geschäftskritische Systeme und planbare Änderungen.
Für produktive Automations-, AI- und Integrationssysteme.
Für geschäftskritische Systeme nur nach technischer Vorprüfung.
Dieser SLA-Rahmen gilt nur, wenn er im Angebot, Managed-Service-, Wartungs- oder Supportvertrag ausdrücklich einbezogen wird. Projektbezogene Vereinbarungen, SOW, AVV/DPA und individuell vereinbarte Serviceparameter gehen diesem Rahmen vor.
Servicezeiten sind Zeiträume, in denen Supportanfragen bearbeitet und Reaktionszeiten gemessen werden. Gesetzliche Feiertage in Nordrhein-Westfalen sind ausgeschlossen, sofern nicht ausdrücklich anders vereinbart. Außerhalb des vereinbarten Servicefensters beginnt die Reaktionszeit mit dem nächsten Servicezeitraum.
Störungen werden über die im Vertrag benannten Kanäle gemeldet, z. B. Ticket/Project Portal, E-Mail oder vereinbarte Notfallnummer. Für P1/P2 ist eine Meldung über den vorgesehenen priorisierten Kanal erforderlich. Informelle Nachrichten an einzelne Mitarbeitende gelten nicht als SLA-auslösende Meldung.
Die Priorität richtet sich nach Geschäftsauswirkung und Ausweichmöglichkeit, nicht nach subjektiver Dringlichkeit.
| Priorität | Definition | Beispiele |
|---|---|---|
| P1 · Kritisch | Produktiver Kernservice vollständig ausgefallen oder erheblicher Security Incident; kein zumutbarer Workaround. | Produktionsworkflow steht vollständig; kritische unautorisierte Zugriffe; zentrale Integration blockiert. |
| P2 · Hoch | Wesentliche Funktion stark beeinträchtigt; Geschäftsbetrieb eingeschränkt; Workaround nur eingeschränkt möglich. | Teilworkflow fehlerhaft; wichtige API-Integration instabil; wiederkehrende Fehler mit hoher Auswirkung. |
| P3 · Mittel | Begrenzte Funktionsstörung ohne wesentliche Geschäftsunterbrechung; Workaround vorhanden. | Einzelne Fehlermeldung; nichtkritische Integration; Reporting- oder UI-Problem. |
| P4 · Niedrig | Frage, Optimierung, Change Request oder kosmetisches Thema. | Feature-Wunsch, Anpassung, Dokumentationsfrage, Performance-Tuning ohne Störung. |
Die Reaktionszeit bezeichnet die Zeit bis zur qualifizierten Aufnahme, Priorisierung und ersten Rückmeldung bzw. Einleitung einer Bearbeitung. Eine Reaktionszeit ist keine Garantie für vollständige Fehlerbehebung oder Wiederherstellung.
Resolution Targets, Wiederherstellungszeiten oder maximale Entstörzeiten gelten nur, wenn sie ausdrücklich projektbezogen vereinbart wurden.
Bei P1/P2 erfolgt eine technische Eskalation abhängig von Ursache und Scope. Wenn ein Drittanbieter, Hosting-Provider, AI-/Cloud-Anbieter oder Kundensystem betroffen ist, koordiniert BAIS im vereinbarten Umfang die Eskalation; die Bearbeitungszeit des Dritten liegt außerhalb der direkten Kontrolle von BAIS.
Proaktives Monitoring umfasst ausschließlich die im SOW benannten Komponenten, Checks, Schwellenwerte und Alarmkanäle. Nicht überwachte Komponenten gelten nicht als Bestandteil eines Monitoring-SLA.
Alarmierung ersetzt keine garantierte Fehlererkennung. False Positives, technische Blindspots und externe Plattformgrenzen werden im Monitoring-Konzept dokumentiert.
Planbare Wartungen, Patches und Changes werden grundsätzlich in abgestimmten Wartungsfenstern durchgeführt. Kritische Security-Maßnahmen können nach Risikoabwägung kurzfristig erforderlich sein. Geplante Wartungszeiten werden bei vereinbarten Verfügbarkeitsmessungen nur berücksichtigt, wenn dies im konkreten SLA so festgelegt ist.
Backup und Recovery sind nur geschuldet, wenn sie ausdrücklich Bestandteil des Managed Service sind. Backup-Ziel, Frequenz, Retention, Verschlüsselung, Restore-Test und Verantwortlichkeit werden im Runbook dokumentiert.
RPO beschreibt den maximal angestrebten Datenverlustzeitraum; RTO die angestrebte Wiederherstellungszeit. Verbindliche RPO/RTO-Werte werden ausschließlich projektspezifisch vereinbart und setzen eine technisch geeignete Architektur voraus.
Security Incidents werden nach Auswirkung priorisiert. Bei Verdacht auf Kompromittierung können Schutzmaßnahmen wie Token-Rotation, Deaktivierung von Integrationen, Zugangssperren oder Isolation erforderlich sein. Der Auftraggeber stellt hierfür die vereinbarten Ansprechpartner und Freigabewege bereit.
Soweit personenbezogene Daten betroffen sind, gelten zusätzlich der AVV/DPA und der dort geregelte Incident-/Meldeprozess.
Ausfälle oder Änderungen von Cloud-, Hosting-, AI-, API-, Telekommunikations- oder SaaS-Anbietern können die Leistung beeinflussen. BAIS übernimmt keine Verfügbarkeitsgarantie für Drittanbieter, soweit diese nicht ausdrücklich als durch BAIS geschuldete End-to-End-Leistung einbezogen wurde.
BAIS unterstützt im vereinbarten Umfang bei Diagnose, Eskalation und Workaround.
Der Auftraggeber stellt aktuelle Ansprechpartner, notwendige Zugänge, Logs, Freigaben und Informationen bereit. SLA-Zeiten können pausieren, solange eine zur Bearbeitung notwendige Mitwirkung des Auftraggebers oder eines von ihm verantworteten Dritten aussteht.
Support behebt Störungen im vereinbarten Scope. Neue Funktionen, Architekturänderungen, neue Datenquellen, zusätzliche Integrationen oder wesentliche Erweiterungen sind Change Requests und werden gesondert geplant und vergütet.
Bei Care Plus/Critical kann ein regelmäßiger Service Review vereinbart werden. Typische Inhalte sind Incidents nach Priorität, Reaktionszeiten, wiederkehrende Ursachen, offene Risiken, Changes, Monitoring-Befunde und empfohlene Maßnahmen.
Ein prozentuales Verfügbarkeitsziel gilt nur bei ausdrücklicher Vereinbarung. Dann müssen Messpunkt, Messintervall, Servicegrenzen, Wartungsfenster, ausgeschlossene Ursachen und Berechnungsmethode im SOW definiert sein. Ohne diese Definition besteht keine pauschale Uptime-Garantie.
SLA-Verpflichtungen gelten nicht für Störungen, die wesentlich verursacht werden durch nicht freigegebene Änderungen des Auftraggebers, nicht unterstützte Software-/Systemstände, fehlende Mitwirkung, höhere Gewalt, externe Angriffe außerhalb zumutbarer Schutzmaßnahmen oder nicht von BAIS kontrollierte Drittanbieter, soweit BAIS die Ursache nicht zu vertreten hat.
Service Credits, Vertragsstrafen oder automatische Vergütungsminderungen gelten nur, wenn sie ausdrücklich im konkreten SLA vereinbart wurden. Dieser allgemeine Rahmen begründet solche Ansprüche nicht automatisch.
Laufzeit, Mindestlaufzeit, Verlängerung und Kündigungsfrist ergeben sich aus dem jeweiligen Managed-Service- oder Wartungsvertrag. Das Recht zur Kündigung aus wichtigem Grund bleibt unberührt.
Bei Vertragsende werden vereinbarte Betriebsdokumente, Konfigurationen und offene Punkte im festgelegten Umfang übergeben. Datenrückgabe/-löschung richtet sich zusätzlich nach Hauptvertrag und AVV/DPA.
| Parameter | Vereinbarung |
|---|---|
| System / Service | |
| Supportmodell | ☐ Care ☐ Care Plus ☐ Critical / individuell |
| Servicezeit / Zeitzone | |
| Supportkanäle | |
| P1 Reaktionszeit | |
| P2 Reaktionszeit | |
| P3 Reaktionszeit | |
| P4 Behandlung | |
| Monitoring Scope | |
| Wartungsfenster | |
| RPO | Nur falls vereinbart: |
| RTO | Nur falls vereinbart: |
| Verfügbarkeitsziel | Nur falls vereinbart: |
| Service Credits | Nur falls vereinbart: |
| Rolle | Auftraggeber | BAIS |
|---|---|---|
| Operativer Kontakt | Projekt-/Servicekontakt gemäß Angebot | |
| Security / P1 | BAIS Eskalationskontakt gemäß Vertrag | |
| Management-Eskalation | BAIT Solution · Inhaber Bünyamin Atik |
Für jedes System werden die konkret betreuten Komponenten dokumentiert:
Vertragsstatus: Dieses veröffentlichte Dokument ist ein BAIS-SLA-/Wartungsvertragsmuster. Verbindlich sind nur die im jeweiligen Angebot oder Vertrag ausgewählten Serviceparameter. Insbesondere 24/7-Bereitschaft, Uptime-Ziele, RPO/RTO und Service Credits entstehen nicht allein durch Veröffentlichung dieser Seite.
Supportumfang, Eskalation, Monitoring und Recovery bereits vor dem Handover definieren.
Supportmodell besprechen