Möglichkeiten in der kostenpflichtigen Version

Allgemein Fragen, deutsche News, Ankündigungen & Events zum OTRS
Post Reply
ncmbu
Znuny advanced
Posts: 111
Joined: 23 Jun 2016, 17:11
Znuny Version: 5.0.23

Möglichkeiten in der kostenpflichtigen Version

Post by ncmbu »

Hallo,

wir versuchen noch immer unser OTRS umzugestalten, werden aber immer mal wieder aus diversen Gründen zurückgeworfen. Aktuell hängt es an Anforderungen aus der Chefetage, die mit der Open Source Variante offenbar nicht zu realisieren sind. Daher nun die Frage, ob die kostenpflichtige OTRS-Variante mit den Anforderungen klar kommt.
Hier in paar Dinge, die aktuell Probleme machen:
  • Aufteilung der Kunde in Privatkunden und Geschäftskunden.
    Sowohl zur Auswertung, als auch im operativen Geschäft sollen Privatkunden und Geschäftskunden unterscheidbar sein. Aktuell ist z.B. eine Haupt-Anforderung, dass Geschäftskunden eine andere Signatur bekommen. Dies wird zur Zeit über separate Queues realisiert. Dadurch könnten für die beiden Gruppen auch unterschiedliche Eskalationszeiten definiert werden. Allerdings sind zu viele Queues nicht gut für die Übersichtlichkeit.
    Kurz: Kann man Kunden in der Business-Variante in verschiedene Kategorien einteilen und diesen Kategorien Signaturen / Eskalationszeiten zuweisen, ohne separate Queues zu benötigen? (Außerdem soll das ganze auch bei der Auswertung verwertbar sein)
  • Separierung in 1st-/ 2nd-/ 3rd-Level
    Aus ähnlichen Gründen, primär jedoch zur Auswertung, soll jedes Ticket zusätzlich danach Kategorisiert werden, ob es im 1st-, 2nd- oder 3rd-Level bearbeitet wird. Auch dies ließe sich zwar grundsätzlich über Queues regeln, aber da wir auch hier jede einzelne Queue in dreifacher Ausfertigung anlegen müssten (bzw. mit dem vorigen Punkt in 6-facher) und auch damit wieder die Übersichtlichkeit dahin ist, wäre auch hier die Frage ob es möglich ist ein dynamisches Feld o.ä. für die Kategorisierung von Tickets zu verwenden.
  • Lassen sich die Antwort-Vorlagen abhängig vom gewählten Service eines Tickets einblenden?
reneeb
Znuny guru
Posts: 5018
Joined: 13 Mar 2011, 09:54
Znuny Version: 6.0.x
Real Name: Renée Bäcker
Company: Perl-Services.de
Contact:

Re: Möglichkeiten in der kostenpflichtigen Version

Post by reneeb »

Punkt 2 kannst Du doch auch in der Free-Variante mit einem Dynamischen Feld erledigen...

Zu Punkt 1: Du kannst ja ein eigenes Attribut für die Kunden anlegen. Weiterhin kannst Du Services nutzen und bei den Services unterschiedliche SLAs für Privat- und Geschäftskunden erstellen. Mit ACLs kannst Du dann je nach Wert des Kundenattributs die SLA-Auswahl einschränken.
Perl / Znuny development: http://perl-services.de
Free Znuny add ons from the community: http://opar.perl-services.de
Commercial add ons: http://feature-addons.de
wurzel
Znuny guru
Posts: 3224
Joined: 08 Jul 2010, 22:25
Znuny Version: x.x.x
Real Name: Florian

Re: Möglichkeiten in der kostenpflichtigen Version

Post by wurzel »

Hi,
ncmbu wrote: Aktuell hängt es an Anforderungen aus der Chefetage, die mit der Open Source Variante offenbar nicht zu realisieren sind. Daher nun die Frage, ob die kostenpflichtige OTRS-Variante mit den Anforderungen klar kommt.
Es gibt mehere "kostenpflichtige" Varianten. Sollten aber alle Open Source sein.

Es gibt hier im Forum eine Liste der Dienstleister (finde ich gerade nicht). Ich nutze die, des Herstellers, deshalb kann ich nur zu der was sagen.
ncmbu wrote:
  • Aufteilung der Kunde in Privatkunden und Geschäftskunden.
Kundeninformationen kannst Du auch in der Free auswerten.
Kurz: Kann man Kunden in der Business-Variante in verschiedene Kategorien einteilen und diesen Kategorien Signaturen / Eskalationszeiten zuweisen, ohne separate Queues zu benötigen? (Außerdem soll das ganze auch bei der Auswertung verwertbar sein)
Das sollte auch in der Free gehen. Sei es mit dynmischen Feldern oder mit spezifischen Prozesstickets.
[*]Separierung in 1st-/ 2nd-/ 3rd-Level
Eine Kategorisierung ist auch in der Free möglich.

[*]Lassen sich die Antwort-Vorlagen abhängig vom gewählten Service eines Tickets einblenden?[/list]

Das geht meines Wissens nur mit der OTRS Business Solution des Herstellers - zumindest kenne ich die anderen verfügbaren Module nicht.

viele Grüße
Florian
OTRS 8 SILVER (Prod)
OTRS 8 auf Debian 11 (Test)
Znuny 7.x latest version testing auf Debian 11

-- Ich beantworte keine Forums-Fragen PN - No PN please

I won't answer to unfriendly users any more. A greeting and regards are just polite.
ncmbu
Znuny advanced
Posts: 111
Joined: 23 Jun 2016, 17:11
Znuny Version: 5.0.23

Re: Möglichkeiten in der kostenpflichtigen Version

Post by ncmbu »

reneeb wrote:Punkt 2 kannst Du doch auch in der Free-Variante mit einem Dynamischen Feld erledigen...
Klar kann ich ein dynamisches Feld anlegen und dann da "1st Level" oder "3rd Level" reinschreiben. Aber das ist ja von der Funktion her nicht vergleichbar mit unterschiedlichen Queues. Eine Queue "3rd Level" könnte man z.B. einer bestimmten Gruppe an Bearbeitern zuweisen; diese könnten die Queue dann abonnieren um Benachrichtigungen über neue Tickets o.ä. zu erhalten. Ich wüsste nicht, wie ich Tickets, die einen festgelegten Wert in einem dynamischen Feld haben, abonnieren sollte.
Zu Punkt 1: Du kannst ja ein eigenes Attribut für die Kunden anlegen. Weiterhin kannst Du Services nutzen und bei den Services unterschiedliche SLAs für Privat- und Geschäftskunden erstellen. Mit ACLs kannst Du dann je nach Wert des Kundenattributs die SLA-Auswahl einschränken.
Die Services wollen wir nach der Umstrukturierung für unsere Produkte nutzen, insofern kommen diese für die Privat-/Business-Kunden-Unterscheidung eigentlich nicht in Frage. Zudem besteht ja auch eine der Haupt-Anforderungen in "Unterschiedliche Signatur für Business-/Privatkunden" und Signaturen lassen sich meines Wissens (in der Free Variante) nicht über Services beeinflussen.

Wenn ich die Geschäftsführung richtig verstanden habe, dann soll es letzenendes darauf hinaus laufen, dass jedes einzelne Ticket in der Auswertung unterschieden werden kann nach Produkt (ca. 14 Stück, wollen wir über Services definieren), Privat-/Business-Kunde und 1st/2nd/3rd-Level, also letztlich 14×2×3 Möglichkeiten.
wurzel wrote:
Kurz: Kann man Kunden in der Business-Variante in verschiedene Kategorien einteilen und diesen Kategorien Signaturen / Eskalationszeiten zuweisen, ohne separate Queues zu benötigen? (Außerdem soll das ganze auch bei der Auswertung verwertbar sein)
Das sollte auch in der Free gehen. Sei es mit dynmischen Feldern oder mit spezifischen Prozesstickets.
Das klingt interessant. Kannst du mir da weitere Informationen zu geben? Also ich denke ich bekomme es hin den Kundeninformationen die Unterscheidungskriterien hinzuzufügen und diese im Ticket in ein dynamisches Feld zu übernehmen. Ich weiß allerdings nicht, wo ich dann ansetzen soll, um Signatur oder Eskalationszeit nach dem dynamischen Feld festzulegen.
wurzel
Znuny guru
Posts: 3224
Joined: 08 Jul 2010, 22:25
Znuny Version: x.x.x
Real Name: Florian

Re: Möglichkeiten in der kostenpflichtigen Version

Post by wurzel »

Hi,
ncmbu wrote:
reneeb wrote:Punkt 2 kannst Du doch auch in der Free-Variante mit einem Dynamischen Feld erledigen...
Klar kann ich ein dynamisches Feld anlegen und dann da "1st Level" oder "3rd Level" reinschreiben. Aber das ist ja von der Funktion her nicht vergleichbar mit unterschiedlichen Queues. Eine Queue "3rd Level" könnte man z.B. einer bestimmten Gruppe an Bearbeitern zuweisen; diese könnten die Queue dann abonnieren um Benachrichtigungen über neue Tickets o.ä. zu erhalten. Ich wüsste nicht, wie ich Tickets, die einen festgelegten Wert in einem dynamischen Feld haben, abonnieren sollte.
Das "Problem" ist, dass Du entweder Queues oder Services abonieren kannst. Wenn Du jetzt über dynamische
Felder Deine Ansichten definierst, wirst Du umbauen müssen
- eigene Suchvorlagen (Ansicht nach Queues oder Services bringt Dir nichts mehr)
- eigene Dashbaord Widgets
- eigene Ticket Notifications
- ...

Das ist machbar, bedarf aber einer sehr guten und genauen Konfiguration. Ich für meinen Teil versuche, das
zu vermeiden.

Zu Punkt 1: Du kannst ja ein eigenes Attribut für die Kunden anlegen. Weiterhin kannst Du Services nutzen und bei den Services unterschiedliche SLAs für Privat- und Geschäftskunden erstellen. Mit ACLs kannst Du dann je nach Wert des Kundenattributs die SLA-Auswahl einschränken.
Die Services wollen wir nach der Umstrukturierung für unsere Produkte nutzen, insofern kommen diese für die Privat-/Business-Kunden-Unterscheidung eigentlich nicht in Frage. Zudem besteht ja auch eine der Haupt-Anforderungen in "Unterschiedliche Signatur für Business-/Privatkunden" und Signaturen lassen sich meines Wissens (in der Free Variante) nicht über Services beeinflussen.
Die Signaturen sind im OTRS erstmal immer Queue gebunden. Wenn Du also verschiedene Signaturen brauchst,
musst Du erstmal verschiedene Queues dafür bauen.

Es gibt die Alternative, dass Du Dir die Signaturen zusammenbaust aus Dynamischen Feldern. Dann kannst
Du halt die Standard Funktionen Queues <-> Signaturen nicht nutzen sondern musst in jedes Template
halt Deine Werte von dynamischen Feldern drinstehen haben, als Variable.

Die Variable befüllt sich auf Grund der Kunden Infos. Du kannst Werte aus der CustomerUser Mapping Table
in dynamische Felder schreiben.


Auch hier - genauso wie oben - ist es erheblicher Aufwand, muss genau konfiguriert werden.
Die Alternative = Kundenbezogene Queues sind aber am Ende auch übles Queue Design.
Wenn ich die Geschäftsführung richtig verstanden habe, dann soll es letzenendes darauf hinaus laufen, dass jedes einzelne Ticket in der Auswertung unterschieden werden kann nach Produkt (ca. 14 Stück, wollen wir über Services definieren), Privat-/Business-Kunde und 1st/2nd/3rd-Level, also letztlich 14×2×3 Möglichkeiten.
Kannst Du über Queues, Services, Dynamische Felder konfigurieren. Für Auswertungen garnicht mal so schwer.
Ich denke, Dein Problem ist "nur" die Signatur.

Achso... in dem Fall ist es auch egal ob Free oder Business.
Die Business Solution hat die gleichen grundsätzlichen Ansätze.
wurzel wrote:
Kurz: Kann man Kunden in der Business-Variante in verschiedene Kategorien einteilen und diesen Kategorien Signaturen / Eskalationszeiten zuweisen, ohne separate Queues zu benötigen? (Außerdem soll das ganze auch bei der Auswertung verwertbar sein)
Das sollte auch in der Free gehen. Sei es mit dynmischen Feldern oder mit spezifischen Prozesstickets.
Das klingt interessant. Kannst du mir da weitere Informationen zu geben? Also ich denke ich bekomme es hin den Kundeninformationen die Unterscheidungskriterien hinzuzufügen und diese im Ticket in ein dynamisches Feld zu übernehmen. Ich weiß allerdings nicht, wo ich dann ansetzen soll, um Signatur oder Eskalationszeit nach dem dynamischen Feld festzulegen.
Das ist eine Kombi aus CustomerUser Data mapping Informationen in dynamische Felder schreiben,
Generic Agents, ggf. Ticket Notifications. Wie oben beschrieben, sehr aufwändig. Vieles muss der
Generic Agent übernehmen.


Wenn ihr den Weg gehen wollt, OK. Ich würde mir überlegen, ob ich nicht doch eine Signatur verwende für alle
Kunden. Das würde viel Arbeit ersparen. SLAs, Services, sind sowieso Kundenbenutzer-bezogen, das sollte klappen.


Eine (unschöne) Alternative ist, zwei Instanzen aufzubauen.
Eine für privatkunden, eine für Geschäftskunden.
Vorteil -> Saubere Trennung, einfache Konfig
Nachteil -> zwei Instanzen

:(

viele Grüße
Flo
OTRS 8 SILVER (Prod)
OTRS 8 auf Debian 11 (Test)
Znuny 7.x latest version testing auf Debian 11

-- Ich beantworte keine Forums-Fragen PN - No PN please

I won't answer to unfriendly users any more. A greeting and regards are just polite.
ncmbu
Znuny advanced
Posts: 111
Joined: 23 Jun 2016, 17:11
Znuny Version: 5.0.23

Re: Möglichkeiten in der kostenpflichtigen Version

Post by ncmbu »

Hi,
ich möchte den Thread nochmal aufgreifen.

Und zwar geht es um die Signatur-Frage, konkret um folgenden Part:
wurzel wrote:Es gibt die Alternative, dass Du Dir die Signaturen zusammenbaust aus Dynamischen Feldern. Dann kannst
Du halt die Standard Funktionen Queues <-> Signaturen nicht nutzen sondern musst in jedes Template
halt Deine Werte von dynamischen Feldern drinstehen haben, als Variable.
Unser Gedanke ging jetzt tatsächlich in die Richtung Teile der Signatur aus den dynamischen Feldern zusammen zu bauen, da die Informationen zu den Kunden ja entsprechend vorliegen.
Ich bin hier beim Testen jedoch auf ein Problem gestoßen: Offenbar wertet OTRS die entsprechenden Felder gar nicht richtig aus. Ich habe das ganze mal mit einem einfachen <OTRS_CUSTOMER_DATA_UserLastname> ausprobiert. Meine Beobachtung war: Für Folgetickets funktioniert dies zwar, wird jedoch ein neues Ticket erstellt, klappt die Ersetzung nicht.
Meine Vermutung wäre, dass das System hier die entsprechenden Daten erst zuweist, nachdem das Ticket tatsächlich erstellt wurde und die Daten daher bei einem Ticket, welches gerade erstellt wird (bisher also noch nicht existiert) nicht verfügbar hat.
Ist meine Annahme hier korrekt?
Post Reply