vereinfacht später es später, die Toolun-terstützung aufzusetzen.Dank der CMDB hält eine IT-Abteilung in zentral vorgehaltenen Strukturen ihr Wis-sen vor, welche Geräte sie besitzt, ver-waltet und betreibt, welche Services sie anbietet und wie die funktionieren. Letz-tere Informationen liegen häufig schon vor, zum Beispiel weil die Firma mit ei-nem SAP-System bucht. Daher bleibt in den meisten Fällen das Zusammentra-gen aller Informationen über Hard- und Software der mit Abstand arbeitsaufwän-digste Akt.Die LAN-Geräte kann der Admin häufig durch einen Netzwerkscan automatisiert erfassen, und bringt mit Hilfe der MAC-Adresse die anderen Informationen wie Ausstattung, Kaufdatum und Benutzer so-wie Services ans Licht. Standortinformati-onen (Raum-, aber auch Telefonnum-mern) muss er meist manuell einpflegen. Dabei ist nicht immer der Anwender auch der Kunde, sondern häufig dessen Chef, an den die Rechnung ging.Schwieriger ist die Software (auf Win-dows-Rechnern) zu erfassen – Linux-Ma-schinen mit ihrem einheitlichen Paketma-nagement erleichtern diese Aufgabe. Ganz allgemein gibt es Tools, die Software er-kennen. Der IT-Verantwortliche sollte aber darauf achten, dass daraus keine Überwachung der Mitarbeiter entsteht – allein der Verdacht genügt, um Ärger zu bekommen. Wer jetzt noch beispielswei se aus dem SAP die Services gewinnen kann, ist einen großen Schritt weiter.

Von Calls und Tickets

Der nächste große Schritt zielt auf die Auswahl eines Tools, das, als Mindest-anforderung, Störungsmeldungen der

Mit „ITIL ist eine Sammlung von Bü-chern ...“ beginnen fast alle Ausführun-gen [1] zur IT Infrastructure Library [2]-[4]. Zurecht, denn die Aussage ist ele-mentar und ITIL wirklich nur Best Prac-tice, also eine Darstellung von guten Bei-spielen, um ein IT-Service-Management (ITSM) zu etablieren. Zwar gibt es mit ISO/ IEC 20 000 lange schon eine richtige Norm, gegen die sich Organisationsein-heiten (für drei Jahre) zertifizieren lassen können. Aber der Kerngedanke von ITIL bleibt, dass sich eine Firma anhand der Beispiele ihr eigenes Qualitätsmanage-ment-System maßschneidert (Abbildung

1), und das geht ohne Zertifikat.Die gute Nachricht lautet: Das Ganze ist kein Hexenwerk, solange die IT-Abteilung nicht riesig groß ist und eine Zertifizie-rung – falls überhaupt angestrebt – erst am Schluss stehen soll. Der Prozess lässt

sich weitgehend ohne professionelle Be-ratung in Eigenregie einrichten, oder man holt sich Unterstützung aus einer Firma, die so etwas schon einmal an sich selbst gemacht hat.

Vorarbeit spart Aufwand

Wichtig ist von allem die gründliche Vor-arbeit. Alles, was jemand hier versäumt, bereut er später – das Nachholen verviel-facht häufig den notwendigen Aufwand, so die Erfahrung. Ein Teil der Vorarbeit kristallisiert sich in der Configuration Ma-nagement Database (CMDB), die alle Be-triebsmittel der IT (Configuration Items, CI) erfasst. Mit ihr steht und fällt zugleich ITIL. Dabei muss die CMDB nicht zwin-gend eine einheitliche Datenbank sein – in großen Firmen ist sie es tatsächlich häufig nicht –, aber eine Gesamt-CMDB

IT-Abteilungen unterliegen ebenso einem Wandel wie ihr Gegenstand, die IT. Organisch gewachsene Struk-turen, die beim Weiterwachsen deutliche Schmerzen verursachen, sollten Verantwortliche dringend ordnen und professionalisieren. ITIL kann ihnen dabei helfen. Oliver Kluge

IT-Abteilungen modernisieren mit ITIL-Ideen

Suche nach Struktur

Tit

elth

ema

38

ww

w.lin

ux-m

agaz

in.d

eIT

IL12

/201

3©

Buc

hach

on P

etth

anya

, 123

RF.c

om

Anwender und die da-raufhin erledigten Ar-beiten erfasst. Je nach Tool heißen solche Meldungen Tickets oder Calls. Sie zu ma-nagen, ist neben der CMDB die zweite un-verzichtbare Säule.Abteilungen mit orga-nisch gewachsenen Strukturen hantieren hier genau wie bei der CMDB gerne nur mit Papierformularen oder E-Mails. Das geht eine ganze Zeit gut, danach aber verlieren die Ad-mins in der Mailflut den Überblick, und die Erkenntnis reift, dass es ohne Tool nicht mehr geht. Die Auswahl an Ticketsyste-men erscheint mehr als reichlich.Neben der Zertifizierung gegen Ende scheint es hier eine zweite Gelegenheit zu geben, um punktuell professionelle Hilfe einzuholen. Denn die Tools unter-scheiden sich in vielen Merkmalen, vor allem in der Art, wie sie Prozesse und Workflows abbilden. Probleme ergeben sich nämlich, wenn bereits vorhandene Systeme zu integrieren sind, häufig SAP & Co. Das macht die Eigenarbeit schwie-rig, aber möglich.Es gibt Tools, die einen eigenständigen Ansatz verfolgen und bei denen Work-flows erst beim Customizing entstehen – was den Vorteil hat, dass die dann wirklich maßgeschneidert sind. Und es gibt Tools, die mit einem vorgefertigten Satz an ITIL-Prozessen kommen, und so schneller zum Erfolg führen. Manchmal ist es aber nötig, einen Workflow an das Tool anzupassen.

Prozesse mit Augenmaß

Während ein Admin das Tool aufsetzt und mit der CMDB füttert, sollte jemand zumindest einen Rohentwurf seiner wichtigsten Prozesse anlegen. Hilfreich ist es, bereits vorhandene Dokumentation heran zuziehen und zu vereinheitlichen. Denn: Jeder noch so geniale Neuentwurf haftet ein Makel an – eben, dass er neu und damit für Mitarbeiter unbekannt ist. Je ähnlicher der Neuentwurf der bisheri-

gen Praxis ist, desto leichter und rei-bungsärmer wird er umgesetzt werden.Prozesse haben Besitzer. Das sind Mitar-beiter, die definieren, wie die Firma einen Prozess konkret ausgestaltet. Ein solcher Owner kümmert sich um die Weiterent-wicklung der Prozessdokumentation, und er sorgt dafür, sie mit Leben zu füllen. Prozesse definieren Rollen, die wiederum Mitarbeiter ausführen. Die Basisprozesse, ohne die nichts geht, sind:n Incident Managementn Configuration Managementn Change Management.Wer sie sauber definiert, für den sind die meisten anderen Prozesse nicht mehr weit. Er sollte sich jedoch unbedingt hü-ten, zu viel auf einmal zu wollen. Fürs Erste lässt sich ohne Problem Manage-ment arbeiten, sich wiederholende Stö-rungen fängt das Incident Management ab, das ohnehin stets mit im Boot ist. Das Release Management vermag das Change Management mit abzuhandeln et cetera. Spezialdisziplinen wie Availabi-lity oder Capacity Management brauchen realistisch betrachtet ohnehin fast nur Großbetriebe, oder man fasst Prozesse zusammen.

Botschafter mit Außenwirkung

Im Incident Management (in ITIL zu fin-den unter: Service Operation | Incident Management) muss sich die IT-Abteilung der Außenwirkung wegen entscheiden,

Abbildung 1: Die prinzipielle Struktur von ITIL, dargestellt als Kreis.

© IT

IL.o

rg -

Gle

nfis

AG

ment). Es regelt, welche Daten von wem wann wie womit zu erheben sind, wer sie pflegt und wer sie überprüft. Eine Va-liditäts- und Integritätskontrolle ist lästig, muss aber ab und zu sein. Nicht zwin-gend dagegen sind manuell Inventuren, denn dafür gibt es automatische Tools.

Der Probestart

Wer die elementaren Prozesse beieinan-der hat, darf mit der Testphase beginnen. Die größte Umstellung für Mitarbeiter ist sicherlich das Rollenmodell an sich. In vielen organisch gewachsenen IT-Abtei-lungen gibt es Zuständigkeiten: Server

repariert der Kollege Huber. Die Telefon-anlage macht Franz. Am Telefon sitzt Karla Meier. Mit ITIL gibt es das so nicht mehr. Eine Rolle heißt hier, ein Mitarbei-ter führt eine Funktion aus. Ein anderer Mitarbeiter kann die gleiche Rolle und damit Funktion ausführen.Ein Mitarbeiter darf zudem mehr als eine Rolle innehaben – dann hat er sinnbild-lich mehrere Hüte auf. Hier ist es wichtig, dass sich kein Kollege überfordert fühlt. Drei Hüte aufhaben heißt nicht automa-tisch, für drei arbeiten zu müssen. Das richtig zu justieren ist Aufgabe der Vorge-setzten und nicht immer einfach.Das Servicedesk beziehungsweise das Auftragsmanagement (oder die Kombina-tion beider) soll so organisiert sein, dass es als die einzige Anlaufstelle für Anwen-der und Kunden fungiert (Abbildung 2). Als professionell kann eine IT-Abteilung erst gelten, wenn ein Anwender nicht mehr seinen Lieblingsspezialisten direkt anruft, denn die persönliche Bindung er-weist sich zwar als schnell, ist aber nicht nachhaltig. Dabei entstehen undokumen-tierte Lösungen. Wer sich entscheidet, das Auftragsmanagement separat zu be-treiben, kann seine Struktur recht ähnlich zu der vom Servicedesk wählen (in ITIL: Service Operations | Request Fulfill-ment).

King of the Ring

Schwieriger als das in irgendeiner Form ohnehin vorhandenen Servicedesk zu

ob sie nur ein Helpdesk oder (besser) ein Servicedesk betreiben möchte. Ideal ist ein so genannter Skilled Service Desk mit Mitarbeitern, die versuchen, die Hälfte oder mehr aller eingehenden Störungen zu beheben, während der Anwender noch am Telefon ist. In den meisten Fir-men nehmen die normalen Angestellten von der IT-Abteilung als Ganzes im Nor-malfall nichts wahr. Sehen können sie nur die Leute, die mal einen PC ausliefern oder reparieren. Zu hören bekommen sie IT-Kräfte am Telefon, wenn sie etwas be-stellen oder eine Störung melden. Tipp: Diese IT-Mitarbeiter sollte man auf ihre Rollen als „Botschafter“ der IT-Abteilung einschwören.

Ausdifferenziert

Mit steigender Größe wird eine Aufga-benteilung in der Entstörung sinnvoll. Die IT-Abteilung braucht ohnehin Leute, die arbeitsintensivere Sachen nachverfol-gen oder Auskünfte bei Herstellern ein-holen. Fürs vertiefte Bearbeiten schafft man einen Second-Level-Support und für Hausbesuche bei Anwendern und Kun-den einen Außendienst. Für den Betrieb eines Rechenzentrums sollten die Admins einige Rollen definieren.Um die so mühsam erstellte CMDB weiter gut in Schuss zu halten, erweist sich ein Configuration Management als absolut unverzichtbar (in ITIL: Service Transition | Service Asset & Configuration Manage-

Um ITIL ranken sich Mythen und Sagen. Ein paar davon seien hier auf ihren Wahrheitsgehalt hin abgeklopft:n ITIL ist furchtbar kompliziert und komplexEs handelt sich um keinen Mythos. In Reinform und in voller Ausprägung ist ITIL furchtbar kom-plex. Aber: Die volle Ausprägung braucht kaum jemand! Weniger ist hier mehr. Wenige, dafür gut dokumentierte und gut gelebte Prozesse bringen viel mehr als eine Vollausstattung, die viele Mitarbeiter nur zu umgehen suchen.n ITIL spart GeldITIL ist aus der Sicht von ISO 9001 ein Qualitäts-managementsystem. Es hat nicht zum primä-ren Ziel, Kosten zu sparen. Es soll die Verläss-lichkeit und Planbarkeit erhöhen. Dabei lässt sich hier und da etwas sparen. Zunächst aber erzeugt es höhere Verwaltungsaufwände, und damit eigene Kosten in nennenswerter Höhe.

n ITIL beschleunigt ProzesseIn sehr gut eingeführten ITIL-Prozessen kann das der Fall sein. In der Einführungsphase tritt aber fast immer der gegenteilige Effekt auf: Bis sich alle eingewöhnt haben, dauert vieles viel länger als früher, daher ist ein gewisser Durchhaltewille notwendig.n ITIL ist besser als ISO 9001Definitiv ein Mythos, denn ITIL ist selbst ein QMS, während ISO 9001 beschreibt, dass eine Organisation ein QMS haben muss, aber nicht welches. Für die IT-Abteilung kann das dann ITIL/ ISO 20 000 sein, für andere Abteilungen nicht. Der Fokus ist ein anderer. ISO 9001 kommt aus dem produzierenden Gewerbe und ist viel älter, hat daher andere Schwerpunkte. Manches daraus kann sich auch ein ITIL-Prozess abgucken, etwa die Dokumentenlenkung. Fazit: ITIL und ISO 9001 ergänzen sich gut.

ITIL: Mythen und Wahrheiten

Abbildung 2: Das proaktive Servicedesk mit seinen Facetten sollte viele Probleme sofort am Telefon lösen.

© IT

IL.o

rg -

Gle

nfis

AG

Tit

elth

ema

40

ww

w.lin

ux-m

agaz

in.d

eIT

IL12

/201

3

reformieren, ist es, das Change Manage-ment (Service Transition | Change Ma-nagement) zu starten. Denn die Spezia-listen im Haus, die wissen „wie man es macht“, lassen sich erfahrungsgemäß nur ungern sagen, dass sie künftig nicht „mal schnell“ etwas ändern dürfen. Vielmehr müssen sie nun einen Antrag (Request for Change, RfC) formulieren, über den ein Change Advisory Board berät – und den es auch mal ablehnt.In einer gut geführten IT-Abteilung kommt kein Administrator einfach so ins Rechen-zentrum, sofern er keinen genehmigten RfC und einen Termin (im Forward Sche-dule of Change) hat. Und nach jedem Change kommt der PIR, der Post Im-plementation Review. Nur Änderungen, die erfolgreich waren, haben Bestand. Andernfalls muss man einen Rollback erwägen. Für Routine-Aufgaben gibt es übrigens abgespeckte Changes, damit die Bürokratie nicht zu sehr wuchert (Stan-dard Change – vorab autorisiert).

Keine Schikane

Was im ersten Moment nach ausufernder Bürokratie klingt, ist in Wirklichkeit die einzige Chance, Ordnung in den Wild-wuchs zu bringen und eine zwingende Voraussetzung für erfolgreiche Entstörun-gen. Salopp ausgedrückt muss jeder die Welt neu dokumentieren, wenn er sie än-dert. Für Systemadministratoren bedeutet es sicherlich eine Umstellung, nicht mehr „King of the Ring“ zu sein, sondern Teil eines Teams. Doch wer schon einmal er-lebt hat, was passiert, wenn so ein King kündigt (oder nur krank wird), weiß um die Gefahren. Wenn dann, wie so oft, die Dokumentation nicht stimmt, wird es schnell brenzlig.Gerade wenn die IT-Abteilung nicht be-sonders groß ist und trotzdem jede Rolle mit einem oder gar mehreren Mitarbei-tern zu besetzen ist, bekommen viele Admins mehrere Hüte aufgesetzt, sprich mehrere Rollen zugewiesen. Ideal ist es, wenn der Organisator dabei die bisherige Tätigkeit der Mitarbeiter abbilden kann. Andernfalls sollte er sachlich Naheliegen-des kombinieren.Wie in allen modernen QM-Systemen ist in ITIL auch der Deming-Cycle integraler Bestandteil. Der Zyklus wird auch Plan-do-check-Act oder kontinuierlicher Ver-

besserungsprozess genannt. Er sieht vor, dass jeder Vorgang erst geplant, dann ausgeführt und dann überprüft wird, und daraufhin wird die Planung verbessert und so weiter.

Die weitere Reise

Ist diese Einführungsphase geschafft, kann sich die Firma daran machen, die Buchhaltung anzuflanschen (ITIL: Ser-vice Strategy | Financial Management), und zum Beispiel die Ergebnisse der Aufwandsbuchungen für Tickets SAP zu übergeben. Ohne SAP-Spezialisten geht da gar nichts – eigentlich wie immer, wenn es um Geld geht. Dann zieht man weitere Verästelungen ein.Sicher lässt das erste Problem nicht lange auf sich warten. Fünf Kollegen können auf einmal nicht mehr drucken. Jemand muss – nachdem die unmittelbare Stö-rung behoben ist – untersuchen, ob es ein Spoolerproblem gab. Oder es leigt ein tiefgreifendes Problem mit dem Drucker vor, der eventuell den Anforderungen nicht gewachsen ist. Oder es gab eine Netzwerkstörung oder eine Putzfrau hat schlicht ein paar Stecker gezogen. Kurz: Ein Problem Management (Service Ope-ration | Problem Management) muss her, das nach den Wurzeln des Übels (Root Causes) sucht und Known-Error-Doku-mente erstellt (oder anfertigen lässt). So hat der Servicedesk beim Eingang weite-rer Störmeldungen erste Handlungsan-weisungen und kann die Experten auf-treiben, damit sie wo möglich Lösungen schaffen und dokumentieren (Abbildung

3). Gerade bei großen Störungen bewährt sich ein Problem Management.Spätestens der nächste Betriebssystem-wechsel oder ein Leasingtausch wird die Notwendigkeit des Release Managements (Service Transition | Release and Deploy Management) zeigen, eine Art aufgebohr-tes Change Management. Für die Planung des Ausbaus kann ein Capacity Manage-ment (Service Design | Capacity Manage-ment) sinnvoll sein, für das Einhalten der Servicelevel ein Availability Management (Service Design | Availability Mana-gement). Einen Qualitätsmanager sollte spätestens dann bereitstehen, wenn es ans Zertifizieren geht. Er wacht unter anderem darüber, dass alle Prozesse sau-ber dokumentiert sind, und prüft mit re-

gelmäßigen internen Audits, ob sich auch alle an die Regeln halten.Jedes Firma kann morgen Opfer eines Hackerangriffs werden, weshalb ITIL je-der IT-Abteilung ein Security Manage-ment angedeihen lässt (Service Design | Information Security Management).

Mit Sicherheit mehr

Das Ende des Artikel bringt den ITIL-Interessierten allerdings noch nicht zum Ende seiner Todo-Liste: Vertragsmanage-ment, Lizenzmanagement, Supplier Ma-nagement, Business Relation Manage-ment, Service Portfolio Management, IT Service Continuity Management, Access

Start weg unter Zeitdruck setzt, kann sie damit viel erreichen. Ein echter Königs-weg existiert nicht, aber die sichere Er-kenntnis, dass die Qualität der CMDB über jeden Zweifel erhaben sein muss, um eine Chance auf Sieg zu haben. Den Kunden und Anwendern ist es meistens viel wichtiger, dass alles „schön flutscht“. Wichtiger als Zertifikate allemal. (jk) n

Infos

[1] Oliver Kluge, Peter Pieronczyk, „IT-Quali-

tätsmanagement nach den ITIL-Versionen 2

und 3“, Linux-Magazin 12/07, S. 108

[2] ITIL: [http://www.itil-officialsite.com]

[3] ITIL.org: [http:// www. itil. org]

[4] IT Service Management Forum (Verein):

[http:// www. itsmf. de]Management – es bleiben viele Dinge, die er tun kann, wenn die Zeit dafür ge-kommen ist. Wie schon erwähnt: Lieber anfangs weniger, dafür bessere Prozesse. Und wer den Eindruck hat, dass alles schön läuft, darf eine Zertifizierung ins Auge fassen. Hier ist professionelle Hilfe unerlässlich, denn nur sie erkennt Stol-perstellen, bevor man ein teures externes Audit versemmelt.

Fazit

ITIL ist ein Weg zur Professionalisierung. Nicht der einzige, aber ein bewährter. Sofern eine IT-Abteilung nicht zu viel auf einmal will oder sich unnötigerweise vom

Der Autor

Oliver Kluge ist ITIL-geprüft

und zertifizierter Qualitäts-

managementbeauftragter

und -Auditor (QMB/ QMA)

nach ISO 9001. Er ist verant-

wortlich für das technische

Qualitätsmanagement in der IT des Flughafens

München und leitet dort das Testlabor. Er arbeitet

auch als Problem Manager und berät IT-Abteilun-

gen anderer Flughäfen in vielen Ländern der Welt.

Kluge hat Informatik studiert, war Redakteur bei

großen PC-Zeitschriften und 2001 beim

Linux-Magazin Leiter des damaligen Competence

Center Hardware.

Abbildung 3: Das Problem Management sucht nach Root Causes und fertigt Known-Error-Dokumente an.

© IT

IL.o

rg -

Gle

nfis

AG

Tit

elth

ema

42

ww

w.lin

ux-m

agaz

in.d

eIT

IL12

/201

3