-
Beiträge
-
-
Hallo zusammen,
aktuell nutzen wir in der IT das Otobo Ticketsystem. Nun wollen auch zwei weitere Abteilungen aus unserem Unternehmen ein Ticketsystem bekommen. Hierfür wird ein zweiter Server aufgesetzt, auf dem die zwei Abteilungen ihre Queues usw. bekommen. Die beiden Ticketsysteme bekommen einen unterschiedlichen Ticketprefix damit keine Tickets verloren gehen und sich so bei einem Austausch zwei Tickets parallel aufbauen.
Jetzt wollte ich mir aber noch andere Meinungen einholen. Gibt es hier Unternehmen die auch mehrere Abteilungen mit Ticketsystem haben? Wie genau gehen Sie hier vor? Nutzen Sie einen oder mehrere Server und wie sind hier die Erfahrungen?
Ich freue mich auf Ihre Antworten!
LG
-
Hallo Mirco,
wir nutzen Otobo für mehrere Abteilungen auf einem Server.
Die Abteilungen haben dann eigene Emailadressen, die per Postmaster dann abgeholt werden und in die entsprechenden Queues geschoben werden.
Die Agenten (User) sind dann Mitglied der entsprechenden Gruppe, die auf die Queue gesetzt wurde.
Hier muss dann dann aufpassen, falls in einer Email beide Abteilungen drin sind. Hier kann es passieren, dass die Email nur in der Queue von Abteilung 1 landet oder von Abteilung 2. Da müsste man die Filter dann testen.
Und Abteilungsübergreifend, verschiebt der Agent dann am Besten die Email in die jeweilige Queue, wenn die von einer anderen Abteilung bearbeitet werden soll.
Hoffe das ist halbwegs verständlich geschrieben :)
Gruß Marcel
-
Hey Marcel,
danke für deine Antwort! Wie macht ihr das bei den abteilungsübergreifenden Emails…Damit du es in die Queue von einer anderen Abteilung schieben kannst brauchst du doch die Berechtigung dafür? Habt ihr dann alle Gesamtberechtigung für jede Queue. Das wollen wir zum Beispiel nicht machen
Gruß Mirco
-
-
Hallo Mirco,
wir haben für die Agenten, die das benötigen, in der entsprechenden Gruppe das Recht “verschieben in” eingerichtet.
Wenn du eine Gruppe erstellt hast und dann unter “Agenten<->Gruppen” den Agenten oder die Gruppe auswählst, kannst du die Rechte setzen.
Gruß Marcel
-
-
Hallo zusammen,
wir nutzen eine OTOBO-Instanz für den IT-Support, Teile der Verwaltung, das Liegenschaftsmanagement mit seinem Schließsystem und Hausmeistern, unsere Bibliothek, sowie für den 2nd-Level-Support für zentrale IT-Dienste.
Für mich ist das Schwierigste, die Konfiguration der Statuus, Ticket-Typen, SLAs und Co. so aufzubauen, dass die einzelnen Bereiche sich nicht in die Quere kommen: Solange alle einen Default-Ticket-Typ haben, ist alles kein Thema. Wenn aber die IT nach ITIL arbeiten möchte, kommt damit das Liegenschafsmanagement nicht immer so recht klar. Also baut man ACLs, die die Konfigurationen ein-/ausblenden. Das geht, macht aber die “schnelle” Einführung von Neuerungen deutlich komplizierter und damit langsamer. Man muss bei allen Einstellungen aufpassen, dass man nicht die Arbeitsweisen einer anderen Einrichtung tangiert. Dennoch sind wir bei einer Instanz geblieben, weil alles andere dann wieder den Overhead zweier zu konfigurierender/zu pflegender Systeme mit sich brächte.
Die Übergabe von Tickets und die Pflege der Berechtigungen wiederum ist innerhalb des einen Systems bei uns überhaupt kein Problem: Da alle im selben System arbeiten, haben wir einen Identifier und eine relativ große Menge an Queues mit verschiedensten Berechtigungen und kommen damit gut klar. Die Übergabe zwischen Abteilungen/Einrichtungen geschieht in der Regel über die Eingangs-/Dispatch-Queues der Einrichtungen (so kann z.B. der IT-Support nur aus seinem Posteingang in andere Einrichtungen dispatchen, damit IMMER eine letzte Sichtung durch das SPOC-Team erfolgt, bevor das Ticket das eigene Hoheitsgebiet “für immer” verlässt). Auch sind nicht alle Agenten zum Verschieben nach Extern berechtigt. Das Ziel ist dann immer der Eingangskorb oder die Haupt-Queue der anderen Betriebseinheiten, damit nicht “aus der Tiefe in die Tiefe” an Dispatching/Monitoring vorbei gearbeitet werden kann. Der GenericAgent setzt gegebenenfalls auf Basis dieser Haupt-Queue auch noch Einstellungen oder löscht z.B. einen IT-SLA.
Zu empfehlen ist aus meiner Sicht in jedem Fall die konsequente Anlage von Queues -> Gruppen <-> Rollen <- Agenten, und die Zuweisung von Berechtigungen ausschließlich über den “Umweg” der Rollen abzubilden. Spätestens, wenn ACLs dazu kommen, macht das einiges leichter und verständlicher.
Viele Grüße
Martin -
Hallo,
ich habe ähnliches Problem wobei wir den Ansatz nehmen, das für jede externe Firma eine eigene Queue angelegt wurde. Was ist der beste Weg um sicherzustellen, dass die jeweilige externe Firma nur die eigene Queue sieht und eine Masterqueue in welche das Ticket zurück gegeben werden kann?
Sollen wir hierfür eigene Gruppen verwenden oder Rollen. Müssen die jeweiligen Queues dann der jeweiligen Gruppe zugeordnet werden oder sollen diese in der default “users” gruppe bleiben?Welche Rolle Gruppe soll ich der MasterQueue geben oder soll diese in der default users Gruppe bleiben
Brauchen wir dann noch zusätzlich ACLs?
Die einzelnen Agents möchte ich möglichst nur bei der Anlage angreifen und maximal einer Rolle oder Gruppe zuordnen und nicht immer manuell die notwendigen Rechte per User setzen-
Vielen Dank
Thomas
-
Ich denke ich habe es nun selbst gelöst wie in einer oberen Antwort geschrieben mittels Queue –> Gruppen –> Rollen –> Agents.
Sprich jede Queue (CompanyA) wurde auf eine Gruppe (Gruppe-CompanyA) gesetzt. (MasterQueue –> Gruppe-Master)
Es wurde jeweils eine Rolle erstellt (Rolle-CompanyA), und über “Roles<->Groups” wurde der Rolle voller Zugriff auf die jeweilige Gruppe erteilt (Gruppe-CompanyA) und nur “move to” Rechte auf die “Gruppe-Master”.
Die Agents wurden dann der jeweiligen Rolle zugeordnet via “Agents<->Roles”
Alle Agents wurden aus der default “user” Gruppe entfernt und es werden weitere Agents nur noch Rollen zugeordnet.
Ich denke das ist der korrekte Weg.
ACLS etc. sind hierfür nicht notwendig.
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.