Was der KI-Text-Block macht

Der Dashboard-Block ist ein konfigurierbarer Bereich auf dem Projekt-Dashboard. Du schreibst einen Prompt mit Variablen, die KI generiert daraus einen Text. Der Block kann bis zu 8 Mal pro Dashboard eingebunden werden, nützlich wenn man jeweils einen anderen Prompt benötigt.

Die Konfiguration besteht aus drei Feldern:

• Titel: Überschrift des Blocks (z.B. “Projektstatus”)
• Prompt: Die Anweisung an die KI, inklusive Variablen
• Model-Tags: Welches KI-Modell den Block generiert

Das Ergebnis wird 6 Stunden gecacht. Danach wird der Prompt beim nächsten Seitenaufruf erneut ausgeführt.

Voraussetzungen

Für den KI-Dashboard-Block brauchst Du:

1. Redmine Automation Plugin - Basis für das AI Plugin
2. Redmine AI Plugin - stellt den KI-Text-Block bereit
3. Ein konfiguriertes KI-Modell mit Model-Tags
4. Die Berechtigung “KI-Aufrufe ausführen”

Der Block funktioniert über das Dashboard-System, sobald das AI Plugin im Einsatz ist.

Das AI Plugin ist für AlphaNodes Redmine Hosting Kunden über unseren Enterprise Support oder als einzelnes AI Add-On monatlich zubuchbar.

Die Variable project.metrics

Der entscheidende Baustein ist die Variable {%project.metrics%}. Sie liefert automatisch aggregierte Projektdaten, die als Kontext an die KI übergeben werden. Welche Daten enthalten sind, hängt von den Berechtigungen des ausführenden Benutzers ab.

Beispiele für enthaltene Daten

Die Variable deckt verschiedene Bereiche ab, unter anderem:

• Ticket-Statistiken (offen/geschlossen, nach Tracker und Priorität, überfällige Tickets)
• Zeiterfassung und Schätzgenauigkeit
• Wöchentliche Trends (letzte 4 Wochen)
• Versions-Fortschritt
• Letzte Aktivität im Projekt
• Anzahl Mitglieder nach Rolle

Welche Daten konkret enthalten sind, hängt von den Berechtigungen des ausführenden Benutzers und den aktiven Modulen ab. Die vollständige Aufstellung findest Du in der Plugin-Dokumentation.

Warum Variablen? Ein Prompt ohne Variablen wie “Erstelle einen Projektstatus” liefert kein brauchbares Ergebnis - die KI kennt Dein Projekt nicht und hat keine Daten. Erst durch Variablen wie {%project.metrics%} oder {%query=47|table%} bekommt die KI die tatsächlichen Zahlen, Tickets und Trends als Kontext mitgeliefert. Damit kann sie konkrete Aussagen treffen (“5 Tickets sind überfällig”) statt allgemeiner Hinweise (“prüfen Sie ob Tickets überfällig sind”).

Praxisbeispiel: Wöchentlicher Projektstatus

Ein typischer Prompt für den KI-Text-Block:

Erstelle einen kurzen Statusbericht für das Projekt {%project.name%}
für KW {%week%} / {%year%}:

{%project.metrics%}

Hebe besonders überfällige Aufgaben und kritische Prioritäten hervor.
Fasse die wöchentlichen Trends zusammen.

Die KI erhält damit alle aktuellen Projektdaten und generiert daraus einen lesbaren Bericht. Das Ergebnis enthält typischerweise:

• Eine Zusammenfassung der aktuellen Lage (z.B. “42 offene Tickets, davon 5 überfällig”)
• Auffälligkeiten aus den Trends (z.B. “Ticketzugang hat sich gegenüber Vorwoche verdoppelt”)
• Konkrete Hinweise auf Probleme (z.B. “3 Tickets sind seit über 30 Tagen ohne Aktualisierung”)

Was genau die KI daraus macht, hängt vom eingesetzten Modell und der Qualität des Prompts ab.

Weitere Prompt-Beispiele

Risiken und Engpässe:

Analysiere die folgenden Projektdaten von {%project.name%}
und identifiziere Risiken und Engpässe:

{%project.metrics%}

Konzentriere Dich auf: überfällige Tickets, nicht zugewiesene Aufgaben,
Abweichungen bei der Zeitschätzung und Versionen mit geringem Fortschritt.

Stakeholder-Update:

Erstelle ein kurzes Stakeholder-Update für {%project.name%}
(Stand: {%date%}):

{%project.metrics%}

Formuliere verständlich für Nicht-Techniker.
Maximal 5 Sätze. Fokus auf Fortschritt, Risiken und nächste Schritte.

Kombination mit gespeicherten Abfragen:

Statusbericht für {%project.name%}:

Projektmetriken:
{%project.metrics%}

Kritische offene Tickets:
{%query=47|table%}

Fasse den Projektstatus zusammen und bewerte die kritischen Tickets.

Hier wird {%query=47|table%} genutzt, um die Ergebnisse einer gespeicherten Abfrage (z.B. “Alle kritischen offenen Tickets”) als Tabelle in den Prompt einzubetten. Die Abfrage muss für den ausführenden Benutzer sichtbar sein.

Datenschutz: Wer nur aggregierte Statistiken und keine personenbezogenen Daten an die KI senden will, sollte ausschließlich die Variable {%project.metrics%} verwenden. Sie liefert nur Anzahlen und Kennzahlen - keine Ticket-Beschreibungen, keine Namen. Variablen wie {%query=47|table%} hingegen übertragen Ticket-Details inklusive Betreff und Zuständigem an den KI-Anbieter. Wer auch mit Ticket-Details auf der sicheren Seite sein will, setzt auf ein lokal betriebenes KI-Modell über Ollama - damit verlassen die Daten nicht das eigene Netzwerk.

Für wen ist der Dashboard Block nützlich?

Projektleiter und Teamleiter, die regelmäßige Berichte liefern müssen und schnell den Überblick brauchen. Den Block einmal einrichten, Prompt schreiben - und der Projektstatus steht automatisch auf dem Dashboard. Weitere Details zur Konfiguration (Berechtigungen, Model-Tags, mehrere Blöcke kombinieren) findest Du in der Plugin-Dokumentation abrufbar über den Kundenbereich.

Integriert, nicht draufgesetzt

Der Grund, warum ein einziger Prompt mit {%project.metrics%} einen vollständigen Projektbericht liefern kann: Das AI Plugin ist kein isoliertes Werkzeug, sondern greift direkt auf die Daten des Reporting und Automation Plugins zu. Die Variablen, die Metriken-Berechnung und das Dashboard-System arbeiten zusammen - deshalb reicht eine Variable, um aktuelle Ticketzahlen, Trends, Versionsfortschritt und Zeiterfassung in einen Bericht zu bündeln.

Weiterführende Infos

• Redmine AI Plugin - alle KI-Funktionen im Überblick
• KI-gestützte Automatisierung - AI und Automation Plugin kombinieren
• Redmine Hosting Funktionsübersicht - alle Funktionen auf einen Blick
• Enterprise Support - Support-Pakete mit AI Plugin

Voraussetzungen

Für die KI-gestützte Automatisierung brauchst Du drei Komponenten:

1. Redmine Automation Plugin - welches die Regel-Engine mit Triggern, Bedingungen und Aktionen liefert
2. Redmine AI Plugin - welches die KI-Aktionen im Automation Plugin ergänzt. Beide Plugins stammen von AlphaNodes und sind aufeinander abgestimmt
3. Ein geeignetes Sprachmodell (LLM) - entweder lokal über Ollama (DSGVO-konform) oder über einen Cloud-Anbieter wie Azure OpenAI. Welche Modelle sich eignen, erfährst Du im Abschnitt Welche KI-Modelle eignen sich?

LLM (Large Language Model): Ein Sprachmodell ist eine KI, die natürliche Sprache versteht und erzeugt - vergleichbar mit ChatGPT. Es gibt Cloud-basierte Modelle (z.B. von OpenAI oder Anthropic) und lokale Modelle, die auf eigenen Servern laufen (z.B. über Ollama).

Das Automation Plugin ist bei vielen Hostingkunden bereits im Einsatz. Das AI Plugin ist über unseren Enterprise Support oder als einzelnes AI Add-On monatlich buchbar.

Warum Automatisierung mit KI sinnvoll ist

Mit dem Automation Plugin lassen sich viele typische Ticketbearbeitungen regelbasiert lösen: Enthält ein Ticket beispielsweise den Begriff “Server down”? Kann man die Priorität “Hoch” setzen und dem DevOps-Team zuweisen. Solche Regeln funktionieren zuverlässig (sowohl beim SAVE-Event als auch beim Zeitlichen-Auslöser), solange die Kriterien eindeutig sind.

Aber viele Support-Tickets sind selten eindeutig. “Datenexport funktioniert nicht” kann ein Frontend-Bug, ein Datenbankproblem oder eine falsche Konfiguration sein. Starre “If-Then”-Regeln scheitern hier, weil sie den Inhalt nicht verstehen - sie können nur nach vorgegebenen Stichworten oder Feldern filtern.

Das AI Plugin ergänzt das Automation Plugin um zusätzliche KI-Aktionen, die den Inhalt eines Tickets tatsächlich lesen, verstehen und darauf basierend Entscheidungen treffen. Das Ergebnis sind:

• Schnellere Reaktionszeiten: Tickets werden kurz nach Eingang klassifiziert und zugewiesen, nicht erst, wenn jemand Zeit hat, sie zu lesen
• Konsistente Qualität: Die KI wendet dieselben Kriterien auf jedes Ticket mit den definierten Bedingungen an - ohne Ausnahme auch nach Feierabend und am Wochenende
• Entlastung des Teams: Statt sich auf einen Mitarbeiter zu verlassen, der diese Zuweisung bisher manuell so nebenbei erledigt hat, können sich Mitarbeiter auf die eigentliche Problemlösung konzentrieren
• Bessere Nachvollziehbarkeit: Die KI dokumentiert ihre Entscheidung als Kommentar im Ticket - jeder kann nachvollziehen, warum ein Ticket so klassifiziert wurde

Für wen ist die Kombination interessant?

• Support-Teams mit hohem Ticketaufkommen: Wer täglich Dutzende oder hunderte Tickets per E-Mail bekommt und diese manuell sichtet, spart mit einer automatisierten KI-Einordnung erheblich Zeit
• Teams ohne dedizierten Dispatcher: In kleineren Teams übernimmt oft ein Mitarbeiter die Ticket-Zuweisung nebenbei. Die KI-Automatisierung macht diese Rolle überflüssig
• Unternehmen mit mehreren Fachbereichen: Je mehr mögliche Zuständige es gibt, desto schwieriger wird die manuelle Zuordnung. Die KI erkennt anhand des Inhalts, welches Team gefragt ist
• Organisationen mit Compliance-Anforderungen: Behörden, Finanzdienstleister oder ISO-zertifizierte Unternehmen profitieren von der lückenlosen Protokollierung jeder KI-Entscheidung im Reporting Log
• Teams mit Schichtbetrieb oder internationalem Support: Die KI arbeitet rund um die Uhr - auch nachts, am Wochenende und an Feiertagen werden Tickets sofort eingeordnet

Was die Kombination ermöglicht

Das Automation Plugin basiert auf individuell festgelegten Regeln: Wenn X passiert und Bedingung Y erfüllt ist, führe Aktion Z aus. Es bringt zahlreiche sinnvolle Aktionen mit - von Statusänderungen über E-Mail-Versand bis hin zu Webhooks und Shell-Befehlen.

Mit dem AI Plugin sind zusätzliche Aktionen verfügbar:

KI-Ticketänderung - die KI analysiert das auslösende Ticket und gibt strukturierte Änderungen zurück:

• Tags setzen
• Status ändern
• Priorität anpassen
• Zuständigen zuweisen
• Fortschritt setzen
• Kommentar hinzufügen

KI-Tool - die KI bekommt vollen Zugriff auf Redmine und kann auf Basis mitgelieferter Tools eigenständig handeln: Ticket erstellen, Wiki-Seite schreiben, Zeitbuchungen anlegen.

Das Besondere: Beide Aktionen unterstützen Variablen. Der Prompt wird vor dem KI-Aufruf mit den tatsächlichen Ticket-Daten befüllt die Du für relevant hältst - Betreff, Beschreibung, Autor, Projekt, benutzerdefinierte Felder und mehr.

Praxisbeispiel zu einer intelligenten Ticket-Zuweisung

Hier mal ein typisches Einsatzszenario: Dein Team betreut mehrere Kunden und bekommt Support-Tickets per E-Mail. Bisher liest ein Teamleiter jedes Ticket, entscheidet über Dringlichkeit und weist es manuell einem freien Mitarbeiter zu. Das kostet den Mitarbeiter täglich ca. 30-60 Minuten Zeit, die er an anderer Stelle deutlich besser nutzen kann.

Die Automation-Regel dazu

Wir arbeiten mit dem Trigger “Event - Ticket speichern”, damit die Regel immer bei einem Speichervorgang geprüft wird und Änderungen zeitnah durchgeführt werden.

Die nachfolgenden Bedingungen sind nur beispielhaft und müssen auf Deine Bedingungen angepasst werden.

Der KI-Prompt (Action: KI-Ticketänderung)

Prompt: Ein Prompt ist die Anweisung an die KI - ein Text, der beschreibt, was sie tun soll. Im Automation Plugin wird der Prompt einmal definiert und dann bei jedem passenden Ticket automatisch ausgeführt.

Du bist ein Support-Triage-Agent.

Analysiere dieses Support-Ticket:
- Betreff: {issue.subject}
- Beschreibung: {issue.description}
- Erstellt von: {issue.author}
- Projekt: {project.name}

Klassifiziere das Ticket nach folgenden Regeln:

PRIORITÄT:
- "Dringend": Produktionsausfall, Datenverlust, Sicherheitslücke
- "Hoch": Funktionalität stark eingeschränkt, viele User betroffen
- "Normal": Einzelne Funktion fehlerhaft, Workaround vorhanden
- "Niedrig": Kosmetisch, Verbesserungsvorschlag

ZUWEISUNG:
- "mueller" bei Backend/API/Datenbank/Performance
- "schmidt" bei Frontend/UI/CSS/JavaScript
- "weber" bei Infrastruktur/Deployment/Server
- "DevOps Gruppe" bei Unsicherheit

TAGS:
Setze passende Tags aus: bug, feature-request, question, security, performance, ui, api, database, infrastructure

Füge als Kommentar (notes) eine kurze Begründung hinzu.

Als Model-TAGs wird z.B. automation gewählt - hinter dem sich beispielsweise ein schnelles, günstiges Modell versteckt, welches für Klassifizierungsaufgaben geeignet ist.

Was passiert als nächstes?

Sobald die Regel aktiv ist, wäre der beispielhafte Ablauf wie folgt:

1. Du erhältst eine Supportanfrage mit dem Betreff “Datenexport bricht nach 2 Minuten ab”
2. Die Automation-Regel greift: neues Ticket, richtiger Tracker, richtiger Status
3. Das AI Plugin wird aufgerufen. Die Variablen im Prompt werden durch die Ticket-Daten ersetzt
4. Die KI analysiert im Hintergrund den Inhalt und führt die geforderten Tätigkeiten durch
5. Das Automation Plugin wendet die Änderungen auf das Ticket an: Priorität wird auf “Hoch” gesetzt, mueller wird zugewiesen, Tags werden vergeben, die KI-Begründung erscheint als Kommentar
6. mueller bekommt eine Benachrichtigung und sieht ein fertig klassifiziertes Ticket mit Kontext

Ergebnis: Vom Eingang der Supportanfrage bis zum korrekt zugewiesenen, priorisierten Ticket vergeht nur wenig Zeit und man erhält bei Bedarf auch eine Begründung bezüglich der durchgeführten Änderungen.

Weitere Kombinationsmöglichkeiten

Diese Ticket-Zuordnung ist nur ein Beispiel. Die Kombination aus Automation und AI Plugin eignet sich überall dort, wo regelbasierte Automatisierung an ihre Grenzen stößt:

• Zeitgesteuerte Ticket-Analyse: Eine geplante Regel prüft wöchentlich alle offenen Tickets und markiert solche, die seit 14 Tagen keine Aktivität zeigen. Die KI liest den letzten Stand und schreibt einen Kommentar mit einer Empfehlung: nachfragen, eskalieren oder schließen.
• Automatisches Tagging bei Änderungen: Bei jeder Ticket-Aktualisierung prüft die KI, ob die bestehenden Tags noch zum aktuellen Inhalt passen und aktualisiert sie bei Bedarf.
• Intelligentes Routing nach Projektkontext: Die KI liest nicht nur das Ticket, sondern nutzt die read-only Tools, um ähnliche bereits gelöste Tickets zu finden. Basierend darauf weist sie das Ticket dem Kollegen zu, der ähnliche Probleme bereits erfolgreich gelöst hat.
• Qualitätsprüfung neuer Tickets: Bevor ein Ticket den Status “Neu” verlässt, prüft die KI ob alle notwendigen Informationen vorhanden sind und hinterlässt einen Kommentar mit Rückfragen, falls Angaben fehlen.

Welche KI-Modelle eignen sich?

Nicht jedes Sprachmodell kann zuverlässig Tickets analysieren und als strukturiertes JSON antworten. Für die Automation-Aktionen muss ein Modell zwei Dinge beherrschen: den Inhalt eines Tickets im Kontext bewerten und das Ergebnis in einem vorgegebenen Format zurückgeben. Das setzt eine gewisse Modellgröße und Instruktionstreue voraus.

Gut geeignet:

Eingeschränkt geeignet:

Kleine Modelle unter 14B Parametern (z.B. Llama 3.2 8B, Phi-3 Mini) können bei einfacher Klassifizierung funktionieren, liefern aber bei komplexeren Prompts oder deutschsprachigen Tickets oft ungenaue oder unvollständige JSON-Antworten. Für produktiven Einsatz empfehlen wir mindestens ein Modell mit 32B Parametern oder eines der Cloud-Modelle.

Wer DSGVO-konform arbeiten möchte, setzt auf Ollama mit einem lokalen Modell. Über unser Redmine AI Hosting übernehmen wir den Betrieb des Ollama-Servers auf dedizierter Hardware in Deutschland - ohne dass Du eigene GPU-Server verwalten musst.

Kostenkontrolle: Token-Limits und Model-Tags

Token: Ein Token entspricht ungefähr einem Wort oder Wortteil. Jeder KI-Aufruf verbraucht Tokens - sowohl für die Anfrage (Dein Prompt + Ticket-Daten) als auch für die Antwort der KI. Die Kosten bei Cloud-Anbietern werden pro Token abgerechnet.

KI-Aktionen in Automation-Regeln können schnell viele API-Aufrufe erzeugen. Das AI Plugin bietet dafür zwei Stellschrauben:

Model-Tags legen fest, welches KI-Modell eine Regel verwendet. Ein schnelles, günstiges Modell reicht für Klassifizierung. Komplexere Analysen bekommen ein leistungsfähigeres Modell.

Token-Limits begrenzen den Verbrauch pro Modell auf ein tägliches oder monatliches Budget. Ist das Limit erreicht, wird die KI-Aktion übersprungen - die restlichen Aktionen der Regel laufen trotzdem weiter. Ein Hinweis im Log dokumentiert den Grund.

So behältst Du die Kontrolle über die Kosten, auch wenn täglich hunderte Tickets verarbeitet werden.

Die Einrichtung in 4 Schritten

Wer beide Plugins nutzt, muss bei der Einrichtung Folgendes beachten:

1. KI-Modell konfigurieren: Im AI Plugin ein Modell anlegen (z.B. Ollama lokal oder Azure OpenAI), Model-Tag “automation” vergeben, Token-Limit setzen
2. Automation-Regel erstellen: Trigger, Bedingungen und Filter festlegen (z.B. neues Support-Ticket)
3. KI-Aktion hinzufügen: “AI Issue Change” als Aktion wählen, Prompt mit Variablen schreiben, Model-Tag “automation” auswählen
4. Testen und aktivieren: Regel mit einem Test-Ticket prüfen, Ergebnis im Log kontrollieren, Regel aktivieren

Der eigentliche Mehrwert dieser Plugin-Kombination

Das Automation Plugin übernimmt das “Wann” und “Unter welchen Bedingungen”, das AI Plugin übernimmt das “Was genau tun”. Zusammen ergibt das einen vollautomatischen Prozess ohne manuellen Auslöser.

Und ein oft unterschätzter Punkt: Die Automation-Bedingungen sind ein wichtiger Kostenfilter. Denn nicht jedes Unternehmen betreibt einen eigenen Ollama Server, sondern nutzt oft eine tokenbasierte Abrechnung. Ohne diese Automation-Bedingungen würde die KI bei jeder Ticket-Änderung aufgerufen - auch bei Statuswechseln, Kommentaren, Feldänderungen. Die Bedingungen (nur neue Tickets, nur bestimmter Tracker, nur unzugewiesen etc.) sorgen dafür, dass die KI nur dann läuft, wenn es tatsächlich sinnvoll ist. Das spart Token und damit Geld.

Wer das Reporting Plugin im Einsatz hat, profitiert zusätzlich vom integrierten Anwendungs-Log. Jeder KI-Aufruf wird dort automatisch protokolliert - mit Modellname, Token-Verbrauch und den durchgeführten Änderungen. Gerade bei automatisierten Prozessen, die ohne manuelles Zutun laufen, schafft das die nötige Transparenz: Was hat die KI wann entschieden und warum? Besonders relevant ist das für Unternehmen mit Dokumentationspflichten - etwa in regulierten Branchen wie Behörden, Finanzdienstleistung oder Gesundheitswesen, aber auch für ISO-zertifizierte Organisationen, die Prozessentscheidungen lückenlos nachweisen müssen.

Zudem lassen sich KI-gestützte Automatisierungen über die Zusammenarbeit mit weiteren AlphaNodes Plugins auf andere Entitäten ausweiten - etwa Helpdesk-Tickets, User, DB-Einträge oder Passwort-Einträge. Die KI-Aktionen sind damit nicht auf klassische Tickets beschränkt, sondern lassen sich überall dort einsetzen, wo das Automation Plugin einen Trigger bereitstellt.

Redmine AI Plugin: Als Aufsatz für das Automation Plugin unterstützt Dich die KI mit unserem neuen Feature beim schnelleren Erreichen Deiner Ziele. Das Plugin stellt die Verbindung zu externen KI-Anbietern her, die Du selbst auswählst und bei denen Du ein eigenes Konto bzw. Abonnement benötigst. Mit dieser Anbindung kannst Du Tickets zusammenfassen, Antwortentwürfe erstellen, Wiki-Inhalte analysieren und eigene KI-Prompts definieren.

Weiterführende Infos

• Redmine AI Plugin - KI-Funktionen für Redmine
• Redmine Automation Plugin - Automatisierung für Redmine
• DSGVO-konforme AI-Integration - KI-Einsatz ohne Datenschutz-Risiken
• AI Entscheidungshilfe - ist das AI Plugin für Dich geeignet?

• Eigene offene Aufgaben auf einen Blick sehen
• Aufgabenstatus schnell ändern (z. B. per Drag & Drop)
• Unterschiedliche Ansichten je nach Rolle: “Was muss ich tun?”, “Was habe ich erstellt?”, “Was ist überfällig?”

Das Reporting Plugin deckt diese Anforderungen mit zwei Funktionen ab: Zählerboxen und dem Taskboard.

Zählerboxen: Ticket-Abfragen als Zahl

Zählerboxen sind kompakte Kacheln die man mittels Dashboard Block “Abfragegruppen” auf der Startseite oder Projektübersicht platziert. In diesen wird jeweils eine Zahl dargestellt, die zu einer Ticket-Abfrage führt. Per Klick gelangt man direkt zur zugehörigen Ticketliste oder der Board-Ansicht (je nachdem was man als Darstellung eingestellt hat).

Typische Zählerboxen für Mitarbeiter

• Mir zugewiesen: Alle offenen Tickets, die dir zugewiesen sind
• Überfällig: Tickets mit überschrittenem Fälligkeitsdatum
• Gemeldete Tickets: Tickets, die du selbst erstellt hast
• Diese Woche fällig: Aufgaben mit Fälligkeit in der laufenden Woche
• Ohne Zuweisung: Offene Tickets im Projekt, die noch niemandem zugewiesen sind

So funktioniert es

Jede Zählerbox basiert auf einer gespeicherten Ticket-Abfrage. Ticket-Abfragen können von Administratoren oder von Anwendern mit entsprechender Berechtigung angelegt werden.

Um Zählerboxen für alle Anwender auf der Startseite einzurichten, benötigt man das Recht, Dashboard-Blöcke für andere Benutzer zu konfigurieren (z.B. als Administrator möglich). Und für andere Benutzer öffentliche Abfragen einzurichten. Sobald die Funktion “Abfrageboxen” in den Plugin-Einstellungen aktiv und konfiguriert ist kannst Du los legen.

Damit die Zählerboxen für alle Mitarbeiter sinnvoll nutzbar sind, empfiehlt es sich, Ticket-Abfragen so einzurichten, dass sie:

• für alle Benutzer sichtbar sind (öffentliche Abfrage)
• projektübergreifend gelten, also nicht auf ein einzelnes Projekt beschränkt sind
• ich-bezogen sind, also Zugewiesen an = ich

So muss die Abfrage nur einmal angelegt werden und gilt für das gesamte Team. Sowohl global als auch projektbezogen.

Zählerboxen einrichten

1. Erstelle eine Ticket-Abfrage mit den gewünschten Filtern (z. B. Status = offen, Zugewiesen an = aktueller Benutzer)
2. Als Darstellung wähle “Board” aus (nicht Liste) und klicke auf “Abfrage speichern”.
3. Fülle die notwendigen Felder aus (Name, Sichbarkeit, für alle Projekte etc.) und aktiviere die Option “Zählerbox aktivieren”.
4. Wähle eine Abfragegruppe aus, vergib einen Namen, eine Farbe, eine Gewichtung etc. und klick auf “Speichern”.
5. Die erste Zählerbox sollte entsprechen der Plugin-Konfiguration im entsprechenden Dashboard-Block “Abfrageboxen” erscheinen.
6. Fahre fort mit weiteren Abfragen.

Taskboard: Tickets in einer Kanban-Ansicht

Das Taskboard zeigt Tickets als Karten in Spalten, geordnet nach Status. Tickets lassen sich per Drag & Drop zwischen den Spalten verschieben, was den Status direkt in Redmine ändert.

Was du damit tun kannst

• Status ändern: Ziehe ein Ticket von “Neu” nach “In Bearbeitung” oder “Erledigt”
• Zuweisungen ändern: Über die Avatar-Leiste kannst du Tickets direkt anderen Mitarbeitern zuweisen
• Gruppieren: Lass dir Tickets nach Status, Priorität, Kategorie oder anderen Feldern gruppiert anzeigen
• Spaltenübersicht: Jede Spalte zeigt die Gesamtanzahl der enthaltenen Tickets, sodass erkennbar ist, wo sich Aufgaben stauen

Zählerboxen und Taskboard im Zusammenspiel

Zählerboxen und Taskboard ergänzen sich: Die Zählerbox zeigt die Anzahl, ein Klick öffnet die Liste oder das Board. Auch im Taskboard selbst zeigt jede Spalte die Gesamtanzahl der Tickets.

Das ergibt zwei Ebenen der Übersicht:

• Startseite: Wie viele Aufgaben liegen in welcher Kategorie?
• Taskboard: Wie sind die Aufgaben auf die Statusspalten verteilt?

Mobiler Zugriff

Redmine ist eine Webanwendung und läuft im Browser, auch auf Smartphone und Tablet. Die Oberfläche passt sich an kleinere Bildschirme an, eine separate App ist nicht erforderlich. Die Qualität der mobilen Darstellung hängt vom verwendeten Redmine-Theme ab.

Redmine vs. separates Tool: Was zu bedenken ist

Wer bereits Redmine im Einsatz hat, kann mit dem Reporting Plugin auf ein zusätzliches Tool verzichten. Die Daten bleiben im bestehenden System, Berechtigungen greifen wie gewohnt, und es entfallen Lizenzkosten für ein weiteres Produkt.

Zählerboxen geben Deinen Mitarbeitern sofortigen Überblick, das Drag & Drop Board ermöglicht schnelles Arbeiten im Kanban-Stil, und der mobile Zugriff funktioniert ganz ohne App über den Browser - mit den regulären Zugangsdaten.

Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Das kostenpflichtige Reporting Plugin gibt es einzeln oder als Teil unseres Business-Class Bundle, sowie dem Enterprise+ Bundle. Die hier beschriebene Funktion kann in unserer Online-Demo ausgiebig getestet werden. Die hier beschriebene, erweiterte Ticketliste ist nur eine der vielen nützlichen Funktionen unseres Plugins. Mehr Informationen findest du auch in folgendem Beitrag.

Weiterführende Infos

• Redmine Reporting Plugin
• Redmine Online Demo
• Plugin Features

• Sie ist projektbezogen als auch projektübergreifend nutzbar und
• bietet zahlreiche Filter, um sowohl offene als auch geschlossenen Vorgänge aufzuspüren.

Stell Dir vor, du erhälst noch detailliertere Suchmöglichkeiten, zahlreiche Zusatzfilter und Spalten, sowie andere Darstellungsformen um deine Daten bis ins Detail auseinanderzunehmen - für nachvollziehbare Analysen und mehr Transparenz.

Mehr Möglichkeit zu organisieren und zu präsentieren

Die erweiterte Ticketliste des Redmine Reporting Plugins erlaubt Dir einfach und unkompliziert noch tiefere Einblicke in die Arbeitsprozesse, welche die Standard Redmine-Liste nicht bietet.

Lerne ein paar praktische Use Cases kennen, wie Dir die erweiterte Ticketliste des Redmine Reporting Plugins helfen kann.

Für Projektleiter: Schneller Überblick und Steuerung

Du hast nur wenig Zeit das Statusmeeting mit dem Team vorzubereiten? Oder musst den Status von über 100 offenen Tickets prüfen und weißt nicht: welche kritisch sind, wo es Probleme gibt oder wer überlastet ist?

Die Lösung: Statt dich durch endlose Listen zu klicken, nutzt du die erweiterten Filter der Ticketliste:

• Ticket-Lebenszeit: Zeigt dir sofort, welche Tickets ungewöhnlich lange offen sind. Ein Ticket, das seit mehr als 1 Monat in “In Bearbeitung” hängt zeigt dir: Da läuft etwas schief.

• Roundtrips: Ein Ticket mit 8 Roundtrips (ständiges Hin-und-Her zwischen Status A und B) signalisiert: Hier gibt es Unklarheiten oder Probleme zwischen Team-Mitgliedern. Die solltest du prüfen.

• Counter-Boxen mit Schwellwerten: Du hast dir eine Abfragebox eingerichtet, die rot wird, wenn mehr als 5 Tickets länger als 30 Tage offen sind. Die Box ist rot - du weißt sofort, wo du nachfragen musst.

Das Ergebnis: Statt langer Vorbereitung brauchst du maximal 5 Minuten um dir einen Überblick zur aktuellen Situation zu verschaffen und dein Team mit konkreten Fragen besser zu steuern: “Ticket #123 hat 8 Roundtrips - was blockiert euch da?” Oder: “Ticket #234 ist seit über 1 Monat in Bearbeitung - ich weise es Andi zu, der gerade etwas Leerlauf hat.”

Für Teams: Prozesse verbessern und Engpässe erkennen

Die Situation: Das täglich 15-Minuten-Stand-up dauert oft 30 Minuten, weil jeder erstmal seine Tickets zusammensuchen muss und ihr über problembehaftete Tickets diskutiert, diese nicht schnell genug findet oder hier nicht weiter kommt?

Die Lösung: Das Team nutzt die erweiterte Ticketliste mit spezifischen Filtern:

• Board-Ansicht farblich hevorgehoben oder gruppiert nach “Zugewiesen an”: Jeder sieht seine Spalte mit den aktuellen Tickets. Wer nichts in “In Progress” hat, sollte sich ein neues Ticket holen.

• Roundtrips: Tickets mit hohen Roundtrips werden hervorgehoben. Das Team hat sich auf die Regel geeinigt: Erst ab 5 Roundtrips wird ein Ticket im Stand-up diskutiert, weil offensichtlich etwas unklar ist.

• Live-Search mit Feldsuche: Während des Meetings tippt jemand schnell id:1234,1235,1236 in die Live-Search der Ticketliste ein, um die drei diskutierten Tickets sofort anzuzeigen - keine Klick-Odyssee über zeitraubende Filterung.

Das Ergebnis: Die Stand-ups dauern wieder 15 Minuten. Die Diskussion ist fokussiert auf tatsächliche Blocker (hohe Roundtrips) und dem weiteren Fortschritt (Boardansicht zur aktuellen Aufgabenverteilung). Niemand verschwendet Zeit mit “Wo steht mein Ticket nochmal?”

Für Admins: Reporting für Management und Qualitätssicherung

Die Situation: Du bist verantwortlich für 15 Projekte in Redmine. Jeden Monat will das Management wissen: Welche Projekte laufen gut? Wo gibt es Risiken? Welche Teams brauchen Unterstützung?

Die Lösung: Du nutzt die projektübergreifende Ticketliste mit aggregierten Metriken:

• Tree Map “Aufgewendete Zeit aller Projekte”: Zeigt visuell, wo die meiste Zeit investiert wurde. Ein Projekt mit überproportional viel Zeit, aber wenig geschlossenen Tickets? Ein Warnsignal.

• Ticketabhängigkeiten-Ansicht: Für die identifizierten Problem-Tickets schaust du dir die Abhängigkeiten an. Muster: Viele haben blockierende Tickets, die erst spät entdeckt wurden. Das deutet auf unzureichende Planung hin.

• Gruppierung nach “Projekt” mit Summen: Du aktivierst die Summen für “Geschätzter Aufwand”, “Aufgewendete Zeit” und “Kosten”. Damit siehst du pro Projekt: Wo liegen wir über Budget? Die Spalte “Kosten mit Unteraufgaben” gibt dir die Gesamtkosten inklusive Sub-Tasks.

• Export als Excel: Du exportierst die gefilterte Ansicht und ergänzt sie mit ein paar Kommentaren. Fertig ist der Management-Report.

Das Ergebnis: Du präsentierst dem Management nicht nur “es gibt ein Problem”, sondern konkrete Daten: “Team X hat zu hohe Kosten bei Ticket #123 und #234, Team Y nur bei Ticket #345. Das Pattern zeigt sich besonders bei Feature-Tickets, nicht bei Bugs. Wir sollten den Feature-Review-Prozess in Team X überarbeiten.”

Was alle drei Zielgruppen verbindet:

Egal ob Projektleiter, Team oder Admin - die wirkliche Stärke der erweiterten Ticketliste liegt in den benutzerdefinierten Abfragen.

Die erweiterte Ticketliste des Reporting Plugins ist kein Feature, das man “einschaltet” - sie integriert sich automatisch da, wo man sie braucht. Die Kunst liegt nur darin, die richtigen Fragen für den eigenen Einsatz zu stellen und die entsprechenden Metriken zu nutzen:

• Projektleiter fragen: “Wo sind die Probleme?” → Lebenszeit, Roundtrips, SLA-Filter
• Teams fragen: “Was blockiert uns?” → Status-Änderungen, Roundtrips, Abhängigkeiten
• Admins fragen: “Wie ist der Gesamtzustand?” → Tree Maps, Kosten-Summen, projektübergreifende Filter

Einmal eine sinnvolle Filterkombi erstellt, gespeichert, und dann regelmäßig wiederverwendet (Beispielsweise mittels Zählerboxen) unterstützt dich bei mindestens 80% der üblichen Anwendungsfälle in einem Projektteam.

Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Das kostenpflichtige Reporting Plugin gibt es einzeln oder als Teil unseres Business-Class Bundle, sowie dem Enterprise+ Bundle. Die hier beschriebene Funktion kann in unserer Online-Demo ausgiebig getestet werden. Die hier beschriebene, erweiterte Ticketliste ist nur eine der vielen nützlichen Funktionen unseres Plugins. Mehr Informationen findest du auch in folgendem Beitrag.

Weiterführende Infos

• Redmine Reporting Plugin
• Redmine Online Demo
• Plugin Features

Künstliche Intelligenz revolutioniert die Art und Weise wie wir arbeiten. Nicht nur im Allgemeinen, sondern auch im Speziellen: Automatische Ticket-Zusammenfassungen, intelligente Priorisierung, semantische Suche, das sind nur ein paar Tätigkeiten welche die Produktivität fördern und daher auch im Projektmanagement gefragt sind.

Hier ist der Einsatz von KI praktisch, aber nicht unbedenklich. Wer in Deutschland oder der EU arbeitet, steht vor einer Herausforderung: Die führenden AI-Dienste wie ChatGPT oder Claude verarbeiten Daten in den USA - rechtlich problematisch nach DSGVO und dem Schrems II Urteil (C-311/18 „Schrems II“, EuGH). Besonders bei sensiblen Projektdaten aus Behörden, Gesundheitswesen oder regulierten Branchen ist das ein Risiko.

In unserem Artikel erfährst Du, welche Möglichkeite bestehen AI in Redmine DSGVO-Konform zu integrieren ohne, dass deine Daten Deutschland verlassen.

Warum das für IT-Entscheider und Projektmanager wichtig ist

DSGVO-Verstöße können teuer werden. Die Bearbeitung kostet Zeit und Nerven und gehen oft auch mit Vertrauensverlust der Betroffenen einher. Aber was viele nicht berücksichtigen: Wenn du Projektdaten wie Kundennamen, interne Prozesse oder Personaldaten an US-Cloud-Dienste sendest, verlierst du die Kontrolle darüber, was mit den Daten tatsächlich passiert. Wie sie genutzt werden und ob man dem Anbieter nicht nur jetzt, sondern auch in Zukunft trauen kann.

Das Schrems-II-Urteil des EuGH hat gezeigt: Standard Contractual Clauses (SCCs) reichen oft nicht aus, wenn US-Behörden durch den CLOUD Act Zugriff verlangen können.

Allerdings sind in der EU ansässige Unternehmen nicht machtlos der amerikanischen Willkür ausgesetzt: Mit der richtigen Architektur nutzt du AI-Funktionen wie automatische Analysen und intelligente Vorschläge auch ohne rechtliche Risiken.

DSGVO-Compliance: Die 3 kritischen Punkte

Eine DSGVO-konfrome AI-Integration muss drei Anforderungen erfüllen:

1. Datenresidenz in Deutschland/EU Redmine-Daten und AI-Verarbeitung müssen in Deutschland oder der EU bleiben. Das bedeutet: Entweder Hosting bei einem deutschen Anbieter oder selbst betriebene Server in deutschen Rechenzentren.

2. Auftragsverarbeitungsvertrag (AVV) Wenn du externe AI-APIs nutzt, benötigst du einen AVV, der die Datenverarbeitung regelt. Bei komplett lokalen Lösungen wie Ollama entfällt dieser Punkt, denn die Daten verlassen dein System nie.

3. Bewusste Provider-Auswahl Nicht jeder AI-Anbieter ist gleich. Viele bekannte Anbieter verarbeiten Daten in den USA, Azure OpenAI kann EU-Regionen nutzen (mit AVV DSGVO-konform), OpenAI bietet seit kurzem für bestimmte Kundengruppen auch Datenresidenz in Europa an und lokale Lösungen wie Ollama bleiben komplett in deiner Infrastruktur (100% DSGVO-konform).

Ollama: Die On-Premises Lösung für 100% DSGVO-Konformität

LLMs sind rechenintensive Anwendungen. Es gibt auch Open Source LLMs, die mit entsprechender Hardware nahezu die Möglichkeiten bieten, die auch mit öffentlichen KI-Anwendungen zur Verfügung stehen. Ollama ist eine Open-Source-Plattform, die große Sprachmodelle wie LLaMA, Mistral oder Qwen lokal auf deinen Servern betreibt.

Alle Daten bleiben in Deutschland. Keine externe Übertragung, keine Cloud-Abhängigkeit.

Provider im Überblick

AlphaNodes Managed Ollama: Gemanagte Ollama-Infrastruktur auf dedizierter Hardware

AlphaNodes bietet Ollama als komplett verwalteten Service auf eigenen Servern in Deutschland. Wer unser Redmine AI Hosting Cloud Paket bucht, bekommt seinen eigenen Server. Das bedeutet, deine Daten liegen ausschließlich auf deiner Hardware und werden nicht mit anderen Kunden geteilt.

Was das für dich bedeutet:

• Dein eigener Server nur für deine Projektdaten
• Alle Daten bleiben in Deutschland
• AlphaNodes kümmert sich um alles: LLM Installation, Wartung, Updates, Überwachung
• 100% DSGVO-konform, deine Daten verlassen niemals Deutschland

Beliebte LLM Modelle wären beispielsweise Llama (Meta), Mistral oder Qwen - je nach Anforderung und Einsatzgebiet.

Deine Vorteile:

• Keine eigene Server-Hardware kaufen oder betreiben nötig
• Du brauchst kein IT-Team für den Server-Betrieb
• Feste monatliche Kosten
• Professionelles Hosting in deutschen Rechenzentren
• KI-Hosting speziell auf Redmine abgestimmt - durch das AlphaNodes AI Plugin optimal in deine Redmine-Workflows integriert

So einfach geht’s: Nachdem das Redmine AI Paket bereit steht, konfigurierst Du das Redmine AI Plugin nach Deinen Bedürfnissen: leg fest welche KI-Funktionen genutzt werden und wer diese nutzen darf (z.B. KI-Prompts, KI-Assistent, MCP). Fertig - ab sofort kannst du KI mit deinen Redmine Daten nutzen. Für einen schnellen Start stehen dir bereits nützliche KI-Prompt Vorlagen zur Nutzung bereit. Die kannst du natürlich jederzeit anpassen und erweitern.

KI-Prompts: Ein Prompt ist eine vordefinierte Anweisung an die KI, z.B. “Fasse dieses Ticket zusammen” oder “Schlage eine Priorität vor”. Im Redmine AI Plugin kannst du solche Prompts speichern und mit einem Klick auf beliebige Tickets anwenden. Das spart Zeit bei wiederkehrenden Aufgaben. Außerdem kann jeder Mitarbeiter diese nutzen, ohne notwendiges Hintergrundwissen.

MCP (Model Context Protocol): MCP ist eine Schnittstelle, die es der KI ermöglicht, mit externen Tools zu kommunizieren. Zum Beispiel kann die KI über MCP auf Slack, GitHub oder andere Dienste zugreifen und dort Informationen abrufen oder Aktionen ausführen - alles gesteuert aus Redmine heraus.

Konkrete Use Cases im Projektalltag

Es geht nicht darum, KI um der KI willen einzusetzen. Die Frage ist: Welche zeitraubenden Aufgaben kann AI übernehmen, damit sich dein Team auf die eigentliche Projektarbeit konzentriert? Hier sind sechs bewährte Anwendungsfälle:

1. Automatische Ticket-Zusammenfassungen Dein Support-Team erhält täglich Dutzende Tickets mit langen Beschreibungen. Das AI-Plugin liest den Text und erstellt eine kurze, verständliche Zusammenfassung. Ergebnis: Schnellere Einschätzung, einheitliche Sprache, weniger Lesezeit.

2. Intelligente Priorisierung Die AI analysiert Dringlichkeit, Auswirkungen und Kategorie und schlägt eine Priorität vor (hoch, mittel, niedrig). Das standardisiert die Priorisierung, vermeidet menschliche Fehler und beschleunigt die Bearbeitung.

3. Automatische Klassifizierung und Tagging Ist es ein Bug, ein Feature Request oder eine Support-Anfrage? Die AI erkennt die Kategorie automatisch und fügt passende Tags hinzu. Das verbessert die Übersicht und ermöglicht automatisches Routing an die zuständigen Teams.

4. Vorschläge für Antworten und Lösungen Dein Support schreibt oft ähnliche Antworten? Die AI erstellt Vorschläge für Kommentare basierend auf ähnlichen, bereits gelösten Tickets. Das spart Zeit, sorgt für einheitliche Antworten und beschleunigt Ticket-Abschlüsse.

5. Reporting und Analyse Bei großen Ticketzahlen wird es unübersichtlich. Die AI generiert automatisch Reports: Anzahl ungelöster Tickets pro Kategorie, durchschnittliche Bearbeitungszeit, häufig auftretende Problemtypen. So triffst du schneller strategische Entscheidungen und erkennst Schwachstellen in deinen Prozessen.

6. Semantische Suche (mit RAG) Die vektorbasierte Suche findet semantisch ähnliche Tickets - nicht nur nach Stichworten, sondern nach Bedeutung. Das hilft, Duplikate zu vermeiden und bewährte Lösungen wiederzuverwenden. Voraussetzung: PostgreSQL mit pgvector (da unsere Redmine Hosting Kunden alle PostgreSQL einsetzen ist diese Funktion immer nutzbar).

RAG (Retrieval Augmented Generation): RAG erweitert die KI um deine eigenen Daten. Die KI durchsucht dabei deine Redmine-Tickets und Wiki-Seiten und nutzt diese Informationen für bessere Antworten. So kennt die KI deine Projekte, frühere Lösungen und projektspezifische Details - statt nur allgemeines Wissen zu haben.

Fazit: DSGVO-konform und zukunftsorientiert

Die optimale Kombination für DSGVO-konforme AI in Redmine ist: Managed Redmine Hosting in Deutschland + Ollama-Server (durch AlphaNodes betrieben) + AI-Plugin. Damit bleiben alle Daten in Deutschland, du bist unabhängig von externen Cloud-Diensten, genießt flexible KI-Funktionen und musst keinen eigenen GPU-Server verwalten. Für jedes Unternehmen relevant, das den Datenschutzanforderungen entsprechen will - und ein Muss für Behörden, Gesundheitswesen und regulierte Branchen.

Häufige Fragen (FAQ)

Weiterführende Links

• AlphaNodes Redmine AI Plugin - Produktseite
• Redmine Managed Hosting in Deutschland
• Redmine Enterprise Support

Wenn der Admin (mit anderen Dingen) beschäftigt ist

In den meisten Teams gibt es ihn - „den Admin”. Eine Person, die gleichzeitig für Drucker, Laptops, VPN und Softwarelizenzen zuständig ist. Da hat der fehlerhafte E-Mail-Abruf eines Kollegen natürlich Vorrang. Redmine läuft still im Hintergrund - und das seit Monaten überfällige Update auch.

Das Problem: „läuft” bedeutet nicht „ist sicher”, „ist aktuell” oder „lässt sich im Ernstfall wiederherstellen”.

Sicherheitsupdates wurden nicht eingespielt, weil nie Zeit dafür war. Backups laufen irgendwie, aber ob sie wirklich funktionieren, hat niemand getestet. Und wenn Kundenprojekte oder Mitarbeiterdaten in Redmine liegen, seid ihr als Unternehmen verpflichtet, deren Schutz nachzuweisen. Aber „der Admin schaut ab und zu drauf” ist kein dokumentierter Prozess.

Wer täglich mit operativen Aufgaben ausgelastet ist, kann nebenbei keinen professionellen Serverbetrieb leisten. Das ist keine Frage von Kompetenz, sondern von Kapazität.

Wenn Eigenentwicklungen zur (Kosten-)Falle werden

Ein anderes Muster verschärft das Problem: Eigenentwicklungen.

Ja, Redmine lässt sich anpassen, das ist einer seiner Vorteile. Teams oder Agenturen bauen individuelle Erweiterungen, die genau das liefern, was gebraucht wird. Einmalig bezahlt, funktioniert, erledigt. So denken viele Entscheider.

Was dabei selten berücksichtigt wird, sind die laufenden Pflegearbeiten:

• Wenn Redmine aktualisiert werden soll, läuft die Erweiterung plötzlich nicht mehr.
• Wer sie ursprünglich gebaut hat, ist vielleicht nicht mehr im Unternehmen, oder das Budget sitzt nicht mehr so locker wie vor einem Jahr.

Und hier liegt die eigentliche Kostenfalle: Die initiale Entwicklung wurde bezahlt - das fühlt sich abgeschlossen an. Dass Software laufend gepflegt werden muss, hat niemand im Hinterkopf. Mit absehbaren Folgen:

• Die Erweiterung wird nicht aktualisiert, alles bleibt auf dem alten Stand.
• Auch Redmine, egal wie viele Bugfix oder Sicherheitsupdates in der Zwischenzeit heraus kamen.

Nicht immer aus einer bewussten Entscheidung heraus, sondern weil es sich schwer begründen lässt, nochmal Geld auszugeben, wenn man doch schon bezahlt hat. So frieren Systeme über Jahre ein und mit ihnen alle ungepatchten Sicherheitslücken.

Was dagegen hilft: Klare Zuständigkeiten

Das sind zwei Muster, mit denen wir regelmäßig konfrontiert werden. Managed Hosting löst nicht jedes Problem, schafft aber genau das, was in beiden Szenarien fehlt: eine klare Verantwortung.

Wir sorgen dafür, dass der Betrieb überwacht wird, täglich Backups erstellt und verschlüsselt abgelegt werden. Wir wissen, wo sie liegen, wie man sie im Notfall einspielt - und kümmern uns zeitnah darum. Es geht weniger darum, den Admin zu ersetzen, als darum, eine Aufgabe zu übernehmen, die bislang niemand wirklich in der Hand hatte.

Fazit

Stellt euch zwei Fragen:

• Wann wurde bei uns zuletzt ein Backup gemacht - und ein Restore getestet?
• Wann wurde Redmine zuletzt aktualisiert? Oder gibt es Blocker, die das schon seit einer Weile verhindern?

Die Antworten sagen oft mehr als jede Risikoanalyse. Und wenn die Antwort “weiß ich nicht” oder “ja wir haben Gründe nicht zu aktualisieren” lautet, ist das ein guter Zeitpunkt, um das zu ändern.

Weiterführende Infos

• Redmine Hosting
• Redmine AI Hosting

Das Reporting Log protokolliert zusätzliche Aktivitäten in deiner Redmine-Instanz und macht sie leichter durchsuchbar, speicherbar und exportierbar, falls nötig.

Was wird protokolliert?

Das Reporting Log erfasst zwei Kategorien von Ereignissen: Authentifizierung und Datenänderungen.

Bei der Authentifizierung werden sowohl erfolgreiche als auch fehlgeschlagene Login-Versuche aufgezeichnet. Das hilft dir dabei, ungewöhnliche Muster zu erkennen - etwa wenn ein Benutzerkonto wiederholt mit falschen Passwörtern angesprochen wird.

Bei Datenänderungen protokolliert das System CRUD-Operationen (Create, Read, Update, Delete) auf den wichtigsten Redmine-Objekten. Wenn jemand ein Ticket erstellt, ein Projekt umbenennt oder einen Benutzer deaktiviert, erscheint ein entsprechender Eintrag im Log. Kategorisiert nach Log Level (Debug, Info, Warning, Error, Fatal, Unknown).

Reporting Log: Funktionsumfang

Hier eine Übersicht der aktuellen Plugin Version 4.3.0 zu den Aktivitäten, die geloggt werden:

Projekt-basierte Sichtbarkeit

Das Reporting Log arbeitet mit Redmines Berechtigungssystem zusammen. Du kannst pro Projekt festlegen, welche Rollen Zugriff auf die Log-Einträge haben.

Das bedeutet konkret, dass beispielsweise ein Projektleiter nur die Aktivitäten in seinen eigenen Projekten sieht. Wohingegend Administratoren projektübergreifend auf alle Einträge zugreifen können. Diese Trennung ist besonders in Umgebungen mit mehreren Kunden oder Abteilungen hilfreich, wo nicht jeder die Aktivitäten der anderen einsehen soll, wenn ihn diese nicht betreffen.

Filtern und Suchen

Wie in Redmine üblich werden auch die Log-Einträge über eine Query-Oberfläche angezeigt, die du auch schon von anderen Redmine-Listen (z.B. Ticketliste) kennst. Du kannst die Einträge daher nach den für dich relevanten Kriterien filtern:

• Zeitraum (von/bis)
• Benutzer
• Projekt
• Art der Aktion (Login, Erstellung, Änderung, Löschung)
• Betroffenes Objekt (Ticket, Projekt, Benutzer etc.)

Die Filter lassen sich kombinieren. Wenn du wissen möchtest, welche Tickets ein bestimmter Benutzer letzte Woche bearbeitet hat, wählst du die entsprechenden Filter und Optionen aus und erhältst eine übersichtliche Liste der geloggten Einträge.

Export für weitere Verarbeitung

Die gefilterten Ergebnisse kannst du bei Bedarf als CSV oder XLSX exportieren. Das ist nützlich, wenn du die Daten in anderen Programmen weiterverarbeiten möchtest - etwa für Berichte oder zur Archivierung.

Der Export enthält alle sichtbaren Spalten und respektiert die gesetzten Filter. Du exportierst also genau das, was du auf dem Bildschirm siehst.

Syslog-Integration

Für Umgebungen mit zentraler Log-Verwaltung bietet das Reporting Log eine Syslog-Integration. Die Einträge werden dann zusätzlich an einen Syslog-Server gesendet, wo sie zusammen mit Logs aus anderen Systemen ausgewertet werden können.

Das ist besonders in größeren IT-Infrastrukturen relevant, wo ein zentrales Log-Management-System (SIEM) im Einsatz ist. Die Redmine-Aktivitäten fügen sich dann nahtlos in das Gesamtbild ein.

Log-Retention konfigurieren

Log-Daten wachsen mit der Zeit. Das Reporting Log bietet eine konfigurierbare Aufbewahrungsdauer (Retention). Du legst fest, wie lange Einträge gespeichert werden sollen, bevor sie gelöscht werden. Für das manuelle Aufräumen steht Dir ein Rake-Task zur Verfügung.

Der Task eignet sich für Cronjobs, wenn du die Retention automatisieren möchtest. Je nach Anforderung kann das ein Monat, 90 Tage, oder ein Jahr sein etc. Die automatische Löschung läuft im Hintergrund und sorgt dafür, dass die Datenbank nicht unnötig wächst.

Einrichtung

Ab der erfolgreichen Installation und Konfiguration des Reporting Plugins funktioniert auch das Log und protokolliert neue Einträge. Wichtig ist, dass du in den Rollen die Berechtigung zum Einsehen der Log-Einträge vergibst.

Bestehende Aktivitäten aus der Vergangenheit werden nicht rückwirkend erfasst - das Log beginnt mit der Aktivierung.

Typische Anwendungsfälle

Das Reporting Log beantwortet Fragen wie:

• Wer hat ein Ticket gelöscht?
• Hat sich jemand außerhalb der Arbeitszeiten eingeloggt?
• Wurden unüblich viele Benutzerkonten geändert?
• Wer hat zuletzt Anpassungen an der Redmine Konfiguration durchgeführt?

Diese Informationen sind im normalen Redmine-Betrieb nicht ohne Weiteres verfügbar. Die Journal-Einträge bei Tickets zeigen zwar Änderungen, aber eine systemweite Übersicht fehlt und Löschvorgänge werden gar nicht protokolliert.

Tipp: Die für dich relevanten Einträge kannst du einfach als benutzerdefinierte Abfrage abspeichern und in einen Dashboard Block integrieren - dann hast du solche Änderungen die einer genaueren Analyse bedürfen immer auf dem Schirm.

Grenzen des Reporting Logs

Das Reporting Log ist kein vollständiger Audit-Trail im Sinne von Compliance-Frameworks. Es protokolliert, dass eine Änderung stattgefunden hat, speichert aber nicht die Vorher/Nachher-Werte. Auch reine Lesezugriffe (wer hat welches Ticket angesehen) werden aktuell nicht erfasst.

Für viele Teams reicht das Reporting Log jedoch aus, um Transparenz über die Systemnutzung zu gewinnen. Wer strengere Anforderungen hat - etwa aus regulatorischen Gründen - sollte prüfen, ob zusätzliche Maßnahmen nötig sind. Diese lassen sich gegebenenfalls mit dem Automation Plugin und der Aktion “Logeintrag hinzufügen” abdecken, wenn dieses zusätzlich im Einsatz ist.

Für wen lohnt sich die Funktion?

Das Reporting Log bringt Transparenz in deine Redmine-Nutzung. Du siehst, wer sich wann einloggt und welche Änderungen vorgenommen werden. Die projekt-basierte Sichtbarkeit, flexible Filter und Export-Funktionen machen es zu einem praktischen Werkzeug für den Alltag mit Redmine.

Besonders profitieren größere Teams und Organisationen mit mehreren Kunden oder Abteilungen, wo Nachvollziehbarkeit und Datentrennung wichtig sind. Projektleiter behalten den Überblick über ihre Projekte, Administratoren können systemweit agieren, und IT-Sicherheitsverantwortliche erkennen ungewöhnliche Login-Muster frühzeitig.

Die hier vorgestellte Funktion ist Teil des Reporting Plugins. Das Reporting Plugin ist einzeln oder als Bestandteil des Enterprise+ Bundles erhältlich und kann auch im Zuge unserer Redmine Hostingangebots genutzt werden. Informationen zu unseren Managed Application Hosting zu Redmine findest Du hier auf der Webseite. Wenn Du Hilfe bei der Entscheidung benötigst, nutze unsere Redmine Hosting Entscheidungshilfe.

Weiterführende Infos

• Redmine Reporting
• Redmine Online Demo
• Plugin Features

Für wen ist diese Funktion geeignet?

Die Webformular-Funktion richtet sich an Anwender mit HTML-Grundkenntnissen und Einblick in die notwendigen Felder innerhalb deines Redmine Systems. Du solltest wissen, wie ein einfaches HTML-Formular aufgebaut ist (<form>, <input>, <select>). Programmierkenntnisse sind nicht zwingend erforderlich, aber hilfreich - das Einbinden erfolgt per Copy & Paste mit Anpassung der Feldnamen wie von deinem Redmine vorgegeben.

Anwendungsfälle

• Formularbasierte Service-Anfragen: Mitarbeiter können Hardware bestellen, Software-Installationen anfragen oder Berechtigungen beantragen
• Kundensupport und strukturierte Ticketerfassung: Kontaktformular auf deiner Website - Anfragen werden automatisch als Tickets erfasst
• Feedback: Kundenfeedback oder Verbesserungsvorschläge direkt in Redmine sammeln

So funktioniert es

1. Formular aktivieren: In den Projekteinstellungen unter Helpdesk → Eingehendes Helpdesk Formular die Option aktivieren. Du erhältst eine Formular-URL für dein Projekt.

2. Rückgabe-URLs festlegen: Definiere, wohin Benutzer nach dem Absenden weitergeleitet werden (Erfolgs- und Fehlerseite).

3. HTML-Formular einbinden: Erstelle ein Formular auf deiner Website, das an die Formular-URL sendet. Die Feldnamen bestimmen, welche Ticket-Attribute befüllt werden.

Das war’s - jede Formulareinreichung erstellt automatisch ein Helpdesk-Ticket im zugewiesenen Redmine-Projekt. Mittels Ticketfilter oder Suche lassen sich die Anfragen in Deinem Redmine schnell aufspüren und weiter verteilen. Oder Du richtest Dir eine Automatisierungsregel ein.

Funktionsumfang

Stärken

• Niedrige Einstiegshürde: Kein Backend-Code, kein API-Token-Management, keine Authentifizierung. HTML-Formular bauen, in Webseite integrieren, ausfüllen, absenden - fertig.
• Schneller Proof-of-Concept: In wenigen Minuten ein funktionierendes Kontaktformular, das echte Tickets erzeugt.
• Kontakterstellung inklusive: Absender werden automatisch als Kontakte erfasst - inklusive Verlauf bei Folge-Anfragen.
• Spam-Schutz out-of-the-box: Honeypot, IP-Filter, DNS-Blacklists - alles konfigurierbar.

Anmerkung: Für komplexere Anforderungen empfehlen wir die Redmine REST API (siehe unten).

Webformular oder API?

Die Webformular-Funktion ist ideal für einfache bis mittlere Anforderungen:

• Kontaktformulare mit wenigen Feldern
• Einfache Service-Anfragen
• Feedback-Formulare
• Relativ schnelle Integration ohne tiefgreifenden Entwicklungsaufwand

Wann du die Redmine REST API nutzen solltest

Für umfangreiche oder komplexe Formulare empfehlen wir die direkte Nutzung der Redmine REST API:

Gut zu wissen: Unsere Plugins erweitern die Redmine REST API um zusätzliche Endpunkte - etwa für Kontakte, Helpdesk-Tickets oder Automatisierungen. Mit einer Support-Lizenz erhältst du Zugriff auf die vollständige API-Dokumentation.

Tipp: Starte mit einem Webformular für einen schnellen Proof-of-Concept. Wenn die Anforderungen wachsen, kannst du später auf die API umsteigen - die erstellten Tickets und Kontakte bleiben erhalten.

Fazit

Mit der Webformular-Funktion verwandelst du jedes HTML-Formular in einen Ticket-Eingang. Die Einrichtung erfordert nur HTML-Grundkenntnisse - ideal für schnelle Integrationen ohne Entwicklungsaufwand. Das ServiceDesk Plugin ist Teil des Enterprise+ Bundles, denn es benötigt das Reporting und Automation Plugin als Basis. Wer sich die Installation des Bundles nicht zutraut kann auch unser Redmine Managed Application Hosting Angebot in Anspruch nehmen. Die Plugins sind hierbei bereits bei Bedarf integriert.

Alle Informationen zu unseren Managed Application Hosting Angeboten zu Redmine findest Du hier auf der Webseite.

Weiterführende Infos

• Redmine Hosting
• Redmine Online Demo
• Plugin Features

Der typische Enterprise-Anforderungskatalog

Anforderungskataloge für Projektmanagement Software folgen in der Regel einem erkennbaren Muster. Einer Kombination aus Basis-Funktionalitäten mit spezifischen Anforderungen aus der Unternehmensrealität.

Zu den Schwerpunkten gehören folgende Bereiche:

Authentifizierung und Zugriffskontrolle

Single Sign-On mit SAML oder OAuth, Integration in Active Directory, rollenbasierte Berechtigungen auf Projekt- und Objektebene, Audit-Logs für Compliance.

Projektmanagement-Methoden

Support für klassische (Gantt, Meilensteine) und agile Methoden (Kanban, Scrum), Portfolio-Sicht über mehrere Projekte, Ressourcenplanung und Kapazitätsmanagement.

Automatisierung und Workflows

Konfigurierbare Status-Änderungen, Event-basierte Automatisierungen, Integration mit anderen Tools, automatische E-Mail Benachrichtigungen und Eskalationen.

Reporting und Dashboards

Individuelle Dashboards pro Rolle, Export-Funktionen für Management-Reporting, KPI-Tracking, Burndown- und Velocity-Charts für agile Teams.

Integration und Datenmanagement

REST-APIs für Systemintegration, Anbindung an ERP-Systeme, Versionsverwaltung für Code, zentrale Wissensdatenbank mit Versionierung.

Redmine Core liefert eine solide Basis für 60% der Anforderungen

Redmine bringt in der Standardinstallation bereits mehr mit, als viele vermuten würden. Die Core-Installation deckt die folgenden Bereiche ab:

• Projektmanagement: Gantt-Diagramme, Roadmaps, Meilensteine, Issue-Tracking mit flexiblen Tracker-Typen umd Workflows, Ticketbeziehungen, Zeiterfassung zu Tickets mit Aufwandsschätzung
• Berechtigungen: Granulares Rollen- und Rechtekonzept auf Projekt- und Modul-Ebene, LDAP/Active Directory-Integration, öffentliche und private Projekte / Unterprojekte.
• Kollaboration: Einfaches Wiki mit Versionierung, Dokumentenmanagement, Forum, News-System, Activity-Stream für Projekt-Tätigkeiten (global & projektbezogen).
• Integration: REST-API, Repository-Browser für Git/SVN/Mercurial, E-Mail-Integration (Ticket-Erstellung per Mail), benutzerdefinierte Felder für beliebige Datenstrukturen.

Das sind mehr Basis-Features als bei manch anderer Software dieser Art, aber für die üblichen Enterprise-Anforderungen fehlen trotzdem einige kritische Komponenten.

Redmine Core vs. Jira - Funktionsvergleich

Plugins schließen die Lücke: Von 60% auf 85%

Hier muss man dann gezielt mit Plugins arbeiten, um die meisten Enterprise-Anforderungen abdecken zu können. Hier eine Auswahl:

SAML Plugin: Single Sign-On über SAML2-kompatible Identity Provider. Kritisch für Unternehmen mit zentraler Authentifizierungs-Infrastruktur.

Reporting Plugin: Professionelle Dashboards, interaktive Diagramme, Burndown-Charts, Flexible Taskboards (Drag & Drop Support), Portfolio-Übersichten, erweiterte Filter- und Aggregationsfunktionen, SLA-Management via Ticket-Priorität. Damit wird Redmine vom reinen PM-Tool zum Schweizer Taschenmesser für Projektmanager und Entscheider mit zusätzlichen Berichten und Auswertungen.

Automation Plugin: Event-basierte Workflows, automatische Ticket-Updates, Eskalationen bei SLA-Verstößen und vieles mehr. Der Automation Bot ist ein unermüdlicher Helfer für die Automatisierung regelmäßiger Routineaufgaben.

WikiGuide Plugin: Macht aus der Basis Wiki eine strukturierte Wissensdatenbank mit Live-Search, Filterfunktionen, Freigabeworkflows, Makros für dynamische Inhalte und einiges mehr.

HRM Plugin: Für eine realistische Ressourcenplanung mit der Möglichkeit zur Abwesenheitsverwaltung (Urlaub, Krankheit, etc.). Hilft bei der langfristigen Planung von Projektarbeiten.

ServiceDesk Plugin: Generiert aus eingehenden Kunden E-Mails Helpdesk-Tickets - für eine Bi-Direktionale Kommunikation, mit Kundenzufriedenheits-Ratings und Kontaktverwaltung.

DevOps Plugin: CI/CD-Integration, erweiterte Repository-Funktionen, automatische Ticket-Updates bei Commits. Zentralisiert Informationen aus externen DevOps Tools (Hetzner, GitLab, GitHub etc.) direkt in Redmine.

Mit dieser Plugin-Kombination liegt die Abdeckung realistisch bei 85% eines typischen Enterprise-Katalogs.

Professionelles Hosting, Support + Premium-Features

Lerne unsere Hostinganpakete zu Redmine, sowie unser Enterprise Supportpaket mit exklusiven Erweiterungen kennen.

Redmine Hosting Pakete

Und was ist mit den restlichen 15%?

• Microsoft-Ökosystem-Integration (Sharepoint & Co): Für produktive Umgebungen arbeitet Redmine stabiler mit Attachments statt Live-Dokumenten.
• ERP-Direktintegration: SAP, Oracle oder Dynamics lassen sich über die REST-API anbinden.
• Real-time Collaboration: Echtzeit-Ko-Editierung im Wiki, wie in Confluence oder Notion, gibt es in Redmine nicht. Community-Plugins dafür sind experimentell und für Enterprise-Einsatz nicht ausgereift genug.
• Der entscheidende Unterschied: Wir konzentrieren uns auf Plugin-Kombinationen, die wir langfristig supporten und warten können. Community-Plugins mit unregelmäßigen Updates passen nicht in ein professionelles Managed-Hosting-Konzept.

Wann ist Redmine die richtige Wahl?

Die Entscheidung hängt von vier Faktoren ab:

• Datensouveränität: On-Premise oder in deutschem Rechenzentrum mit voller Kontrolle über Daten, Backups und Zugriffsrechte. Kritisch für DSGVO-sensible Branchen oder Unternehmen mit Compliance-Anforderungen.
• Kostenstruktur: Kein benutzerbasiertes Lizenzmodell, keine Vendor Lock-in-Effekte, planbare TCO.
• Offenheit für Open Source: Open Source bedeutet jederzeit Einblick in den Code und auch Anpassbarkeit ohne Abhängigkeit vom Hersteller.
• Betriebsmodell: Managed Hosting kombiniert die Vorteile von On-Premise (Datenkontrolle, Stabilität) mit SaaS-Komfort (keine eigene IT-Infrastruktur nötig). Du entscheidest: Self-Hosted oder professionell betreut.

Return on Investment (ROI): Redmine vs. kommerzielle Alternativen

Ein wichtiger Faktor bei der Entscheidung für eine Enterprise-Projektmanagement-Lösung sind bei vielen Unternehmen übrigens auch die Gesamtkosten über einen längeren Zeitraum.

Der ROI bei einer Migration zu Redmine kann oft bereits nach wenigen Monaten erreicht sein - abhängig von Migrationskomplexität und notwendigen Anpassungen für funktionale Unterschiede. Die größten Einsparungen entstehen in der Regel durch den Wegfall nutzerbasierter Lizenzkosten.

Was du berücksichtigen solltest sind:

• Funktionale Unterschiede: Kommerzielle Lösungen bieten teilweise spezialisierte Features die in Redmine anders oder über Plugins abgebildet werden müssen
• Migrationsaufwand: Der tatsächliche Migrationsaufwand hängt stark von der Komplexität deines bestehenden Systems ab (Custom Fields, Workflows, Integrationen)
• Langfristige Strategie: Redmine eignet sich besonders dann, wenn du langfristig Kontrolle über deine Daten und Kosten behalten willst

Daher sollte die Entscheidung nicht allein auf Kostenbasis getroffen werden, sondern auch die funktionalen Anforderungen deines Unternehmens berücksichtigen.

Unser Fazit

Redmine bietet erhebliche Kostenvorteile gegenüber kommerziellen Cloud-Lösungen. Selbst wenn die Funktionsabdeckung nicht 100% entspricht. Man muss nicht zwingend für alles ein Plugin verwenden. Natürlich machen Plugins Sinn, aber nur dann, wenn sie regelmäßig gepflegt und auch noch in fünf Jahren stabil weiter entwickelt werden. Nur dann ist sicher gestellt, dass sie mit der jeweils aktuellen Redmine Version kompatibel bleiben.

Unser Managed Hosting liefert genau das:

• Professionell konfigurierte Redmine-Instanzen mit Enterprise-Plugins,
• regelmäßigen Updates und deutschem Support.
• Von R100 für wachsende Unternehmen über Cloud RE Pro mit SSO und KI bis zum InHouse-Angebot für höchste Compliance-Anforderungen.

Alle Informationen zu unseren Managed Application Hosting Angeboten zu Redmine findest Du hier auf der Webseite.

Weiterführende Infos

• Redmine Hosting
• Redmine Online Demo
• Plugin Features

Was ist das Taskboard?

Das Taskboard visualisiert deine Tickets als Karten, organisiert in Spalten nach Status. Statt durch Listen zu scrollen, siehst du auf einen Blick: Was ist neu? Was wird gerade bearbeitet? Was wartet auf Feedback? Die Grundfunktion ist simpel, aber effektiv: Du ziehst Tickets per Drag & Drop zwischen Spalten, um ihren Status zu ändern.

Diese Visualisierung funktioniert mit deinen bestehenden Redmine-Workflows. Du musst keine neue Methodik einführen, keine Prozesse umstellen. Das Board nutzt die Status, die du bereits konfiguriert hast.

Anpassbare Darstellung

Das Reporting Plugin Board zeigt genau die Informationen, die für dich relevant sind. Über die Filter-Optionen unter “Spalten” legst du fest, welche Felder auf den Ticket-Karten erscheinen: Zugewiesene Person, Priorität, Kategorie, Zielversion, Custom Fields oder andere Informationen.

Zusätzlich kannst du die Karten farblich kennzeichnen - nach Tracker (Bug, Feature, Support), Priorität (Dringend, Hoch, Normal), zugewiesener Person, Projekt oder anderen Feldern. Das macht relevante Unterschiede sofort sichtbar: Rote Karten = Bugs, blaue = Features, oder jede Person hat ihre eigene Farbe.

Diese Konfiguration speicherst du als Teil deiner benutzerdefinierten Abfrage. So steht dir deine optimale Board-Ansicht jederzeit zur Verfügung - inklusive Filter, Spaltenauswahl, Farbschema und Sortierung.

“Das Reporting Plugin Taskboard ermöglicht Teams eine visuelle Arbeitsweise - ohne dass sie ihre Prozesse, Plattform oder Methodik ändern müssen.”

Neue Funktionen ab Version 4.3.0

Mit der Plugin Version 4.3.0 hat das Taskboard zwei wesentliche Erweiterungen erhalten, die die tägliche Arbeit deutlich beschleunigen.

Drag & Drop-Support für die Gruppierungs-Funktion

Es ist nicht neu, dass Du Tickets nach verschiedenen Kriterien gruppieren kannst: nach Person, Priorität, Projekt, Tracker, Kategorie oder Zielversion. Das Besondere: Wenn du ein Ticket zwischen Gruppen ziehst, änderst du gleichzeitig zwei Werte auf einmal.

Ein Beispiel: Du gruppierst nach Priorität. Ein Ticket liegt bei “Normal” im Status “Neu”. Du ziehst es nach “Dringend” in die Spalte “In Arbeit”. Das Ticket wechselt den Status UND wird als dringend markiert - mit einer einzigen Aktion. Das Gleiche funktioniert beim Gruppieren nach Person (Zuweisung ändern), nach Zielversion (Sprint-Zuordnung) oder nach Tracker (Ticket-Typ korrigieren).

Diese Funktion ist verfügbar für: Projekt, Tracker, Priorität, Kategorie (nur projektintern), Zielversion und Zugewiesene Person. Bei anderen Gruppierungen ändert Drag & Drop nur den Status.

Avatar Bar für schnelle Zuweisungen

Die Avatar Bar zeigt dir die Avatare deiner Teammitglieder am oberen Rand des Boards. Du ziehst einen Avatar auf ein Ticket, und schon ist es zugewiesen. Kein Ticket öffnen, kein Dropdown-Menü, keine Extra-Klicks.

Das System merkt sich, welchen Personen du häufig Tickets zuweist - diese erscheinen automatisch in der Bar. Wenn jemand fehlt, klickst du auf das Plus-Symbol und durchsuchst alle Projektmitglieder.

Bei beiden Funktionen - Gruppierungs-Drag und Avatar-Zuweisung - kannst du die Shift-Taste halten, um beim Verschieben einen Kommentar hinzuzufügen. Das ist nützlich, wenn du Kontext mitgeben möchtest: “Max, betrifft dein Modul” oder “Produktionsfehler, bitte sofort prüfen”.

Wann ist das Taskboard geeignet?

Das Board funktioniert überall dort gut, wo Arbeit durch definierte Phasen läuft. Typische Einsatzszenarien:

• Support und Service: Tickets durchlaufen klar definierte Schritte - von “Neu” über “In Bearbeitung” bis “Gelöst”. Das Board zeigt sofort, wo Tickets warten oder sich stauen. Die Avatar Bar macht die Zuweisung an freie Teammitglieder zur Sache von Sekunden.

• Entwicklungsteams: Ob Bug-Tracking oder Feature-Entwicklung - das Board visualisiert den Fortschritt. Gruppierung nach Person zeigt die Lastverteilung, Gruppierung nach Version hilft bei der Release-Planung. Farbliche Kennzeichnung nach Tracker macht Bugs auf einen Blick erkennbar.

• Projektmanagement: Für Projektleiter, die den Überblick behalten möchten. Die Gruppierung nach Person beantwortet “Wer arbeitet woran?”, die nach Priorität zeigt “Was ist wichtig?”, die nach Version visualisiert “Was kommt in welches Release?”.

• Administrative Prozesse: Auch Abteilungen ohne technischen Hintergrund profitieren. Urlaubsanträge, Bestellungen oder Änderungsanforderungen durchlaufen Workflows. Das Board macht diese Prozesse transparent.

Wann ist das Taskboard weniger geeignet?

Das Board hat klare Grenzen. Bei sehr komplexen Tickets mit vielen Custom Fields ist die Detailansicht besser geeignet - auch wenn du die Felder auf den Board-Karten konfigurieren kannst, bleibt der Platz begrenzt. Für detaillierte Zeiterfassung und Reporting bleibt die Listenansicht die bessere Wahl, da sie alle Spalten gleichzeitig zeigt.

Wenn du strikte Scrum-Methodik mit Story Points, Sub-Spalten und WIP-Limits brauchst, bietet das Taskboard diese Funktionen nicht nativ. Hier sind dedizierte Agile-Tools besser geeignet.

Sprint-Tracking mit Burndown Charts

Für Teams, die mit Sprints oder Versionen arbeiten, bietet das Reporting Plugin Burndown Charts als Dashboard-Block für die Projektübersicht und Versionsliste. Du kannst den Fortschritt wahlweise nach Ticket-Anzahl oder geschätzter Zeit visualisieren - für einzelne Projekte oder projektübergreifend. Die Charts lassen sich ins persönliche Dashboard oder Projekt-Dashboard einbinden und ergänzen die Board-Ansicht um metrische Auswertungen. So behältst du nicht nur visuell im Board, sondern auch quantitativ im Chart den Überblick über deinen Sprint-Fortschritt.

Integration in bestehende Arbeitsweisen

Das Taskboard ersetzt nicht die Listenansicht, sondern ergänzt sie. Du kannst für verschiedene Zwecke unterschiedliche Ansichten speichern:

• Ein Filter “Meine Arbeit” mit Board-Ansicht für die tägliche Arbeit,
• ein Filter “Zeiterfassung” mit Listenansicht für Reports,
• ein Filter “Team Sprint” mit Board-Ansicht gruppiert nach Person für Meetings.

Die Board-Konfiguration - welche Felder angezeigt werden, welches Farbschema aktiv ist, wie gruppiert und sortiert wird - speicherst du als Teil deiner benutzerdefinierten Abfrage. Einmal eingerichtet, steht sie dir jederzeit zur Verfügung. Du kannst sie mit deinem Team teilen oder nur für dich behalten.

Verwenden Sie die vorhandenen Filter “Optionen” um das Taskboard aufzurufen und die Informationen anzupassen.

Technische Voraussetzungen

Das Taskboard ist Teil des Reporting Plugins ab Version 4.2.0 (Basis-Drag & Drop) und 4.3.0 (erweiterte Funktionen). Wenn du das Reporting Plugin bereits nutzt, musst du nur auf die entsprechende Pluginversion updaten. Die Funktion respektiert alle konfigurierten Workflow-Regeln und Berechtigungen. Wenn ein Status-Übergang nicht erlaubt ist, springt das Ticket zurück und zeigt eine entsprechende Fehlermeldung.

Das Board funktioniert auf Desktop-Browsern und Tablets. Auf Smartphones ist die Nutzung durch viele Spalten eingeschränkt - hier bleibt die mobile Listenansicht praktischer.

Fazit

Das Taskboard agiert als Visual Workflow Manager. Es visualisiert deine bestehenden Prozesse und macht die Arbeit damit schneller und übersichtlicher. Die erweiterten Funktionen ab Version 4.3.0 eliminieren repetitive Klickarbeit und sparen echte Zeit im Arbeitsalltag. Mit dem Reporting Plugin erhälst du:

• ein Taskboard mit Drag & Drop (Status + Zuweisung)
• Burndown Charts
• Projekt-Burndown für übergreifenden Fortschritt
• Flexible Gruppierung mit Swimlane-ähnlicher Funktionalität (ab v4.3.0)

Ob es für dein Team passt, hängt davon ab, ob ihr mit statusbasierten Workflows arbeitet und visuellen Überblick schätzt. Die einzige Voraussetzung: Das Reporting Plugin muss installiert sein. Den Rest macht das Board.

Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Das kostenpflichtige Reporting Plugin gibt es einzeln oder als Teil unseres Business-Class Bundle, sowie dem Enterprise+ Bundle. Die hier beschriebene Funktion kann in unserer Online-Demo ausgiebig getestet werden. Das Drag&Drop Feature ist Teil der Pluginversion 4.2.0 (Plugin-Update Veröffentlichungen und Mindestvoraussetzungen prüfen).

Weiterführende Infos

• Redmine Reporting Plugin
• Redmine Online Demo
• Plugin Features