Übungsaufgaben zu Ticketsystem und IT-Service

Je Vorteil bzw. Nachteil 3 Punkte (1 Punkt Merkmal, 2 Punkte Erläuterung von Wirkung und Nutzen mit Bezug zu Let’s Meet). Drei Vorteile aus z. B.:

• Nachvollziehbarkeit: Jede Meldung erhält eine Ticketnummer und einen Verlauf. Anders als im Sammelpostfach geht keine Meldung mehr verloren oder bleibt unbemerkt liegen; auch wenn Birgit Sommer im Urlaub ist, sieht Amir Rahimi, was bereits passiert ist.

• Transparenz über den Status: Support, Entwicklung und Nutzende sehen den Bearbeitungsstand. Doppelarbeit (beide antworten auf dieselbe Mail) und Nachfragen „Was ist mit meiner Meldung?“ entfallen.

• Automatisierung: Eingangsbestätigung, Zuweisung nach Kategorie und Benachrichtigung bei Statuswechsel laufen automatisch. Die App übermittelt App-Version und Gerät gleich mit, das spart dem kleinen Team Zeit und Rückfragen.

• Priorisierung: Tickets werden nach Auswirkung und Dringlichkeit geordnet. Sicherheitsrelevante Meldungen (z. B. Fake-Profile) oder Ausfälle werden zuerst bearbeitet statt in der Reihenfolge des Eingangs.

• Auswertungen: Ticketaufkommen je Kategorie, Reaktions- und Lösungszeiten lassen sich auswerten. Clara Neumann erkennt, ob das Team ausreicht, und die Entwicklung sieht, welche Funktionen die meisten Probleme machen.

• Wissensdatenbank: Lösungen werden gespeichert und wiederverwendet; häufige Fragen können als Hilfeartikel in der App erscheinen (Self-Service), das entlastet das Team.

• Einhaltung von Zusagen (SLA): Das System misst Fristen und warnt rechtzeitig, z. B. bei Datenauskünften mit gesetzlicher Frist.

Ein Nachteil aus z. B.:

• Kosten: Abo-Gebühren oder Lizenz, Einrichtung, Anpassung und Anbindung an die App kosten Geld und Arbeitszeit des Entwicklungsteams – für ein Start-up mit 24 Beschäftigten ein spürbarer Posten.

• Überwachungsverdacht: Das System protokolliert, wer wie lange an welchem Ticket gearbeitet hat. Birgit Sommer und Amir Rahimi könnten das als Leistungskontrolle empfinden; das gefährdet die Akzeptanz (bei einem Betriebsrat: Mitbestimmung nach § 87 Abs. 1 Nr. 6 BetrVG).

• Datenschutz: Tickets enthalten personenbezogene Daten, ggf. Screenshots von Chats; Zugriffsrechte, Löschfristen und ggf. ein Auftragsverarbeitungsvertrag sind nötig.

• Schulung und Umstellung: Das Team muss Kategorien, Regeln und Bedienung lernen; Nutzende, die lieber anrufen, empfinden ein Formular als Hürde.

Bewertungshinweis: Reine Stichworte („Übersicht“) höchstens 1 Punkt. Zwei Vorteile mit gleichem Kern (z. B. „Zeitersparnis“ und „schnellere Bearbeitung“) zählen nur einmal.

Sechs Angaben (2 Punkte, je drei richtige Angaben 1 Punkt), z. B.:

• Ticketnummer (vergibt das Ticketsystem)

• meldende Person bzw. Benutzerkonto (benutzer_id) und Kontakt (E-Mail) – automatisch, weil die Person angemeldet ist

• Zeitpunkt des Eingangs – automatisch

• App-Version, Betriebssystem und Gerätetyp – automatisch

• Kanal (App, E-Mail, Telefon) – automatisch

• Kategorie (z. B. Anmeldung, Aktivitäten, Chat, Konto, Meldung über eine Person)

• Beschreibung, ggf. Screenshot

• Typ (Incident, Service Request), Priorität, Status, zuständige Person

1 Punkt für drei sinnvoll gekennzeichnete automatische Angaben. Nicht automatisch erfassbar sind Beschreibung und (in der Regel) Kategorie, Priorität setzt der Support.

Reihenfolge (2 Punkte): neu → zugewiesen → in Bearbeitung → (wartend → in Bearbeitung) → gelöst → geschlossen. wartend darf auch zwischen in Bearbeitung und gelöst stehen, wenn deutlich wird, dass es danach zurück in die Bearbeitung geht. Bei gelöst kann das Ticket wiedereröffnet werden.

wartend (1 Punkt): Das Ticket wechselt dorthin, wenn die Bearbeitung von einer Zuarbeit von außen abhängt, z. B. wenn der Support eine Rückfrage an die meldende Person stellt („Welche App-Version nutzt Du?“) oder auf einen externen Dienstleister wartet.

Frist angehalten (1 Punkt): Der Support kann die Wartezeit nicht beeinflussen. Würde die Uhr weiterlaufen, würde eine späte Antwort der Nutzenden als Verstoß gegen die vereinbarte Lösungszeit gezählt.

Ein Incident ist eine ungeplante Unterbrechung oder Beeinträchtigung eines Services (etwas funktioniert nicht wie vorgesehen); Ziel ist die schnelle Wiederherstellung. Ein Service Request ist eine Anfrage nach einer vereinbarten Standardleistung (z. B. Datenexport, Kontoänderung); nichts ist gestört, die Anfrage wird nach einem festgelegten Ablauf erfüllt. 1 Punkt je zutreffender Beschreibung.

Bewertung: je Meldung 1 Punkt für Einordnung mit Begründung, 1 Punkt für eine zur Begründung passende Priorität. Andere Einschätzungen von Auswirkung oder Dringlichkeit sind richtig, wenn sie begründet sind und die Matrix korrekt angewendet wird. Meldung 4 als „Problem“ statt Incident einzuordnen, ist nur mit dem Hinweis richtig, dass die einzelnen Meldungen Incidents sind.

Je Ebene 2 Punkte (1 Punkt Zuordnung, 1 Punkt Aufgaben). Bei Third Level sind auch andere externe Spezialist*innen richtig (z. B. Anbieter eingesetzter Bibliotheken oder des Kartendienstes).

Funktionale Eskalation (2 Punkte): Das Ticket wird an eine höhere Support-Ebene mit mehr Fachwissen oder Berechtigungen übergeben – hier von Amir Rahimi (First Level) an die Entwicklung (Second Level), weil nur sie den Fehler im Filter analysieren und beheben kann.

Hierarchische Eskalation (2 Punkte): Vorgesetzte bzw. die Leitung werden eingeschaltet, weil eine Entscheidung oder Befugnis nötig ist, die die Bearbeitenden nicht haben – hier informiert Birgit Sommer die Geschäftsführerin, die über das Abschalten einer Funktion und die Information aller Nutzenden entscheidet.

Je 2 Punkte, z. B.:

• Nutzende: Sie haben eine einzige, bekannte Anlaufstelle für alle Anliegen und müssen nicht herausfinden, wer zuständig ist; sie erhalten verlässlich eine Eingangsbestätigung und Rückmeldungen aus einer Hand.

• Entwicklungsteam: Es erhält nur vorsortierte, vollständig erfasste Tickets, die wirklich einen Eingriff der Entwicklung erfordern, und wird nicht durch Anrufe und Standardfragen bei der Arbeit (z. B. im Sprint) unterbrochen.

Ebenfalls richtig: Der Support behält den Überblick über alle Probleme und erkennt Häufungen.

Übrig bleibt B (Change Enablement: Änderungen planen, genehmigen und kontrolliert umsetzen). Je richtiger Zuordnung 1 Punkt.

Grundursachenanalyse (2 Punkte): Statt jeden Absturz einzeln zu behandeln, werden die gleichartigen Tickets zu einem Problem zusammengefasst und systematisch untersucht, warum die App abstürzt (z. B. Absturzprotokolle vergleichen, Gemeinsamkeiten wie App-Version oder Android-Version suchen, mit 5-Why fragen, was sich mit dem Update geändert hat). Aus der gefundenen Ursache wird eine dauerhafte Korrektur abgeleitet (z. B. Fehlerbehebung in Version 3.4.2), damit der Fehler nicht wieder auftritt.

Wissensdatenbank (2 Punkte): Der bekannte Fehler wird mit Umgehungslösung als Artikel erfasst („Absturz beim Öffnen des Chats in Android-Version …: bis zum Update die Web-App nutzen“). Der First Level kann weitere Meldungen sofort beantworten und mit dem Problem verknüpfen, ohne die Entwicklung erneut zu fragen; nach der Korrektur wird der Artikel aktualisiert. Ein Hinweis in der App kann neue Tickets ganz vermeiden.

Ein Service Level Agreement (SLA) ist Teil des Servicevertrags zwischen einem Dienstleister (hier Lippe Software AG) und dem Kunden (Let’s Meet GmbH) (1 Punkt). Darin wird messbar festgelegt, in welchem Umfang und in welcher Qualität (Servicelevel) die Leistung erbracht wird, z. B. Verfügbarkeit von 99,5 %, Servicezeiten, Reaktions- und Lösungszeiten (1 Punkt). Außerdem regelt es die Folgen bei Nichteinhaltung, hier eine Gutschrift von 5 % der Monatsgebühr (1 Punkt).

Zwei aus (je 1 Punkt Nennung mit Wert, 1 Punkt Beschreibung):

• Servicezeit (Supportzeit): Zeitraum, in dem der Anbieter Supportanfragen entgegennimmt und bearbeitet – Montag bis Freitag 8 bis 18 Uhr, außer an Feiertagen in NRW.

• Reaktionszeit: Zeit vom Eingang des Tickets bis zum Beginn der Bearbeitung durch qualifiziertes Personal – bei Priorität 1 eine Stunde, sonst acht Servicestunden (eine automatische Eingangsbestätigung zählt nicht).

• Lösungszeit (Wiederherstellungszeit): Zeit, bis der Service wieder vollständig nutzbar ist – bei Priorität 1 vier Servicestunden.

Typischer Fehler: Reaktionszeit und Lösungszeit gleichsetzen.

Geg.: Verfügbarkeit V = 99{,}9\,\% = 0{,}999, Oktober: T = 31\,\mathrm{d}, 24/7-Betrieb

Ges.: zulässige Ausfallzeit t_A im Oktober in Minuten

V = \frac{T - t_A}{T} \quad | \cdot T

t_A = (1 - V) \cdot T

t_A = (1 - 0{,}999) \cdot 31\,\mathrm{d} \cdot 24\,\frac{\mathrm{h}}{\mathrm{d}} \cdot 60\,\frac{\mathrm{min}}{\mathrm{h}} = 0{,}001 \cdot 44.640\,\mathrm{min} = \underline{\underline{44{,}640\,\mathrm{min}}}

Im Oktober darf der Server insgesamt 44,64 Minuten ausfallen. Yusufs 43,2 Minuten gelten für einen Monat mit 30 Tagen.

Bewertung: Ansatz (1 - V) \cdot T 1 Punkt, Minuten des Oktobers und Ergebnis 1 Punkt. Mit 30 Tagen gerechnet (43,2 min): 1 Punkt.

Geg.: V = 0{,}999 je Kalendermonat, Jahr 2026: T_J = 365\,\mathrm{d}

Ges.: höchstmögliche Ausfallzeit t_J im Jahr, wenn jeder Monat ausgeschöpft wird

Die zulässigen Ausfallzeiten der zwölf Monate addieren sich; zusammen umfassen die Monate alle 365 Tage:

t_J = (1 - V) \cdot T_J = 0{,}001 \cdot 365\,\mathrm{d} \cdot 24\,\frac{\mathrm{h}}{\mathrm{d}} = \underline{\underline{8{,}760\,\mathrm{h}}}

Stellungnahme: Die Aussage ist falsch. Der Server darf im Jahr insgesamt bis zu 8,76 Stunden (525,6 Minuten) ausfallen, also mehr als doppelt so lange wie von Jonas angenommen – allerdings höchstens 40,32 Minuten (Februar, 28 Tage) bis 44,64 Minuten (Monate mit 31 Tagen) in jedem einzelnen Monat, ein Ausgleich zwischen den Monaten ist nicht erlaubt.

Bewertung: Rechnung 2 Punkte, Urteil mit Begründung 1 Punkt. Ebenfalls richtig: 12 \cdot 43{,}2\,\mathrm{min} = 518{,}4\,\mathrm{min} \approx 8{,}64\,\mathrm{h} (mit 30-Tage-Monaten).

SaaS ist ein Modell des Cloud-Computings: Der Anbieter (Lippe Software AG) betreibt die Software samt Servern, Updates und Backups in seinem Rechenzentrum (1 Punkt). Let’s Meet nutzt das Ticketsystem als Dienstleistung über das Internet im Browser bzw. per App und zahlt eine laufende Gebühr, ohne sich um die Infrastruktur zu kümmern; die Daten liegen beim Anbieter (1 Punkt).

Bedeutung (1 Punkt): Die Software läuft auf eigener Hardware in den eigenen Räumen (hier Server im Büro am Jahnplatz) und wird vom Unternehmen selbst installiert, betrieben und gewartet.

Grund (2 Punkte), z. B.:

• Datenschutz und Kontrolle: Alle Tickets mit personenbezogenen Daten bleiben im eigenen Haus; kein Auftragsverarbeiter, keine Fragen zum Serverstandort – wichtig für eine App, bei der Vertrauen und Datenschutz zentral sind.

• Anpassbarkeit: Das Open-Source-System kann an die eigenen Abläufe und die REST-Schnittstelle der App angepasst werden, der Quellcode ist einsehbar.

• Keine Lizenzgebühren und keine Anbieterbindung: kein Abo, kein Risiko von Preiserhöhungen oder Einstellung des Dienstes.

• Updates in eigener Verantwortung: Updates können vorher getestet werden.

Beide Entscheidungen sind möglich; je Argument mit Situationsbezug 2 Punkte. Eine Entscheidung ohne Festlegung („beides hat Vor- und Nachteile“) erhält höchstens 2 Punkte.

Für SaaS („TicketLotse“), z. B.:

• Das Entwicklungsteam ist mit dem Neuaufbau von Backend und Datenbank ausgelastet; Betrieb, Updates und Backups übernimmt der Anbieter, das schont knappe Personalkapazität.

• Die App läuft rund um die Uhr; ein einzelner Server im Büro ohne Redundanz und ohne Rufbereitschaft wäre weniger verfügbar als ein Anbieter mit SLA (99,5 % je Jahr, Gutschrift bei Verstoß).

• Schnell einsatzbereit, da Meldungen bisher tagelang liegen bleiben.

• Der Datenschutz lässt sich mit einem Auftragsverarbeitungsvertrag und einem Rechenzentrum in Deutschland bzw. der EU absichern.

Für On-Premises (Open Source), z. B.:

• Tickets enthalten sensible Daten (Meldungen über Personen, Screenshots von Chats); im eigenen Haus behält Let’s Meet die volle Kontrolle, was das Vertrauen der Nutzenden stärkt.

• Das Team hat mit Docker und Spring Boot bereits Know-how im Serverbetrieb; das System lässt sich an die eigene REST-Schnittstelle und Moderationsabläufe anpassen.

• Keine Abhängigkeit von einem Anbieter und keine laufenden Lizenzkosten für ein Start-up.

Gegenargument, das bei On-Premises erkannt werden sollte: Fällt die Internetverbindung des Büros aus, kommen auch keine Tickets aus der App an.

• Für Tickets muss eine Löschfrist festgelegt werden (Löschkonzept), z. B. eine bestimmte Zeit nach dem Schließen des Tickets (1 Punkt).

• Sobald ein Ticket abgeschlossen ist und die Daten nicht mehr gebraucht werden (z. B. für Rückfragen, Abrechnung oder Nachweise), müssen die personenbezogenen Daten gelöscht oder anonymisiert werden (Name, E-Mail, Benutzerkonto, Screenshots) (1 Punkt).

• Die technische Lösung und anonyme Statistiken dürfen für Wissensdatenbank und Auswertungen erhalten bleiben; das System sollte das Löschen bzw. Anonymisieren automatisch durchführen. Wird ein Konto gelöscht, sind auch die zugehörigen Tickets zu berücksichtigen (1 Punkt).

Warum (1 Punkt): Bei SaaS verarbeitet die Lippe Software AG die personenbezogenen Daten der Nutzenden im Auftrag der Let’s Meet GmbH auf ihren Servern. Nach Art. 28 DSGVO ist dafür ein Vertrag über die Auftragsverarbeitung erforderlich; die Verantwortung für die Daten bleibt bei der Let’s Meet GmbH.

Inhalt (2 Punkte), z. B.: Der Anbieter verarbeitet die Daten nur nach Weisung und nur für den vereinbarten Zweck; er setzt geeignete technische und organisatorische Maßnahmen zum Schutz um; Gegenstand, Dauer, Art der Daten und betroffene Personen sind festgelegt; Unterauftragnehmer nur mit Zustimmung; Vertraulichkeit der Beschäftigten; Unterstützung bei Auskunft und Löschung; Löschung oder Rückgabe der Daten bei Vertragsende; Kontrollrechte des Auftraggebers.

Drei aus (je 1 Punkt Erläuterung, 1 Punkt passender Satz):

Bewertung: Sätze, die belehren oder eine Lösung vorwegnehmen („Sie müssen einfach neu installieren“), zählen nicht als aktives Zuhören.

Je Vorteil 2 Punkte, z. B.:

• Jede Anfrage ist mit Zeitstempel, Kategorie und Status erfasst; Auswertungen nach Monat, Schule oder Kategorie entstehen auf Knopfdruck statt aus Mails und Notizen.

• Häufige Ursachen werden sichtbar (z. B. viele Tickets der Kategorie „Lernplattform“) und können gezielt beseitigt werden.

• Die Einhaltung von Reaktions- und Lösungszeiten lässt sich nachweisen und berichten.

Im Juli sinkt die Ticketzahl auf 260, weil in den Sommerferien kaum Unterricht stattfindet und weniger Geräte genutzt werden (1 Punkt). Im August und September steigt sie auf 690 bzw. 720: Zum Schuljahresbeginn kommen neue Schüler*innen, 600 neue Tablets müssen eingerichtet werden, und die neue Version der Lernplattform führt zu Fragen und Störungen (2 Punkte).

Ohne die Ausreißer steigt die Ticketzahl: Im ersten Halbjahr kamen im Schnitt rund 407 Tickets im Monat, von Oktober bis Dezember rund 482 – etwa 18 % mehr. Vermutlich erzeugen die zusätzlichen Tablets dauerhaft mehr Anfragen (2 Punkte).

Je Maßnahme 1 Punkt, z. B.: häufige Fragen in der Wissensdatenbank bzw. in einem Self-Service-Portal beantworten (z. B. Passwort selbst zurücksetzen); Lehrkräfte und Schüler*innen zur Tablet-Nutzung schulen; wiederkehrende Ursachen im Problem Management beseitigen; Personal für Spitzenzeiten zum Schuljahresbeginn einplanen.

Geg.: 470 + 480 + 495 = 1.445 Tickets (1 Punkt); 838 im First Level gelöst; 1.372 mit eingehaltener Reaktionszeit

Ges.: Erstlösungsquote, SLA-Erfüllungsquote

\text{Erstlösungsquote} = \dfrac{838}{1.445} \approx \underline{\underline{57{,}993\,\%}} (1 Punkt)

\text{SLA-Erfüllungsquote} = \dfrac{1.372}{1.445} \approx \underline{\underline{94{,}948\,\%}} (1 Punkt)

Die vereinbarten 95 % werden knapp verfehlt; es fehlt ein einziges Ticket mit pünktlicher Reaktion (95 % von 1.445 wären 1.373 Tickets). Die Schul-IT sollte prüfen, in welchen Wochen die Reaktionszeiten überschritten wurden (vermutlich zu Spitzenzeiten), und dort nachsteuern. (2 Punkte)

Der Beamer ist ein Incident: eine ungeplante Störung, die schnell behoben werden muss (1 Punkt). Der Kursraum ist ein Service Request: eine Anfrage nach einer vereinbarten Standardleistung, nichts ist defekt, sie folgt einem festen Ablauf (1 Punkt).

Ges.: Kosten je Ticket

Kosten: 2 \cdot 62.000\,€ + 4.800\,€ + 3.600\,€ = 132.400\,€ (1 Punkt); Tickets 2026: 5.555 (1 Punkt)

\text{Preis je Ticket} = \dfrac{132.400\,€}{5.555} \approx \underline{\underline{23{,}83\,€}} (1 Punkt)

Je Merkmal mit Maßnahme 2 Punkte, z. B.:

Je Grund 2 Punkte, z. B.: klare Rahmenbedingungen und Leistungserwartungen auf beiden Seiten; Rechtssicherheit und Grundlage für Ansprüche, wenn der Shop ausfällt; Planungssicherheit bei Kosten und Leistungen (Vergütung, Zahlungsmodalitäten); geregelte Lösung von Streitigkeiten.

Vier Aspekte je 1 Punkt, z. B.: Verfügbarkeit, Lösungszeit je Schweregrad, Servicezeit/Erreichbarkeit, Datensicherung und Wiederherstellung, Verantwortlichkeiten beider Seiten, Sicherheit und Datenschutz, Berichte und Kennzahlen, Eskalation, Gutschriften bzw. Bonus-Malus, Laufzeit und Kündigung.

Zwei Beschreibungen je 2 Punkte, z. B.:

• Verfügbarkeit: Der Shop muss rund um die Uhr erreichbar sein, weil Kund*innen auch abends und am Wochenende bestellen; vereinbart wird z. B. 99,9 % je Kalendermonat ohne angekündigte Wartungsfenster, die nachts liegen.

• Datensicherung: tägliche Sicherung von Datenbank und Bestelldaten an einem zweiten Standort, Aufbewahrung 30 Tage, Wiederherstellung innerhalb von 4 Stunden.

Je Kriterium 2 Punkte, z. B.:

• Verfügbarkeit: Shop und Bestell-API zu 99,9 % je Kalendermonat erreichbar (gemessen per externem Monitoring alle 60 Sekunden); Hotline für Störungen 24/7 erreichbar; Antwortzeit der Startseite unter 2 Sekunden bei 95 % der Aufrufe.

• Verantwortlichkeiten des Dienstleisters: monatlicher Servicebericht mit Verfügbarkeit, Störungen und Ursachen bis zum 5. Werktag; Meldung von Sicherheitsvorfällen innerhalb von 8 Stunden; Einspielen von Sicherheitsupdates innerhalb von 7 Tagen nach Veröffentlichung; monatlicher Test der Datenwiederherstellung mit Protokoll.

Je Begriff 2 Punkte:

• Down Time: Ausfallzeit – jeder Zeitraum, in dem Shop oder Bestellschnittstelle für mehr als 10 % der Anfragen nicht erreichbar sind; mindestens 72 Stunden vorher angekündigte Wartung zählt nicht.

• Severity 1 incident: Störung der höchsten Schwere – kompletter Ausfall des Shops, Verlust von Bestelldaten oder ein schwerer Sicherheitsvorfall; dafür gelten die kürzesten Reaktions- und Lösungszeiten.

• 24x7 monitoring: Der Dienstleister überwacht rund um die Uhr an allen Tagen alle Server, Datenbanken und Netzkomponenten, für die er verantwortlich ist.

• Service credit: Gutschrift, wenn die Monatsverfügbarkeit unter 99,9 % fällt: 10 % der Monatsgebühr je angefangenem 0,1-Prozentpunkt darunter, höchstens 50 %.

Je Maßnahme 2 Punkte, z. B.: getrennte virtuelle Maschinen bzw. Container und eigene Datenbank je Kunde (Mandantentrennung); eigenes VLAN bzw. Netzsegment mit Firewall-Regeln; Verschlüsselung der Daten im Speicher und bei der Übertragung; strikte Rechtevergabe nach dem Need-to-know-Prinzip mit protokollierten Administratorzugriffen.

Z. B. (1,5 Punkte je Punkt): ob der Vertrag Subunternehmer überhaupt erlaubt und die Zustimmung regelt; ob der Subunternehmer auf personenbezogene Kundendaten zugreifen kann – dann sind Auftragsverarbeitung und die Übermittlung in ein Drittland nach DSGVO (Angemessenheitsbeschluss oder Standardvertragsklauseln) zu klären; ob der Dienstleister für den Subunternehmer haftet und die SLA-Zusagen weiter gelten; Sprache und Erreichbarkeit bei Störungen.

Zwei Grundgedanken je 2 Punkte, z. B.: ITIL sammelt bewährte Vorgehensweisen, mit denen IT-Services einheitlich geplant, erbracht und verbessert werden; IT-Aktivitäten und -Kosten werden an den Anforderungen des Unternehmens und der Kund*innen ausgerichtet; die IT wird als Partner gesehen, der gemeinsam mit dem Geschäft Wert schafft, nicht als technisches Hinterzimmer.

Zweck des Service-Level-Managements (2 Punkte): klare, am Geschäftsbedarf orientierte Ziele für die Services festlegen und sicherstellen, dass die Leistungen daran gemessen, berichtet und überprüft werden.

• Vereine (2 Punkte): eine Kontaktadresse für alle Anliegen; sie müssen nicht wissen, ob App, Abrechnung oder Server betroffen ist, und erhalten eine einheitliche Rückmeldung.

• Entwicklungsteam (2 Punkte): Es bekommt nur vorsortierte, vollständig erfasste Tickets, für die es wirklich zuständig ist, und wird nicht ständig durch Anrufe unterbrochen.

• Funktionale Eskalation (2 Punkte): Das Ticket wird an eine Ebene mit mehr Fachwissen oder Berechtigungen weitergegeben – vom Service Desk (First Level) an das App-Team (Second Level) und weiter an den Hosting-Dienstleister (Third Level).

• Hierarchische Eskalation (2 Punkte): Vorgesetzte werden eingebunden, weil eine Entscheidung, mehr Ressourcen oder Kommunikation nötig sind – hier die Information an die Leitung Entwicklung, wenn die Lösungszeit überschritten zu werden droht.

Ein Incident ist eine ungeplante Störung oder Qualitätsminderung eines Services, z. B. ein Verein kann das Logo seines Vereinskontos nicht hochladen (1 Punkt). Ein Major Incident ist ein Incident mit sehr großer Auswirkung, z. B. die Anmeldung zur App ist für alle Nutzenden ausgefallen (1 Punkt); er bekommt höchste Priorität, einen eigenen Ablauf mit Krisenteam und regelmäßiger Information der Betroffenen (1 Punkt).

Je Ereignis 2 Punkte (Art 1, Folge 1):

1. Information: Vorgang im Sollbereich, nur protokollieren, kein Eingreifen nötig.

2. Warnung: Schwellenwert überschritten, aber noch keine Störung; Ursache prüfen und vorbeugend handeln (z. B. Index der Suche optimieren, Ressourcen erhöhen), bevor Nutzende betroffen sind.

3. Ausnahme (Exception): Service gestört; sofort Incident anlegen bzw. automatisch erzeugen lassen und beheben, Betroffene informieren.

Proaktives Problem Management sucht Ursachen möglicher Störungen, bevor Incidents entstehen (1 Punkt). Steigt die Antwortzeit der Suche z. B. jede Woche, weil die Zahl der Aktivitäten wächst, wird die Ursache analysiert (fehlender Index, zu kleine Datenbank) und beseitigt, bevor die Suche ausfällt und Vereine Tickets schreiben (2 Punkte).

Known Error: ein Problem, dessen Ursache bekannt und dokumentiert ist – hier der Absturz beim Hochladen großer Fotos (1 Punkt). Workaround: vorläufige Umgehungslösung, bis der Fehler behoben ist, z. B. Fotos verkleinern oder über die Web-App hochladen; der Service Desk gibt sie aus der Wissensdatenbank weiter (1 Punkt).

Geg.: 30 Tage; Ausfälle 156 min (12.11.) und 75 min (25.11.); Wartungsfenster zählt nicht

Ges.: Verfügbarkeit V

Gesamtzeit: t_G = 30 \cdot 24\,\mathrm{h} \cdot 60\,\frac{\mathrm{min}}{\mathrm{h}} = 43.200\,\mathrm{min} (1 Punkt)

Ausfallzeit: t_A = 156\,\mathrm{min} + 75\,\mathrm{min} = 231\,\mathrm{min} (2 Punkte, davon 1 Punkt für das Weglassen des Wartungsfensters)

V = \dfrac{t_G - t_A}{t_G} = \dfrac{43.200\,\mathrm{min} - 231\,\mathrm{min}}{43.200\,\mathrm{min}} \approx \underline{\underline{99{,}465\,\%}} (2 Punkte)

Das SLA wurde nicht eingehalten: Zulässig wären 0{,}5\,\% \cdot 43.200\,\mathrm{min} = 216\,\mathrm{min} Ausfall gewesen, tatsächlich waren es 15 Minuten mehr. (1 Punkt)

Unterschreitung: 99{,}5\,\% - 99{,}465\,\% \approx 0{,}035 Prozentpunkte, also eine angefangene 0,1 (1 Punkt). Gutschrift: 5\,\% \cdot 240\,€ = \underline{\underline{12{,}00\,€}} (1 Punkt)

Gerechnet wird nur in der Servicezeit (Mo–Fr 7–17 Uhr). Je Ticket 1 Punkt, Quote 2 Punkte:

Erfüllungsquote: \dfrac{3}{5} = \underline{\underline{60\,\%}}

• Datenbankspeicher voll (2 Punkte): Speicherbelegung überwachen und ab z. B. 80 % eine Warnung erzeugen; Wachstum auswerten und Speicher rechtzeitig erweitern; alte Protokolle und abgelaufene Fahrten automatisch löschen.

• Zertifikat abgelaufen (2 Punkte): Zertifikate automatisch erneuern lassen (z. B. per ACME-Protokoll); Ablaufdatum überwachen und 30 Tage vorher eine Warnung an die Schul-IT senden.

Die Schul-IT kann der Schule nur zusagen, was ihre Zulieferer ihr zusichern. Fällt das Netz aus und braucht das Rechenzentrum bis zu 8 Stunden, kann die Schul-IT weder kurze Lösungszeiten noch 99,5 % Verfügbarkeit garantieren (8 Stunden allein wären 480 Minuten Ausfall) (2 Punkte). Die Vereinbarung mit einem externen Zulieferer heißt Underpinning Contract (UC); mit internen Teams wäre es ein Operational Level Agreement (OLA) (1 Punkt).

Je Inhalt 1 Punkt, z. B.: erreichte Verfügbarkeit mit allen Ausfällen und Ursachen; Anzahl der Tickets nach Priorität; Einhaltung von Reaktions- und Lösungszeiten; Gutschriften; geplante Wartungen und Verbesserungsmaßnahmen.