aiMOOC

IT-Service Projekte und Automatisierung – Tickets nachvollziehbar bearbeiten

QR-Code

Einleitung

IT-Service Projekte und Automatisierung – Tickets nachvollziehbar bearbeiten

Zielgruppe: IT-Ausbildung, insbesondere Fachinformatik und IT-nahe Ausbildungsberufe.

Dauer: ca. 90–120 Minuten einschließlich Praxisaufgaben.

Kurzbeschreibung: Du lernst, IT-Service-Tickets mit klaren Statusmeldungen, gezielten Rückfragen und dokumentierten Lösungen nachvollziehbar zu bearbeiten. Anschließend automatisierst Du einfache Arbeitsschritte in einer lokalen Testumgebung.

Deine Lernziele:

Ticketsystem: Du erfasst einen Vorgang vollständig und verständlich.
Workflow: Du wählst einen passenden Bearbeitungsstatus.
Kommunikation: Du formulierst gezielte Rückfragen.
Fehleranalyse: Du überprüfst eine Lösung mit einem reproduzierbaren Test.
Dokumentation: Du hältst Ursache, Maßnahme und Ergebnis nachvollziehbar fest.
Automatisierung: Du testest sichere Regeln mit fiktiven Daten.

Sicherheitsregel: Alle praktischen Übungen erfolgen ausschließlich lokal und mit erfundenen Daten. Du verwendest keine fremden Netzwerke, Produktivsysteme, Zugangsdaten oder echten Kundendaten. Externe Dienste werden nicht durch die Programme angesprochen. Änderungen an echten IT-Systemen benötigen eine ausdrückliche Autorisierung.

Historische Demo-Ansicht eines Ticketsystems: Mehrere Vorgänge werden zentral verwaltet. Quelle: Wikimedia Commons, Maddin42, GPL.

Der Ausbildungsfall: Ticket T-104

Du arbeitest im fiktiven IT-Service der Lernfirma Nordlicht.

Eine Person aus dem Übungsbüro meldet:

„Ich wollte heute die Übersicht als CSV exportieren. Die Datei enthält nur die Spaltenüberschriften. Ich brauche alle vorhandenen Einträge.“

Ticketdaten:

Feld	Fiktiver Inhalt
Ticket-ID	T-104
Kategorie	Anwendungsunterstützung
Betroffener Dienst	Lokales Übungsportal
Meldung	CSV-Export enthält keine Datensätze
Auswirkung	Eine Übungsaufgabe kann nicht abgeschlossen werden
Status	Neu
Zuständigkeit	IT-Service-Team der Lernfirma
Nächster Schritt	Zeitraumfilter erfragen

Dein Auftrag: Bearbeite T-104 bis zu einer überprüften und dokumentierten Lösung. Entscheide zunächst nicht, dass ein Programmfehler vorliegt: Es fehlen noch Informationen.

Lerneinheit 1: Tickets verstehen

Lernzeit: 5 Minuten

Ein Issue-Tracking-System erfasst und verfolgt Anfragen, Störungen und Aufgaben. Die Ticket-ID macht jeden Vorgang eindeutig auffindbar.

Ein Incident betrifft eine ungeplante Störung oder Qualitätsminderung eines IT-Service. Eine Serviceanfrage betrifft beispielsweise den Wunsch nach einer bereitgestellten Leistung. Im konkreten Fall muss zunächst festgestellt werden, ob tatsächlich eine technische Störung vorliegt.

Ein gutes Ticket beantwortet vier Fragen:

Was funktioniert nicht wie erwartet?
Wo tritt die Beobachtung auf?
Welche Auswirkung hat sie?
Was wurde bereits überprüft?

Video: „ITSM Request Portal in Jira Service Management“, offizieller Atlassian-Kanal. Beobachte, wie Anfragen eingehen und in einer Warteschlange landen. Das Video zeigt ein reales Produkt; Du arbeitest im Kurs ausschließlich mit der lokalen Simulation.

Mini-Aufgabe – Basis: Ergänze im Ticket T-104 die fehlende Information, die Du vor einer sicheren Diagnose benötigst.

Feedback und Begründung anzeigen

Sinnvoll ist die Frage nach dem eingestellten Zeitraumfilter. Ohne diese Angabe lässt sich nicht zwischen einer leeren Auswahl und einer Fehlfunktion unterscheiden.

Lerneinheit 2: Den richtigen Status setzen

Lernzeit: 7 Minuten

Der Status zeigt, wo die Bearbeitung steht und welche Aktion als Nächstes erforderlich ist.

Kanban-Visualisierung von Jennifer Falco, CC BY 4.0. Eine ähnliche Übersicht kann für Tickets genutzt werden.

Unser vereinfachter Übungsworkflow:

Status	Bedeutung	Nächste Aktion
Neu	Eingang erfasst	Zuständigkeit prüfen
In Bearbeitung	Analyse läuft	Sachverhalt untersuchen
Rückfrage	Information fehlt	Antwort abwarten und nachverfolgen
Gelöst	Lösung erfolgreich getestet	Rückmeldung und Bestätigung einholen
Geschlossen	Abschluss bestätigt	Vorgang archivieren

Statusweg von T-104:

Neu → In Bearbeitung → Rückfrage → In Bearbeitung → Gelöst → Geschlossen

Dies ist ein didaktisch vereinfachter Workflow. In realen Systemen können Statusbezeichnungen und Übergangsregeln abweichen.

Ein weiteres Kanban-Beispiel, Garbanea, CC BY-SA 4.0. Überlege, welche Spalte die wartenden Rückfragen enthalten sollte.

Video: „Jira Service Management Queues | Explained in 6 Minutes“, Hean Tech. Achte darauf, wie Filter und Warteschlangen die Arbeit organisieren.

Mini-Aufgabe – Basis: Du hast die Meldung gelesen, aber kannst ohne weitere Auskunft nicht fortfahren. Welchen Status setzt Du nach einer dokumentierten Rückfrage?

Feedback und Begründung anzeigen

Rückfrage ist im Übungsworkflow passend. Der Vorgang ist nicht gelöst. Der Status macht erkennbar, dass eine Information fehlt. Eine Wiedervorlage verhindert, dass er vergessen wird.

Lerneinheit 3: Rückfragen professionell stellen

Lernzeit: 7 Minuten

Eine gute Rückfrage ist konkret, freundlich und beantwortbar. Sie erklärt kurz, welche Information für die Diagnose benötigt wird.

Ungünstig: „Bitte mehr Informationen senden.“

Besser:

„Danke für die Meldung zu T-104. Welcher Zeitraum ist beim CSV-Export eingestellt? Bitte teile uns außerdem mit, ob Einträge für diesen Zeitraum erwartet werden. Wir prüfen danach das Verhalten in unserer Testumgebung.“

Historische Demo-Oberfläche für die Antwort auf ein Supportticket, Maddin42, CC BY-SA 3.0 / GFDL.

Wichtig: Eine interne Notiz ist nicht automatisch eine Nachricht an die anfragende Person. Unterscheide zwischen interner Dokumentation und externer Kommunikation.

Rückmeldung im Rollenspiel:

„Der Filter steht auf 10.10.2026. Ich möchte aber auch Einträge der Vortage exportieren.“

Neue Information: Möglicherweise begrenzt der Filter die Ausgabe auf einen Zeitraum ohne Einträge. Dies ist zunächst eine Hypothese, noch kein bestätigter Befund.

Lerneinheit 4: Prüfen und die Lösung dokumentieren

Lernzeit: 7 Minuten

Eine erfolgreiche Bearbeitung unterscheidet zwischen Beobachtung, Ursache, Maßnahme und Testergebnis.

Allgemeines Flussdiagramm von Erik Streb, CC BY-SA 3.0. Nutze das Prinzip für Entscheidungen in der Fehleranalyse.

Dokumentation für T-104:

Baustein	Beispiel
Ausgangslage	Der Export zeigt nur die Kopfzeile
Rückfrage	Welcher Zeitraum ist eingestellt?
Beobachtung	Der Filter steht auf 10.10.2026
Vermutete Ursache	Der gewählte Zeitraum enthält keine Übungsdatensätze
Maßnahme	Filter im lokalen Test auf „alle“ umstellen
Test	CSV-Export erneut durchführen
Ergebnis	Drei fiktive Datensätze werden ausgegeben
Abschluss	Nach Bestätigung im Rollenspiel schließen

Wichtige Unterscheidung: Ein erfolgreicher Test belegt das beobachtete Ergebnis in der Testumgebung. Er beweist nicht automatisch, dass jedes denkbare technische Problem ausgeschlossen ist.

Ein Beispiel für einen strukturierten Korrespondenzablauf aus dem OTRS-Umfeld, Cary Bass, CC BY-SA 3.0. Es ist kein allgemeingültiger ITIL-Workflow.

Mini-Aufgabe – Anwendung: Eine Kollegin schreibt nur „Problem behoben“. Verbessere den Eintrag.

Feedback und Begründung anzeigen

Muster: „In der lokalen Testumgebung enthielt der Filter 10.10.2026 keine Datensätze. Mit der Auswahl ‚alle‘ wurden drei vorhandene Testeinträge exportiert. Der Export wurde erneut geprüft und war erfolgreich.“

Diese Dokumentation ist besser, weil sie Ursache, Maßnahme und überprüfbares Ergebnis enthält.

Lerneinheit 5: Lokales Testlabor mit Python

Lernzeit: 15 Minuten

Jetzt überprüfst Du die Hypothese mit echten Programmausgaben, aber ausschließlich fiktiven Daten.

Voraussetzung: Python 3.9 oder neuer. Es werden nur Module aus der Python-Standardbibliothek verwendet.

Isolationskonzept: Die Übung benötigt keinen Server, keine Installation zusätzlicher Pakete und keine Internetverbindung. Der CSV-Inhalt entsteht nur im Arbeitsspeicher.

Labor A: CSV-Export testen

Speichere diesen vollständigen Code lokal als export_probe.py:

import csv
import io

daten = [
    {"tag": "2026-10-08", "eintrag": "Demo-A"},
    {"tag": "2026-10-08", "eintrag": "Demo-B"},
    {"tag": "2026-10-09", "eintrag": "Demo-C"}
]

def auswahl(filterwert):
    return [d for d in daten
            if filterwert == "alle" or d["tag"] == filterwert]

def export(filterwert):
    puffer = io.StringIO()
    schreiber = csv.DictWriter(puffer, fieldnames=("tag", "eintrag"))
    schreiber.writeheader()
    schreiber.writerows(auswahl(filterwert))
    return puffer.getvalue()

assert len(auswahl("2026-10-10")) == 0
assert len(auswahl("alle")) == 3
assert len(export("alle").splitlines()) == 4

print("Filter 2026-10-10:", len(auswahl("2026-10-10")))
print("Filter alle:", len(auswahl("alle")))
print(export("alle"), end="")

Start im lokalen Terminal:

python3 -I -B export_probe.py

Unter Windows ist alternativ py -I -B export_probe.py möglich.

Erwartetes Ergebnis:

Filter 2026-10-10: 0
Filter alle: 3
tag,eintrag
2026-10-08,Demo-A
2026-10-08,Demo-B
2026-10-09,Demo-C

Testauswertung: Drei `assert`-Anweisungen prüfen die Filterauswahl und den erzeugten CSV-Inhalt. Schlägt eine Prüfung fehl, beendet Python die Ausführung mit einem Fehler.

Feedback: Die Kopfzeile zählt nicht als Nutzdatensatz. Der Datumsfilter liefert null Datensätze, die Auswahl „alle“ dagegen drei. Damit ist das Verhalten im lokalen Beispiel reproduziert.

Labor B: Interaktiver Ticket-Simulator

In diesem Labor steuerst Du den Ticketstatus selbst. Das Programm speichert den Verlauf ausschließlich in einer SQLite-Datenbank im Arbeitsspeicher.

Speichere den Code als ticketlabor.py:

import sqlite3

regeln = {
    "Neu": ("In Bearbeitung",),
    "In Bearbeitung": ("Rückfrage", "Gelöst"),
    "Rückfrage": ("In Bearbeitung",),
    "Gelöst": ("In Bearbeitung", "Geschlossen"),
    "Geschlossen": ()
}

db = sqlite3.connect(":memory:")
db.execute(
    "CREATE TABLE verlauf "
    "(nr INTEGER PRIMARY KEY, status TEXT, notiz TEXT)"
)
db.execute(
    "INSERT INTO verlauf(status, notiz) VALUES (?, ?)",
    ("Neu", "T-104: CSV-Export zeigt keine Datensätze")
)
status = "Neu"

while status != "Geschlossen":
    print("\nAktuell:", status)
    print("Erlaubt:", ", ".join(regeln[status]))
    ziel = input("Neuer Status (oder ende): ").strip()

    if ziel.lower() == "ende":
        break

    if ziel not in regeln[status]:
        print("Feedback: Übergang nicht erlaubt.")
        continue

    notiz = input("Notiz: ").strip()

    if not notiz:
        print("Feedback: Dokumentation ist Pflicht.")
        continue

    if ziel == "Rückfrage" and not notiz.startswith("Frage:"):
        print("Feedback: Bitte mit 'Frage:' beginnen.")
        continue

    if ziel == "Gelöst" and not all(
        x in notiz for x in
        ("Test:", "Ursache=", "Maßnahme=", "Ergebnis=")
    ):
        print("Feedback: Test, Ursache, Maßnahme "
              "und Ergebnis fehlen.")
        continue

    if ziel == "Geschlossen" and not notiz.startswith(
        "Bestätigung:"
    ):
        print("Feedback: Bestätigung dokumentieren.")
        continue

    db.execute(
        "INSERT INTO verlauf(status, notiz) VALUES (?, ?)",
        (ziel, notiz)
    )
    status = ziel

print("\nTicketverlauf T-104:")
for nr, zustand, text in db.execute(
    "SELECT nr, status, notiz FROM verlauf ORDER BY nr"
):
    print(f"{nr}. {zustand}: {text}")

db.close()

Start:

python3 -I -B ticketlabor.py

Teste diese Statusfolge:

In Bearbeitung – Notiz: „Sichtung: Zeitraum unbekannt“
Rückfrage – Notiz: „Frage: Welcher Zeitraum ist eingestellt?“
In Bearbeitung – Notiz: „Rückmeldung: Filter steht auf 10.10.2026“
Gelöst – Notiz: „Test: Ursache=Filter heute; Maßnahme=alle; Ergebnis=3 Zeilen“
Geschlossen – Notiz: „Bestätigung: Lösung im Rollenspiel bestätigt“

Experimentiere: Versuche einmal, unmittelbar von „Neu“ nach „Geschlossen“ zu wechseln. Versuche danach, „Gelöst“ ohne Testergebnis zu setzen.

Feedback zur Testumgebung anzeigen

Der Simulator weist beide Aktionen zurück. Die Übergangsregeln verhindern einen unzulässigen Statuswechsel, die Dokumentationsregeln einen unvollständigen Lösungsvermerk.

Eine Software kann prüfen, ob Pflichtangaben vorhanden sind. Ob diese Angaben sachlich wahr sind, muss weiterhin fachlich kontrolliert werden.

Die Datenbank existiert ausschließlich im Arbeitsspeicher und verschwindet nach Programmende. Der Python-Modus `-I` reduziert Einflüsse der Python-Umgebung, ist jedoch keine vollständige Betriebssystem-Sandbox.

Lerneinheit 6: Automatisierung und visualisierte Daten

Lernzeit: 10 Minuten

Mit Automatisierung lassen sich wiederkehrende Vorgänge zuverlässig unterstützen. Beispielsweise können Tickets mit ausstehender Rückfrage für eine Wiedervorlage markiert werden.

Eine sichere Automatisierungsregel benötigt: Auslöser, Bedingung, Aktion, Nachweis und Kontrolle.

Beispiel: Liegt seit zwei Tagen eine Rückfrage ohne Antwort vor, zeigt das Übungssystem eine interne Erinnerung an. Es sendet keine Nachricht an eine echte Person.

Lokaler Automatisierungstest

Speichere den folgenden Code als wiedervorlage.py:

from datetime import date

stichtag = date(2026, 10, 10)

tickets = [
    {"id": "T-104", "status": "Rückfrage",
     "seit": "2026-10-08"},
    {"id": "T-105", "status": "In Bearbeitung",
     "seit": "2026-10-07"},
    {"id": "T-106", "status": "Rückfrage",
     "seit": "2026-10-10"}
]

for ticket in tickets:
    alter = (
        stichtag - date.fromisoformat(ticket["seit"])
    ).days

    if ticket["status"] == "Rückfrage" and alter >= 2:
        print("Interne Wiedervorlage:", ticket["id"])

Start:

python3 -I -B wiedervorlage.py

Erwartete Ausgabe:

Interne Wiedervorlage: T-104

Begründetes Feedback: T-104 erfüllt beide Bedingungen. T-105 ist zwar älter, wartet aber nicht auf eine Rückfrage. T-106 befindet sich erst seit dem Stichtag in diesem Status.

Im Programm wird nichts versendet oder an einem echten Ticket verändert.

Datenauswertung als Statusdiagramm

Fiktiver Ticketbestand einer Übungswoche:

Status	Tickets	Diagramm
Neu	2	██
In Bearbeitung	1	█
Rückfrage	2	██
Gelöst	3	███
Gesamt	8	████████

Ein Block entspricht einem fiktiven Ticket. Die Zahlen sind ausschließlich Beispieldaten.

Analysiere: Zwei von acht Tickets warten auf Rückmeldungen. Das sind 25 Prozent. Die Kennzahl allein sagt jedoch noch nicht, ob es zu viele Rückfragen gibt: Entscheidend sind auch Wartezeit, Qualität und Ursachen.

Service-Desk-Prozess als Ereignisgraph, Drgwag, CC BY-SA 4.0. Vertiefung: Auch Bearbeitungsprozesse lassen sich als Abläufe modellieren.

Mini-Aufgabe – Transfer: Eine automatische Regel schließt alle Tickets nach zwei Tagen ohne Antwort. Beurteile diese Regel.

Feedback und Begründung anzeigen

Die Regel ist riskant. Eine fehlende Antwort beweist weder die Behebung noch die Zustimmung. Besser ist eine dokumentierte Wiedervorlage mit klarer Zuständigkeit. Ein automatisches Schließen dürfte nur nach ausdrücklich festgelegten und autorisierten Regeln erfolgen.

Gestufte Hilfen für den Ausbildungsfall

Nutze zuerst nur die erste Hilfe. Öffne weitere Hilfen, wenn Du nicht weiterkommst.

Hilfe 1 – Orientierung

Frage Dich: Was ist beobachtet, und welche Information fehlt? Unterscheide die Meldung „CSV ist leer“ von der Hypothese „Filter ist falsch“.

Hilfe 2 – Vorgehen

Dokumentiere den Eingang, beginne mit der Analyse, stelle die Frage nach dem Zeitraum, teste anschließend beide Filter in der lokalen Simulation und halte die Unterschiede fest.

Hilfe 3 – Musterlösung

Statusfolge: Neu → In Bearbeitung → Rückfrage → In Bearbeitung → Gelöst → Geschlossen.

Lösungsnotiz: „Der gewählte Zeitraum 10.10.2026 enthielt in der Übung keine Einträge. Der Export mit Filter ‚alle‘ lieferte drei Datensätze. Beide Ergebnisse wurden mit lokalen Testdaten nachvollzogen. Eine Schließung erfolgt erst nach dokumentierter Bestätigung im Rollenspiel.“

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Wozu dient eine Ticket-ID? (Zur eindeutigen Zuordnung eines Vorgangs) (!Zum automatischen Beheben aller Fehler) (!Zum Ersetzen einer Fehlerbeschreibung) (!Zum Speichern eines Passworts)

Was bedeutet der Status Rückfrage im Übungsworkflow? (Eine benötigte Information fehlt noch) (!Der Vorgang wurde endgültig abgeschlossen) (!Eine Lösung wurde erfolgreich getestet) (!Das Ticket darf gelöscht werden)

Welche Rückfrage hilft beim Fall T-104 am meisten? (Welcher Zeitraum ist eingestellt) (!Warum funktioniert bei Ihnen nichts) (!Können Sie bitte alles neu installieren) (!Kennen Sie Ihr Passwort noch)

Was sollte vor dem Status Gelöst vorliegen? (Ein dokumentiertes positives Testergebnis) (!Eine unbelegte Vermutung) (!Eine gelöschte Ticketbeschreibung) (!Eine automatische Eskalation)

Welche Angaben machen eine Lösung nachvollziehbar? (Ursache Maßnahme und Ergebnis) (!Nur der Name des Bearbeiters) (!Nur eine allgemeine Erfolgsmeldung) (!Nur das Erstellungsdatum)

Wann wird T-104 im Übungsworkflow geschlossen? (Nach dokumentierter Bestätigung) (!Direkt nach dem Eingang) (!Sobald eine Rückfrage gesendet wurde) (!Allein wegen einer langen Wartezeit)

Warum zeigt der Export für den Übungstag keine Datensätze? (Die Beispieldaten liegen außerhalb des gewählten Datums) (!Die CSV Bibliothek löscht automatisch alle Einträge) (!Python benötigt einen Internetzugang) (!Die Ticketnummer ist zu kurz)

Was bewirkt die SQLite Angabe memory im gezeigten Code? (Die Datenbank liegt nur im Arbeitsspeicher) (!Die Daten werden in eine Cloud übertragen) (!Die Daten werden an echte Kunden verschickt) (!Alle Dateien auf dem Computer werden gelöscht)

Welche Automatisierung ist im lokalen Übungsfall sinnvoll? (Eine interne Wiedervorlage für wartende Tickets) (!Ungeprüfte Änderungen an Produktivservern) (!Automatisches Veröffentlichen von Kundendaten) (!Ungefragtes Versenden von Zugangsdaten)

Was bedeutet Datenminimierung? (Nur für den Zweck notwendige Daten verarbeiten) (!Möglichst viele personenbezogene Daten speichern) (!Alle Protokolle öffentlich veröffentlichen) (!Sämtliche Zugangsdaten in Tickets eintragen)

Memory

Ordne jedem Fachbegriff seine passende Bedeutung zu.

Ticket-ID	Eindeutige Vorgangskennung
Status	Bearbeitungszustand
Rückfrage	Bitte um fehlende Angaben
Verlauf	Chronologische Dokumentation
Testnachweis	Beobachtetes Prüfergebnis
Eskalation	Übergabe an zuständige Stelle
Wiedervorlage	Erinnerung an offene Arbeit
Datenminimierung	Beschränkung auf notwendige Informationen

Drag and Drop

Ordne die Statusbegriffe den typischen Schritten des vereinfachten Übungsworkflows zu.

Ordne die richtigen Begriffe zu.	Bearbeitungsschritt
Neu	Erfassung
In Bearbeitung	Analyse
Rückfrage	Klärung
Gelöst	Erfolgskontrolle
Geschlossen	Abschlussbestätigung

Kreuzworträtsel

Ticket	Wie nennt man einen einzelnen dokumentierten Supportvorgang?
Status	Welches Feld zeigt den aktuellen Bearbeitungszustand?
Filter	Welche Einstellung begrenzt die angezeigten Datensätze?
Verlauf	Wie heißt die chronologische Dokumentation eines Vorgangs?
Nachweis	Was belegt die Durchführung einer erfolgreichen Prüfung?
Eskalation	Wie heißt die Weitergabe an eine zuständigere Bearbeitungsebene?

LearningApps

Optionale Suche nach ergänzenden Lernspielen. Nutze externe Angebote nur, wenn ihre Verwendung ausdrücklich erlaubt ist, und gib keine echten Ticket- oder Kundendaten ein.

Lückentext

Ein IT-Service-Vorgang erhält eine eindeutige

.

Der aktuelle Bearbeitungszustand wird als

bezeichnet.

Wenn eine notwendige Information fehlt, stellst Du eine

.

Die eingestellte Zeitraumauswahl wird im Beispiel als

bezeichnet.

Der simulierte Export ohne passende Einträge enthält nur die

.

Eine angenommene Fehlerursache heißt zunächst

.

Die technische Prüfung dokumentierst Du mit einem

.

Die chronologische Aufzeichnung aller Schritte heißt

.

Eine interne Erinnerung an offene Aufgaben ist eine

.

Die lokale SQLite-Datenbank wird ausschließlich im

erstellt.

Für die Übungen dürfen ausschließlich fiktive

verwendet werden.

Der dokumentierte Abschluss eines Tickets wird als

bezeichnet.

Offene Aufgaben

Bearbeite die Aufgaben in steigender Schwierigkeit. Alle technischen Experimente bleiben auf die lokale, fiktive Lernumgebung beschränkt.

Leicht – Basisaufgaben

Ticketbeschreibung: Erstelle für T-104 eine verständliche Kurzbeschreibung mit Beobachtung, Auswirkung und fehlender Information.
Ticketstatus: Zeichne die sechs Stationen des Übungsworkflows als einfaches Ablaufdiagramm.
Kundenkommunikation: Formuliere eine freundliche und konkrete Rückfrage zum Zeitraumfilter.
Dokumentation: Schreibe eine Lösungsnotiz mit Ausgangslage, Maßnahme und Testergebnis.

Standard – Anwendungsaufgaben

Fehleranalyse: Führe das lokale CSV-Programm aus und vergleiche die Ergebnisse der beiden Filter.
Python: Ergänze im Ticket-Simulator eine neue erlaubte Rückkehr von „Gelöst“ nach „In Bearbeitung“ und beschreibe einen sinnvollen Anwendungsfall.
Datenvisualisierung: Erstelle aus acht fiktiven Tickets ein eigenes Balkendiagramm mit einer kurzen Interpretation.
Softwaretest: Entwickle drei positive und drei negative Testfälle für eine Statusänderung und protokolliere die erwarteten Ergebnisse.

Schwer – Transferaufgaben

Workflow-Management: Entwirf einen Ticketprozess mit Eskalation, Zuständigkeiten und überprüfbarem Abschluss.
Prozessautomatisierung: Erweitere das lokale Wiedervorlageprogramm um einen zweiten Grenzwert und begründe, wann eine Erinnerung entsteht.
Datenschutz: Untersuche eine fiktive Ticketbeschreibung mit unnötigen persönlichen Angaben und erstelle eine datensparsame Fassung.
IT-Service-Management: Entwickle ein kleines Verbesserungskonzept, das Rückfragen reduziert, ohne vorschnell Tickets zu schließen.

Aufgabenfeedback und Bewertung

Kompetenzstufe	Erwartete Leistung	Begründetes Feedback
Basis	Sachverhalt und Status korrekt beschreiben	Verständliche Angaben vermeiden Missverständnisse und machen Übergaben möglich
Anwendung	Lokale Tests durchführen und Ergebnisse dokumentieren	Reproduzierbare Beobachtungen sind belastbarer als bloße Vermutungen
Transfer	Automatisierungsregeln samt Risiken und Kontrollen beurteilen	Eine effiziente Regel ist nur sinnvoll, wenn sie fachlich richtig, prüfbar und autorisiert ist

Selbstkontrolle: Begründe bei jeder Aufgabe nicht nur Deine Entscheidung, sondern auch, warum eine naheliegende Alternative weniger geeignet ist.

Lernkontrolle

Diese Aufgaben prüfen Zusammenhänge und Transferleistungen statt isoliertem Faktenwissen.

Ursachenanalyse: Ein Ticket wurde als gelöst markiert, obwohl keine Prüfung vorliegt. Erkläre mögliche Folgen für die betroffene Person und das IT-Service-Team.
Kommunikationsqualität: Vergleiche zwei Rückfragen, eine allgemeine und eine konkrete. Begründe, welche schneller zu einer belastbaren Diagnose führt.
Workflow: Entwirf einen Fall, in dem ein bereits gelöstes Ticket erneut in Bearbeitung genommen werden muss. Formuliere geeignete Übergangsregeln.
Automatisierungsrisiko: Beurteile die automatische Schließung unbeantworteter Tickets. Entwickle eine risikoärmere Alternative mit dokumentierter Entscheidung.
Prozessverbesserung: In einer fiktiven Woche warten viele Tickets auf Rückmeldungen. Entwickle zwei Hypothesen zur Ursache und beschreibe, welche Daten Du zu ihrer Überprüfung benötigst.
Qualitätssicherung: Übertrage das Vorgehen von T-104 auf eine fiktive Software-Installationsanfrage. Trenne notwendige Genehmigung, Durchführung und Funktionsprüfung.

Lernnachweis

Für einen erfolgreichen Lernnachweis erstellst Du eine kompakte Ticket-Projektmappe mit ausschließlich fiktiven Informationen.

Ein vollständig beschriebenes Ticket mit eindeutiger Kennung.
Ein Ablaufdiagramm mit erlaubten Statusübergängen.
Eine begründete Rückfrage und die dazugehörige simulierte Antwort.
Eine Lösungsdokumentation mit Befund, Maßnahme und Testnachweis.
Die lokale Ausführung des CSV-Tests einschließlich der überprüften Ergebnisse.
Einen nachvollziehbaren Ticketverlauf aus dem interaktiven Simulator.
Eine Visualisierung des fiktiven Ticketbestands mit kurzer Interpretation.
Eine Automatisierungsregel mit Testfällen, Grenzen und Risikoabwägung.
Eine Reflexion darüber, welche Arbeitsschritte menschliche Prüfung und ausdrückliche Berechtigung benötigen.

Bewertungskriterien: fachliche Richtigkeit, Nachvollziehbarkeit, Testqualität, Verständlichkeit, Datenschutz und begründete Entscheidungen.

OERs zum Thema

Wikipedia-Grundlagen: Issue-Tracking-System, IT-Service-Management, Workflow-Management, Prozessmanagement, Softwaretest und Datenschutz.

Geprüfte fachliche Quellen

Wikipedia: Issue-Tracking-System – Grundlagen und Funktionen von Ticketsystemen.
Atlassian: IT-Service-Management – Einordnung von Serviceanfragen, Incidents und Problemmanagement.
Atlassian: Incident-Management-Prozess – Dokumentation, Statuskommunikation, Eskalation und Nachbereitung. Der Ablauf für Großvorfälle wird hier nicht als universeller Standard für einfache Tickets verwendet.
Atlassian Support: Ticket-Warteschlangen – Strukturierung und Bearbeitung eingehender Anfragen.
Python-Dokumentation: sqlite3 – SQLite-Datenbank im Arbeitsspeicher.
Python-Dokumentation: unittest – Grundlagen automatisierter Tests.
Datenschutz-Grundverordnung, Artikel 5 – insbesondere Datenminimierung und Zweckbindung.

Bildquellen und Nutzungsrechte

Alle aufgeführten Bilddateien wurden auf Wikimedia Commons gefunden. Urheberangaben und Lizenzen gelten jeweils gemäß der verlinkten Dateiseite.

Otrs-2.0.4-queueview.png – Maddin42; GPL Version 2 oder später; historischer Demo-Screenshot.
Abstract Kanban Board.svg – Jennifer Falco; CC BY 4.0.
Kanban board.png – Garbanea; CC BY-SA 4.0.
Otrs-2.0.4-answer.png – Maddin42; CC BY-SA 3.0 / GFDL; historischer Demo-Screenshot.
Flowchart de.svg – Erik Streb; CC BY-SA 3.0.
Complaint flowchart.svg – Cary Bass; CC BY-SA 3.0.
Service Desk Event Graph.svg – Drgwag; CC BY-SA 4.0.

YouTube-Quellen:

ITSM Request Portal in Jira Service Management – Atlassian, 2021.
Jira Service Management Queues | Explained in 6 Minutes – Hean Tech, 2025.

Rechtehinweis: YouTube-Videos sind externe Lernmedien, nicht automatisch frei lizenzierte OER. Für eine weitergehende Wiederverwendung gelten die Rechte der jeweiligen Urheber. Externe Medien und iFrames können beim Aufruf Verbindungen zu Drittanbietern auslösen. Die lokalen Codeübungen übertragen dagegen keine Daten an externe Dienste.