von Redaktion IT-A…
Lesezeit
6 Minuten
IT-Dokumentation
In der IT-Administration soll die IT-Dokumentation beschreiben, was existiert, wie es betrieben wird und dessen Schutz aussieht. Doch diese Aufgabe wird bei gut der Hälfte aller IT-Abteilungen ohne vernünftige Methodik angepackt. Abhilfe ist einfacher, als viele denken: Weil niedrigschwellige Tools verfügbar sind, ist es nur eine Frage der Überwindung, bis Admins endlich aus ihrem IT-Brachland fruchtbare Weiden machen.
Dokumentation definiert
Beginnen wir zunächst mit einer vermeintlich banalen Frage, was eigentlich unter "Dokumentation" im Allgemeinen und unter "IT-Dokumentation" im Speziellen zu verstehen ist. Bei Ersterem finden wir über Suchmaschinen verschiedenen Interpretationen, die jedoch eine Gemeinsamkeit aufweisen. Es geht um die "Nutzbarmachung von Informationen". Diese "Nutzbarmachung" wird an dem Beispiel Bibliothek schnell deutlich. Eine Bibliothek ohne das Wissen über deren Inhalt ist ein Haufen Papier und somit nutzlos. Erst wenn Standort, Art, Ausprägung und Inhalt der einzelnen Werke bekannt, verfüg- und abfragbar sind, entsteht ein nutzbares Wissen. Das ist das Wesen der Dokumentation.
Der Begriff "IT-Dokumentation" wird dagegen sehr flexibel verwendet. So werden Inventory- oder Discovery-Lösungen schon mal unbedacht um das Attribut "IT-Dokumentation" erweitert, obwohl sie in der Regel nur eine von zwei Ebenen der Information liefern, die zu einer Nutzbarkeit führen. Aber der Reihe nach: Am Beispiel einer noch allseits bekannten, handelsüblichen Computer-Tastatur können wir diese beiden Informationsebenen, die für eine grundsätzliche Nutzbarkeit erforderlich sind, sehr schön verdeutlichen. Eine Tastatur ohne Beschriftung liefert nur eine strukturelle Information. Der Nutzer erkennt, dass es sich um eine solche handelt, wird sie aber in diesem Zustand nicht bedienen können. Es fehlt die funktionale Ebene, in diesem Fall die Beschriftung. Erst damit wird das Gerät nutzbar. Genauso verhält es sich bei der IT-Dokumentation. Die strukturellen Informationen einer IT-Umgebung (Geräte/Systeme und ihre technische Ausprägung) können von Inventory- oder Discovery-Programmen zugeliefert werden. Aber sie müssen um die funktionalen Beziehungen angereichert werden, um zu nutzbaren Informationen für Betreiber und Verantwortliche zu werden. Darunter fallen dann zum Beispiel erweiterte technische und logische Abhängigkeiten, Standort- und Vertragsdaten oder Kontaktzuordnungen. Mit diesem Grundverständnis können wir uns nun den zentralen Fragen bei der Umsetzung einer erfolgreichen IT-Dokumentation zuwenden.
Einstieg über den Konfigurations-Management-Plan
Auch das Dokumentieren will dokumentiert werden: Der Konfigurations-Management-Plan (KMP) liefert hierbei die Antworten auf die Fragen "Wer, Wie, Was?" und wird fortlaufend aktualisiert. Er ist schriftlich fixiert und von allen Beteiligten einsehbar.
Für einen solchen KMP braucht es natürlich einen Verantwortlichen, der – je nach Unternehmensgröße – von einem Team begleitet wird, das die verschiedenen Bereiche der eigenen IT abdeckt (zum Beispiel Server, Netze, Clients oder Security). Mit dem entsprechenden Mandat ausgestattet, befasst sich dieses Projektteam im Wesentlichen mit den Ausarbeitungen für den KMP.
Erfahrungsgemäß ist die Ausprägung des "Was" die aufwändigste Arbeit und bestimmt zum Teil die Antworten auf die weiteren Fragen. Also ein guter Grund, mit genau diesem Punkt zu beginnen. Welcher Informationsgehalt muss Ihnen also bekannt (verfüg- und abfragbar) sein, um eine echte Hilfestellung zu liefern? Bei dieser Festlegung müssen Sie verschiedene Einflussfaktoren berücksichtigen. Es gibt zunächst natürlich die Anforderungen der unmittelbaren Teilhaber, die die Datenbasis für ihre tägliche Arbeit benötigen und diese selber auch pflegen. Hier sind die in nahezu allen Umgebungen bestehenden Inseldokumentationen (Serverlisten, Netztabellen et cetera mit spezifischem Informationsgehalt) ein guter Anhaltspunkt für die Ausprägung der gemeinsamen Dokumentationsumgebung. Daneben können Anforderungen aus der Buchhaltung, aus in- oder externen Audits, aus dem Datenschutz oder bezüglich IT-Sicherheit und viele weiteren Faktoren eine Rolle spielen und müssen bei der Ausprägung berücksichtigt werden. Insgesamt sollten Sie bei der Antwort auf das "Was" aber das Gebot der Datensparsamkeit im Auge behalten. Mehr geht immer und gerade für den Start sollten Sie die Latte nicht höher als nötig legen. Das gibt allen Beteiligten die Möglichkeit, sich an das Thema und die damit verbundenen Arbeiten zu gewöhnen.
Damit bewegen wir uns auch schon auf die zweite Frage nach dem "Wie" zu, die klärt, woher die Daten eigentlich kommen und wann Änderungen dokumentiert werden. Dabei müssen Sie zunächst eine weitere Grundsatzfrage der Dokumentation klären: SOLL oder IST? Oder anders ausgedrückt: erfolgt das Befüllen der Konfigurationsdatenbank rein manuell oder durch Einsatz von automatisierten Zulieferungen? Ersteres ist der theoretisch richtige Weg, Letzteres die praktikablere Lösung. Dabei sollten Sie immer zwei Phasen unterscheiden: die Befüllung mit dem gewünschten Gesamtbestand zu Beginn und die laufende Pflege der Änderungsdaten im Betrieb.
Dokumentation im laufenden Betrieb
Beide Phasen werden im KMP abgebildet, aber wir wollen uns jetzt auf die zweite Phase, den eigentlichen Betrieb konzentrieren. Auch wenn Zulieferer wie Inventory- oder Discovery-Programme die Aktualisierung vieler Detaildaten in regelmäßigen Zeitintervallen übernehmen, bleiben manuelle Arbeiten meist nicht aus, beispielsweise um Vertragsdaten, passive Komponenten oder Verfahren einzupflegen. Hier gilt es für Sie, Verantwortlichkeiten und Zeitpunkte festzulegen, um die Aktualität des Datenbestands sicherzustellen. Sollen Änderungen – und von nichts anderem reden wir nach der Inbetriebnahme mehr – vor der Durchführung als eine Art Änderungsauftrag dokumentiert werden oder findet die Dokumentation nach getaner Arbeit statt? Ist dann der Durchführende oder der Beauftragende dokumentationspflichtig? Diese Frage müssen Sie vorab klären.
Und wenn wir schon bei Verantwortlichkeiten sind, kommen wir damit zum "Wer". Dabei sollten Sie berücksichtigen, dass nicht jede hier beschriebene Rolle durch eigene Personen zu besetzen ist. ITDokumentation ist in nahezu jeder Organisation ein Thema und bei kleineren Unternehmen lassen sich natürlich auch mehrere Rollen in einer Person verankern. Da gibt es natürlich zunächst einmal das Team, also die Gesamtheit aller aktiven Nutzer der Dokumentation. Neben der Nutzung selber haben diese Teilhaber im Übrigen auch Einfluss auf die Weiterentwicklung des Dokumentationssystems im Sinne neuer Anforderungen oder Erweiterungen. Daneben gibt es den System-Verantwortlichen, der sich zum einen um den Betrieb des Dokumentationssystems kümmert, neue Anforderungen umsetzt, aber auch deren Vorbereitung und die notwendige Kommunikation koordiniert. Hierzu gehört unter anderem die Fortschreibung des KMP. Er wird begleitet von der Steuerungsgruppe, die idealerweise die verschiedenen Teilhaber repräsentiert. Hier bietet sich natürlich das eingangs erwähnte Projektteam für den Start an. Die Steuerungsgruppe entscheidet über Erweiterungen und/oder Änderungen am KMP und unterstützt das Team bei der konsequenten Umsetzung. Zu guter Letzt fehlt noch ein Sponsor, der die notwendigen Ressourcen freigibt und auch den fortlaufenden Betrieb unterstützend begleitet. Das Schöne ist, dass eine aktuelle IT-Dokumentation als aktives Arbeitsinstrument laut Umfragen durchschnittlich 20 Prozent Arbeitszeit einspart. Damit dürfte es Ihnen nicht schwerfallen, Unterstützer in der Organisation zu gewinnen.
Auf der Suche nach dem passenden Tool
Natürlich soll die Frage nach dem passenden Werkzeug nicht unberücksichtigt bleiben. Im Grundsatz stellt sich unabhängig vom Produkt immer die Frage, ob die eigene Dokumentation strukturiert oder unstrukturiert erfolgen soll. Sprich: soll eine Datenbank zum Einsatz kommen oder reicht auch ein Wiki beziehungsweise ein Unternehmens-Intranet/CMS. Bei den Datenbank-gestützten Systemen, mal abgesehen von nicht anzuratenden Eigenentwicklungen, stellen sich heute eine Reihe von Anbietern mit ihren Dokumentationslösungen am Markt auf. Diese reichen von Open-Source-Angeboten über professionelle Lösungen bis hin zu hochpreisigen und proprietären Sonderprodukten. Sie sind teilweise auf einzelne Plattformen beschränkt und haben meist entweder einen Fokus auf strukturelle oder auf funktionale Daten.
Den Sprung zu einer strukturierten Lösung sollten Sie immer dann ins Auge fassen, wenn viele Referenzen dokumentiert werden müssen. Um beispielsweise sichtbar und damit nutzbar zu machen, welche Software wo installiert ist oder welche Kontakt- oder auch Vertragszuordnungen bestehen. Hier haben unstrukturierte Lösungen wie etwa ein Wiki den entscheidenden Nachteil, dass Beziehungen enthaltende Daten redundant eingetragen werden müssen und eben keine echten Referenzen zwischen Objekten gebildet werden können, was mit einer hohen Fehleranfälligkeit einhergeht. In manchen Fällen ist allerdings eine Kombination beider Ansätze hilfreich. So lassen sich in einem kontextbezogenen Wiki-Eintrag Freitexteinträge wie zum Beispiel Servertagebücher pflegen. Es hängt also viel ab vom identifizierten Informationsgehalt (dem "Was"), um zu entscheiden, welche Werkzeuge ein geeigneter Begleiter sein können. Wichtigstes Kriterium sollte immer die Wiederverwendbarkeit der Daten sein.
Und wert, in die engere Wahl zu kommen, sind Werkzeuge mit möglichst generischen Exportformaten. Nur sie erlauben es einem Nutzer, das Tool im Zweifel mit geringem Migrationsaufwand zu wechseln, wenn Anforderungen steigen oder Erwartungen nicht erfüllt werden. Alles in allem ist eine aktuelle, gemeinsame IT-Dokumentation ein lohnendes Terrain. Neben der direkten Zeitersparnis für den operativen Betrieb ergeben sich mit diesen Daten vielfältige Sekundäreffekte, die je nach Organisationsgröße mal mehr, mal weniger relevant sein können. Getreu nach Goethe, denn "man sieht nur, was man weiß", bildet eine aktuelle IT-Dokumentation die Basis für IT-Sicherheit, Datenschutz, Compliance, CMDB/ITIL und Planung. Mit der richtigen Vorbereitung, dem gemeinsamen Willen und einem passenden Werkzeug ist der Acker bereits bereitet, um diese Effekte auch in seine Organisation zu holen. Dennoch sind viele Unternehmen organisatorisch überfordert. Ihre Admins machen einen guten Job, fühlen sich aber von Herstellern allein gelassen. Bei Ressourcenknappheit und Automatisierungsdruck keine schöne Basis.
Als passendes Open Source-Werkzeug steht seit Jahren etwa i-doit [1] – ergänzt durch kommerzielle Module – bereit. Als Vermittler und Regisseur der ITIL-Disziplinen sorgt das Tool dafür, dass die spezialisierten Tools ihre Daten austauschen und dem Admin eine zunehmend geschlossene Sicht auf sein ITSM erlauben. Diese Idee setzt sich zunehmend schneller durch. Dennoch gibt es nach wie vor viele Admins, die noch nicht aufgesprungen sind, weil sie entweder noch den old way gehen oder nicht die Zeit finden, ihre Dokumentation zu füllen. An dieser Stelle gilt: Wer nicht weiß, was er hat, weiß auch nicht, was er tut und ob er das, womit er es tut, ordentlich und sicher betreibt. Und gerät damit in die Gewährleistungs-Falle. Haftung für IT-Verantwortliche ist heute kein Tabu mehr – verantwortlich ist nicht nur der CIO, sondern auch der CEO. Damit haben IT-Dokumentation und ITSM auch Management-Relevanz.
Konrad Buck/jp
[1] http://www.i-doit.org/
Beginnen wir zunächst mit einer vermeintlich banalen Frage, was eigentlich unter "Dokumentation" im Allgemeinen und unter "IT-Dokumentation" im Speziellen zu verstehen ist. Bei Ersterem finden wir über Suchmaschinen verschiedenen Interpretationen, die jedoch eine Gemeinsamkeit aufweisen. Es geht um die "Nutzbarmachung von Informationen". Diese "Nutzbarmachung" wird an dem Beispiel Bibliothek schnell deutlich. Eine Bibliothek ohne das Wissen über deren Inhalt ist ein Haufen Papier und somit nutzlos. Erst wenn Standort, Art, Ausprägung und Inhalt der einzelnen Werke bekannt, verfüg- und abfragbar sind, entsteht ein nutzbares Wissen. Das ist das Wesen der Dokumentation.
Der Begriff "IT-Dokumentation" wird dagegen sehr flexibel verwendet. So werden Inventory- oder Discovery-Lösungen schon mal unbedacht um das Attribut "IT-Dokumentation" erweitert, obwohl sie in der Regel nur eine von zwei Ebenen der Information liefern, die zu einer Nutzbarkeit führen. Aber der Reihe nach: Am Beispiel einer noch allseits bekannten, handelsüblichen Computer-Tastatur können wir diese beiden Informationsebenen, die für eine grundsätzliche Nutzbarkeit erforderlich sind, sehr schön verdeutlichen. Eine Tastatur ohne Beschriftung liefert nur eine strukturelle Information. Der Nutzer erkennt, dass es sich um eine solche handelt, wird sie aber in diesem Zustand nicht bedienen können. Es fehlt die funktionale Ebene, in diesem Fall die Beschriftung. Erst damit wird das Gerät nutzbar. Genauso verhält es sich bei der IT-Dokumentation. Die strukturellen Informationen einer IT-Umgebung (Geräte/Systeme und ihre technische Ausprägung) können von Inventory- oder Discovery-Programmen zugeliefert werden. Aber sie müssen um die funktionalen Beziehungen angereichert werden, um zu nutzbaren Informationen für Betreiber und Verantwortliche zu werden. Darunter fallen dann zum Beispiel erweiterte technische und logische Abhängigkeiten, Standort- und Vertragsdaten oder Kontaktzuordnungen. Mit diesem Grundverständnis können wir uns nun den zentralen Fragen bei der Umsetzung einer erfolgreichen IT-Dokumentation zuwenden.
Einstieg über den Konfigurations-Management-Plan
Auch das Dokumentieren will dokumentiert werden: Der Konfigurations-Management-Plan (KMP) liefert hierbei die Antworten auf die Fragen "Wer, Wie, Was?" und wird fortlaufend aktualisiert. Er ist schriftlich fixiert und von allen Beteiligten einsehbar.
Für einen solchen KMP braucht es natürlich einen Verantwortlichen, der – je nach Unternehmensgröße – von einem Team begleitet wird, das die verschiedenen Bereiche der eigenen IT abdeckt (zum Beispiel Server, Netze, Clients oder Security). Mit dem entsprechenden Mandat ausgestattet, befasst sich dieses Projektteam im Wesentlichen mit den Ausarbeitungen für den KMP.
Erfahrungsgemäß ist die Ausprägung des "Was" die aufwändigste Arbeit und bestimmt zum Teil die Antworten auf die weiteren Fragen. Also ein guter Grund, mit genau diesem Punkt zu beginnen. Welcher Informationsgehalt muss Ihnen also bekannt (verfüg- und abfragbar) sein, um eine echte Hilfestellung zu liefern? Bei dieser Festlegung müssen Sie verschiedene Einflussfaktoren berücksichtigen. Es gibt zunächst natürlich die Anforderungen der unmittelbaren Teilhaber, die die Datenbasis für ihre tägliche Arbeit benötigen und diese selber auch pflegen. Hier sind die in nahezu allen Umgebungen bestehenden Inseldokumentationen (Serverlisten, Netztabellen et cetera mit spezifischem Informationsgehalt) ein guter Anhaltspunkt für die Ausprägung der gemeinsamen Dokumentationsumgebung. Daneben können Anforderungen aus der Buchhaltung, aus in- oder externen Audits, aus dem Datenschutz oder bezüglich IT-Sicherheit und viele weiteren Faktoren eine Rolle spielen und müssen bei der Ausprägung berücksichtigt werden. Insgesamt sollten Sie bei der Antwort auf das "Was" aber das Gebot der Datensparsamkeit im Auge behalten. Mehr geht immer und gerade für den Start sollten Sie die Latte nicht höher als nötig legen. Das gibt allen Beteiligten die Möglichkeit, sich an das Thema und die damit verbundenen Arbeiten zu gewöhnen.
Damit bewegen wir uns auch schon auf die zweite Frage nach dem "Wie" zu, die klärt, woher die Daten eigentlich kommen und wann Änderungen dokumentiert werden. Dabei müssen Sie zunächst eine weitere Grundsatzfrage der Dokumentation klären: SOLL oder IST? Oder anders ausgedrückt: erfolgt das Befüllen der Konfigurationsdatenbank rein manuell oder durch Einsatz von automatisierten Zulieferungen? Ersteres ist der theoretisch richtige Weg, Letzteres die praktikablere Lösung. Dabei sollten Sie immer zwei Phasen unterscheiden: die Befüllung mit dem gewünschten Gesamtbestand zu Beginn und die laufende Pflege der Änderungsdaten im Betrieb.
Dokumentation im laufenden Betrieb
Beide Phasen werden im KMP abgebildet, aber wir wollen uns jetzt auf die zweite Phase, den eigentlichen Betrieb konzentrieren. Auch wenn Zulieferer wie Inventory- oder Discovery-Programme die Aktualisierung vieler Detaildaten in regelmäßigen Zeitintervallen übernehmen, bleiben manuelle Arbeiten meist nicht aus, beispielsweise um Vertragsdaten, passive Komponenten oder Verfahren einzupflegen. Hier gilt es für Sie, Verantwortlichkeiten und Zeitpunkte festzulegen, um die Aktualität des Datenbestands sicherzustellen. Sollen Änderungen – und von nichts anderem reden wir nach der Inbetriebnahme mehr – vor der Durchführung als eine Art Änderungsauftrag dokumentiert werden oder findet die Dokumentation nach getaner Arbeit statt? Ist dann der Durchführende oder der Beauftragende dokumentationspflichtig? Diese Frage müssen Sie vorab klären.
Und wenn wir schon bei Verantwortlichkeiten sind, kommen wir damit zum "Wer". Dabei sollten Sie berücksichtigen, dass nicht jede hier beschriebene Rolle durch eigene Personen zu besetzen ist. ITDokumentation ist in nahezu jeder Organisation ein Thema und bei kleineren Unternehmen lassen sich natürlich auch mehrere Rollen in einer Person verankern. Da gibt es natürlich zunächst einmal das Team, also die Gesamtheit aller aktiven Nutzer der Dokumentation. Neben der Nutzung selber haben diese Teilhaber im Übrigen auch Einfluss auf die Weiterentwicklung des Dokumentationssystems im Sinne neuer Anforderungen oder Erweiterungen. Daneben gibt es den System-Verantwortlichen, der sich zum einen um den Betrieb des Dokumentationssystems kümmert, neue Anforderungen umsetzt, aber auch deren Vorbereitung und die notwendige Kommunikation koordiniert. Hierzu gehört unter anderem die Fortschreibung des KMP. Er wird begleitet von der Steuerungsgruppe, die idealerweise die verschiedenen Teilhaber repräsentiert. Hier bietet sich natürlich das eingangs erwähnte Projektteam für den Start an. Die Steuerungsgruppe entscheidet über Erweiterungen und/oder Änderungen am KMP und unterstützt das Team bei der konsequenten Umsetzung. Zu guter Letzt fehlt noch ein Sponsor, der die notwendigen Ressourcen freigibt und auch den fortlaufenden Betrieb unterstützend begleitet. Das Schöne ist, dass eine aktuelle IT-Dokumentation als aktives Arbeitsinstrument laut Umfragen durchschnittlich 20 Prozent Arbeitszeit einspart. Damit dürfte es Ihnen nicht schwerfallen, Unterstützer in der Organisation zu gewinnen.
Auf der Suche nach dem passenden Tool
Natürlich soll die Frage nach dem passenden Werkzeug nicht unberücksichtigt bleiben. Im Grundsatz stellt sich unabhängig vom Produkt immer die Frage, ob die eigene Dokumentation strukturiert oder unstrukturiert erfolgen soll. Sprich: soll eine Datenbank zum Einsatz kommen oder reicht auch ein Wiki beziehungsweise ein Unternehmens-Intranet/CMS. Bei den Datenbank-gestützten Systemen, mal abgesehen von nicht anzuratenden Eigenentwicklungen, stellen sich heute eine Reihe von Anbietern mit ihren Dokumentationslösungen am Markt auf. Diese reichen von Open-Source-Angeboten über professionelle Lösungen bis hin zu hochpreisigen und proprietären Sonderprodukten. Sie sind teilweise auf einzelne Plattformen beschränkt und haben meist entweder einen Fokus auf strukturelle oder auf funktionale Daten.
Den Sprung zu einer strukturierten Lösung sollten Sie immer dann ins Auge fassen, wenn viele Referenzen dokumentiert werden müssen. Um beispielsweise sichtbar und damit nutzbar zu machen, welche Software wo installiert ist oder welche Kontakt- oder auch Vertragszuordnungen bestehen. Hier haben unstrukturierte Lösungen wie etwa ein Wiki den entscheidenden Nachteil, dass Beziehungen enthaltende Daten redundant eingetragen werden müssen und eben keine echten Referenzen zwischen Objekten gebildet werden können, was mit einer hohen Fehleranfälligkeit einhergeht. In manchen Fällen ist allerdings eine Kombination beider Ansätze hilfreich. So lassen sich in einem kontextbezogenen Wiki-Eintrag Freitexteinträge wie zum Beispiel Servertagebücher pflegen. Es hängt also viel ab vom identifizierten Informationsgehalt (dem "Was"), um zu entscheiden, welche Werkzeuge ein geeigneter Begleiter sein können. Wichtigstes Kriterium sollte immer die Wiederverwendbarkeit der Daten sein.
Und wert, in die engere Wahl zu kommen, sind Werkzeuge mit möglichst generischen Exportformaten. Nur sie erlauben es einem Nutzer, das Tool im Zweifel mit geringem Migrationsaufwand zu wechseln, wenn Anforderungen steigen oder Erwartungen nicht erfüllt werden. Alles in allem ist eine aktuelle, gemeinsame IT-Dokumentation ein lohnendes Terrain. Neben der direkten Zeitersparnis für den operativen Betrieb ergeben sich mit diesen Daten vielfältige Sekundäreffekte, die je nach Organisationsgröße mal mehr, mal weniger relevant sein können. Getreu nach Goethe, denn "man sieht nur, was man weiß", bildet eine aktuelle IT-Dokumentation die Basis für IT-Sicherheit, Datenschutz, Compliance, CMDB/ITIL und Planung. Mit der richtigen Vorbereitung, dem gemeinsamen Willen und einem passenden Werkzeug ist der Acker bereits bereitet, um diese Effekte auch in seine Organisation zu holen. Dennoch sind viele Unternehmen organisatorisch überfordert. Ihre Admins machen einen guten Job, fühlen sich aber von Herstellern allein gelassen. Bei Ressourcenknappheit und Automatisierungsdruck keine schöne Basis.
Als passendes Open Source-Werkzeug steht seit Jahren etwa i-doit [1] – ergänzt durch kommerzielle Module – bereit. Als Vermittler und Regisseur der ITIL-Disziplinen sorgt das Tool dafür, dass die spezialisierten Tools ihre Daten austauschen und dem Admin eine zunehmend geschlossene Sicht auf sein ITSM erlauben. Diese Idee setzt sich zunehmend schneller durch. Dennoch gibt es nach wie vor viele Admins, die noch nicht aufgesprungen sind, weil sie entweder noch den old way gehen oder nicht die Zeit finden, ihre Dokumentation zu füllen. An dieser Stelle gilt: Wer nicht weiß, was er hat, weiß auch nicht, was er tut und ob er das, womit er es tut, ordentlich und sicher betreibt. Und gerät damit in die Gewährleistungs-Falle. Haftung für IT-Verantwortliche ist heute kein Tabu mehr – verantwortlich ist nicht nur der CIO, sondern auch der CEO. Damit haben IT-Dokumentation und ITSM auch Management-Relevanz.
Konrad Buck/jp
[1] http://www.i-doit.org/
