Suche: Beschreibung der Nutzungmöglichkeiten von OTRS

[vboehm]

Hallo,
ich setze jetzt seit gut einer Woche OTRS ein und mit den Trivial-Fällen (Kunde hat Problem --> Nachdem ich es gelöst habe, schließe ich das Ticket und der Kunde erfährt es) komme ich wohl auch klar.

Jetzt stehe ich aber z.B. vor dem Problem, dass ich eine Rückfrage an den Kunden habe und solange nicht an dem Ticket weiterarbeiten kann, bis der die Frage beantwortet hat. Das kann ich natürlich außerhalb von OTRS mit normaler eMail abkaspern aber das ist wohl kaum der Sinn eines solchen Systems. D.h. mir fehlt ein neuer Status 'warten auf Kunden-Antwort' (den kann ich mir ja gerade noch basteln) und vor allem ein Dialog den ich auswählen kann (wie Zurück, Freigeben, Historie, Drucken, ...) um eine Notiz mit einer Statusänderung zu verfassen, die aber - im Gegensatz zu dem Warten-Dialog - keine interne Notiz ist, sondern an den Kunden als Mail geschickt wird, damit der jetzt in die Hufe kommt.
Ich habe zu diesem Problem schon ein wenig gegoogelt und dabei nur ähnliche Fragen ohne praktikable Lösungen gefunden. Wobei die Antworten aber zeigten, dass auch die Antwortenden vollkommen andere - oder auch gar keine - Vorstellungen hatten, wie so eine Aufgabe überhaupt anzugehen sei.

Deshalb - neben der Lösung zu dem o.a. Problem - meine Frage: Wo finde ich eine (oder mehrere) Beschreibungen, wie sich die Macher von OTRS mögliche Abläufe überhaupt vorstellen? Bzw. wie ich meine Abläufe auf die Möglichkeiten von OTRS abbilden kann?

Das OTRS-Admin-Manual kenne ich und da steht auch einiges drin (Einrichtung, bestimmte Spezialfälle, vage Hinweise auf Möglichkeiten) aber eigentlich (bis auf zwei Trivial-Beispiele) nichts aus den täglichen leben.

mfg Volker

[jojo]

Du schreibst dem Kunden einfach eine Antwort und setzt den Status dabei. (Compose Answer)

Da die Abläufe und Installationen bei jeder Installation unterschiedlich sind gibt es kein generisches Handbuch, ich empfehle hier Konzeptionierung und Trainings durch die xxx

[vboehm]

Du schreibst dem Kunden einfach eine Antwort und setzt den Status dabei. (Compose Answer)

Hallo jojo,
danke für die Antwort. Und genau da beginnt das Problem: Ich habe in meinem OTRS nirgendwo einen Menüpunkt oder Link der 'Compose Answer' heißt. Ich nehme mal an, dass du damit den Link 'Antwort erstellen (E-Mail):' auf der rechtes Seite der Ticket-Detail-Ansicht meintest.
Dort (alles Andere im rechten Abschnitt sind nur Infos) hätte ich niemals eine für die Ticket-Verarbeitung wichtige Aktion vermutet; die sind sonst alle oberhalb der Ticket-Details in der gleichen Ansicht. Und warum kann ich bei einer eMail zwar den Status ändern, jedoch nicht bei einer Notiz? Alles Fragen, die eine Übersicht über die Strategien und Abläufe eines solchen Systems zeigen müsste.

Leider ist so etwas wie ein Ticketsystem nicht so trivial, das ein selbsterklärendes Programm möglich wäre. Es müssten zumindest irgendwo die gewählten Annahmen und das grobe Zustands-Modell eines Tickets beschreiben sein, da es zig Möglichkeiten gibt, so etwas zu implementieren.
Deshalb wäre ein Dokument mit der Einführung in die (groben) Strategien dieses Systems wichtig, damit man wenigstens die ersten 300 Nutzungs-Minuten übersteht, ohne das Forum fragen zu müssen. Das es zu weit führen würde, dort diverse Spezialfälle auszubreiten, ist natürlich klar.
Ich habe kurz noch mal durch einige Dialoge geblättert und habe des Eindruck , dass mir innerhalb weniger Stunden locker 50 Fragen dazu einfallen würden, die leider nicht selbsterklärend beantwortet werden (Warum sind fast alle Notiz-Arten (Prioritätsänderung, Besitzeränderung, Warten-Notiz, ...) nur als 'Notiz für intern' zu haben? Kann man das ändern? Und, wenn ja, wie? Was hat eine Teilung/Zusammenlegung für Folgen? ...).

..., ich empfehle hier Konzeptionierung und Trainings durch die xxx

Und für solche Trivialitäten gleich eine Mehr-Tausend-Euro-Schulung zu buchen ist wohl etwas mit Kanonen auf Spatzen.
Deshalb vermisse ich ein User-Manual oder etwas ähnliches, das mir erklärt, wie die normalen Abläufe (das sind vielleicht 20 - 30 Abläufe mit 1 - 5 Schritten) dieses Systems ablaufen. Eine vollständige Beschreibung aller Menüs und Dialoge mit einer Beschreibung der Folgen bestimmter Feld-Inhalte/-Auswahlen (z.B. wenn Sie 'Sender informieren' anklicken, bekommt ???? die Notiz als Mail ...) würde natürlich auch schon deutlich weiter helfen.

mfg Volker

PS: Ich möchte hier nicht OTRS schlecht machen oder behaupten, die gesamte existierende Dokumentation sei Mist. Nur gerade als Einsteiger fallen einem Sachen auf, die man hinterher nicht mehr erkennt. Und warum soll das Forum - oder selbst bezahlte Supporter - dauernd mit blödsinnigen Trivial-Fragen belästigt werden, die genauso einem User-Manual erklärt werden könnten.

[jojo]

Hallo jojo,
danke für die Antwort. Und genau da beginnt das Problem: Ich habe in meinem OTRS nirgendwo einen Menüpunkt oder Link der 'Compose Answer' heißt. Ich nehme mal an, dass du damit den Link 'Antwort erstellen (E-Mail):' auf der rechtes Seite der Ticket-Detail-Ansicht meintest

Richtig, der heisst nämlich "Compose Answer" ohne die deutsche Übersetzung (ich kann mir ja nicht alle Sprachen merken).

Dort (alles Andere im rechten Abschnitt sind nur Infos) hätte ich niemals eine für die Ticket-Verarbeitung wichtige Aktion vermutet; die sind sonst alle oberhalb der Ticket-Details in der gleichen Ansicht. Und warum kann ich bei einer eMail zwar den Status ändern, jedoch nicht bei einer Notiz? Alles Fragen, die eine Übersicht über die Strategien und Abläufe eines solchen Systems zeigen müsste.

An dieser Stelle befinden sich diese Aktionen nun schon seit der ersten Version von OTRS. Zur 3.0 werden sie aber am Artikel oben, bzw. Ticketaktionen am Ticket oben angezeigt. Du kannst das Verhalten fast aller Masken über die SysConfig beeinflussen, wenn also Dein Prozess es vorsieht über Notizen den Status zu ändern, dann konfiguriere die Notizmaske dementsprechend.

Leider ist so etwas wie ein Ticketsystem nicht so trivial, das ein selbsterklärendes Programm möglich wäre. Es müssten zumindest irgendwo die gewählten Annahmen und das grobe Zustands-Modell eines Tickets beschreiben sein, da es zig Möglichkeiten gibt, so etwas zu implementieren.

Es gibt ein Haufen Wege ein Ticket zu berarbeiten, der Auslieferungszustand ist nur einer davon und bedarf auch einiger zusätzlicher Einstellungen um besser zu funktionieren. Alles andere ist Konfiguration.

..., ich empfehle hier Konzeptionierung und Trainings durch die xxx

Und für solche Trivialitäten gleich eine Mehr-Tausend-Euro-Schulung zu buchen ist wohl etwas mit Kanonen auf Spatzen.
Deshalb vermisse ich ein User-Manual oder etwas ähnliches, das mir erklärt, wie die normalen Abläufe (das sind vielleicht 20 - 30 Abläufe mit 1 - 5 Schritten) dieses Systems ablaufen.

Ein Ticketsystem hat häufig eine Komplexität, die sich nicht mehr alleine durch Doku beschreiben lässt, Dienstleistungen um eine Einführung zu begleiten und Schulungen durchzuführen sind daher ein typischer Weg. Du würdest ja sicherlich auch keines der großen kommerziellen Ticketsystem von z.B. BMC ohne Beratung einführen? Das Changemanagement Modul z.B. ist so komplex das es auf alle Fälle einer Schulung bedarf (und das nicht nur Aufgrund des Tools, sondern hauptsächlich aufgrund der prozessualen Komplexität). Open Source bedeutet weder kostenlos noch "kann ich alles selber machen"....

Eine vollständige Beschreibung aller Menüs und Dialoge mit einer Beschreibung der Folgen bestimmter Feld-Inhalte/-Auswahlen (z.B. wenn Sie 'Sender informieren' anklicken, bekommt ???? die Notiz als Mail ...) würde natürlich auch schon deutlich weiter helfen.

Eine generische Userdoku ist nicht trivial, da jedes OTRS anders konfiguriert ist oder anders genutzt wird. Viele Masken sind daher häufig anders konfiguriert als im Auslieferungszustand, z.B. um freie Felder zu nutzen.
OTRS ist Open Source, genauso die Doku. Es hindert Dich also niemand daran eine solche User Doku zu schreiben und mit Sicherheit finden sich auch genug Leute die daran mitwirken würden (z.B. im Rahmen eines wikibasierten Dokumentationsprojektes). Also nicht immer "meckern" sondern vielleicht einfach mal machen!