Assets in Jira Service Management modellieren: erst die Entscheidungen, dann das Schema

Der häufigste Fehler: der Prozess vor dem Modell

Wer den Prozess vor dem Modell entwirft, bekommt einen Service Desk, der Arbeit sehr gut dokumentiert, aber keine davon reduziert. Drei Anzeichen verraten das:

• Das Formular denkt mit. Portalfelder fragen den Melder nach Dingen, die das Werkzeug wissen müsste: welches System, welcher Standort, wie dringend. Der Melder rät, und die Vermutung wird zu deinen Daten.

• Die Automation ist fest verdrahtet. Ohne Modell muss eine Regel Dinge beim Namen nennen: Ist der Service Payroll, geht das Ticket an Team A. Aus fünfzig Services werden fünfzig Regeln, und jeder neue Service ist ein Änderungsantrag gegen das eigene Werkzeug.

• Der Agent ist das fehlende Bindeglied. Jemand liest das Ticket, ermittelt das System, erinnert sich an das zuständige Team, setzt eine Priorität und weist neu zu. Dutzende Male am Tag, aus einer Tabelle, die nur in seinem Kopf existiert.

Das ist kein Konfigurationsfehler. Es passiert, wenn du Verhalten entwirfst, bevor die Struktur steht, die dieses Verhalten braucht. Und wer Assets erst nachträglich einführt, zahlt doppelt: Formulare werden kleiner, Regeln fallen weg, Workflows und SLAs werden neu geschnitten, und das alles im laufenden Betrieb.

Vier Entscheidungen statt vierhundert Anforderungen

Modell zuerst heißt nicht, blind zu modellieren. Es heißt, mit den Entscheidungen anzufangen, die das Werkzeug allein treffen soll:

• Wer bekommt dieses Ticket?

• Welches SLA gilt?

• Wer gibt frei?

• Was ist betroffen, wenn sich das hier ändert?

Jede dieser Entscheidungen braucht eine kleine, klar umrissene Menge an Feldern und Beziehungen. Modelliere genau die. Für vier Entscheidungen zu modellieren dauert Wochen. Alles zu modellieren, was ihr besitzt, ist ein Projekt, das nie endet.

In vier Schritten zum Modell, das entscheidet

1. Entscheidungen sammeln, nicht Anforderungen. Was soll das Werkzeug selbst entscheiden?

2. Modellieren, was diese Entscheidungen brauchen. Für das Routing zum Beispiel: betroffener Service, zuständige Supportgruppe, Kritikalität, Service-Tier.

3. Die Prozesse auf dem Modell aufbauen. Der Request Type füllt seine Felder aus Assets, und der Workflow nutzt, was das Objekt schon weiß.

4. Generische Regeln schreiben. Statt „ist der Service Payroll, an Team A mit hoher Priorität“ liest die Regel das Objekt: an die Supportgruppe des betroffenen Services, Priorität aus der Kritikalität, SLA aus dem Service-Tier, Benachrichtigung an den Owner, wenn das Objekt geschäftskritisch ist.

Dasselbe Prinzip trägt weiter: SLA-Ziele ergeben sich aus Objektattributen, sodass ein Produktivsystem und ein Testsystem nie dieselbe Uhr teilen. Eskalation und Genehmigung folgen den Rollen am Objekt. Und mit AQL bietet das Portal dem Melder nur die Objekte an, die er tatsächlich hat.

Beispiel: Routing vorher und nachher

Prozess zuerst: Ein Nutzer meldet eine Störung in eine zentrale Queue. Ein Agent liest, ermittelt das System, erinnert sich an das Team, setzt die Priorität, weist neu zu und eskaliert von Hand. Ein neuer Service heißt: eine neue Regel.

Modell zuerst: Der Nutzer wählt den betroffenen Service aus Assets. Eine Regel liest das Objekt und erledigt den Rest. Keine Triage, keine Neuzuweisung, keine Regel für genau diesen Service. Ein neuer Service heißt: ein neues Objekt.

Daher kommt die Skalierbarkeit. Geht ein neuer Service live, legt jemand das Objekt an und verknüpft es mit dem zuständigen Team, der Kritikalität und dem Tier. Ab dem nächsten Ticket stimmt das Routing, ohne dass jemand eine Regel angefasst hat. Eine Umorganisation funktioniert genauso: Ändere die Beziehung an den Objekten eines Teams, und alle betroffenen Services werden auf einmal umgeleitet.

Rechne mit deinen eigenen Zahlen

Deine Regelzahl: Zähle die Automation-Regeln, die in ihren Bedingungen einen bestimmten Service, ein Team, einen Standort oder ein System nennen. Zähle dann deine Services. Wenn beide Zahlen gemeinsam wachsen, ist deine Logik fest verdrahtet. Bei einem Modell wächst nur die Zahl der Services: Eine Regel deckt zehn Services ab oder vierhundert.

Deine Triagezeit: Nimm die Tickets pro Tag mal die Sekunden, die ein Agent braucht, um System, Owner und Priorität zu ermitteln, bevor die eigentliche Arbeit beginnt. Zur Veranschaulichung: 300 Tickets am Tag mal 90 Sekunden sind 7,5 Stunden am Tag. Das ist mehr als eine volle Stelle für ein Nachschlagen, das das Modell sofort erledigen könnte.

Schon live? So fängst du an

Kaum jemand startet auf der grünen Wiese. Neu anfangen musst du nicht, und du solltest auch nicht den gesamten Bestand modellieren, bevor du ein Ergebnis siehst.

• Eine Entscheidung wählen, nicht ein Schema. Routing ist meist die erste Wahl: Die Wirkung ist innerhalb einer Woche sichtbar, und die nötigen Daten sind überschaubar.

• Neben der alten Logik laufen lassen. Pilotiere mit einer Servicegruppe: die generische Regel live, die alten Regeln noch als Rückfallebene. Vergleichen, dann die alten Regeln für diese Gruppe abschalten.

• Entfernte Regeln berichten. „Abgeschaltete Regeln“ ist der deutlichste Beleg dafür, dass das Modell die Arbeit macht.

• Das Modell für die nächste Entscheidung nutzen. SLA, Freigaben und Change Impact lesen weitgehend dieselben Objekte. Die zweite Entscheidung kostet nur einen Bruchteil der ersten.

Und dann gib dem Modell einen Owner. Jeder Objekttyp braucht eine benannte verantwortliche Person, eine führende Datenquelle, einen Lebenszyklus von der Beschaffung bis zur Ausmusterung und einen Termin für die nächste Prüfung. Datenqualität ist keine Phase, sondern eine Aufgabe.

Fünf Fragen: Entscheidet dein Modell oder beschreibt es nur?

1. Findet eine Regel die richtige Zuweisungsgruppe über den betroffenen Service, ohne diesen Service beim Namen zu nennen?

2. Kommt dein SLA aus dem Objekt oder aus dem, was der Melder ausgewählt hat?

3. Wenn du einen neuen Service anlegst: Änderst du Daten oder eine Regel?

4. Hat jeder Objekttyp einen benannten Owner und eine führende Datenquelle?

5. Wann hat ein Objekt zuletzt seinen Status geändert, ohne dass jemand es von Hand bearbeitet hat?

Sind drei oder mehr Antworten wackelig, beschreibt dein Modell, aber es entscheidet nicht.

Der Asset Scheme Blueprint

Unser Asset Scheme Blueprint ist eine dokumentierte Bibliothek von JSM-Anwendungsfällen für Routing, SLA, Freigaben und Change, entstanden aus echten Projekten. Du passt ein funktionierendes Modell an, statt eine CMDB von null zu entwerfen. Whitepaper und Blueprint gibt es kostenlos.

Warum ein Service Desk dabei auch als Betriebsmodell gedacht werden muss, beschreiben wir in Jira Service Management als Betriebsmodell .