(Artikel 5 von 9)

Gruppen in JDisc bilden

Eine übliche Vorgehensweise, um dem Datenwust im Netzwerk Herr zu werden, ist es, gleichartige Assets wie Notebooks, PCs oder IP-Telefone zu Gruppen zusammenzufassen. Gerne werden auch IP-Netze, die geografisch strukturiert sind, als eigene Scan-Gruppe ausgebildet. Mit der Kombination aus beidem erhalten wir dynamische Gruppen von Clients in Frankreich und Telefone im Jemen. Aus diesem Titel ergibt sich noch kein IT-Verbund, doch bringen wir zumindest die Prozesse im Asset Management auf Vordermann. Wir strukturieren “verdaubare Häppchen” bereits im Discovery und ermöglichen so eine Vorqualifizierung der Daten – bevor sie noch in die CMDB gespielt werden und dort möglicher Weise Verwirrung stiften. In JDisc können sie vorab auf Vollständigkeit geprüft und dann “auf einen Rutsch” in die CMDB übernommen werden, die Schnittstelle kann mit JDisc Gruppen umgehen.

Übernahme aller Clients in Frankreich in die CMDB

Nun beginnen die Nacharbeiten in der CMDB – das Anreichern um jene Daten, die nicht per Discovery identifiziert werden können. Verträge, buchhalterische Werte, eindeutige Identifkationsnummern bzw. Labels. Diese Arbeit kann eventuell im Team aufgeteilt werden und von entsprechenden Gebietsbetreuern abgewickelt werden. Und: SOLL/IST sollte verifiziert werden um zu einem Punkt zu kommen, der uns ermöglicht auf verifizierte Daten aufzusetzen:

Verifizierte Baseline: Clients aus Frankreich

Ist nun SOLL und IST verifiziert, alle vereinbarten Daten in den Datensätzen angereichert und damit die Gesamtmenge der Information für alle Folgeprozesse freigegeben? Wie wissen es die Kolleginnen und Kollegen? Diesen Umstand sollten wir im Datenbestand kenntlich machen. Dazu benötigen wir einen Marker im Verlauf des Lebenszyklus, sprich: Logbuch.

Erstellen einer Baseline in i-doit

Als “Marker” im Lebenszyklus von Assets oder CIs bieten sich die bereits im Auslieferungszustand von i-doit vorhandenen Workflows an. Ein eigener Workflow-Typ Baseline, ist rasch erstellt und erfüllt den erwünschten Zweck. Jene “kleinen Häppchen”, die aus JDisc in die CMDB importiert wurden werden zu einer, mit selbsterklärendem Text ausgestatteten, Baseline hinzugefügt. Ist der vereinbarte Vorgang durchgeführt, wird auch die Aufgabe auf “erledigt” gesetzt. Jede Aktion führt zu einem Eintrag bei den betroffenen Assets. Der Screenshot zeigt uns den LOG-Eintrag eines einzelnen Arbeitsplatzrechners, der für alle späteren Leser nachvollziehbar ist.

Soweit die Vorgehensweise, wenn es um die Datenübernahme von Assets geht. Der Prozess sieht wie folgt aus:

  1. Achtung wir ändern etwas: SOLL und IST könnten voneinander abweichen!
  2. Änderung an den Endgeräten, Versionen, Releases, etc.
  3. Scanning mit JDisc, Übernahme des neuen IST
  4. Übernahme des neuen IST in die CMDB
  5. Verifikation der Daten in der CMDB: SOLL und IST gleichsetzen
  6. ggf. Anpassungen im IST und Durchlauf von Punkt 3
  7. Alle Changes abschließen, die neue Configuration Baseline gilt: Alle Änderungen sind abgeschlossen, ab nun gilt für diesen Datensatz wieder die Configuration Control: nichts darf sich im Datenbestand “einfach so” ändern!

 

Ebenso können Massenrollouts, etc. mit Hilfe von i-doit Workflows gekennzeichnet und am Ende, nach erfolgtem SOLL/IST-Abgleich mit einer Configuration Baseline “offiziell” gekennzeichnet werden. Dies ersetzt zwar kein ausgefeiltes Change Management, ist jedoch im Sinne der Kommunikation ein pragmatischer Ansatz.

So weit der einfache Teil. Doch es wäre nicht IT, wenn es nicht kompliziert wäre: