Implementierung eines IT-Portfolio in ein Ticket-Issue-System

Dieser Fachartikel der Autoren Mag. Christian Gasperi und Markus Rotter, MA ist Teil der Artikelserie zum Thema "From Chaos to Organization: Einführung eines BICC in einem KMU”.

In diesem Artikel verfolgen diese konsequent den Weg eines Ticket-Issue-Systems weiter und verankern diesen noch tiefer in die IT-Organisation. Dies geschieht mit der Implementierung eines IT-Portfolio im oben genannten System.

Prozessbeschreibung

Einleitung:

Für die Erstellung des IT-Portfolio haben die Autoren aus der täglichen Arbeit in einer IT-Abteilung drei wesentliche Bereiche identifizieren können. Diese wurden in weiterer Hinsicht genauer analysiert um einen optimalen Prozessablauf zu gewährleisten.

In einem Ticket-Issue-System werden aus folgenden Tätigkeiten, Daily Business und Projekte, Anforderungen an die IT gestellt. Wobei die Autoren eine Unterteilung für das Daily Business vorgenommen haben, da sich hier die Prozesse wesentlich unterscheiden. Somit wurde die oben genannte Tätigkeit in zwei Untergruppen geteilt, Daily Business (extern) und Daily Business (IT-intern). Wobei mit extern einerseits die Fachbereiche der eigenen Organisation und andererseits auch Zulieferer bzw. unternehmensfremde Dienstleister unter diesen Begriff fallen. In diesem Konzept wird bewusst auf die Eingliederung der DevOps verzichtet, da dieser Bereich einer komplett anderen Systematik folgt, wenngleich auf den ersten Blick Parallelen vorhanden sind.

Für den unten beschriebenen Prozessablauf gibt es zwei Voraussetzungen.

Erste Voraussetzung ist, dass das Ticketsystem in der Landing-Page nur die notwendigsten Schaltflächen anbietet, siehe 5S-Lösungsansatz weiter unten im Artikel. Der Lösungsansatz der Autoren lehnt sich an die gute Bedienbarkeit aus verschiedenen Bereichen aus dem Alltag an. An dieser Stelle sollen nur zwei Beispiele genannt werden.

Wer hat nicht schon einmal bei einer großen Fastfood Kette an den Bestellterminals sein Essen bestellt oder in einem schwedischen Möbelhaus Möbel retourniert, beanstandet oder Service angefordert?

Die zweite Voraussetzung ist die Schulung der jeweiligen/zukünftigen Benutzer/-innen, damit gewährleistet ist, dass ein effizienter Ablauf in der IT und eine richtige Kategorisierung der Tätigkeiten erfolgt.

Die Autoren haben in der Grafik die oben beschriebenen Schaltflächen mit Problem, Aufgabe und Verbesserung/Anforderung benannt. Dahinter verbirgt sich natürlich der ITIL Standard und seine Nomenklatur, die aber im wesentlichen dem Benutzer/-innen nicht bekannt sein müssen.

Abbildung 1: Prozess der Abarbeitung von Tickets

Prozess:

Daily Business (extern):

Die Benutzer/-innen geben ein Ticket auf und kategorisieren in die Bereiche Problem, Aufgabe oder Verbesserung/Anforderung. Wird die Schaltfläche Problem ausgewählt so wird der User mittels einem Leitfaden ans Ziel geführt. Aufgrund der getroffenen Entscheidungen wird ein kritisches oder normales Ticket aus dem System erstellt. Wobei sich die jeweiligen Unterzweige (kritisch/normal) im Prozessablauf wesentlich unterscheiden. Im kritischen Zweig wird das Problem (Ticket) unverzüglich in die Queue des zuständigen IT-Mitarbeiters gesendet und erfordert das unmittelbare tätig werden von diesem. Beim normalen Problem landet das Ticket in der Warteschlange des Keyusers. Dieser analysiert das Problem und versucht selbstständig eine Lösung zu finden, gelingt ihm das nicht, so muss das Problem in ein regelmäßig tagendes priorisierendes Gremium eingebracht werden. Dabei steht es im frei das Ticket einer anderen Kategorie zuzuweisen. Zum Beispiel kann der Keyuser ein Ticket das auf Problem kategorisiert wurde zu einer Aufgabe umwandeln und vice versa. In diesem Gremium sind alle Fachbereiche an einem Tisch und stimmen über die Wichtigkeit der Themen ab. Für eine detaillierte Ausführung über dieses Konzept lesen Sie bitte unseren Artikel zur Einführung eines Business Intelligence Competency Center.

Werden Tickets mit der Kategorie Aufgabe erstellt, so durchläuft diese Ticket den gleichen Prozess wie oben beschrieben das Problem.

Tickets mit der Kategorie Verbesserung/neue Anforderung landen auch in der Queue des Keyusers. Dieser entscheidet dann ob es sich um eine relevante oder nicht relevante Anforderung handelt. Im Zweig nicht relevant wird das Ticket durch den Keyuser geschlossen, im gegenteiligen Fall wird die Anforderung dann wieder in ein priorisierendes Gremium eingebracht und in späterer Folge der IT zur Bearbeitung weiter geleitet. In diesem Konzept spielt der Keyuser eine wesentliche Rolle und ist Bindeglied zwischen Fachbereich und IT, sozusagen der verlängerte Arm der IT in den Fachbereich. Eine Detailbeschreibung der Anforderungen an einen Keyuser und der Implementierung eines Keyuser-Konzepts können Sie unserem Artikel Effektiv sowie effizient Arbeiten durch Keyuser entnehmen.

Daily Business (intern):

Im Wesentlichen folgt der Prozess dem oben beschriebenen Bereich des Problems mit zwei Ausnahmen. Das Ticket wird nicht von einem Benutzer/Keyuser im Fachbereich erstellt sondern von einem Mitarbeiter in der IT. Dabei hat er die gleichen Auswahlmöglichkeiten wie die Kollegen/-innen in den Abteilungen der Organisation. Die Autoren haben in diesem Prozess die Mitarbeit des Keyuser völlig ausgeklammert da Probleme, Aufgaben und Verbesserung/neue Anforderungen aus der IT meist einen hohen technischen Detailgrad haben und direkt mit dem Betrieb der jeweiligen Applikation zusammen hängen. Es muss jedoch immer der Keyuser über etwaige Arbeiten an dem von ihm betreuten System informiert werden.

IT-Projekte:

In diesem Teil fällt die Kategorie des Problems weg, da ein Projekt einer kontinuierlichen Veränderung unterliegt. Die übrigen Ticket Kategorien/Bereiche verlaufen genau gleich wie oben beschrieben. Ein wesentliche Unterschied ist der Personenkreis der ein Ticket erfassen kann und schränkt sich auf die Rolle der Projektleitung ein. Auch in diesem Fall ist der Keyuser im Prozessablauf nicht involviert, da er von vornherein ein Mitglied im Projektteam ist. Wird im Zuge des Projekts ein Ticket bearbeitet, dass unmittelbar in den Bereich des Keyuser fällt, so wird dieser imformiert.

Erhöhung der Akzeptanz und Effizienz durch eine passende Benutzeroberfläche

Zusätzlich zu einer effizienten prozesstechnischen Abwicklung darf eine entscheidende Komponente nicht vergessen werden: der/die AnwenderIn.

Die besten technischen Lösungen sind nutzlos, wenn diese nicht akzeptiert werden oder Spielraum für fehlerhafte Anforderungen gewähren. Um dies zu bewerkstelligen ist einiges an Planung und Überprüfung notwendig. Die Autoren haben unter anderem mit den Lean Management Methoden „5S“ und „Poka Yoke“ sehr gute Erfahrungen gemacht. Eine detaillierte Vorstellung würde den Rahmen dieses Artikels sprengen, jedoch gehen die Autoren in sehr kurzer Form zum besseren Verständnis darauf ein. 5S kommt eigentlich aus dem Produktionsbereich und bedeutet, dass der Arbeitsplatz möglichst zusammengeräumt ist und die benötigten Gegenstände schnell erreichbar sind. Zusätzlich sind jederzeit Ablaufbeschreibungen verfügbar. Umgelegt auf die Benutzeroberfläche verweise die Autoren auf die bereits genannten Beispiele in der Einleitung der Prozessbeschreibung. Diese ermöglichen Ihnen ohne Einschulung und intuitiv die Bestellung oder Reklamation durchzuführen.

Folgendes kurzes Beispiel verdeutlicht die Effizienz. Versuchen Sie eine Idee für Anwendung A (Beispiel ein neues berechnetes Feld) im Geiste „mitzuklicken“. Um wie viel sind Sie schneller, wenn eine gute Anordnung besteht und Begriffe verwendet werden, die keine ITIL-Schulung oder anderes Wissen in der Organisation voraussetzen:

Abbildung 2: Ein vereinfachtes Beispiel für eine Benutzeroberfläche nach 5S

Die zweite angesprochene Methode, das „Poka Yoke“ steht für Fehlervermeidung. Dies bedeutet, dass das Ticket-Issue-System fehlerhafte oder unlogische Anforderungen (zum Beispiel: Passwort zurücksetzen als kritisches Problem, Programmänderung im ERP-System unter Anwendung A klassifizieren, etc.) verhindert. Ein sehr plakatives, und im Lean Management beliebtes, Beispiel für ein „Poka Yoke“ sind Steckdosen: Es ist unmöglich ein Netzteil mit Spannung wie in Amerika üblich in eine europäische Steckdose einzustecken, die Endstücke passen nicht. Erst ein Adapter, der die Spannung kompensiert und Brände verhindert lässt eine Benutzung des Netzteils zu.

Strategischer Mehrwert durch die Nutzung für Portfolio-Management

Ein funktionales Ticket-Issue-System ermöglicht die effiziente Verwaltung von IT-Agenden. Wenn das Ticket-System aber für weitere Agenden darüber hinaus verwendet werden kann, so steigert sich der Nutzen erheblich. Auf dieser Seite wurde bereits ein IT-Management-Portfolio thematisiert. Wenn das Ticket-Issue-System eine schnelle Erfassung von internen Aufgaben und die Darstellung aller Tickets in Form eines KanBan-Boards zulässt, so haben Sie eine großartige Möglichkeit zur abteilungsübergreifenden Steuerung geschaffen. Durch den gemeinsamen Zugriff mit den KeyuserInnen werden auch die Transparenz und die Zusammenarbeit verbessert. Das angesprochene Portfolio wird an dieser Stelle nicht näher thematisiert, Sie können den entsprechenden Artikel -> HIER <- nachlesen.

Schlussbetrachtung

Für die breite Akzeptanz und einen gesteigerten Mehrwert für die Organisation ist eine technisch optimierte Implementierung eines Ticket-Issue-Systems unumgänglich. Die hier geschilderten Prozesse dienen als ein Beispiel, eine generische und sofort verwendbare Blaupause gibt es nicht. Bei den Prozessen ist es wichtig, nicht nur eine Seite (Fachbereich, Management, IT, etc.) zu berücksichtigen, sondern einen möglichst breiten Blickwinkel an den Tag zu legen.

Erfahrungsgemäß wird bei derartigen Implementierungen oftmals der (entscheidende) Faktor Mensch vergessen bzw. weitere Potenziale durch fehlende ganzheitliche Betrachtung verschenkt. Durch die Nutzung von den hier angeführten bzw. weiteren Techniken und Modellen kann dies verhindert werden.

Die hier dargestellte grundsätzliche Methodik hat sich als ein wesentlicher Erfolgsfaktor für die Autoren bei der Einführung von Keyuserkonzepten und Ticket-Issue-Systemen erwiesen bzw. ist der Mehrwert zur Steuerung ein weiterer Erfolgsbaustein.

Über die Autoren

Mag. Christian Gasperi Markus Rotter, MA

Mag. Christian Gasperi ist seit den 2000ern in der IT tätig und hat in dieser Zeit Erfahrungen mit Business Itelligence, Datawarehousing, Geoinformatik, Datenbanken, IT-Architkur, Systemarchitektur, Projektmanagement und lateraler Mitarbeiterführung gemacht. Markus Rotter, MA ist seit den 2000ern in der IT tätig und hat in dieser Zeit Erfahrungen mit IT-Management, Business Intelligence, Datawarehousing, Datenbanken, Systemadministration, IT-Architekturen, Mitarbeiterführung und Projektmanagement gemacht.
Homepage Homepage
Xing Profil Xing Profil

 

Zurück

Übersicht der Artikel

Dieser Artikel beschäftigt sich mit den Rollen in einem Data Team und den damit notwendigen Wandel.

Weiterlesen

Dieser Artikel beschäftigt sich mit den Erfolgsfaktoren und Stolpersteine bei der Einführung eines BICC.

Weiterlesen

Dieser Artikel befasst sich mit dem Aufbau einer passenden Architektur zur Umsetzung einer Datenstrategie.

Weiterlesen

Dieser Artikel befasst sich mit der Erstellung einer Datenstrategie.

Weiterlesen