Mehrere ITSM-Toolhersteller und Integratoren bieten Schnittstellen zu i-doit an. Eine Frage drängt sich auf: Warum mehrere CMDBs (Configuration Management Databases)  im Unternehmen? Ist eine nicht genug? Dieser Artikel beleuchtet die unterschiedlichen Ansätze der Softwarehersteller und die Frage, wo eine Tool-Integration Nutzen bringt.

Wenn Sie beim ITSM-Tool Ihrer Wahl eine Schnittstelle zu i-doit finden, stellen sich Ihnen vermutlich mehrere Fragen: Wozu dient denn nun welches Werkzeug? Wie ändert sich der Workflow durch den Einsatz mehrerer Tools? Was soll die Schnittstelle können und was bringen? Wie wirkt sich das auf die Datenqualität aus? Brauche ich wirklich mehrere Werkzeuge?

Wenn Sie beim ITSM-Tool Ihrer Wahl eine Schnittstelle zu i-doit finden, stellen sich Ihnen vermutlich mehrere Fragen: Wozu dient denn nun welches Werkzeug? Wie ändert sich der Workflow durch den Einsatz mehrerer Tools? Was soll die Schnittstelle können und was bringen? Wie wirkt sich das auf die Datenqualität aus? Brauche ich wirklich mehrere Werkzeuge?

Sehen wir uns in der Welt der Prozesse und Tools des IT-Servicemanagements (ITSM) gemeinsam um.

ITIL-konform?

Wenn ein Hersteller die ITIL-Konformität seiner CMDB lobt, bedeutet das vorerst nicht viel. Die IT-Branche verwendet ITIL gerne als Referenzmodell. Aus dieser Best-Practice-Sammlung stammt schließlich auch der Begriff CMDB. Damit eine Software ITIL-konform ist (so ein Werkzeug zu einer Praxis überhaupt konform sein kann), muss sie ihre Assets bzw. CIs (Configuration Items) erstellen und verwalten können. Es muss einige Attribute zur Beschreibung und Unterscheidung der Objekte geben und diese sollen in Bezug (Relation) zueinander gebracht werden können, um gegenseitige Abhängigkeiten darzustellen. Das war es im Prinzip auch schon.

Die ITIL-Literatur sagt uns, wie Unternehmensabläufe praxisnah gestaltet werden können, aber nicht wie und mit welchen Werkzeugen das umzusetzen ist. Ein verbindliches Referenzmodell für Tool-Sets gibt es nicht. Es bleibt den Softwareherstellern überlassen, die niedergeschriebenen Praktiken auch tatsächlich handhabbar zu machen. Entsprechend breit ist die Auslegung. 

CMDB ist nicht gleich CMDB

Wenn das Werkzeug, das Sie betrachten, Incidents, Service Requests, Problems und Change Requests aufzeichnen kann – manchmal wird auch einfach von „Tickets“ gesprochen –, ist noch etwas anderes wichtig: der Bezug dieser „Fälle“ zu Assets und CIs.

Ein Incident Record bezieht sich auf ein oder mehrere IT-Services, die aus Kundensicht nicht so wie vereinbart zur Verfügung stehen.

(Anmerkung: ITIL ist weise. Auch eine potenzielle Unterbrechung ist es wert, aufgezeichnet zu werden. Da muss der Anwender noch gar nichts davon bemerken. Es lebe das proaktive Monitoring!)

Aus der Praxis wissen wir, dass IT-Services zweifellos existieren, nur höchst selten dokumentiert sind. Noch seltener haben sie eine definierte Qualität oder Quantität. Die Möglichkeit, einen „Fall“ zu einem oder mehreren Services zu verbinden, ist also bei der Auswahl einer ITSM-Suite gut und wichtig, wird aber anfangs selten in Anspruch genommen. Weit spannender, weil schmerzvermeidend finden es viele Anwender, herauszufinden, welches Gerät ein „Montags-Gerät“ ist und tunlichst nicht dem VIP-Anwender für’s Wochenende geliehen werden sollte.

Dazu ist es nötig, das oder die CIs in der Software mit dem jeweiligen Incident Record zu verbinden. Das bereitet Mühe. Denn die Konsequenz, bei jedem Fall auch das oder die verursachenden Geräte herauszufinden und auch tatsächlich mit dem Fall zu verbinden, muss man erstmal in das eigene Betriebssystem programmieren  – und in jenes der Kolleginnen und Kollegen. Aber: Man wird mit Auswertungen, Statistiken bzw. Reports belohnt. Man erhält Fakten statt Bauchgefühl.

Bei diesem Anwendungsfall kommt nun der CMDB-Teil der ITSM-Software ins Spiel. Die Assets, CIs und auch IT-Services finden dort ihre Heimat. Je nach Herstellerphilosophie sind mehr oder weniger Details zur Beschreibung dieser Objekte vorhanden. Für das Umsetzen des genannten Anwendungsfalles genügen jedenfalls einige wenige Attribute, um „das richtige CI“ zu identifizieren (Modell, Name, Seriennummer, evtl. Standort oder Anwender) und mit einem Incident Record verbunden zu werden. 

Die CMDB im ERP-System

So wie die ITSM-Tools auf IT-Prozesse spezialisiert sind, so sind oft viele andere Geschäftsprozesse eines Unternehmens im ERP-System abgebildet. Von Buchhaltung über Kundenverwaltung und Bestellwesen bis Mitarbeiterverwaltung: So gut wie alles kann im ERP-System abgebildet werden. Verlockend ist daher die Idee, aus dem ERP-System mit einigen individuellen Erweiterungen auch eine CMDB zu machen. Gemeint ist hier in erster Linie der Anwendungsfall des Asset-Managements, also das Verwalten von Software, Lizenzen und Hardware.

Oft findet die Ersterfassung der IT-Assets bereits bei der Bestellung statt. Spätestens bei der Lieferung tauchen sie im ERP-System auf. Hier aus einer Sammelbestellung die entsprechenden Einzelkomponenten zu generieren und diese gleich mitzuverwalten, scheint nicht schwer. Das Datenmodell der Software erlaubt mitunter die Erweiterung um eigene Attribute und das Herstellen von Relationen. Sogar die Abbildung von ITSM-Prozessen (siehe oben) ist denkbar, schließlich sind CRM-Prozesse recht ähnlich.

Was wir aus vielen Jahren Erfahrung darüber sagen können: So gut wie alle diese Projekte enden letztlich als Schnittstelle zu einer darauf spezialisierten Software. Denn die Anwendungsfälle gehen nach wenigen Monaten der Umsetzung weit über das hinaus, was man sich anfangs von einer CMDB vorstellen kann. Das ERP-Projekt wird endlos. Zum Budgetfresser, zum Super-GAU beim nächsten Releasewechsel.

 

Die CMDB als IT-Dokumentation

Anders gelagert ist der Anwendungsfall einer CMDB mit der Motivation der IT-Dokumentation. Diese Philosophie verfolgen wir mit i-doit. Wir haben uns darauf spezialisiert, (möglichst) alle Details zu Ihrer IT – Assets, Services, Configuration Items und vieles mehr – in i-doit aufzuzeichnen und ihre Konfiguration nachvollziehbar zu machen. 

Die elementare Idee ist, diese Daten in ihrer Detailtiefe nur einmal im Unternehmen erfassen zu müssen und auch an anderer Stelle und in anderen Prozessen nutzbringend verwenden zu können.

Objekte jeder Art können entweder manuell gepflegt oder mittels Schnittstelle von anderen Datenquellen importiert und ebenso aktualisiert werden. Dazu liefern wir eine große Menge vorgefertigter Objekttypen mit allen erdenklichen Attributen und Relationen. Was es nicht gibt, kann einfach und individuell erstellt werden – und zwar ohne dass Ihnen das darunter liegende Datenmodell Limits auferlegt.

Der Schwerpunkt bei der IT-Dokumentation liegt in der Detailbeschreibung. Dazu ist es nötig, die jeweiligen Datenquellen miteinzubeziehen. Ein Gesamtkonzept umfasst jedoch auch die weiteren Nutzer dieser Informationen und ihre verwendeten Systeme.

Die Ziele der Dokumentation sind ein wenig anders gelagert als bei den zuvor erwähnten Fällen. Hier drei Beispiele:

1) Dokumentieren von funktionierenden Referenz-Konfigurationen

2) Einhalten von Vorschriften („Compliance“)

3) Nachvollziehen und Kommunizieren von Änderungen 

  • Um einer Applikation (oder einem Service) eine Funktion zu ermöglichen, müssen viele Einzelkomponenten korrekt konfiguriert sein. Das beginnt bei der richtigen Konfiguration der beteiligten Hardware und reicht über die Betriebssysteme, die laufenden und korrekt konfigurierten Windows-Services und Linux-Daemons, das Netzwerk und die dem definierten Anwendungsfall entsprechend installierten und lizenzierten Applikationen bis zu Datenbanken, System-User im Directory u. v. m.

    In der IT-Dokumentation einen funktionierenden Stand all dieser Objekte abzubilden – ITIL spricht hier von der Configuration Baseline –, ist zwar viel Arbeit, kann aber über weite Strecken automatisiert werden. Bei jeder Recherche, spätestens jedoch im Fehlerfall freut man sich über die Sammlung von Fakten an einem zentralen Ort. Die Überführung dieser Dokumentation in Notfallhandbücher ist üblich und sinnvoll.

      

  • Es gibt gesetzliche Anforderungen zur Dokumentation, um die man nicht herum kommt. Am Beispiel DSGVO und des geforderten Verfahrensverzeichnisses haben unsere Anwender auch diese Dokumentationsfälle in i-doit umgesetzt. Standardanwendungen sind das Führen eines gesetzlich vorgeschriebenen IT-Asset-Verzeichnisses und das Software- und Lizenzmanagement. Auch hier ist konsequente und mitunter detaillierte Arbeit nötig, und auch hier können viele Handgriffe automatisiert werden.

    Die Dokumentationspflichten sind ja nach Branche unterschiedlich definiert. Die Automobilindustrie hat ihre eigenen Regeln, Banken haben wiederum andere. Fakt ist: IT muss immer dokumentiert werden, weil geschäftskritisch. Viele Anwender machen beim Dokumentieren keinen Unterschied mehr zwischen IT und non-IT. So halten auch Tische, Stühle und der Fuhrpark in i-doit Einzug. 
  • Bei verteilten Teams, mehreren Niederlassungen, zeitlich versetzten Tätigkeiten (Tag-/Nachtschicht) ist es nötig, den Überblick über Änderungen zu bewahren. Die weniger gute Praxis: Administratoren schreiben (manchmal auch unstrukturierte) E-Mails mit den von ihnen durchgeführten Änderungen.

    Unser Weg: Jede Änderung wird bei den betroffenen Objekten protokolliert. Jeder Berechtigte kann aus dem Logbuch auf einen Blick erkennen, wer wann was geändert hat. Diese Dokumentation der Änderungen im gleichen System, in dem auch alle anderen Details aufscheinen, macht – zusätzlich zur Baseline-Dokumentation – die Sache rund und übersichtlich.

    Falls Änderungen nun auch Bezüge zu Incidents, Service Requests oder Change Requests haben sollen, kommen Schnittstellen zum Zug.

Die Schnittstelle: IT-Dokumentation und Prozessdokumentation Hand in Hand

Man kommt recht lange ohne eine strukturierte Aufzeichnung der ITSM-Prozesse aus. Manche Administratoren fürchten die Einführung solcher Systeme, scheint man doch bei schlechter Implementierung im Papierkram zu versinken, nur um dem Prozess Genüge zu tun.

Doch irgendwann ist der Zeitpunkt erreicht, wo Incidents strukturiert und vor allem schnell abgearbeitet werden sollen. Der gewünschte Reifegrad des Prozesses erfordert auch eine entsprechend professionelle Umsetzung mit einem spezialisierten Werkzeug. 

Häufig ist die Notwendigkeit gegeben, den Schrecken und das Risiko aus Änderungen „an der IT“ zu nehmen. Vorher planen, das Risiko abschätzen, informieren, kommunizieren klingt eben anders als: nachher fixen, erklären müssen, Protokolle schreiben, zum Rapport gehen. Der Change-Prozess in hoher Reife kann das leisten. Auch hier geht es nicht ohne professionelles Werkzeug und kluge Umsetzung.

Spätestens bei der Einführung des neuen Tools prallen zwei Welten und unterschiedliche Arbeitsweisen aufeinander: Die CMDB des ITSM-Tools enthält einige Details der CIs und den Bezug zu den Incidents und Changes. Die technischen Details und alle noch so kleinen Änderungen an Konfigurationen sind jedoch in i-doit dokumentiert.

Eine Schnittstelle soll nun …

1) die Details der i-doit-Objekte in der ITSM-Suite sichtbar (und durchsuchbar) machen.

2) die Bedienung von zwei Werkzeugen und doppelte Datenpflege vermeiden helfen.

3) die betroffenen Geräte und CIs aus i-doit zu den jeweiligen Fällen dazuheften (linken).

4) einen Vermerk (backlink) in i-doit anbringen, dass ein Fall aufgetreten oder in Zukunft geplant ist.

5) das Auslösen von Incidents, Problems und Changes von einem i-doit-Objekt aus auf kurzem Weg ermöglichen.

Sind diese fünf Kriterien erfüllt, können beide Seiten vernünftig weiterarbeiten und man kann von optimaler Prozessintegration sprechen. Jene, die primär mit der ITSM-Suite arbeiten – zumeist wird das der Service Desk sein –, erhalten i-doit-Informationen. Und jene, die sich täglich um die Details kümmern, arbeiten weiterhin primär in der IT-Dokumentation. Sie  erhalten auch einen schnellen und einfachen Zugang zur Prozessdokumentation.

Funktionsweisen und Umfang bei den Schnittstellen der Hersteller unterscheiden sich naturgemäß. Doch schließlich ist es nur ein kleines Stück Software, das meist ohne großen Aufwand um weitere Funktionen erweitert werden kann.

 

Noch einmal Best Practice: Das CMS

Wem bei den Erklärungen zu ITIL der Begriff CMS fehlte, dem sei hier eine Würdigung dieses Konzepts nachgereicht: Seit ITIL 3 wird nicht mehr ausschließlich von „der“ CMDB (Configuration Management Database) gesprochen, sondern darauf hingewiesen, dass es zumeist deren mehrere im Unternehmen gibt. Die Gesamtmenge aller CMDBs stellt dann das CMS (Configuration Management System) dar. Das wurde auch mit der recht neuen ITIL-Version 4 beibehalten.

Dem können wir aus der Sicht unserer Anwender nur beipflichten, und wir sagen einmal mehr: Es geht um intelligente Schnittstellen!

  • Die ERP-Systeme haben, wie oben geschildert, Funktionen, die eine Art CMDB darstellen.
  • Die ITSM-Tools haben allesamt eigene CMDBs – mit mehr oder weniger hohem  Detailgrad.
  • Die IT-Dokumentation ist – im Fall von i-doit – eine CMDB mit dem Anspruch einer Informationsdrehscheibe: Alle anderen verfügbaren Informationen sollen entweder direkt hier abgebildet und laufend aktualisiert werden oder live eingeblendet, zumindest jedoch verlinkt sein. Auf jeden Fall: einfach erreichbar!
  • Die Werkzeuge der IT-Abteilung für Softwareverteilung, das Management von virtuellen Maschinen, die Provisionierung von Containern, die Überwachung (Monitoring) von Servern, Netzwerkgeräten, Druckern, Applikationen und IT-Services, das Management von Applikationen und der IT-Security sind jeweils hoch spezialisierte CMDBs – mit jeweils unterschiedlichen Teilmengen an Informationen.
  • Die Cloud-Verwaltungswerkzeuge kommen ebenfalls hinzu und liegen oftmals gar nicht in der Hand der IT! Auch sie stellen wesentliche Informationen über den Informationsverbund Ihres Unternehmens dar. Diese Informationen bilden einen wichtigen Teil der IT-Dokumentation, denn an die IT wendet sich der verzweifelte Anwender, wenn etwas nicht funktioniert. Ohne diese Informationen entstehen weiße Flecken auf Ihrer IT-Landkarte.

Zusammenfassung

Mit steigendem Reifegrad Ihrer ITSM-Prozesse ist der Einsatz professioneller ITSM-Tools unumgänglich. Ebenso hält mit jeder neuen Technologie ein neues Verwaltungswerkzeug Einzug in Ihr Unternehmen. Die Spezialisten bilden jeweils Teilaspekte ab. Die zentrale IT-Dokumentation ist aber nicht komplett, wenn diese Informationen fehlen.

Intelligente Schnittstellen von und zu i-doit ermöglichen integrierte Prozesse über Toolgrenzen hinweg. Sie sind das Mittel der Wahl, um in erster Linie eines zu schaffen: den Gesamtüberblick über Ihre IT zu bewahren. 

Weiterführende Links

Zammad Schnittstelle:

https://www.i-doit.com/blog/intuitiv-bedienbar-zammad-und-i-doit/

OTRS-Schnittstellen:

https://www.i-doit.com/blog/otrs-partner-schnittstellen/

becon Open Source APU-Hub OpenCelium:

https://opencelium.io/

https://www.becon.de/pm-early-adopter-programm-opencelium/

i-doit Schnittstelle von i-Top:

https://www.itomig.de/shop/product/i-doit-integration-81?category=8

i-doit Schnittstelle zu KIX:

https://www.kixdesk.com/de/zusatzmodule/kixconnect.html

Die i-doit API:

https://kb.i-doit.com/pages/viewpage.action?pageId=7831613

„ITIL® is a (registered) Trade Mark of AXELOS Limited. All rights reserved.“