ITIL - kompakt und verständlich (Handbuch für ITIL-Helden)
ITIL (Information Technology Infrastructure Library) hat sich in der IT längst als Quasi-Standard für das IT Service Management (ITSM) etabliert. Damit Sie bei all den Fachbegriffen nicht den Überblick verlieren, haben wir die wichtigsten Basics rund um ITIL in diesem Handbuch für Sie zusammengefasst. Der Schwerpunkt liegt dabei auf der ITIL-Implementierung im IT-Helpdesk.
1. Was können Sie von diesem Handbuch erwarten?
Dieses Handbuch soll Ihnen ITIL (Information Technology Infrastructure Library) näherbringen – und zwar ohne, dass Sie vor lauter Fachbegriffen die Orientierung verlieren. Zunächst werden die ITIL-Basics für das IT-Service-Management (ITSM) vorgestellt, das Hauptaugenmerk liegt hierbei aber mehr auf der ITIL-Implementierung im IT-Helpdesk.
Also keine Panik, falls Sie sich gerade mit ITIL auseinandersetzen müssen:
Das Handbuch konzentriert sich auf das, was IT-Manager wirklich über ITIL wissen müssen und ist so einfach geschrieben, dass es jeder mit IT-Basiswissen verstehen kann.
Setzen Sie ITIL einfach um - mit ServiceDesk Plus
Unsere ITIL-fähige IT-Service-Management-Lösung ServiceDesk Plus bietet zahlreiche Features, mit denen Sie Ihren Anwendern einen erstklassigen IT-Support bieten können.
Der ITIL-Ansatz von ManageEngine
Der Großteil der ITIL-Lösungen auf dem Markt ist für das durchschnittliche Unternehmen zu komplex. Ein Beispiel: Ein Unternehmen möchte eine ITIL-Lösung implementieren. Dazu benötigt es zunächst ein ITIL-Consulting, um die Prozesse zu definieren und auf seine Geschäftsziele abzustimmen. Anschließend muss es sich für eine ITIL-Software entscheiden und auswählen, welche Module benötigt werden, da die meisten ITIL-Lösungen Incident-, Problem- und Change-Management separat anbieten. Nach der Auswahl der Software dauert es dann oft noch Monate, bis die Produkt-Consultants die Prozesse implementiert haben. Der hohe Zeitaufwand und die mit einem derartigen Projekt verbundenen Kosten sind zwei Gründe, warum gerade kleine und mittlere Unternehmen (KMU) oft vor der ITIL-Einführung zurückscheuen.
Der Ansatz von ManageEngine ist es, ITIL so einfach zu machen, dass jedes Unternehmen von ITIL profitieren kann – unabhängig von der Größe. ManageEngine automatisiert den ITIL-Service-Support – ohne teure Consultants oder Folgekosten für das Customizing. Sobald Sie das Produkt installiert haben, erhalten Sie ein ITIL-konformes Framework mit Incident-, Problem-, Change- und Release-Management basierend auf einer CMDB. Sie können ab dem ersten Tag in den Produktiv-Betrieb gehen, da nur minimale Konfigurationen notwendig sind.
ServiceDesk Plus Produktvorstellung
Wir stellen Ihnen die Funktionen von ServiceDesk Plus gerne in einer unserer regelmäßigen Live-Demos vor - kostenlos und unverbindlich.
On-Premise | Cloud
Jetzt anmelden!
2. ITIL-Fakten
Was ist ITIL? Fakten, aber kein historischer Abriss
Eine kurze Einleitung in das Thema möchten wir trotzdem vorweg schicken. ITIL ist ein Rahmenwerk (Framework) mit Best Practises für das optimale Management und die Services eines IT-Betriebs. 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, sollten Sie sich nach ISO 20000 und BS 15000 basierend auf ITIL zertifizieren lassen. |
| 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-Größe von 5 Mitarbeitern. |
| ITIL stammt nicht von einem einzigen Unternehmen oder einer einzigen Person. | ITIL wird nicht von einem einzelnen Unternehmen oder einer einzelnen Person unterstützt. Es gibt keine Profitabsichten oder persönliche Profilierungsabsichten. |
Bei ITIL geht es nicht um komplizierte Prozesse
Bei ITIL geht es nicht um komplizierte, strenge Prozesspläne. Da die Prozesse immer an das eigene Unternehmen angepasst werden sollten, empfehlen wir Ihnen, nicht einfach die Prozesse eines anderen Unternehmens oder aus irgendweinem Buch zu übernehmen.
Tipp:
Wenn Sie ITIL umsetzen möchten, sollten Sie nicht damit beginnen, detaillierte Prozesspläne für Ihre ITIL-Consultants zu machen, die die Pläne dann mit den ITIL-Spezifikationen vergleichen. Denn: Selbst der beste Berater kann Ihnen nicht helfen, wenn er nicht weiß und versteht, wie Ihr Support strukturiert ist und im Detail funktioniert.
ITIL-Service-Mangement ist unser Fokus
Heutzutage ist ein IT-Helpdesk fester Bestandteil eines jeden Unternehmens - egal ob dieses klein oder groß ist. Das erklärte Ziel eines jeden IT- und Helpdesk-Managers ist es, einen effizienten und produktiven IT-Support zu bieten - und genau auf dieses Ziel werden wir uns in diesem Handbuch konzentrieren.
Ob "Service-Support-Modul" aus ITIL V2 oder "Service-Management-Prozesse" aus ITIL v4: Das ITIL-Regelwerk bietet zahlreiche Best Practices für den IT-Helpdesk. Wir richten unser Augenmerk allerdings darauf, wie ITIL die Helpdesk-Manager und IT-Manager unterstützen kann, um einen hochverfügbaren IT-Support sicherzustellen. Dieser Ansatz stand und steht auch bei der Entwicklung unserer IT-Service-Management-Lösung ServiceDesk Plus im Vordergrund.
3. Incident-Management
Unter einem Incident versteht man eine Störung des normalen Service, der einen oder mehrere Anwender oder das Business beeinträchtigt. Ziel von Incident-Management ist es, 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 ausgedrückt:
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 zunächst nach einem ausgeklügelten Trouble-Ticket-System mit schönen Extras anhören. Beim Incident-Management geht es allerdings vielmehr darum, wie Sie Ihren IT-Helpdesk aufsetzen müssen, damit dieser die Anwender und Geschäftsprioritäten Ihres Unternehmens kennt, versteht und berücksichtigt. Incident-Management zeigt, wie wichtig funktionierende Prozesse zum Wiederherstellen von Services sind. Das Servicedesk ist dabei sozusagen der Klebstoff, der die verschiedenen Service-Management-Prozesse mit einem Single Point of Contact für die Anwender zusammenhält. Er stellt sicher, dass der IT-Service das Business stets im Fokus hat.
Erfassen der wichtigen User-Details
New Service Request
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
Incident
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
Weiterführende Informationen:
Incident-Management-Workflow
Hier ist ein Beispiel eines Incident-Management-Workflows. Betrachten Sie ihn als ein Basisvorlage, die Sie - falls nötig - an die spezifischen Anforderungen Ihres Unternehmens anpassen sollten.
4. Problem-Management
Ziel des Problem-Managements ist es, die Ursache des Incidents zu finden und so 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 Feurerwehr-Modus, die von Brand zu Brand eilt, in einen proaktiven Modus zu wechseln und den Incidents einen Schritt voraus zu sein.
Mit einfachen Worten: Die Störungen, die von den Anwendern wahrgenommen werden, sind oft unterschiedliche Auswirkungen bzw. Folgen eines Problems. Wenn Sie die gemeinsame Ursache (Root Cause) aller Incidents finden und diese beheben, packen Sie das Übel an der Wurzel und verhindern damit künftige Incidents.
Weiterführende Informationen:
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.
Weiterführende Informationen:
Wir glauben, dass jedes Unternehmen Change-Management braucht. 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 bei Zoho für neue Berufseinsteiger besteht aus zwei Teilen: einem Eignungstest und persönlichen Interviews. Für ersteren loggen sich in der Regel mehrere Bewerber gleichzeitig in unsere Testumgebung "Zoho Challenge" ein, die auf einem Windows-Server läuft. An einem Tag - die Kandidaten sassen alle schon erwartungsvoll auf ihren Plätzen und waren bereit, mit dem Test loszulegen, geschah es plötzlich: Bumm, der Server war down und somit auch unser Testsystem. Sie können sich vorstellen, wie peinlich es uns war, den Bewerbern zu sagen, dass sich der Test aufgrund technischer Probleme verzögern würde - und das nach unseren einleitenden Worten über Effizienz und Zuverlässigkeit.
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, um unsere HR-Abteilung über ein Systemupdate zu informieren. 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 | Back out Plan |
| 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 einer Sandbox 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 |
Ein einfacher Workflow basierend auf diesen Fragen hilft Ihnen bei der Erstellung eines effektiven Change-Management-Prozesses.
Change-Management-Workflow
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).
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
|
| Identifizieren | Assets/CIs müssen einzigartig definiert werden können. Sie brauchen also ein System, das
|
| 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. IT-ServiceDesk nach ITIL mit ServiceDesk Plus aufsetzen
ITIL, IT-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 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.
8.1 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.
Importieren Sie Ihre 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 den E-Mail-Versand, 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!
8.2 IT-Assets scannen und in das Inventar aufnehmen
Mit ServiceDesk Plus können Sie all Ihre IT-Assets und Nicht-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.
8.3 Incident-Management mit ServiceDesk Plus
Der Incident-Workfow in ServiceDesk Plus besteht aus folgenden Schritten:
- 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.
8.4 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.
8.5 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.
8.6 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