Jira Service Management Portalstruktur – Request Types, Portalsicht und interne Jira-Konfiguration richtig verstehen

Das Serviceportal ist nicht Jira – und genau das ist seine größte Stärke

Viele Unternehmen investieren viel Zeit in Workflows, Felder und Automatisierungen. Das eigentliche Serviceportal wird dagegen häufig erst kurz vor dem Go-live gestaltet. Dabei entscheidet genau diese Oberfläche darüber, wie Anwender den Service wahrnehmen.

Ein modernes Serviceportal sollte nicht die interne Struktur der IT widerserspiegeln. Es sollte die Sprache der Anwender sprechen.

Niemand möchte einen Issue Type erstellen, einen Workflow starten oder ein Screen Scheme ausfüllen. Anwender möchten einen Laptop bestellen, einen Softwarefehler melden oder einen Zugriff beantragen.

Genau deshalb trennt Jira Service Management konsequent zwischen der internen Jira-Welt und der Sicht des Kunden. Beide arbeiten mit demselben Vorgang – sehen jedoch völlig unterschiedliche Informationen.

Diese Trennung gehört zu den wichtigsten Konzepten von Jira Service Management und ist gleichzeitig eine der häufigsten Ursachen für unnötig komplexe Serviceportale.

Zwei Sichten auf denselben Vorgang

Ein Jira-Vorgang besitzt immer zwei Perspektiven.

Die erste richtet sich an den Kunden.

Hier stehen Übersichtlichkeit, einfache Formulare und verständliche Bezeichnungen im Vordergrund.

Die zweite richtet sich an Agenten und Administratoren.

Hier geht es um Prozesse, Workflows, Berechtigungen, Automatisierungen und technische Informationen.

Kundenportal	Interne Jira-Ansicht
Serviceportal	Jira-Projekt
Request Types	Issue Types
Request Form	Jira Screens
Kundenstatus	Workflow-Status
Customer Notifications	Notification Scheme
Einfache Sprache	Technische Konfiguration

Beide Ansichten greifen auf denselben Jira-Vorgang zu. Sie verfolgen jedoch unterschiedliche Ziele.

Ein gut aufgebautes Serviceportal macht diese technische Komplexität für Anwender vollständig unsichtbar.

Wie eine Anfrage tatsächlich entsteht

Viele Administratoren denken zunächst in Jira-Projekten.

Für den Anwender beginnt der Prozess jedoch deutlich früher.

Stellen wir uns vor, ein Mitarbeiter benötigt einen neuen Laptop.

Er öffnet das Serviceportal und findet dort den Service „Neuen Laptop bestellen“.

Das Formular fragt lediglich die Informationen ab, die für die Bestellung notwendig sind.

Nach dem Absenden passiert im Hintergrund deutlich mehr, als der Anwender sieht.

Der Request Type erzeugt einen Jira-Vorgang, weist diesem einen Issue Type zu und startet den passenden Workflow. Gleichzeitig greifen sämtliche projektbezogenen Konfigurationen wie Berechtigungen, Automatisierungen, SLA-Regeln oder Benachrichtigungen.

Für den Anwender bleibt dieser technische Ablauf vollständig verborgen.

Genau diese Entkopplung macht Jira Service Management so flexibel.

Das Serviceportal bildet Services ab – keine Organisationsstrukturen

Ein häufiger Fehler besteht darin, das Portal nach internen Verantwortlichkeiten aufzubauen.

Beispielsweise:

• Infrastruktur

• Netzwerk

• Workplace

• SAP

• Active Directory

• 
  

Aus Sicht der IT mag diese Struktur logisch erscheinen.

Für einen Mitarbeiter jedoch nicht.

Er kennt meist weder die Zuständigkeiten noch die interne Organisation.

Ein gutes Serviceportal orientiert sich deshalb ausschließlich an den angebotenen Leistungen.

Zum Beispiel:

Arbeitsplatz

• Neuen Laptop bestellen

• Zusätzlichen Monitor bestellen

• Maus oder Tastatur austauschen

Software

• Software installieren

• Microsoft Visio bestellen

• Adobe Acrobat beantragen

Zugriffe

• SAP-Zugriff beantragen

• VPN-Zugang anfordern

• Shared Folder freischalten

Anwender suchen nach Lösungen für ihr Anliegen – nicht nach der verantwortlichen Abteilung.

Request Types und Issue Types erfüllen unterschiedliche Aufgaben

Kaum ein Thema führt häufiger zu Missverständnissen als diese beiden Begriffe.

Dabei unterscheiden sie sich grundlegend.

Der Issue Type

Der Issue Type gehört zur technischen Jira-Konfiguration.

Er definiert unter anderem:

• den Workflow

• Screen Schemes

• Automatisierungen

• SLA-Konfigurationen

• Auswertungen

• Berechtigungen

Issue Types dienen der internen Verarbeitung.

Typische Beispiele sind:

• Incident

• Service Request

• Change

• Problem

Der Kunde bekommt diese Klassifizierung normalerweise nie zu Gesicht.

Der Request Type

Der Request Type gehört ausschließlich zum Serviceportal.

Er beschreibt einen konkreten Service, den Anwender auswählen können.

Zum Beispiel:

Request Type	Zugeordneter Issue Type
Neuen Laptop bestellen	Service Request
Software installieren	Service Request
SAP-Zugriff beantragen	Service Request
Passwort zurücksetzen	Service Request
VPN funktioniert nicht	Incident
Outlook startet nicht	Incident

Mehrere Request Types können also denselben Issue Type verwenden.

Dadurch lassen sich Portale sehr übersichtlich gestalten, ohne die technische Konfiguration unnötig aufzublähen.

Weniger Issue Types bedeuten meist eine bessere Architektur

Gerade bei neuen Einführungen entsteht häufig der Wunsch, für jeden Service einen eigenen Issue Type anzulegen.

Aus der Praxis ist das selten sinnvoll.

Anstatt zwanzig verschiedener Issue Types wie

• Laptop

• Monitor

• Smartphone

• Software

• SAP

• Office

• Drucker

reichen häufig wenige technische Kategorien vollkommen aus.

Zum Beispiel:

• Incident

• Service Request

• Change

• Problem

Die eigentliche Differenzierung erfolgt anschließend über Request Types.

Dadurch bleiben Workflows, Schemas und Automatisierungen deutlich einfacher wartbar.

Request Forms bilden die eigentliche Benutzeroberfläche

Der Request Type definiert gleichzeitig das Formular, das Kunden im Portal sehen.

Hier entscheidet sich, welche Informationen wirklich benötigt werden.

Ein gutes Formular konzentriert sich ausschließlich auf die Angaben, die für die Bearbeitung erforderlich sind.

Ein typisches Formular für einen Laptop könnte beispielsweise enthalten:

• Gerätetyp

• Standort

• Kostenstelle

• Begründung

Intern arbeiten Agenten später mit deutlich mehr Informationen.

Zusätzliche Felder wie

• Asset

• Lieferant

• Bestellnummer

• Beschaffungsstatus

• Einkauf

• Inventarnummer

werden erst während der Bearbeitung ergänzt.

Dadurch bleibt das Portal übersichtlich, während intern alle notwendigen Informationen dokumentiert werden können.

Request Form und Jira Screen sind zwei unterschiedliche Konzepte

Auch diese beiden Begriffe werden häufig verwechselt.

Ein Request Form richtet sich ausschließlich an den Kunden.

Ein Jira Screen richtet sich an Bearbeiter.

Obwohl beide dieselben Felder verwenden können, verfolgen sie unterschiedliche Ziele.

Request Form	Jira Screen
Für Kunden optimiert	Für Agenten optimiert
Wenige Eingaben	Vollständige Bearbeitung
Fachliche Sprache	Technische Informationen
Hilfetexte	Administrationsfelder
Übersichtlichkeit	Prozesssteuerung

Diese Trennung ermöglicht eine deutlich bessere Benutzererfahrung auf beiden Seiten.

Warum Kunden andere Status sehen sollten

Ein Workflow kann intern problemlos zehn oder mehr Bearbeitungsschritte enthalten.

Beispielsweise:

• Neu

• Analyse

• 2nd Level Support

• Hersteller

• Beschaffung

• Installation

• Qualitätssicherung

• Dokumentation

• Freigabe

• Abgeschlossen

Für den Kunden besitzen viele dieser Schritte jedoch keinerlei Mehrwert.

Deshalb können mehrere Workflow-Status zu einem gemeinsamen Portalstatus zusammengefasst werden.

Im Serviceportal erscheinen dann beispielsweise lediglich:

• Offen

• In Bearbeitung

• Warten auf Rückmeldung

• Erledigt

Der interne Prozess bleibt vollständig erhalten.

Die Kommunikation gegenüber dem Kunden wird dagegen deutlich verständlicher.

Gerade bei komplexeren Workflows reduziert diese Trennung Rückfragen erheblich.

Auch Benachrichtigungen sollten getrennt werden

Dasselbe Prinzip gilt für E-Mails.

Agenten benötigen Informationen über:

• Zuweisungen

• Eskalationen

• SLA-Verletzungen

• interne Kommentare

• Workflow-Wechsel

Kunden interessieren sich dagegen lediglich für Ereignisse, die ihr Anliegen betreffen.

Beispielsweise:

• Ihre Anfrage wurde erfolgreich erstellt.

• Ihre Anfrage wird bearbeitet.

• Wir benötigen weitere Informationen.

• Ihre Anfrage wurde abgeschlossen.

Je konsequenter diese Trennung umgesetzt wird, desto professioneller wirkt das Serviceportal.

Was unterhalb des Portals passiert

Das Portal bildet lediglich die oberste Ebene von Jira Service Management.

Nach dem Absenden einer Anfrage greifen sämtliche Jira-Basiskonfigurationen.

Dazu gehören unter anderem:

• Issue Type Scheme

• Workflow Scheme

• Workflow

• Screen Scheme

• Issue Type Screen Scheme

• Field Configuration

• Permission Scheme

• Notification Scheme

• Issue Security Scheme

• Automatisierungen

• SLA-Konfigurationen

Genau diese Architektur zeigt auch unsere Übersicht zur Konfigurations- und Objektstruktur in Jira Service Management.

Sie verdeutlicht, dass das Serviceportal keine eigenständige Anwendung ist, sondern auf den bewährten Jira-Mechanismen aufsetzt und diese um eine vollständig separate Kundensicht erweitert.

Hierzu empfehlen wir einen Blick auf folgenden Artikel: Konfigurations- und Objektstruktur in Jira Service Management

Typische Fehler bei der Portalstruktur

In Kundenprojekten begegnen uns immer wieder dieselben Herausforderungen.

Das Portal orientiert sich an der IT statt am Anwender

Services werden nach Teams oder Abteilungen gruppiert.

Anwender wissen jedoch selten, welche Abteilung für ihr Anliegen verantwortlich ist.

Zu viele Request Types

Statt einer klaren Struktur entstehen häufig mehrere hundert Portalanfragen.

Dadurch verlieren Anwender schnell den Überblick.

Für jeden Service existiert ein eigener Issue Type

Das führt langfristig zu unnötig vielen Workflows, Schemas und Automatisierungen.

Formulare fragen zu viele Informationen ab

Nicht jede Information muss bereits beim Erstellen einer Anfrage vorliegen.

Viele Angaben können während der Bearbeitung ergänzt werden.

Interne Workflow-Schritte werden im Portal angezeigt

Kunden interessieren sich nicht für Eskalationsstufen oder interne Bearbeitungsprozesse.

Eine reduzierte Statusdarstellung sorgt für deutlich mehr Transparenz.

Fazit

Ein professionelles Serviceportal entsteht nicht durch möglichst viele Request Types oder komplexe Formulare. Es entsteht durch eine konsequente Trennung zwischen der internen Jira-Konfiguration und der Service Experience für Anwender.

Request Types, Formulare, Portalstatus und Kundenbenachrichtigungen bilden die Sprache des Kunden.

Issue Types, Workflows, Schemas und Berechtigungen bilden die technische Grundlage im Hintergrund.

Wer diese Architektur versteht, kann Serviceportale entwickeln, die sowohl für Anwender als auch für Administratoren langfristig verständlich, wartbar und skalierbar bleiben.

Genau darin liegt eine der größten Stärken von Jira Service Management: Komplexe Prozesse lassen sich intern beliebig detailliert modellieren, während das Portal nach außen einfach, verständlich und serviceorientiert bleibt.