Asset-Framework

Im Asset-Management ist ein Framework das Modell, das verstreute Geräte- und Lizenzdaten in ein gesteuertes Programm verwandelt. Es legt vier Dinge fest: eine Taxonomie von Asset-Kategorien, einen Lebenszyklus, den jedes Asset durchläuft, Rollen, die Eigentum, Verwahrung und Aufsicht zuweisen, sowie Entscheidungsregeln für Freigabe, Änderung und Ausmusterung. Es sorgt dafür, dass Antworten auf praktische Fragen aus einer Richtlinie kommen und nicht aus Improvisation. Darf eine Abteilung eigene Notebooks kaufen? Wer genehmigt einen Softwarekauf?

Der Begriff ist weiter als jedes Verzeichnis oder jede Datenbank. Eine Tabelle mit Seriennummern ist kein Framework, und ein Erkennungswerkzeug ist es ebenso wenig, egal wie vollständig sein Scan ist. Das Framework ist die Menge aus Definitionen und Verantwortlichkeiten, die festlegt, was diese Datensätze enthalten müssen, wer sie pflegt und welche Entscheidungen sie speisen. Innerhalb des IT-Asset-Managements ist es die Struktur, die Werkzeuge automatisieren. Ersetzen können sie sie nicht.

Ein Framework beginnt damit, den Bestand an Assets in Kategorien zu gliedern. Die Kategorie bestimmt alles Weitere: welche Attribute erfasst werden, welche Kontrollen gelten, wer der natürliche Eigentümer ist und wie das Asset bewertet wird. Eine typische Unternehmenstaxonomie unterscheidet die fünf folgenden Kategorien.

Zwei Regeln halten die Taxonomie tragfähig. Kategorien müssen sich gegenseitig ausschließen, damit jedes Asset genau einen Platz in der Struktur hat. Sie müssen außerdem vollständig sein, damit nichts, wofür die Organisation Geld ausgibt, außerhalb liegt. Jede Kategorie braucht eine Benennungs- und Kennzeichnungsregel, die unter Asset-Identifikation beschrieben ist. Passt ein neuer Asset-Typ nicht, wird das Framework selbst angepasst. Ad-hoc-Listen außerhalb davon sind der Ort, an dem Schatten-IT entsteht.

Keine Organisation muss ein Framework von null erfinden. Mehrere Praxisrahmen sind weit verbreitet. Die Normenreihe ISO 55000 beschreibt ein Asset-Management-System in allgemeiner Form: abgestimmte Asset-Entscheidungen, den Zyklus Planen-Umsetzen-Prüfen-Handeln und eine durchgängige Linie von der Richtlinie bis zum einzelnen Asset. ITIL behandelt Asset-Management als Teil des Service-Managements und verknüpft den Asset-Lebenszyklus mit der Serviceerbringung, den Konfigurationsdaten und der Configuration Management Database. Die Sicherheitsperspektive ergänzt die Anforderung an ein Inventar. NIST SP 800-53 erwartet ein vollständiges, aktuelles Verzeichnis der Systemkomponenten, das in festgelegten Abständen geprüft wird. ISO/IEC 27001 verlangt ein Asset-Inventar mit zugewiesener Verantwortung.

Reife Organisationen übernehmen selten einen Standard vollständig. Üblich ist eine Governance-Hülle im Stil von ISO 55000, eine Anbindung an den Lebenszyklus im Stil von ITIL und eine sicherheitsgetriebene Inventaranforderung, angepasst an Größe und Risikoprofil der Organisation.

Der Lebenszyklus ist das Rückgrat des Frameworks. Jedes Asset befindet sich immer in genau einer Phase, und jede Phase hat definierte Eintrittskriterien, Austrittskriterien und eine verantwortliche Rolle. Das klassische Modell hat fünf Phasen:

1. 1

   Planen

   Anforderungen werden erfasst, Budgets genehmigt und Beschaffungsstandards festgelegt. Zentrale Nachweise: genehmigte Standards, Budgetposten.

2. 2

   Beschaffen

   Das Asset wird gekauft, gemietet oder übernommen und danach erfasst und gekennzeichnet. Zentrale Nachweise: Kaufbeleg, Inventareintrag, Asset-Tag.

3. 3

   Einsetzen und betreiben

   Das Asset wird konfiguriert, ausgegeben, gewartet und regelmäßig erneut geprüft. Zentrale Nachweise: Zuweisungshistorie, Wartungsprotokolle.

4. 4

   Ändern

   Umzug, Upgrade, Neuzuweisung oder Neuklassifizierung, wenn sich die Nutzung entwickelt. Zentrale Nachweise: Änderungshistorie, aktualisierte Attribute.

5. 5

   Ausmustern

   Das Asset wird außer Betrieb genommen, seine Daten werden gelöscht und das Gerät wird weiterverwendet, verkauft oder vernichtet. Zentrale Nachweise: Ausmusterungsprotokoll, Nachweis der Datenbereinigung.

Der häufigste Fehler ist, ein Werkzeug zu kaufen und die Aufgabe für erledigt zu halten. Ein Discovery-Agent, der jeden Endpunkt auflistet, ist kein Framework, und eine Configuration Management Database ist es ebenso wenig. Das Framework ist die Vereinbarung über Kategorien, Eigentum, Phasen und Entscheidungsrechte, die diese Systeme erfassen und durchsetzen. Das Werkzeug ist der Ort, an dem die Daten liegen. Ohne Framework verkommt die Ausgabe des Werkzeugs zu einer Liste ohne Verantwortlichen. Ohne Werkzeug versinkt das Framework in manueller Pflege.

Der praktische Test lautet: Kann die Organisation aus ihren Daten antworten und nicht aus dem Gedächtnis? Welche Assets besitzen wir? Wer ist für jedes verantwortlich? In welcher Phase des Lebenszyklus befindet sich jedes? Wann wurde die Antwort zuletzt geprüft? Ein tragfähiges Framework macht diese Fragen zur Routine. Ein schwaches verwandelt jede davon in eine Untersuchung.

In Anexet Inventory listet die Karte jedes Arbeitsplatzrechners auf dem Reiter Devices jede Komponente mit Gerätetyp und Hersteller. Auf der Serverkarte ergänzt derselbe Reiter die Spalten für Inventarnummer und Seriennummer, sodass sich das Verzeichnis mit Kaufbelegen und dem physischen Bestand abgleichen lässt.

1 / 2

• 
• 

Ein Framework weist Aufgaben benannten Rollen zu und nicht demjenigen, der ein Problem zuerst bemerkt. Der Rollensatz ist klein und stabil, und jede Rolle trägt eine Entscheidung:

Beginnen Sie mit den Kategorien und ihren Eigentümern, nicht mit der Software. Benennen Sie je Kategorie einen Verantwortlichen, vereinbaren Sie die fünf Lebenszyklusphasen und wählen Sie erst dann ein Werkzeug, das festhält, was das Framework bereits entscheidet. Verknüpfen Sie das Framework früh mit dem Software-Asset-Management, denn bei den Lizenzen zeigen sich Kosten und Risiko einer Liste ohne Verantwortlichen zuerst.