Ü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.

Gewinn für Let’s Meet (3 Punkte, ein gut erläuterter Aspekt mit Bezug zur Situation 2 Punkte, ein weiterer 1 Punkt), z. B.:

• Die 30 gleichartigen Absturzmeldungen aus der Android-App (Meldung 4) landen alle beim Support und werden dort zu einem Problem verknüpft; bisher wären sie teils per Mail an einzelne Entwickler*innen gegangen, und niemand hätte die Häufung früh bemerkt.

• Yusuf Demirs Team, das gerade Backend und Datenbank mit Spring Boot neu aufbaut, wird nicht mehr durch Anrufe zu Passwort- oder Kontofragen unterbrochen und bekommt nur noch Tickets wie Lea Schmitts Filterfehler, die wirklich Code betreffen.

• Nutzende haben eine bekannte Anlaufstelle in der App und erhalten Rückmeldungen aus einer Hand, statt bei Mail, Telefon und Kanban-Board nachzufragen.

Gefahr und Maßnahme (2 Punkte): Bei zwei Personen im Support entsteht ein Rückstau, z. B. nach einem fehlerhaften Update oder bei Urlaub und Krankheit; Tickets bleiben liegen und die Nutzenden sind unzufriedener als vorher. Maßnahmen, z. B.: Wissensdatenbank und Self-Service (Hilfeseiten in der App, Passwort-Reset) ausbauen, damit weniger Tickets entstehen; Vertretungsregel bzw. Rufbereitschaft aus der Entwicklung für Spitzen; Standardantworten und automatische Verknüpfung gleicher Meldungen mit einem Major Incident.

Ü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,7 %, 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).

Je Zeile 1 Punkt:

1. falsch: Die 99,7 % gelten je Kalenderjahr, nicht je Monat. Ein einzelner Monat darf also schlechter sein, solange das Jahr insgesamt reicht.

2. falsch: Supportanfragen werden nur Montag bis Freitag von 8 bis 18 Uhr angenommen und bearbeitet, nicht an Feiertagen in NRW. Die Software selbst läuft rund um die Uhr, der Support nicht.

3. falsch: Reaktionszeit heißt hier, dass eine qualifizierte Fachkraft des Supports mit der Bearbeitung beginnt; eine automatische Eingangsbestätigung zählt nicht.

4. richtig: angekündigte Wartungsfenster sonntags 2–4 Uhr sind von der Verfügbarkeit ausgenommen.

5. falsch: Ausfälle durch eigene Schnittstellen der Kund*innen sind ausgeschlossen (Exclusions); sie zählen nicht gegen die Verfügbarkeit von TicketLotse.

Typischer Fehler: die Verfügbarkeit der Software mit der Erreichbarkeit des Supports 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.: Eingang Fr 06.11.2026, 16:15 Uhr; Servicezeit Mo–Fr 8–18 Uhr; Priorität 1: Reaktion 1 h, Lösung 4 Servicestunden

Ges.: spätester Beginn der Bearbeitung, spätester Lösungszeitpunkt

Reaktion (1 Punkt): 16:15 Uhr + 1 h = Freitag, 17:15 Uhr (liegt noch in der Servicezeit).

Lösung (2 Punkte): Am Freitag bleiben von 16:15 bis 18:00 Uhr 1,75 Servicestunden (1 h 45 min). Samstag und Sonntag zählen nicht. Die restlichen 4\,\mathrm{h} - 1{,}75\,\mathrm{h} = 2{,}25\,\mathrm{h} laufen ab Montag, 09.11.2026, 8:00 Uhr – das Ticketsystem muss also erst bis Montag, 10:15 Uhr wieder funktionieren, 66 Stunden nach der Meldung.

Beurteilung (2 Punkte): Die Zusagen passen schlecht. Gerade am Freitagabend und am Wochenende melden viele Nutzende Probleme; fällt die Ticketannahme dann aus, bleiben Meldungen bis Montag liegen – genau das Problem, das das Ticketsystem lösen soll. Let’s Meet sollte eine Servicezeit auch am Wochenende oder für Priorität 1 eine Lösungszeit in Kalenderstunden aushandeln (ggf. gegen Aufpreis) oder die Ausfallsicherheit beim anderen Angebot vergleichen.

Typischer Fehler: 4 Kalenderstunden rechnen (Lösung bis Freitag 20:15 Uhr).

Ges.: Kosten über 36 Monate

TicketLotse (SaaS) (2 Punkte):

K_{SaaS} = 400\,€ + 5 \cdot 29\,€ \cdot 36 = 400\,€ + 5.220\,€ = \underline{\underline{5.620{,}00\,€}}

Open Source im eigenen Büro (On-Premises) (3 Punkte):

• Server: 2.100,00 €

• Einrichtung: 16\,\mathrm{h} \cdot 55\,€/\mathrm{h} = 880{,}00\,€

• Strom: 0{,}035\,\mathrm{kW} \cdot 24\,\mathrm{h} \cdot 365 \cdot 3 = 919{,}8\,\mathrm{kWh}; 919{,}8\,\mathrm{kWh} \cdot 0{,}32\,€/\mathrm{kWh} \approx 294{,}34\,€

• Pflege: 1{,}5\,\mathrm{h} \cdot 36 \cdot 55\,€/\mathrm{h} = 2.970{,}00\,€

K_{On\text{-}Prem} = 2.100\,€ + 880\,€ + 294{,}34\,€ + 2.970\,€ = \underline{\underline{6.244{,}34\,€}}

Vergleich (1 Punkt): Die eigene Lösung ist über drei Jahre rund 624 € (etwa 11 %) teurer, obwohl keine Lizenzgebühren anfallen. Den größten Posten bildet die Arbeitszeit für die Pflege.

Stellungnahme (1 Punkt): Die Aussage stimmt nicht. Die Software ist lizenzfrei, aber Einrichtung und Pflege kosten Arbeitszeit, die dem ausgelasteten Entwicklungsteam beim Neuaufbau des Backends fehlt; auch „nebenbei“ geleistete Stunden haben ihren Preis (hier 3.850 € über drei Jahre).

Fehlende Posten (2 Punkte, je 1 Punkt), z. B.:

• Datensicherung außer Haus und Wiederherstellungstests beim eigenen Server

• Ausfallrisiko: Ersatzteile, Hardwaredefekt ohne Ersatzgerät, Internetausfall im Büro (dann kommen keine Tickets aus der App an)

• Schulung der Beschäftigten (bei beiden Varianten)

• Anpassung der REST-Schnittstelle der App an das jeweilige System

• Preiserhöhungen des SaaS-Anbieters bzw. zusätzliche Lizenzen, wenn das Team wächst

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; die 1,5 Stunden Pflege im Monat und die 16 Stunden Einrichtung aus ga) fehlen dort, während die Lippe Software AG den Server ohnehin rund um die Uhr betreut.

• 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,7 % je Jahr, Gutschrift bei Verstoß); außerdem ist TicketLotse über drei Jahre etwas günstiger.

• 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; die Mehrkosten von rund 624 € in drei Jahren sind gering.

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.

Auswertung (je Antwort 1 Punkt):

1. Paraphrasieren: Amir gibt das Anliegen mit eigenen Worten wieder und lässt es sich bestätigen.

2. ungeeignet: Amir stellt eine Vermutung als Tatsache hin und schiebt dem Anrufer die Schuld zu, bevor er etwas weiß; Tobias fühlt sich nicht ernst genommen, und wichtige Angaben (App-Version, Gerät) fehlen weiter.

3. Verbalisieren: Amir spricht das Gefühl hinter der Beschwerde an und zeigt Verständnis.

4. ungeeignet: Amir spielt das Problem herunter und bewertet die Gefühle des Anrufers; das verstärkt den Ärger.

5. Nachfragen: Eine offene, gezielte Frage klärt den Fehler genauer.

Bessere Sätze (je 1 Punkt), z. B.:

• statt 2 (Nachfragen bzw. Unklares aufklären): „Damit ich das prüfen kann: Welches Smartphone nutzen Sie, und funktioniert außer dem Absagen alles andere in der App?“

• statt 4 (Zusammenfassen): „Ich halte fest: Absagen klappt seit dem Update nicht, der Lauftreff ist morgen früh. Ich lege dafür jetzt ein Ticket an und sage der Gruppenleitung Bescheid, dass Sie nicht kommen.“

Bewertung: Ein Satz, der wieder belehrt oder eine Lösung vorwegnimmt („Installieren Sie die App einfach neu“), zählt nicht.

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.

Zwei Schwächen je 2 Punkte, z. B.:

• Spitze mit Normalmonat verglichen: Der September ist der einzige Ausreißer des Jahres – 600 Tablets wurden eingerichtet und die Lernplattform umgestellt, beides erzeugt einmalig viele Fragen und Störungen. Schon im Oktober sinkt die Zahl deutlich. Wer diesen Sondermonat mit dem Juli vergleicht, sieht eine „Explosion“, die es im laufenden Betrieb nicht gibt.

• Absolute Zahlen ohne Bezugsgröße: Laut Tabelle betreut die Schul-IT seit September 600 Geräte mehr (+25 %). Dass dann mehr Tickets kommen, ist zu erwarten und sagt nichts darüber, ob die Geräte häufiger Probleme machen.

• Falscher Schluss auf die Arbeitsqualität: Die Ticketanzahl misst, wie viele Anliegen eingehen, nicht wie gut sie bearbeitet werden. Dafür wären Kennzahlen wie Erstlösungsquote oder SLA-Erfüllungsquote nötig.

Zutreffende Aussage (1 Punkt), z. B.: „Die Einführung der Tablets hat im September eine einmalige Spitze verursacht. Seit Oktober liegt die Ticketzahl rund 27 % über dem ersten Halbjahr, die Zahl der betreuten Geräte aber auch um 25 %; je Gerät hat sich wenig geändert.“

Geg.: Januar bis Juni 2.440 Tickets bei 2.400 Geräten; Oktober bis Dezember 1.550 Tickets bei 3.000 Geräten

Ges.: Tickets je 100 Geräte und Monat

Erstes Halbjahr: \dfrac{2.440}{6} \approx 406{,}7 Tickets im Monat; \dfrac{406{,}7}{2.400} \cdot 100 \approx \underline{\underline{16{,}9}} Tickets je 100 Geräte (1 Punkt)

Oktober bis Dezember: \dfrac{1.550}{3} \approx 516{,}7 Tickets im Monat; \dfrac{516{,}7}{3.000} \cdot 100 \approx \underline{\underline{17{,}2}} Tickets je 100 Geräte (1 Punkt)

Bewertung (2 Punkte): Je Gerät kommen nur etwa 2 % mehr Tickets als im ersten Halbjahr – fast der gesamte Anstieg entsteht durch die größere Zahl betreuter Geräte. Die Tablets verursachen nach der Einführung kaum mehr Anfragen als die übrigen Geräte. Eine dritte Fachkraft lässt sich mit „schlechterer Arbeit“ nicht begründen; zu prüfen ist aber, ob die vorhandenen zwei Fachkräfte die um ein Viertel höhere Menge auf Dauer schaffen (siehe d).

Abschätzung (1 Punkt): 3.400 \cdot \dfrac{17{,}2}{100} \approx \underline{\underline{586}} Tickets im Monat (mit dem Wert des ersten Halbjahres rund 576).

Geg.: 505 + 515 + 530 = 1.550 Tickets (1 Punkt); 899 im First Level gelöst; 1.470 mit eingehaltener Reaktionszeit

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

\text{Erstlösungsquote} = \dfrac{899}{1.550} \approx \underline{\underline{58{,}000\,\%}} (1 Punkt)

\text{SLA-Erfüllungsquote} = \dfrac{1.470}{1.550} \approx \underline{\underline{94{,}839\,\%}} (1 Punkt)

Die vereinbarten 95 % werden knapp verfehlt; es fehlen drei Tickets mit pünktlicher Reaktion (95 % von 1.550 sind 1.472,5, also mindestens 1.473 Tickets). Die Schul-IT sollte prüfen, in welchen Wochen die Reaktionszeiten überschritten wurden (vermutlich zu Spitzenzeiten), und dort nachsteuern – das passt zur Frage aus c), ob zwei Fachkräfte die höhere Menge schaffen. (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.540 (1 Punkt)

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

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

Je Problem mit passendem Vertragsinhalt 2 Punkte, z. B.:

• Keine Erreichbarkeit in der Nacht: Niemand hat zugesagt, dass außerhalb der Bürozeiten jemand reagiert; der Shop war 17 Stunden 25 Minuten offline, mitten im umsatzstärksten Wochenende. → Servicezeit bzw. Notfallhotline 24/7 und Reaktionszeit je Schweregrad (z. B. 30 Minuten für einen Komplettausfall).

• Keine Folgen für den Hoster: „Bemühen“ ist keine überprüfbare Leistung; CSB-Rad kann weder eine Gutschrift noch Schadenersatz durchsetzen. → messbare Verfügbarkeit je Monat mit Gutschriftstaffel und ggf. Sonderkündigungsrecht.

• Keine Klarheit über die Ursache und das weitere Vorgehen: CSB-Rad weiß nicht, warum der Shop ausfiel und ob es wieder passieren kann. → Pflicht zu Störungsbericht mit Ursache und Maßnahmen, Eskalationsstufen mit Ansprechpersonen.

Ebenfalls richtig: Wiederherstellung von Bestelldaten ungeregelt (Sicherung, RPO); Wartungsarbeiten ohne Ankündigung.

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 Urteil mit Begründung 1 Punkt, je überprüfbarer Umformulierung 1 Punkt:

1. ungeeignet („praktisch immer“ lässt sich nicht messen). Besser: „Shop und Bestellschnittstelle sind zu mindestens 99,9 % je Kalendermonat erreichbar, gemessen durch externes Monitoring im Minutentakt.“

2. geeignet: Frist, Inhalt und Zuständigkeit sind festgelegt und lassen sich nachprüfen.

3. ungeeignet („zeitnah“ ist unbestimmt). Besser: „Als kritisch eingestufte Sicherheitsupdates werden innerhalb von 72 Stunden, alle übrigen innerhalb von 14 Tagen nach Veröffentlichung eingespielt; jede Installation wird protokolliert.“

4. ungeeignet (offen, was, wie oft und wie lange gesichert wird). Besser: „Datenbank und Bestelldaten werden täglich an einem zweiten Standort gesichert und 30 Tage aufbewahrt; eine Wiederherstellung wird einmal im Quartal getestet und protokolliert.“

Bedeutung (je 1 Punkt):

• Maintenance windows: Geplante Wartung zählt nicht als Ausfall, wenn sie mindestens 72 Stunden vorher angekündigt wird und zwischen 23 und 4:30 Uhr liegt. CSB-Rad kann die Kund*innen vorab informieren und z. B. keine Werbeaktion in diese Zeit legen.

• Exclusions: Ausfälle, die CSB-Rad selbst verursacht – etwa durch ein selbst installiertes Plug-in oder eine eigene Konfigurationsänderung –, rechnet der Dienstleister nicht gegen die Verfügbarkeit.

Beurteilung (2 Punkte): Ganz streichen ist nicht sinnvoll. Der Dienstleister kann nicht für Fehler einstehen, die er weder verursacht noch beeinflussen kann; er würde die Klausel kaum akzeptieren oder die Monatsgebühr erhöhen. Problematisch ist aber, dass bei jedem Ausfall nach einer Änderung von CSB-Rad Streit darüber droht, wer ihn verursacht hat.

Vorschlag (1 Punkt), z. B.: „Ausgenommen sind Ausfälle, die nachweislich durch Software oder Konfigurationsänderungen der Kundin verursacht wurden. Den Nachweis führt der Dienstleister anhand der Protokolle; er unterstützt die Kundin bei der Wiederherstellung innerhalb der vereinbarten Reaktionszeit.“

Was zählt als Ausfall? (2 Punkte): Die Wartung am 09.03. lag in der Nacht und wurde rund 87 Stunden vorher angekündigt – sie zählt nicht. Den Ausfall am 23.03. hat CSB-Rad mit dem eigenen Plug-in verursacht; er fällt unter die Exclusions. Es zählen nur die 220 Minuten vom 13.03.

Verfügbarkeit und Gutschrift (2 Punkte):

t_G = 31 \cdot 24\,\mathrm{h} \cdot 60\,\frac{\mathrm{min}}{\mathrm{h}} = 44.640\,\mathrm{min}

V = \dfrac{44.640\,\mathrm{min} - 220\,\mathrm{min}}{44.640\,\mathrm{min}} \approx \underline{\underline{99{,}507\,\%}}

Die Verfügbarkeit liegt unter 99,9 %, aber knapp nicht unter 99,5 %: Gutschrift 10\,\% \cdot 890\,€ = \underline{\underline{89{,}00\,€}}.

Abweichung erklären (1 Punkt): Der Bericht hat auch die 45 Minuten vom 23.03. mitgezählt: \dfrac{44.640 - 265}{44.640} \approx 99{,}41\,\%. Dieser Ausfall ist aber ausgeschlossen. Der Fehler geht hier zulasten des Dienstleisters; CSB-Rad sollte ihn trotzdem melden, damit künftige Berichte richtig rechnen.

Wiederherstellungsziele (2 Punkte): Der Shop war von 21:40 bis 01:20 Uhr ausgefallen, also 3 h 40 min – weniger als die zugesagten 4 Stunden. Verloren gingen höchstens die Bestellungen von 21:30 bis 21:40 Uhr, also 10 Minuten – weniger als 15 Minuten. Die Aussage „All recovery targets met“ stimmt.

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.

Je Vorschlag 2 Punkte (Zuordnung 1, Begründung 1):

• V1 – Progress iteratively with feedback: Alles wird gleichzeitig und ohne Erprobung umgestellt; Fehler in Kategorien oder Portal treffen sofort alle Vereine, und das Team kann nicht aus Rückmeldungen lernen. (Auch „Keep it simple and practical“ ist vertretbar, wenn mit den vielen Kategorien und Freigaben begründet.)

• V2 – Keep it simple and practical: Eine Freigabe durch die Geschäftsführerin bringt bei Standardanfragen niemandem einen Nutzen, verzögert aber jede Meldung und bindet Clara Neumann.

• V3 – Start where you are: Vorhandene, bewährte Inhalte werden weggeworfen, obwohl viele Vereinsfragen (Passwort, Kontodaten, Bedienung) dieselben sind wie bei Einzelnutzenden.

Bessere Variante (2 Punkte, mit Bezug zum Leitprinzip), z. B.:

• zu V1: zuerst mit drei Pilotvereinen und vier neuen Kategorien starten, nach vier Wochen deren Rückmeldungen und die Ticketauswertung besprechen, dann schrittweise erweitern;

• zu V2: Freigabe nur für Anliegen mit Vertragsbezug (z. B. Kündigung, Preisänderung); Standardanfragen löst der Service Desk sofort, Passwort-Reset als Self-Service;

• zu V3: vorhandene Wissensartikel sichten, passende übernehmen und nur um vereinsspezifische Themen (Mitgliederliste, Vereinsrechnung) ergänzen.

Reaktion (1 Punkt): Jonas antwortet freundlich, verweist auf den Service Desk und leitet die Nachricht selbst dorthin weiter bzw. legt ein Ticket an, damit der Verein nicht noch einmal schreiben muss. Er erklärt kurz, dass so die Bearbeitung auch bei seiner Abwesenheit gesichert ist.

Folgen (je 2 Punkte), z. B.:

• Die Änderung ist nirgends dokumentiert; bei Rückfragen oder Fehlern weiß niemand, wer was geändert hat, und Auswertungen des Supports werden unvollständig.

• Der Verein lernt, dass der direkte Weg schneller ist, und schreibt künftig wieder an Jonas; der SPOC wird ausgehöhlt und das Entwicklungsteam ständig unterbrochen.

• Datenschutz und Berechtigungen: Ob der Vorsitzende die Änderung überhaupt verlangen darf, prüft sonst der Service Desk nach festem Ablauf.

• 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).

Geg.: Kapazität 2.000 GB, belegt 1.640 GB, Zuwachs 40 GB/Monat, Lieferzeit der Erweiterung 2 Monate

Restzeit bis voll: \dfrac{2.000\,\mathrm{GB} - 1.640\,\mathrm{GB}}{40\,\mathrm{GB/Monat}} = 9 Monate (1 Punkt)

Mögliche Lösung (je Schwellenwert mit Folge und Begründung 2 Punkte):

• Schwellenwert 1 bei 85 % (1.700 GB): Dann bleiben \dfrac{300\,\mathrm{GB}}{40\,\mathrm{GB/Monat}} = 7{,}5 Monate. Das Monitoring erzeugt automatisch ein Ticket an Yusuf Demir; er plant die Erweiterung, holt ein Angebot ein und prüft, ob alte Fotos gelöscht oder verkleinert werden können. Die Zeit reicht für Planung, Freigabe und die zwei Monate Lieferzeit.

• Schwellenwert 2 bei 95 % (1.900 GB): Dann bleiben nur noch 2,5 Monate, also kaum mehr als die Lieferzeit. Das Monitoring benachrichtigt Entwicklung und Geschäftsführung sofort; ist die Erweiterung noch nicht bestellt, wird sie umgehend beauftragt und vorübergehend z. B. die Bildgröße beim Hochladen begrenzt.

Andere Werte sind richtig, wenn die erste Schwelle genug Zeit für Planung und Lieferzeit lässt (mehr als zwei Monate Vorlauf) und die zweite eine dringende Reaktion vor dem Ausfall auslöst.

Einordnung (2 Punkte): Amirs Löschen war reaktiv – erst die Störung, dann die Behebung eines Incidents, die eigentliche Ursache (stetiges Wachstum ohne Vorwarnung) bleibt bestehen. Die Schwellenwerte aus e) sind proaktiv: Der Trend wird ausgewertet und die Ursache beseitigt, bevor eine Störung entsteht.

Folgen (2 Punkte), z. B.: Reaktiv erleben die Nutzenden einen Ausfall und schreiben Tickets; das Support-Team arbeitet unter Zeitdruck, und der Fehler kehrt wieder. Proaktiv merken die Nutzenden nichts; das Team kann die Erweiterung in Ruhe planen, braucht dafür aber ein gepflegtes Monitoring und Zeit für die regelmäßige Auswertung.

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.