Support und Projekte teilen sich dieselben Leute, und niemand steuert den Konflikt

Das eigentliche Problem

Der Engpass entsteht nicht durch zu wenig Personal, sondern durch fehlende gemeinsame Sicht auf die Arbeit. Support ist reaktiv und dringlich, Projektarbeit ist planbar und wichtig. Konkurrieren beide um dieselbe Kapazität, gewinnt fast immer das Dringliche. Projekte verzögern sich, ohne dass jemand diese Entscheidung bewusst getroffen hat. Die Geschäftsführung sieht am Ende, dass ein Rollout drei Monate zu spät kommt, nicht warum.

Ein Ticketsystem allein löst das nicht. Es macht den Support steuerbar und sagt nichts darüber aus, was die Projektarbeit gerade blockiert. Solange Servicearbeit und Projektarbeit in getrennten Systemen liegen, bleibt jede Priorisierung ein Bauchgefühl, und Kapazitätsdiskussionen enden oft in Schuldzuweisungen.

Erst der Serviceprozess, dann die Projektsteuerung

Die Basis ist der Betrieb. Jira Service Management strukturiert die eingehende Arbeit: Anfragen und Störungen laufen über definierte Request-Typen ein, werden priorisiert, per SLA nachgehalten und den richtigen Teams zugeordnet. Erst wenn dieser Strom sauber erfasst ist, entsteht eine belastbare Zahl dafür, wie viel Kapazität der laufende Betrieb tatsächlich bindet.

Auf dieser Basis wird die Projektseite steuerbar. In Jira Software liegen die IT-Vorhaben als Epics und Aufgaben, verortet auf einer Roadmap mit Zeitbezug: Was wird wann an welchem Standort umgesetzt. Der entscheidende Schritt ist nicht das zweite Tool, sondern die gemeinsame Schicht darüber. Atlassian nennt dieses Prinzip System of Work: Service- und Projektarbeit liegen in einem verbundenen System, in dem dieselbe Kapazität nicht doppelt verplant werden kann. Ein Projekt und eine Welle kritischer Tickets treffen dann sichtbar aufeinander, statt sich im Verborgenen zu verdrängen.

Steuerung nach Standort, nicht nach Lautstärke

Versorgt die zentrale IT mehrere Werke oder Standorte, wird jede Projektaufgabe über Komponenten und Labels dem betroffenen Standort zugeordnet. Eine Netzwerkerneuerung betrifft nur Werk Nord, die ERP-Anbindung nur Standort Süd. Die Roadmap lässt sich pro Standort filtern, und das IT-Management berichtet der Geschäftsführung eine Statusübersicht statt einer Ticketliste: welches Vorhaben wo steht und was der Betrieb blockiert. Priorisierung wird zur Managemententscheidung mit Datengrundlage, nicht zur Reaktion auf den lautesten Standort.

Was ein Industriekunde daraus gemacht hat

Ein Fertigungsunternehmen stand vor genau diesem Zielkonflikt: Dieselben Spezialisten trugen Support und Projekte, steigende Ticketmengen drohten die Projektarbeit zu verdrängen. Wir haben beide Seiten in Atlassian aufgebaut, den Betrieb in Jira Service Management, die Vorhaben in Jira Software.

Der eigentliche Hebel lag in der neuen Supportstruktur. Der zentrale Service Desk wurde zum einzigen Eingangskanal, der alle Tickets annimmt, die Triage übernimmt und weiterleitet. Davor fängt eine Self-Service-Schicht mit Knowledge Base und Automatisierung wiederkehrende Anfragen ab. Standardisierte Aufgaben laufen auf einem eigenen Support-Level, und ein externer Dienstleister ist als zusätzliche Ebene sauber integriert, mit klarer Zuständigkeit und Statusverfolgung über Organisationsgrenzen hinweg.

Der Effekt trifft den Kern des Problems. Repetitive Arbeit wandert auf die unteren Level und in den Self-Service, die Spezialistenteams werden von Routinetickets entlastet. Es sind dieselben Spezialisten, die die Projekte tragen. Wer den Betrieb so strukturiert, dass nicht jede Anfrage an der teuersten Ebene landet, gewinnt Projektkapazität zurück, ohne eine Stelle zu schaffen.

Typische Fehlerquellen

• Der Support wird sauber in Jira Service Management abgebildet, die Projektarbeit läuft weiter über Excel und Meetings. Der Konflikt bleibt unsichtbar, weil nur eine Hälfte gemessen wird.
• Beide Welten liegen in Jira, aber ohne gemeinsame Kapazitätssicht. Zwei Systeme nebeneinander steuern den Zielkonflikt nicht besser als eines.
• Die Standortzuordnung fehlt oder ist uneinheitlich, dann lässt sich die Roadmap weder pro Werk filtern noch belastbar priorisieren.

Was zuerst zu klären ist

Vor der Konfiguration steht die Struktur. Welche Arbeit gehört in den Serviceprozess, welche in die Projektsteuerung, und wo verläuft die Grenze bei Aufgaben, die als Ticket beginnen und zum Projekt werden. Und welche Kennzahlen braucht die Geschäftsführung wirklich, um zu entscheiden, statt nur informiert zu werden.

Wer diesen Zielkonflikt strukturiert angehen will, beginnt mit einer Analyse der eigenen Arbeitsströme. Ein Process Impact Check macht sichtbar, wie viel Kapazität der Betrieb bindet, wo Projekte hängen und welche Struktur beide Welten zusammenführt: Kontakt