Wie Jira vom Projekttool zum Betriebssystem wurde

Wenn Sie die Person sind, die Jira und Confluence in Ihrem Unternehmen tatsächlich verwaltet, wissen Sie bereits, was die meisten anderen nicht wissen: Das System, das Sie betreiben, ist schon lange kein bloßes Tool mehr.

Für alle anderen ist es der Ort, an dem Tickets liegen. Für Sie ist es das gesammelte Protokoll eines ganzen Jahrzehnts an Entscheidungen: Workflows, die exakt festlegen, wie ein Change Request Ihr Unternehmen durchlaufen darf, Berechtigungskonzepte, die Ihre Berichtslinien widerspiegeln, und Benachrichtigungsregeln, die bestimmen, wer wann was wissen muss.

Und dann ist da noch Confluence, das so eng mit demselben System verzahnt ist, dass Architekturentscheidungen, Projekt-Charten und wichtige Beschlüsse oft nur im Zusammenspiel mit den Jira-Tickets, auf die sie verweisen, Sinn ergeben.

Irgendwann auf diesem Weg haben Sie – ohne dediziertes Projekt, Budget oder gar einen Namen dafür – das Betriebssystem gebaut, auf dem die eigentliche Arbeit Ihres Unternehmens läuft. Schema für Schema, Workflow für Workflow, Feld für Feld, Integration für Integration.

Das muss man einmal ganz klar so sagen. Denn die meisten Gespräche über die „Modernisierung“ dieser Landschaft gehen vom gegenteiligen Ansatz aus: dass darunter nur ein Kanban-Board mit ein paar Zusatzfeldern liegt und die Ablösung im Wesentlichen ein Datenexport mit neuer Optik ist. Sie wissen, dass das nicht stimmt. Sie wissen es, weil Sie derjenige sind, der dafür geradestehen muss, wenn etwas bricht, sobald ein Schema angefasst wird, oder warum ein Feld, das „da sein sollte“, fehlt, oder warum das Lieblings-Dashboard des Lenkungsausschusses nach einer Projektumbenennung plötzlich falsche Zahlen anzeigt.

Bevor wir also technisch werden, lohnt es sich, genau zu definieren, woraus dieses Betriebssystem eigentlich besteht. Teils, weil es selten offen ausgesprochen wird, und teils, weil eine präzise Benennung der einzig ehrliche Ausgangspunkt für jede Diskussion über seine Zukunft ist.

Wichtige Erkenntnisse

1. Jira und Confluence sind keine reinen Tools geblieben. Sie wurden zum ungeschriebenen Betriebssystem des Unternehmens. Ein Jahrzehnt voller Schemata, Workflows und Berechtigungen regelt heute exakt, wie Arbeit fließen darf, wer was sieht und wer wann benachrichtigt wird. Niemand hat es dokumentiert, weil die Macher es einfach im Kopf hatten.

2. Die wahre Komplexität liegt in sechs Ebenen, die keine Demo jemals zeigt. Schemata, Workflows, Felder, Berechtigungen, Dashboards und Marketplace-Apps fallen jeweils auf ihre ganz eigene, stille Weise aus; ein Feld, das drei von vier Hürden nimmt, wird einfach nicht gerendert, und ein Workflow-Ereignis ohne konfigurierte Benachrichtigung ist nicht kaputt – es bleibt einfach stumm.

3. Das Atlassian-Fristende für Data Center im Jahr 2029 erzwingt die Entscheidung, vereinfacht sie aber nicht. Die Uhr tickt. Was genau vor diesem Datum migriert werden muss, ist von außen betrachtet nicht sofort offensichtlich.

4. Die Bestandsaufnahme muss vor der Migration erfolgen – und genau hier zieht sovara die Linie. rready ermittelt zunächst, was unter die Migrationsgarantie von sovara fällt (Tickets, Workflows, Automatisierungen, Kernkonfiguration) und was separat besprochen werden muss (Plugins, benutzerdefinierter Code).

Eine Engine, drei Produkte und Confluence mittendrin

Jira ist eine Suite, keine einzelne Anwendung. Jira Software, Jira Work Management und Jira Service Management laufen alle auf derselben Ticket-Engine mit Tickets, Workflows, Feldern, Benachrichtigungen und Schemata – teilen sich aber weder UI, Zielgruppe noch Lizenzierung:

• Jira Software: Entwickler- und Delivery-Teams: Scrum- und Kanban-Boards, Sprints, Versionen

• Jira Work Management: Business-Teams wie HR, Legal und Ops: einfachere Aufgabenvorlagen für Prozesse außerhalb der Entwicklung

• Jira Service Management: Support und Service Desks: Kundenportal, Anfragetypen, SLAs

Die meisten Enterprise-Umgebungen betreiben mehrere dieser Produkte gleichzeitig – oft auf Data Center, der selbstverwalteten Cluster-Architektur von Atlassian. Sie ist immer noch der Standard, wenn Datenhaltung, regulatorische Vorgaben oder Private-Cloud-Vorgaben die Public Cloud von Atlassian ausschließen. Doch hier gilt eine harte Frist: Atlassian stellt den Support für Data Center im Jahr 2029 ein. Mehrere Nodes, eine gemeinsame Datenbank, ein gemeinsames Verzeichnis für Plugins und Daten – alles agiert als eine einzige logische Instanz. Und direkt daneben steht Confluence Data Center: kein isoliertes Silo, sondern Makros, die Live-Jira-Daten in Spezifikationsseiten ziehen, Meeting-Notizen, die über Schlüssel auf Tickets verweisen, und Architekturentscheidungen, die sich auf die zugrundeliegenden Epics beziehen. Nichts davon taucht in einem einfachen Feature-Vergleich auf. All das müssen Sie aber bei einer Migration berücksichtigen.

Das wahre Betriebssystem sind die Schemata

Diesen Mechanismus verstehen Außenstehende selten: Ein Jira-Projekt ist kein Ordner. Es ist ein typisierter Container. Alles an seinem Verhalten (welche Tickettypen existieren, welche Felder erscheinen, welche Eingabemasken beim Erstellen versus Bearbeiten angezeigt werden, welcher Workflow Statusänderungen regelt, wer benachrichtigt wird, wer was sehen darf) wird über ein Schema definiert. Und diese Schemata werden den Projekten zugewiesen, anstatt für jedes Projekt einzeln neu gebaut zu werden.

Genau das ermöglicht es einer gut geführten Instanz, 1.300 Projekte mit rund 200 gemeinsamen Workflows zu betreiben, statt den Prozess bei jedem neuen Team neu zu erfinden. Wenn die Governance jedoch schleift, führt dies dazu, dass Systeme Hunderte von fast identischen, aber minimal abweichenden Konfigurationen aufweisen, die niemand mehr anzufassen wagt. Die Frage „Kann dieses Tool Workflows abbilden?“ war nie die entscheidende. Die entscheidende Frage ist, ob Sie ein Betriebsmodell einmal definieren, breit ausrollen, kontrollierte Abweichungen für Teams mit echtem Bedarf zulassen und Änderungen auch nach Jahren noch zentral steuern können – oft lange nachdem die ursprünglichen Ersteller das Unternehmen verlassen haben.

Boards waren nie der eigentliche Workflow

Ein Board ist nur eine Ansicht. Scrum fügt ein Backlog und Sprints hinzu, Kanban nutzt WIP-Limits. In beiden Fällen bilden die Spalten lediglich Statuswerte ab. Wenn Sie eine Spalte umbenennen, ändern Sie nur das, was die Benutzer sehen, nicht den tatsächlichen Prozess. Genau deshalb sagt eine Demo, die sich nur um Boards dreht, fast nichts darüber aus, was Sie beim Ablösen des Systems eigentlich ersetzen müssen.

Der eigentliche Prozess liegt eine Ebene tiefer, im Workflow selbst: Transitionen, die nur in eine Richtung laufen (ein Rückschritt ist eine eigene Transition), Bedingungen, die regeln, ob ein Schritt überhaupt sichtbar ist, Validierungen für Klicks und Folgefunktionen (Post-Functions), die die echten Seiteneffekte auslösen – etwa das Setzen einer Lösung, das Zuweisen von Personen oder das Anstoßen eines Webhooks. Wenn Ihr Workflow „vierzig Folgefunktionen“ hat, ist das meist kein Standard-Jira mehr. Dann erledigen ScriptRunner, JSU, JWT oder JMWE im Hintergrund die eigentliche Arbeit, während das Diagramm an der Oberfläche noch ganz einfach aussieht.

Felder müssen vier Hürden nehmen, um überhaupt zu erscheinen

Benutzerdefinierte Felder sind nicht global. Jedes existiert in einem Kontext – einer bestimmten Kombination aus Projekt und Tickettyp. Existiert dieser Kontext nicht, ist das Feld nicht einfach nur ausgeblendet, sondern schlicht nicht vorhanden. Um auf einer Maske zu erscheinen, muss ein Feld vier Hürden nehmen: ein Kontext für dieses Projekt und diesen Typ, ein Platz auf der Maske, diese Maske muss für das Erstellen, Bearbeiten oder Anzeigen zugewiesen sein, und dieses Maskenschema muss für das Projekt ausgewählt sein. Fehlt nur einer dieser vier Schritte, bewirkt ein einfaches „Ich habe ein Feld hinzugefügt“ im Hintergrund absolut nichts.

Hier zeigt sich die wahre Dimension Ihres Systems. Tausende benutzerdefinierte Felder sind kein bloßes Datenmapping-Projekt. Sie sind das betriebliche Vokabular Ihres Unternehmens – die spezifischen Begriffe, die HR, Legal oder Delivery für ihre Prozesse nutzen, verknüpft mit Kontexten, Masken, Workflows, Filtern und Berichten. Das als flache Liste von Feldnamen zum schnellen „Eins-zu-eins-Mapping“ abzutun, verkennt die Realität.

Berechtigungen sind ein Stack, E-Mail ist ein Event-Bus

Zugriffsschutz ist keine einzelne Einstellung. Er besteht aus dem Anwendungszugriff auf Lizenzebene, gefolgt von globalen Berechtigungen und dem Berechtigungsschema des Projekts (idealerweise an Rollen gebunden, statt an fest codierte Gruppen, die beim nächsten Umbau umbenannt werden). Optional kommt ein Ticket-Sicherheitsschema für einzelne Vorgänge hinzu, die noch strenger geschützt werden müssen als das restliche Projekt.

Benachrichtigungen funktionieren ähnlich: Ausgehende E-Mails lösen Events aus, die an ein Benachrichtigungsschema gekoppelt sind. Eingehende E-Mail-Handler erstellen oder kommentieren Tickets aus einem gemeinsamen Postfach, und Benutzer abonnieren gespeicherte Filter für ihre eigenen Übersichten. Ein benutzerdefiniertes Workflow-Ereignis ohne konfigurierte Benachrichtigung ist nicht fehlerhaft – es bleibt einfach stumm. Deshalb ist „Wir bekommen eine E-Mail, wenn X passiert“ eine bewusste Prozessentscheidung Ihres Teams, kein vergessenes Häkchen.

Filter und Dashboards sind das Reporting-System, das niemand dokumentiert hat

Die Suche bietet einen Schnellmodus, einen Standardmodus und JQL (eine WHERE-Klausel, keinen Report-Generator). Filter sind gespeicherte JQL-Abfragen, und Dashboards sind Gadgets, die auf diesen Filtern aufbauen. In gewachsenen Systemen ist diese Ebene meist riesig – und genau das, worauf das Management schaut. Die Folie, die der Lenkungsausschuss jeden Monat prüft, basiert meist auf tief verschachtelten Filtern, die von jemandem erstellt wurden, der das Team längst gewechselt hat. Jede ehrliche Bestandsaufnahme muss diese Ebene einbeziehen – nicht nur die Tickets selbst, sondern alles, was darauf aufbaut.

In den Marketplace-Apps steckt oft die eigentliche Logik

Apps aus dem Atlassian Marketplace (oder als JARs in isolierten Umgebungen installiert) müssen exakt zum Hosting-Modell passen. Eine App aus der Server-Ära auf einem Data-Center-Node sorgt genau für das „unerwartete Verhalten“, das niemand im Support-Call reproduzieren kann. ScriptRunner für skriptbasierte Logik, JSU/JWT/JMWE für No-Code-Workflow-Erweiterungen, Structure für Portfolio-Hierarchien sowie Testmanagement-, Zeiterfassungs- und CMDB-Tools auf derselben Ticket-Engine: All das ist kein Beiwerk. In vielen Systemen läuft hier die eigentliche Prozesslogik. Eine Bestandsaufnahme, die diesen Bereich auslässt, ist von Anfang an unvollständig.

Warum rready mit der Analyse Ihres Systems startet

Nichts davon spricht gegen Veränderung. Es spricht aber dafür, die nötigen Schritte ernst zu nehmen. Über Jahre im Realeinsatz nehmen Jira und Confluence die Prozesse, das interne Vokabular, das Berichtswesen und die Governance eines Unternehmens in sich auf. Das meiste davon steckt in Konfigurationen, die nie dokumentiert wurden, weil die Macher sie einfach im Kopf hatten – so wie Sie.

Deshalb starten wir mit einem gemeinsamen Gespräch, um:

• Die Systemlandschaft einzugrenzen: Ein erstes Gespräch über Ihr Setup auf hoher Ebene: Projektanzahl, Integrationen und bekannte Schwachstellen.

• Das System real zu analysieren: Eine Session direkt an Ihren echten Schemata, Workflows, Feldern, Berechtigungen und Marketplace-Apps anstelle einer generischen Checkliste.

• Klarheit über den Umfang zu gewinnen: Was fällt unter die Migrationsgarantie von sovara (Tickets, Workflows, Automatisierungen und Kernkonfiguration mit Geld-zurück-Garantie) und was liegt außerhalb (Plugins und Individualcode), was wir separat besprechen, bevor Termine gesetzt werden.

Ein Betriebssystem dieser Größenordnung aufzubauen, hat Jahre harter Arbeit gekostet – Schema für Schema, Workflow für Workflow, Integration für Integration. So etwas ersetzt man nicht durch einen simplen Datenexport und eine neue Oberfläche. Es zuerst im Detail zu verstehen, bevor überhaupt über Angebote gesprochen wird, ist der einzig richtige Weg.