Lizenzmanagement: Wer braucht einen Sitz, wer nur Zugriff — und wer zahlt?
TL;DR (Quick Summary)
Ein strukturiertes Lizenzmanagement macht ungenutzte oder überdimensionierte Lizenzen sichtbar und senkt dadurch Kosten. Es scheitert selten am Einkauf, sondern an wiederkehrenden Entscheidungen im Alltag: Wer braucht einen persönlichen Sitz, wer nur begrenzten Zugriff, und welche Kostenstelle übernimmt was? Das lässt sich mit festen Regeln, wenigen Arbeitsdokumenten und einer verbindlichen Review-Logik steuern.
- Lizenzprozess am Alltag ausrichten → wiederkehrende Entscheidungen statt Einzelfälle steuern
- Verbindliche Zuweisungsregeln → Sitz und Zugriff klar trennen
- Lebenszyklus klar regeln → Eintritt, Wechsel und Austritt ohne Grauzonen
- Kontrollpunkte gegen Inaktivität → ungenutzte Sitze werden beendet
- Kosten fair verrechnen → Jahresprüfung als Sparhebel nutzen
Takeaway: Ein brauchbarer Lizenzprozess verbindet Zuweisung, Nutzung, Entzug und Verrechnung in einem Ablauf. Wer dabei gelegentliche Nutzer und Ausnahmen mitführt, spart nicht nur Kosten, sondern schließt auch typische Kontrolllücken.
Lizenzen laufen oft deshalb aus dem Ruder, weil Sitzvergabe, Zugriff und Kostenverantwortung getrennt behandelt werden. Lizenzmanagement funktioniert erst dann zuverlässig, wenn jede wiederkehrende Entscheidung in einem festen Ablauf landet – von der Bedarfsmeldung bis zur Rücknahme und Verrechnung.
Wie viel dabei zu gewinnen ist, hängt vom Lizenzmodell ab. Bei Tools mit Abrechnung pro Nutzer zählt jeder einzelne Sitz. Bei Plattformen mit Festpreis je Tarif, wie der Cloud-Version von Bitrix24, verschiebt sich die Frage: Entscheidend ist dann, ob die Nutzerobergrenze des Tarifs zum tatsächlichen Bedarf passt und wer die Plattformkosten intern trägt. Die Grundlogik bleibt dieselbe: Wer bekommt vollen Zugriff, wer arbeitet eingeschränkt, welche Alternativen sind zulässig, und wer zahlt?
Den Lizenzprozess um die wiederkehrenden Entscheidungen herum aufbauen
Viele Teams denken beim Lizenzmanagement zuerst an Vertragslaufzeiten oder an die Zahl gekaufter Sitze. Das greift zu kurz. Die eigentliche Steuerung passiert früher und häufiger: bei jeder Zugriffsanfrage, bei jeder Rollenänderung, bei jeder Vertretung und bei jedem Austritt.
Die wiederkehrenden Fragen lauten: Braucht diese Person einen namentlichen Sitz? Reicht ein eingeschränkter Zugriff? Kann sie über eine gemeinsam bereitgestellte Funktion arbeiten? Und welcher Bereich übernimmt die Kosten? Werden diese Fragen nicht einheitlich beantwortet, wächst der Bestand zufällig.
Typische Bruchstellen entstehen dort, wo kurzfristig entschieden wird: Ein Projekt startet, eine Führungskraft macht Druck, gelegentliche Nutzer arbeiten über Umwege, oder beim Offboarding bleiben Nebensysteme und Sonderrollen aktiv. Am Ende landet die Rechnung gesammelt in der IT, obwohl die Nutzung fachlich verteilt ist.
Ein tragfähiges Zielbild ist deshalb kein starres Regelwerk, sondern ein wiederholbarer Ablauf. Er beginnt mit der Bedarfsmeldung inklusive Rolle und Kostenstelle. Danach folgen die Prüfung des passenden Lizenztyps, die Zuweisung oder eine Alternative, die laufende Nutzungskontrolle, die Umverteilung bei geänderten Aufgaben und schließlich der Entzug des Zugriffs. Die verursachungsgerechte Verrechnung gehört von Anfang an dazu, nicht erst zur Diskussion am Jahresende.
Entscheidungsmatrix: Sitz oder Zugriff für faire Abrechnung
Geben Sie Ihre E-Mail-Adresse ein, um eine umfassende Schritt-für-Schritt-Anleitung zu erhalten
Verbindliche Zuweisungsregeln festlegen, damit Sitz und Zugriff nicht verwechselt werden
Der häufigste Fehler ist simpel: Vollsitz und Zugriff werden gleichgesetzt. Wer irgendwie in ein Tool hinein muss, bekommt vorsorglich die umfassendste Lizenz. Das ist bequem, aber teuer und oft unnötig.
Besser ist eine dokumentierte Einteilung nach Nutzungsklassen: volle Produktivnutzung, gelegentliche Nutzung, reine Leserechte, Genehmigerrollen, externe Beteiligte und befristete Projektzugriffe. Diese Klassen müssen nicht kompliziert sein, aber belastbar genug, damit Anfragen nicht jedes Mal neu diskutiert werden.
Für jede Klasse braucht es konkrete Mindestanforderungen:
- Nutzungshäufigkeit: Arbeitet die Person regelmäßig im System oder nur an einzelnen Vorgängen?
- Geschäftskritische Aufgaben: Muss sie Daten erfassen, ändern, freigeben oder nur einsehen?
- Compliance-Vorgaben: Ist ein personenbezogener Zugriff zwingend, etwa wegen Nachvollziehbarkeit oder Freigabehistorie?
- Benötigte Funktionen: Reichen Lese-, Kommentar- oder Genehmigerrechte aus?
- Zulässige Alternativen: Gibt es Portale, Berichte, Exporte oder genehmigte Sammelfunktionen statt eines Vollsitzes?
Beispiele je Nutzungsklasse:
- Volle Produktivnutzung: Ein Entwickler braucht in Jira einen Vollsitz, weil er täglich Aufgaben erstellt, bearbeitet und kommentiert.
- Gelegentliche Nutzung: Ein Controller arbeitet in SAP nur sporadisch mit Finanzdaten und erhält deshalb einen Zugang mit eingeschränkten Buchungsrechten.
- Reine Leserechte: Eine Mitarbeiterin im Finanzbereich sieht in SAP ausschließlich Berichte ein und braucht dafür nur eine Anzeigelizenz.
- Genehmigerrollen: Eine Teamleiterin erhält in Jira die Genehmigerrolle, damit sie Urlaubs- oder Einkaufsanträge freigeben kann und die Freigabehistorie nachvollziehbar bleibt.
- Externe Beteiligte und befristete Projektzugriffe: Ein externer Partner arbeitet in Bitrix24 nur in dem Bereich, zu dem er eingeladen wurde, statt einen vollwertigen Mitarbeiterzugang zu bekommen. Ob das auch Lizenzkosten spart, hängt vom Lizenzmodell des jeweiligen Tools ab.
Ausnahmen wird es trotzdem geben. Entscheidend ist, dass sie begrenzt bleiben. Zu jeder Ausnahme gehört eine Begründung: Welche Aufgabe lässt sich mit der Standardklasse nicht abbilden, welche Alternative wurde geprüft, und bis wann wird die Ausnahme erneut bewertet?
Ohne Wiedervorlage werden Ausnahmen zum Dauerzustand. Deshalb gehört zu jeder Abweichung ein Enddatum oder mindestens ein verbindlicher Prüftermin.
Rollen, Freigaben und Übergaben im Lebenszyklus eindeutig machen
Selbst gute Zuweisungsregeln helfen wenig, wenn unklar bleibt, wer im Ablauf was auslöst. Lizenzmanagement hängt an Übergaben, und dort bleiben Dinge liegen.
Die Grundverteilung der Verantwortung ist meist überschaubar. Der Fachbereich meldet Bedarf und Kostenstelle. Die IT oder der Tool-Verantwortliche prüft Lizenztyp und freie Kontingente. HR oder der Identity-Prozess liefert Ereignisse wie Eintritt, Wechsel oder Austritt. Daraus muss ein verbindlicher Ablauf entstehen, nicht nur eine lose Abstimmung.
Kritisch sind die Punkte im Lebenszyklus, an denen Zugriffe schnell geändert werden müssen: Neueintritte, Rollenwechsel, Vertretungen, Projektstarts, Vertragsenden, interne Wechsel und Austritte. Sonst verlässt eine Person die Abteilung und behält alte Rollen, ein Projekt endet ohne Entzug der befristeten Zugriffe, oder ein Vertretungszugang bleibt bestehen.
Auch Freigaben brauchen eine feste Route. Wer Bedarf meldet, sollte nicht gleichzeitig Lizenzklasse und Ausnahme selbst festlegen. Anforderung, Prüfung und Freigabe sollten getrennt sein, zumindest bei kostenrelevanten oder sensiblen Tools.
Eine mögliche Verteilung nach dem RACI-Schema (verantwortlich, rechenschaftspflichtig, einbezogen, informiert) – und wie man solche Entscheidungen festhält, beschreibt der Beitrag zum Dokumentieren von Entscheidungen:
- Eintritt: Der Fachbereich ist verantwortlich für die Bedarfsmeldung, HR ist rechenschaftspflichtig für den Eintritt, die IT wird zur Lizenzprüfung einbezogen, die Geschäftsführung wird informiert.
- Wechsel: HR ist verantwortlich für die Meldung des Rollenwechsels, der Tool-Verantwortliche ist rechenschaftspflichtig für die Anpassung der Lizenz, der Fachbereich wird einbezogen, Finance wird über Kostenänderungen informiert.
- Austritt: HR ist verantwortlich für die Austrittsmeldung, die IT ist rechenschaftspflichtig für den Entzug aller Zugriffe, der Fachbereich wird zur Bestätigung einbezogen, Compliance wird über die abgeschlossenen Schritte informiert.
Für widersprüchliche Datenquellen braucht es einen Eskalationsweg: HR zeigt „ausgetreten“, im Verzeichnis ist das Konto noch aktiv, im Tool wurde letzte Woche noch gearbeitet. Oder ein aktiver Nutzer hat keinen erkennbaren Verantwortlichen mehr, weil Team, Projekt oder Kostenstelle nicht mehr stimmen. Dann muss klar sein, wer entscheidet, wer vorläufig sperren darf und wer die Zuordnung nachzieht.
Ist diese Eskalation nicht definiert, bleiben problematische Konten aus Vorsicht oft bestehen.
Die wenigen Arbeitsdokumente pflegen, die den Prozess tatsächlich steuerbar machen
Lizenzmanagement scheitert oft nicht an fehlenden Daten, sondern an zu vielen halbfertigen Listen. Sinnvoll sind wenige Dokumente, dafür gepflegt und mit klarer Funktion.
Das erste ist ein kompaktes Lizenzregister. Es muss kein schwerfälliges System sein, sollte pro Anwendung aber mindestens Lizenztyp, zugewiesene Person, Rolle, Kostenstelle, Verantwortlichen, Startdatum und nächsten Prüftermin enthalten.
Damit lassen sich drei Fragen schnell beantworten: Wer nutzt was? Warum hat die Person diesen Lizenztyp? Und wann wird der Fall wieder geprüft? Fehlt eine dieser Antworten, wird jede Bereinigung mühsam.
Das zweite ist eine Entscheidungsmatrix oder eine knappe Richtlinie pro Tool-Gruppe. Darin stehen Zuweisungsregeln, zulässige Ausnahmen, zuständige Genehmiger und erlaubte Zugriffsalternativen. So müssen dieselben Grundsatzfragen nicht jede Woche neu verhandelt werden.
Das dritte ist für kostenrelevante Anwendungen besonders wichtig: eine Abteilungsübersicht. Sie zeigt gekaufte Kontingente, belegte und inaktive Sitze, gemeinsam genutzte Zugriffe und die zu verrechnenden Beträge. Diese Sicht bringt Fachbereiche dazu, ihren Bestand als eigene Ressource zu behandeln.
|
Dokument |
Zweck |
Pflichtinhalte |
Minimalbeispiel |
|---|---|---|---|
|
Lizenzregister |
Einzelfallsteuerung und Review |
Person, Lizenztyp, Rolle, Kostenstelle, Verantwortlicher, Startdatum, Prüftermin |
M. Schmidt – Jira-Vollsitz – Entwickler – Kostenstelle IT-Dev – verantwortlich: Tool-Owner IT – Start 01.03.2026 – Prüfung 01.09.2026 |
|
Entscheidungsmatrix |
Einheitliche Zuweisung |
Regeln, Ausnahmen, Genehmiger, Alternativen |
Regel: Vollsitz nur bei täglicher Bearbeitung; Ausnahme: Projektleitung mit befristetem Zugriff; Genehmiger: Tool-Owner und Fachbereichsleitung; Alternative: Leselizenz oder Exportberichte |
|
Abteilungsübersicht |
Kosten- und Bestandssteuerung |
Kontingente, belegte und inaktive Sitze, gemeinsame Zugriffe, Verrechnung |
IT-Dev – Kontingent 50 – belegt 47 – inaktiv 3 – gemeinsame Zugriffe 5 – Kosten 12.000 € |
Mehr Dokumentation macht den Prozess nicht automatisch besser. Diese drei Dokumente reichen oft aus, solange sie aktuell bleiben und im Tagesgeschäft verwendet werden.
Mit festen Kontrollpunkten verhindern, dass ungenutzte Sitze weiterlaufen
Ohne feste Prüftermine laufen Lizenzen weiter, weil niemand einen Anlass hat, sie anzufassen. Deshalb braucht der Prozess feste Kontrollpunkte.
Wie oft geprüft wird, richtet sich nach Kritikalität und Kosten. Teure SaaS-Verträge oder stark regulierte Tools sollten enger geprüft werden als breit ausgerollte Anwendungen mit geringem Einzelwert. Hinzu kommen ereignisbasierte Prüfungen, etwa bei Austritt oder Rollenwechsel, weil genau dort Fehlbestände entstehen.
Die Prüfung darf nicht nur auf Logins schauen. Ein Login sagt wenig darüber aus, ob eine volle Lizenz gerechtfertigt ist. Aussagekräftiger ist die tatsächliche Funktionsnutzung: Wird aktiv erstellt, geändert, administriert oder nur gelesen? Wer seit Monaten keine produktiven Funktionen nutzt, ist ein Kandidat für ein Downgrade oder den Entzug, auch wenn gelegentlich ein Login stattfindet.
Eine interne Richtlinie könnte zum Beispiel so aussehen – die konkreten Werte legt jedes Unternehmen selbst fest:
- Inaktivität: Prüfung nach 60 Tagen ohne produktive Nutzung, verbindliche Entscheidung über den Entzug nach 90 Tagen.
- Vertragshöhe: große Verträge monatlich prüfen, kleine vierteljährlich.
- Befristete Lizenzen: Prüfung spätestens eine Woche vor dem Enddatum.
- Doppelte Ausstattung: sofort prüfen, ob ein Downgrade möglich ist.
- Fehlende Freigabe: Lizenzen ohne bestätigte Freigabe der Führungskraft werden nach einem Monat eskaliert.
Zusätzlich sollte die Prüfung gezielt nach bestimmten Mustern suchen:
- Doppelte Ausstattung: Nutzer haben mehrere Werkzeuge oder Lizenzstufen mit überlappender Funktion.
- Ruhende Projektkonten: Zugriffe laufen weiter, obwohl das Projekt faktisch beendet ist.
- Überfällige befristete Lizenzen: Enddatum überschritten, aber keine Verlängerungsentscheidung dokumentiert.
- Unbestätigte Freigaben: Der Bestand wird weitergeführt, obwohl die fachliche Bestätigung fehlt.
Wirkung entsteht erst durch die Folgemaßnahme. Jede Prüfung muss zu einer klaren Entscheidung führen: behalten, herabstufen, entziehen, neu zuordnen oder als begründete Ausnahme dokumentieren. Produzieren Reviews nur Listen ohne Fristen und Verantwortliche, verschiebt sich das Problem in den nächsten Zyklus.

Gelegentliche Nutzer sichtbar machen, bevor sie zu Schattenkosten oder einem Compliance-Risiko werden
Typische Beispiele sind gemeinsame Postfächer, Leselinks, Admin-Ausnahmen, Freigabewege außerhalb des Kernsystems oder nicht integrierte Fachanwendungen. Auch externe Beteiligte oder interne Vertretungen tauchen oft nur teilweise auf. So nutzt die Organisation Funktionen, die der offizielle Lizenzbestand nicht vollständig abbildet.
Diese Nutzergruppen müssen aktiv erfasst werden: über Abfragen bei Führungskräften, Rollenkataloge, Projektlisten, Genehmigerpools und den Abgleich mit Zugriffsprotokollen oder Verzeichnisdaten.
Fragen an die Führungskräfte:
- „Welche Personen benötigen nur gelegentlichen Zugriff?“
- „Wer muss Daten einsehen, aber nicht aktiv bearbeiten?“
- „Welche befristeten Projektrollen laufen aktuell?“
Typische Datenquellen:
- Systemprotokolle (Funktionsnutzung: Erstellen, Bearbeiten, Freigeben)
- SSO- und Identity-Protokolle (Häufigkeit und Dauer der Anmeldungen)
- Berichte der Tools (Lese- gegenüber Bearbeitungsaktivität)
Mögliche Genehmiger:
- Fachbereichsleitung für operative Rollen
- Tool-Verantwortliche oder IT für technische Zuweisungen
- Compliance oder Datenschutz für sensible Zugriffe
Kategorien für die Zuordnung:
- Ohne Zusatzkosten tolerierbar: Der Zugriff ist bewusst begrenzt und verursacht keinen relevanten Zusatzaufwand und kein Lizenzrisiko.
- Günstigere Zugriffsstufe: Die Nutzung ist real, aber ein Vollsitz wäre überzogen.
- Personenbezogener Sitz erforderlich: auch bei geringer Nutzung, wenn Freigabehistorie, Verantwortlichkeit oder Compliance es verlangen.
Gerade der letzte Punkt wird oft übersehen. Geringe Nutzung heißt nicht automatisch geringer Lizenzbedarf. Wer rechtsverbindlich freigibt, sensible Daten sieht oder eine nachvollziehbare Einzelverantwortung trägt, braucht unter Umständen trotzdem einen persönlichen Sitz.
Gemeinsam genutzte Postfächer oder Sammelkonten erschweren die Nachvollziehbarkeit, weil sich Zugriffe keiner einzelnen Person mehr zuordnen lassen. Bei audit- oder compliance-relevanten Vorgängen sollten sie deshalb vermieden werden.
Perfektionieren Sie Ihr Lizenzmanagement
Mit Bitrix24 können Sie effektive Lizenzmanagementprozesse implementieren und optimieren, Kosten einsparen und Ihre Geschäftsabläufe verbessern. Probieren Sie es noch heute aus!
Jetzt startenKosten fair verrechnen und die Jahresprüfung als Sparhebel nutzen
Bleiben Lizenzkosten pauschal in der IT, fehlt dem Fachbereich der Anreiz, Bestände aktiv zu hinterfragen. Deshalb braucht es ein einfaches Verteilungsmodell, das zur tatsächlichen Nutzung passt.
Am einfachsten ist die direkte Zuordnung benannter Sitze zur jeweiligen Kostenstelle. Schwieriger sind gemeinsam genutzte oder zentral finanzierte Lizenzen. Dafür braucht es eine feste Regel: Verteilung nach Nutzerkreis, nach definierten Leistungseinheiten oder als zentrale Plattformkosten mit transparentem Umlageschlüssel. Die Methode muss nicht perfekt sein, aber nachvollziehbar und stabil.
Bereichsübergreifende Plattformen brauchen oft eine Mischlogik. Direkt zurechenbare Lizenzen werden den Kostenstellen zugeordnet, zentrale Administrations- oder Basisfunktionen bleiben im gemeinsamen Topf. Bei Plattformen mit Festpreis je Tarif wird meist der gesamte Tarif nach einem Schlüssel umgelegt. Entscheidend ist, dass Kosten weder doppelt auftauchen noch unsichtbar bleiben.
Die Jahresprüfung ist kein Reporting-Termin, sondern ein Entscheidungspunkt. Sie sollte in konkrete Maßnahmen münden:
- Verlängerung anpassen: Bestände werden vor der Verlängerung an den realen Bedarf angepasst.
- Reserven überprüfen: Nicht jede historische Sicherheitsreserve ist noch nötig.
- Altverträge zusammenführen: Unterschiedliche Vertragsstände oder Lizenzmodelle werden gebündelt.
- Verrechnung korrigieren: Kosten landen dort, wo die Nutzung heute tatsächlich stattfindet.
- Einsparungen nachweisen: Entzogene, herabgestufte oder nicht verlängerte Lizenzen werden belastbar dokumentiert.
Hier zeigt sich, ob der Prozess über das Jahr funktioniert hat. Wer Zuweisungen, Ausnahmen, Inaktivität und gelegentliche Nutzer sauber erfasst, geht mit einem belastbaren Bestand in die Verlängerung.
Rechenbeispiel für ein Tool mit Abrechnung pro Nutzer:
- Vor der Prüfung: 200 Vollsitze zu je 500 € → 100.000 € pro Jahr.
- Nach der Prüfung: 30 Nutzer werden auf Leselizenzen zu je 100 € umgestellt, 20 Sitze werden entzogen.
- Neue Kosten: (150 × 500 €) + (30 × 100 €) = 75.000 € + 3.000 € = 78.000 €.
- Einsparung: 22.000 € pro Jahr.
Damit Einsparungen belastbar nachgewiesen werden können, muss jede Maßnahme dokumentiert sein. Alle Schritte werden in einem prüffähigen Register festgehalten, sodass Einkauf, Revision und Fachbereiche nachvollziehen können, wie die Einsparung zustande kam. Nur dann gilt die Reduktion als belegt und kann im nächsten Zyklus angerechnet werden.