Technische Umsetzung des Backlogs mit einem 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”.

Nachdem die organisatorischen Abläufe geklärt wurden, kann mit der Digitalisierung der Abläufe begonnen werden. Hierzu müssen die fachlich definierten Vorgänge in technisch abbildbare Prozesse überführt und die entsprechenden technischen Rahmenbedingen dafür geschaffen werden. Zusätzlich ist es sinnvoll, sich dabei an Rahmenwerken wie der IT Infrastructure Library (ITIL) zu orientieren.  Dieser Artikel stellt eine beispielhafte Abstraktion und technische Abbildung des entsprechenden Prozesses dar und geht dabei auch auf wesentliche Standards und die wesentlichen Aspekte einer Erweiterung oder Beschaffung ein.

Schematischer Ablauf der Abhandlung von Problemen und neuen Anforderungen

Zur Veranschaulichung dient folgendes Beispiel:

Die/Der zuständige KeyuserIn für den Vertriebswürfel verwaltet drei Domänen: Kosten, Verkäufe und Preisfindung. Die AnwenderInnen  im Controlling haben ein schweres Problem mit den Daten und einen Verbesserungsvorschlag, ein/e ExpertIn im Vertrieb hat ein leichtes Problem und ein/e MitarbeiterIn im Pricing hat einen Verbesserungsvorschlag.

Folgende Grafik stellt diese Sachverhalte schematisch dar:

Grafik 1: Schematischer Ablauf der Abhandlung von Problemen und neuen Anforderungen im Sales-Cube

Probleme werden im ITIL-Fachjargon als „Incidents“ und neue Anforderungen als „Changes“ bezeichnet. Oftmals kommt es zu Ineffizienzen, wenn diese Begriffe von MitarbeiterInnen ohne ITIL Know-How nicht korrekt abgegrenzt und falsch gehandhabt werden. Zum einfachen Verständnis werden Probleme in der Grafik in roter Farbe und einem „Totenkopf“ dargestellt, wohingegen neue Anforderungen und Ideen in grüner Farbe und einer „Glühbirne“ abgebildet werden.

Zur besseren Übersicht und Priorisierung nutzen größere Organisationen System, welche eine Verwaltung ermöglichen -> oftmals als "Ticketsystem" bezeichnet, aber eigentlich Issue-Tracking-System. Ein Incident oder Change wird in diesem System als „Ticket“ erfasst und mit allen notwendigen Informationen zur Bearbeitung versehen. Diese Tickets ermöglichen eine Priorisierung bzw. auch die Überwachung der Fortschritte und generell Informationen zur Zuverlässigkeit der IT-Systeme.

In der IT sollten Incidents grundsätzlich den Vorzug gegenüber Changes erhalten, da diese den Tagesbetrieb einschränken. Mit installierten Power- und KeyuserInnen ist es aber nicht notwendig sämtliche Incidents direkt an die IT weiter zu leiten. In erster Instanz kümmert sich der/die PoweruserIn um das Problem. Sollte es nicht lösbar sein, geht dieses an die/den HauptexpertIn der Domäne, der/dem KeyuserIn. Sollte dies auch nicht lösbar sein, so wird dieses Ticket an die IT weitergeben. Im Beispiel bedeutet das, dass das Problem im Vertriebsbereich (Domäne 2) direkt von dem/der PoweruserIn gelöst wurde und das Problem in der Kostenrechnung (Domäne 1) an die IT weitergegeben wurde. Der/Die KeyuserIn hat hierbei den vollen Überblick, wie viele und welche Probleme auftreten bzw. auch über den laufenden Bearbeitungsstatus. Die Changes werden in einen Pool gesammelt und der/die KeyuserIn kann danach über die Umsetzung entscheiden. Die wichtigsten Punkte werden in das Backlog überführt und dann die Umsetzung gemeinsam mit den KeyuserInnen der anderen Domänen (z.B.: Logistik, Human Ressources, etc.) priorisiert. Durch die transparente Abbildung der Changes und Incidents ist die Auslastung leichter greifbar und das Verständnis für Wartezeiten wird dadurch erhöht.

Der Prozess

In diesem Teil des Artikels möchten wir nun genauer auf den Prozessablauf von einerseits Incidents und andererseits Changes eingehen und damit den von uns gewählten Ansatz genauer erläutern.

Wir verzichten dabei ausdrücklich auf eine bestimmte Prozessmethode wie BPMN oder eEPK um hier eine Reduktion der Komplexität zu erreichen und uns damit auf das Wesentliche konzentrieren zu können.

In den folgenden Flow-Charts verwenden wir folgende Symbolik.

Legende Flow-ChartGrafik 2: Legende der verwendeten Symbolik für Flow-Charts

Der Incident

Grundsätzlich unterscheiden sich die Prozesse von Incident und Change nicht wesentlich. Ein Incident hat jedoch eine bestimmte Zeit in dem er gelöst bzw. bearbeitet werden muss. Dies ist normalerweise von der "schwere" des Problems (Konzern-, Gruppenweit oder einzel Arbeitsplatz) abhängig. Ein weiteres Merkmal ist, dass das Problem plötzlich und unerwartet auftritt und den betroffenen Personenkreis in der täglichen Arbeit hämmt oder sie sogar blockiert.

In unserem Modell gibt es zwei Anlaufstellen bevor das Problem an die IT weiter geleitet wird. In diesem konkreten Fall gibt es im Ticketsystem zwei Queues, einmal die Queue des Powerusers und dann noch die Queue der Keyuser, eine detaillierte Information über diese Rollen finden Sie in unserem Artikel Effektiv sowie effizient Arbeiten durch Keyuser. Zwingende Vorraussetzung das beide Gruppen in späterer Hinsicht entscheiden können ob es sich um einen Change oder Incident handelt ist, dass die Begrifflichkeiten des ITIL-Frameworks bekannt sind.

Grundsätzlich werden Probleme durch User eingemeldet die mit dem betroffenen System täglich arbeiten und direkt in den Backlog des Powerusers im Ticketsystem geleitet. Dieser entscheidet dann ob es sich um einen Incident oder Change handelt. Danach muss eine Analyse des Powerusers durchgeführt werden mit dem Ziel der Lösbarkeit des Problems durch diese Instanz. Im weiteren Schritt, sollte keine Lösung durch den Poweruser möglich sein, muss eine detaillierte Problembeschreibung mit Fallbeispielen bzw. reproduzierbarem Fehlerverhalten erstellt werden. Im Grunde muss durch die getätigte Beschreibung die nächste Instanz in der Lage sein, die Analyse für die Behebung des Fehlers ohne größeren Zeitverzug bearbeiten zu können. Nach diesem Schritt wird der Incident in den Backlog (Queue im Ticketsystem) des Keyusers verschoben.

Der Keyuser überprüft die Beschreibung des Incident, hier könnte man eine Art Checkliste entwickeln, auf Vollständigkeit und Plausibilität und beginnt die Analyse des Problems auf technischer Ebene. Nach diesem Schritt muss er entscheiden ob das Problem durch ihn oder die IT gelöst werden kann. Trifft zweiter Punkt zu, wir das Ticket um die detailliertere Analyse, mit schon stärkerem teschnischen Wissen, angereichert und in die Incident-Queue der IT verschoben.

In der IT löst ein Incident einen vordefinierten Prozess aus, der mit der "Alarmierung" der jeweiligen zuständigen Gruppen/Personen beginnt die sich ohne Zeitverzug diesem Problem annehmen. Ein wesentlicher Faktor für die schnelle Abwicklung des Incidents ist eine gute Problembeschreibung des Power- und Keyusers. Ist dies nicht der Fall muss eine Schleife gezogen werden und der Keyuser und in weiterer Folge der Poweruser müssen den Sachverhalt detaillierter formulieren. Danach kann die Arbeit der IT mit der Problemanalyse beginnen und darauf folgend die Implementierung des Problems. Nach diesem Schritt wird auf die jeweilige QA Umgebung der erarbeitete Code deployed und durch das Ticketsystem der Keyuser informiert, dass ein Testen möglich ist. Erst wenn eine erfolgreiche Abnahme, wieder über das Ticketsystem, erfolgt wird ein Deployment auf die Produktion durch die IT veranlasst, das wiederum den gleichen Prozess durchlaufen muss wie in einer QA Umgebung (Freigabe durch Key- oder Poweruser). Erst dann darf das Ticket durch die IT geschlossen werden. Dies ist auch gleichzeitig der letzte Punkt im Prozess und beendet diesen.

Der Change

Der Change Prozess unterscheidet sich insofern vom Incident, dass hier keine fix definierten Laufzeiten für Bearbeitung und Lösung des Problems vorliegen. Der oben beschrieben Verlauf eines Incidents ist bis zum Keyuser und einer eventuellen Lösung durch diesen ident. Kann keine Lösung durch diese Instanz angeboten werden, so wird der Change, in Form eines Tickets, in den BICC Backlog verschoben. Dieser Backlog kann bis zum nächsten Treffen des BICC-Gremium mit beliebige vielen Anfordernung befüllt werden. Im BICC wird dann gemeinsam mit allen beteiligten Fachbereichen und im beisein der IT über die Notwendigkeit und Priorisierung der einzelnen Changes entschieden. Eine genaue Beschreibung der Tätigkeiten des BICC finden Sie in unserem Artikel Effektiv Steuern mit einem Business Intelligence Competency Center.

Nach der Priorisierung durch das BICC werden die notwendigen Changes in die Queue des Changepools im Ticketsystem verschoben und der Change läuft den gleichen Prozess durch wie ein Incident. Die Ausnahme ist, dass keine Alarmierung durch das System an die betroffenen Gruppen/Personen in der IT ausgelöst wird.

ITIL-Standards für den Gesamtprozess

In diesem Teil möchten die Autoren den Gesamtprozess hinsichtlich ITIL näher erläutern. Dabei aber nicht zu sehr das Thema in einem hohen Detailgrad beleuchten, da dies den Rahmen des Artikels sprengen würde.

Der Lesende der mit ITIL vertraut ist, wird in den einfachen Flußdiagrammen die verschiedenen Phasen des ITIL Lifecycles vermutlich schon identifieziert haben. Diese wären:

  1. Business case und Projektstart (Strategiephase)
  2. Bedarfsanalyse (Service Designphase)
  3. Design (Designpahse)
  4. Programmierung (Übergangsphase)
  5. Live und Support (Produktions- und Dienstleistungsphase)

Business case und Projektstart (Strategiephase)

In dieser Phase werden Business cases anhand von Kosten und Nutzen evaluiert und entschieden ob ein bestehender Service ausgebaut oder ein neuer Service implementiert wird. Initiiert wird diese Ebene durch den jeweiligen Anwendungsfall der aus den Fachbereichen an die IT herangetragen wird.

In unserem Fall ist das der Schritt des Problems beim Change-Prozess. Die Autoren haben im Desing der Change-Prozesse diese Phase erneut in Form des BICC implementiert, da es ihnen wichtig war eine konzernweite Entscheidungsplattform zu etablieren, in der etwaige Probleme in Hinsicht auf die Gesamtheitlichkeit der Prozesse im Vorfeld analysiert und abgestimmt werden.

Bedarfsanalyse (Service Designphase)

Eine Analyse bezüglich Systemabhängigkeiten und Voraussetzungen für den Change erfolgt in dieser Ebene. Umgeschlüsselt auf unseren Change-Prozesse beginnt das mit der Problembeschreibung des Powerusers und endet mit der Beschreibung des Keyusers

Design (Designphase)

Eine ausführliche Beschreibung zum Beispiel in Form eines Lastenheftes, wird erstellt. In unserere Prozesskette findet das vor dem BICC statt, da nur Themen in diesem Gremium priorisiert werden dürfen, die den Change aus Sicht des Fachbereichs genau dokumentieren. Somit startet diese Phase vor dem BICC und endet mit der Analyse des Problems in der IT.

Programmierung (Übergangsphase)

Die gewünschten Anforderungen des Changes werden implementiert und getestet. Diese Phase beginnt im dargestellten Prozess mit der Behebung des Problems und erfolgreichem Test der zur Freigabe für das Deployment auf Produktion führt.

Live und Support (Produktions- und Dienstleistungsphase)

Der Change ist im Produktionssystem, wird gewartet und auftretende Probleme behoben. In unerer Prozesskette beginnt diese Ebene mit der Produktionsumgebung und der finalen Freigabe durch den Fachbereich.

Unerwartete auftretende Fehler in der Produktion werden mit dem Incidentprozess abgedeckt.

Abbildung des Prozesses im Issue-Tracking-System

Nachdem die Prozesse nun sowie fachlich wie technisch definiert wurden, können diese im Issue-Tracking-System („Tícketsystem“) abgebildet werden. Sollte bereits ein System vorhanden sein, so ist dieses im Regelfall bereits in der technischen Prozessmodellierung mitberücksichtigt worden. Die Autoren empfehlen hier die Nutzung eigener Container oder auch „Bearbeitungswarteschlange“ (Queue). Hierzu gibt es kein generisches Konzept, welches 1:1 für sämtliche Organisationen passt. Es hat sich jedoch bewährt, dass die Probleme aller Benutzer in die Queue der/des PoweruserIn kommen, diese wiederum geben diese in die Queue der/des Keyusers ein, welche diese in die IT-Queue geben können. Die Neuanforderungen sollten direkt in die Queue des Keyuser einfließen und von dort nach Abstimmung mit dem BICC in die Queue der IT überführt werden. Danach werden diese Changes einem (Verbesserungs-)Projekt zugewiesen, damit das Projektcontrolling in einer effizienten Form erfolgen kann

Anpassung oder Neuanschaffung

Zur Unterstützung bei der Entscheidungsfindung zu einer Adaption eines vorhanden Ticketssystems oder einer Neuanschaffung sollten zunächst die Anforderungen ermittelt und dokumentiert werden. Diese sollten nicht nur die Anforderungen des Keyuserkonzepts beinhalten sondern auch weitere Aspekte (z.B.: Tauglichkeit für verschiedene Projekte wie SCRUM oder das Wasserfallmodell, Dokumentation, Schulung, Integration von Dashboards in eine andere Plattform, etc.) der IT-Landschaft berücksichtigen, um sich darin optimal einzufügen.

Die wichtigsten Anforderungen werden dann in einer Entscheidungsmatrix abgebildet. Wichtig ist es, die Anforderungen in „Muss vorhanden sein -> K.O. Kriterium“, „Sollte vorhanden sein“ und „Kann vorhanden sein“ zu teilen. Zusätzlich können noch bei Bedarf Gewichtungsfaktoren nach den Gruppen hinterlegt werden, da Aspekte wie die gesamten Kosten während des Lebenszyklus (Total Cost of Ownership) auch sehr wichtig sind. Folgende Tabelle stellt ein vereinfachtes Beispiel dar:

Tabelle 1: Beispielhafte Anforderungsmatrix

Wenn nun die Entscheidung für ein System getroffen wurde, sollte ein Proof-of-Concept (PoC) durchgeführt werden. Auf eine Vorgangsweise wird an dieser Stelle nicht näher eingegangen, da dies sonst den Rahmen des Artikels sprengen würde. Auf dieser Homepage befindet sich jedoch bereits ein Artikel über eine Vorgansweise für einen PoC für ein Datawarehouse. Zwar ist der Zusammenhang etwas anders, die Grundaspekte sind aber im Rahnem dieses Kontexts brauchbar.

Schlussbetrachtung

Für die breite Akzeptanz und einen gesteigerten Mehrwert für die Organisation ist eine technisch optimierte Implementierung unumgänglich. Die hier geschilderten Prozesse dienen als ein Beispiel für eine Variante, 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 Blick zu nutzen.

Wenn zum Beispiel nur noch der/die KeuyserIn Tickets erfassen darf, so steigt die Qualität in Richtung IT, jedoch wird das zu einer Überlastung an anderer Stelle führen bzw. wird Arbeitszeit blockiert, wde an anderer Stelle sinnvoller genutzt wäre. Daher haben sich die Autoren für das Weiterleiten und Ergänzen von Tickets entschieden. Dies ist nur ein kleines Beispiel der Aspekte, die berücksichtigt werden müssen.

Die hier dargestellte grundsätzliche Methodik hat sich als ein wesentlicher Erfolgsfaktor für die Autoren bei der Einführung von Keyuserkonzepten erwiesen.

Ü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