Issue Management meint das strukturierte Vorgehen, mit dem Organisationen aktuelle Probleme, offene Entscheidungen oder konfliktträchtige Themen erfassen, bewerten und bearbeiten. Der Begriff „Issue“ stammt aus dem Englischen. Er steht je nach Zusammenhang für „Thema“, „Streitfrage“, „Anliegen“ oder schlicht für ein Problem, das Aufmerksamkeit und eine Entscheidung erfordert.

Das Wichtigste in Kürze

„Issue“ ist ein aktuelles Problem, eine offene Frage oder ein strittiger Punkt.
Issue Management macht solche Issues sichtbar, priorisiert sie und führt sie zu einer Entscheidung oder Lösung.
Issue Management wird je nach Umfeld anders verstanden: Kommunikation, Projektarbeit, IT und Softwareentwicklung.
Ein gepflegtes Issue-Log oder Ticketsystem sorgt für Verantwortlichkeit, Fristen und Nachvollziehbarkeit.

Definition: Was bedeutet Issue Management?

Im Kern ist Issue Management ein Regelkreis aus Erfassen, Priorisieren, Bearbeiten und Nachhalten. Entscheidend ist nicht das Tool, sondern die klare Frage: Welches Issue liegt vor, wer trägt die Verantwortung, bis wann braucht es eine Entscheidung, und wie prüfen Sie, ob das Issue tatsächlich erledigt ist.

In der Unternehmenskommunikation fokussiert „Issues Management“ auf Themen, die in der Öffentlichkeit oder in relevanten Dialoggruppen entstehen und die Handlungsfähigkeit oder Ziele einer Organisation beeinflussen können. Dazu gehört, solche Themen früh zu erkennen, ihre Entwicklung zu beobachten und eine Position sowie Maßnahmen abzuleiten. Häufig fällt in diesem Zusammenhang der Begriff „Stakeholder“. Damit sind Personen oder Gruppen gemeint, die berechtigte Interessen an einem Thema haben oder davon betroffen sind (zum Beispiel Kunden, Mitarbeitende, Behörden, Anwohner, Verbände).

In Projekten wird Issue Management meist als Disziplin verstanden, mit der Sie aktuelle, bereits eingetretene Hindernisse oder Entscheidungsbedarfe steuern. Ein Issue ist dann „etwas von concern in the present“, also ein Problem, das jetzt besteht und eine Reaktion erfordert, während ein Risiko eine mögliche zukünftige Entwicklung beschreibt. Als zentrales Werkzeug dient das „Issue-Log“: eine lebende Dokumentation aller offenen und geschlossenen Issues, inklusive Status und Verantwortlichem.

In der Software- und Produktentwicklung hat sich „Issue“ zusätzlich als Sammelbegriff für Tickets etabliert. Ein Ticket kann ein Fehler („Bug“), eine Aufgabe, Feedback oder eine Idee sein. Das Issue Management wird dann oft über ein Issue-Tracking-System umgesetzt, das Tickets mit Metadaten wie Priorität, Zuständigkeit, Fristen und Status verwaltet. GitHub beschreibt Issues ausdrücklich als Mittel, um Ideen, Feedback, Aufgaben oder Bugs zu verfolgen und Arbeit zu planen, zu diskutieren und nachzuverfolgen.

openPR-Tipp: Legen Sie zu Beginn eines Projekts oder Produkts schriftlich fest, was bei Ihnen als „Issue“ zählt. So verhindern Sie, dass Entscheidungen, Aufgaben, Risiken und Änderungen in einer unscharfen Sammelkategorie verschwinden.

Abgrenzung zu ähnlichen Begriffen: Issue, Risiko, Incident, Problem und Change

Ein „Risiko“ ist eine mögliche, unsichere Entwicklung in der Zukunft. Es kann eintreten oder auch nicht. Ein „Issue“ ist dagegen eine aktuelle Angelegenheit, die bereits wirkt und deshalb eine konkrete Aktion oder Entscheidung verlangt. Diese Abgrenzung ist in der Praxis wichtig, weil sich das Vorgehen unterscheidet: Risiken planen Sie vorab, Issues lösen Sie im laufenden Betrieb.

Neben Risiko und Issue begegnen Sie im IT-Umfeld häufig dem Begriff „IT-Servicemanagement“, abgekürzt ITSM. ITSM beschreibt ein strukturiertes Vorgehen, mit dem IT-Teams IT-Services planen, bereitstellen und unterstützen. In diesem Umfeld werden Anfragen und Störungen meist als Tickets über einen Service Desk bearbeitet. Ein „Service Desk“ ist dabei die zentrale Anlaufstelle für Meldungen, Fragen und Serviceanfragen.

Innerhalb von ITSM sind „Incident“ und „Problem“ klar abgegrenzt. Ein Incident ist eine plötzliche oder drohende Störung der Serviceerbringung; das Ziel im Incident Management ist die schnelle Wiederherstellung des normalen Betriebs. Ein Problem bezeichnet die Ursache oder potenzielle Ursache für einen oder mehrere Incidents; das Problem Management sucht die Grundursache und verhindert Wiederholungen. Praktisch heißt das: Ein schneller Workaround (eine vorläufige Umgehungslösung) kann einen Incident beenden, ohne das zugrunde liegende Problem zu beseitigen.

Noch ein Begriff, der in Logs und Tickets oft auftaucht, ist „Change“ (Änderung). Im Projekt- und IT-Kontext meint Change eine Änderung an einem bereits geplanten oder umgesetzten Stand, die bewertet, entschieden und gesteuert werden muss. In ITIL 4, einem verbreiteten Best-Practice-Framework für ITSM, wird dafür die Praxis „Change Enablement“ beschrieben, die Änderungen so umsetzt, dass Risiken und Störungen minimiert werden. Wichtig ist die Trennung: Ein Issue kann einen Change auslösen, aber nicht jedes Issue ist automatisch ein Change.

Mehr Sichtbarkeit und Reichweite für Ihre Unternehmensnachrichten?

Verbreiten Sie Ihre Pressemitteilung digital über openPR und erreichen Sie genau Ihre Zielgruppe!

Jetzt GRATIS starten

Prozess: Issue Management vom Erfassen bis zum Schließen

Ein funktionierender Issue-Management-Prozess beginnt mit einem sauberen Eingangskanal. Ein Issue sollte nicht „irgendwo“ landen, sondern immer in einer nachvollziehbaren Form erfasst werden: als Eintrag im Issue-Log oder als Ticket im System. Das Log ist dabei keine bloße Liste, sondern ein Steuerungsinstrument. Denn erst wenn ein Issue eindeutig beschrieben ist, kann jemand Verantwortung übernehmen, eine Frist setzen und die Bearbeitung überprüfen.

Nach der Erfassung folgt die Einordnung. Dazu gehören mindestens drei Entscheidungen: Welcher Typ ist es (zum Beispiel Entscheidung, Abhängigkeit, Fehler, Lieferproblem, Kommunikationsrisiko), wie hoch ist der Einfluss (zum Beispiel auf Termine, Kosten, Qualität, Compliance), und wie dringlich ist das Issue. Auf dieser Basis vergeben Sie eine Priorität und benennen einen „Issue Owner“, also die Person, die das Issue bis zur Klärung treibt. Issue Owner bedeutet nicht zwingend „selbst lösen“, sondern „Verantwortung für Fortschritt und Entscheidung“.

Viele Issues scheitern nicht an Technik, sondern an fehlender Entscheidungsfähigkeit. Genau dafür dient Eskalation. Eskalation bedeutet, dass Sie ein Issue bewusst an eine Ebene mit höherer Entscheidungskompetenz oder mehr Ressourcen geben. Das funktioniert nur, wenn Sie Eskalationswege und Entscheidungsgremien vorab festlegen, zum Beispiel nach Fachlichkeit, Budget, Zeitkritik oder Risiko.

openPR-Tipp: Definieren Sie klare Eskalations-Trigger, zum Beispiel „ohne Entscheidung bis Datum X“ oder „Blocker für ein Release“. Das reduziert Diskussionen darüber, ob eskaliert werden „darf“, und schafft Verlässlichkeit.

Die Bearbeitung selbst folgt idealerweise einer einfachen Logik: Problem verstehen, Optionen bewerten, Entscheidung treffen, Umsetzung nachhalten, Abschluss dokumentieren. In Projekten bedeutet das oft: Informationen sammeln, Entscheidungsvorlage erstellen, Verantwortliche zusammenbringen, Entscheidung protokollieren und Auswirkungen auf Plan, Budget oder Scope (Leistungsumfang) aktualisieren. Die Projektpraxis kennt dafür neben dem Issue-Log meist weitere Logs, etwa für Risiken und Änderungen; genau diese Trennung hilft, sauber zu steuern.

In der Unternehmenskommunikation nutzt Issues Management zusätzlich Methoden der Umfeldbeobachtung. „Scanning“ meint eine zunächst breite, noch nicht vollständig spezifizierte Beobachtung relevanter Entwicklungen. „Monitoring“ meint die gezielte, fortlaufende Beobachtung bereits identifizierter Themen. Das ist das Gegenstück zum operativen Issue-Log: Statt einzelner Tickets steuern Sie Themenverläufe, Akteurspositionen und mögliche Eskalationsstufen in der öffentlichen Debatte.

Werkzeuge und Dokumentation: Issue-Log, Ticket-System und Issue Tracking

Für Issue Management reichen in kleinen Vorhaben oft einfache Mittel, etwa ein gepflegtes Issue-Log in einem geteilten Dokument. Entscheidend ist nicht das Format, sondern dass Sie Einträge nicht „verlieren“ und dass Sie Status, Owner und nächste Schritte zuverlässig aktualisieren. Größere Teams nutzen dafür ein Ticket-System. Ein Ticket-System ist eine Software, die Vorgänge als Tickets mit eindeutiger ID erfasst, Zuständigkeiten abbildet, Statusübergänge steuert und Kommentare sowie Anhänge nachverfolgbar speichert.

„Issue Tracking“ bezeichnet den toolgestützten Teil: Issues werden als Tickets angelegt, kategorisiert und entlang eines Workflows bearbeitet. Ein „Workflow“ ist dabei die definierte Abfolge von Status und Regeln (zum Beispiel „neu“ → „in Bearbeitung“ → „wartet auf Entscheidung“ → „erledigt“). Ein gutes Issue-Tracking-System macht Blockaden sichtbar, verhindert Doppelarbeit und schafft eine überprüfbare Historie.

In der Softwareentwicklung sind Issue-Tracker häufig eng mit Code-Workflows integriert. GitHub beschreibt Issues als flexible Einträge, um Ideen, Feedback, Aufgaben oder Bugs zu verfolgen, und erlaubt die Planung über Projekte sowie die Unterteilung in Unter-Issues. GitLab beschreibt Issues ebenfalls als Mittel, um Arbeit zu planen, zu priorisieren und teamübergreifend zu diskutieren, inklusive Zuweisungen und Fälligkeiten. Solche Funktionen unterstützen Issue Management, weil sie die „Kleinteiligkeit“ komplexer Arbeit abbilden, ohne dass der Überblick verloren geht.

Wenn Sie Jira nutzen, sollten Sie eine aktuelle Terminologie kennen: Atlassian ersetzt in Jira Cloud schrittweise den Begriff „Issue“ durch „Work“ beziehungsweise „Work item“. Atlassian weist zugleich darauf hin, dass APIs und viele Filter die Bezeichnung „Issue“ zunächst weiterführen, um Kompatibilität zu erhalten. Für Ihr Issue Management heißt das: Achten Sie in Dokumentationen und Schulungen auf gemischte Begriffe und erklären Sie sie einheitlich im Team.

openPR-Tipp: Reduzieren Sie Pflichtfelder im Ticket auf das Minimum, das zur Entscheidung reicht. Zu viele Pflichtangaben führen dazu, dass Issues gar nicht erst erfasst werden oder unpräzise „ausgefüllt“ werden. Präzision entsteht eher durch gute Vorlagen als durch viele Felder.

Praxisbeispiele: So funktioniert Issue Management im Alltag

Ein Projektbeispiel zeigt die Abgrenzung zwischen Risiko und Issue. Sie planen eine Lieferung eines kritischen Bauteils. Solange nur die Möglichkeit besteht, dass sich der Liefertermin verschiebt, dokumentieren Sie das als Risiko und planen Gegenmaßnahmen. Sobald der Lieferant verbindlich meldet, dass die Lieferung tatsächlich später kommt, ist das ein Issue: Es betrifft Ihre Zeitachse jetzt, und Sie müssen aktiv entscheiden. In diesem Moment gehört der Eintrag ins Issue-Log, inklusive Owner, Frist und Entscheidungspfad (zum Beispiel alternative Beschaffung oder Plananpassung).

Ein typischer Fehler in solchen Situationen ist das „Parken“ ohne nächste Aktion. Besser ist ein eindeutiger nächster Schritt: Wer klärt bis wann, welche Option realistisch ist, und welches Gremium entscheidet. Genau hier wird Eskalation praktisch: Nicht als Konflikt, sondern als Mechanismus, um rechtzeitig Entscheidungskompetenz zu aktivieren.

In der Softwareentwicklung beginnt ein gutes Issue Management häufig bei der Qualität der Fehlermeldung. Ein Bug-Ticket wird lösbar, wenn es reproduzierbar ist: Was wurde erwartet, was ist passiert, unter welchen Bedingungen, seit wann, und wie groß ist der Impact. Danach folgt die Triage (erste Einordnung), die Priorisierung und die Zuordnung an ein Team. Systeme wie GitHub Issues und GitLab Issues unterstützen diesen Ablauf durch Metadaten wie Zuweisungen, Fälligkeiten, Labels und Unter-Issues beziehungsweise Hierarchien.

Ein drittes Beispiel betrifft die Unternehmenskommunikation. Stellen Sie sich vor, in Ihrer Branche entsteht eine öffentliche Debatte über einen neuen regulatorischen Standard. Das Issue ist hier nicht „ein Ticket“, sondern ein Thema mit Akteuren, Positionen und Dynamik. Issues Management startet dann mit Scanning, um frühe Signale zu erkennen, und wechselt bei Relevanz in Monitoring, um Verlauf, Argumente und Stakeholder-Positionen systematisch zu verfolgen. Anschließend legen Sie eine Position fest und stimmen intern ab, ob neben Kommunikation auch organisatorische Anpassungen nötig sind.

openPR-Tipp: Trennen Sie in der Kommunikation sauber zwischen „Faktenlage“ und „Position“. Ein Issue eskaliert oft, weil externe Wahrnehmung und interne Fakten vermischt werden. Eine klare Trennung beschleunigt Entscheidungen und reduziert Widersprüche in Aussagen.

Qualitätskriterien und Kennzahlen: Woran Sie gutes Issue Management erkennen

Gutes Issue Management erkennen Sie an der Verlässlichkeit des Systems, nicht an der Anzahl der Tickets. Ein Issue-Log erfüllt seinen Zweck, wenn es in Statusrunden aktiv genutzt wird, wenn Owners real Verantwortung übernehmen und wenn Entscheidungen nachvollziehbar dokumentiert sind. Viele Projektmanager empfehlen außerdem, erledigte Issues nicht zu löschen, weil die Historie für Lessons Learned, Stakeholder-Kommunikation und spätere Referenz nützlich bleibt.

Kennzahlen helfen, typische Engpässe sichtbar zu machen. In Projekten betrachten Teams häufig die Durchlaufzeit (Zeit von Erfassung bis Abschluss), die Anzahl offener Issues nach Priorität und die Quote wiedereröffneter Issues. In ITSM-Kontexten kommen servicebezogene Kennzahlen hinzu. Hier taucht oft der Begriff „Service Level Agreement“, abgekürzt SLA, auf. Ein SLA ist eine verbindliche Vereinbarung über Servicequalität, zum Beispiel Reaktions- oder Wiederherstellungszeiten. Incident- und Problemmanagement werden häufig auch daran gemessen, ob diese Vereinbarungen eingehalten werden.

Ein weiteres Qualitätsmerkmal ist die saubere Übergabe zwischen Issue, Problem und Change. Wenn ein Incident durch einen Workaround gelöst ist, aber die Grundursache weiterhin besteht, braucht es häufig ein Problem-Record und später einen Change, um die Ursache zu entfernen. Atlassian beschreibt diese Trennung zwischen schneller Wiederherstellung und Ursachenbeseitigung ausdrücklich. Diese Logik können Sie auch außerhalb von ITIL nutzen: Kurzfristig stabilisieren, langfristig Ursache beheben, und Änderungen kontrolliert umsetzen.

openPR-Tipp: Legen Sie eine klare Definition für „Done“ fest. Ein Issue ist erst abgeschlossen, wenn die Auswirkung nicht mehr besteht, die Entscheidung dokumentiert ist und die Folgearbeiten (zum Beispiel Change, Test oder Kommunikationsmaßnahme) als eigene Einträge sichtbar sind.

FAQ

Was sollte in einem Issue stehen, damit es bearbeitbar ist?
Ein Issue ist bearbeitbar, wenn Sie Auswirkungen und Erwartung klar beschreiben. In Projekten reicht oft eine knappe Problembeschreibung plus Impact, Owner, Priorität und ein nächster Schritt. In der Softwareentwicklung kommt hinzu, dass Sie einen Bug reproduzierbar beschreiben: Bedingungen, Schritte, erwartetes Verhalten, tatsächliches Verhalten und seit wann das Problem auftritt. Issue-Tracker unterstützen diese Struktur über Vorlagen und Metadaten.

Wann sollten Sie ein Issue eskalieren?
Eskalation ist sinnvoll, wenn das Team die Entscheidung nicht selbst treffen kann, wenn Ressourcen fehlen oder wenn ein Termin nicht mehr haltbar ist. Typische Auslöser sind Blockaden durch Abhängigkeiten, ausbleibende Entscheidungen oder ein hoher Schaden bei Verzögerung. Wirksam wird Eskalation nur, wenn Sie vorher festlegen, wer in welchem Fall entscheiden darf und wie schnell.

Worin unterscheidet sich Issue Management von Bug Tracking?
Bug Tracking ist ein Spezialfall des Issue Managements. „Bug“ meint einen Softwarefehler; Issue Management umfasst darüber hinaus Aufgaben, Fragen, technische Schulden, Abhängigkeiten oder Verbesserungen. GitHub beschreibt Issues explizit als Tracking für Ideen, Feedback, Aufgaben oder Bugs, also nicht ausschließlich Fehler.

Sollten geschlossene Issues im System bleiben?
Ja, in der Regel ist das sinnvoll. Die Historie hilft bei Rückfragen, Audits, Lessons Learned und beim Erkennen wiederkehrender Muster. Außerdem lassen sich aus geschlossenen Issues oft neue Risiken ableiten oder Prozessverbesserungen begründen. Projektmanagement-Vorlagen empfehlen ausdrücklich, dokumentierte Issues nicht zu entfernen, auch wenn sie gelöst sind.

Kann ein Issue gleichzeitig ein Change sein?
Ein Issue kann einen Change erforderlich machen, ist aber nicht automatisch selbst ein Change. Ein Issue beschreibt ein aktuelles Problem oder einen Entscheidungsbedarf. Ein Change beschreibt eine gesteuerte Änderung an einem bestehenden Stand, die Sie abwägen, freigeben und umsetzen. In ITIL 4 zielt Change Enablement darauf, Änderungen mit minimalem Risiko und minimaler Störung umzusetzen. Trennen Sie beides, damit Ihnen weder Entscheidungen noch Auswirkungen „durchrutschen“.

Issue Management: Bedeutung und Anwendung in der Praxis