In der Regel ist darin der Zeitrahmen festgelegt, den die eine Partei (z.B. Kunde, Lieferant, Abteilungsleiter etc.) für die Lösung eines Problems oder zumindest für die Antwort darauf erwarten kann, wenn er sich über das Redmine Ticketsystem mit Dir und Deinem Team in Verbindung setzt.
Du verpflichtest Dich also bei einer bestimmten Aktion entsprechend zu reagieren. Mit dem Ziel den Ersteller zeitnah zufrieden zu stellen.
Was beim Nichteinhaltung der Verpflichtung passiert, legen die beiden Parteien in einer schriftlichen Vereinbarung fest. Das muss normal niemand aus dem Team wissen. Wichtig ist, jedoch, dass man vorab entsprechende Eskalationsmaßnahme definiert und seine Mitarbeiter auf die Einhaltung der festgelegten Zeitrahmen trimmt.
Das Redmine Reporting Plugin ist mit einer projektbezogenen SLA-Funktion ausgestattet um Dein Team bei einfachen SLA-Tätigkeiten die auf Tickets in Redmine Anwendung finden, zu unterstützen.
SLAs müssen dabei nicht immer nach außen hin angezeigt werden. Dafür sorgt im Bereich Rollen und Rechte die Möglichkeit einer entsprechenden Rechteverteilung für ausgewählte Rollen. Du bestimmst wer in einem Projekt:
Wer SLAs für bestimmte Projekte aktiviert erhält dadurch eine gute Möglichkeit seine Supportleistungen klar zu definieren und sein Team bei der Lösung zu unterstützen. Denn so ist jedem im Team klar worum es geht, wenn er eine bestimmte Aufgabe zugewiesen bekommt hinter der mittels SLA Funktionalität ein Zeitrahmen für eine Reaktions- oder Lösungszeit festgelegt ist.
SLAs mit Hilfe des Redmine Reportin Plugins sind immer Prioritätsbezogen. Dadurch kann man für jede Priorität eine Stundenangabe machen bis zur Reaktion und / oder zur Lösung einer Aufgabe. Abhängig von der ausgewählten Ticket-Priorität.
Beispielsweise kannst Du festlegen, dass eine Verpflichtung für ein Fehler-Ticket mit der Priorität hoch darin besteht, dass der Empfänger auf das Ticket spätestens nach 2 Stunden reagieren muss und innerhalb von 6 Stunden eine Lösung für das Problem finden sollte.
Die SLA-Konfiguration findet in der jeweiligen Projektkonfiguration statt und kann damit für jedes Projekt individuell und auf den Workflow abgestimmt, festgelegt werden.
Mit Hilfe von zusätzlichen Filteroptionen lassen sich SLA Tickets über individuell erstellte Ticketabfragen gut überwachen. Nützliche Filter hierfür sind:
Außerdem kann man durch den Einsatz der Zählerboxen ebenfalls dafür sorgen, dass Dein Supportteam auf der Startseite oder der Projektübersicht rechtzeitig auf neue, auslaufende oder bereits abgelaufene SLA Tickets hingewiesen wird.
Unabhängig davon, ob man mit einem Kunden oder Stakeholder SLA Vereinbarungen getroffen hat oder nicht, kann der Einsatz von SLAs im Projekt generell Vorteile haben:
SLAs für Tickets zeigen erstmals auf, wie groß der Zeitrahmen für die Beatwortung von Anfragen und / oder auch wie hoch das Volumen von bestimmten SLA-Anfragen ist. So lässt sich leichter eine Kundenbewertung durchführen. Denn man erkennt besser, wo der Aufwand für bestimmte Supportanfragen besonders hoch ist und kann hier entsprechend gegensteuern (z.B. durch festlegen spezieller Gebühren für bestimmte Anfragetypen).
Wer SLAs einsetzt, gibt einen Zeitrahmen für die Beantwortung von Tickets vor. Das hilft auch dem Support-Team zu einem besseren Überblick über anstehende Tickets. Was für eine bessere Konsistenz sorgt. Der Kunde weiß, wann er mit einer Antwort rechnen kann und der Supportmitarbeiter kann seine Arbeit entsprechend besser planen.
SLAs helfen bei der Priorisierung. Da die SLAs in Redmine Reporting auf Grundlage der Priorität basieren ist es leichter zu entscheiden welche Anfrage zuerst bearbeitet werden soll. Viele tun sich ohne SLA schwer Tickets zu priorisieren. Diese Arbeit wird in diesem Sinn erleichtert. Denn wenn man die Wahl zwischen niedrig, normal und hoch hat, entscheidet man sich auf jeden Fall für die Tickets mit hoher Priorität und entsprechend kurzer Reaktions- / Lösungszeit. Bevor man sich an Tickets mit anderen Prioritäten darunter macht. Wer jedoch dazu tendiert immer nur hoch priorisierte Tickets zu erledigen und die “normalen” ständig zur Seite schiebt, kann hier mit entsprechend anderen Reaktions- / Lösungszeiten gegensteuern und bleibt dadurch maximal flexibel.
Wenn Deine Supportmitarbeiter SLAs nach Prioritäten sortieren können Sie sicher stellen, dass alles rechtzeitig beantwortet wird. Kein Ticket fällt durch ein Raster oder geht verloren. Nicht beantwortete SLA Tickets sind leicht identifizierbar, sowohl für den Kunden als auch für den Supportmitarbeiter.
SLAs helfen dabei die Leistung des Supports zu messen und innerhalb der SLA-Richtlinien besser zu beurteilen. Das trägt nicht nur für Kundenzufriedenheit bei, sondern auch dazu, dass Du besser erkennen kannst, was Dein Team leistet.
Vielleicht fragst Du Dich, warum unser Reporting Plugin SLAs nach dem Ticketprioritätsprinzip unterstützt?
Die meisten Agenturen oder mittelständischen Betriebe arbeiten nach dem First-in / First-out Prinzip. Tickets in der Warteschlange werden in der Regel der Reihe nach abgearbeitet.
Das Prinzip funktioniert so lange gut, solange das Ticketvolumen in einem überschaubaren Rahmen bleibt. Nehmen die Supportanfragen überhand. Oder hat man nicht genug Mitarbeiterkapazität für die Anfragenbearbeitung, dann nimmt die Ticketlebenszeit und dadurch die Wartezeit des Erstellers deutlich zu.
Stattdessen sollte sich die Reaktionszeit Deines Teams nach dem Grad der Unterstützung Deines Kunden und der Dringlichkeit des Problems richten. Prioritärer Support hebt diese Kunden hervor und hilft Deinem Team, deren Probleme rechtzeitig zu lösen.
Die SLA-Funktion ist nur eines von zahlreichen Features des Redmine Reporting Plugins. Lerne alle Plugin-Funktionen kennen: Featureliste.
Wer in den SLA keine konkrete Lösungs- oder Reaktionszeit vereinbart hat. Oder für ein Projekt gar keinen SLA nutzt, aber dennoch entsprechend seinem Team die Arbeit erleichtern will, kann sich an folgende Richtlinien orientieren wenn es um den Support eines Produkts oder einer Leistung nach dem Prioritätsprinzip geht:
Priorität Niedrig: Anfragen von Personen, die keine aktiven Kunden sind und nichts konkretes zu einem Produkt oder Service wissen wollen. Also nur allgemeine Fragen stellen. Im Idealfall an die Kundenakquise weiterleiten.
Priorität Normal: Fragen oder Probleme von Kunden, die jedoch nicht so gravierend sind, dass der Kunde das Produkt oder den Service aktuell nicht verwenden kann. Aber dennoch eine zügige Antwort erfordern.
Priorität Hoch: Fragen oder Probleme von Kunden, die verhindern, dass dieser das Produkt oder den Service effektiv nutzen kann. Sie erfordern eine sofortige Antwort.
Priorität Dringend: Fragen oder Probleme von Kunden die aufgrund dessen das Produkt oder den Service überhaupt nicht nutzen können (blockierter Einsatz). Sie erfordern eine sofortige Antwort. Diese Probleme sollten immer die oberste Priorität sein.
In unserer Online-Demo kann die aktuelle Version von Redmine getestet werden. Die hier beschriebene SLA Funktion des Reporting Plugins steht dort zur Ansicht bereit. Probier es aus. Fragen beantworten wir Dir gerne via E-Mail. Weitere informationen zum Umgang mit SLAs in Redmine gibt es in folgendem Beitrag unseres Blog.
]]>Mit dem ServiceDesk Plugin werden extern eingehende Anfragen (via E-Mail oder eingebundenem Webform) über ein zentrales Helpdesk-Projekt in Redmine verwaltet und innerhalb des Support-Teams transparent abgewickelt. Das ist möglich, da der Empfang und Versand von E-Mails in Redmine erfolgt. Und nicht über einen nicht einsehbaren E-Mail Account einzelner Mitarbeiter.
Unternehmer stehen häufig vor dem Problem, dass, wenn ein Mitarbeiter geht, sein E-Mail-Postfach bleibt. Dennoch darf der Arbeitgeber die Daten des Ausgeschiedenen aufgrund personenenbezogener Daten nicht uneingeschränkt nutzen. Deswegen ist es besser den Kundenkontakt mittels zentralem Helpdesk zu pflegen. So hat jeder im Team immer Zugriff auf die Informationen, die für ein Unternehmen eine wichtige Rolle spielen.
Jedes Unternehmen hat andere Vorgehensweisen was den Einsatz eines Helpdesk angeht. Die einen nutzen Redmine als Ticketsystem für interne (angemeldete) Anwender. Hierfür ist Redmine standardmäßig gut geeignet und braucht in der Regel keine Erweiterung, da jeder Anwender einen Benutzeraccount besitzt und Möglichkeit hat, ein eigenes Ticket innerhalb Redmine zu erstellen.
Andere wickeln damit extern eingehende Anfragen in Redmine ab. Wenn keine weitere Kommunikation via E-Mail nach außen hierfür notwendig ist, reicht auch hier die Redmine Standardfunktion aus. Eine E-Mail geht an einen für Redmine eingerichteten Mailaccount ein und es wird daraus ein herkömmliches Ticket erstellt.
Erst wenn es darum geht, auch externe Anfragen innerhalb Redmine zu bearbeiten und mit Kontakten außerhalb (ohne Redmine Zugriff) zu interagieren, ist der Einsatz eine Plugins wie dem ServiceDesk notwendig. Hierbei werden eingehende E-Mail Anfragen in ein Helpdesk-Ticket umgewandelt und vom Supportmitarbeiter entsprechend weiterbearbeitet. Antworten an den Kunden werden via Helpdesk-Ticket als E-Mail an den externen Kontakt verschickt.
Unsicher was Du brauchst? Hier geht’s zum Redmine Mailversand Decicion Tree (PDF).
Wer unser ServiceDesk Plugin einsetzt erhält ein Helpdesk für seinen Kunden- und Mitarbeiterservice, um extern eingehende E-Mail Anfragen in einem zentralen Projekt zu bündeln. Von wo aus die Kontaktdaten weiter verwaltet, auf Anfragen schneller reagiert und mit Hilfe von Regeln bestimmte Aufgaben im Team automatisiert werden können.
Helpdesk-Funktionen sind nicht nur für große Unternehmen oder bestimmte Branchen wichtig. Auch kleine, verbraucherorientierte Unternehmen, die Kundenanfragen schnell beantworten müssen profitieren davon. Denn so wird Wachstum und Skalierung gleichermaßen gefördert.
Wer unser Helpdesk für seinen Kunden- und Mitarbeiterservice nutzt, bündelt extern eingehende E-Mail Anfragen in einem zentralen Projekt. Von wo aus die Kontaktdaten weiter verwaltet, auf Anfragen schneller reagiert und mit Hilfe von Regeln bestimmte Aufgaben im Team automatisiert werden können.
Mit der Implementierung folgender Funktionen wird das ServiceDesk Plugin zu einem effizienten Tool für Dein Redmine:
Diese drei Funktionen können für ein ausgewähltes Redmine Projekt als Modul aktiviert und entsprechend konfiguriert werden.
Wird das Helpdesk für mehrere Projekte genutzt, ist für jedes Projekt ein eigener E-Mail Account zu verwenden und in den Projekteinstellungen zu konfigurieren. Ein und derselbe E-Mail Account kann nicht gleichzeitig für verschiedene Projekte genutzt werden. Wir empfehlen immer mit einem zentralen Helpdesk Projekt zu arbeiten. Und mit Hilfe der Automation Regeln oder manuell die Helpdesk Tickets bei Bedarf in ein anderes Projekt zur Weiterbearbeitung zu verschieben.
Wer die Helpdesk Funktion in einem Projekt aktiviert dem steht dadurch automatisch auch die Möglichkeit zur Verwaltung einer Sperrliste bereit. Über diese lassen sich eingehende E-Mails mit bestimmten Begriffen im Betreff oder von bestimmten Absendern zukünftig blockieren.
Alternativ kann ein bestehender Kontakt auch einfach als SPAM markiert werden. Durch diese optische Darstellung ist dem Anwender klar, dass es sich bei den E-Mails dieses Kontakts um unerwünschte Nachrichten handelt. Ein Projektmanager beispielsweise kann dann entscheiden, ob der Kontakt einfach nur gelöscht oder in die Sperrliste gesetzt wird.
Im Redmine Anwendungslog (/log) - einer Funktion des Reporting Plugins - wird dokumentiert, sobald eine E-Mail von einem gesperrten Absender oder aufgrund eines gesperrten Begriffs abgewiesen wurde. So kann man bei Bedarf nachverfolgen, ob auch wirklich die richtigen Inhalte blockiert werden.
Sobald die notwendigen Module (Helpdesk, Kontakt) in einem Projekt aktiviert wurden, kann der Supportmitarbeiter entsprechend seinem Rollenrecht mit Kontakten aus Redmine heraus via E-Mail kommunizieren.
Alles was er hierfür tun muss, ist:
Es öffnet sich ein eigener Bereich um eine E-Mail Nachricht an die im Kontakt hinterlegte Empfänger E-Mail zu verfassen. Sowohl CC als auch BCC Empfänger sind möglich. Bei Bedarf ist auch der Einsatz von Variablen erlaubt.
Der Versand der Nachricht wird im History-Eintrag zum Kontakt dokumentiert. Dadurch wird die Kommunikation für andere Teammitglieder transparenter. Sollte der Eintrag durch einen Anwender mit entsprechender Berechtigung gelöscht werden, wird dieser Löschvorgang im Redmine Anwendungslog (/log) entsprechend dokumentiert.
Der Unterschied zwischen einem regulären Redmine Ticket und einem Helpdesk Ticket liegt darin, dass ein Helpdesk Ticket einen Kontakt zugewiesen hat. Nur durch diesen Kontakteintrag ist eine Kommunikation via E-Mail aus Redmine heraus möglich. Sonst nicht.
Möchte man aus einem regulären Redmine Ticket ein Helpdesk Ticket machen, dann sind folgende Schritte nötig:
Sind die genannten Voraussetzungen erfüllt, dann kann in der Ticketansicht über den rechten Seitenbereich ein Kontakteintrag zugewiesen werden.
Für viele Anwender ist der Unterschied zwischen einem regulären Ticket und einem Helpdesk Ticket in Redmine nicht klar. Um Missverständnisse vorzubeugen besitzen Helpdesk Tickets zusätzlich den Label Helpdesk. Tickets ohne diesen Label sind keine Helpdesk Tickets. Solche Tickets sind nicht geeignet um eine E-Mail Kommunikation mit einem externen Kontakt zu führen. Sobald ein Ticket ein Helpdesk Ticket ist, kann man auf Ticketkommentare antworten und diese Antwort via “E-Mail” an den Ticketersteller verschicken.
Damit Du Deine Mitarbeiter gut unterstützt, brauchst Du die hierfür notwendigen Funktionen. Das ServiceDesk Plugin liefert einen Dashboard Support. Das bedeutet, Du kannst sowohl die Redmine Startseite als auch die Projektübersichtsseite durch eigene Dashboards individuell für Dein Support Team gestalten.
Damit die Helpdesk Tickets von Deinem Team schnell bearbeitet werden können, gibt es den Dashboard Block Helpdesk Information. Dieser wird auf der Projektübersichtsseite platziert (von einem Anwender mit entsprechender Berechtigung). und liefert alle Informationen zu existierenden Helpdesk Tickets (offen / gesamt) im Projekt. Dazu gehören beispielsweise:
Dieses Dashboard ist somit der zentrale Einstieg für Dein Team. Denn die Einträge sind entsprechend verlinkt. Dadurch ist klar, wieviel Helpdesk Tickets existieren (offen / insgesamt), über welchen Kanal sie reingekommen sind (E-Mail, Webform) und wieviel Kontakte im Projekt existieren.
Ein Helpdesk Ticket wird wie ein herkömmliches Ticket gemäß dem vorgegebenen Workflow bearbeitet. Der Supportmitarbeiter kann das Ticket direkt beantworten. Oder er weist es einem anderen Redmine Anwender zur weiteren Bearbeitung zu. In dem Fall kann er auch einen (internen) Kommentar hinterlegen, der nicht als E-Mail an den externen Kontakt verschickt wird.
Antwortvorlagen (sogenannte Canned responses) sind Vorlagen für Helpdesk-Tickets. Diese ermöglichen es Dir, eine vorbereitete Antwort auf eine Helpdesk-Frage anzuwenden. Im Service Desk-Plugin wird diese Funktionalität sowohl für Antworten auf Helpdesk Tickets, als auch herkömmliche Redmine Tickets bereit gestellt.
Anwender mit entsprechender Berechtigung können Antworvorlagen:
erstellen. Sowohl projektbezogen als auch projektübergreifend.
Mittels TAGs lassen sich die Vorlagen gut kategorisieren. Und der Inhalt lässt sich durch die Implementierung von Variablen personalisieren.
Antwortvorlagen sind gut geeignet um Kundenfeedback einzuholen nachdem ein Problem behoben wurde, oder um zu beurteilen, wie zufrieden die Kunden sind. Hierfür können in die Antwortvorlagen die entsprechenden Variablen eingebaut werden.
In der Plugin Konfiguration hat der Administrator die Möglichkeit folgende Vorgaben für Automatisierungen vorzugeben:
Ein Projektmanager mit Zugriff auf das Helpdesk hat die Möglichkeit in der Projektkonfiguration die Vorgabe für E-Mail Antworten, sowie automatische E-Mail Antwort zu überschreiben.
Ob ein Ticket automatisch geschlossen wird oder nicht, kann er nicht beeinflussen. Jedoch kann er die Textvorgabe an seine Projektbedürfnisse überarbeiten.
Weitere Automatisierungen sind nur für Anwender mit Administratorrechten konfigurierbar. Und zwar in den Plugineinstellungen des Automation Plugins im Abschnitt Eigene Regeln. Diese Aufgabe sollte nur von Anwendern mit dem nötigen Wissen durchgeführt werden, denn bei falscher Konfiguration können alle Tickets in Redmine betroffen sein - nicht nur Helpdesk Tickets.
Durch die Automation Plugin Regeln bieten sich zahlreiche Möglichkeiten der Workflow Automatisierung an. Das Plugin ist so umfangreich, dass es mit einer eigenen Dokumentation speziell für diesen Anwendungszweck ausgeliefert wird.
Beispielsweise lassen sich mit Hilfe von Automation Regeln Kontaktdaten pflegen und bereinigen wie beispielsweise:
Das ServiceDesk Plugin liefert verschiedene Funktionen deren Nutzen sich rollenbezogen einschränken lässt. Über die Rollenberechtigung legt der Administrator fest, ob ein bestimmter Anwender Zugriff auf die Helpdesk Funktion hat oder nicht. Und falls ja, was er für Tätigkeiten ausführen darf. Gleiches gilt auch für die anderen Funktionen wie Kontaktverwaltung, Antwortvorlagen oder Rechnungsverwaltung.
Für einen Anwender ohne Helpdesk-Zugriff sieht ein Helpdesk Ticket nicht viel anders aus, als ein reguläres Redmine Tickets.
Anwender mit Administratorberechtigung sind für die Plugin Installation und Konfiguration zuständig. Sie übernehmen die grundlegenden Einstellungen im Admin-Bereich. Dazu gehören nicht nur die Plugineinstellungen, sondern auch die Festlegung der Rollenberechtigung hinsichtlich der verfügbaren Funktionen und der notwendigen Automatisierungen.
Wichtig ist auch die Implementierung des Support Tokens. Nur mit dieser Integration steht Deinen Redmine Anwendern innerhalb des Redmine Systems die Plugin Dokumentation im Top-Menü “?” zur Verfügung. Die Funktionen sind so umfangreich, dass die Anwender (Projektmanager und Supportmitarbeiter) in jedem Fall einen Blick in die Hilfe werfen sollten.
Projektmanger, welche die Funktion nutzen möchten können die entsprechenden Module in ihrer Projektkonfiguration aktivieren. Anschließend sind die Funktionen projektspezifisch zu konfigurieren. Wird das Helpdesk genutzt, ist der hierfür zu verwendende E-Mail Account einzurichten und die Vorgaben für Helpdesk-Tickets und Kontakte zu definieren.
Weiterhin sind die Helpdesk-Vorgaben zu prüfen, die der Administrator in der Pluginkonfiguration vorgegeben hat. Bei Bedarf lassen sich diese projektbezogen ändern.
Die Sperrliste ist zu Beginn leer. Hier ist es erst nach einiger Zeit notwendig, die Daten zu prüfen und nicht erwünschte E-Mails abzuwehren. Manchmal landen hier auch versehentlich E-Mail Adressen von Kontakten, die explizit gewünscht sind. Dann sollte man diese hier entsprechend entfernen.
Hat der Projektmanager die Möglichkeit Dashboards zu verwalten, sollte er ein eigens für den Support nutzbares Dashboard erstellen und dort die Helpdesk spezifischen Dashboards Blocks hinzufügen. Dadurch erleichtert er seinem Support Team die Abwicklung von eingehenden Helpdesk Tickets.
In der Regel hat ein Unternehmen eine zentrale E-Mail an welche Kontaktanfragen / Supportanfragen gehen. Pro Projekt ist nur ein E-Mail Konto nutzbar. Es reicht also vollkommen aus hierfür ein einzelnes Projekt in Redmine als Helpdesk zu aktivieren. Von diesem werden die Tickets dann durch Supportmitarbeiter weiter bearbeitet oder bei Bedarf in ein anderes (passendes) Projekt verschoben. Mit dem ServiceDesk Plugin ist es möglich aus anderen Projekten heraus auf Helpdesk-Tickets zu antworten., insofern die Funktion (Helpdesk, Kontakte) aktiviert ist. In den projektbezogenen Helpdesk-Einstellungen wird hierbei für den Versand von E-Mail im Bereich „Ausgehender Mailserver“ das Protokoll „Redmine Standard“ verwendet. Wichtig: Stell vorher sicher, dass der definierter Redmine Standard Mail Account auch andere Absender E-Mails erlaubt.
Anwender mit entsprechender Rollenberechtigung sind für die Bearbeitung eingehender Helpdesk-Tickets zuständig. Hierbei ist der reguläre Redmine Workflow anzuwenden. Die Tätigkeit an einem Helpdesk-Ticket wird sich nicht viel von der eines regulären Redmine Tickets unterscheiden.
Der Hauptunterschied liegt meist darin, dass ein Helpdesk-Ticket einem Kontakt zugewiesen ist und man über das Ticket mit diesem Kontakt kommuniziert. Wobei der Kommentar als E-Mail an den Kontakt verschickt wird.
Zugriff auf Helpdesk-Tickets erhält der Supportmitarbeiter über die Ticketliste. Mit Hilfe der verfügbaren Ticketfilter lassen sich die Tickets nach bestimmten Kriterien heraus filtern. Existiert ein eigenes Dashboard mit dem “Helpdesk Informationen” Dashboard Block, dann lassen sich darüber die Tickets schnell abrufen.
Das Plugin ist aktuell in den Sprachen DE und EN verfügbar und für den deutschsprachigen Raum ausgerichtet. Es ist geeignet für Unternehmen mit Kundendienst-Agenten und -Managern, welche Redmine als Helpdesk zur Abwicklung von per E-Mail eingehenden (Support-)Anfragen ihrer Mitarbeiter, Kunden oder Dienstleister nutzen, einen deutschsprachigen Support oder in der EU ansässigen Hersteller bevorzugen.
Mitarbeitern steht durch Implementation des gekauften Lizenz Support Tokens für 12 Monate Zugriff auf die Anwendungsdokumentation (EN / DE) innerhalb des Redmine Top-Menüs bereit. Über die REST API ist ein Austausch der Plugin-Informationen auch mit anderen Anwendungen möglich.
Kontaktdaten aus anderen Anwendungen lassen sich via CSV Import einlesen. RedmineUp CRM Anwender steht alternativ auch ein Migrationsskript zur Verfügung. Dadurch ist das Plugin nicht nur für Neueinsteiger, sondern auch für Umsteiger geeignet.
Das ServiceDesk Plugin ist Teil des Enterpise+ Bundles. Es benötigt sowohl das Reporting Plugin als auch das Automation Plugin als Basis. Es ist nicht einzeln oder in einem anderen Bundle erhältlich. Alternativ kann die Funktion als Teil des Redmine Managed Application Hosting Pakets R100 gebucht werden. Dies empfehlen wir Kunden, die das Plugin nicht selbst installieren und betreuen wollen.
Möchtest Du mehr über das ServiceDesk und dessen Funktionen erfahren?
Das Plugin kann nur genutzt werden, wenn das Redmine System unseren Mindestvoraussetzungen entspricht. Kompatibilitätsprobleme mit anderen Plugins / Plugin Hersteller sind in der FAQ gelistet.
Das Dashboard dient somit als zentrales Steuerungsinstrument, um den Projekterfolg zu gewährleisten. Es ermöglicht eine transparente Kommunikation aller Beteiligten und fördert die Zusammenarbeit im Team. Die regelmäßige, automatische Aktualisierung des Dashboards stellt sicher, dass die Informationen dem aktuellen Stand entsprechen und eine solide Grundlage für Entscheidungen bieten.
Mehr über Dashboards und deren Einsatzzweck erfährst Du in unserem Dashboard Guide und unserem Einführungsartikel zu Dashboard im Blog.
Der hier vorgestellte Use Case ist eine Möglichkeit die aufzeigt, wie agile Teams die Dashboard Funktion unserer Plugins nutzen können, um Aufgaben im Blick zu behalten.
Wer Redmine bereits als Projektmanagement- und Ticketsystem in der von uns vorgegebenen Version einsetzt, muss für die Erstellung des hier vorgeschlagenen Dashboards noch folgende Bedingungen erfüllen:
Mit Dashboards kann man bestimmte Bereiche in Redmine so anpassen, dass sie den individuellen Anforderungen entsprechen die dich und dein Team besser voranbringen.
Das folgende Layout ist beispielsweise ideal für ein agiles Team geeignet, um Ticketfortschritte, Workload der Mitglieder, wichtige Tickets und überfällige Projekttickets zu verfolgen.
Das von uns vorgeschlagene Redmine-Dashboard-Beispiel ist einfach zu erstellen. Die notwendigen Dashboard-Blöcke werden vom Redmine Reporting Plugin bereit gestellt. Als Benutzer mit entsprechender Berechtigung kann man ein neues Dashboard für die Redmine Startseite oder die Redmine Projektübersicht Seite erstellen und sichtbar machen für:
Zur grafischen Auswertung können in einem Dashboard die folgenden Diagramme des Redmine Reporting Plugins verwendet werden. Welche mit der entsprechenden Liste verknüpft sind, wenn man auf die Grafik klickt. Über die Auswahl Block hinzufügen ordnet sie ein Anwender mit entsprechender Berechtigung im Dashboard zu und positioniert sie:
Für die Auswertung des Ticket-Status müssen entsprechende Listen mit Ticketfiltern erstellt werden. Diese speichert man ab und ordnet sie anschließend im Dashboard über den folgenden Dashboard Block zu:
Um die Ticket-Workload seiner Teammitglieder zu ermitteln, kann eine Ticketliste wie die folgende erstellt werden, indem man mit Hilfe der Ticketfilter und Optionen die Liste nach diesen Bedürfnissen anpasst.
Speichere die gefilterte Ticketliste und achte dabei auf folgendes:
Um eine Liste seiner Projekt-Backlog-Elemente zu erhalten, kann eine Ticketliste wie folgende erstellt werden. Hierfür werden wieder die Filter und Optionen der Projektübergreifenden Ticketliste verwendet um die notwendigen Einträge entsprechend zu filtern. Auch hier ist beim speichern der Ticketliste darauf zu achten, dass die Inhalte für alle Anwender nutzbar sind (mittels Für alle Projekte).
Für die Auswertung des Sprintstatus müssen entsprechende Versionslisten erstellt werden. Der Vorgang hier ist der gleiche wie bei den Ticketlisten. Mit Hilfe der Filter und Optionen wird das gewünschte Ergebnis erstellt und abgespeichert. Abschließend wird die Liste im Dashboard über folgenden Dashboard Block zugewiesen:
Was ist Dir sonst noch wichtig? Das Tutorial soll nur eine kleine Einführung sein, was mit der Dashboard Funktion möglich ist. Es gibt sicher noch viele andere Einsatzzwecke bei Dir im Team oder im gesamten Unternehmen.
Die zusätzlichen Filteroptionen des Reporting Plugins helfen dabei die verschiedenen Listen sinnvoll zu nutzen. Besonderheit des Burndown Chart: Er kann auf eine Version mit Start und Enddatum angewendet werden. Funktioniert aber auch wenn kein Startdatum und / oder Enddatum hinterlegt ist.
Zudem gibt es die Möglichkeit den Projekt Burndown Chart zu nutzen. Dieser bezieht sich dann (anders als der reguläre Burndown Chart) auf das gesamte Projekt und bei Bedarf auch auf Tickets aus vorhandenen Unterprojekten.
Möchtest Du mehr über das Dashboard für Redmine erfahren? Schau Dir die Möglichkeiten doch mal in unserer frei zugänglichen Online-Demo an: Unsere öffentliche Demo-Instanz ist jederzeit verfügbar und prima geeignet, um sich einen ersten Eindruck von der Funktionalität zu verschaffen.
Da wir stets auf der Suche nach Möglichkeiten sind die Anwendung von Redmine für unsere Kunden und uns so gut es geht zu vereinfachen, musste eine Art von Ticketwiederholung her. Denn je größer das Unternehmen, desto mehr Projekte und desto mehr sich wiederholende Aufgaben gilt es zu verwalten.
Niemand kann es sich leisten hier den Überblick zu verlieren. Deswegen nutzt man die Möglichkeit bestimmte, sich wiederholende Ticketvorgänge zu automatisieren. Nur so kann Dein Team so schnell und produktiv wie möglich arbeiten - und verbringt deutlich weniger Zeit mit administrativen Aufgaben.
Ein bereits existierendes Redmine Ticket lässt sich mit Hilfe des Automation Plugins gut automatisieren und zur wiederholenden Ticketvorlage umfunktionieren. Zum Einsatz kommen hier die existierenden Zeitintervalle des Automation Plugins, welche den Anwendern zur Auswahl bereit stehen.
Für Ticketwiederholungen werden beliebige Zeitintervalle in der Pluginkonfiguration hinterlegt.
Anwender mit entsprechender Berechtigung können aus jedem offenen Ticket eine Ticketwiederholung erzeugen.
Möchte man eine automatische Ticketwiederholung beenden, wird die Ticketvorlage heraus gesucht und der Status auf “geschlossen” geändert. Geschlossene Tickets können nicht als Vorlage verwendet werden.
Damit ein Ticket als Vorlage für eine Ticketwiederholung nutzbar ist, sind folgende Voraussetzungen zu erfüllen:
Damit Du Tickets, die sich regelmäßig wiederholen nicht aus den Augen verlierst gibt es zusätzliche Filter (z.B. Intervall) für die Ticketsliste. Mit denen behälst Du stets einen Überblick zu allen Ticketwiederholungen und deren nächste geplante Ausführung.
Mit dem Redmine Automation Plugin kann man also zeitintensive, wiederkehrende Tätigkeiten wie die hier genannten Beispiele, einfach und sicher automatisieren ohne etwas zu vergessen.
Alles was man tun muss, wenn man sich mit dem Thema Automatisierung in Redmine beschäftigt ist:
Probiert’s aus. In unserer Online-Demo könnt ihr die Funktion testen. Das Redmine Automation Plugin ist eine Funktionserweiterung für aktuelle Redmine Versionen. Mit ihm erstellt man Regeln für verschiedene Entitäten (z.B. Tickets, Projekte, Benutzer, DB-Einträge etc.) und hat auch die Möglichkeit Wiederholungen zu Tickets oder Zeitbuchungen zu nutzen.
Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Kunden, deren Redmine den Mindestanforderungen nicht entspricht oder die lieber jemanden für die Installation und regelmäßige Pflege ihrer Redmine-Instanz beauftragen wollen, haben alternativ die Möglichkeit unser Managed Applikation Hosting für Redmine zu buchen. Hier ist das Plugin bereits Teil unseres Hosting Angebots. Die Funktionalität kann in unserer Online-Demo ausgiebig getestet werden.
An sich keine große Sache, wenn da nicht der übliche Agentur-Alltag wäre. Hier muss man aufpassen nicht zusätzlich noch mit dringenden oder schnell zu erledigenden Aufgaben konfrontiert zu werden.
Und selbst wenn Du die Situation im Griff hast, ist es nicht ungewöhnlich, dass ein Angestellter an mehreren Projekten gleichzeitig arbeitet. Das bedeutet, dass dieses Teammitglied nicht in der Lage ist, sich zu 100 % auf Dein Projekt zu konzentrieren. Folglich musst Du als Projektleiter die Aufgaben so verteilen, dass auch die anfallenden Tätigkeiten des Mitarbeiters in anderen Projekten entsprechend berücksichtigt werden. Von Krankheit, Forbildung und Urlaub mal abgesehen.
In der Regel ist selbst eine 14-tägige Planung recht zeitaufwändig, sobald jemand aus Deinem Team in mehrere Projekte gleichzeitig eingebunden ist. Und wenn sogar Du selbst noch einen Kollegen vertreten musst, wird die Projektplanung nochmal stressiger.
Wer jetzt immer noch damit beschäftigt ist alle Eventualitäten akribisch und manuell zu planen tut sich schwer jemals aus diesem Mikrokosmos der Projektplanung auszubrechen.
Abgesehen davon hat das nicht mehr viel mit Agilität zu tun. Eine große Herausforderung bei der Steuerung agiler Projekte ist nämlich den “administrativen” Projektaufwand so gering wie möglich zu halten.
Mit herkömmlichen Werkzeugen, die im klassischen Projektmanagement eingesetzt werden, wird es schwierig Mikromanagement zu vermeiden. Deswegen ist der Einsatz von Tools, die das Selbstmanagement Deines Teams fördern wichtig. Manuelle Anpassungen sollten nur im Notfall erfolgen.
Das Redmine HRM Plugin ist ein solches Tool für Redmine. Es ist ideal geeignet für agile Projektteams, die mit Redmine als Projektmanagement-Software arbeiten. Das AlphaNodes HRM Plugin hat hierfür spezielle Regeln zur Ressourcenberechnung implementiert, die es erlauben, die Zuordnung von Aufgaben so zu bestimmen, dass:
standardmäßig in Real-Time (bei der Planung) berücksichtigt werden.
Darin unterscheidet sich dieses Plugin von anderen Tools für Redmine, die derzeit auf dem Markt sind. Unser Ziel war es von Anfang an, dem zeitraubenden Mikromanagement in der Projektplanung entgegenzuwirken und den Fokus mehr auf das Selbstmanagement zu legen.
Die Regeln gelten für die Ressourcensicht der geplanten Stunden und sind für die folgenden Bereiche nutzbar:
Kriterien, dass ein Ticket in die Ressourcenplanung einbezogen wird sind:
Als Projektleiter sollte man nur dann manuell eingreifen, wenn Dir bestimmte Aufgaben wichtiger erscheinen oder aus anderen Gründen vorgezogen werden müssen. Das HRM-Plugin ordnet automatisch die verfügbaren Tickets der beteiligten Redmine-Benutzer in dem vorgegebenen Zeitrahmen des Sprints zu.
Die Sprint-Planung sollte realistisch sein. Stopfe die Aufgabenliste nicht mit zu vielen Tätigkeiten für den Sprint voll. Gerade in einem neu zusammengewürfelten Team wird sich schnell nach dem ersten Sprint heraus stellen, was das Team tatsächlich für ein Aufgabenvolumen leisten kann.
Dies sollte bei der Sprint Planung im Hinterkopf bleiben:
Was ist ein Release-Plan? In vielen Projekten fehlt es an Fokus und Klarheit. Deswegen müssen klare Ziele her die definieren was in welchem Zeitraum umgesetzt wird. Bei einem Release handelt es sich also um festgelegte Zeiträume, in denen an einem Teilbereich (Features, Funktionen) des Gesamtprojekts gearbeitet wird. Mit Hilfe des Reporting Plugins hat man die Möglichkeit die einzelnen Zeiträume durch die Versionen festzulegen und deren zeitlichen Verlauf in der Versionsliste aufzulisten.
In der Ressourcenplanung des HRM Plugins werden alle Aufgaben aufgelistet, die:
Die Verwaltung von Ressourcen in Redmine kann mit dem richtigen Ressourcenmanagement-Tool wie dem hier erwähnten HRM Plugin recht einfach werden. Das Plugin ist nur ein Teil des großen Ganzen, aber es sorgt in jedem Fall für eine Verbesserung, wenn es darum geht, das Projektmanagement und die Projektplanung mit Redmine so einfach wie möglich zu gestalten.
Die Funktionalität kann in unserer Online-Demo getestet werden. Die Ressourcenplanung ist hierbei nur ein Bereich des HRM Plugin. Es gibt weitere Funktionen wie Urlaubsplanung und Anwesenheitsmanagement, welche auch für überwiegend remote arbeitende Teams nützlich sind. Das multilinguale HRM Plugin ist im Bundle mit dem Reporting Plugin erhältlich (wird als Basis benötigt) oder Teil des Enterprise+ Bundles.
Wer überwiegend remote arbeitet und seine Arbeitszeit auf viele Projekte parallel aufteilt steht vor einer entsprechend hohen Anzahl an Tickets. Dazu kommen regelmäßige Status-Updates und entsprechend viele Benachrichtigungen bei Änderungen.
Wer hier kein strukturiertes Vorgehensmodell besitzt, der tut sich auf jeden Fall leichter, mit entsprechender Hilfe. Das Redmine Reporting Plugin liefert eine passende Funktionalität durch den Einsatz von Zählerboxen. Basierend auf benutzerdefinierte Abfragelisten erstellst Du für Dich und Dein Team einfach entsprechende Zählerboxen nach der Getting-Things-Done Methode. Und hilfst zu entscheiden, woran als nächstes gearbeitet werden soll.
Als Projektmanager oder Teamleiter bist Du für die Produktivität Deines Teams verantwortlich. Allerdings macht es keinen Sinn hinter allen hinterher zu laufen und vorzugeben, woran heute gearbeitet wird. Dein Team muss in der Lage sein, ein gewisses Maß an Eigenverantwortung an den Tag zu legen. Soviel Eigeninitiative muss man von einem Mitarbeiter verlangen dürfen.
Dennoch hast Du eine Möglichkeit, den Entscheidungsprozess bis zu einem gewissen Grad zu beeinflussen. Indem Du gemeinsam mit Deinem Team überlegst, wie ihr Aufgaben, die jeder mehr oder weniger dringlich zu erledigen hat, strukturieren könntet und dadurch entsprechende Vorgaben macht, was Priorität hat.
Um Deinen Mitarbeitern die Entscheidungsfindung zu erleichtern, haben wir eine Lösung, die hilft, ähnliche Aufgaben zusammenzufassen. Alles, was Du tun musst, ist herauszufinden, welche Struktur für die Bearbeitung von Aufgaben in Deinem Projekt sinnvoll wäre. Hier sind einige Beispiele, die bei der Zusammenfassung von Aufgaben Sinn machen könnten.
Die Erledigung von Aufgaben nach Dringlichkeit oder zeitlichen Fristen ist wohl eine der häufigsten Optionen. Wer seine Tickets nach Priorität sortiert, könnte die Zählerboxen nach der GTD-Methode wie folgt aufbauen.
Eine Möglichkeit zu entscheiden, was ich heute erledigen möchte, kann auch der zeitliche Arbeitsaufwand für ein Ticket sein. Manchmal reicht die Zeit einfach nicht für mehrere Stunden konzentrierte Arbeit. Um trotzdem etwas schnell zu erledigen, fokussiert man sich auf die Aufgaben, die schneller gehen. Hier hilft es, sich auf die Zeitschätzung einer einzelnen Aufgabe zu konzentrieren.
Es gibt Menschen, die feste Rituale in ihre Arbeitswoche einbauen. Sie konzentrieren sich darauf, bestimmte Aufgaben zu bestimmten Zeiten zu erledigen. Wichtige Besprechungen werden zum Beispiel als erstes am Morgen erledigt. E-Mails werden nur vor dem Ende des Arbeitstages beantwortet. Oder jeden Montag wird eine Marketingkampagne gestartet. Hier hilft es, sich entsprechend einer Kategorisierung auf die zu erledigenden Tickets zu konzentrieren.
Eine ebenfalls beliebte Methode, die wir unseren Kunden empfehlen, ist die Strukturierung von Aufgaben nach Tracker-Status. Sie ist in der Regel für jeden Mitarbeiter - vom Novizen im Team bis zum langjährigen Veteranen - gut geeignet. Denn zum einen bildet sie den Workflow eines Tickets im Zählerboxenbereich ab. Zum anderen erleichtert es neuen Mitarbeitern, sich schnell zurechtzufinden.
Egal, welches der oben genannten Beispiele für Dich in Frage kommt. In der Regel reicht ein Blick und man erkennt leichter, wo es Sinn macht mit seinen täglichen Arbeiten im Projekt anzufangen.
Alles, was Du tun musst, damit die Getting-Things-Done-Methode mit den Zählerboxen funktioniert, ist:
Über die Verwendung von Zählerboxen nach dieser Methode haben wir schon einmal geschrieben. In der Plugin-Dokumentation wird auch der Einsatz und die Konfiguration genauer erklärt.
Lies unseren älteren Blogbeitrag zum Thema Getting Things Done im Projektmanagement mit Redmine, wenn Du weitere Infos hierzu benötigst.
Das Redmine Reporting Plugin eignet sich für Unternehmen mit fachübergreifenden IT- und Business-Teams, die Redmine als Projektmanagement-Tool nutzen und einen besseren Überblick über Zeitpläne, Fortschritte und Budgets erhalten möchten.
Die Counterboxen lassen sich auch mit unseren anderen Produkten integrieren wie beispielsweise:
Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Das kostenpflichtige Reporting Plugin gibt es einzeln oder im Bundle mit weiteren Funktionen. Die Funktionalität kann in unserer Online-Demo ausgiebig getestet werden.
Unsere Plugins unterstützen die neu veröffentlichte neue Redmine Version ab Plugin Version 3.1.0.
Starten wir auch gleich mit einigen Anpassungen zur Verbesserung der Usability im Bereich Ticket Status und Aufwandsbuchungen. Danach lernt ihr noch zwei größere Neuerung für Administratoren kennen (Projektliste und Benutzerliste).
Legt ein Administrator in den Redmine Einstellungen die verschiedenen Ticket Status Angaben fest, hat er dort die Möglichkeit eine entsprechende Beschreibung zum jeweiligen Status zu hinterlegen.
Die Beschreibung ist auch für den Anwender sichtbar. Das erleichtert diesem besser zu verstehen, worum es bei dem jeweiligen Status geht. Hierzu wird in der Ticket Bearbeiten-Ansicht einfach auf das Informationssymbol neben Status geklickt und die dazugehörige Info wird Dir angezeigt.
Tipp: Wer zusätzlich das kommerzielle Redmine Reporting Plugin nutzt, kann sich auch den dazugehörigen Workflow Graphen ausgeben lassen. Dann wird der komplette Ticketablauf von Anfang bis Ende einer Aufgabe zusätzlich visuell dargestellt.
Eine weitere Verbesserung der Usability liefert die Möglichkeit für eine Rolle eine Aufwandsbuchungaktivität als Standard zu definieren. Bisher musste man die als Redmine Anwender mit der Möglichkeit für Zeitbuchungen zu Tickets pro Buchung entsprechend auswählen. Durch die Vorauswahl bleibt einem dieser Schritt erspart.
Bleiben wir gleich im Bereich Aufwandsbuchung und stellen Dir die neue Import-Funktion mittels CSV Datei vor.
Der Export von Aufwandsbuchungen war ja schon immer möglich. Mit Hilfe der verfügbaren Filter und Optionen kann man sich eine passende Liste an Informationen für den Export zusammen stellen und diese dann für später speichern, oder alternativ als CSV Datei ausgeben. Beispielsweise zur Weiterverarbeitung in einer externen Anwendung.
Redmine Administratoren oder Anwender mit entsprechendem Rollenrecht erhalten mit Redmine v5.1.0 nun auch die Gelegenheit aus einem externen System mittels CSV Import Aufwandsbuchungen in Redmine zu importieren.
Nach der Auswahl der CSV-Datei wird mittels Field mapping der Dateiinhalt den Feldern in Redmine zugeordnet (z.B. Project, Activity, User, Issue, Date, Hours, Comment). Passt alles zusammen, einfach auf Import klicken und sehen was passiert. Treten Probleme auf, sind diese entsprechend der Fehlermeldung vor dem nächsten Importversuch zu beheben.
Anwender mit Administratorberechtigung haben nun in den Redmine Einstellungen im Bereich Projekte (/admin/projects) zur einfacheren Verwaltung von umfangreichen Projektlisten die Möglichkeit diese entsprechend dem persönlichen Bedarf zu optimieren.
Hierfür stehen Filter wie Status, Projekt, Unterprojekt von, Öffentlich, Erstellt bereit. Sowie die dazugehörigen Spalten-Optionen. Die durchgeführten Änderungen lassen sich für einen späteren / schnelleren Zugriff als benutzerdefinierte Abfrage speichern.
Über die Multiselekt Auswahl kann man mehrere Projekte gleichzeitig löschen. Den Löschvorgang muss man jedoch noch einmal bestätigen. Über das Aktionen-Menü pro Projektzeile kann man das ausgewählte Projekt archivieren, kopieren oder einzeln löschen.
Eine ähnliche Überarbeitung gab es für die Benutzerliste im Administrationsbereich. Auch hier sind neue Filter und Optionen zur individuellen Darstellung der Inhalte hinzugekommen. Welche sich bei Bedarf auch als benutzerdefinierte Abfrage abspeichern lassen.
Nicht optimal gelöst hinsichtlich Usability ist die Darstellung / Positionierung der Inhalte im rechten Seitenbereich. Bei einer langen Liste an benutzerdefinierten Abfragen verschwindet das relevante Administrationsmenü schnell aus dem Blickfeld.
Tipp: Wer zusätzlich das Administrationsmenü über das “Top-Menü” abrufen will, oder andere Bereiche als Menüpunkte im Top-Bereich integrieren möchte, der kann zusätzlich das kommerzielle Redmine HRM Plugin nutzen. Hier ist es möglich benutzertypen spezifische Menüs anzulegen. Um einen schnellen Zugriff auf relevante Bereiche zu ermöglichen oder bestimmten Benutzern zielgerichtet Zugriff auf externe URLs zu ermöglichen.
Die über den Header global zugängliche Suche im Bereich /search liefert ebenfalls ein paar Neuerungen:
Was wir sonst noch ganz nützlich finden ist die Möglichkeit sich die einzelne Version einer Roadmap als Textdatei (TXT) ausgeben zu lassen. Diese kann man dann problemlos irgendwo an anderer Stelle platzieren. Infos hierzu auf Redmine.org
Auch die Anpassungen der Desktop-Kalenderansicht in eine mobile Ansicht ist ein tolles Upgrade. Die typische Tabellenstruktur passt sich dann entsprechend der verwendeten Smartphone oder Tablet-Größe an und ändert sich in eine vertikale Listenansicht.
Außerdem gibt es für verschiedene Bereiche neue Filter oder Filteroperatoren, welche das aufspüren von Tickets oder Zeitbuchungen zu Tickets / Projekten nochmal erleichtern sollen. Dazu gehören beispielsweise:
Mehr dazu findet man in der oben verlinkten Changelog zur neusten Redmine Version.
Neu hinzugekommen ist auch das Rollenrecht Set project public or private. Um seine Projekte und die damit verwalteten Inhalte noch besser vor unachtsamer Anwendung durch Projektmanager zu schützen kann man dieses Recht nun rollenbezogen vergeben, oder eben auch nicht. Wer mit öffentlichen Projekten arbeitet muss immer auch prüfen, ob die Rechte für die Rollen Nicht-Mitglied und Anonymous entsprechend dem geplanten Einsatzzweck gesetzt sind.
Redmine ist eine kostenlose, webbasierte Projektmanagementsoftware, die Projektteams aller Art umfangreiche Funktionen bietet. Neben der Benutzer- und Projektverwaltung haben die Nutzer Zugang zu Diskussionsforen, Wikis und Aufgabenmanagement. Redmine ist eine gute Alternative zu kommerziellen Anwendungen. Denn Unternehmen können kostengünstiger skalieren und sind nicht an bestimmte Anbieter oder begrenzte Nutzerlizenzen gebunden. Wer mehr über Redmine erfahren möchte, findet umfangreiche Informationen unter “redmine.org”.
Um TAGs zu einem Ticket oder Wiki sehen, hinzufügen oder ändern zu können, benötigt man entsprechende Rechte, wenn man kein Administrator ist. Diese werden im Administrationsbereich unter Rollen und Rechte konfiguriert.
Anwender mit entsprechender Berechtigung können TAGs direkt im Editiermodus des Tickets hinzufügen oder später in der Ticketansicht. Einfach indem man über den TAG-Bereich mit der Maus schwebt und den TAG auf diese Weise hinterlegt.
Für die Wiki ist die gleiche Vorgehensweise wie bei Tickets möglich. Entweder wird ein TAG oder mehrere über den Editiermodus einer Wikiseiten hinzugefügt. Oder indem man über den TAG-Bereich am Ende einer Wikiseite schwebt und einen TAG hinterlegt.
Egal ob Du TAGs für die Wiki verwendest um die Inhalte besser zu strukturieren. Oder mit Hilfe von Tags Deine Tickets besser zu organisieren. Sie sind komplett anpassbar und lassen sich nach Bedarf verwenden. Verwende Sie so, damit Sie für Dich und Dein Unternehmen am Besten funktionieren.
In der Ticketliste kann man nach TAGs anzeigen und filtern. Genauso in der Wiki. Dort kann man Inhalte nach TAGs anzeigen und schneller ausfindig machen.
Für Anwender mit Administratorrechten wird die Konfiguration zum additional_tags Plugin im Adminbereich durchgeführt.
Die Konfiguration ist recht simpel gehalten. Neben allgemeinen Einstellungen zur Darstellung von TAGs (z.B. im Seitenbereich von Redmine) kann man festlegen, ob man die Funktion überhaupt nutzen will für den Bereich:
Kostenlose TAG Plugins für Redmine gibt es bereits ein paar, jedoch werden sie:
Da es sich bei der TAG-Funktion um eine simple, aber essenzielle Funktionalität handelt (die seit Jahren in anderen Ticketsystemen zum Einsatz kommt) ist eine stabile Erweiterung für die aktuelle Redmine Version unabdingbar. Und zwar jetzt und nicht irgendwann in der Zukunft.
Das additional_tags Plugin ist ein fast kompletter Re-Write von bereits bestehenden TAG-Plugins und stellt eine stabile Funktion zur Implementation von TAGs in Redmine Tickets als auch in Redmine Wikiseiten bereit.
Das Plugin dient zusätzlich als Framework für andere Redmine Plugins, welche auf die TAG-Funktion aufbauen können, anstatt was eigenes zu entwickeln. Dazu gehören aktuell:
Wer eines oder mehrere dieser Plugins nutzt, kann seine TAGs zentral in der Pluginkonfiguration verwalten: bearbeiten, zusammenführen, löschen
Will man seine TAGs verwalten ist es nützlich einen Überblick zu haben, wo der besagte TAG überall verwendet wird. Dafür ist der zentrale TAG-Bereich gut geeignet. Denn er verlinkt (wo möglich) auf die Inhalte, welche den entsprechenden TAG verwenden.
Das additional_tags Plugin ist eine kostenlose Funktionserweiterung für die aktuelle Redmine Version 4.1x. In unserer Online Demo kann es getestet werden.
Mit Hilfe der Ticketinformationen erledigt man die beruflichen Aufgaben, die man im Zuge seiner Tätigkeitsbereiche zu erfüllen hat.
Für die Abarbeitung seiner Ticketliste sollte man sich von Anfang an ein passendes System überlegen, damit man möglichst effizient arbeitet und am Ende des Tages zufrieden nach Hause geht. Wenn Du keine konkreten Vorgaben erhalten hast, welche Tickets wie zu handhaben sind, ist vielleicht eine der folgenden drei Möglichkeiten zur Abarbeitung von Tickets in Redmine interessant für Dich.
Sind die Tickets in Deinem Redmine mit einem Fälligkeitsdatum versehen, oder gibt es Richtlinien (z.B. SLA-Bedingungen), dass Tickets innerhalb eines festgelegten Zeitrahmens abzuarbeiten sind, dann ist diese Option die passende Lösung für Dich.
Nämlich Tickets nach Fälligkeitsdatum sortieren und entsprechend vor Ablauf des festgelegten Fälligkeitsdatum abarbeiten.
Mit dem Reporting Plugin steht auch SLA-Funktionalität für bestimmte Tickets bereit. Dadurch lässt sich die Reaktions- und Lösungszeit festlegen um Tickets innerhalb eines definierten Zeitintervalls zu lösen. Mehr über den Einsatz von SLA in Redmine in folgendem Blogbeitrag: SLA Management mit Redmine Reporting.
Nicht nur in agilen Teams werden manche Tickets priorisiert und sollten entsprechend abgearbeitet werden. Auch in herkömmlichen Projektteams ist es häufig der Fall, dass bestimmte Aufgaben mit der Priorität Hoch, Dringend oder sogar Sofort versehen werden. Dann sollten solche Aufgaben bevorzugt angegangen werden. In diesem Fall sortiert man seine Tickets nach Priorität.
Wir empfehlen die Ticketlisten nach Priorität zu filtern und als benutzerdefinierte Abfrage abzuspeichern. Dann kann man mit Hilfe des Reporting Plugins Zählerboxen auf der Redmine Startseite und / oder Projektübersicht platzieren und hat immer einen Blick auf die wichtigen Aufgaben, die es priorisiert zu erledigen gilt. Mehr dazu in folgendem Blogbeitrag: GTD Produktivitätstipps.
Vor allem Support-Agents haben häufig mit Kundenanfragen zu tun, die in Form eines Tickets eintrudeln. Hier kommt es auf den Inhalt der Anfrage an. Bei verärgerten Kunden lassen sich die Wogen glätten, wenn man entsprechend schnell auf ihre Anfrage reagiert.
Hier ist es sinnvoll Tickets mit TAGs (Schlagworten) zum Problem zu versehen und diese Aufgaben entsprechend abzuarbeiten. Solche TAGs helfen übrigens auch im Nachhinein. Wenn man selbst (oder andere Mitarbeiter) ähnliche Tickets zu bearbeiten hat und sich orientieren will, wie der Kollege mit ähnlichen Anfragen umgegangen ist.
TAGs zu Tickets lassen sich mit dem Reporting Plugin zuweisen. Dieses liefert zusätzliche Möglichkeiten die Ticketliste nach TAGs zu filtern. Wer Zugriff auf die TAGs hat, kann man mit Hilfe der Rollenrechte im Administrationsbereich festlegen. Mehr zum Einsatz von TAGs in Redmine in folgendem Blogbeitrag.
Wir hoffen der Artikel war nützlich. Auf jeden Fall weißt Du jetzt, dass es verschiedene Möglichkeiten gibt seine Ticketliste abzuarbeiten. Standardmäßig ist sowohl die Sortierung von Tickets nach Priorität und Fertigstellungsdatum mit Redmine möglich. Wenn Du zusätzlich unser Reporting Plugin nutzt, hilft Dir dieses dabei Tickets mit TAGs zu versehen und noch weitere Filteroptionen zur Abarbeitung zu nutzen.
Alle Informationen zu unseren Erweiterungen für Redmine gibt es auf der Produktseite. Kunden, deren Redmine den Mindestanforderungen nicht entspricht oder die lieber jemanden für die Installation und regelmäßige Pflege ihrer Redmine-Instanz beauftragen wollen, haben alternativ die Möglichkeit unser Managed Applikation Hosting für Redmine zu buchen. Hier ist das Plugin bereits Teil unseres Hosting Angebots.
Das DevOps-Plugin integriert relevante GitLab-Daten direkt in Dein Redmine. Auf diese Weise hat jeder innerhalb des Redmine-Teams rollenabhängig Zugriff auf externe GitLab-Informationen. Und zwar ohne Redmine verlassen zu müssen. Dadurch bleibt das ganze Team immer auf dem aktuellen Stand. Folgende GitLab Information lassen sich beispielsweise als Dashboard-Blöck einbinden: GitLab Merge Requests, GitLab Pipelines, GitLab Projekte, GitLab Tickets.
Dashboard-Block Beispiel für Redmine: GitLab Pipelines
Das DevOps-Plugin fungiert als Informationshub innerhalb Deiner Redmine Anwendung. Die eigentliche Aktivität findet also weiterhin in dem extern angebundenen GitLab statt. Es ist möglich externe Commit-Nachrichten mit Redmine-Tickets zu verknüpfen, sowie Repository-Aktualisierungen zuzulassen. In diesem Fall ist es zusätzlich notwendig innerhalb Deiner GitLab Instanz die Redmine-Integration zu aktivieren.
Dabei spielt es keine Rolle, ob der jeweilige Anwender Projektleiter / Teamleiter ist. Oder mit der Entwicklung, dem Testen, der Administration, der Dokumentation oder dem Marketing des entwickelten Produkts betraut ist. Ein Blick auf die Redmine-Projektübersichtsseite verschafft jedem zugriffsberechtigten Anwender Einblicke in das extern angebundenen GitLab. Ohne Redmine dafür verlassen zu müssen.
Ein Benutzer mit Administratorrechten konfiguriert die Anbindung an GitLab (GitLab Personal Access Token für API-Zugriff erforderlich) einmalig in Redmine.
Im Abschnitt Rollen und Berechtigung legt der Benutzer fest, welche Benutzerrolle in einem Projekt Zugriff auf die GitLab-Informationen hat. Die folgenden Berechtigungen müssen eingestellt werden:
Im letzten Schritt wird das Plugin in den Projekteinstellungen aktiviert und die nun verfügbaren Dashboard-Blöcke für die Projektübersichtsseite entsprechend zugewiesen. So definierst Du, welche Informationen aus GitLab in Deinem Redmine-Projekt angezeigt werden. Dazu wird der Dashboard-Block ebenfalls einmalig von einem Benutzer mit entsprechenden Rechten konfiguriert.
Das war’s schon. Von nun an sind die externen GitLab-Informationen des konfigurierten Kontos für die autorisierten Benutzer aus Deinem Team verfügbar.
Füge einfach relevante Informationen als Dashboard-Block zu Deiner Projektübersichtsseite hinzu
Der größte Vorteil der Dashboard-Unterstützung besteht darin, dass zusätzlich zu einem öffentlich zugänglichen Dashboard jeder Mitarbeiter mit Dashboard-Berechtigung problemlos sein eigenes privates Dashboard mit seinen persönlichen GitLab-Kontoinformationen erstellen kann.
Mit der Plugin Version 3.1.0 werden die in Redmine hinterlegten Commit Keywords in der Commit-Message berücksichtigt, um den Ticketstatus zu ändern. Nützlich für Anwender, die den Ticketstatus nicht manuell, sondern mittels ihres Commits anpassen wollen. Hierzu muss in der Plugin-Einstellung die entsprechende Option aktiviert und in den Redmine Settings die zu verwendenden Schlüsselwörter hinterlegt werden.
Aktiviere die entsprechende Option um Schlüsselwörter in der Commit-Message zum Auslösen eines Ticketstatus zu verwenden.
Auch Zeitbuchungen zu einem referenzierten Ticket sind mittels Commit Message möglich. Wenn dies in den Redmine Settings ebenfalls entsprechend aktiviert ist und die hierfür notwendige Commit Message laut einem der genannten Beispiele auf Redmine.org integriert wurde.
Das kommerzielle DevOps-Plugin eignet sich für Organisationen mit funktionsübergreifenden IT- und Business-Teams, die Redmine als Projektmanagement-Tool verwenden und gleichzeitig mindestens eines der unterstützten DevOps-Tools (z.B. GitLab) einsetzen.
Mit dem DevOps Plugin ist es möglich die Verantwortung zu teilen und sein Team so zu kultivieren, dass diese neue Erfahrungen sammeln können und so auch mit Unternehmensbereichen vertraut werden, in denen sie normalerweise wenig Einblick haben. Das fördert zum einen die Zusammenarbeit und auch das Verständnis für andere Teamaufgaben.
Erfahre mehr auf unserer Plugin-Produktseite. Und teste die Funktionalität auf unserer öffentlich zugänglichen Online-Demo in einem eigenen Projekt.
Informationen über unsere Redmine Leistungen findest Du auch auf unserer Themenseite. Wenn Redmine für Dich und Dein Team interessant ist kannst Du Dich gerne für ein konkretes Angebot an uns wenden. Unsere Hosting-Angebote setzen eine regelmäßige, monatliche Betreuung durch uns voraus.
GitLab ist ein Open-Source-Tool für die Zusammenarbeit von Entwicklern mit einem umfangreichen Funktionsumfang, darunter die Verwaltung von Repositories, Review-Werkzeuge, Bugticketverfolgung, Aktivitätsfeeds und vieles mehr.