5 min
Atlassians neues Modell der nutzungsbasierten Preisgestaltung hat verständlicherweise viel Aufmerksamkeit erhalten, insbesondere wegen der Rovo-Credits und KI-Funktionen. Für viele Jira-Enterprise-Admins liegt die unmittelbarere operative Veränderung jedoch an anderer Stelle: Jira Automation wird nutzungsbasiert gemessen und abgerechnet.
Ab dem 3. Dezember 2026 misst Atlassian die Nutzung von Automation in ausgeführten Schritten. Enterprise-Abonnements verfügen nicht länger über unbegrenzte Automation. Stattdessen steuern berechtigte Abonnements ein gemeinsames monatliches Kontingent auf Organisationsebene bei. Zusätzliche Kapazität kann über vorausbezahlte Pakete oder nachträglich abgerechnete Nutzung zu 0,50 US-Dollar pro 1.000 Schritten bezogen werden.
Das ist kein nebensächliches Lizenzdetail. Automation ist in vielen Jira-Umgebungen Teil der operativen Grundlage: Sie weist Arbeit zu, setzt Standards durch, versendet Benachrichtigungen, synchronisiert Felder, erstellt Folgeaufgaben, steuert Freigaben, eskaliert Service-Anfragen und hält komplexe Workflows in Bewegung. Für reife Jira-Landschaften lautet die entscheidende Frage daher nicht, ob Automation wertvoll ist. Sie lautet, ob die Organisation versteht, wie ihre Regeln Nutzung verursachen, welche Flows tatsächlich geschäftskritisch sind und was geschieht, wenn das gemeinsame Kontingent aufgebraucht ist.
Bisher maß Atlassian Automation anhand erfolgreicher Rule Runs. Eine einfache und eine komplexe Regel zählten jeweils als ein erfolgreicher Durchlauf, unabhängig davon, wie viele Bedingungen, Verzweigungen, Aktionen oder Schleifen in der Regel enthalten waren. Für Enterprise-Kunden war Automation unter diesem Modell unbegrenzt.
Der neue Ansatz zählt Automation Steps, also einzelne ausgeführte Bestandteile eines Flows. Ein Schritt kann ein Trigger, eine Bedingung, eine Aktion, eine Verzweigung oder eine Schleifeniteration sein. Atlassians eigenes Beispiel — Trigger, Prioritätsprüfung, Zuweisung und Benachrichtigung — verbraucht vier Schritte.
Damit können zwei Regeln, die im Audit Log ähnlich aussehen, sehr unterschiedliche Nutzungsmuster aufweisen. Eine Regel, die eine Bedingung prüft und ein Feld aktualisiert, verbraucht möglicherweise nur wenige Schritte. Eine zeitgesteuerte Regel, die viele Vorgänge durchsucht, mehrere Pfade durchläuft, über verknüpfte Elemente iteriert und verschiedene Aktualisierungen sendet, kann bei jeder Ausführung deutlich mehr Schritte verbrauchen.
Die Änderung führt außerdem ein gemeinsames Modell ein. Kontingente aus berechtigten Abonnements für Jira, Confluence, Jira Product Discovery, Jira Service Management und Collections werden auf Organisationsebene zusammengeführt. Das schafft Flexibilität über Produkte hinweg. Gleichzeitig kann ein einziger Use Case mit hohem Volumen die Kapazität beeinflussen, die allen anderen Teams zur Verfügung steht.
Das zentrale Risiko besteht nicht darin, dass jede Automation-Regel plötzlich teuer wird. Das Risiko liegt in fehlender Transparenz. Viele Enterprise-Instanzen haben über Jahre hinweg Regeln angesammelt, häufig über mehrere Projekte und Teams hinweg. Manche sind gut gestaltet und werden aktiv gepflegt. Andere wurden zur Lösung eines temporären Problems erstellt und danach vergessen. Einige laufen nur, wenn ein Mensch einen Vorgang ändert. Andere laufen nach Zeitplan, reagieren auf Ereignisse mit hohem Volumen oder iterieren über große Arbeitsmengen.
Bei einer schrittbasierten Messung zählen Komplexität und Häufigkeit gemeinsam. Eine komplexe Regel, die selten ausgeführt wird, kann einen vernachlässigbaren Effekt haben. Eine mittelkomplexe Regel, die alle paar Minuten über Tausende von Vorgängen läuft, kann zu einem erheblichen Verbrauchstreiber werden. Zeitgesteuerte Regeln verdienen besondere Aufmerksamkeit, weil sie Schritte verbrauchen können, auch wenn sie keine sinnvoll zu bearbeitenden Ergebnisse finden.
Hinzu kommt ein Thema der Betriebskontinuität. Wenn das gemeinsame monatliche Kontingent verbraucht ist und zusätzliche Nutzung deaktiviert wurde, werden neue Automation Flows bis zum Beginn des nächsten Abrechnungszeitraums oder bis zum Hinzufügen weiterer Kapazität nicht mehr ausgeführt. Ereignisse werden nicht zwischengespeichert und nach der Kontingent-Erneuerung nicht erneut verarbeitet. Bereits laufende Flows können abgeschlossen werden, aber Trigger-Ereignisse während der Pause werden nicht für eine spätere Ausführung gespeichert.
Deshalb sollte diese Änderung als Aufgabe für Service Management und Prozess-Governance verstanden werden, nicht nur als Thema für Finance.
Der Unterschied zwischen einem Rule Run und einem Step ist das wichtigste Konzept, das Admins vermitteln sollten.
Betrachten Sie eine einfache Onboarding-Regel. Eine neue Mitarbeiteranfrage wird erstellt, die Regel prüft den Request Type, weist sie einem Team zu, erstellt eine verknüpfte Aufgabe und versendet eine Benachrichtigung. Auch ohne Verzweigungen oder Schleifen werden mehrere Schritte ausgeführt.
Betrachten Sie nun eine zeitgesteuerte Regel zur Prozesshygiene. Sie sucht jede Stunde nach allen überfälligen Anfragen, iteriert über jede Anfrage, prüft Priorität und Kundensegment, fügt einen Kommentar hinzu, aktualisiert ein Feld, benachrichtigt einen Owner und erstellt bei Bedarf eine Eskalationsaufgabe. Der gesamte Verbrauch hängt von der Anzahl passender Anfragen, der pro Anfrage ausgeführten Logik und der Häufigkeit des Zeitplans ab.
Die zweite Regel kann ausgesprochen wertvoll sein. Es geht nicht darum, sie pauschal zu entfernen. Es geht darum, ihren Verbrauch und ihren Geschäftswert sichtbar zu machen und danach zu entscheiden, ob ihr Design angemessen ist.
Das neue Preismodell bestraft Automation nicht. Es macht sichtbar, welche Automationsmuster besonders häufig, besonders komplex oder nicht mehr ausreichend gepflegt sind.
Atlassian stellt über das Platform Usage Dashboard in Atlassian Administration Transparenz zur Nutzung bereit, einschließlich Monitoring und Alerts, wenn sich Organisationen ihrem Kontingent nähern. Beginnen Sie mit den verfügbaren Daten, statt allein aus der Anzahl bestehender Regeln zu schätzen.
Identifizieren Sie die Apps, Projekte und Zeiträume mit dem höchsten Verbrauch. Prüfen Sie Trends, statt sich auf eine einzelne ruhige Woche zu verlassen. Saisonale Prozesse, Release-Zyklen, Aktivitäten zum Quartalsende und Support-Spitzen können die Baseline deutlich verändern.
Regeln, die durch Ereignisse mit hohem Volumen ausgelöst werden, verdienen eine frühe Prüfung. Dazu gehören häufige Vorgangsaktualisierungen, Statuswechsel, Formulareinreichungen, Kommentare, eingehende Service-Anfragen und Integrationen, die viele Datensätze aktualisieren.
Zeitgesteuerte Regeln benötigen eine separate Prüfung. Fragen Sie, wonach sie suchen, wie häufig sie laufen, wie viele Elemente sie auswerten und ob sie weiterhin laufen müssen, wenn keine relevante Veränderung stattgefunden hat. Ersetzen Sie breit angelegte Polling-Muster, wo sinnvoll, durch ereignisgesteuerte Trigger oder reduzieren Sie Umfang und Frequenz des Zeitplans.
Verzweigungen und Schleifen sind nützliche Funktionen, aber sie vervielfachen den Verbrauch, weil sie Logik wiederholt ausführen. Eine Schleife über verknüpfte Vorgänge, betroffene Services, Beteiligte oder eine große JQL-Ergebnismenge kann dazu führen, dass der Step-Verbrauch schnell skaliert.
Suchen Sie nach Regeln, die dieselbe Aktualisierung oder Benachrichtigung mehrfach ausführen. Eine Vereinfachung der Abfolge, eine präzisere JQL-Abfrage, früher platzierte Bedingungen oder die Bündelung von Aktionen können unnötige Ausführung reduzieren, ohne das Geschäftsergebnis zu verändern.
Atlassian bietet derzeit keine Möglichkeit, einzelne Flows als „business critical“ zu markieren und bei ausgeschöpftem Kontingent priorisiert auszuführen. Das macht Governance umso wichtiger. Admins müssen wissen, welche Flows Kundenverpflichtungen, Incident Response, Security-Prozesse, regulatorische Nachweise oder finanzielle Abläufe unterstützen und welche vor allem Komfort schaffen.
Dokumentieren Sie Owner, Zweck, Auswirkung und Fallback-Prozess für kritische Regeln. Wer bemerkt, wenn ein kritischer Automation Flow pausiert? Welcher manuelle Prozess übernimmt? Wie schnell kann zusätzliche Kapazität freigegeben oder ein Usage Pack ergänzt werden? Diese Fragen sollten beantwortet sein, bevor tatsächlich eine Unterbrechung eintritt.
Atlassian ermöglicht den Kauf vorausbezahlter Automation-Step-Pakete oder die Aktivierung nachträglich abgerechneter zusätzlicher Nutzung. Zusätzliche Nutzung wird mit 0,50 US-Dollar pro 1.000 Schritten berechnet. Keine der beiden Optionen ist für jede Organisation automatisch die richtige.
Teams mit planbarer, geschäftskritischer Automation bevorzugen möglicherweise Kapazitätsplanung und feste Pakete. Teams mit variablem, aber nicht geschäftskritischem Verbrauch können sich für kontrollierte nachträgliche Nutzung entscheiden. Legen Sie in jedem Fall fest, wer diese Einstellung ändern darf, wer Alerts erhält, welcher Schwellenwert eine Prüfung auslöst und wer das Budget verantwortet.
Das Ziel ist nicht, für jeden Step Reibung zu erzeugen. Es geht darum, einer gemeinsam genutzten operativen Fähigkeit einen klaren Owner und einen eindeutigen Entscheidungsprozess zu geben.
Beginnen Sie nicht damit, jede komplexe Regel zu löschen. Komplexität ist kein Fehler, wenn sie einen wertvollen Geschäftsprozess abbildet. Verlassen Sie sich auch nicht auf eine einmalige Prüfung. Automation verändert sich, wenn Teams neue Projekte erstellen, Integrationen hinzufügen, Workflows überarbeiten und neue Apps einsetzen.
Behandeln Sie das Kontingent nicht als reines IT-Thema. Projekt-Admins und Fachbereiche besitzen oft die Regeln, die die meisten Steps verbrauchen. Sie sollten verstehen, warum Häufigkeit, Schleifen und breit angelegte Suchen relevant sind, und an der Entscheidung beteiligt sein, was optimiert wird.
Warten Sie schließlich nicht auf eine Benachrichtigung bei 80 Prozent Nutzung, bevor Sie beginnen. Alerts sind eine wichtige Kontrolle, ersetzen aber nicht das Verständnis der Regeln und Prozesse, die für die Organisation am wichtigsten sind.
Atlassians Wechsel zu einer schrittbasierten Automation-Abrechnung verändert die Management-Diskussion. Enterprise-Teams wechseln von einem unbegrenzten Modell zu einem Modell, das Nutzung, Designentscheidungen und operative Prioritäten sichtbar macht.
Die richtige Reaktion ist weder Panik noch ein pauschales Verbot von Automation. Sie ist ein strukturiertes Audit: Schaffen Sie eine Baseline, verstehen Sie die Verbrauchstreiber, entfernen Sie unnötige Ausführung, schützen Sie kritische Workflows durch Planung und sorgen Sie für klare Verantwortung auf technischer wie fachlicher Seite.
Teams, die diese Arbeit vor dem 3. Dezember abschließen, sind besser aufgestellt, Kosten zu steuern und Unterbrechungen zu vermeiden. Vor allem aber erhalten sie eine Jira-Automation-Landschaft, die einfacher, bewusster gestaltet und leichter zu betreiben ist.
Wenn Sie Ihre Automation-Landschaft mit einem zweiten Blick überprüfen möchten, unterstützt Sie Lupus Consulting dabei, Verbrauchstreiber zu identifizieren, Regel-Designs zu prüfen, kritische Flows zu priorisieren und vor Inkrafttreten des neuen Modells eine praxistaugliche Governance aufzubauen. Nehmen Sie Kontakt mit unserem Team auf, um Ihre nächsten Schritte zu besprechen.
Den meisten Organisationen fehlt keine Strategie. Ihnen fehlt eine aktuelle, verlässlic
Der Wechsel von Opsgenie zu Jira Service Management ist mehr als eine Datenmigration. E
Viele Unternehmen investieren massiv in Atlassian-Lizenzen und Implementierungen, nur u