Hallo Zusammen
Uns wurde bereits toll von der Community hier geholfen Entsprechend sind sind wir fleissig am System testen. Dabei drängen sich bei uns zwei weitere Fragen auf:
Queue vs. Dynamic Fields
Hintergrund: Handelsfirma mit 20+ Werksvertretungen. Entsprechend häufen sich die Anfragen aller Art.
Augenscheinlicher Ansatz 1 wäre:
Bestellungen::HerstellerA
Bestellungen::HerstellerB
Bestellungen::HerstellerC
Support::HerstellerA
Support::HerstellerB
Support::HerstellerB::Basic
Support::HerstellerB::Premium
Support::HerstellerC
Support::HerstellerN
USW.
Wie man sehen kann, können die Queues verschieden tief und unterschiedlich Strukturiert sein. Eins bleibt: Für jeden Typ + Hersteller gibt es eine andere Queue. Die Überlegung hierbei ist: Einfaches Reporting, Berechtigungen (Groups = Queue), "Queue Verantwortliche" per Generic Agents, Signature usw.
Nachteil: Extrem viele Queues...
Ansatz 2
Beim testen ist uns jetzt aber aufgefallen, dass wir die gewünschte Segmentierung nach Hersteller auch mittels dynamischen Felder realisieren könnten. Mit entsprechend weniger initial Aufwand...
Welches Design ist sinnvoller?
Was hat sich in der Praxis bewährt?
Performance bei 200k+ Customers und 5 Agents
Die hohe Anzahl Customers erklärt sich durch den Import aus dem CRM. Jedoch ist das Webportal deaktiviert und die Installation hinter einer Firewall. Entsprechend gibt es "nur" 5 Agenten, welche das System regelmässig benützen.
Muss man hier bei der Skalierung des Servers etwas besonderes beachten? Wir gehen davon aus, da der Zugriff nur durch Agenten erfolgt, die Perfomance relative nebensächlich ist...
Beste Grüsse
wucherpfennig
System Design: Queue vs. Dynamic Fields und Performance (200k+ Customers)
-
- Znuny newbie
- Posts: 23
- Joined: 11 Apr 2017, 14:15
- Znuny Version: 5.0.18
-
- Znuny guru
- Posts: 2210
- Joined: 13 Mar 2014, 09:16
- Znuny Version: 6.0.14
- Real Name: Rolf Straub
Re: System Design: Queue vs. Dynamic Fields und Performance (200k+ Customers)
Du kannst neben dynamischen Feldern auch Services nutzen zum differenzieren.
Was sich bei unseren OTRS Einsätzen bewährt hat, ist NICHT eine Queue pro Kunde aufzusetzen. Diese sollten lieber generisch gehalten werden, z.B.:
Queue1 => Bestellungen
Queue2 => Support
Queue3 => Änderungen
Das Rollenmodell kann wirklich umfangreich sein. Einen tollen Beitrag dazu findest zu etwa hier:
https://htddi.wordpress.com/2014/02/04/otrs-config-pt1/
Was sich bei unseren OTRS Einsätzen bewährt hat, ist NICHT eine Queue pro Kunde aufzusetzen. Diese sollten lieber generisch gehalten werden, z.B.:
Queue1 => Bestellungen
Queue2 => Support
Queue3 => Änderungen
Das Rollenmodell kann wirklich umfangreich sein. Einen tollen Beitrag dazu findest zu etwa hier:
https://htddi.wordpress.com/2014/02/04/otrs-config-pt1/
Currently using: OTRS 6.0.14 -- MariaDB -- Ubuntu 16 LTS
-
- Znuny newbie
- Posts: 23
- Joined: 11 Apr 2017, 14:15
- Znuny Version: 5.0.18
Re: System Design: Queue vs. Dynamic Fields und Performance (200k+ Customers)
Kannst du diesen Ansatz noch ein wenig detaillierter erläutern?RStraub wrote:Du kannst neben dynamischen Feldern auch Services nutzen zum differenzieren.[...]
Kannte ich schon, ist wirklich eine tolle Lektüre.RStraub wrote:[...]Das Rollenmodell kann wirklich umfangreich sein. Einen tollen Beitrag dazu findest zu etwa hier:
https://htddi.wordpress.com/2014/02/04/otrs-config-pt1/
Freundliche Grüsse
wucherpfennig