Früher oder später benötigt man neben einer aktuellen IT-Dokumentation auch ein Werkzeug zur Prozessabbildung. Auf der Wunschliste jedes Anwenders steht dann natürlich Datenintegration ganz oben: Doppelerfassung, redundante Arbeitsschritte und die Suche nach Informationen über zwei Tools will man sich gerne ersparen. Konkret wollen wir uns heute das Zusammenspiel von ((OTRS)) Community Edition HelpDesk mit i-doit ansehen. Mehrere i-doit Partner bieten solche Schnittstellen an, und das mit hohem Integrationsgrad.
Zum Ende des Jahres 2020 wurde bekannt gegeben das die Weiterentwicklung des Open Source Ticketsystem ((OTRS)) Community Edition 6 eingestellt wurde. Da es somit zukünftig keine weiteren lizenzkostenfreien Versionen des Produktes geben wird, könnte der ((OTRS)) Community Edition-Fork OTOBO eine gute Alternative darstellen. Er basiert auf der ((OTRS)) Community Edition und wird konstant weiterentwickelt.
Wer braucht welches Tool?
Spielt man die sprichwörtliche One-Man-Show, also IT-Admin, der selbst Systeme betreibt, Störungen beseitigt, den Anwendern persönlich hilft, muss man sich in erster Linie selbst organisieren. Hier steht selten der Aufbau eines Werkzeugs zur Prozessabbildung im Vordergrund, es reicht zumeist ein System zur Dokumentation der IT-Infrastruktur, wie es mit i-doit gegeben ist. Und man benötigt viele Automatismen, die einem das Leben erleichtern.
Teilen sich die Aufgaben jedoch auf mehrere Personen auf und gibt es fachliche oder zeitliche Überschneidungen, braucht man bessere Koordination und vor allem: Kommunikation. Hat ein Kollege nachts einige Änderungen durchgeführt, ist es einfach notwendig, dass der Kollege diese am nächsten Tag nachvollziehen kann. Es sei denn man will ständig für’s Troubleshooting erreichbar sein. Sind Störungen vom letzten Arbeitstag offen geblieben, sollen diese in einer Liste ersichtlich sein und effizient abgearbeitet werden können. Welche Reparaturen sind beim externen Servicecenter beauftragt? Ein Service Desk Tool hat die Antwort.
Vorteile für den IT-Betrieb
Die Verwendung von beiden Werkzeugen bringt folgende Vorteile im IT Betrieb:
- Alle Informationen und Vorgänge werden zentral gespeichert.
- Der Zugriff auf diese Informationen kann granular gesteuert werden.
- Jeder Schritt ist dokumentiert, und zwar dort, wo die Information hingehört: der Zustand der Geräte in der CMDB, der Verlauf von Störungen im Service Desk Tool. Um Zusammenhänge zu erkennen, dient die Verknüpfung der Daten.
- Klare Kommunikation zwischen internen Abteilungen, Kunden und Dienstleistern
- Gibt es Nachfragen oder weiteren Informationsbedarf, können alle Beteiligten, unabhängig von Dienstplan und Uhrzeit, auf den jeweils aktuellen Stand der Information zugreifen.
Was ist das Ziel?
Störungen in der IT gibt es, seit es IT gibt. Sie zu beseitigen, ist seit jeher ein langwieriges Unterfangen. ITIL nennt den Prozess “Incident Management” und das Ziel dieses Prozesses ist vorerst nicht die nachhaltige Lösung, die das Wiederauftreten des Fehlers verhindert, sondern eine schnelle Lösung für den Anwender. Hauptsache, die Arbeit kann weitergehen.
IT-Services sollen so schnell wie möglich wieder verwendbar sein, da darf auch mal gebastelt werden, sprich: Ein Workaround wird angewandt. Treten solche Fälle vermehrt auf, häufen sich auch die Bastellösungen. Man wünscht sich ein System, um diese Fälle wiederzufinden. Das Auftreten von Störungen will gezählt werden, Auswertungen sollen Serienfehler aufspüren, oder man will einfach nur herauszufinden, wo die Arbeitszeit geblieben ist.
Genügt anfangs eine Strichliste, wird man sich bald eine Excel-Tabelle bauen, oder eben ein System auswählen, das mehr kann. Ein Ticketsystem muss her, das zum Beispiel per E-Mail an Aufgaben erinnern kann, Auswertungen ohne langwierige SQL Schulung ermöglicht und vieles mehr, was erst später relevant wird. Bei der Auswahl greift man gerne zu Open Source. Denn wer zum ersten Mal ein solches System einführt, kann die Marketingaussagen der Hersteller proprietärer Systeme meist nicht deuten: Was braucht man wirklich?
Open Source Ticket Systeme gibt es wie Sand am Meer. Man könnte meinen, dass jeder Programmierer das Rad neu erfunden und online gestellt hat. Doch in den letzten Jahren hat sich ein System vom Wettbewerb abgesetzt: ((OTRS)) Community Edition, was ursprünglich “Open Ticket Request System” bedeutet und nun mit “Open Technology Real Services” umgedeutet wurde.
Noch ein Prozess
Spätestens nach der schnellen Lösung muss noch eine Haftnotiz an den Monitor, damit die Suche nach der nachhaltigen Lösung nicht in Vergessenheit gerät. Hier spricht ITIL nun von einem weiteren Prozess: Dem Problem Management. Hier wäre eine Art “Sammelticket” vorteilhaft, denn: während die Anwender mit dem Workaround bereits weiter arbeiten können, deren Tickets also geschlossen wurden, beschäftigen sich mitunter mehrere Personen mit dem Finden einer nachhaltigen Lösung. Hier fließt eine Menge Zeit und Energie rein. Grund genug, die jeweiligen Neuigkeiten zum Problem Ticket zu notieren – und damit auch gleich alle Beteiligten mit aktuellen Informationen zu versorgen.
Aller guten Dinge sind drei
Ist man sich nun sicher, was zu ändern ist, wird ein “Request for Change”, Im Admin-Sprech oft einfach “ein RfC” im Service Desk Tool eröffnet. Warum noch ein Ticket?
Änderungen werden gerne gesammelt und zu definierten Zeitpunkten umgesetzt. In diesen Wartungsfenstern ist wenig Zeit für Recherche, daher ist möglichst viel vorzubereiten. Die Risiken sollte man sich bereits im Vorfeld angesehen haben – was wäre wenn …
Um jede Änderung sauber betrachten zu können, Bemerkungen festzuhalten und auch eine Genehmigung von verantwortlicher Stelle zu dokumentieren, erhält sie eben einen eigenen “Change Record” im System. Gleiches gilt bei Reparaturaufträgen an externe Firmen: Jede Reparatur wird auch dort eigens gehandhabt, diese Vorgehensweise nutzen wir auch hier.
Mit diesen drei Prozessen gehen wir also an den Start, um uns ((OTRS)) Community Edition anzusehen. Doch alle drei Prozesse werden erst so richtig “rund”, wenn sie mit aktuellen Informationen beschickt werden: Hier kommt i-doit ins Spiel.
Wann i-doit, wann ((OTRS)) Community Edition?
Um herauszufinden, mit welchem Tool man was machen kann oder soll, müssen wir uns den eigentlichen Zweck der beiden Softwaretitel ansehen. Zusammengefasst: Bei i-doit liegen die Schwerpunkte in der flexiblen und individuell anpassbaren Dokumentation und bei ((OTRS)) Community Edition in der individuellen Gestaltung der Prozesse.
Der Schwerpunkt von ((OTRS)) Community Edition, das seit 2002 verfügbar ist, liegt in der Abbildung von Prozessen. Die oben beschriebenen Standardprozesse kommen in jeder IT-Organisation vor, nichtsdestotrotz hat jede Organisation ihre Spezialitäten. Halten wir uns vor Augen, dass das Werkzeug auch von großen IT-Organisationen eingesetzt wird, wo beispielsweise mehrere Help Desk Agents im 1st Level Support Anwenderfragen lösen und technische Incidents in Form von Tickets an den 2nd Level weiterleiten, wird schnell klar, wo Flexibilität gefordert ist: Bei der Anpassung eben dieser Standardprozesse an den Bedarf des eigenen Unternehmens. Das kann ((OTRS)) Community Edition, dafür wurde die Software geschrieben.
Überschneidung mit i-doit: Ebenso gibt es in ((OTRS)) Community Edition eine integrierte Asset-Verwaltung, die einfache Anwendungsfälle wie Seriennummern- und Standortverwaltung von Geräten ermöglicht.
Der Schwerpunkt von i-doit ist das Dokumentieren in allen Facetten. Die Software ist 2004 aus konkretem Praxisbedarf entstanden und wird stetig mit Praxisbezug weiterentwickelt. Im Vordergrund steht natürlich die IT Infrastruktur mit all ihren Komponenten, egal ob physisch oder virtuell. Der gesamte Lebenszyklus kann dokumentiert werden, dazu kommen Relationen, Services, Applikationen und weitere, gut 120 vorgefertigte Objekttypen bis zum Kabel. Der Anwender hat vollkommene Flexibilität beim selbst Erstellen zusätzlicher Attribute und sogar eigener Objekttypen, sodass er im Prinzip auch seinen Fuhrpark, Bleistifte oder Satelliten dokumentieren kann.
Überschneidung mit ((OTRS)) Community Edition: i-doit bringt auch eine rudimentäre Möglichkeit der Prozessabbildung mit, hier “Workflows” genannt.
Das Aufeinandertreffen der beiden Tools
Bleiben wir beim Incident Prozess und sehen uns an, wann der Prozess Zugriff auf die Information einer CMDB benötigt. Dazu nehmen wir einen Standardfall aus dem IT Support als Beispiel:
Der Incident
Ein Anwender meldet sich beim Service Desk und meldet eine Druckerstörung. Der Service Desk Mitarbeiter im 1st Level nimmt die Daten des Anwenders in ((OTRS)) Community Edition auf, ebenso jene des Druckers. Beides wird im Ticket vermerkt. Der Druckername wird als Link zur i-doit CMDB hinzugefügt.
Der Workaround
Durch Recherche in der Dokumentation wird einerseits der aktuelle Status festgestellt. Dieser lautet noch “in Betrieb”, es ist also noch keine Störung gemeldet worden. Die Zugangsinformation zum Drucker wird ausgehoben und der Fehler verifiziert. Nachdem mit dem Anwender geklärt wurde, dass es sich anscheinend um einen nicht durch den Anwender behebbaren Fehler handelt, wird das Druckerobjekt in i-doit als “Defekt” gekennzeichnet. Nun wird ein funktionierender Drucker als Alternative gesucht. Dazu wird die Standortinformation in i-doit verwendet und weitere verfügbare Drucker gesucht. Die Daten des alternativen Druckers werden dem Anwender direkt am Telefon mitgeteilt. Damit kann das Incident Ticket mit Workaround geschlossen werden, denn der Anwender kann wieder drucken.
Der Change Request bzw. Reparaturauftrag
Ein Change Request in ((OTRS)) Community Edition wird eröffnet, sowohl das i-doit Objekt als auch der ursprüngliche Incident werden mit dem Ticket verbunden, und als Empfänger dieses nun zum Reparaturauftrag mutierten Tickets wird die Wartungsfirma eingetragen. Die automatisch versandte Nachricht an den Service Provider enthält alle notwendigen Daten, um den Drucker zu finden (Druckername, Modell, Seriennummer, Stockwerksangabe, genauer Standort, lokaler Ansprechpartner), dazu auch den aktuellen Zählerstand, der online abgefragt wird, und natürlich Ticketnummer und Ansprechpartner im Service Desk. Der Vollständigkeit halber wird in der CMDB der Status des Druckerobjekts auf “In Reparatur” gesetzt – das zeigt allen KollegInnen, dass keine weitere Recherche oder Aktion erforderlich ist.
Problem Management
Nun beginnt die Arbeit, um die Reparatur des Druckers durchzuführen. Eine kurze Recherche durch Aufruf der Druckerseite (dazu hilft uns wieder die Integration von i-doit und ((OTRS)) Community Edition) und der Homepage des Herstellers beschreibt den Fehler, daher wird auf das Anlegen eines Problem Tickets verzichtet – es ist keine aufwendige Recherche nötig.
Weitergehende Informationen über Servicevertrag oder Ansprechpartner werden der Dokumentation in i-doit entnommen. Da ein aktueller Servicevertrag besteht, kann direkt mit dem Servicepartner per e-Mail kommuniziert werden. Meist ist eine Reparatur binnen 5 Arbeitstagen vertraglich zugesichert.
Die Vermeidung weiterer Unterbrechungen
Um nun weitere Anwender über die bereits beauftragte Reparatur zu informieren, soll diese allgemein zugänglich kenntlich gemacht und die alternativen Drucker mitgeteilt werden. Ziel ist auch hier wieder: Möglichst wenig Arbeitsunterbrechung für Anwender. Dazu wird der Störungsfall als PDF ausgedruckt und der Standort von alternativen Druckern beigefügt. Dieses Dokument sendet der Service Desk Mitarbeiter dem Einmelder des Incidents per e- Mail zu, mit der Bitte, diesen am Drucker gut sichtbar anzubringen.
Das Nachvollziehen in der CMDB
Fragen Anwender am Service Desk nach dem aktuellen Status der Reparatur, oder meldet sich der Wartungstechniker mit Neuigkeiten, muss nurmehr der Druckername, der allen Beteiligten Personen bekannt ist, genannt werden. Über den Einstieg in die CMDB findet man einerseits den Status “In Reparatur”, als auch den noch offenen Change Request in ((OTRS)) Community Edition mit allen Informationen und der nachvollziehbaren Geschichte des Servicefalls.
Information über erfolgte Reparatur
Nachdem der Drucker repariert wurde, wird der Change Request geschlossen und der Status des i-doit Objektes wieder auf “in Betrieb gesetzt”.
Weitergedacht: Livedaten aus dem Monitoring
Liegt die Ursache in der Infrastruktur, wird diese zumeist von einem Monitoringsystem festgestellt. Hier können mit einer weiteren Kopplung viele Arbeitsschritte eingespart werden:
Nicht die Störung, die vom Anwender gemeldet wird, löst das erste Ticket aus, vielmehr wird automatisch ein Ticket aus dem Monitoringsystem eröffnet. So kann ein Techniker bereits an der Störung arbeiten, bevor ein Anwender überhaupt merkt, was los ist.
Ebenso ist die Kopplung von Ticketsystem und CMDB vorteilhaft: Der Status wird an das entsprechende Objekt in der CMDB weitergegeben, damit können sowohl die Auswirkung einer Störung, als auch Alternativen frühzeitig überblickt werden.
Ebenso werden Änderungen an Systemen erkannt und in die IT-Dokumentation übernommen. Dies kann z.B. die Änderung einer IP-Adresse, eines Hostnames oder neue installierte Komponenten wie Software, CPU, Arbeitsspeicher oder Festplatten sein.
Die Post-((OTRS)) Community Edition-Ära: OTOBO
OTOBO ist eine OpenSource HelpDesk Software, die auf der ((OTRS)) Community Edition basiert. Es verfügt neben einem Kundenportal, über das Kunden neue Tickets erstellen können, auch über ein Backend für Agenten. Dort können Tickets von den zuständigen Mitarbeitern wie gewohnt erstellt, bearbeitet und abgeschlossen werden.
Pattrick Bluhm
