Viele IT-Verantwortliche kleiner und mittlerer Unternehmen verstehen unter der geordneten Verwaltung ihrer IT meist die techniklastigen Disziplinen des IT-Managements. Die sich häufenden

Sicherheitslücken in Mainstream-Produkten wie Windows ("PrintNightmare"), Linux ("Baron Samedit") oder Exchange ("Proxy-Shell") rücken das Patchmanagement in den Fokus der IT-Leiter und Admins. Und die Verbreitung von Clouddiensten zwingt IT-Organisationen aller Größen, ihr Identity-Management kritisch zu hinterfragen. Zudem hat die Corona-Pandemie gezeigt, dass Anwendungs- und Clientmanagement kein lästiges Beiwerk sind, sondern über Erfolg oder Misserfolg von "work from home"-Initiativen entscheiden können.

Doch IT ist viel mehr als nur Systeme und Dienste. Sie wird von Menschen betrieben und vor allem von Menschen genutzt, um die tägliche Arbeit möglichst effizient und mit möglichst wenig Frustration zu verrichten. Daher beschäftigt sich das klassische IT-Service-Management (ITSM) neben den oben genannten mit weiteren wichtigen Disziplinen:

- Knowledge-Management

- Service-Request-Management

- Incident-Management

- Problem-Management

- IT-Asset-Management

- Change-Management

Die konkreten Bezeichnungen variieren, je nachdem, nach welchem Framework Sie das ITSM in Ihrer Organisation bewerten und ausrichten. Als De-facto-Standard hat sich in größeren Unternehmen und staatlichen Organisationen ITIL [1] durchgesetzt. Doch auch COBIT [2] und das Microsoft Operations Framework (MOF) [3] werden nach wie vor von IT-Organisationen überall auf der Welt praktiziert.

Wenn Sie als Praktiker in der IT-Abteilung eines KMU anfangen, sich mit einem der gängigen ITSM-Frameworks zu beschäftigen, werden Ihnen sehr schnell zwei Dinge auffallen: Die an sich schlüssigen, wenn auch bisweilen etwas gestelzt formulierten Texte des Frameworks haben keinen sofort erkennbaren Bezug zu Ihrem "Tagesgeschäft" an der Hotline oder in der Serveradministration. Daneben sind die einzelnen Disziplinen jeweils sehr umfangreich und greifen ineinander, was das Erfassen des gesamten Frameworks noch weiter erschwert.

Dieser scheinbare Widerspruch zwischen Theorie und Praxis zeigt sich regelmäßig in Zertifizierungsprüfungen – gerade Mitarbeiter des Service-Desks, die theoretisch jeden Tag im "ITIL-Land" leben, schneiden dabei häufig schlecht ab oder fallen gar beim ersten Anlauf durch. Praktiker in kleinen Unternehmen fragen sich daher oft zu Recht, ob das geordnete IT-Service-Management nicht nur etwas für die Großen ist. Schließlich können sich nur große Unternehmen und Behörden Personal leisten, dessen einzige Aufgabe es ist, zwischen dem gewählten ITSM-Framework und den täglichen Aufgaben der IT-Mitarbeiter zu übersetzen. Das wohl prägnanteste Beispiel ist hier der "Alleinunterhalter", der es durch seinen unermüdlichen Einsatz irgendwie immer wieder schafft, IT-Dienste für hundert Benutzer in akzeptabler Qualität am Laufen zu halten. Diesem Menschen zu vermitteln, dass er für seine Arbeit "Organisation" und "Prozesse" benötigt, ist oft schwierig, und der Versuch wird höchstens mit einem müden Lächeln quittiert.

Angesichts der Notwendigkeit, ihre IT geordnet, verbindlich und nachvollziehbar zu betreiben, greifen IT-Verantwortliche oft instinktiv zu Anwendungen. Sie tun das in der Hoffnung, dass das gewählte Produkt die Komplexität und das unverständliche Wording des ITSM-Frameworks abstrahiert und auf magische Art und Weise in die gewohnten Prozesse des täglichen Doings umsetzt. Doch diese Hoffnungen werden meist enttäuscht und die entsprechenden Projekte schnell wieder eingestampft.

Die gängigen ITSM-Tools wie Microsoft System Center Service Manager, ivanti Cherwell oder ServiceNOW sind nämlich auf beliebige ITSM-Anforderungen im Rahmen von ITIL beziehungsweise MOF ausgelegt. Die Übersetzung in die eigenen Prozesse findet also in der Planungs- und Implementierungsphase des jeweiligen Kunden statt. Kleine IT-Abteilungen, die zuvor keine Prozesse für ihre Tätigkeit formuliert hatten und sich diesbezüglich Hilfe von einer Software erhoffen, werden bei der Einrichtung dieses Tools mit der Aufgabe konfrontiert, die (nicht vorhandenen) Prozesse in einem (schwer zu erlernenden) Framework abzubilden, um das Tool sinnvoll nutzen zu können.

Ein weiteres Thema, mit dem sich IT-Verantwortliche in Unternehmen aller Größen bei der Einführung eines geordneten ITSM frühzeitig beschäftigen müssen, ist die Wahrnehmung dieser Maßnahmen durch ihre Mitarbeiter. Hier müssen Sie an mindestens drei Punkten mit einer gewissen Skepsis oder sogar mit offenem Widerstand rechnen:

- Die Überwachung der Service-Desk-Performance nach numerischen KPIs, wie aus großen IT-Organisationen bekannt, stößt in kleinen IT-Abteilungen stets auf große Abneigung. Dabei ist eine Überwachung hier in der Regel gar nicht beabsichtigt.

- Oft haben IT-Mitarbeiter eine starke emotionale Bindung zu selbst erarbeiteten Prozessen, mit denen sie bisher ihren Arbeitsalltag bewältigt haben. Die Angst, durch die Neuordnung des ITSM die Kontrolle über den Prozess zu verlieren, sollten Sie auf keinen Fall unterschätzen.

- Nicht jede IT-Abteilung hat das Glück, auf Mitarbeiter zurückgreifen zu können, die gern dokumentieren. Da in der IT mit "Ordnung" nicht zu Unrecht auch Dokumentationspflichten assoziiert sind, müssen Sie den Umfang der zusätzlichen Aufgaben frühzeitig mit Ihren Mitarbeitern erörtern und vor allem Mehrwerte, die daraus entstehen, aufzeigen.

Gerade in kleineren IT-Abteilungen leiden Mitarbeiter besonders oft an dem Heldensyndrom, das im Endeffekt sowohl der Work-Life-Balance der Mitarbeiter als auch dem geordneten IT-Management im Wege steht. Paul Cunningham hat dieses und andere Phänomene, mit denen Sie sich bei der Führung Ihres IT-Teams beschäftigen müssen, in seinem Buch "Surviving IT" [4] beschrieben. Sprechen Sie im Team darüber und sichern Sie sich den Rückhalt Ihrer Mitarbeiter auf dem Weg in eine wohlgemanagte IT-Organisation!

Bevor Sie die Devise "ab morgen machen wir alles nach ITIL" ausgeben, fragen Sie sich, welches Ergebnis Sie in Ihrer IT-Abteilung wirklich erzielen möchten. Entscheidend dabei ist der Begriff "Technical Debt". Diese nicht direkt bezifferbaren "technischen Schulden" haben viel mit Geldschulden gemeinsam. Sie neigen dazu, unkontrolliert zu wachsen, sie sind schlecht für die Moral und sie haben das Potenzial, Ihr Leben im unpassendsten Moment aus der Bahn zu werfen.

Wie kommt es zu Technical Debt? Es beginnt oft mit kleinen Schritten: Ein undokumentierter schneller Fix hier, eine Firewallausnahme dort und nach zwei Wochen erinnert sich niemand mehr daran, wie der Fix zustande kam. Dann müssen Sie mühsam recherchieren, welche Registry-Einstellung dafür sorgt, dass etwas anderes plötzlich nicht mehr funktioniert. Bei der Forensik nach einem

Sicherheitsvorfall findet sich die Firewallausnahme, und ein unangenehmes Gespräch ist die Folge. Auch selbstgeschriebene Skripte sorgen paradoxerweise oft für die Erhöhung des Technical Debt der gesamten Organisation, denn Aufgaben, die mit den Skripten "erschlagen" werden, sind mit anderen Mitteln nachhaltiger lösbar. Zudem öffnen Skripte eine Hintertür für Sicherheitsvorfälle und das Troubleshooting und die Weiterentwicklung der Skripte bleiben auf der Strecke, wenn der Urheber das Unternehmen verlässt oder einfach im Urlaub ist.

Haben Sie in Ihrer Umgebung Systeme, die Probleme machen, wenn ein bestimmter Mitarbeiter einmal nicht da ist? Das ist ein deutlicher Hinweis darauf, dass sich hier solche Schulden angehäuft haben, die eine konkrete Person durch den Einsatz ihrer Zeit täglich "abstottert". Dies ist problematisch, weil dieser Zeiteinsatz in Ihrer Planung vermutlich nicht berücksichtigt wird und somit für andere Aufgaben fehlt. Doch auch die nicht dokumentierten und nicht nachhaltig behandelten Probleme werden Ihnen irgendwann auf die Füße fallen – meist genau dann, wenn Sie es am wenigsten brauchen können.

Um Technical Debt und andere Probleme in Ihrer IT-Organisation einzufangen und dauerhaft loszuwerden, bedarf es klar definierter und vor allem täglich befolgter Prozesse zum Abarbeiten sowohl der regelmäßigen Aufgaben als auch außergewöhnlicher Vorfälle. Ob diese Vorgaben auf das ITIL-Framework oder auf den gesunden Menschenverstand und jahrelange Erfahrung zurückgehen, ist dabei nicht wichtig. Die Hauptsache ist, dass sie ihren Zweck erfüllen und Ihr IT-Team sich darin wiederfindet.

Schauen Sie sich die Aufstellung der üblichen ITSM-Disziplinen in der gleichnamigen Tabelle an und achten Sie ganz besonders auf den nicht-technischen Teil ("organisatorisch"). Selbst wenn von Ihnen nicht erwartet wird, zu jeder dieser Disziplinen ein Kapitel im Arbeitsplatzhandbuch Ihrer IT-Mitarbeiter zu haben, müssen Sie sich zu allen ITSM-Aspekten dennoch Gedanken machen und die Ziele der jeweiligen ITSM-Disziplin auf Ihre konkrete IT-Organisation projizieren. Übrigens: Das Arbeitsplatzhandbuch ist ein klassisches Produkt des Knowledge-Managements. Tatsächlich berühren alle nicht-technischen ITSM-Disziplinen das Thema "Wissen". Das Erfassen, Konservieren und Weitergeben von Wissen in Ihrem IT-Team sollte daher unbedingt im Fokus stehen.

Das Asset-Management hat in größeren Betrieben viele Zwecke. In einer kleineren IT-Organisation ist das primäre Ziel dieser Disziplin, die Arbeit der IT-Abteilung und ihre Kommunikation mit dem Einkauf zu erleichtern. Wenn Sie zu jeder Hard- und Software, die in Ihrem Unternehmen zum Einsatz kommt, folgende Informationen in einer durchsuchbaren Liste erfassen, haben Sie schon viel gewonnen:

- Hersteller, Modell, Seriennummer

- Lieferant und falls vorhanden Rahmenvertrag

- Supportlevel (E-Mail oder Telefon, 9/5 oder 24/7 und so weiter)

- Supportweg (E-Mail-Adresse, Link zum SR-Formular, Hinweis auf Anmeldedaten, Telefonnummer)

- Supportende

- Lage (bei Servern oder Netzwerkgeräten beispielsweise Gebäude, Raum oder Schrank)

Alle konkreten Informationen wie IP-Adressen, Versionen und Builds, Zertifikate und Ähnliches gehören in den technischen Bereich des Configuration- und Patchmanagements, das Sie vermutlich bereits beherrschen.

Das Change-Management erfüllt in allen IT-Organisationen die Aufgabe, jede Änderung zu beschreiben, bevor sie angegangen wird. Vor jeder Änderung, die gravierender ist als "normale Anpassungen im laufenden Betrieb", ist das Team gezwungen, innezuhalten und die Auswirkungen des Change noch einmal zu überdenken. Denn schließlich sorgt das Change-Management dafür, dass Anpassungen nachvollziehbar sind, solange sich alle an den vereinbarten Change-Prozess halten.

In einer kleinen Organisation brauchen Sie natürlich kein formales, in einem gewissen Turnus tagendes Change-Board. Aber bereits ein schnelles Review von "Changes mit Impact" im Team hilft zu vermeiden, dass generell freigegebene Standard-Changes und einmalige Änderungen zeitlich miteinander kollidieren. Geben Sie sich und Ihrem Team einen Change-Abstimmungsprozess und leben Sie ihn zur Probe einige Monate lang. Als kleines Team haben Sie die Freiheit, Ihre Prozesse anzupassen, wenn diese Sie in Ihrer täglichen Arbeit behindern.

Mit dem Service-Request-Management verfolgt ein kleines IT-Team etwas andere Ziele als ein großer Service-Desk in einem Konzern. In einem solchen Umfeld geht es darum, Service-Requests (SR)je nach vorhandenem Fachwissen gezielt zuzuweisen und am Ende die Performance des Service-Desks insgesamt und die der einzelnen Mitarbeiter zu messen. Ein kleines IT-Team ist jedoch bereits sehr gut bedient, wenn kein Service-Request vergessen wird und das Team aus sich häufenden Anfragen einen Incident und vielleicht sogar ein Problem ableiten kann. Wenn sich am Ende des Geschäftsjahres die Anzahl von Service-Requests pro Anwendung oder pro Fachabteilung eruieren lässt, ist es ein großes Plus. Solche Auswertungen sollten aber nicht das Verfahrensdesign für das Service-Request-Management in einem kleinen Team bestimmen.

Das Incident- und Problem-Management lassen sich in einer kleinen, aus Generalisten bestehenden IT-Organisation nicht immer klar inhaltlich unterscheiden. Lassen Sie sich hier nicht von ITIL treiben, das eine separate Betrachtung von Problemen und Incidents fordert. Es ist ausreichend, wenn Sie einen Weg finden, Incidents miteinander verlinken zu können, bei denen Ihre Mitarbeiter eine gemeinsame Ursache vermuten.

IT stellt allen Nutzern im Unternehmen Werkzeuge zur Verfügung, die ihre Arbeit erleichtern sollen, und selbstverständlich brauchen Sie auch Werkzeuge, die Ihr ITSM optimal unterstützen. Das Angebot an solchen Lösungen ist groß, und oft trennt sich die Spreu vom Weizen erst nach der Einführung. Daher sollten Sie in einem kleinen Team eher einen minimalistischen Ansatz wählen und nur für diejenigen Prozesse ein Spezialwerkzeug anschaffen, die Sie nicht anders abbilden können.

Zwei Tools, an denen Sie nicht vorbeikommen werden, sind ein Passwort-Manager und ein Wiki. Das Wiki ist eine Universalwaffe des modernen Knowledge-Managements und kann daher alle organisatorischen ITSM-Disziplinen unterstützen. Wählen Sie in beiden Fällen das Werkzeug, das zu Ihnen passt. Wenn Ihre Mitarbeiter den Passwort-Manager nur selten benutzen müssen, reicht eine kostenfreie Single-User-Lösung wie beispielsweise KeePass. Falls jeder aus Ihrem Team ständig den Passwortmanager benötigt, brauchen Sie eine mehrbenutzerfähige Lösung. Hier bietet der Markt viele Produkte, sowohl selbstgehostet als auch aus der Public Cloud.

Als Wiki für Ihre IT haben sich drei Plattformen etabliert: Für Linux-affine Puristen ist MediaWiki [5] gut geeignet. Die User Experience ist allen von Wikipedia bekannt, die Software ist kostenfrei verfügbar und es gibt exzellenten Community-Support und viele Erweiterungen. Allerdings ist die Wiki-Sprache nicht visuell, so dass sich MediaWiki nur bedingt zum schnellen Dokumentieren mit vielen Screenshots eignet. Organisationen, die bereits SharePoint einsetzen, können die dort vorhandene Wiki-Funktionalität nutzen. Die Bearbeitung erfolgt in einer Oberfläche, die an Word Online erinnert, und die wenigen Eigenarten sind schnell verinnerlicht.

Ein nahezu ideales Wiki für den IT-Bedarf ist Confluence von Atlassian. Allerdings werden seit Februar 2021 keine neuen Lizenzen mehr für den On-Premises-Betrieb verkauft. Sie sind daher gezwungen, Ihr Wiki in der Atlassian-Cloud hosten zu lassen. Klären Sie frühzeitig mit der Geschäftsleitung, ob dies in Ihrer Organisation zulässig ist. Einen großen Vorteil hat ein Cloud-Wiki in jedem Fall – seine Verfügbarkeit ist unabhängig vom Zustand Ihrer IT-Infrastruktur. Sie kommen also auch dann an den Wiederanlaufplan, wenn das gesamte Rechenzentrum abgeschaltet ist.

Sehr viele ITSM-Prozesse haben mit Listenführung zu tun. In der obigen Tabelle ist daher mehrmals von Excel die Rede. Verstehen Sie dies bitte nicht als Empfehlung, sondern lediglich als Feststellung, dass viele IT-Teams "Management by Excel" in ihre täglichen Prozesse übernommen haben. Microsoft Excel bringt für die Verwaltung von IT-Infrastrukturen und -Prozessen meist mehr Nachteile als Vorteile mit sich, Sie sollten also frühzeitig auf einen anderen "Listen-Provider" setzen. Das können SharePoint-Listen, Wiki-Tabellen oder spezialisierte Werkzeuge sein, im Asset-Management beispielsweise eine CMDB.

Ein Prozess, für den Sie unbedingt spezialisierte Tools betrachten sollten, ist das Service-Request-Management. Ein ordentliches Werkzeug ist insbesondere dann wichtig, wenn Sie den Endbenutzern die Möglichkeit einräumen möchten, SRs nicht per Mail oder Telefon, sondern direkt zu eröffnen. Obwohl einige IT-Teams ihr SR-Management erfolgreich mit SharePoint-Listen abbilden, sollten Sie auf jeden Fall ein spezialisiertes Produkt erwägen. Auch hier müssen Sie zwischen Cloud- und lokalem Betrieb wählen. Falls Sie Atlassian Confluence als Wiki einsetzen wollen, ist das Produkt "Jira" des gleichen Anbieters als Ticket-System prädestiniert, da zwischen den beiden eine enge Integration besteht. Falls Sie on-premises bevorzugen und keine Linux-Kompetenz in Ihrem Team haben, können Sie mit JitBit ein Ticket-System auf der Basis von IIS und Microsoft SQL aufbauen. Suchen Sie ein kostenfreies Produkt, werden Sie vermutlich sehr schnell auf OTRS stoßen. Leider bietet der Hersteller seit August 2020 keine Bugfixes für die kostenfreie Version mehr an.

Für welches Helpdesk-System Sie sich auch entscheiden, Sie sollten die gewünschten Prozesse – Erfassung, Eskalation et cetera – vorher festlegen und dann mit dem gewählten System abbilden. Sammeln Sie nicht zu viele Metadaten zu jedem SR, denn dies führt zu Frustration und Falscheingaben. Konzentrieren Sie sich lieber auf die notwendigen Angaben und ergänzen Sie das Ticket durch Kommentare und Anhänge.

Auch in einem kleinen Unternehmen kann es passieren, dass Sie Ihre Leistungserbringung nach einem konkreten Framework ausrichten müssen. Unternehmen in Branchen, bei denen Qualitätsmanagement-Zertifizierungen wie ISO 9000 üblich oder gar vorgeschrieben sind, finden sich gezwungen, ihre ITSM-Prozesse formal darzustellen. Auch Versicherer fordern von ihren Kunden zunehmend ein sauberes ITSM, wenn es um den Abschluss von IT-Versicherungen geht.

In solchen Fällen lohnt es sich eher, ein Mapping der eigenen Prozesse auf ITIL oder MOF vorzunehmen, als die eigenen Prozesse bis ins kleinste Detail zu beschreiben und den Auditor damit zu zwingen, sich mit diesen Beschreibungen zu beschäftigen. Erarbeiten Sie hierfür eine Art eigenes "ITIL light", das punktuell auf die ITIL-Normen passt, jedoch nur die Bereiche berührt, die für Ihre Organisation relevant sind. Oft können Sie mehrere Schritte aus dem Framework zu einem Schritt in Ihrem Prozess zusammenfassen. Auch die personelle Einheit von einigen Handelnden, obwohl von ITIL explizit abgelehnt, kann es Ihnen ermöglichen, sinnvolle Abkürzungen einzubauen. Bei Anpassungen Ihrer eigenen Prozesse müssen Sie in dieser Situation natürlich stets daran denken, sich inhaltlich nicht vom gewählten Framework zu entfernen.

Ein geordnetes IT-Management hilft, Frustration zu vermeiden, die Service-Qualität zu verbessern und die Unternehmens-IT auf Dauer sicherer und robuster zu gestalten. Mit Augenmaß und gesundem Menschenverstand können Sie es schaffen, Best Practices aus den gängigen ITSM-Frameworks sinnvoll für Ihr kleines IT-Team zu adaptieren. Lassen Sie sich dabei nicht vom Marketing der "All-In-One-ITSM-Tools" blenden, sondern geben Sie sich und Ihrem Team die Werkzeuge an die Hand, die das prozess- und ergebnisorientierte Arbeiten in einem kleinen IT-Team optimal abbilden. Ein Wiki, ein Passwort-Manager und ein einfaches Ticketsystem bringen Ihre IT-Abteilung schnell ein ganzes Stück weiter.