Die meisten IT-Verantwortlichen sind sich einig: Sie benötigen eine bessere Transparenz über ihre Technologielandschaft. Sie möchten wissen, welche Services einen kritischen Geschäftsprozess unterstützen, welche Systeme von einem Incident betroffen sind und was bei einem Change ausfallen könnte. Die übliche Antwort darauf ist der Start eines CMDB-Projekts.
Genau dort gehen viele Teams falsch vor.
Eine Configuration Management Database ist nicht deshalb wertvoll, weil sie eine große Anzahl von Datensätzen enthält. Sie ist wertvoll, weil sie Menschen hilft, im entscheidenden Moment bessere Entscheidungen zu treffen: während eines Incidents, vor einem Change, bei der Risikobewertung oder bei der Beantwortung einer Audit-Frage. Eine CMDB, die von Beginn an jedes Gerät, jede Anwendung und jede Beziehung modellieren will, wird meist zu einem Datenfriedhof — groß, unvollständig und losgelöst von der tatsächlichen Arbeitsweise der Teams.
Jira Service Management stellt mit Assets eine integrierte Funktion für IT-Asset-Management und Service Configuration Management bereit. Das Potenzial ist groß, aber der Ansatz muss bewusst schlank bleiben.
Die Begriffe Asset Management, Configuration Management und CMDB werden oft synonym verwendet. Sie hängen zusammen, beantworten aber unterschiedliche Fragen.
IT-Asset-Management beschäftigt sich damit, was eine Organisation besitzt oder nutzt. Dazu gehören Laptops, Softwarelizenzen, Mobilgeräte, Cloud-Abonnements und andere Ressourcen, die beschafft, zugewiesen, gewartet oder außer Betrieb genommen werden müssen.
Service Configuration Management konzentriert sich auf die Services, von denen das Unternehmen abhängt, sowie auf die Configuration Items, die diese Services ermöglichen. Ein Configuration Item, oft als CI bezeichnet, kann eine Anwendung, eine Datenbank, ein Server, ein Cloud-Service oder eine konkrete Integration sein. Entscheidend ist nicht nur das einzelne Objekt, sondern seine Beziehung zu anderen Objekten.
Eine CMDB ist das strukturierte Repository, das diese Konfigurationsdatensätze und ihre Beziehungen über ihren Lebenszyklus hinweg speichert. Eine hilfreiche CMDB zeigt einem Team beispielsweise, dass ein Payroll-Service von einem bestimmten Identity Provider, einer Datenbank und einer Integration abhängt — nicht nur, dass diese Komponenten jeweils existieren.
Der schnellste Weg, eine CMDB scheitern zu lassen, besteht darin, mit dem Import aller verfügbaren Daten zu beginnen. Das erzeugt häufig Tausende von Datensätzen ohne klaren Eigentümer, ohne definierten Use Case und ohne sinnvolle Verbindung zur täglichen Arbeit im Service Management.
Atlassian empfiehlt einen Top-down-Ansatz: Beginne mit einem oder zwei kritischen Business Services, dokumentiere die Configuration Items, die diese Services tatsächlich unterstützen, und lasse das Service-Modell anhand realer operativer Anforderungen wachsen.
Eine gute Ausgangsfrage lautet nicht: „Welche Daten können wir importieren?“ Sie lautet: „Welche Antwort brauchen wir im Störungsfall zu lange, obwohl sie für das Geschäft wichtig ist?“
Ein Unternehmen kann zum Beispiel Schwierigkeiten haben, bei einem Ausfall des Single Sign-on Providers die betroffenen Services zu identifizieren. Damit sind Identity Services ein sehr guter erster Scope. Ein anderes Unternehmen erlebt wiederholt langsame Incident-Lösungen rund um seine E-Commerce-Plattform. In diesem Fall kann sich das erste Service-Modell auf Storefront, Payment Gateway, Order-Management-Integration und die verantwortlichen Teams konzentrieren.
Dieser Ansatz stellt sicher, dass die CMDB von Anfang an einem konkreten Business-Zweck dient.
In Jira Service Management Assets ist ein Object Schema die Struktur, die Object Types und einzelne Objects enthält. Ein Laptop kann beispielsweise ein Object Type sein, während jedes einzelne Firmenlaptop ein Object darstellt. Dasselbe Prinzip gilt für Anwendungen, Datenbanken, Services, Lieferanten und Standorte.
Das Ziel besteht nicht darin, im ersten Workshop ein perfektes Enterprise-Modell zu entwerfen. Es besteht darin, die Mindestinformationen zu definieren, die Teams für bessere Entscheidungen benötigen.
Für einen kritischen Application Service kann dies bedeuten, Service Owner, Technical Owner, Service Tier, Support Group, Hosting Location, Lifecycle Status sowie Upstream- und Downstream-Abhängigkeiten zu erfassen. Für eine geschäftskritische Integration können Source System, Target System, Data Owner, Interface Type und der unterstützte Business Process relevant sein.
Jedes Feld sollte seinen Platz verdienen. Wenn ein Team nicht erklären kann, wie ein Attribut in Incident, Change, Reporting, Compliance oder einer Lifecycle-Entscheidung genutzt und gepflegt wird, gehört es wahrscheinlich nicht in die erste Version des Modells.
Ein flaches Inventar ist für Procurement nützlich. Eine Service Map ist für den Betrieb nützlich.
Wenn Configuration Items über sinnvolle Beziehungen verbunden sind, können Service-Teams Fragen beantworten, die einen praktischen Unterschied machen: Welche Services könnten von diesem Infrastruktur-Change betroffen sein? Welches Team besitzt das System, das mit diesem Incident verbunden ist? Welche kundenorientierten Prozesse hängen von der Datenbank ab, die Performance-Probleme aufweist?
Deshalb sollte Dependency Mapping auf operativen Szenarien und nicht auf abstrakten Architekturdiagrammen aufbauen. Beginne mit den Abhängigkeiten, die bei Incidents und Changes regelmäßig relevant sind. Verbessere das Modell, wenn ein echter Service-Fall einen blinden Fleck aufdeckt.
Das Ziel ist keine optisch beeindruckende Karte. Das Ziel ist verlässlicher Kontext, wenn Zeit knapp ist.
Eine CMDB schafft deutlich mehr Wert, wenn sie in das tägliche Service Management eingebettet ist. In Jira Service Management können Assets Objects direkt in Issues und auf Request Forms angezeigt werden. Dadurch erhalten Agents und Requester den relevanten Kontext dort, wo Arbeit stattfindet.
Wenn ein Mitarbeiter einen Laptop anfordert, kann der Request mit einem konkreten Asset verknüpft werden. Wenn ein Incident auftritt, kann die betroffene Anwendung oder der Service mit dem Ticket verbunden werden. Wenn ein Change vorgeschlagen wird, können Teams die gefährdeten Configuration Items identifizieren und relevante Beziehungen vor der Freigabe sehen.
Diese Verbindung hat zwei Vorteile. Sie verbessert Qualität und Geschwindigkeit operativer Entscheidungen. Außerdem entsteht eine natürliche Feedback-Schleife. Teams entdecken veraltete Daten, weil sie ihnen in realen Workflows begegnen — nicht weil sich jemand einmal pro Quartal an eine Tabellenkalkulation erinnert.
Automatisierung und Discovery Tools können dabei helfen, ein Asset Repository aktuell zu halten. Sie können jedoch keine unklare Verantwortlichkeit lösen. Jira Service Management unterstützt Imports aus Formaten wie CSV und JSON. Für Premium- und Enterprise-Pläne kann Data Manager Informationen aus mehreren Quellen konsolidieren, bereinigen und abgleichen. Assets Discovery kann Umgebungen scannen und Änderungen nach Zeitplan erkennen.
Diese Funktionen sind nur dann wertvoll, wenn die Organisation drei Governance-Fragen beantwortet hat. Wer ist für die Genauigkeit eines bestimmten Datensatzes verantwortlich? Welche Quelle ist maßgeblich, wenn Datensätze voneinander abweichen? Welches operative Ereignis löst eine Überprüfung oder Aktualisierung aus?
Ein einfaches Ownership-Modell reicht zu Beginn meist aus. Ein Service Owner trägt die Verantwortung für die geschäftliche Relevanz eines Services. Ein Technical Owner ist für Konfigurationsinformationen und Beziehungen verantwortlich. Das Service-Management-Team stellt sicher, dass das Modell Incidents, Changes und Requests unterstützt.
Die Reife einer CMDB sollte nicht an der Anzahl ihrer Datensätze gemessen werden. Sie sollte an der Anzahl der Entscheidungen gemessen werden, die sie verbessert.
Eine nützliche CMDB erleichtert das Routing eines Incidents, die Bewertung eines Changes, die Erfüllung einer Audit-Anforderung, die Identifikation eines Service Owners oder das Verständnis der möglichen Auswirkungen eines Ausfalls. Wenn sie Teams bei keiner dieser Aufgaben unterstützt, sind ihre Pflegekosten schwer zu rechtfertigen.
Beginne klein. Wähle einen kritischen Service. Definiere nur die Informationen, die eine echte operative Entscheidung ermöglichen. Verknüpfe ihn mit Incidents, Changes und Requests. Etabliere Ownership. Anschließend kannst Du das Modell bewusst und auf Basis nachgewiesenen Nutzens erweitern.
So wird Jira Service Management Assets mehr als ein Inventar. Es wird zu einer verlässlichen operativen Karte der Services, auf die sich das Unternehmen tatsächlich verlässt.
Jahrelang lebten Produktmanager in einer fragmentierten Welt: Ideen in Tabellenkalkulat
Von intelligentem Aufgabenmanagement bis zu Echtzeit-Insights – mit Atlassian Intellige
Sie denken, Jira ist nur etwas für Entwickler? Weit gefehlt. Ob Marketing, HR oder Fina
