IT Governance & Cloud Operations · Asset-Management

Was nicht im Inventar steht, kann niemand schützen.

Geräteverwaltung, Virenschutz und Einkauf zählen jeweils einen anderen Bestand – und welcher Server welchen Geschäftsprozess trägt, steht in keinem davon. Also beginnt bei jeder Störung, jeder Änderung und jeder Auditfrage die Suche von vorn, während Listen von Hand nachgepflegt werden – und trotzdem veralten. Wir geben Ihnen ein Inventar mit Konzept dahinter: Systeme, Verantwortliche, Kritikalität und Abhängigkeiten in einem Modell – dokumentiert, automatisch aus Ihren Quellen gespeist, mit eingebauten Kontrollen.

Regulatorik

Wissen, was da ist und wer es verantwortet: Externe Treiber.

NIS2 / BSIG

„Konzepte für die Sicherheit des Personals, die Zugriffskontrolle und für die Verwaltung von IKT-Systemen, -Produkten und -Prozessen“ – § 30 Abs. 2 Nr. 9 BSIG (EU: Art. 21 Abs. 2 lit. i). Verwaltung beginnt beim Wissen, welche Systeme es gibt: Inventar, Verantwortliche und Pflegeprozess zahlen auf diese Anforderung ein.

DORA

IKT-gestützte Funktionen und die unterstützenden Informations- und IKT-Assets ermitteln und klassifizieren, Konfiguration und Abhängigkeiten dokumentieren und die Inventare regelmäßig sowie bei jeder wesentlichen Änderung aktualisieren (Art. 8 Abs. 1, 4 und 6) – Asset-Modell und Pflegeprozess unterstützen genau diese Anforderungen.

TISAX

VDA ISA 6, Themenfeld Asset-Management: Informationswerte erfassen, Verantwortlichen zuordnen und über den Lebenszyklus führen – ein gepflegtes Inventar schafft die Nachweisfähigkeit für das Assessment in der Automotive-Lieferkette.

Cyber-Versicherung

Risikofragebögen fragen nach der Zahl der Server und Endgeräte, nach Altsystemen und danach, ob ein aktuelles IT-Inventar geführt wird – die Antworten beeinflussen Prämie, Selbstbehalt und Deckung. Ein gepflegter Bestand liefert sie, ohne dass jemand schätzen muss.

Referenztechnologien

Unsere technische Basis.

Angepasst an Ihre Umgebung und Lizenzen.

01 · Zielsysteme

Assets in Jira Service Management führt den Bestand: Systeme, Geräte, Verträge und ihre Abhängigkeiten als verbundenes Modell nach Ihrer Taxonomie – dort steht die eine Zahl, auf die sich alle beziehen.

02 · Durchführung & Self-Service

Microsoft Intune, Defender und Entra ID speisen Geräte- und Systemdaten automatisiert ein; Abgleiche laufen in festen Zyklen, Abweichungen erzeugen Aufgaben für die Verantwortlichen.

03 · Prozess-Dokumentation & Ablauf

Jede Aufnahme ein Antrag, jede Änderung ein Change, jede Aussonderung ein dokumentierter Abschluss – alles mit Spur in Jira Service Management.

Das Konzept im Detail

Jedes System bekommt einen Eintrag, einen Verantwortlichen und einen Lebenszyklus.

Der Zuschnitt folgt Ihrer Ausgangslage und Lizenzsituation – der Kern ist in jedem Projekt derselbe. Sie nutzen andere Tools? Wir prüfen, wie sich unser Konzept am besten bei Ihnen abbilden lässt.

01

Bestandsabgleich

Ihre Inventare im Vergleich: was Geräteverwaltung, Virenschutz, Einkauf und Einzellisten jeweils kennen, wo sie sich widersprechen und welche kritischen Systeme in keinem auftauchen.

02

Asset-Modell

Taxonomie und Pflichtangaben: Objekttypen, Beziehungen, benannte Verantwortliche und die Kritikalität – also wie schwer ein Ausfall das Geschäft trifft – je System; als Modell in Assets angelegt.

03

Pflege- und Kontrollprozess

Aufnahme, Änderung, Inventur und Aussonderung als dokumentierte Abläufe; automatische Abgleiche mit den technischen Quellen melden Abweichungen an die Verantwortlichen.

04

Pilot & Umsetzung

Ein geschäftskritischer Service macht den Anfang: seine Systeme, Abhängigkeiten und Verantwortlichen vollständig modelliert, die Quellen angebunden. Danach wächst der Bestand Service für Service.

FAQ

Fragen vor dem Start.

Welche Jira-Lizenz brauchen wir dafür?

Assets ist nach Atlassian-Dokumentation in den Plänen Premium und Enterprise von Jira Service Management enthalten. Ob Ihr Plan die Funktionen schon abdeckt und wie tief die automatische Erkennung (Discovery) gehen soll – also welche Geräte und Dienste im Netz selbsttätig aufgespürt werden –, hängt von Umgebung und Zielbild ab; deshalb steht die Lizenzprüfung am Anfang des Projekts, vor jeder Umsetzung.

Ist eine CMDB dasselbe wie ein Inventar?

Nein. Ein Inventar listet Bestände. Eine CMDB (Configuration Management Database) verbindet Systeme, Services und Abhängigkeiten – bei einer Störung oder Änderung ist damit sichtbar, was betroffen ist. Im Modell laufen beide Sichten zusammen, das Inventar ist die erste Ausbaustufe.

Müssen wir sofort alle Assets erfassen?

Nein. Der Pilot beginnt mit einem geschäftskritischen Service und seinen Systemen; das Modell ist auf Erweiterung angelegt. Vorhandene Listen und Discovery-Daten werden importiert und abgeglichen – von Hand erfasst wird nur, was keine Quelle hat.

Wüssten Sie heute, welche Systeme geschäftskritisch sind – und wer sie verantwortet?

30 Minuten Ausgangslage besprechen: Sie schildern Stand und Schmerzpunkte – etwa wie viele Bestandslisten nebeneinander laufen und wann die letzte Inventur war –, Loptr ordnet ein.

Termin direkt buchen
Wenn das Problem woanders liegt

Der passende Einstieg ist manchmal ein anderer.

Ein lückenhaftes Inventar zeigt sich selten zuerst als Inventarproblem – vier typische Ausgangslagen:

Die Risiken sollen bewertet werdenKritikalität und Bedrohung je System in eine Rangfolge bringen → IT-Risikoanalyse
Störungen und Änderungen laufen ungeordnetDer Bestand entfaltet Wirkung erst im Service- und Änderungsprozess → IT-Service-, Incident- & Change-Management
Support-Enden und Altsysteme drückenFristen, Entscheidungen und Ablösung je System → System Lifecycle Management
Es geht vor allem um die EndgeräteGeräte zentral verwalten und Stände automatisch prüfen → Endpoint Management

Oder der Überblick: alle Lösungen im Bereich IT Governance & Cloud Operations →