Toni Portas hat sich bereits mit dem Thema CSV Import in i-doit beschäftigt um Stammdaten in die neue CMDB zu importieren. Bald hat er herausgefunden, dass er mit der manuellen Eingabe von Daten in die Applikation stets langsamer ist, als wenn er sie auf einen Rutsch importieren kann. Noch flotter wird er, wenn er neue Datensätze beim Import mit bereits bestehenden Datensätzen verknüpft. So spart er gleich mehrere Arbeitsgänge. Bereits beim Import verknüpft er Geräte mit Standorten. Er schöpft Hoffnung. Sollte das alles so einfach sein?

Offizieller Start

Doch vorerst geht es um das Abholen und Prüfen der Dateien, die bisher als Dokumentation gedient haben. Toni weiß natürlich, wo diese abgelegt sind. Aber Projektleiter Max hat ihm geraten diese “offiziell” abzuholen. Dem Team soll klar sein, dass Toni an “ihren” Daten arbeitet.

Im Teammeeting stellt Junior sein Vorhaben vor:

  • “Vorerst will ich mich nur um Hardware kümmern, alle anderen Daten lasse ich möglichst unberührt”. Das ist sein momentaner Projekt-Scope, auf den will er sich beschränken.
    Dies führt im Team zu Kopfschütteln. Gerne hätten sie das Thema bereits erledigt. Nach einigen Diskussionen verstehen aber alle, dass sich Toni eine neue Methode aneignet. Mit dem überschaubaren Scope wird er hier schneller fertig sein. Nun ist auch allen klar, dass sie Änderungen an Hardware Toni informieren müssen.
  • “Ich möchte gerne Zugriff auf eure gesamte Dokumentation erhalten. Ich will prüfen, was mehrfach dokumentiert wurde und was eventuell gar nicht. Außerdem will ich die Aktualität verifizieren: Was ist aktuell und gültig, was ist veraltet? Ich muss mir auch ein Bild machen, welche Datensätze vor dem Import bearbeitet werden müssen”.

Auch beim zweiten Punkt stößt er auf unterschiedliche Reaktionen. Einige senden noch im Meeting eine Kopie ihrer Dateien per e-Mail an ihn, (“sieh es dir an, viel Spaß …”), während vor allem ein Kollege keine Anstalten macht, seine Dokumentation auch nur zu zeigen.

Widerstand aus den eigenen Reihen

David Sendo, der Netzwerk-Administrator gilt allseits als sehr sicherheitsbewusst. Für einige Kollegen geht das, was David nun sagt allerdings zu weit:

“Ich stufe es als Sicherheitsrisiko ein, dir, Anton, meine gesamte Netzwerk-Dokumentation zu übergeben. Solange ich nicht nachvollziehen kann, was du damit machst, bekommst du gar nichts von mir. Ich habe mir meine eigene Dokumentation erarbeitet, habe alle Informationen bei mir, sauber, in einem eigenen Tool. Ich brauche euer CMDB Projekt nicht, erkenne für mich keinen Mehrwert. Und wie gesagt: Zeigt mir mal, wie sicher das alles ist, dann reden wir weiter.”

Es knistert im Raum. Während Toni vor den Kopf gestoßen ist, deeskaliert Projektleiter Max: “David. Wir zeigen dir, was wir haben, wem es nutzt, wozu es dient. Gib uns ein wenig Zeit – dann siehst auch du die Vorteile. Ich bin sicher: Es ist etwas dabei, das du selbst nicht hast und auch alleine nicht erreichen kannst. Und um die Sicherheit der Daten werden wir uns gemeinsam kümmern.” David grummelt ein: “Na, da bin ich mal gespannt”.

Daten sichten, schlichten und sortieren

Die nun folgende Arbeit macht Toni wenig froh. Er sieht jedoch die Notwendigkeit der einmaligen Datenübernahme ein. Fehlende Primärschlüssel, um Objekte eindeutig identifizieren zu können, hat er sofort als Mangel identifiziert. Die Seriennummer könnte dazu taugen. Da es jedoch eine große Menge an Einträgen ohne dieses Erkennungsmerkmal gibt, müsste er künstliche Seriennummern erfinden, um die Redundanz aufzulösen. Das gefällt Toni gar nicht. Er bevorzugt eine zusätzliche ID, die bestenfalls nie wieder geändert wird, also für den gesamten Lebenszyklus im Unternehmen gilt.

Bei der Analyse der Bestandsdaten trifft ihn noch eine weitere Erkenntnis: Bei vielen Einträgen kann er nur raten, worum es sich handelt. Für Manche ist ja eine Typenbezeichnung klar und sprechend, für Andere der Hostname. Toni aber braucht eine Übersetzung: Hier handelt es sich um einen Drucker, das ist Serverhardware, das ist Netzwerk-Equipment. Diese Unterscheidung gibt es nicht. Er beginnt zu verstehen: Die bisherige Dokumentation war als Ergänzung für jene Informationen gedacht, die sowieso “im Kopf” sind. Aber nicht in seinem … Die neue CMDB wird auch ein Kommunikationsmedium für die gesamte Abteilung sein.

Bei der Sichtung der Daten stellt er fest, dass er wohl einige Datensätze nicht importieren kann:

IP-Adresse Hostname Anschaffungsdatum Garantie bis Serien #
10.13.12.11

s174

16.12.2014 15.12.2016 4711
10.10.22.26

p142

lange ist es her 3 Jahre 19034567p5
10.10.12.19

s822

? ?? 1234h0483

 

Tabellen sind leider sehr geduldig. Hier muss noch vor dem Import Hand angelegt werden, Toni nennt das “Daten-Clearing”. Schön langsam beginnt er eine Allergie gegen Tabellen zu entwickeln. So schnell wie möglich möchte er davon weg kommen. Die Liste seiner gefundenen Mängel in der bisherigen Dokumentation liest sich so:

 

  • Fehlende Primärschlüssel
  • Fehlende Typisierung der Geräte
  • Vermischung von Datentypen (Datum/Text)
  • Unklare Aktualität der Datensätze
  • Redundante Einträge über mehrere Dateien
  • Unterschiedliche Datenqualität

Diese Mängel aufzulösen bedeutet:

  • Generieren neuer Primärschlüssel
    Hier wird sich Toni mit dem Projektleiter zusammen setzen um eine Nomenklatur auszuarbeiten.
  • Analyse und Definition von Objekttypen
    Ob sie nun Server und virtuelle Server unterscheiden wollen, muss einmalig definiert werden. Da i-doit bereits ein umfangreiches Repertoire an Objekttypen mitbringt, werden sie dieses genauer unter die Lupe nehmen.
  • manuelles Löschen oder Ergänzen fehlerhafter Einträge
    Hier bleibt die manuelle Arbeit an der Datenquelle an ihm hängen.
  • Intensive Zusammenarbeit mit den Wissenden
    Das will er sich und allen KollegInnen tunlichst ersparen. Der Faktor Zeit ist ja genau der Grund, warum die Dokumentation in dem Zustand ist, wie er ist. Zumindest behaupten das alle. Dieser Punkt lässt ihn befürchten, dass das Daten-Clearing eine unendliche Geschichte wird und er soeben auf den Holzweg abgebogen ist. Er kann nur mit sehr hohem Aufwand feststellen, welche Information tatsächlich korrekt ist (und jeder, den er befragt, erzählt ihm etwas Anderes).

Toni überlegt eine neue Strategie: Was wäre, wenn er einfach mal alle verwertbare Daten importiert und dann in i-doit bereinigt? Damit wäre zumindest mal seine Allergie gegen Tabellen geheilt.

Zuerst importieren, dann bereinigen?

Gedacht, probiert. Toni ist bereits recht fit in der Bedienung und Konfiguration des Tools. Die Eigenschaft des Daten-Mappings beim Import hilft ihm: Bereits bestehende Daten können in i-doit mit neuen Daten angereichert werden, Felder werden entsprechend überschrieben. Die Vor- und Nachteile muss er nun abwägen.

Er muss nun die ältesten Informationen als erstes in die Datenbank laden und dann mit den Neuesten überschreiben. Allerdings ist er vom Hörensagen abhängig: schließlich kann er schwerlich das Änderungs-Datum einer Datei als letztes Änderungsdatum jedes einzelnen Eintrages annehmen …

Der Trick beim Import

Das Überschreiben von Feldern funktioniert auch beim Objekttyp: Dieser kann beim CSV-Import beliebig festgelegt werden. Toni wendet diesen Trick an, den er von einem befreundeten Admin, ebenfalls i-doit Anwender, erfahren hat:

Er legt sich einen neuen Objekttyp “Import-Objekte” an, sozusagen als Sammelbecken für das Daten-Clearing. Und erreicht damit gleich mehrere Vorteile:

  1. Es befinden sich alle durch den Import neu angelegten Objekte in einer Liste. Die Daten, auch wenn sie aus unterschiedlichen Quellen stammen, werden beim Importvorgang konsolidiert. Von hier aus kann er weiter arbeiten und behält stets den Überblick. Mit der Möglichkeit der Massenänderung in i-doit verändert er danach mehrere Datensätze auf einmal – so arbeitet er sich durch die Liste.
  2. Er weiß stets, welche Objekte noch qualitätsgesichert werden müssen, unter anderem muss er ja auch den Objekttyp ändern. Ist die Liste leer, ist es gut.

Toni arbeitet nach folgendem Schema:

CMDB Datenimport Schema

Ergebnis: Garbage In = Garbage Out

Es bleibt, auch wenn die Daten aus beiden Tabellen nun in i-doit konsolidiert sind, das Thema Aktualität und einheitliche Datenqualität unbeantwortet. Trotz aller Tricks beim Import hat Toni ein grundlegendes Problem in der Datenübernahme festgestellt: Er kann nur manuell und stichprobenartig überprüfen, ob die Daten zusammen passen. Ob Seriennummern korrekt abgetippt wurden?

Toni wird sich auch noch mit anderen Datenquellen und Techniken der Datenbeschaffung auseinander setzen.

Doch dazu im nächsten Beitrag mehr.

Conclusio

Dateien als Informationsspeicher sind tricky: Häufig gibt es Redundanzen, die Inhalte haben fragliche Aktualität, oft gibt es nicht importierbare Inhalte. Diese Daten zu manipulieren und zu aktualisieren ist ein enormer Zeitfaktor im Projekt. Die Frage muss im Projekt erlaubt sein, ob man nicht die bisherige Dokumentation “einfriert” und eine andere Quelle für aktuelle Daten findet!

Nützliche Links

doIT BETTER: Von Excel zu i-doit in 5 Minuten

Knowledge Base: CSV-Datenimport

i-doit Testversion: Bestellen

Share This