ITIL - kompakt und verständlich (Handbuch für ITIL-Helden)

Übersicht


1. Einleitung

Was können Sie von diesem Whitepaper erwarten?
Dieses Whitepaper beabsichtigt, Ihnen ITIL näher zu bringen und zwar ohne, dass Sie vor lauter Fachbegriffen die Orientierung verlieren. Ich beginne mit den ITIL Basics, fokussiere mich hierbei (aber) mehr auf die ITIL-Implementierung. Also keine Panik, sollten Sie sich gerade mit ITIL auseinandersetzen müssen, ist dieses Whitepaper so einfach geschrieben, dass jeder, sofern er über IT- Basiswissen verfügt, es leicht verstehen kann.

Der Lösungsvorschlag zu ITIL von ManageEngine
Die Mehrzahl der ITIL-Lösungen auf dem Markt sind zu komplex. Hierzu ein Beispiel. Ein Kunde möchte eine ITIL-Lösung implementieren. Zunächst braucht er das ITIL-Consulting, um die ITIL-Prozesse zu definieren und diese auf seine Geschäftsziele abzustimmen. Im Anschluss daran muss er eine ITIL-Software kaufen. Die meisten ITIL-Lösungen bieten Incident-, Problem- und Change-Management als unterschiedliche, nicht zusammenhängende Module an. Auch nach Auswahl der Software dauert es so noch Monate für die Produktconsultants bis die Prozesse implementiert sind. Aufgrund der Kosten und des Zeitfaktors ist eine ITIL-Lösung für KMUs nicht erschwinglich.

Die Mission von ManageEngine ist, ITIL so einfach zu machen, dass jedes Unternehmen von ITIL profitieren kann. ManageEngine automatisiert den ITIL-Service-Support ohne teure Consultants oder Folgekosten für das Customizing zu generieren. Sobald Sie das Produkt installiert haben, erhalten Sie ein ITIL-Service-Support-Framework mit Incident-, Problem-, Change- und Release-Management basierend auf einer CMDB. Sie können ab dem 1. Tag produktiv gehen, da nur minimalste Konfigurationen notwendig sind.

2. ITIL-Fakten

Was ist ITIL? Fakten, aber kein historischer Abriss
Eine kurze Einleitung in das Thema muss ich trotzdem vorweg schicken. ITIL ist ein Rahmenwerk (Framework) mit Best Practises für das optimale Management und die Services eines IT-Betriebes. Erstellt wurde dieses Framework Mitte der 80er Jahre durch das Government of Commerce in Großbritannien. Das oberste Ziel von ITIL ist es, die IT auf den Geschäftsbetrieb abzustimmen, so dass Unternehmen genau die Teile implementieren können, die für ihren Geschäftsbetrieb relevant und wichtig sind. ITIL ist das dokumentierte Wissen aus der jahrelangen Erfahrung von Helpdesk-Managern auf der ganzen Welt. Hier steht, was Sie wirklich wissen müssen:

Fakten in Kürze Was heißt das?
ITIL ist kein Standard. Es sind gute Ratschläge von IT Managern. Sie entscheiden, ob Sie diese umsetzen oder nicht. Sie können ITIL so implementieren, wie es für Ihr Unternehmen am besten ist.
Sie können Ihr Unternehmen nicht ITIL zertifizieren lassen. Sollten Sie eine Zertifizierung anstreben, müssen Sie sich nach ISO 20000 und BS 15000 basierend auf ITIL zertifizieren.
Es gibt keine ITIL-kompatiblen Produkte. Niemand kann Produkte als ITIL-kompatibel zertifizieren lassen. Gewöhnlich wird auf die Zertifizierung PinkElephant verwiesen.
ITIL ist für kleine, mittlere und große Unternehmen. Das ist richtig. Jeder kann ITIL implementieren. Sinn macht es ab einer Helpdesk-Mitarbeitergröße von 5.
ITIL stammt nicht von einem einzigen Unternehmen oder einer einzigen Person. ITIL wird von keinem einzigen Unternehmen finanziert. Es gibt keine Gewinnabsichten oder persönliche Werbung.

ITIL handelt nicht von komplizierten Prozessen
Unter ITIL versteht man keine strikten Prozesspläne. Sie sollten auch nicht dem Prozess eines anderen folgen oder den in Büchern definierten Prozessen. Wenn Sie ITIL umsetzen möchten, machen Sie keine detaillierten Prozesspläne für alle Module, die Sie dann an Consultants weiter reichen, um diese zu befragen, ob diese mit den ITIL-Spezifikationen übereinstimmen. Die Wahrheit ist, dass Consultants Ihnen nicht helfen können, wenn diese nicht verstehen, wie Ihr Support strukturiert ist und funktioniert.

ITIL-Service-Support ist unser Fokus
Heutzutage ist ein IT-Helpdesk fester Bestandteil eines jeden Business - egal ob dieses klein oder groß ist. Das erklärte Ziel eines jeden IT- und Helpdesk-Managers ist es, einen effizienten und produktiven Helpdesk zu haben. Wir werden uns auf dieses Problem fokussieren. Da der ITIL-Service-Support ein Regelwerk mit Best Practises für den IT-Helpdesk bietet, richten wir unser Augenmerk darauf, wie ITIL den Helpdesk-Manager und IT-Manager unterstützen kann. Das IT-Service-Support Modul von ITIL bietet Best Practises für einen ständig verfügbaren IT-Support. ManageEngine ServiceDesk Plus Enterprise Edition integriert eben diese IT-Service-Support-Module.

3. Incident-Management

Unter einem Incident versteht man die Störung des normalen Service, der den Benutzer oder das Business beeinträchtigt. Ziel von Incident-Management ist, den IT-Service so schnell wie möglich wieder in den ursprünglichen Zustand zu versetzen - mit Workarounds oder Lösungen, die sicherstellen, dass der Geschäftsbetrieb nicht beeinträchtigt wird. Ein Incident ist ein Ereignis, das nicht Teil des Standardbetriebs ist und das Sie nach Möglichkeit vermeiden wollen. Einfach gesagt: Incident-Management ist ein Prozess, um Störungen zu verwalten und den IT-Service wieder in den ursprünglichen Zustand zu versetzen.

Das mag sich zu schön anhören, um wahr zu sein. Aber Incident-Management zeigt Ihnen, wie Sie Ihren IT-Helpdesk einrichten müssen, damit dieser Ihre Geschäftsprioritäten kennt und konsequent umsetzt. Incident-Management zeigt, wie nützlich Prozesse sind, die in der Lage sind, Ihren Service wiederherzustellen. Das Servicedesk ist sozusagen der Klebstoff, der die Service-Support-Module zusammenhält - mit einem Single Point of Contact zum Enduser. Er stellt sicher, dass der IT-Service das Business im Fokus hat.

Erfassen der wichtigen User-Details
Falls der User nach einem neuen Service fragt: NEW Service Request

  • Bringen Sie Ihren Helpdesk-Analysten bei, sich wieder beim Benutzer zu melden, wenn er nach einem neuen Service gefragt hat
  • Schulen Sie sie, damit Sie Details von Requests mit Dringlichkeit und Priorität versehen
  • Schulen Sie das Helpdesk-Team, nach neuen Serviceplänen und Meilensteinen zu suchen
  • Schulen Sie sie, wo sie nach Antworten für FAQs suchen können

Wird ein Ausfall oder eine Störung gemeldet: INCIDENT

  • Entscheiden Sie, ob es sich um einen Incident handelt oder nicht
  • Überprüfen Sie, ob Sie mit einer Lösung aus der Knowledgebase helfen können
  • Weisen Sie den Incident einem Spezialisten aus der Supportgruppe zu
  • Arbeiten Sie eng mit den Spezialisten der Support-Gruppe zusammen, um dem User eine Lösung bieten zu können
  • Schließen Sie den Incident mit Bestätigung des Users

Hier ist ein Beispiel eines Incident-Management-Workflows. Betrachten Sie ihn als ein Grundformat und machen Sie Änderungen, falls nötig.

Incident-Management-Workflow

4. Problem-Management

Das Ziel des Problem-Managements ist es, die Urasache des Incidents zu finden und den Einfluss auf den Geschäftsbetrieb zu reduzieren. Problem-Management ist ein proaktiver Ansatz, der das Wiederauftreten der Incidents verhindern soll.

Problem-Management gibt Ihrem Helpdesk eine Strategie: es hilft Ihnen, vom Modus des Brändelöschens in einen proaktiven Modus zu wechseln. Mit einfachen Worten, die Störungen, die von den Usern wahrgenommen werden, sind oft unterschiedliche Instanzen eines Problems. Wenn Sie die Wurzel aller Incidents finden und diese beheben, verhindern Sie damit weitere künftige Incidents.

Problem-Management-Workflow

Aufnahme und Suche nach bekanntem Fehler in der Datenbank
Ein Problem kann direkt oder durch die Kombination von einem oder mehreren Incidents gemeldet werden. Sobald das Problem erfasst ist, überprüft der Techniker, ob es schon einmal gemeldet wurde und ob es dafür bereits einen Workaround oder eine Lösung gibt.

Probleme mit Workaround / Lösung: Bekannter Fehler
Falls es für das gemeldete Problem einen Workaround oder eine Lösung gibt, handelt es sich um einen bekannten Fehler. Der Helpdesk-Mitarbeiter kontaktiert den Nutzer und liefert diesem den Workaround oder die Lösung. Der Techniker vermerkt, dass das Problem aufgetreten ist und erhöht die Anzahl des Problemzählers, um die Häufigkeit des Problems zu messen.

Problemklassifizierung, um richtige Priorität festzulegen
Es ist wichtig, das Problem nach folgenden Kriterien zu klassifizieren:

  • Kategorie, Unterkategorie und Begriff
  • Beeinträchtigung des Businesses und Dringlichkeit

Die Klassifizierung hilft dem Techniker, dem Problem die richtige Priorität zuzuweisen.

Problemanalyse zur Ursachenforschung
Sobald das Problem klassifiziert ist, bekommt der Techniker ein genaues Bild, womit eranfangen soll. Abhängig davon, ob das Problem am Arbeitsplatz des Users auftritt oder am Proxy-Server oder an der Firewall, nutzen Techniker unterschiedliche Tools zur Diagnose. Der Techniker vermerkt alle Merkmale und die Ursache des Problems zusammen mit einem Workaround oder der Lösung.

Lösung anbieten oder einen Request for Change initiieren
Der Techniker wendet sich wieder an den User, falls es bereits eine verfügbare Lösung gibt. Falls für das Problem einige Änderungen am System notwendig sind, können Sie einen Workaround anbieten und einen Request for Change initiieren. Ein Beispiel: Eine Gruppe von Usern kann nicht auf das Internet zugreifen, die Ursache ist die Firewall. Die Techniker können den Usern einen Workaround anbieten, um auf das Internet zuzugreifen. Darüber hinaus veranlassen sie einen Change Request, damit die Internetverfügbarkeit in Zukunft gewährleistet ist.

Problem schließen
Auch wenn der Techniker das Problem löst, ist es die Aufgabe der Helpdesk-Mitarbeiter, die User über alle Aktivitäten zu informieren. Haben die User einen Single Point of Contact, müssen sie die Angelegenheit nicht ständig bei unterschiedlichen Ansprechpartnern wiederholen. Darüber hinaus stellen die Mitarbeiter sicher, dass die Lösung auch exakt den Anforderungen des Users entspricht.

5. Change-Management

Der Change-Management-Prozess hilft Ihnen, die Veränderungen (Changes) mit minimalen Beeinträchtigungen und Risiken zu koordinieren.

Die meisten kleinen Unternehmen befürchten, dass Change-Management zu beherrschend ist und dass sich ein Change nicht rasch genug implementieren lässt, wenn man einen sehr langwierigen Prozess hat. Change-Management ist nicht kompliziert, es sei denn, Sie machen es kompliziert. Es geht darum, einen einfachen Plan zu entwerfen, um überraschende Ausfälle zu vermeiden.

Meiner Meinung nach braucht jedes Unternehmen Change-Management. Es unterstützt die IT-Manager und das IT-Personal, die Geschäftsführung und Aktionäre zu informieren, sobald ein Change notwendig ist. Sobald alle von der Geschäftsführung bis zum IT-Personal von der Entscheidung bis zur Einführung involviert sind, bleibt kein Raum für unvorhergesehene Überraschungen.

Warum haben wir Change-Management eingeführt?
Unser Einstellungsverfahren für einen Berufseinsteiger setzt sich aus zwei Teilen zusammen: Eignungstest und persönliche Interviews. Der User muss sich in unsere Testumgebung "Zoho Challenge" einloggen, das auf einem Windows-Server läuft. Wie an jedem Tag gab es einen neuen Test, unser HR-Team war bereit, sich die Bewerber anzusehen.

Der Server war down und somit auch unser Testsystem. Und ….ich sag Ihnen…es war eine Blamage.

Als wir die Sache überprüften, fanden wir heraus, dass unser Helpdesk-Team die neuesten Security-Patches eingespielt hatte und das System dann nicht mehr startete. Es stellte sich heraus, dass es nicht komplett die Schuld des Helpdesk war, da ihre Anweisung lautete, dass sie die neuesten Patches auf alle Server verteilen müssen.

Eine kleine Lücke in der Kommunikation, aber eine große Blamage.

Was wir daraus gelernt haben:
Wir hatten keine Methode, dem Personalwesen, ein Systemupdate mitzuteilen. Falls sie informiert gewesen wären, hätten sie den Test zu einem späteren Zeitpunkt einplanen können bzw. bei einem wichtigen Test hätte das Update später gemacht werden können. Ergebnis: Wir haben Change-Management eingeführt.

Implementieren Sie ein Change-Management-System ohne Komplikationen und mit der nötigen Freiheit.

Hier ist ein einfacher und effektiver Change-Management-Prozess, der einen vernünftigen Plan mit ITIL verbindet:

Vernünftiger Plan ITIL Plan
Formulieren Sie einen gut definierten Plan Request for Change
Der Change Plan sollte beinhalten
Definieren Sie Ihren vorgeschlagenen Change Rollout Plan
Wie komplex ist der Change: Groß/Klein/Regulär Rückzugsplan
Wann und wie planen Sie, diesen Change auszurollen Abschätzung des Einflusses auf das Business
Ist Ihr Business bei der Implementierung des Changes betroffen? Checkliste der Abhängigkeiten
Falls Ihr Change-Plan versagt, werden Sie den letzten guten Zustand wiederherstellen
Machen Sie eine Checkliste für alle verfügbaren Dinge
Identifizieren und erhalten Sie das Buy-in aller Beteiligten, die von dem Change betroffen sein könnten Change Advisory Board
Priorisieren und planen Sie den Change Vorausplanung der Changes
Testen Sie den Change in der Sandkiste und implementieren Sie ihn Release Management
Wie lief der Change? Sprechen Sie über die Pannen und verbessern Sie Ihren Plan für das nächste Mal Post Implementation Betrachtung

Großen Unternehmen, die einen kontrolliertes Change-Management für ihre Projekte wünschen, empfehle ich folgende Seite: www.PRINCE2.com

Ein einfacher Workflow basierend auf diesen Fragen hilft Ihnen bei der Erstellung eines effektiven Change-Management-Prozesses.

6. Release-Management

Das Ziel von Release-Management ist, den Change zu planen, die User zu informieren und Änderungen reibungslos einzuführen.

Das Release-Management arbeitet eng mit dem Change-Management zusammen. Das Change-Management ist verantwortlich für die Planung, während das Release-Management für die Ausführung / Einführung zuständig ist.

Nehmen wir ein Beispiel aus unserem täglichen Leben. Bei einer wichtigen Kanalarbeit auf einer stark befahrenen Straße kann der Verkehr nicht sofort gestoppt werden. Die Behören informieren die Pendler in Tageszeigungen, Anzeigen, Radiomeldungen, dass die Straße an einem bestimmten Tag gesperrt sein wird und welche Alternative vorgesehen ist. Die Pendler können nun vorausplanen und es gibt keine Enttäuschungen und die Arbeiten (Changes) können reibungslos ablaufen.

Das ist Release-Management in Aktion.

Aus Sicht der IT hilft Release-Management, Changes an Ihrer IT reibungslos zu implementieren.

  • Ein Release-Plan mit Informationen, wie etwas umgesetzt wird, wann es umgesetzt wird und die Spezifikationen, wie es abläuft
  • Der Build/Change wurde gründlich in einer Testumgebung getestet, die den Echtzeitbedingungen entspricht
  • Die Konfiguration vor dem Change wurde festgehalten
  • Release und Distribution sind geplant
  • Verifizieren und testen, ob die gewünschten Veränderungen eingetreten sind

7. Configuration Management Database (CMDB)

Das Ziel der CMDB besteht darin, eine Datenbank mit dem Inventar an Hardware, Software, Dokumenten und ihren Beziehungen aufzubauen.

Die Hauptidee hinter der CMDB ist ein Inventardepot aufzubauen, das leicht identifiziert, kontrolliert und verwaltet werden kann.

Was muss eine CMDB enthalten?

Die CMDB sollte alle Informationen zu allen kritischen Komponenten des Businesses beinhalten

  • Menschen: User-Name, Abteilung, Standort und so weiter
  • Inventar: Alle geschäftsrelevanten Assets, wie Workstations, Desktops, Router und Drucker
  • Software: Alle gekauften Software-Programme Ihres Unternehmens

Die Assets (Inventar) und die Komponenten in der CMDB sind bekannt und sog. Configured Items (CIs).

Zitat von Fedex: „Informationen über ein Paket sind genauso wichtig wie das Paket selbst“ – Mike Glenn, Fedex (Aus dem Englischen)

Wo soll ich anfangen?
Zunächst brauchen Sie einen Plan. Hier sind ein paar Vorschläge, die Ihnen helfen, einen Entwurf zu erstellen:

Planen Sie brauchen eine klare Vorstellung über
  • Warum brauchen Sie eine CMDB?
  • Was wollen Sie damit erreichen?
  • Wer kontrolliert und verwaltet?
  • Welche Arbeitsschritte müssen eingehalten werden?
Identifizieren Assets/CIs müssen einzigartig definiert werden können. Sie brauchen also ein System, das
  • ein Muster für Labelnamen definiert
  • einen Identifikator, der leicht lokalisiert und Versionsnummern
  • ein System, das Zuständigkeiten der CIs und die Verbindung mit anderen CIs definiert
Kontrollieren Stellen Sie eine kontrollierte Umgebung Ihrer CIs sicher, damit CIs nur aufgrund eines seziellen Prozederes hinzugefügt werden können. Das Ziel der CMDB besteht darin, eine Datenbank mit dem Inventar an Hardware, Software, Dokumenten und ihren Beziehungen aufzubauen. Sie müssen nicht Ihr komplettes Inventar (Assets) in der CMDB haben; Sie können sich auf die für Ihr Business wichtigen CIs beschränken.
Life-Cycle-Management-Status Ihres Inventars Es ist wichtig, das Inventar (Assets) während seines Lebenszyklus zu überwachen. Das Inventar kann sich in Wartung, Reparatur oder in einer Live-Umgebung befinden. Reports über Asset Life Cycle können sehr hilfreich sein, um Aufschluß über Wartung und Abhängigkeiten zu erhalten.
Prüfen und Verifizieren Die CMDB ist keine einmalige Sache. Sie sollten von Zeit zu Zeit Audits durchführen, um sicher zu gehen, dass Ihre CMDB Ihre Live-Umgebung widerspiegelt. Wenn Sie keinen regelmäßigen Abgleich machen, ist Ihre CMDB nur ein Mythos.

Die Seele einer CMDB verstehen
Denken Sie daran, das Ziel einer CMDB ist es, ein Depot/Speicher Ihrer Vermögensgegenstände (Asset) mit allen Informationen zu Ihren Assets aufzubauen. Ein Speicher Ihrer Vermögensgegenstände kann logisch und verteilt aufgesetzt sein. Eine CMDB aufzubauen heisst nicht, dass Sie alles in einer großen physikalischen Datenbank haben.

Eine umfassende Software-Bibliothek (Software Libary SL)
Aufgrund von quartalsweisen Software-Releases und wöchentlichen Sicherheits-Patches ist es notwendig, die Kopien der einzelnen Software-Releases in die Live-Umgebung zu integrieren. Sollte einer Ihrer Server crashen und Sie haben zwar die Versionsnummer, aber nicht die Software dieser Version, können Sie Schwierigkeiten bekommen.

Sie sollten über eine Basiskonfiguration verfügen
Eine Basiskonfiguration ist eine Momentaufnahme Ihrer CMDB. In jeder IT-Umgebung gibt es zahlreiche Systeme mit unterschiedlichen Konfigurationen, Software, Speicher, Prozessoren und anderem. Bei dieser Vielzahl an Variablen müssen Sie sicherstellen, dass Sie bei einer Änderung alle Versionen unterstützen, sonst könnte es schnell Schwierigkeiten geben. Die IT-Verantwortlichen müssen die Anzahl der Variablen planen und reduzieren, damit sie unter Kontrolle bleiben.

Sie könnten ein stabiles Betriebssystem und eine Browser-Version als Standard setzen, um sicherzustellen, dass alle über eine optimale Basiskonfiguration verfügen. Ein Beispiel: Sie könnten z. B. folgende Parameter als Basiskonfiguration für alle Geschäftsapplikationen vorschreiben

  • Standard Betriebssystem – Windows XPRAM – 1 GB
  • Prozessor Intel Mobile Centrino
  • Unterstützter Browser – IE 7

Erstellen Sie nun eine Liste mit Nutzern, die diese Anforderungen erfüllen bzw. nicht erfüllen. Nutzer, die die Anforderungen nicht erfüllen, müssen auf das Basisniveau gebracht werden, so dass Problemlösungen bzw. Fixes für alle Nutzer verfügbar und nutzbar sind.

8. Implementierung eines ITIL-Service-Support mit ServiceDesk Plus

ITIL-Service-Support und ServiceDesk Plus
Mit ServiceDesk Plus haben Sie das komplette ITIL-Service-Support-Rahmenwerk mit Incident-, Problem-, Change- und Release-Management mit einer CMDB. Sobald Sie ServiceDesk Plus installieren, sehen Sie alle Module.

ServiceDesk Plus aus dem Effeff installieren
Die Installation von ServiceDesk Plus ist einfach und unkompliziert. Es lässt sich auf einem Windows-Server / Workstation oder Linux-Server / Workstation installieren. Eine Datenbank-Konfiguration oder ein Webserver wird nicht benötigt. Es enthält eine MySQL-Datenbank und einen Apache-Tomcat-Server, die sich automatisch bei der Installation konfigurieren. Folgen Sie dem Installations-Wizard und sobald Sie auf "Finish" klicken, sind Sie fertig.

Probieren Sie aus, wie einfach die Installation ist. Laden Sie eine 30-Tage-Testversion von unserer Webseite herunter. Nach der Installation starten Sie Ihren Webclient und Sie sehen ServiceDesk Plus in Aktion…. Tada.

9. Anlegen und Import von Benutzerinformationen

Um zu sehen, wie ServiceDesk Plus den ITIL-Service-Support-Prozess abbildet, brauchen wir ein paar User, Anfragen und Assets (Vermögensgegenstände). Sehen Sie nun, wie schnell wir sie ins System bekommen.

Nehmen Sie die User auf
Importieren Sie die User aus dem Active Directory

ServiceDesk Plus lässt sich mit dem Active Directory integrieren und unterstützt Sie beim Import der User. Um die Demo einfach zu machen, wählen Sie nur eine Organisationsgruppe (Organisational Unit – OU) aus und importieren Sie die Benutzer.

Admin > User > Active Directory

Sie haben kein Active Directory?
Wenn Sie kein Active Directory haben, können Sie die User auch über eine CSV-Datei importieren oder ein paar manuell anlegen.

Konfigurieren Sie die E-Mails, um Anfragen zu erhalten
Wir empfehlen immer auf einem Testsystem zu arbeiten, damit Sie Ihre Live-Umgebung nicht beeinträchtigen.

  • Erstellen Sie einen Demo-E-Mail-Account auf Ihrem Mailserver
  • Um Anfragen zu erhalten, müssen Sie die Mailserver-Settings unter dem Admin-Tab konfigurieren
  • Spezifizieren Sie die E-Mail-Adresse, die Sie gerade erstellt haben demo@IhreDomaine.de und den Usernamen
  • Wählen Sie das Protokoll im E-Mail-Typ aus

Danach senden Sie eine E-Mail oder fragen Sie einen User, eine E-Mail zu senden. Sie sehen, dass die E-Mail abgerufen wird und zu einer Anfrage konvertiert wird.

Bitte beachten Sie, dass E-Mails, die von ServiceDesk Plus abgerufen werden, vom Mailserver gelöscht werden. Sie wurden gewarnt!

10. Vermögensgegenstände scannen und in das Inventar aufnehmen

Mit ServiceDesk Plus können Sie all Ihre IT-Vermögensgegenstände (IT Assets) und Nicht-IT-Vermögensgegenstände (Non-IT Assets) aufnehmen.

Diese IT-Assets können Sie scannen

  • Alle Workstations und Server – Windows, Linux, Apple Macs und HP Thin Clients
  • Netzwerkgeräte – Drucker, Router, Switche und Access Points (und die meisten Geräte mit einer IP-Adresse)

Mit dem Windows Domain Scan erhalten Sie alle Windows-Workstations und -Server und mit dem Netzwerk-Scan können Sie alle Linux-Server, Linux-Workstations, Apple Macs sowie alle Netzwerkgeräte erkennen. Es müssen keine Agenten installiert werden. Der Windows-Scan arbeitet mit WMI, um sich mit den Workstations / Server zu verbinden. Der Network-Scan arbeitet mit SSH, um Linux und Apple Macs zu scannen und SNMP für alle Netzwerkgeräte.

11. Incident Management

Der Incident-Workfow in ServiceDesk Plus

  • Incident erkennen
  • Incident-Details aufnehmen
  • Einordnen des Incidents
  • Workaround oder Lösung anbieten
  • Eskalation / Neue Probleme einordnen oder mit existierenden Problemen verknüpfen
  • Incident schließen

Schritt 1: Incident erkennen
Sobald eine Anfrage hereinkommt, hilft Ihnen ServiceDesk Plus den Anfragetyp zu definieren. Meldet die Anfrage einen Ausfall oder eine Qualitätsverschlechterung eines Services, dann handelt es sich um einen Incident. Handelt es sich bei der Anfrage um einen neuen Service-Wunsch, wird er als New Service Request eingeordnet.

Schritt 2: Incident-Details aufnehmen

Sobald ein Incident erkannt wurde, ist es wichtig, dass der Helpdesk-Mitarbeiter den Incident qualifiziert. Durch die richtige Fragetechnik können die Helpdesk-Mitarbeiter den Incident qualifizieren, damit die Level-2-Techniker das Problem schneller lösen können. ServiceDesk Plus hilft Ihnen dabei, die Incident-Details aufzunehmen.

Definieren Sie eine Prioritätenmatrix
Die Prioritätenmatrix hilft Ihnen, die richtige Priorität entsprechend dem Einfluß auf das Business und deren Dringlichkeit zu vergeben. Der Helpdesk-Manager kann das einmalig konfigurieren und ServiceDesk Plus vergibt dann automatisch die richtige Priorität – das ist eine der ITIL Incident Management Best Practises. ServiceDesk Plus ist jedoch flexibel genug, dass von der Prioritätenmatrix abgewichen werden kann und der Techniker oder der User selbst die Priorität definieren kann (das würde ich aber nicht empfehlen).

Administrator > Helpdesk anpassen > Prioritäten Matrix

Schritt 3: Einordnen des Incidents
Der Helpdesk-Mitarbeiter kann einen Incident bereits während der Erstellung oder dem Update eines Users klassifizieren. Die Klassifizierung ist sehr wichtig, um den Grund aller Incidents zu verstehen.

Kategorie > Unterkategorie > Komponente

Schritt 4: Workaround oder Lösung anbieten
Die Helpdesk-Mitarbeiter können nach einem existierenden Workaround oder einer Lösung für die Anfrage suchen und dem User sofort antworten.

Schritt 5: Neue Probleme einordnen oder mit existierenden Problemen verknüpfen
Helpdesk-Techniker gruppieren ähnliche Incidents, die dieselbe Kategorie > Unterkategorie > Komponente haben und ordnen neue Probleme ein oder verknüpfen sie mit existierenden Problemen. Sobald ein Problem erstellt ist, übernimmt der Level-2-Techniker oder der Problemtechniker.

Schritt 6: Schließen des Incidents
Ein Incident sollte erst dann geschlossen werden, wenn der User bestätigt, dass die Lösung geholfen hat. Die Helpdesk-Mitarbeiter sollten dabei der Single Point of Contact sein und den User informiert halten, den Status überprüfen und sicherstellen, dass alle Incidents beantwortet werden und geschlossen werden. Es ist zwar ein sehr aufwendiger Prozeß, alle User zu einer Bestätigung zu bewegen, dass ein Incident geschlossen werden kann.

Erstellen Sie eine Policy und informieren Sie Ihre User darüber
Sie können definieren, dass der Helpdesk Probleme löst und antwortet. Die User müssen bestätigen, dass der Incident gelöst wurde. Falls der User nicht innerhalb von 10 Tagen antwortet, nehmen wir an, dass der User die Lösung akzeptiert hat.

ServiceDesk Plus hilft beim Schließen eines Incidents
Die Helpdesk-Mitarbeiter lösen die Incidents und ändern den Status der Anfrage auf gelöst. ServiceDesk Plus sendet eine E-Mail an den Anfragenden und fragt, ob die Lösung geholfen hat. Antwortet der User nicht innerhalb von 10 Tagen wird der Request automatisch auf geschlossen gesetzt.

12. Der Problem-Management-Workflow in ServiceDesk Plus

  • Problem erkennen und klassifizieren
  • Problem priorisieren
  • Problem analysieren
  • Lösungen, Workaround oder Bestätigung eines bekannten Fehlers
  • Problem schließen

Schritt 1: Problem erkennen und klassifizieren
Der Problemtechniker schaut nach der Herkunft des Incidents, basierend auf der Klassifizierung (Kategorie > Unterkategorie>Komponente). Reports über die 10 häufigsten Incidents hilft einzuordnen, was zuerst gelöst werden muss.

Schritt 2: Problem priorisieren

Je nach Dringlichkeit und Einfluss wird das Problem mit einer Priorität versehen. Damit können die Techniker die verschiedenen Probleme priorisieren und die notwendigen Aktionen veranlassen, wobei die kritischen Probleme zuerst bearbeitet werden.

Schritt 3: Problem analysieren
Der Techniker kann die Ursache und den Einfluss des Problems analysieren und dies in ServiceDesk Plus vermerken. Somit sieht man auf einen Blick, was eine Ursache und mögliche Lösungen oder Workaround sein können.

Schritt 4: Lösungen, Workarounds oder Bestätigung eines bekannten Fehlers

Lösungen sind dauerhafte Fixes für ein Problem. Workarounds sind zeitlich begrenzte Lösungen, bis eine endgültige Lösung bereit steht. Optional können Sie auch Aufgaben vergeben, die erledigt werden müssen, um den Incident zu klären.

Schritt 5: Problem schließen
Techniker schließen ein Problem oft sehr schnell, aber Manager brauchen klare Reports, um die Struktur der Probleme zu analysieren. Die Schließregeln für Probleme erlauben es einem Techniker ein Problem nur dann zu schließen, sofern alle erforderlichen Felder ausgefüllt worden sind. Diese Regeln lassen sich im Admin > Problem/Change Management > Problem Closure Rules festlegen. Nur wenn die zwingend erforderlichen Felder komplett sind, kann das Problem geschlossen werden.

13. Change-Management-Workflow

  • Einen Request for Change initiieren
  • Change-Pläne und CAB (Change Advisory Board)
  • Zustimmung durch die CAB-Mitglieder
  • Koordination der Change-Implementierung
  • Review nach der Implementierung
  • Change-Historie

Einen Request for Change initiieren
Sie können einen NEUEN Change Request oder einen Change zu einem oder mehreren Problemen starten.Der Request for Change wird nach folgenden Gesichtspunkten betrachtet: Business Impact, Dringlichkeit und Priorität.

Der Change-Plan wird formuliert, um den Change-Prozess zu starten. Der Change-Plan muss die kompletten Details über die Gründe eines notwendigen Changes haben und warum dieser Change das Business beeinträchtigt. Der Change-Plan muss über folgende Informationen verfügen, damit der Change-Manager und das CAB über alle Details verfügen, um entsprechende Entscheidungen zu treffen.

  • Analyse des Einflusses – Risiko bei Implementierung des Changes
  • Rollout-Plan – wie wird der Plan implementiert
  • Ausstiegsplan – Plan, die Daten zum Originalzustand zurückzuspeichern, falls der Plan versagt
  • Checkliste – Liste an notwendigen Dingen, damit der Plan erfolgreich wird

Change-Pläne und CAB (Change Advisory Board)
ServiceDesk Plus verfügt über 4 verschiedene Typen von vordefinierten Change-Plänen

  • Standard Change
  • Geringfügiger Change
  • Größerer Change
  • Signifikanter Change

ServiceDesk Plus erlaubt Ihnen, eigene Change-Typen zu definieren und zu konfigurieren. Dafür stehen unterschiedliche Farben für die Schwere zur Verfügung.

Standard Change
Standard Changes sind bereits genehmigte Changes, die vom Change-Manager aufgrund der Management Policys autorisiert worden sind. Häufige Changes wie z. B. genehmigte RAM-Upgrades für User oder eine Liste mit erlaubter Software können durch den Change-Manager im Vorfeld genehmigt werden, so dass Changes schneller durchgeführt werden können.

Geringfügiger Change
Ein geringfügiger Change ist definiert als ein Change mit einem geringen Einfluss auf das Business und benötigt keine großen Ressourcen. Der Change-Manager genehmigt den geringfügigen Change.

Größerer und signifikanter Change
Größere und signifikante Changes benötigen die Genehmigung von allen Mitgliedern des Change Advisory Boards und des Change-Managers. Die Mitglieder des CAB (Change Advisory Boards) setzen sich aus Mitgliedern, die von diesem Change betroffen sind, zusammen. Auf Basis des Change-Plans und des damit verbundenen Risikos werden die CAB-Mitglieder entschieden, ob Sie den Change-Plan akzeptieren oder ablehnen.

Change Advisory Board
Mit ServiceDesk Plus können Sie ein CAB erstellen. Basierend auf den definierten Change-Typen können Sie wählen, den Change-Plan zur Genehmigung an die CAB-Mitglieder zu versenden. Es ist möglich, verschiedene CABs wie z. B. einen Notfall-CAB, einen technischen CAB usw. zu erstellen.

Genehmigung durch die CAB-Mitglieder
Die CAB-Mitglieder treffen sich einmal alle zwei Wochen oder einmal im Monat, um die angefragten Changes zu diskutieren. Basierend auf dem Change-Plan und den damit verbundenen Risiken treffen die CAB Mitglieder eine einstimmige Entscheidung, den Change-Plan zu akzeptieren oder zu verwerfen.

Die Change-Implementierung koordinieren
FSC (Forward Schedule of Change)

Alle genehmigten Changes müssen mit minimaler Beeinträchtigung des Services implementiert werden. ServiceDesk Plus verfügt über Standardreports zu Priorität, Dringlichkeit, Incident und Anzahl der Probleme, was den Change-Managern bei der Priorisierung und der Planung der Changes hilft.

Change-Kalender
Auf Basis der genehmigten Changes werden die Changes geplant und veröffentlicht. Der Change-Kalender informiert alle, wann und wie lange ein spezieller Service zwecks Wartung nicht verfügbar sein wird.

Implementierungen
Mit ServiceDesk Plus behalten Sie wichtige Aufgaben im Blick, wenn es darum geht, genehmigte Changes zu implementieren. Der Change-Manager kann Aufgaben an Techniker zu delegieren und den Stand nachvollziehen, inwieweit die Aufgaben erfüllt sind. Mit den Aufgaben hat der Change-Manager ein noch feineres Kontrollinstrument für die Implementierung von Changes.

Post-Analyse der Implementierung
Die Post-Analyse der Implementierung hilft dem Change-Manager, das Rollout der Changes zu beobachten:

  • Erkennen von Pannen während des Changes
  • Messen der Effizienz des Changes durch Vergleich der KPI (Key Performance Indicator)

Beobachten der Change-Historie
Da Change-Management das Kerngeschäft betrifft, ist es wichtig, eine klare Dokumentation über den Change zu erstellen. ServiceDesk Plus vollzieht die komplette Change-Historie nach. Damit lassen sich Change-Audits leichter durchführen und Sie erhalten alle notwendigen Informationen, wie z. B.: Wann wurde der Changeplan geändert, wann wurde er genehmigt, wer hat ihn genehmigt. Mit der Property View lassen sich alle Daten zu einem Change für Audit-Zwecke abrufen.

14. Configuration Management Database (CMDB)

Assets erkennen
ServiceDesk Plus unterstützt Sie dabei, alle IT-Assets wie Workstations (Windows, Linux und Apple Macs), Drucker, Router, Switche und Access Points zu erkennen. Sie erhalten alle Asset-Details in einer zentralen Stelle. ServiceDesk Plus hilft Ihnen, die Asset-IDs und Asset-Namen zu vergeben.

Detailliertes Bestandsinventar (Asset-Inventar)
Sie erhalten detaillierte Informationen wie Modelnummer, Status und detailierte Konfiguration des Inventars.

Software-Bibliothek
ServiceDesk Plus erkennt alle installierten Software-Programme in Ihrem Unternehmen und baut daraus eine Software-Bibliothek, um Lizenzen zu tracken. ServiceDesk Plus besitzt die Möglichkeit, einen Report zu erstellen, der zwischen gekaufter und installierter Software unterscheidet. Selten genutzte, gekaufte Software wird durch diesen Report identifiziert. Dies erleichtert Ihnen Ihr Software-Lizenzmanagement.

Beziehung der Assets
Sobald ein IT-Service ausfällt, sollten Sie sofort wissen, wie viele User davon betroffen sind. Mit ServiceDesk Plus können Sie die Beziehung zwischen Assets definieren und verwalten. ServiceDesk Plus bietet 3 Typen von Beziehungen, die Sie Ihren Assets zuweisen können.

  • Beziehung der Assets zueinander
  • Nutzungsbeziehung
  • Containerbeziehung
Mehr

Bringing IT together Seminar & Workshop

06.11.2018, München

  • IT Service Management
  • Unified Endpoint Management
  • Active Directory Management
  • IT Operations Management

ManageEngine - Support


MicroNova AG
Unterfeldring 6
85256 Vierkirchen

   +49 8139 9300-13
   Support-ManageEngine@micronova.de

» Anfahrtsplan