IT-Asset-Management-Zielbild: So entwickeln Sie es, darauf kommt es an
IT-Systemtransformation
In vielen Unternehmen laufen zur selben Zeit mehrere Vorhaben rund um die eigene IT-Landschaft: Ein Werkzeug für das Enterprise Architecture Management wird eingeführt, ein Anwendungsverzeichnis aufgebaut, der Freigabeprozess für neue Software überarbeitet und eine Konfigurationsdatenbank (CMDB) für die technischen Assets erweitert. Jedes dieser Vorhaben ist für sich sinnvoll. Zusammen passen sie oft nicht.
Die Folgen zeigen sich schnell: Daten werden doppelt gepflegt, niemand fühlt sich für die Qualität verantwortlich, und Audit-Anforderungen lassen sich nur mit viel Handarbeit erfüllen. Was fehlt, ist ein gemeinsames Zielbild für das IT-Asset-Management.
In diesem Beitrag zeige ich Ihnen, wie Sie ein solches Zielbild entwickeln, worauf Sie dabei achten sollten und was Sie mit dem Ergebnis steuern können. Die Beispiele stammen aus einem Projekt, das ich als Projektreferenz beschrieben habe.
1. Was ein Zielbild für das IT-Asset-Management leisten muss
Unter IT-Asset-Management verstehe ich die Steuerung aller IT-Werte eines Unternehmens über ihren gesamten Lebenszyklus: Anwendungen, Server, Geräte, Lizenzen und Cloud-Dienste. Ein Zielbild beschreibt, wie dieses Zusammenspiel künftig funktionieren soll. Es muss vier Fragen eindeutig beantworten:
- Welches System führt welche Daten? Zum Beispiel die fachliche Sicht auf Anwendungen in LeanIX und die technischen Assets in der CMDB.
- Wer ist wofür verantwortlich? Jede Anwendung und jede Datenklasse braucht einen benannten Verantwortlichen.
- Wie kommt eine neue Anwendung ins Unternehmen? Von der Anfrage über die Freigabe bis zur Beschaffung.
- Wie verlässt sie das Unternehmen wieder? Die Außerbetriebnahme wird häufig vergessen, ist aber für Kosten und Sicherheit entscheidend.
Ein Zielbild ist damit kein Werkzeugkonzept. Es ist eine Vereinbarung darüber, wie Systeme, Menschen und Abläufe zusammenwirken.
2. Das Zielbild in drei Ebenen
Bewährt hat sich für mich ein Modell aus drei Ebenen, die gemeinsam betrachtet werden:
- Systeme und Integration: Für jede Datenklasse gibt es genau ein führendes System. Ein Werkzeug für das Enterprise Architecture Management wie LeanIX führt die fachliche Sicht mit Geschäftsfähigkeiten und Anwendungen. Die CMDB führt die technischen Assets. Die automatische Inventarisierung, oft Discovery genannt, liefert Daten zu Hardware, Software und Lizenzen, ist aber nie selbst führendes System.
- Organisation und Rollen: Ein Gremium trifft Architekturentscheidungen nach dem Vier-Augen-Prinzip. Eine Rolle verantwortet das Anwendungsportfolio und den Freigabeprozess. Jede Anwendung hat einen Verantwortlichen, und ein schlankes Team sichert die Datenqualität in der CMDB.
- Prozesse: Alle Anfragen für neue Software laufen über einen einzigen Eingang. Risikobasierte Freigabestufen sorgen dafür, dass Standardfälle ohne Wartezeit durchlaufen und nur kritische Vorhaben geprüft werden. Der Ablauf reicht von der Anfrage bis zur Außerbetriebnahme.
Entscheidend ist, dass die drei Ebenen zusammenpassen. Ein sauberes Datenmodell nutzt wenig, wenn niemand die Daten pflegt. Und ein guter Prozess scheitert, wenn das System die notwendigen Informationen nicht bereitstellt.
3. Das Vorgehen in drei Phasen
Ein Zielbild entsteht nicht am Schreibtisch, sondern gemeinsam mit den Beteiligten. Ich gehe dabei in drei Phasen vor:
- Validieren: Ich nehme die laufenden Initiativen auf, kläre das übergeordnete Ziel und mache Abhängigkeiten und Überschneidungen sichtbar. Grundlage sind Interviews mit IT-Leitung, Architektur, Informationssicherheit, Betrieb und Fachbereichen sowie eine Analyse der Systeme und Dokumente. Am Ende steht ein erstes Gesamtbild, das mit den zentralen Beteiligten abgestimmt ist.
- Zielbild entwickeln: Ich lege fest, welche Rolle jedes System spielt, wie die Verantwortung verteilt ist und welche Regeln für Freigaben und Datenqualität gelten. Offene Maßnahmen aus Audits fließen hier direkt ein.
- Management-Abstimmung: Gemeinsam mit den Entscheidern prüfen wir das Zielbild kritisch, priorisieren die Handlungsfelder und treffen offene Grundsatzentscheidungen. Daraus leite ich eine realistische Roadmap mit Reihenfolge und ersten Umsetzungsschritten ab.
Praxis-Tipp: Befunde nummerieren und nachverfolgen
Fassen Sie alle Erkenntnisse aus Interviews und Analysen in einer konsolidierten Liste zusammen und geben Sie jedem Befund eine Nummer. In meinem Projekt waren es rund 50 Befunde. Jede spätere Initiative verweist auf die Befunde, die sie löst. So sehen Sie auf einen Blick, ob jede Lücke genau einmal adressiert ist, und können jede Maßnahme gegenüber dem Management begründen.
4. Worauf Sie achten sollten
Aus meiner Erfahrung entscheiden wenige Grundsätze darüber, ob ein Zielbild im Alltag trägt:
- Grundlagen vor Skalierung: Legen Sie zuerst fest, welche Daten Pflicht sind und was ein Begriff wie „Anwendung“ oder „Produkt“ genau bedeutet. Erst dann lohnt es sich, Daten in großem Umfang zu erfassen.
- Steuerungsrelevanz statt Vollständigkeit: Ein Verzeichnis mit tausenden Einträgen hilft wenig, wenn niemand die Angaben bestätigt hat. Erfassen Sie zuerst die Daten, die Sie für Entscheidungen, Audits und Sicherheit wirklich brauchen.
- Anwendungs- und Assetsicht trennen: Die fachliche Sicht und die technische Sicht gehören in unterschiedliche Systeme. Sie werden an klar definierten Stellen über Schnittstellen verbunden, statt Daten doppelt zu pflegen.
- Erst festlegen, dann anbinden: Bevor Sie die automatische Inventarisierung an die CMDB anschließen, definieren Sie, welche Objekte, Merkmale und Qualitätsregeln übertragen werden. Wer zuerst die Technik verbindet, baut später teuer um.
- Betriebsmodell vor dem Start: Ohne ein Team, das die Datenqualität laufend sichert, veralten die Daten nach dem Start schnell. Eine CMDB ohne Betriebsmodell ist ein teurer Maschinenraum ohne Bediener.
- Rollen mit Mandat: Der Engpass sind selten die Werkzeuge. Entscheidend sind besetzte Rollen mit klarem Auftrag und gesicherter Kapazität. Eine Anwendung ohne benannten Verantwortlichen sollte gar nicht erst in Betrieb gehen.
Ein Punkt wird zudem oft unterschätzt: Ein gemeinsames Zielbild verschiebt Verantwortung. Bereiche, die bisher eigenständig entschieden haben, geben Teile davon an zentrale Rollen ab. Sprechen Sie das früh an und beziehen Sie die betroffenen Bereiche in die Ausgestaltung ein.
5. Was Sie mit dem Ergebnis erreichen
Ein abgestimmtes Zielbild ist kein Selbstzweck. Es wird zum Steuerungsinstrument für die nächsten Jahre:
- Initiativen neu ausrichten: Bestehende Vorhaben werden so geschnitten, dass jede Lücke genau einmal bearbeitet wird. Fehlentwicklungen lassen sich frühzeitig stoppen.
- Eine Roadmap mit klarer Reihenfolge: Erst werden die Grundlagen geklärt, dann Inhalte und Prozesse aufgebaut und schließlich ausgerollt. Abhängigkeiten sind sichtbar, bevor sie Zeit und Geld kosten.
- Entscheidungen vorbereiten: Grundsatzfragen, etwa ob die CMDB zentral oder verteilt aufgebaut wird, werden als dokumentierte Architekturentscheidungen vorbereitet und nachvollziehbar getroffen.
Den Nutzen spüren unterschiedliche Bereiche:
- Management: Das Anwendungsportfolio wird steuerbar, und IT-Kosten lassen sich den Geschäftsfähigkeiten zuordnen.
- Informationssicherheit: Eine prüffähige CMDB zeigt, welche Assets es gibt, wer verantwortlich ist und wie kritisch sie sind.
- Einkauf: Bestellt wird nur mit Freigabe und benanntem Verantwortlichen. Wiederverwendung vorhandener Software senkt Lizenzkosten.
- Fachbereiche: Standardfälle laufen ohne Wartezeit durch, nur kritische Vorhaben werden ausführlich geprüft.
6. Praxisbeispiel: Der Weg einer neuen Anwendung
Wie das Zielbild im Alltag wirkt, zeigt ein typischer Fall. Der Vertrieb einer Ländergesellschaft möchte ein neues Werkzeug für die Angebotserstellung einführen.
Anfrage: Statt einer E-Mail an die IT stellt die Vertriebsleiterin die Anfrage über den zentralen Eingang im Serviceportal. Dabei entsteht automatisch ein Entwurf im Anwendungsverzeichnis. Eine Prüfung zeigt, dass in einem anderen Land bereits ein vergleichbares Werkzeug im Einsatz ist.
Freigabe: Weil das Werkzeug Kundendaten verarbeitet, durchläuft es eine mittlere Freigabestufe. Informationssicherheit und Datenschutz prüfen ihre Kriterien, ein Architekt bewertet die Anbindung an das CRM. Ein Standardwerkzeug ohne sensible Daten hätte diese Stufe ohne Wartezeit durchlaufen.
Beschaffung: Der Einkauf bestellt erst, wenn die Freigabe und ein benannter Anwendungsverantwortlicher vorliegen. Da das Unternehmen das vorhandene Werkzeug wiederverwendet, wird lediglich die bestehende Lizenz erweitert.
Inbetriebnahme und Betrieb: Die Anwendung geht erst in Betrieb, wenn die Pflichtangaben vollständig sind. Die automatische Inventarisierung erfasst die installierte Software, die CMDB führt die technischen Komponenten, und der Anwendungsverantwortliche bestätigt seine Angaben in festen Abständen.
Außerbetriebnahme: Wird das Werkzeug später abgelöst, entscheidet die Rolle für das Anwendungsportfolio über die Außerbetriebnahme. Das Team für die CMDB stößt den technischen Rückbau an, und die Inventarisierung bestätigt, dass die Software nicht mehr installiert ist.
Ohne Zielbild hätte derselbe Fall vermutlich zu einem zweiten, parallelen Werkzeug geführt, zu einer Bestellung ohne Prüfung und zu einer Anwendung ohne Verantwortlichen.
Häufige Fragen zum IT-Asset-Management-Zielbild
1. Brauchen wir dafür ein neues Werkzeug?
In der Regel nicht. Meist sind die notwendigen Systeme bereits vorhanden. Das Zielbild legt fest, welches System welche Aufgabe übernimmt und wie sie zusammenarbeiten.
2. Wie lange dauert es, ein Zielbild zu entwickeln?
Für die Initialphase bis zum abgestimmten Zielbild und einer priorisierten Roadmap sollten Sie mit zwei bis vier Monaten rechnen, abhängig von der Zahl der Initiativen und Beteiligten.
3. Wer sollte beteiligt sein?
IT-Leitung, Enterprise Architecture, Informationssicherheit, Datenschutz, das Team für die CMDB, der Einkauf sowie die IT der Ländergesellschaften. Ohne die Unterstützung der Geschäftsführung bleiben verbindliche Regeln wirkungslos.
Fazit: Erst das Zielbild, dann die Technik
Ein Zielbild für das IT-Asset-Management verbindet Systeme, Rollen und Prozesse zu einem gemeinsamen Modell. Es legt fest, welches System welche Daten führt, wer verantwortlich ist und wie eine Anwendung durch ihren Lebenszyklus läuft. Wer zuerst die Grundlagen klärt und dann die Technik anbindet, vermeidet doppelte Datenpflege und teure Nacharbeit.
Sind Sie bereit, Ihre IT-Initiativen auf ein gemeinsames Ziel auszurichten?
- Nehmen Sie Ihre laufenden Initiativen auf und machen Sie Abhängigkeiten sichtbar.
- Legen Sie je Datenklasse ein führendes System fest und benennen Sie die Verantwortlichen.
- Klären Sie das Betriebsmodell, bevor Sie Systeme technisch verbinden.
Wenn Sie dabei Unterstützung wünschen, lassen Sie es mich gerne wissen. Im Architektur-Klarheitsgespräch klären wir in 30 Minuten, wo Ihr Unternehmen heute steht. Wie ich Unternehmen bei Zielbildern und Roadmaps begleite, beschreibe ich im Leistungsfeld Enterprise & IT Architecture.
Herzlich willkommen auf meinem Blog!
Ich modernisiere IT-Systeme und führe Transformationen zum Erfolg.
Direkt, fokussiert, ohne unnötige Umwege.
Seit Jahren begleite ich Unternehmen bei IT-Systemintegration und -Transformation. Ich verstehe Technik aber vor allem verstehe ich die Menschen, die damit arbeiten.
IT-Projekte greifen massiv in bestehende Arbeitsweisen ein. Genau da scheitern sie oft. Meine Stärke? Ich kenne die Praxis.
Ich weiß, was wirklich gebraucht wird. Lassen Sie uns sprechen. Effiziente IT-Transformation beginnt hier.
