ITIL Handbuch für Helden 1 - · PDF fileITIL Handbuch für Helden 4 Was können...

ITIL Handbuch für Helden 1


Hallo

Ich bin Alex D Paul. Ich arbeite als Produkt Manager bei AdventNet für ManageEngine ITIL Lösungen. Nach zahlreichen, langweiligen Information Technology Infrastructure Libary (ITIL) Präsentationen und Vorträgen in Las Vegas, L.A., London, Sao Paulo, Singapur, Brisbane, Melbourne und Sydney, welche ausschließlich auf dem sogenannten „blue Book“ basierten, dachte ich mir, dass es an der Zeit wäre, selbst einmal etwas über ITIL zu schreiben und zwar nur das, was IT Manager wirklich wissen sollten und das auf eine interessante Art, damit es auch gelesen wird. Bei allem Respekt, das „blue Book“ deckt alle Aspekte des ITIL Service Supports ab und ist der ultimative Referenzguide. Dieses Handbuch hier ist für alle, die weder die Zeit noch die Geduld haben, aber trotzdem das Beste wollen. Ich habe bisher noch keinen interessanten ITIL Service Support Artikel gefunden. Deshalb ist hier mein Versuch einen zu schreiben. Ich hoffe, Sie finden ihn hilfreich.


Kapitel

1

Einführung


Was können Sie von diesem Whitepaper erwarten?

Dieses White Paper 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. ManageEngine’s Lösungsvorschlag zu ITIL

Die Mehrzahl der ITIL Lösungen im 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 Changemanagement 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.


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 die Teile implementieren können, welche für ihren Geschäftsbetrieb relevant und wichtig sind. ITIL ist das dokumentierte Wissen aus der jahrelangen Erfahrung von Helpdeskmanagern 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 ISO20000 und BS 15000, basierend auf ITIL, anstreben.

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 durch Bücher 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 Helpdeskmanagers 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 Helpdeskmanager 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.


Kapitel

2

Incident Management Incident Management im alltäglichen Leben.


Incident Management

Unter einem Incident versteht man die Störung des normalen Service, welche 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 das Business nicht beeinträchtigt wird. Ein Incident ist ein Ereignis, das nicht Teil des Standardbetriebs ist und welches Sie nach Möglichkeit vermeiden wollen. Einfach gesagt: Incident Management ist ein Prozess um Störungen zu managen 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 diese konsequent umsetzt. Incident Management zeigt auf, wie nützliche es ist, über einen Prozeß zu verfügen, der in der Lage ist Ihren Service wiederherzustellen. Der 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 Userdetails • Meldet der User eine Störung oder will er einen neuen Service • Falls der User nach einem neuen Service fragt – NEW Service Request

o Bringen Sie Ihren HelpDesk-Analysten bei, sich wieder beim Benutzer zu melden, wenn er nach einem neuen Service gefragt hat

o Schulen Sie sie, damit Sie Details von Requests mit Dringlichkeit und Priorität versehen

o Schulen Sie das Helpdeskteam nach neuen Serviceplänen und Meilensteinen zu suchen

o Schulen Sie sie, wo Sie nach Antworten für FAQs suchen können • Wird ein Ausfall oder eine Störung gemeldet – INCIDENT

o Entscheiden Sie, ob es sich um einen Incident handelt oder nicht o Überprüfen Sie, ob Sie mit einer Lösung aus der Knowledgebase helfen können. o Weisen Sie den Incident einem Spezialisten aus der Supportgruppe zu o Arbeiten Sie eng mit den Spezialisten der Supportgruppe zusammen, um dem

User eine Lösung bieten zu können o Schließen Sie den Incident mit Bestätigung des Users

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


Incident Management Workflow


Kapitel

3

Problem Management


Problem Management

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 zerstören, verhindern Sie damit weitere künftige Incidents.

Das Ziel von Problem Management ist die Wurzel des Incidents zu finden und den Einfluss auf das Business zu reduzieren. Problem Management ist ein proaktiver Ansatz, der das Wiederauftreten der Incidents verhindern soll.


Problem Management Workflow

Aufnahme und Suche nach bekanntem Fehler in der DB

Ein Problem kann direkt oder durch die Kombination von einem oder mehreren Incidents gemeldet werden. Sobald das Problem erfasst ist, überprüft der Problemtechniker, ob es schon mal 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 ein bekannten Fehler. Der Helpdeskmitarbeiter 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 man anfangen soll. Abhängig davon, ob das Problem am Arbeitsplatz des Users befindet oder am Proxyserver 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. Bsp.: 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 eine Internetverfügbarkeit in Zukunft gewährleistet ist. Problem schließen

Auch wenn der Problemtechniker das Problem löst, ist es die Aufgabe der Helpdeskmitarbeiter, 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 an der Front sicher, dass die Lösung auch exakt den Anforderungen des Users entspricht.


Kapitel 4 Change Management

Kapitel

4

Change Management


Change Management

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 einloggen, Zoho Challenge, 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 unten 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.

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


Implementieren Sei 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ße 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.


Kapitel

5

Release Management


Release Management

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 Releaseplan 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, welche 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.

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


Kapitel 6 CMDB (Configuration Management Database)

Kapitel

6

CMDB (Configuration Management Database)


CMDB (Configuration Management Database)

Die Hauptidee hinter der CMDB ist ein Inventardepot aufzubauen, das leicht identifiziert, kontrolliert und verwaltet werden kann. Was muss eine CMDB haben?

Die CMDB sollte alle Informationen zu allen kritischen Komponenten des Businesses beinhalten • Menschen: User Name, Abteilung, Lokation und so weiter • Inventar: Alle geschäftsrelevanten Assets, wie z.B. Workstations, Desktops, Router,

Drucker • Software: Alle gekauften Softwareprogramme 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 Wo soll ich anfangen?

Zunächst brauchen Sie einen Plan. Hier sind ein paar Vorschläge, die Ihnen helfen einen Entwurf zu erstellen

Plan

Sie brauchen eine klare Vorstellung über • Warum brauchen Sie eine CMDB • Was wollen Sie damit erreichen • Wer kontrolliert und managed • 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 speziellen Prozederes hinzugefügt,

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


verändert oder gelöscht werden dürfen. 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 Lifeumgebung befinden. Reports über Asset Life Cycle kann sehr hilfreich sein, um Aufschluß über Wartung und Abhängigkeiten zu erhalten.

Prüfen und Verifizieren Die CMDB ist keine Einmalsache. Sie sollten von Zeit zu Zeit Audits durchführen, um sicherzugehen, dass Ihre CMDB Ihre Lifeumgebung 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 ein Depot/Speicher Ihrer Vermögensgegenstände (Asset) mit allen Informationen zu Ihren Vermögensgegenständen (Assets). 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 Softwarereleases und wöchentlichen Sicherheitspatches, ist es notwendig, die Kopien der einzelnen Softwarereleases in der Lifeumgebung 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 Anzahl 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 Browserversion als Standard setzen um sicherzustellen, dass alle über eine optimale Basiskonfiguration verfügen.


Beispiel: Sie könnten z.B. folgende Parameter als Basiskonfiguration für alle Geschäftsapplikationen vorschreiben • Standard Betriebssystem – Windows XP • RAM – 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. Die richtige ITIL Lösung auswählen

Da Sie jetzt den ITIL Service Support kennen, ist es an der Zeit, die richtige ITIL Lösung auszusuchen, die Ihnen hilft ITIL umzusetzen. Setzen Sie nicht auf veraltete Lösungen, nur weil jemand eine tolle Salespräsentation abgehalten hat. Sie wissen ja, Marketing- und Vertriebspräsentationen sind immer beeindruckend und sobald Sie das Produkt gekauft haben, sind die Vertriebsleute weg. Versuchen Sie mindestens 4 bis 5 Produkte vom Marktführer bis zu neuen Mitspielern zu evaluieren. Testen Sie diese in Ihrer Umgebung, überprüfen Sie, wie leicht die Software aufzusetzen ist, ob sie sich anpassen lässt und wie sie sich behauptet. Überprüfen Sie nun, was es Sie kostet. Initiieren Sie die Feuerprobe. Bevor Sie sich entscheiden, sollten Sie Ihre Hausaufgaben machen!

Anbieter ITIL Lösung Webseite

AdventNet ManageEngine ServiceDesk Plus

www.servicedeskplus.com

Axios Axios Assyst www.axiossystems.com BMC BMC Incident and

Problem Management BMC Change Management BMC Atrium (CMDB)

www.bmc.com

FrontRange FrontRange ITSM http://itsm.frontrange.com/detail.aspx?id=6018

Infra ITIL Solutions www.infra.co.uk

Service Now IT Service Management on demand

www.service-now.com

Symantec (ehemals Altiris)

Altiris IT Lifecycle Management

www.altiris.com/itil/

Numara Software

Footprints www.numarasoftware.com/footprints.asp


Sie + ITIL Prozesse + ServiceDesk Plus - Richtig hinbekommen

Kapitel

7

Implementierung eines ITIL Service Support mit ServiceDesk Plus


SQL Server Active Directory Crystal Reports

ITIL Service Support und ServiceDesk Plus

Mit ServiceDesk Plus haben Sie das komplette ITIL Service Support Rahmenwerk mit Incident, Problem und Change Management, 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 Installationswizard, sobald sie Finish klicken, sind Sie fertig.

Probieren Sie aus wie einfach die Installation ist. Laden Sie eine 30-Tage Testversion von der Webseite www.servicedeskplus.com/download.html Nach der Installation starten Sie Ihren Webclient und Sie sehen ServiceDesk Plus in Aktion….Tada.

Kombiniert mit

Kompatibel mit


Fangen wir an!

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 legen Sie ein paar manuell an.

Konfigurieren Sie die Emails, um Anfragen zu erhalten Wir empfehlen immer auf einem Testsystem zu arbeiten, damit Sie Ihre Lifeumgebung nicht beeinträchtigen. 1. Erstellen Sie einen Demo Email Account auf Ihrem Mailserver 2. Um Anfragen zu erhalten, müssen Sie die Mail Server Settings unter dem Admin Tab

konfigurieren 3. Spezifizieren Sie die Emailadresse, die Sie gerade erstellt haben [email protected]

und den Usernamen 4. Wählen Sie das Protokoll im Emailtyp aus Danach sende Sie eine Email oder fragen Sie User, dass Sie eine Email senden. Sie sehen, dass die Email abgerufen wird und zu einer Anfrage konvertiert wird. Bitte beachten Sie, dass Emails, die von ServiceDesk Plus abgerufen werden, vom Mailserver gelöscht werden. Sie wurden gewarnt!


Vermögensgegenstände scannen und aufnehmen

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

• Alle Workstations und Server – Windows, Linux, Apple Macs und HP Thin Clients

• Netzwerkgeräte – Drucker, Router, Switches 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 und 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.


Incident Management

Der Incident Workfow im ServiceDesk Plus • Incident erkennen • Incidentdetails 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 Servicewunsch, wird er als New Service Request eingeordnet. Schritt 2: Incidentdetails aufnehmen Sobald eine Incident erkannt wurde, ist es wichtig, dass der Helpdeskmitarbeiter den Incident qualifiziert. Durch die richtige Fragetechnik können die Helpdeskmitarbeiter 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 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 Helpdeskmitarbeiter 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 Helpdeskmitarbeiter können nach einem existierenden Workaround oder einer Lösung für die Anfrage suchen und sofort dem User antworten.


Schritt 5: Neue Probleme einordnen oder mit existierenden Problemen verknüpfen Helpdesktechniker 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 Helpdeskmitarbeiter 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 Helpdeskmitarbeiter lösen die Incidents und ändern den Status der Anfrage auf gelöst. ServiceDesk Plus sendet eine Email 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.


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 analysieren und den Einfluss des Problems 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 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 nur dann ein Problem 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. 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 Changeprozess 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 Changeplä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 autorisiert worden sind, aufgrund der Management Policies. 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 Changeplans und des damit verbundenen Risikos werden die CAB Mitglieder entschieden, ob Sie den Change Plan akzeptieren oder ablehnen. Change Advisory Board Mit ServiceDesk Plus kann man ein CAB erstellen. Basierend auf den definierten Change Typen, kann man 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 den Change Plan und dem damit verbundenen Risikos, 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 delegieren und den Stand inwieweit die Aufgaben erfüllt sind nachvollziehen. 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 Changehistorie nach. Damit lassen sich Change Audits leichter durchführen und man erhält 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 Auditzwecke abrufen..


Configration Management Database (CMDB)

Assets erkennen ServiceDesk Plus unterstützt Sie, alle IT Assets wie Workstations (Windows, Linux und Apple Macs), Drucker, Router, Switches 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. Softwarebibliothek ServiceDesk Plus erkennt alle installierten Softwareprogramme in Ihrem Unternehmen und baut daraus eine Softwarebibliothek, 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 Softwarelizenzmanagement. 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


Zusammenfassung

ITIL ist gedacht für Unternehmen jeglicher Größe, klein, mittel und groß. Jedoch hat ITIL heutzutage keine faire Chance im Markt für KMUs, wird aufgrund der Kosten und Komplexität oft abgelehnt. Das Handbuch für ITIL Helden ist eine Initiative in der Hoffnung, diese generelle Ansicht zu ändern und IT Managern und Ihren Mitarbeitern zu helfen, ITIL im richtigen Sinne zu verstehen. Das Whitepaper soll einen praxisnahen Zugang zu ITIL vermitteln. Starten Sie mit praxisnahen ITIL Prozessen und Workflows, die bei den meisten Unternehmen weltweit funktionieren. Implementieren Sie ITIL in einem Tag. Probieren Sie es aus, damit Sie es glauben.

ITIL Handbuch für Helden 1 - · PDF fileITIL Handbuch für Helden 4 Was können...

Documents

Transcript of ITIL Handbuch für Helden 1 - · PDF fileITIL Handbuch für Helden 4 Was können...