In dieser Sektion wird angezeigt, ob das aktuelle Ticket über- oder untergeordnet verknüpft ist (Haupt-/Teil-Ticket). Verknüpfungen lassen sich über die Schaltflächen rechts neben den Feldern erstellen („+“ = bestehendes Ticket auswählen, „★“ = neues Ticket mit direkter Haupt-/Teil-Verknüpfung). Liegt noch keine Beziehung vor, wird die Sektion zunächst ausgeblendet; die erste Verknüpfung erfolgt über das Aktionsmenü bzw. die Schnellaktion.
|
Hinweis: Der Zustandsabgleich läuft (modellabhängig) bis „Erledigung“. Nach Wiedereröffnung erfolgt kein automatischer Weiterabgleich; weitere Verarbeitung wird manuell bzw. gemäß der Regeln erneut ausgelöst. |
Grundprinzip der Ticketbeziehungen in OMNITRACKS
1.Hierarchische Struktur
oEin Ticket ist entweder Hauptticket (Master) oder Teilticket (Slave) – nicht beides.
oMehrstufige Hierarchien sind nicht unterstützt (genau eine Ebene).
2.Beziehungsfelder
oBeziehungen werden über „Untergeordnete Tickets“ und „Übergeordnetes Ticket“ abgebildet.
3.Verhaltensmodell-Steuerung
oDas Verhaltensmodell wird im Dropdown „Master-Slave-Verknüpfung“ festgelegt.
oWerte: „Keine“, „Hauptticket erledigt Teiltickets“, „Teiltickets erledigen Hauptticket“.
4.Ermittlung des maßgeblichen Verhaltensmodells
oWenn ein übergeordnetes Ticket vorhanden ist, gilt dessen Wert in „Master-Slave-Verknüpfung“ als maßgeblich.
oWenn kein übergeordnetes Ticket vorhanden ist, gilt der Wert des aktuellen Tickets als maßgeblich.
5.Synchronisationsauslöser
oEine Synchronisation wird angestoßen, wenn sich im Kontext der Beziehung relevante Daten ändern, z. B.
▪Zustandsänderung am Master bei „Hauptticket erledigt Teiltickets“,
▪Abschluss eines Slave bei „Teiltickets erledigen Hauptticket“.
Gesamter Ablauf (gilt für alle Verhaltensmodelle)
1.Verhaltensmodell setzen
oVor der Anlage des Tickets: Wenn ein Ticket mit Typ angelegt wird, wird das Verhaltensmodell aus dem Typ übernommen.
oIm Moment des Speicherns, nachdem ein bestehendes Ticket verändert wurde: Wenn zunächst ohne Typ angelegt wurde und später ein Typ zugeordnet wird, wird das Verhaltensmodell dann gesetzt.
oDie initiale Zuordnung ist endgültig; die Typ-Angabe ist Voraussetzung für die Bearbeitung.
2.Rollenkennzeichen setzen (intern)
oAb der ersten Modifikation und nur bei Änderungen an „Übergeordnetes Ticket“ oder „Untergeordnete Tickets“ werden die Rollen intern aktualisiert.
3.Prüfung auf synchronisationsrelevantes Verhalten
oEntfällt, wenn das maßgebliche Verhaltensmodell „Keine“ ist.
oAndernfalls wird geprüft, ob
▪ein Hauptticket vorliegt und „Hauptticket erledigt Teil-Tickets“ maßgeblich ist, oder
▪ein Teilticket vorliegt und „Teiltickets erledigen Hauptticket“ maßgeblich ist.
oZusätzlich muss Zustand oder Kategorie geändert worden sein.
4.Bereitstellung für Eskalationen
oBei erfüllten Bedingungen wird die Verarbeitung durch Eskalationen gestartet.
Modell-spezifische Abläufe
A) „Hauptticket erledigt Teil-Tickets“ (Master → Slaves) Eskalation vom Teilticket aus: „Master solves Slaves“
Startbedingungen:
•Teilticket-Zustand ≠ „Abgeschlossen“,
•maßgebliches Verhaltensmodell = „Hauptticket erledigt Teil-Tickets“,
•übergeordnetes Ticket vorhanden,
•keine aktive Fehlermarkierung im Teilticket.
Ablauf (Reihenfolge):
1.Set Category – Kategorie des Teiltickets ggf. an das Hauptticket anpassen.
2.Set State – wenn Hauptticket-Zustand ≠ „Erledigung“/„Abgeschlossen“ und vom Teilticket abweicht → Teilticket anpassen.
3.Set Solutiondata – wenn Hauptticket „Erledigung“ oder „Abgeschlossen“ → Übernahme von Abschlusskategorie, Lösungsbeschreibung, Interne Lösungsbeschreibung, Zustand ins Teilticket.
4.Abschlussmarkierung am Teilticket – erfolgreiche Verarbeitung wird intern markiert.
Fehlerbehandlung unbefüllter Pflichtfelder (im Teilticket):
•Bei fehlerhaftem Zustandsübergang (Pflichtfelder fehlen): gewünschter Zielzustand wird intern vermerkt, Hinweis-E-Mail wird ausgelöst, interne Fehlermarkierung verhindert Wiederholungen.
•Formularverhalten (Teilticket):
oBeim Öffnen des Formulars: Status wird im Formular vorschaltet, Pflichtfelder werden markiert.
oBeim Speichern nach Anpassung: ursprünglicher Status wird wiederhergestellt, interne Marker werden geleert.
oAnschließend läuft die Eskalation automatisch weiter und setzt den Status.
Eskalation vom Hauptticket aus: Rücksetzung des Verarbeitungsstatus
•Startbedingungen: Hauptticket mit Teiltickets, die als verarbeitet markiert wurden.
•Aktion: interner Verarbeitungsstatus am Hauptticket wird zurückgesetzt (kein offener Bedarf).
B) „Teiltickets erledigen Hauptticket“ (Slaves → Master) Eskalation vom Hauptticket aus: „Slaves solve Master“
Startbedingungen:
•Hauptticket ≠ „Abgeschlossen“,
•mindestens ein Teilticket vorhanden,
•maßgebliches Verhaltensmodell = „Teiltickets erledigen Hauptticket“,
•Teiltickets liegen zur Verarbeitung vor.
Ablauf (Reihenfolge):
1.Set State Classification – Hauptticket auf „Klassifikation“, wenn alle Teiltickets in „Klassifikation“ stehen.
2.Set State In Progress – Hauptticket auf „Bearbeitung“, wenn alle Teiltickets in „Bearbeitung“ stehen.
3.Set Solutiondata – bei Lösung nur Zustand am Hauptticket setzen; Lösungsbeschreibung als dynamischer Standardtext mit Verweis auf die Teiltickets und deren Lösungsbeschreibungen.
4.Abschlussmarkierung am Hauptticket – erfolgreiche Verarbeitung wird intern markiert.
Eskalation vom Teilticket aus: Rücksetzen der Verarbeitungsmarkierung
•Startbedingungen: aktuelles Ticket ist Teilticket und als verarbeitet markiert; das Hauptticket erwartet den Abschluss.
•Aktion: Verarbeitungsmarkierung am Teilticket wird zurückgesetzt (kein offener Bedarf für dieses Ticket).
C) „Keine“
•Es erfolgt keine Synchronisation; die Beziehung dient ausschließlich der Struktur und Navigation.
|
Anwendungsbeispiele Ticketbeziehungen: Ein typisches ITIL®-Szenario ist die Bündelung vieler gleichartiger Incidents zu einem Hauptticket (z. B. „Major Incident“). Statt jeden Incident separat zu bearbeiten, werden die betroffenen Tickets als Teiltickets dem Hauptticket zugeordnet. Die Bearbeitung und Lösungsdokumentation erfolgt zentral im Hauptticket. Ist das Verhaltensmodell entsprechend konfiguriert („Hauptticket erledigt Teiltickets“), werden die zugeordneten Teiltickets beim Abschluss des Haupttickets automatisch mit abgeschlossen; Benachrichtigungen können systemseitig ausgelöst werden. Ticket-Typen dürfen dabei unterschiedlich sein (Cross-Type-Beziehungen sind möglich).
Für Problem- oder Change-Szenarien kann jeweils ein zentrales Ticket als Hauptticket dienen, dem die betroffenen Incidents direkt als Teiltickets zugeordnet werden. Im Problem wird die Ursache analysiert und behoben; je nach Verhaltensmodell werden entweder mit Abschluss des Problems die zugehörigen Incidents automatisch mit abgeschlossen („Hauptticket erledigt Teiltickets“) oder das Problem geht automatisch in „Erledigung“, sobald alle zugeordneten Incidents gelöst sind („Teiltickets erledigen Hauptticket“). Entsprechend lässt sich ein Change als Hauptticket nutzen, um die Umsetzung von Maßnahmen zu steuern und den Abschluss der Incidents entweder vom Change aus zu übernehmen oder durch den Abschluss aller zugeordneten Incidents auslösen zu lassen. |
