Atlassians neue Automation-Abrechnung: Warum viele Regeln teurer werden, obwohl sich am Prozess nichts geändert hat

Von Rule Runs zu einzelnen Steps 

Bisher wurde Atlassian Automation auf Ebene der Regel-Ausführungen gezählt. Ob eine Regel zwei oder zwanzig Aktionen enthielt, spielte für die Abrechnung keine Rolle: Ein Rule Run blieb ein Rule Run. Single-Project-Regeln konnten dabei unbegrenzt ausgeführt werden. Nur globale und Multi-Project-Regeln wurden gegen das monatliche Kontingent gerechnet.

Mit der Umstellung verändert sich diese Logik grundlegend. Atlassian zählt künftig die einzelnen Bestandteile einer Automation. Aktionen, Bedingungen, Branches und Schleifen werden jeweils als Automation Steps berücksichtigt. Die enthaltenen Kontingente werden organisationsweit gepoolt und liegen bei 400 Steps pro User und Monat im Standard-Tarif, 750 im Premium-Tarif und 1.000 im Enterprise-Tarif. Damit verliert auch Enterprise das bisherige „unlimited“ und erhält erstmals eine feste Verbrauchsgrenze.

Warum das ein Betriebsproblem ist, kein reines Preisproblem 

Unter dem bisherigen Modell haben viele Teams vor allem eines optimiert: möglichst wenige Rule Runs zu verbrauchen. Die naheliegende Lösung bestand darin, mehrere Arbeitsschritte in einer größeren Regel zusammenzufassen, anstatt einzelne Abläufe voneinander zu trennen. Eine Regel mit fünfzehn Aktionen kostete schließlich genauso viel wie eine Regel mit zwei Aktionen.

Mit der neuen Step-Logik dreht sich dieser Anreiz um. Was unter dem alten Modell effizient erschien, kann künftig einen besonders hohen Verbrauch erzeugen. Viele bestehende Regeln wurden nie unter der Fragestellung entwickelt, wie viele einzelne Schritte für den zugrunde liegenden Prozess tatsächlich notwendig sind.

Genau darin liegt das eigentliche Problem. Über Jahre gewachsene Automationsregeln enthalten häufig Sonderfälle, zusätzliche Bedingungen und technische Hilfsschritte, die irgendwann ergänzt, aber später nie wieder grundsätzlich hinterfragt wurden. Unter der bisherigen Abrechnung blieb diese Komplexität finanziell weitgehend unsichtbar. Mit der neuen Step-Abrechnung wird diese technische Schuld plötzlich messbar und potenziell kostenrelevant.

Was jetzt konkret zu prüfen ist 

Einfach ein höheres Kontingent einzuplanen, wäre deshalb der falsche erste Schritt. Die neue Step-Logik sollte vielmehr zum Anlass genommen werden, die bestehenden Automationen grundsätzlich zu überprüfen.

Dabei geht es nicht nur darum, einzelne Steps einzusparen. Entscheidend ist die Frage, welchen realen Prozess eine Automationsregel heute überhaupt noch abbildet. Wer ausschließlich die Anzahl der Steps betrachtet, optimiert Symptome. Wer den zugrunde liegenden Prozess untersucht, findet dagegen häufig die eigentliche Ursache für unnötigen Verbrauch.

So sollte beispielsweise geprüft werden, ob eine Regel noch einen Prozess automatisiert, der in dieser Form tatsächlich gelebt wird, oder ob sie einen historischen Sonderfall abbildet, der längst keine Rolle mehr spielt. Ebenso lohnt sich der Blick darauf, ob mehrere fachlich unterschiedliche Abläufe nur deshalb in einer großen Regel zusammengeführt wurden, weil damit früher Rule Runs eingespart werden konnten. Unter der neuen Logik kann es sinnvoller sein, diese Prozesse wieder klar voneinander zu trennen.

Hinzu kommen technische Altlasten innerhalb bestehender Regeln. Bedingungen, die praktisch nie greifen, Debug-Aktionen aus der Einführungsphase oder Schleifen, die deutlich mehr Objekte durchlaufen als fachlich notwendig, erhöhen künftig direkt den Verbrauch.

Diese Analyse ist deshalb keine reine Step-Kosmetik. Sie zwingt Unternehmen dazu, gewachsene Automationsregeln wieder mit den tatsächlichen Geschäfts- und IT-Prozessen abzugleichen. Ein geringerer Step-Verbrauch ist dabei idealerweise nicht das alleinige Ziel, sondern das Ergebnis einer saubereren Prozessgestaltung.

Automation ist nur der sichtbarste Fall 

Automation ist nur einer von mehreren Bereichen, die Atlassian gleichzeitig stärker nach tatsächlicher Nutzung abrechnet. Das grundlegende Muster zeigt sich auch bei anderen Funktionen.

Bei Assets rückt beispielsweise die Anzahl der gespeicherten Objekte stärker in den Mittelpunkt, während die Kontingente auf weitere Atlassian-Produkte ausgeweitet werden. Bei Bitbucket werden Meter wie Build Minutes, Git LFS und Packages von der Workspace-Ebene auf die organisationsweite Betrachtung verschoben. Auch dort verliert Enterprise bisherige „unlimited“-Bestandteile.

Mit Rovo Credits wird wiederum die tatsächliche Nutzung von KI-Funktionen gemessen. Einfache Interaktionen werden mit einem festen Credit-Verbrauch bewertet, komplexere Vorgänge können einen höheren Verbrauch erzeugen. Besonders deutlich wird das verbrauchsabhängige Modell bei AI Agent Resolutions im Customer Service Management: Dort wird jede vollständig durch einen AI Agent gelöste Anfrage einzeln abgerechnet.

Über diese unterschiedlichen Meter hinweg zeigt sich dieselbe Entwicklung. Leistungen, die bislang teilweise pauschal oder unbegrenzt innerhalb eines Tarifs enthalten waren, werden stärker als konkreter Verbrauch sichtbar. Damit entsteht für Unternehmen erstmals die Möglichkeit – aber auch die Notwendigkeit –, diesen Verbrauch aktiv zu steuern.

Genau deshalb ist die Umstellung mehr als eine Preisfrage. Sie verändert die wirtschaftliche Logik hinter dem Betrieb einer Atlassian-Plattform. Automationen, Assets und KI-Funktionen sollten nicht nur technisch funktionieren, sondern einen Verbrauch erzeugen, der durch den jeweiligen Prozess und dessen Nutzen gerechtfertigt ist.

Warum das auch für KI relevant ist 

Besonders deutlich wird dieser Zusammenhang bei Rovo und agentischen Workflows. KI-Funktionen setzen häufig auf denselben Prozessen und Automationen auf, die bereits heute innerhalb von Jira und Jira Service Management existieren.

Ein sauber strukturierter Basisprozess ist deshalb eine wichtige Voraussetzung dafür, dass sich darauf aufbauende KI-Funktionen wirtschaftlich betreiben lassen. KI kann einen guten Prozess leistungsfähiger machen. Sie kann aber genauso einen unnötig komplexen Prozess verstärken und damit zusätzlichen Verbrauch erzeugen.

Die neue Automation-Abrechnung ist deshalb auch ein guter Anlass, bestehende Prozesse zu bereinigen, bevor weitere KI-Funktionen darauf aufgebaut werden.

Wer vor dem 3. Dezember Klarheit haben möchte, sollte jetzt prüfen, welche Automationsregeln unter der neuen Step-Logik tatsächlich relevanten Verbrauch erzeugen und wo historisch gewachsene Komplexität reduziert werden kann. Ein Governance & Operating Check zeigt, wo Kontingente unnötig verbraucht werden und welche Regeln vor dem Stichtag bereinigt werden sollten:  Kontakt