Benutzergruppen
Die Benutzergruppen steuern die zentrale Rechteverwaltung innerhalb des Systems, entsprechen also auch den unterschiedlichen Benutzerrollen und der Zuweisung deren Systemrechten.
Die Struktur ist bewusst vereinfacht aufgebaut, um eine unkomplizierte Verwendung des Systems zu ermöglichen.
Der Administrator für Stammdaten (Mitglieder der Gruppen "Administration - Voll" und "Administration - Stammdaten") können jeden Benutzer in jede Gruppe aufnehmen.
Es ist technisch und kommerziell unerheblich welche Benutzer welche Berechtigungsgruppen erhalten, die Empfehlung ist nicht jeden Benutzer Administratoren Rechte zu geben, damit keine unabgestimmten Veränderungen in System-Prozessen erfolgen.
Standard Benutzergruppen
In der Auslieferung sind folgende Standardbenutzergruppen vorhanden:
•Administration – Asset Management: Die Gruppe hat Zugriff auf die Objekte der Asset-Management-DB, wie z. B. Asset-Typen und Attribute, und kann diese administrieren.
•Administration – Stammdaten: Enthält die Berechtigung, Stammdaten zu erstellen und anzupassen.
•Administration – Voll: Diese Gruppe hat Vollzugriff auf alle Administrationseinstellungen (Standardrolle des Administrators). Ein Administrator hat nicht automatisch die Berechtigung, Tickets zu erfassen und zu bearbeiten. Hierzu muss er separat der entsprechenden Benutzergruppe zugewiesen werden.
•Asset-Manager: Erhält erweiterten Zugriff auf die Asset Datenbank und wird beispielsweise bei Unterschreitung des Mindestbestands im Asset-Lager per E-Mail informiert.
•eCAB-Teilnehmer: Diese Gruppe erbt alle Berechtigungen der Gruppe „Ticket-Benutzer“ und kann zusätzlich verwendet werden, um beispielsweise Changes zu genehmigen.
•Security-Manager: Diese Gruppe hat alle Berechtigungen der Gruppe „Ticket-Manager“ und kann z.B. verwendet für sicherheitsrelevanten Störungen („Security-Incidents“) verwendet werden.
•Ticket-Benutzer: Die Gruppe enthält alle notwendigen Berechtigungen, um Tickets anzulegen und zu bearbeiten (Standardgruppe für Service-Desk-Mitarbeiter).
•Ticket-Manager: Ticket-Manager haben alle Rechte von Ticket-Benutzern und zusätzlich erweiterte Rechte für die Bearbeitung von Tickets und Zugriff auf das Task-Board sowie den KPI-Monitor. Die Gruppe kann beispielsweise die Ticket-Historie sowie die gesamten SLA-Zeiten einsehen. Zusätzlich können Tickets im Zustand „Erledigung“ manuell wieder geöffnet oder abgeschlossen werden (Standardgruppe für Manager).
•Alle Tickets sichtbar: Diese Spezialgruppe ermöglicht es jedem Benutzer (Nicht-Administratoren), unabhängig von anderen zugewiesenen Rollen/ Untergruppen immer alle Tickets innerhalb des Systems zu sehen. Diese Gruppe darf nicht verwendet werden, wenn Tickets von anderen Verantwortungsgruppen von diesem Benutzer nicht gesehen werden dürfen (bewusste Einschränkungen von Sichtbarkeit, s.u.)
Individuelle Benutzergruppen
Es ist möglich beliebige weitere individuelle Benutzergruppen anzulegen, diese sind aber immer eine Teil-Gruppe einer der verfügbaren Standardgruppen und erben entsprechend deren grundsätzlichen Berechtigungen. Daher ist bei der Anlage einer neuen Benutzergruppe immer eine übergeordnete aus den bestehenden Gruppen auszuwählen. Es ergibt sich damit in der Gruppenstruktur mit individuellen Gruppen also immer eine Baumstruktur.
Einschränkung der Sichtbarkeit von Tickets basierend auf der Gruppenstruktur
Bei der Nutzung des Ticketing Systems mit unterschiedlichen Ticket-Typen in mehreren Teams ist - je nach individueller Organisationsform - eine häufige Anforderung, dass Benutzer aus einem Team die Tickets aus einem anderen Team nicht sehen dürfen und umgekehrt. Zusätzlich gibt es übergreifende Benutzer, die den Überblick über alle Tickets benötigen.
Dies kann im Ticketing-System sehr einfach über die Zuweisung der Benutzer zu unterschiedlichen Gruppen oder Untergruppen erreicht werden. Das Feld "Verantwortliche Gruppe" im Ticket steuert damit automatisch welcher Benutzer welches Ticket sehen darf.
Grundsätzlich sehen alle Benutzer einer Gruppe alle Tickets der zugewiesenen Gruppe und deren Untergruppen auch wenn ein Ticket zusätzlich einem bestimmten Benutzer als Verantwortlich zugewiesen ist. Somit ist sichergestellt, dass z.B. bei Abwesenheit eines Benutzers ein Ticket einfach durch einen anderen Benutzer der gleichen Gruppe übernommen werden kann.
|
Hinweis: Die Sichtbarkeitsregeln für Benutzer auf Basis der zugewiesenen Gruppen wirkt sich nur auf Tickets und diesen Tickets zugewiesenen E-Mails aus. Andere Bereiche wie z.B. die Wissensdatenbank und die Asset DB sind für alle Benutzer zugänglich bzw. nur eingeschränkt über die grundsätzlichen Rollen-orientierten Berechtigungs-Gruppen (Administrator, Manager etc.). |
Im Folgenden sind einige Beispiele beschrieben, wie die Gruppenstruktur genutzt werden kann, um Tickets bzgl. deren Sichtbarkeit zwischen Benutzergruppen abzugrenzen:
Beispiel 1: Es gibt mehrere Teams innerhalb der IT Abteilung. Diese sollen nur jeweils die Tickets sehen und bearbeiten, die ihnen verantwortlich zugewiesen sind. Der IT Leiter oder IT Teamleiter soll aber übergreifend alle Tickets sehen.
Umsetzung:
•Eine neue Benutzergruppe muss je Team als Untergruppe der Standardgruppe "Ticket-Benutzer" angelegt werden
•Die Benutzer für die einzelnen Teams müssen auf die entsprechenden Untergruppen zugewiesen werden und dürfen nicht direkt der Ober-Gruppe "Ticket-Benutzer" zugeordnet werden
•Der Teamleiter mit übergreifender Sicht auf alle Tickets, der die Berechtigung "Ticket-Manager" haben soll, muss nur der Standard Obergruppe "Ticket Benutzer" zugeordnet werden und der Standard Gruppe "Ticket Manager"
Beispiel 2: neben IT Tickets sollen auch HR Tickets mit dem Ticketing-System bearbeitet werden. Die HR Tickets und zugehörige Kommunikationen dürfen ausschließlich von Benutzern aus dem HR Bereich gesehen werden. Umgekehrt dürfen die HR Benutzer keine IT Tickets sehen. Die beiden Bereiche haben auch jeweils eigene Teamleiter.
Umsetzung:
•Eine neue Benutzergruppe muss je Team als Untergruppe der Standardgruppe "Ticket-Benutzer" angelegt werden ( IT Team(s) und HR Team(s) )
•Die Benutzer für die einzelnen Teams müssen auf die entsprechenden Untergruppen zugewiesen werden und dürfen nicht direkt der Ober-Gruppe "Ticket-Benutzer" zugeordnet werden
•Der Teamleiter mit übergreifender Sicht auf alle Tickets der IT der die Berechtigung "Ticket-Manager" haben soll, muss nur jeder IT Benutzergruppe zugeordnet werden (oder man bildet für den Fall wieder eine eigene Obergruppe über die IT Gruppen) und der Standard Gruppe "Ticket Manager"
•Gleiches gilt für einen Teamleiter für die HR Tickets für die HR Gruppen
Zur Übersichtlichkeit der eingestellten Gruppenstrukturen werden alle Gruppen einmal als flache Liste und einmal als Baumansicht dargestellt (untergeordnete Gruppen sowie deren Benutzer)
Weitere Einstellungsmöglichkeiten für Benutzergruppen
•E-Mail Verhalten: je Gruppe kann eine spezifische Gruppen-E-Mailadresse hinterlegt werden. Bei automatischen Informationen per Email an die Gruppe kann so definiert werden, ob die Gruppen E-Mail oder jeder zugeordnete Benutzer der Gruppe einzeln über die jeweilige individuelle E-Mailadresse informiert werden soll. Weiterhin kann ein Standard ausgehender Email Account je Gruppe hinterlegt werden.
•Ticket Einstellungen: je Gruppe kann eingeschränkt werden, ob ein Mitglied dieser Gruppe ein Ticket nur an bestimmte andere Verantwortlichkeiten stellen darf (Es gelten dabei die Einschränkungen aller Gruppen, bei dem der User eingetragen ist). Falls es Einschränkungen geben soll, müssen diese in der jeweiligen Gruppe in der Liste gepflegt werden. Ist keine Gruppe in der Liste eingetragen, kann das Ticket auf jede Gruppe des Ticketsystems gestellt werden
Teams
Neben Benutzergruppen ist es möglich auch individuelle Teams zu definieren. Teams können aus Personen und Benutzer bestehen. Diese Teams können damit an unterschiedlichen Stellen im System zur Vereinfachung und Strukturierung der Verwaltung verwendet werden.
Beispiel Use Case: Genehmiger für ein bestimmtes Thema bestehen aus einer definierten Gruppe mehrerer Personen. Um diese nicht einzeln als Genehmiger definieren zu müssen, können sie vorab als „Team“ zusammengestellt und im Genehmigungsmodell entsprechend hinterlegt werden. Änderungen an Teams wirken sich damit auch direkt in den Verwendungsstellen aus. Ein weiteres Beispiel für ein Team sind Stakeholder für ein bestimmtes Thema, die aus Tickets heraus angeschrieben werden müssen.
Ein Team kann aus Personen und Benutzern zusammengestellt und ein entsprechender Team Titel für die Verwaltung vergeben werden. Eine optionale Team-Emailadresse kann hinterlegt werden (z.B. Exchange Gruppenadresse, falls vorhanden), die Teammitglieder werden aber immer auch einzeln informiert.