IT-Asset-Management in SharePoint: Geräte, Lizenzen und Verträge nachvollziehbar verwalten

Kann SharePoint ein IT-Asset-Management-System oder eine kleine CMDB ersetzen? Für überschaubare Umgebungen kann SharePoint als leichtgewichtiges IT-Asset-Register funktionieren: Geräte, Lizenzen, Verträge, Zuordnungen und Fristen lassen sich in strukturierten Listen abbilden, mit Power Automate überwachen und über Berechtigungen absichern. SharePoint wird jedoch nicht automatisch zu einer vollständigen CMDB. Discovery, Abhängigkeitsanalyse, Software-Metering, Patch-Status, Netzwerk-Topologie und tiefe ITSM-Integration benötigen in der Regel spezialisierte Werkzeuge oder zusätzliche Datenquellen.

Ein belastbares IT-Asset-Management in SharePoint steht und fällt mit dem Datenmodell. Wer alle Informationen in eine einzige Liste schreibt, erzeugt schnell doppelte Werte und widersprüchliche Zustände. Sinnvoller ist eine überschaubare Trennung nach fachlichen Objekten: Asset, Modell, Lizenz, Vertrag, Person, Kostenstelle und Zuordnung.

Wann SharePoint als IT-Asset-Register sinnvoll ist – und wann nicht

SharePoint eignet sich besonders, wenn die IT eine zentrale, nachvollziehbare Sicht auf verwaltete Objekte benötigt, aber kein vollständiges ITSM- oder Discovery-Projekt starten möchte. Typische Ausgangslagen sind:

• Geräte und Lizenzdaten liegen in mehreren Excel-Dateien.
• Verträge und Kündigungsfristen werden in Kalendern oder Postfächern überwacht.
• Ausgaben und Rücknahmen von Geräten sind nicht einheitlich dokumentiert.
• Seriennummern, Garantiezeiten und Kostenstellen sind nur teilweise bekannt.
• Fachbereiche benötigen Lesezugriff, sollen aber Stammdaten nicht verändern.

Ein SharePoint-Register ist dagegen keine gute alleinige Lösung, wenn eine oder mehrere dieser Anforderungen zentral sind:

• automatische Netzwerkerkennung und laufende Inventarisierung,
• Erkennung installierter Software auf Endgeräten,
• Lizenz-Compliance auf Basis tatsächlicher Nutzung,
• Konfigurationsbeziehungen mit hoher Tiefe und vielen Abhängigkeitstypen,
• Incident-, Change- und Problem-Management mit verbindlicher ITIL-Prozessintegration,
• sehr hohe Änderungsraten oder transaktionale Konsistenz über mehrere Systeme.

In solchen Fällen kann SharePoint weiterhin eine ergänzende Rolle spielen, etwa als Portal, Dokumentenablage oder genehmigte Sicht auf Daten aus einem spezialisierten System. Es sollte dann aber nicht als führende Quelle für Informationen eingesetzt werden, die an anderer Stelle automatisch und zuverlässiger erhoben werden.

Abgrenzung zur allgemeinen Inventarverwaltung

Ein IT-Asset-Register unterscheidet sich von allgemeiner Inventarverwaltung durch zusätzliche Beziehungen und Lebenszyklen. Ein Laptop ist nicht nur ein physischer Gegenstand. Er besitzt ein Modell, eine Seriennummer, einen Beschaffungswert, einen Sicherheitsstatus, eine zugeordnete Person, möglicherweise eine Dockingstation, einen Garantievertrag und installierte oder zugewiesene Lizenzen. Für allgemeines physisches Inventar ist der Beitrag Inventar- und Asset-Verwaltung mit Power Apps und SharePoint die passendere Grundlage. Der hier beschriebene Ansatz konzentriert sich auf IT-spezifische Daten und Kontrollen.

Datenmodell für IT-Asset-Management in SharePoint

Ein praxistaugliches Modell kann mit mehreren SharePoint-Listen aufgebaut werden. Die genaue Aufteilung hängt von Umfang und Berichtszielen ab, aber folgende Struktur ist ein belastbarer Startpunkt.

Liste IT-Assets

Diese Liste enthält die konkrete Instanz eines Geräts oder eines anderen verwalteten Objekts.

Die Asset-ID sollte unabhängig vom automatisch vergebenen SharePoint-Listenelement-ID-Wert geführt werden. SharePoint-IDs sind technisch nützlich, aber eine fachliche Kennung bleibt auch bei Migration, Import oder Zusammenführung verständlich.

Liste IT-Modelle

Der Modellstamm verhindert, dass Hersteller, Modellname und Standardattribute bei jedem Gerät erneut eingegeben werden.

Mögliche Felder sind Hersteller, Modellbezeichnung, Kategorie, Standardgarantie, Prozessorfamilie, Arbeitsspeicherklasse, unterstütztes Betriebssystem, Lifecycle-Status und Support-Ende. Nur relativ stabile Modellwerte gehören hier hinein. Individuelle Seriennummern oder Ausgabedaten bleiben im konkreten Asset.

Liste Softwarelizenzen

Eine Lizenzliste sollte zwischen Produkt, Lizenzvertrag und Zuweisung unterscheiden. Ein einzelner Eintrag kann etwa folgende Angaben enthalten:

• Lizenzprodukt und Edition,
• Lizenzmetrik, beispielsweise Benutzer, Gerät oder Kapazität,
• erworbene Menge,
• Vertragsreferenz,
• Laufzeitbeginn und -ende,
• Verlängerungsart,
• verantwortliche Person,
• Status,
• Nachweisdokument oder Link zur Vertragsbibliothek.

Bei komplexen Lizenzmetriken ist SharePoint nur ein Register. Es berechnet nicht automatisch, ob eine Herstellerlizenzierung rechtlich und technisch eingehalten wird. Solche Aussagen benötigen Lizenzfachwissen und gegebenenfalls SAM-Werkzeuge.

Liste Verträge

Verträge sollten nicht nur als PDF in einer Bibliothek liegen. Eine zugehörige Liste oder dokumentbezogene Metadaten machen Fristen auswertbar:

• Vertrags-ID,
• Anbieter,
• Vertragsart,
• Start- und Enddatum,
• Kündigungsfrist,
• automatische Verlängerung,
• Kostenstelle,
• interner Owner,
• Schutzbedarf,
• Link zum Vertragsdokument,
• Prüfstatus.

Das Vertragsdokument gehört in eine geeignete Dokumentbibliothek mit Versionierung und Berechtigungen. Die Liste dient als steuernde Metadatenebene.

Listen Asset-Zuordnungen und Wartungsereignisse

Wer nur die aktuell zugeordnete Person direkt am Asset speichert, verliert die Historie. Eine separate Zuordnungsliste kann jede Ausgabe, Rücknahme und Übergabe dokumentieren:

Feld	Beispiel
Asset	NB-004281
Person	Max Mustermann
Ausgegeben am	2026-03-01
Zurückgegeben am	2026-09-30
Zustand bei Ausgabe	einwandfrei
Zustand bei Rückgabe	Displaykratzer
Übergabenachweis	Link auf PDF oder Formular

Dasselbe Prinzip gilt für Reparaturen, Wartungen und Prüfungen. Eine Ereignisliste ist besser als immer neue Spalten wie Reparatur1, Reparatur2 und Reparatur3.

Beziehungen zwischen Assets, Personen und Kostenstellen abbilden

SharePoint-Nachschlagespalten können Listen innerhalb derselben Site miteinander verbinden. Für ein kleines Register ist das ausreichend, wenn Beziehungen bewusst begrenzt werden. Ein Asset verweist beispielsweise auf ein Modell, eine Kostenstelle und einen Standort. Die Zuordnungsliste verweist auf Asset und Person.

Lookup-Spalten gezielt einsetzen

Nicht jede Anzeigeinformation muss als zusätzliche Nachschlagespalte übernommen werden. Viele Lookup-Spalten verkomplizieren Ansichten, Formulare und Abfragen. Empfehlenswert ist:

• primäre Beziehung über eine stabile ID,
• nur häufig benötigte Zusatzfelder anzeigen,
• nicht bei jeder Namensänderung redundante Kopien erzeugen,
• Löschverhalten definieren.

Bei Stammdaten sollte das Löschen oft eingeschränkt werden. Wird beispielsweise ein Modell gelöscht, obwohl noch Assets darauf verweisen, verliert das Register fachlichen Kontext. Häufig ist ein Status Inaktiv besser als physisches Löschen.

Personenbezug nicht als Freitext speichern

Für interne Nutzer ist eine SharePoint-Personenspalte meist geeigneter als ein Textfeld. Sie referenziert eine Identität und bietet zusätzliche Eigenschaften. Trotzdem braucht das Register einen Ablauf für ausgeschiedene Mitarbeitende. Eine deaktivierte Identität darf nicht dazu führen, dass die historische Zuordnung unverständlich wird. Je nach Berichtszweck kann zusätzlich eine unveränderliche Personal- oder Organisations-ID gespeichert werden, sofern dies datenschutzrechtlich erforderlich und zulässig ist.

Kostenstellen und Organisationseinheiten

Kostenstellen ändern sich. Deshalb sollte geklärt werden, ob Berichte die aktuelle Kostenstelle oder die Kostenstelle zum Zeitpunkt der Beschaffung beziehungsweise Ausgabe zeigen sollen. Für historische Auswertungen kann eine Momentaufnahme im Zuordnungs- oder Buchungsdatensatz sinnvoll sein. Das ist eine bewusste Denormalisierung und muss dokumentiert werden.

Automatisierte Erinnerungen für Ablaufdaten und Wartungsintervalle

Power Automate kann IT-Assets und Verträge zeitgesteuert prüfen. Ein täglicher Flow liest beispielsweise aktive Datensätze mit Garantieende oder Vertragsende in einem definierten Zeitraum.

Beispiel: Vertragsverlängerung kontrollieren

1. Geplanter Flow startet täglich.
2. Er filtert Verträge mit Status Aktiv und nächstem Prüftermin innerhalb der Vorlaufzeit.
3. Er bestimmt den Vertragsverantwortlichen.
4. Er erstellt eine Aufgabe oder sendet eine Benachrichtigung.
5. Er schreibt Erinnerungsstufe und Zeitstempel zurück.
6. Bei Überschreitung eskaliert er an eine definierte Rolle.

Die Kündigungsfrist sollte nicht jedes Mal aus Freitext interpretiert werden. Besser ist ein konkretes Feld Entscheidung erforderlich bis, das bei Anlage oder Änderung berechnet und fachlich bestätigt wird.

Beispiel: Garantie und Wartung

Ein zweiter Flow kann Assets mit bevorstehendem Garantieende markieren. Für Server oder Netzwerkgeräte können zusätzlich Wartungsintervalle geführt werden. Die Erinnerung allein genügt jedoch nicht. Der Datensatz benötigt ein Ergebnis wie Garantieverlängerung geprüft, Ersatz geplant oder Kein Handlungsbedarf.

Fehlerbilder bei Erinnerungsflows

Typische Probleme sind:

• Datumswerte werden wegen Zeitzonen um einen Tag verschoben.
• Ein Filter liest auch ausgemusterte Assets.
• Jede tägliche Ausführung sendet dieselbe Nachricht erneut.
• Der Verantwortliche ist ausgeschieden oder nicht mehr berechtigt.
• Ein Vertrag besitzt kein berechenbares Entscheidungsdatum.
• Der Flow schreibt auf das Element und löst dadurch einen zweiten Flow aus.

Gegenmassnahmen sind Statusfilter, Erinnerungsstufen, Vertretungsgruppen, Validierungsansichten und ein technisches Protokollfeld.

Berechtigungen: Wer darf sehen, ändern und auditieren

IT-Asset-Daten sind nicht in jedem Fall hochsensibel, können aber Sicherheits- und Personendaten enthalten. Seriennummern, Gerätekonfigurationen, Standorte, Administrationszuständigkeiten und Nutzerzuordnungen sollten nicht automatisch für alle Mitarbeitenden sichtbar sein.

Ein einfaches Rollenmodell kann so aussehen:

Rolle	Typische Rechte
IT-Asset-Management	Erstellen, ändern, ausmustern
Service Desk	Zuordnungen und Status bearbeiten
Einkauf/Controlling	Verträge und Kosten lesen oder pflegen
Auditor/Revision	Lesen, Versionen und Nachweise prüfen
Fachbereich	eingeschränkte Lesesicht auf eigene Assets
Automatisierungskonto	nur erforderliche Listen und Bibliotheken

Berechtigungen möglichst auf Site- oder Listenebene

SharePoint unterstützt individuelle Berechtigungen, aber ein Modell mit tausenden itembezogenen Berechtigungsbereichen ist schwer wartbar. Microsoft dokumentiert ein unterstütztes Maximum von 50.000 eindeutigen Berechtigungsbereichen pro Liste oder Bibliothek; zugleich werden für gute Leistung deutlich weniger empfohlen. Für ein Asset-Register sind separate Sites oder Listen für unterschiedliche Schutzbereiche meist robuster als individuelle Rechte auf jedem einzelnen Gerätedatensatz.

Wenn Nutzer nur ihre eigenen Geräte sehen sollen, ist zu prüfen, ob eine gefilterte Oberfläche genügt oder echte Zugriffstrennung erforderlich ist. Eine Ansicht ist keine Sicherheitsgrenze. Vertrauliche Daten müssen durch Berechtigungen, getrennte Speicherorte oder eine geeignete Anwendung abgesichert werden.

Versionierung und Audit

SharePoint-Versionierung kann Änderungen an Listenelementen und Dokumenten nachvollziehbarer machen. Für sicherheitsrelevante Auswertungen kann zusätzlich Microsoft Purview Audit Aktivitäten protokollieren. Diese Funktionen ersetzen keine fachliche Änderungsbegründung. Für kritische Felder wie Status, Zuordnung oder Ausmusterung ist eine eigene Ereignisliste mit Grund, Bearbeiter und Zeitstempel oft aussagekräftiger.

Datenimport und Abgleich mit anderen Systemen

Viele IT-Asset-Register starten nicht leer. Daten kommen aus Excel, Endpoint-Management, Einkauf, Verzeichnisdiensten oder einem alten Ticketsystem. Der Import sollte in drei Stufen erfolgen:

1. Staging: Quelldaten unverändert übernehmen.
2. Validierung: Pflichtfelder, Dubletten, Datentypen und Referenzen prüfen.
3. Übernahme: nur gültige und eindeutig zuordenbare Datensätze in das Produktivregister schreiben.

Ein direkter Massenimport in die produktive Liste erschwert Korrekturen. Sinnvoll sind Import-ID, Quellenname und Importzeitpunkt. Damit lassen sich Datensätze eines fehlerhaften Laufs identifizieren und bei Bedarf gezielt zurücksetzen.

Führendes System pro Attribut festlegen

Nicht jedes Feld muss in SharePoint gepflegt werden. Ein Feldkatalog sollte für jedes Attribut festlegen:

• fachliche Bedeutung,
• Datenquelle,
• führendes System,
• Aktualisierungsrhythmus,
• zulässige Bearbeiter,
• Konfliktregel.

Beispiel: Seriennummer und Gerätemodell kommen aus Endpoint-Management, Kostenstelle aus ERP, aktuelle Nutzerzuordnung aus dem Service-Desk-Prozess und Vertragsdaten aus dem Einkauf. Ohne diese Festlegung überschreibt eine manuelle Änderung möglicherweise beim nächsten Import wieder den korrekten Wert.

Grenzen von SharePoint als CMDB

Eine CMDB bildet nicht nur Objekte, sondern auch Konfigurationsbeziehungen, Zustandsänderungen und Auswirkungen ab. SharePoint-Listen können einfache Beziehungen darstellen, sind aber kein Graphmodell und keine automatische Discovery-Plattform.

Ein dediziertes Tool wird sinnvoll, wenn:

• Abhängigkeiten zwischen Services, Anwendungen, Servern und Netzwerkkomponenten zentral sind,
• Änderungen automatisch aus vielen Quellen zusammengeführt werden müssen,
• Incident- und Change-Prozesse direkt auf CIs zugreifen,
• Lizenznutzung technisch gemessen werden muss,
• rollenbasierte Detailrechte und Mandantentrennung sehr fein ausfallen,
• hohe Datenmengen oder häufige parallele Aktualisierungen auftreten,
• standardisierte CMDB-Funktionen und Zertifizierungen gefordert sind.

SharePoint kann dann weiterhin als kuratierte Sicht, Freigabeoberfläche oder Dokumentenablage dienen. Die führende technische Wahrheit sollte jedoch im spezialisierten System bleiben.

Tests, Wartung und Rückfallwege

Vor der Freigabe sollte das Register mit einem dokumentierten Testkatalog geprüft werden.

Funktionstests

• Asset mit vollständigen Daten anlegen.
• Doppelte Asset-ID und Seriennummer erkennen.
• Zuordnung anlegen, ändern und beenden.
• Vertrag mit Kündigungsfrist anlegen.
• Erinnerung vor, am und nach dem Termin auslösen.
• Inaktiven Verantwortlichen simulieren.
• Ausgemustertes Asset aus aktiven Ansichten entfernen.
• Historie nach Änderung prüfen.

Berechtigungstests

• Fachbereich sieht nur freigegebene Informationen.
• Service Desk kann Zuordnung ändern, aber keinen Vertrag löschen.
• Auditor kann lesen, aber nicht bearbeiten.
• Flow-Identität besitzt keine weitergehenden Rechte als nötig.
• Freigabelinks umgehen das Rollenmodell nicht unbeabsichtigt.

Rückfallweg

Fällt ein Import oder Flow aus, muss das Register weiterhin kontrollierbar bleiben. Ein Rückfallplan enthält:

• Ansicht aller Datensätze mit veraltetem Letzter Abgleich,
• manuelle Arbeitsanweisung für dringende Ausgaben und Rücknahmen,
• Protokoll der nicht verarbeiteten Änderungen,
• Verfahren zum erneuten Einspielen ohne Dubletten,
• Sicherung oder Export vor Massenkorrekturen,
• benannten Verantwortlichen für Freigabe der Wiederaufnahme.

So bleibt das IT-Asset-Register auch im Betrieb konsistent und auditfähig

Ein belastbares IT-Asset-Management in SharePoint trennt Stammdaten, konkrete Assets, Verträge, Lizenzen und Ereignisse. Es legt pro Feld ein führendes System fest, vermeidet unnötige Einzelberechtigungen und speichert fachliche Ergebnisse statt nur Benachrichtigungen. Entscheidend ist nicht die Zahl der erfassten Geräte, sondern ob Zuordnung, Frist, Änderung und Verantwortlichkeit auch Monate später eindeutig erklärt werden können. Sobald Discovery, komplexe Abhängigkeiten oder Lizenz-Metering erforderlich werden, sollte das Register gezielt durch ein spezialisiertes System ergänzt oder ersetzt werden.