BEKOM MANAGEDSLAs für GeschäftsanwendungenMessbare Verfügbarkeit pro Anwendung
BEKOM vereinbart Service-Level-Agreements auf Anwendungsebene – für SAP, Microsoft 365 und individuelle Anwendungen mit messbaren Verfügbarkeitszielen.
SLAs auf Anwendungsebene
Geschäftsanwendungen wie SAP, Microsoft 365 oder individuelle Eigenentwicklungen tragen den operativen Betrieb eines Unternehmens. Wenn diese Anwendungen ausfallen oder langsamer werden, spüren Anwender die Auswirkungen unmittelbar – unabhängig davon, ob die darunterliegende Infrastruktur funktioniert. BEKOM vereinbart Service-Level-Agreements auf Anwendungsebene – als Bestandteil von BEKOM MANAGED Applications: messbare Verfügbarkeit, definierte Wartungsfenster und strukturiertes Reporting pro Anwendung. Während Infrastructure-SLAs den Betrieb von Servern, Speichersystemen und Netzwerkkomponenten abdecken, konzentrieren sich Application-SLAs auf das, was Anwender tatsächlich erleben – Transaktionsleistung, Funktionsverfügbarkeit und anwendungsspezifische Qualitätskennzahlen.
Application-SLAs sind geschäftskritisch, da sie die Verfügbarkeit von SAP-Transaktionen, Microsoft-365-Diensten und individuellen Anwendungen messbar machen, die direkt Geschäftsprozesse wie Auftragsverarbeitung oder Kundenbetreuung tragen. Messbare Anwendungsverfügbarkeit wird zur Betriebsvoraussetzung für standortübergreifende Arbeitsabläufe und auditfähige Qualitätsnachweise.
Warum Infrastructure-SLAs für Anwendungen nicht ausreichen
Infrastructure-SLAs messen, ob Server und Netzwerk erreichbar sind. Ein Application-SLA misst, ob SAP-Transaktionen innerhalb der vereinbarten Antwortzeiten laufen, ob Microsoft-365-Dienste aus Anwendersicht funktionieren und ob individuelle Anwendungen die erwartete Leistung erbringen. Die Unterscheidung ist relevant: Ein Server kann erreichbar sein, während die darauf laufende SAP-Anwendung durch ein fehlerhaftes Support Package blockiert ist. Infrastructure-SLAs decken die Basis-Infrastruktur ab – Server, Speicher, Netzwerk. Application-SLAs ergänzen diese um die Anwendungsebene: Transaktionsleistung, Funktionsverfügbarkeit und anwendungsspezifische Kennzahlen.
Was BEKOM unter Application-SLA versteht
BEKOM vereinbart Application-SLAs gemeinsam mit Ihrem Team. Ausgangspunkt sind standardisierte Service-Level-Bausteine für Leistungskennzahlen auf Anwendungsebene: Verfügbarkeitsziele pro Anwendung und Kritikalitätsstufe, Antwortzeiten für geschäftskritische Transaktionen, Wartungsfenster abgestimmt auf den jeweiligen Anwendungstyp, Eskalationspfade bei anwendungsspezifischen Störungen und anwendungsbezogenes Reporting. Im Assessment werden diese Bausteine auf Ihre konkreten Anforderungen angepasst. Das Ergebnis ist eine individuelle Vereinbarung im Service-Design-Dokument – differenziert nach Anwendungstyp, Geschäftsrelevanz und Nutzergruppe.
SLAs nach Anwendungstyp
Jede Anwendungskategorie hat eigene Betriebsanforderungen, Update-Zyklen und Leistungskennzahlen. Die Application-SLAs werden nicht pauschal festgelegt, sondern pro Anwendungstyp – abgestimmt auf die jeweiligen Besonderheiten.
SAP
Die SAP-spezifischen SLAs gelten auf Anwendungsebene – nicht auf Serverebene. Verfügbarkeitsziele unterscheiden sich nach Systemtyp: Produktivsysteme erhalten höhere Ziele als Entwicklungs- oder Testsysteme.
Vorteile
- Dialog-Antwortzeiten für SAP-Transaktionen (gemessen auf Anwendungsebene, nicht auf Serverebene)
- Batch-Laufzeiten und RFC-Verfügbarkeit pro System
- Transaktionsdurchsatz pro System und Mandant
- Verfügbarkeitsziele nach Kritikalitätsstufe (Produktion, Qualitätssicherung, Entwicklung)
- SAP Support Packages: Planung, Test in Vorab-Umgebung, Produktivsetzung, Validierung
- Kernel-Patches nach abgestimmten Wartungsfenstern
- Koordination mit SAP-Team oder SAP-Beratungspartner (kontrollierte Shutdowns)
Fazit
Bei SLA-Unterschreitungen analysiert BEKOM anwendungsspezifische Ursachen – etwa langsame Datenbankabfragen oder blockierte Transaktionen – und definiert gezielte Gegenmaßnahmen.
Microsoft 365
BEKOM vereinbart SLAs auf Microsoft-365-Tenant-Ebene – unabhängig von der darunterliegenden Infrastruktur. Von Microsoft verursachte Ausfälle werden separat dokumentiert.
Vorteile
- Tenant-Health-Score und Synchronisationsstatus
- Compliance-Policy-Durchsetzung und Regelkonformität
- Lizenzauslastung und Nutzungsanalyse
- Klassifizierung und Analyse anwendungsspezifischer Störungen
- Microsoft-verursachte und BEKOM-verantwortete Inzidenzen separat ausgewiesen und dokumentiert
- Change-Prozess für sicherheitsrelevante Tenant-Änderungen mit formaler Freigabe durch Ihr Team
- Strukturierte Status-Updates bei laufenden Inzidenzen mit nächstem geplantem Schritt
Fazit
SLA-Berichte unterscheiden zwischen BEKOM-verantworteten Inzidenzen und von Microsoft verursachten Service-Ausfällen.
Individuelle Anwendungen und Open Source
Für individuelle Anwendungen und Open Source gelten dieselben SLA-Prinzipien wie für Enterprise-Software – unabhängig von Technologie und Hersteller.
Vorteile
- Fehlerraten und Antwortzeiten pro Anwendungsinstanz (unabhängig von Programmiersprache und Framework)
- Deployment-Erfolgsraten und Release-Stabilität
- Anwendungsspezifische Kennzahlen laut Service-Design-Dokument (individuell pro Anwendung definiert)
- Orientierung an Release-Zyklen der jeweiligen Open-Source-Projekte
- Kompatibilitätsprüfung vor jedem Update durch BEKOM
- Einspielen nach Freigabe im vereinbarten Wartungsfenster
Fazit
Open-Source-Anwendungen (Java, .NET, Python, Nextcloud, Keycloak, Odoo) erhalten denselben Betriebsstandard und dieselbe SLA-Struktur wie kommerzielle Software.
| SAP | Microsoft 365 | Individuelle Anwendungen und Open Source | |
|---|---|---|---|
Fokus | Die SAP-spezifischen SLAs gelten auf Anwendungsebene – nicht auf Serverebene. Verfügbarkeitsziele unterscheiden sich nach Systemtyp: Produktivsysteme erhalten höhere Ziele als Entwicklungs- oder Testsysteme. | BEKOM vereinbart SLAs auf Microsoft-365-Tenant-Ebene – unabhängig von der darunterliegenden Infrastruktur. Von Microsoft verursachte Ausfälle werden separat dokumentiert. | Für individuelle Anwendungen und Open Source gelten dieselben SLA-Prinzipien wie für Enterprise-Software – unabhängig von Technologie und Hersteller. |
Vorteile |
|
|
|
Fazit | Bei SLA-Unterschreitungen analysiert BEKOM anwendungsspezifische Ursachen – etwa langsame Datenbankabfragen oder blockierte Transaktionen – und definiert gezielte Gegenmaßnahmen. | SLA-Berichte unterscheiden zwischen BEKOM-verantworteten Inzidenzen und von Microsoft verursachten Service-Ausfällen. | Open-Source-Anwendungen (Java, .NET, Python, Nextcloud, Keycloak, Odoo) erhalten denselben Betriebsstandard und dieselbe SLA-Struktur wie kommerzielle Software. |
Wartungsfenster und Change Management
Anwendungsupdates erfordern geplante Wartungsfenster – der Zeitrahmen und die Vorgehensweise unterscheiden sich je nach Anwendungstyp und Kritikalität. BEKOM dokumentiert alle Wartungsaktivitäten und deren Ergebnisse als Bestandteil der Application-SLA-Vereinbarung.
Anwendungsspezifische Wartungszyklen
SAP-Support-Packages folgen anderen Zyklen als Microsoft-365-Policy-Änderungen oder Deployments individueller Anwendungen.
Die Wartungsfenster werden pro Anwendung im Service-Design-Dokument festgelegt: Frequenz, Dauer, Kommunikationsvorlauf und Freigabeprozess.
Geschäftskritische Anwendungen erhalten Wartungsfenster während verkehrsarmer Zeiten mit kürzerer Dauer. Unterstützende Anwendungen werden in regulären Wartungsfenstern aktualisiert.
Für Microsoft-365-Updates, die Microsoft selbst ausrollt, definiert BEKOM einen Prozess zur Prüfung, Dokumentation und Kommunikation der Änderungen an Ihr Team.
Change-Prozess und Rückfallstrategie
Jede Änderung an einer betriebenen Anwendung durchläuft einen dokumentierten Change-Prozess: Planung, Genehmigung, Test, Durchführung und Validierung.
Für SAP-Transporte bedeutet dies einen definierten Freigabe- und Importprozess zwischen Ihrem Team und BEKOM. Für individuelle Anwendungen einen abgestimmten Prozess für Test, Freigabe und Produktivsetzung.
Jedes Release hat eine dokumentierte Rückfallstrategie – falls ein Update unerwartete Auswirkungen zeigt, kann BEKOM den vorherigen Zustand wiederherstellen.
Die Change-Dokumentation ist Bestandteil des Application-SLA-Reportings und wird im Service-Review als Grundlage für die Bewertung der Change-Erfolgsrate herangezogen.
Eskalationspfade bei Anwendungsstörungen
Bei anwendungsspezifischen Störungen greift ein dreistufiger Eskalationsprozess. Stufe 1: Der Application-Spezialist nimmt die Inzidenz auf, klassifiziert nach Geschäftsauswirkung und beginnt mit der Analyse.
Stufe 2: Der Service-Manager wird einbezogen, wenn die Lösung sich verzögert oder die Auswirkung eskaliert. Stufe 3: Der Delivery-Lead koordiniert bei übergreifenden Inzidenzen, die mehrere Anwendungen oder Teams betreffen.
Ihr Team erhält bei jeder Eskalationsstufe ein strukturiertes Update mit aktuellem Stand, Ursachenanalyse und geplantem nächstem Schritt.
Bei Inzidenzen, die sowohl Infrastruktur als auch Anwendung betreffen, koordiniert BEKOM die Zusammenarbeit zwischen Infrastruktur- und Application-Team.
Anwendungsbezogenes Reporting
Welche Kennzahlen für eine Anwendung relevant sind, hängt von deren Rolle im Geschäftsprozess ab. BEKOM stimmt das Reporting individuell pro Anwendung mit Ihrem Team ab – von der Auswahl der Kennzahlen über das Berichtsformat bis zur Frequenz. Ziel ist ein Reporting, das Entscheidungen unterstützt, statt Daten zu liefern, die niemand auswertet.
Kennzahlen pro Anwendung
Mögliche Reporting-Inhalte reichen von Verfügbarkeitsberichten über Antwortzeit-Analysen bis hin zu Change-Dokumentation und Inzidenz-Trends. Welche Kennzahlen im Einzelfall den größten Mehrwert bieten, hängt vom Anwendungstyp und von den Anforderungen Ihrer Organisation ab.
SAP-Umgebungen profitieren typischerweise von Transaktions- und Batch-Auswertungen, Microsoft-365-Tenants von Health-Score- und Compliance-Berichten. Für individuelle Anwendungen und Open-Source-Software definiert das Service-Design-Dokument, welche anwendungsspezifischen Metriken erfasst und berichtet werden – etwa Fehlerraten, Deployment-Erfolgsraten oder nutzungsbezogene Kennzahlen.
Berichtsfrequenz und Detailtiefe werden gemeinsam vereinbart und können pro Anwendung unterschiedlich ausfallen. Geschäftskritische Systeme erhalten bei Bedarf engmaschigere Berichte als unterstützende Anwendungen.
Service-Reviews und Optimierung
Auf Basis der vereinbarten Kennzahlen können regelmäßige Service-Reviews stattfinden, in denen BEKOM Optimierungspotenziale identifiziert und SLA-Anpassungen vorschlägt. Ob und in welchem Rhythmus Reviews durchgeführt werden, bestimmen Sie gemeinsam mit BEKOM.
Mögliche Review-Inhalte umfassen die Analyse der Application-SLA-Einhaltung, die Bewertung von Inzidenz-Trends pro Anwendung und die Identifikation wiederkehrender Störungsmuster. Wiederkehrende Probleme werden im Problem-Management-Prozess erfasst und dauerhaft behoben. Aus den Ergebnissen leitet BEKOM konkrete Maßnahmenvorschläge ab – etwa die Anpassung von Monitoring-Schwellenwerten, die Optimierung von Wartungsfenstern oder Empfehlungen zur Konsolidierung von Anwendungsinstanzen.
Änderungen an SLA-Zielen oder Messmethodik werden formal dokumentiert und im Service-Design versioniert, sodass beide Seiten den aktuellen und historischen Stand nachvollziehen können.
Kostentreiber von Application-SLAs im Eigenbetrieb
Application-SLAs im Eigenbetrieb verursachen variable Aufwände durch unterschiedliche Kostentreiber: Monitoring-Tools für anwendungsspezifische Kennzahlen, spezialisierte Administratoren für SAP, Microsoft 365 oder individuelle Anwendungen, sowie die Dokumentation und Nachverfolgung von Verfügbarkeitsmessungen pro Anwendung. Assessment-Aufwände entstehen bei der Definition messbarer Service-Level und der Integration verschiedener Überwachungssysteme. BEKOM strukturiert diese Kostenstruktur über eine planbare Monatspauschale, die Application-Monitoring, Reporting und SLA-Management abdeckt. Planbare Betriebskosten ersetzen die variablen Aufwände für Tools, Personalkapazitäten und die kontinuierliche Weiterentwicklung anwendungsspezifischer Service-Level-Definitionen.
Verwandte Themen: Application-SLAs verzahnen sich mit Managed Microsoft und Anwendungen-Betriebsmodelle; BEKOM legt die Open-Source-Variante in Open-Pro-Anwendungen-Betriebsmodelle dar; für strukturierte Microsoft-Ablösungen siehe das Szenario Microsoft-365-Exit.
Häufige Fragen zu Application-SLAs
Was ist der Unterschied zwischen Infrastructure-SLA und Application-SLA?
Ein Infrastructure-SLA misst, ob Server und Netzwerk erreichbar sind – also die Betriebsgrundlage. Ein Application-SLA misst, ob die darauf laufende Anwendung aus Sicht der Anwender funktioniert: Transaktionsleistung, Antwortzeiten, Verfügbarkeit auf Funktionsebene. Beide Ebenen werden separat definiert, da ein funktionierender Server allein keine funktionierende SAP-Transaktion bedeutet. Application-SLAs ergänzen die Infrastruktur-Ebene um anwendungsspezifische Leistungsziele.
Welche Verfügbarkeitsziele sind für SAP-Systeme üblich?
Verfügbarkeitsziele werden pro System und Kritikalitätsstufe vereinbart – es gibt keinen Pauschalwert. BEKOM ermittelt im Application-Assessment die geschäftliche Auswirkung eines Ausfalls und leitet daraus individuelle Ziele ab. Geschäftskritische SAP-Produktivsysteme erhalten typischerweise höhere Verfügbarkeitsziele als Entwicklungs- oder Testsysteme. Die konkreten Werte, Messmethodik und Berechnungsgrundlage werden im Service-Design-Dokument dokumentiert und regelmäßig überprüft.
Was passiert bei einer SLA-Unterschreitung?
Bei Unterschreitung vereinbarter Application-SLAs greift ein definierter Prozess: BEKOM analysiert die anwendungsspezifische Ursache, implementiert Gegenmaßnahmen und dokumentiert die Ergebnisse im Service-Report. Service-Credits gemäß vertraglicher Regelung werden angewendet, sofern im Service-Design-Dokument vereinbart. Der Fokus liegt auf der dauerhaften Vermeidung künftiger Abweichungen, nicht ausschließlich auf finanzieller Kompensation. Im nächsten Service-Review werden Ursache, getroffene Maßnahmen und deren Wirksamkeit gemeinsam besprochen und bewertet.
Können SLAs pro Anwendung individuell vereinbart werden?
Die Application-SLAs werden pro Anwendung und Kritikalitätsstufe festgelegt – keine Pauschal-SLAs für das gesamte Portfolio. SAP-Produktivsysteme erhalten andere Verfügbarkeitsziele als Microsoft-365-Nebenanwendungen oder interne Tools. Jede Anwendung wird im Application-Assessment einzeln bewertet: Geschäftsrelevanz, Nutzeranzahl und Ausfallauswirkung. Das Ergebnis ist ein differenziertes SLA-Profil pro Anwendung im Service-Design-Dokument – keine pauschale Zusage, sondern eine an der Geschäftsrelevanz orientierte Vereinbarung.
Wie laufen Wartungsfenster für verschiedene Anwendungstypen ab?
Wartungsfenster werden pro Anwendung im Service-Design vereinbart. SAP-Support-Packages erfordern koordinierte Shutdowns mit dem SAP-Team. Microsoft-365-Updates werden von Microsoft ausgerollt; BEKOM dokumentiert und prüft die Änderungen. Individuelle Anwendungen folgen den Release-Zyklen des Entwicklungsteams. BEKOM stimmt Frequenz, Dauer und Kommunikationsvorlauf je Anwendungstyp mit Ihrem Team ab und dokumentiert den Prozess verbindlich.
Welche Eskalationsstufen gibt es bei Anwendungsstörungen?
BEKOM nutzt einen dreistufigen Eskalationsprozess bei Anwendungsstörungen. Stufe 1: Application-Spezialist klassifiziert und analysiert den Inzidenz nach Geschäftsauswirkung. Stufe 2: Service-Manager wird bei verzögerter Lösung oder steigender Geschäftsauswirkung einbezogen. Stufe 3: Delivery-Lead koordiniert bei übergreifenden Inzidenzen. Bei jedem Stufenwechsel erhalten Sie ein strukturiertes Update mit aktuellem Stand, Analyse und geplantem nächstem Schritt.
Wie werden Application-SLAs gemessen und nachgewiesen?
BEKOM misst Application-SLAs über die zentrale Monitoring-Plattform auf Anwendungsebene: Verfügbarkeit, Antwortzeiten, Transaktionsdurchsatz und Fehlerraten pro Anwendung. Geplante Wartungsfenster werden bei der Berechnung berücksichtigt und separat ausgewiesen. Die Ergebnisse dokumentiert BEKOM in regelmäßigen Application-SLA-Berichten. Zusätzlich haben Sie Zugang zur Monitoring-Oberfläche für den aktuellen Überblick über alle betriebenen Anwendungen und deren aktuelle Leistungskennzahlen.
Wie wird die Performance bei wachsendem Anwendungsaufkommen optimiert?
BEKOM überwacht die Anwendungs-Performance kontinuierlich anhand definierter Kennzahlen: Antwortzeiten, Transaktionsraten und Ressourcenauslastung. Bei erkennbaren Trends – etwa steigende Antwortzeiten durch wachsende Nutzerzahlen – leitet BEKOM proaktiv Optimierungsmaßnahmen ein: Ressourcenanpassung, Konfigurationsoptimierung oder Infrastruktur-Skalierung. Die Maßnahmen werden im Change-Management-Prozess dokumentiert und mit der IT-Leitung abgestimmt.
Welche Vertragslaufzeiten gelten für Application-SLA-Services?
BEKOM vereinbart Application-SLA-Services als Bestandteil der BEKOM MANAGED Applications mit üblichen Mindestlaufzeiten von 12 oder 24 Monaten. Die Vertragslaufzeit orientiert sich am Umfang der zu überwachenden Anwendungen und der Komplexität der SLA-Definitionen. Kürzere Laufzeiten sind bei größeren Anwendungslandschaften oder strategischen Projekten möglich. Der Vertrag umfasst SLA-Definition, Monitoring-Setup, regelmäßiges Reporting und die kontinuierliche Anpassung der Service-Level an veränderte Geschäftsanforderungen.
Können wir von Application-SLA-Services zurück zum Eigenbetrieb wechseln?
Ein Wechsel zurück zum Eigenbetrieb ist grundsätzlich möglich. BEKOM dokumentiert alle SLA-Definitionen, Monitoring-Konfigurationen und Reporting-Strukturen in übertragbaren Formaten. Die entwickelten Service-Level-Agreements, Messmethoden und Qualitätskennzahlen können in interne Prozesse überführt werden. Der Übergang erfordert jedoch den Aufbau entsprechender interner Kapazitäten für Application-Monitoring, SLA-Reporting und die kontinuierliche Überwachung anwendungsspezifischer Verfügbarkeitskennzahlen. BEKOM unterstützt diesen Übergang durch strukturierte Wissensübertragung.
Nächster Schritt: SLA-Konzept besprechen
Der Einstieg beginnt mit der Analyse Ihrer Anwendungslandschaft und der Anforderungen an Verfügbarkeit, Wartung und Reporting pro Anwendung.
Ein Application-SLA-Assessment liefert eine strukturierte Bestandsaufnahme der aktuellen Anwendungslandschaft und identifiziert messbare Qualitätskennzahlen für jede Geschäftsanwendung. BEKOM entwickelt konkrete Service-Design-Empfehlungen für anwendungsspezifische SLAs, definiert Monitoring-Architektur und Reporting-Strukturen. Das Assessment schafft Klarheit über den Betriebsumfang für Application-SLAs und liefert einen detaillierten Überblick über Verfügbarkeitsmessungen, Wartungsfenster-Definitionen und Eskalationsprozesse pro Anwendung.
Anwendungslandschaft besprechen
Kontaktieren Sie BEKOM für ein Gespräch zu Ihrer Anwendungslandschaft. Gemeinsam erfasst BEKOM die betriebenen Anwendungen – SAP, Microsoft 365, individuelle Anwendungen, Open Source –, deren Kritikalität und Ihre Anforderungen an Verfügbarkeit und Wartung.
Application-SLA-Konzept erstellen
Auf Basis der Analyse erstellt BEKOM ein dokumentiertes Application-SLA-Konzept: Verfügbarkeitsziele pro Anwendung, Wartungsfenster nach Anwendungstyp, Eskalationsstufen und Reporting-Frequenz – abgestimmt auf die Geschäftsrelevanz jeder Anwendung in Ihrem Portfolio.
Vereinbarung finalisieren
Nach Ihrer Freigabe entsteht die formale Application-SLA-Vereinbarung als Teil des Service-Design-Dokuments: verbindliche Leistungsziele auf Anwendungsebene, definierte Messmethodik und anwendungsbezogenes Reporting – als Ergänzung zur bestehenden Infrastruktur-Vereinbarung oder als eigenständige SLA.