Richtig konzipiert: Geschäftsprozesse in Jira automatisieren, aufbauen und führen

Jira bietet bereits eine starke Grundlage für Workflows, Berechtigungen, Genehmigungen, Automatisierung und Nachvollziehbarkeit.

Mit den passenden Erweiterungen rund um diese Funktionen kann Jira darüber hinaus auch reichhaltigere, vernetzte Geschäftsprozesse unterstützen, die sich für die Nutzenden natürlich anfühlen.

Um zu veranschaulichen, was möglich ist, nehmen wir ein sehr einfaches Beispiel: einen Purchase Request, der aus einem bestehenden Business Project heraus angestoßen wird.

Wir verwenden dafür drei sich ergänzende VIP.LEAN Apps:

• Create and Link
• Behaviours Builder
• Issue Pickers

Das Ziel ist nicht, einen vollständigen Beschaffungsprozess zu entwerfen. Der Purchase Request dient lediglich als praktisches Beispiel, um zu zeigen, wie diese Funktionen zusammenwirken können.

Ein einfaches vernetztes Geschäftsszenario

Stellen Sie sich vor, ein Unternehmen verwaltet seine internen Business Projects in Jira. Ein Business Project kann einen eigenen Lebenszyklus, ein eigenes Budget, eine Abteilung, eine Kostenstelle und eine verantwortliche Person haben. Diesen Prozess müssen wir hier nicht im Detail betrachten. Irgendwann erfordert das Projekt eine Beschaffung. Der daraus resultierende Geschäftsablauf kann so einfach aussehen:

Jedes Objekt kann seinen eigenen Workflow, eigene Berechtigungen und eigene Geschäftsregeln haben und bleibt dabei mit dem übergreifenden Geschäftskontext verbunden.

Genau hier ergänzen sich die drei Apps.

Den nächsten Geschäftsprozess direkt aus seinem Kontext heraus starten

Die Nutzerin oder der Nutzer arbeitet bereits im Business Project, wenn der Bedarf für eine Beschaffung entsteht.

Statt eine generische Jira-Erstellungsmaske zu öffnen und den Kontext manuell neu aufzubauen, kann das Business Project eine klare Geschäftsaktion anbieten:

Purchase Request erstellen

Mit Create and Link lässt sich ein Button so konfigurieren, dass er den Purchase Request erstellt und die Beziehung zum Business Project automatisch herstellt.

Relevante Informationen aus der Quelle können ebenfalls in die neue Anfrage übernommen werden, zum Beispiel: Abteilung · Kostenstelle · Projektverantwortliche(r).

Was macht das besonders nützlich?

Create and Link geht über eine weitere Möglichkeit hinaus, ein Work Item zu erstellen. Die Aktion selbst kann kontextabhängig sein. Ihre Verfügbarkeit kann vom Jira-Kontext, von JQL-Bedingungen, vom Work Type, von Benutzern, Gruppen oder Rollen abhängen.

Das Erstellungserlebnis lässt sich anschließend rund um die Geschäftsaktion gestalten: Zielkontext, vordefinierte Werte, übernommene Informationen, ausgeblendete Felder und automatische Verknüpfung.

Wenn alle erforderlichen Angaben bereits bekannt sind, kann dasselbe Konzept sogar zu einer Ein-Klick-Geschäftsaktion werden.

Den Purchase Request an seinen Kontext anpassen

Sobald der Purchase Request geöffnet ist, benötigt nicht jede Beschaffung zwangsläufig dieselben Informationen.

Ein Softwarekauf kann zum Beispiel Angaben erfordern, die für Büroausstattung keinen Sinn ergeben.

Mit dem Behaviours Builder kann das Jira-Formular dynamisch auf die Eingaben der Nutzenden reagieren.

Ein einfaches Beispiel könnte sein:

Purchase Type = Software

und das Formular:

• zeigt sofort ein Feld Number of Licences an,
• macht es zum Pflichtfeld,
• passt die verfügbaren Optionen in einem anderen Feld an,
• oder leitet automatisch einen weiteren Wert ab.

Entscheidend ist die Möglichkeit, dass die Oberfläche selbst dem Geschäftskontext folgen kann, statt jedem Benutzer sämtliche denkbaren Felder und Optionen anzuzeigen.

Der Behaviours Builder kann unter anderem folgende Aspekte dynamisch steuern:

Sichtbarkeit · Pflichtfeld/optional · bearbeitbar/schreibgeschützt · Beschriftungen · Beschreibungen · Feldwerte · verfügbare Optionen · Validierung

Mehr als isolierte Formularregeln

Dynamisches Feldverhalten gibt es im Jira-Ökosystem in verschiedenen Ausprägungen. Besonders interessant wird es hier durch die Art, wie sich die Regeln strukturieren und wiederverwenden lassen.

Bedingungen und Verhaltenslogik können zentral definiert und über verschiedene Kontexte hinweg angewendet werden, statt jeden Screen als isolierte Konfiguration zu behandeln.

Ein weiterer nützlicher Aspekt ist das Konfigurationsbewusstsein: Der Builder berücksichtigt die von Jira unterstützten UI-Modification-Funktionen und hilft Administratoren zu verstehen, ob eine bestimmte Modifikation im gewählten Kontext gültig ist.

Für ein Unternehmen, das viele Geschäftsprozesse umsetzt, lassen sich Verhaltensregeln so leichter steuern und wiederverwenden, während die Jira-Umgebung wächst.

Die Anfrage mit bestehenden Geschäftsobjekten verbinden

Später im Prozess muss der Einkauf den Purchase Request möglicherweise mit einem bestehenden Contract verknüpfen.

Ein Contract ist nicht einfach nur ein Wert in einem Dropdown. Er kann selbst ein Jira Work Item mit eigener verantwortlicher Person, eigenen Terminen, eigenem Status, Lebenszyklus und zugehörigen Informationen sein.

Das ist ein natürlicher Anwendungsfall für Issue Pickers.

Anstatt Jira manuell zu durchsuchen, können Nutzende den passenden Contract direkt in einem dedizierten Feld auswählen. Die verfügbaren Work Items lassen sich über JQL einschränken, sodass nur die Contracts angezeigt werden, die im aktuellen Kontext sinnvoll sind.

Zum Beispiel:

aktive Contracts, die für diese Art der Beschaffung relevant sind – statt aller Contracts oder aller Work Items in Jira.

Die Auswahl des Contracts pflegt anschließend die entsprechende Jira-Beziehung.

Für die Nutzenden ist das Ergebnis denkbar einfach:

Purchase Request → Contract auswählen → Beziehung erstellt

Jira-Beziehungen nativ halten

Einer der markantesten Aspekte von Issue Pickers ist die Beziehung zwischen dem Picker-Feld und den nativen Jira Issue Links.

Der Picker kann den zugrunde liegenden Jira Link pflegen, und Änderungen, die direkt an diesen Links vorgenommen werden, können ebenfalls im Picker widergespiegelt werden.

Das bedeutet: Der Picker muss kein separates, von Jira losgelöstes Beziehungsmodell werden. Er kann auf dem nativen Verknüpfungsmechanismus von Jira aufsetzen und gleichzeitig ein deutlich komfortableres, geschäftsorientiertes Auswahlerlebnis bieten.

Bestehende Jira Links können außerdem genutzt werden, um Picker-Beziehungen zu befüllen – besonders hilfreich, wenn Issue Pickers in einer Umgebung eingeführt werden, die bereits etablierte Daten und Beziehungen enthält.

Der wahre Nutzen zeigt sich im Zusammenspiel der drei Funktionen

Für sich genommen löst jede App ein anderes Problem.

Gemeinsam entsteht daraus ein umfassenderes Muster:

Create and Link
→ Den nächsten Prozess aus dem richtigen Geschäftskontext heraus starten.

Behaviours Builder
→ Die Benutzererfahrung und die Geschäftsregeln an diesen Kontext anpassen.

Issue Pickers
→ Den Prozess mit bestehenden Geschäftsobjekten verbinden.

Aus unserem einfachen Purchase Request wird damit:

Business Project
→ erstellt und liefert Kontext für
Purchase Request
→ passt sich dynamisch an die Anfrage an
→ verbindet sich mit einem bestehenden
Contract

Und dasselbe Muster lässt sich noch deutlich weiter ausbauen.

Ein Business Project könnte mit der Zeit mit Purchase Requests, Contracts, Recruitment Requests, Change Requests oder anderen Unternehmensprozessen verbunden sein — jeweils mit eigenem Lebenszyklus und dennoch Teil eines vernetzten Geschäftsmodells in Jira.

Der Purchase Request ist nur ein Beispiel.

Die weiterreichende Möglichkeit besteht darin, Jira nicht nur zu nutzen, um einzelne Work Items durch Workflows zu bewegen, sondern um vernetzte Geschäftsprozesse zu schaffen, in denen Aktionen, Formulare und Beziehungen die tatsächliche Arbeitsweise der Organisation abbilden.

Den nächsten Prozess starten. Ihn an seinen Kontext anpassen. Ihn mit dem restlichen Geschäft verbinden.

Links:

• Kurze Touren: Behaviour Builder, Create and Link, Issue Pickers
• Kostenlose Testversionen auf dem: Atlassian Marketplace
• Warum Behaviours in Jira Cloud keinen Entwickler erfordern sollten
• Optionen eines Auswahlfelds je nach Vorgangstyp im selben Bereich anpassen – No-Code-Showcase mit dem Behaviours Builder
• Dynamische Feld-Behaviours im JSM-Kundenportal
• Weniger Custom-Field-Wildwuchs dank kontextbasierter Feldbezeichnungen
• Mehrstufige kaskadierende Felder in Jira Cloud: ein No-Code-Ansatz