Leseprobe Torsten Groll - bücher.de · 2018. 7. 2. · 20.5.1 Szenario 1 IBM-Lizenzierung ........

Leseprobe

Torsten Groll

1x1 des Lizenzmanagements

Praxisleitfaden für Lizenzmanager

ISBN (Buch): 978-3-446-44392-1

ISBN (E-Book): 978-3-446-44426-3

Weitere Informationen oder Bestellungen unter

http://www.hanser-fachbuch.de/978-3-446-44392-1

sowie im Buchhandel.

© Carl Hanser Verlag, München

http://www.hanser-fachbuch.de/978-3-446-44392-1

Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII Vorwort zur 2. Auflage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV Vorwort zur 3. Auflage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV

Teil I: Das Lizenzmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Lizenzmanagement – vom Risiko zum Wert . . . . . . . . . . . . . . . . . . . . . . . 31.1 Lizenzmanagement – eine Begriffsdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Allgemeine Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.1 Transparenz schaffen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.2 Kosten senken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.3 Compliance herstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.4 Rechtmäßigkeit gewährleisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 Aktives Lizenzmanagement – Potenzial und Nutzen . . . . . . . . . . . . . . . . . . . . . . 151.5 Lizenzmanagement – Ausblick und Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Eine Softwarelizenz – was ist das? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1 Softwarelizenz – begriffliche Klärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Die gebräuchlichsten Lizenzformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.1 Proprietäre Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.2 Freie Software, Free Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3 Über- oder unterlizenziert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.1 Überlizenzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2 Unterlizenzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4 Unlizenzierte Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4.1 Wie gelangt unlizenzierte Software in das Unternehmen? . . . . . . . . . . . 31

2.5 Softwarelizenz kaufmännisch betrachtet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.5.1 Full Package Product (FPP, Box-Produkt) . . . . . . . . . . . . . . . . . . . . . . . . . 342.5.2 System-Builder-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.5.3 OEM-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Inhalt

VI Inhalt

2.6 Der Lizenzvertrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.6.1 End User License Agreement (EULA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.6.2 Universelle Produktnutzungsrechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.6.3 Der Lizenzvertrag für Freie Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.7 Das Lizenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.7.1 Die Lizenzart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.7.2 Die Lizenzklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.7.3 Der Lizenztyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.7.4 Die Lizenzmetrik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.8 Rechtliche Bestimmungen zur Softwarenutzung in Deutschland . . . . . . . . . . . . 502.8.1 Das deutsche Urheberrecht (UrhG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.8.2 Bestimmung zur Erstellung einer Sicherungskopie . . . . . . . . . . . . . . . . 512.8.3 Verletzung des Vervielfältigungsrechts . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.9 Zivil-, straf- und handelsrechtliche Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.9.1 Zivilrechtliche Haftung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.9.2 Strafrechtliche Haftung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.9.3 Handelsrechtliche Haftung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.10 SOX, EuroSOX, Basel II, KonTraG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.11 Gebrauchte Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3 Der IT-Arbeitsplatz – eine „Black Box“? . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.1 Die Software verwalten und managen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.2 Der Softwarekatalog – welche Software kommt ins Unternehmen? . . . . . . . . . . 63

3.2.1 Softwareportfolio – Schutz vor Softwarewildwuchs . . . . . . . . . . . . . . . . . 663.2.2 Softwareportfolio managen – Kosten reduzieren . . . . . . . . . . . . . . . . . . . 673.2.3 Softwarewarenkorb – Basis für das Lizenzinventar . . . . . . . . . . . . . . . . . 68

Teil II: Der Aufbau des Lizenzmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4 Das Lizenzmanagement projekt starten . . . . . . . . . . . . . . . . . . . . . . . . . . 734.1 Die zehn wichtigsten Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.2 Voraussetzungen für den Start schaffen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.3 Ziele und Nutzen für den Projektauftrag definieren . . . . . . . . . . . . . . . . . . . . . . 784.4 Rollen und Verantwortlichkeiten klar verteilen . . . . . . . . . . . . . . . . . . . . . . . . . . 804.5 Die Risiken einschätzen und bewerten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5 Den Projektplan aufstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.1 Was gehört zum Projektplan? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.1.1 Das Ziel ist der Weg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.1.2 Was ist zu planen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.2 Eine Roadmap definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.3 Projektphasen und Meilensteine erarbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Inhalt VII

5.4 Die Arbeitspakete festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.5 Die möglichen Baustellen identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Teil III: Die Darstellung der Ist-Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6 Erste Schritte zur Analyse und Dokumentation der Ist-Situation . . . . . 1096.1 Aufnahme der Ist-Situation – wo beginnen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.1.1 Die kaufmännischen Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136.1.2 Die technischen Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.1.3 Richtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.1.4 Rollen und Verantwortlichkeiten identifizieren . . . . . . . . . . . . . . . . . . . . 116

6.2 Dokumentation der Ist-Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7 Prozesse: Strukturen analysieren, bewerten, optimieren . . . . . . . . . . . 1197.1 Der Software-Life-Cycle-Prozess im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207.2 Der Software-Life-Cycle-Prozess und seine Schnittstellen . . . . . . . . . . . . . . . . . . 1227.3 Die bisherigen Strukturen und Prozesse untersuchen und bewerten . . . . . . . . 1247.4 Komplexitätstreiber identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1277.5 Die Reifegradanalyse – eine Methode für das Benchmarking und

Optimieren von Prozessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307.5.1 Reifegradbestimmung mit dem CMMI-Modell . . . . . . . . . . . . . . . . . . . . . 1317.5.2 Reifegradbestimmung mit der Norm ISO/IEC 19770-1 . . . . . . . . . . . . . . 134

8 Den Software-Life-Cycle-Prozess optimieren . . . . . . . . . . . . . . . . . . . . . . 1438.1 Die Soll-Prozesse modellieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1448.2 Einteilung der Softwarekategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

8.2.1 Kategorie-1-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548.2.2 Kategorie-2-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1548.2.3 Kategorie-3-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

8.3 Einordnung des Lizenzmanagements in die ITIL®-Umgebung . . . . . . . . . . . . . . 1558.4 Übersicht KPIs im Lizenzmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1578.5 Rollen und Verantwortlichkeiten definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

8.5.1 Die Rolle Strategischer Lizenzmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . 1638.5.2 Die Rolle Operativer Lizenzmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1648.5.3 Die Rolle Produktverantwortlicher/Softwareexperte . . . . . . . . . . . . . . . . 167

8.6 Die wichtigsten Richtlinien für den Umgang mit Software . . . . . . . . . . . . . . . . . 1698.6.1 Erstellen einer Richtlinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

9 Die Beschaffungsprozesse Bedarfsanforderung und Bestellung von Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

9.1 Den Beschaffungsprozess analysieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739.2 Der Softwareanforderungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

9.2.1 Eine Softwareanforderung auslösen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

VIII Inhalt

9.3 Der Softwarebestellprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1799.3.1 Die interne Bestellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1799.3.2 Die externe Bestellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1809.3.3 Weitere Beschaffungswege identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . 181

Teil IV: Die Aufnahme und Sichtung der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . 185

10 Technische Bestands aufnahme der Softwareprodukte . . . . . . . . . . . . . 18710.1 Vorgehen und Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

10.1.1 Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19010.1.2 Vorgehen bei Windows-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19110.1.3 Vorgehen bei Windows-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19110.1.4 Vorgehen bei Linux-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

10.2 Methoden und Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19210.2.1 Agent-based-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19310.2.2 Agent-less-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19410.2.3 Installationsloses Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19510.2.4 Methodik der Erhebung von Softwaredaten . . . . . . . . . . . . . . . . . . . . . . . 196

10.2.4.1 Inventarisierung - Open-Source-Werkzeuge . . . . . . . . . . . . . . . 19710.2.4.2 Inventarisierung - Kommerzielle Werkzeuge . . . . . . . . . . . . . . 198

10.2.5 Scanumfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19910.3 Nutzbare Datenquellen zur Inventarisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20010.4 Die erhobenen Daten analysieren, auswerten und aufbereiten . . . . . . . . . . . . . 202

11 Kaufmännische Bestandsaufnahme der Vertrags- und Softwaredaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

11.1 Vertragsmanagement und der Nutzen für das Lizenzmanagement . . . . . . . . . . 21011.2 Erforderliche Daten und Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21111.3 Voraussetzungen schaffen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21311.4 Aufbau eines Lizenzinventars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21511.5 Die benötigten Daten und Informationen identifizieren . . . . . . . . . . . . . . . . . . . 217

11.5.1 Vertragsdaten identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21711.5.2 Bestelldaten identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21911.5.3 Vorgehen für die Vertrags- und Bestellrecherche . . . . . . . . . . . . . . . . . . 219

11.6 Die Lizenznachweise sammeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22011.7 Historisierung und Stichtag – warum ist das wichtig? . . . . . . . . . . . . . . . . . . . . 22411.8 Warum kann Ihnen Ihr Lieferant helfen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

12 Datenbereinigung und Konsolidierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 22712.1 Planung der kaufmännischen Datenbereinigung . . . . . . . . . . . . . . . . . . . . . . . . . 22812.2 Die kaufmännischen Daten bereinigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22812.3 Die Softwareprodukte eindeutig kennzeichnen . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Inhalt IX

12.4 Planung der technischen Datenbereinigung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23212.5 Die technischen Daten bereinigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23412.6 Die Daten für eine Initialbeladung vorbereiten . . . . . . . . . . . . . . . . . . . . . . . . . . 235

13 Klassifizierung von Software – Methoden aus der Praxis . . . . . . . . . . . . 23913.1 Warum ist eine Klassifizierung zu empfehlen? . . . . . . . . . . . . . . . . . . . . . . . . . . 23913.2 Warum Software klassifizieren? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24013.3 eCl@ss – ein Standard mit Zukunft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24313.4 Die Software strategisch einteilen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24613.5 Klassifizierung über Geräteklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24813.6 Die Softwarenutzung für Client-Klassen definieren . . . . . . . . . . . . . . . . . . . . . . . 25013.7 Die Software weiter einteilen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

13.7.1 Servicekategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25213.7.2 Supportstufen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25413.7.3 Aufwandskategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

13.8 Ein Klassifizierungsprojekt planen und initiieren . . . . . . . . . . . . . . . . . . . . . . . . 256

Teil V: Die Einführung eines Lizenzmanagement-Tools . . . . . . . . . . . . . . . . . . . 259

14 Lastenheft für das Lizenzmanagement-Tool . . . . . . . . . . . . . . . . . . . . . . . 26114.1 Lastenheft und Pflichtenheft – ein kurzer Überblick . . . . . . . . . . . . . . . . . . . . . . 262

14.1.1 Das Lastenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26214.1.2 Das Pflichtenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

14.2 Struktur und Aufbau eines Lastenhefts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26414.2.1 Beispiel eines Lastenhefts für ein Lizenzmanagement-Tool

(gekürzte Fassung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26514.2.2 Worauf Sie bei der Erstellung des Lastenhefts achten sollten . . . . . . . . 267

15 Das Lizenzmanagement-Tool evaluieren . . . . . . . . . . . . . . . . . . . . . . . . . . 27115.1 Vorbereitung der Ausschreibungsunterlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27215.2 Lizenzmanagement-Tool – zentrale Anforderungen formulieren . . . . . . . . . . . . 28115.3 Auswahl der Anbieter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28315.4 Die Angebote analysieren und bewerten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28415.5 Die Teststellung – der Proof of Concept (PoC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

16 Das Lizenzmanagement-Tool implementieren . . . . . . . . . . . . . . . . . . . . . 28916.1 Die Umsetzung und Implementierung – wer leistet was? . . . . . . . . . . . . . . . . . . 290

16.1.1 Voraussetzungen, die der Auftraggeber schaffen sollte . . . . . . . . . . . . . 29016.1.2 Voraussetzungen, die der Auftragnehmer schaffen sollte . . . . . . . . . . . . 292

16.2 Den Implementierungsplan erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29316.3 Die Testphase organisieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

16.3.1 Aufbau und Gliederung der Testvorschrift . . . . . . . . . . . . . . . . . . . . . . . . 296

X Inhalt

16.3.2 Beispiel einer Testbedarfsmeldung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29716.3.3 Testbericht erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29816.3.4 Rahmenbedingungen formulieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

16.4 Die Abnahmespezifikation definieren und erstellen . . . . . . . . . . . . . . . . . . . . . . 30016.5 Das Tool geht in Produktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

17 Lizenzreporting – Ermittlung der Lizenzdaten . . . . . . . . . . . . . . . . . . . . . 30317.1 Die wichtigsten Reports im Lizenzmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 30417.2 Der Compliance-Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30617.3 Das Erstellen eines Maßnahmen katalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30917.4 Permanente Steuerung und Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Teil VI: Die Optimierung des Lizenzmanagements . . . . . . . . . . . . . . . . . . . . . . . 313

18 Softwarenutzung – Lizenzen proaktiv managen . . . . . . . . . . . . . . . . . . . 31518.1 Identifizierung von nicht genutzten IT-Beständen . . . . . . . . . . . . . . . . . . . . . . . . 31618.2 Methoden und Ergebnisse aus der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31818.3 Ein Softwarenutzungsanalyse-Projekt durchführen . . . . . . . . . . . . . . . . . . . . . . 32418.4 Ergebnisbeispiele aus der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

19 Optimierung von Software produkten und -lizenzen durch Virtualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

19.1 Warum Software virtualisieren? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33019.2 Voraussetzungen schaffen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33119.3 Grundlagen der Softwarevirtualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33319.4 Konzepte der Virtualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33519.5 Auswirkungen der Software virtualisierung auf bisherige Prozesse . . . . . . . . . 336

Teil VII: Das produktive Lizenzmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

20 IT-Architektur und Lizenzmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 34120.1 Einige Gedanken zur IT-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34220.2 Voraussetzungen für die Einbindung des Lizenzmanagements schaffen . . . . . 34520.3 Verteilte IT-Landschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34720.4 Lizenzmanagement als Funktion der IT-Architektur . . . . . . . . . . . . . . . . . . . . . . 350

20.4.1 Lizenzkonformität Stufe 1 (aktiv) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35320.4.2 Lizenzkonformität Stufe 2 (proaktiv) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35520.4.3 Lizenzkonformität Stufe 3 (optimiert) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

20.5 Beispielszenarien von IT-Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35820.5.1 Szenario 1 IBM-Lizenzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35820.5.2 Szenario 2 Lizenzierung in einer Citrix-Umgebung . . . . . . . . . . . . . . . . 363

20.6 Lizenzierung von Microsoft Windows Server 2012 (R2) . . . . . . . . . . . . . . . . . . . 366

Inhalt XI

20.6.1 Lizenzberechnung für Windows Server 2012 Installationsszenarien . . 36920.6.2 Weitere Ressourcen zur Microsoft-Lizenzierung . . . . . . . . . . . . . . . . . . . 371

21 Lizenzmanagement in Server-Umgebungen . . . . . . . . . . . . . . . . . . . . . . . 37321.1 Lizenzierung von Server-Umgebungen – Vergangenheit und Gegenwart . . . . . 37421.2 Unterschiede im Lizenzmanagement von Client- und Server-Umgebungen . . . 376

21.2.1 Ermitteln des Lizenzbedarfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37621.2.2 Ermitteln des Lizenzbestands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

21.3 Lizenzrelevante Parameter für Server-Softwareprodukte . . . . . . . . . . . . . . . . . . 37721.3.1 Softwareprodukte finden und identifizieren . . . . . . . . . . . . . . . . . . . . . . . 37821.3.2 Hardwareparameter ermitteln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

21.4 Kontextinformationen der IT-Infrastruktur ermitteln . . . . . . . . . . . . . . . . . . . . . 37921.5 Dynamische Veränderung der Lizenzierungsparameter durch

Virtualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38221.6 Die Lizenzmodelle für Server-Software produkte der wichtigsten Hersteller . . 385

21.6.1 Microsoft: Server-Lizenzierung im Überblick . . . . . . . . . . . . . . . . . . . . . 38521.6.1.1 Microsoft: Was wird lizenziert? . . . . . . . . . . . . . . . . . . . . . . . . . 38721.6.1.2 Microsoft: neue Lizenzmodelle und Lizenzmetriken . . . . . . . . 389

21.6.2 Oracle: Server-Lizenzierung im Überblick . . . . . . . . . . . . . . . . . . . . . . . . 39221.6.2.1 Oracle: Was wird lizenziert? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39521.6.2.2 Oracle: zusätzliche Optionen und Funktionspacks . . . . . . . . . 39721.6.2.3 Oracle-Lizenzierung: Wo liegen mögliche Stolperfallen? . . . . 40121.6.2.4 Oracle-Lizenzierung: Named User Plus (NUP) . . . . . . . . . . . . . 402

21.6.3 IBM: Server-Lizenzierung im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . 40621.6.3.1 IBM: das PVU-Lizenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40721.6.3.2 Weitere Aspekte zur Virtualisierung im IBM-Umfeld . . . . . . . 41321.6.3.3 Maßnahmen und Optimierungsmöglichkeiten . . . . . . . . . . . . 415

21.7 Optimieren der Softwarelizenzkosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41921.8 Gibt es ein Werkzeug für ein Server-Lizenzmanagement? . . . . . . . . . . . . . . . . . 421

22 Lizenzmanagement in Cloud-Umgebungen . . . . . . . . . . . . . . . . . . . . . . . 42522.1 Voraussetzungen schaffen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

22.1.1 Entwicklungsstufen eines Lizenzmanagements . . . . . . . . . . . . . . . . . . . 42822.2 Was ist eigentlich eine Cloud? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

22.2.1 Die Cloud-Liefermodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43222.2.2 Die Cloud-Servicemodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

22.3 Ziele für die Anwendung von Cloud-Technologien . . . . . . . . . . . . . . . . . . . . . . . . 43822.4 Neue Komplexitäten durch die Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440

22.4.1 Kann die bisherige Software mit in die Cloud? . . . . . . . . . . . . . . . . . . . . 44322.4.2 Neue Anforderungen an das Lizenzmanagement . . . . . . . . . . . . . . . . . . 44422.4.3 Aussichten des Lizenzmanagements in Cloud-Umgebungen . . . . . . . . . 445

XII Inhalt

23 Operatives Lizenzmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44923.1 Strategisches vs. operatives Lizenzmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 45023.2 Aspekte und Komponenten des operativen Lizenzmanagements . . . . . . . . . . . 451

23.2.1 Administrative Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45223.2.2 Technische Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45323.2.3 Kaufmännische Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45423.2.4 Lizenzrechtliche Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

23.3 Die Schnittstellen des operativen Lizenzmanagements . . . . . . . . . . . . . . . . . . . . 45623.4 Weitere Rollen im operativen Lizenzmanagement . . . . . . . . . . . . . . . . . . . . . . . . 459

23.4.1 Lizenzverwalter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45923.4.2 Software-Katalogmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46023.4.3 Softwarewarenkorb-Verantwortlicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46123.4.4 Softwareverteiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46223.4.5 Zentraler Archivverantwortlicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46323.4.6 Materialstammdatenpfleger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464

23.5 Das Rollenbild des operativen Lizenzmanagers im Unternehmen . . . . . . . . . . . 465

24 Software-Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46724.1 Rechtswidrige Nutzung von Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46924.2 Software-Audit – Rechtliches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47224.3 Die Schwierigkeiten der Hersteller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47424.4 Was der Anwender wissen sollte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47524.5 Bestandteile einer Audit-Klausel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47724.6 Wie läuft ein Audit ab? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

24.6.1 Wie bereiten Sie sich vor? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48424.6.2 Was ist ein gültiger Lizenznachweis? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

24.7 Was kommt nach dem Audit? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

25 Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49125.1 Webseite zum Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49125.2 ISO/IEC 19770 Software Asset Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49125.3 Lizenzmanagement-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49425.4 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

Keine andere Technologie der Neuzeit hat uns alle wohl so nachhaltig geprägt wie die Erfin-dung des Computers. Seit Konrad Zuse den ersten programmgesteuerten und frei program-mierbaren Rechner 1938 vorstellte, sind 70 Jahre später Computer aus unserem täglichen Leben nicht mehr wegzudenken. Hauptbestandteil eines jeden Rechenknechts ist seine Soft-ware, ohne die bleibt er stumm. Im Gegensatz zur Hardware, die man anfassen und fühlen kann, ist Software eine „weiche Ware“ und nicht greifbar. Software kann nicht visualisiert werden. Der Betriebswirt nennt das auch ein „immaterielles Wirtschaftsgut“. Vielleicht ist auch das ein Grund, weshalb quasi jede Büroklammer inventarisiert wurde, aber das Software-Lizenzmanagement noch immer wenig Beachtung erfährt. Jedes Jahr werden von Unternehmen für die Bereitstellung von Software erhebliche Summen aufgewendet. Das immer schnelleren Veränderungszyklen ausgesetzte Computerzeitalter bringt uns rasant wachsende Technologien zur Herstellung immer größerer und leistungsfähigerer Compu-tersysteme und Speicherkapazitäten. Schon heute wird das Wissen im Internet alle drei Monate komplett erneuert und nimmt enorme Ausmaße an. Viele Privathaushalte verfügen bereits über mehrere Computer und sind an die weltweiten Datenautobahnen rund um die Uhr angebunden. Im Kleinen wie im Großen muss sich heute jeder mit dem Thema Software und Lizenzmanagement auseinandersetzen.Unternehmen sind oft über Jahre hinweg zu komplexen Gebilden herangewachsen und jedes ist anders. Die Schnelligkeit, mit der sich das Geschäft verändert, zwingt die IT, sich effektiver zu organisieren und die angebotenen Services permanent auf den Prüfstand zu stellen. Dabei bekommt gerade jetzt auch das lange vernachlässigte Wirtschaftsgut „Soft-ware“ einen immer größeren Stellenwert in der Gesamtbetrachtung der IT-Kosten. Schon lange sind, statistisch gesehen, die installierte Software (und die daran gekoppelten Ser-vices) der größte Kostenblock bei der Ausrüstung eines IT-Arbeitsplatzes. Die Unternehmen investieren durchschnittlich mehr als ein Drittel des vorhandenen IT-Budgets in den Kauf von Software und in Wartungsverträge. Es wird ein enormer Aufwand betrieben, um die mittlerweile fast vollständig von der IT abhängigen Geschäftsprozesse zu managen. Die ständige Verfügbarkeit von IT-Kapazitäten zu gewährleisten, gehört zu den erfolgskriti-schen Faktoren eines Unternehmens. Störungen können auch die Beziehungen zu Kunden und Geschäftspartnern beeinträchtigen. Fällt die IT aus, kommt es nicht selten zu recht-lichen und wirtschaftlichen Konsequenzen. Deswegen setzen die Unternehmen alles daran, ihre Softwaresysteme stabil und funktionstüchtig zu halten.

Vorwort

XIV Vorwort

Doch kaum ein Unternehmen hat einen ausreichenden Überblick über seine eingesetzte Software. Hier herrscht häufig Misswirtschaft. Ein schwerwiegender strategischer Fehler, denn wer die Lizenzthematik falsch einschätzt, muss finanzielle Einbußen befürchten.Gerade unter diesem Aspekt und auch aufgrund der derzeitigen wirtschaftlichen Situation in ganz Deutschland wird der Druck auf die IT-Verantwortlichen, Kosten zu senken, enorm steigen. Im Gegenzug werden die Softwarehersteller, bedingt durch fallende Umsätze und geringere Lizenzeinnahmen, sehr viel öfter bei Ihnen vor der Tür stehen und die Einhaltung der vereinbarten Nutzungsrechte aufs Penibelste überprüfen. Wenn Sie sich hier keinem Risiko aussetzen wollen, das vielleicht Ihr Unternehmen gefährden könnte, sollten Sie sich ausführlich mit den in diesem Buch beschriebenen Themen auseinandersetzen.Auf den nachfolgenden Seiten möchte ich Ihnen einen Überblick geben, mit welchen Metho-den und Lösungen Sie an das Thema „Software-Lizenzmanagement“ herangehen können. Das Buch soll Sie dabei unterstützen, einen eigenen Fahrplan für Ihre ersten Schritte als Lizenzmanager zu entwerfen. Verschaffen Sie sich einen genauen Überblick über Ihre IT-Infrastruktur, alle IT-Investitions- und Anlagegüter, und vermeiden Sie auf diese Weise unnötige Kosten. Gleichzeitig erhalten Sie Transparenz, Rechtssicherheit und erhöhen deut-lich die Qualität der IT-Services in Ihrem Unternehmen. So vorbereitet, können Sie Ihrem nächsten Softwareaudit gelassen entgegensehen.Besonders bedanken möchte ich mich auch bei Margarete Metzger vom Carl Hanser Verlag, die mir sehr kompetent und mit einer Engelsgeduld über die Hürden bei der Erstellung dieses Buchs hinweggeholfen hat.

Torsten Groll, 2009

■■ Vorwort zur 2. Auflage

Vor knapp drei Jahren erschien dieses Buch in der ersten Auflage und es hat sich seitdem in seinem Bereich zu einem Standardwerk etabliert. Eigentlich haben die meisten gedruckten Fachbücher für den IT-Bereich – was den jeweils aktuellen Informationsgehalt betrifft – nur eine eng begrenzte Lebensdauer. Zu schnell ist der Zyklus der sich verändernden Informa-tionen und Visionen. Gerade erst hat Microsoft das „Office365“ gestartet, das dem Anwen-der die Möglichkeit bietet, vollkommen losgelöst von einer lokalen Office-Installation seine Office-Dokumente, Termin- oder Kalenderdaten zu bearbeiten und jederzeit an jedem Ort verfügbar zu halten. Ob und in welchem Umfang sich der Hype „Cloud-Dienste“ durchsetzen wird, bleibt abzuwarten, denn die Fragen nach Datenschutz und Datensicherheit werden nicht verstummen. So manches Desaster in der jüngsten Zeit hat die Schwachstellen dieser neuen Technologie deutlich aufgezeigt. Sicherlich wird es also auch deshalb noch eine sehr lange Zeit die Aufgabenstellung geben, ein „klassisches“ Softwareasset- und Lizenzmanage-ment einzuführen und zu betreiben.Dass das Thema mehr denn je aktuell ist, zeigt das stetig größer werdende Interesse an diesem Thema. Die zweite, erweiterte Auflage enthält deshalb außer den schon bekannten und überarbeiteten Inhalten für den strategischen und konzeptionellen Part auch Themen

Vorwort zur 3. Auflage XV

zur IT-Architektur und Beschreibungen für den operativen Part im Umfeld eines Software-asset- und Lizenzmanagements. Nach wie vor gilt es, die eingesetzte Software und deren Nutzung zu überblicken und deren optimalen Einsatz zu steuern. Denn im Vordergrund ste-hen sowohl der möglichst wirtschaftliche Einsatz der Software als auch die Einhaltung der vereinbarten Nutzungsrechte gegenüber den Herstellern. Gelingen wird es nur demjenigen, der einen ausreichenden Überblick über seine aktiven Software- und Hardwareassets hat und diese permanent überwacht und kostenoptimal einsetzt.Auch für die Überarbeitung und Erstellung der 2. Auflage möchte ich mich bei den Mit-arbeitern des Hanser Verlags und besonders bei Margarete Metzger bedanken, die nicht müde wurde, mich immer wieder neu zu motivieren. Besonders bedanken möchte ich mich außerdem bei meinem Freund und Kollegen Alexander Reutter, der mich mit seinen lang-jährigen Erfahrungen als operativer Lizenzmanager bei der Erstellung der neuen Inhalte fachlich sehr gut beraten und unterstützt hat.

Torsten Groll, 2012

■■ Vorwort zur 3. Auflage

Im Vorwort zur 2. Auflage formulierte ich, dass abzuwarten bleibt, ob sich der neue Hype um das „Cloud Computing“ in der IT-Welt etablieren wird. Heute kann festgestellt werden, dass sich der Hype in einen dynamischen Prozess weiterentwickelt hat und damit auch den Status einer weiteren Schlüsseltechnologie in der zukünftigen Informationsarchitektur beansprucht. Im bisherigen Verwalten von Softwarelizenzen entstehen nun – aufgrund der neuen Komplexitäten – weitere Herausforderungen für das gemeinsame Management von klassischen Softwarelizenzen und Softwareprodukten in Cloud-Umgebungen. Aber nicht nur die Cloud-Technologien verlangen nach neuen Verfahrensweisen und Prozessen. Der Anspruch, immer und überall und von jedem Gerät unter jedem Betriebssystem auf die Geschäftsdaten zugreifen zu können, kann nur durch die weitere Einbindung von mobi-len Geräten wie Smartphones oder Tablets erfüllt werden. Diese müssen aber auch in die Unternehmensarchitektur integrierbar sein und sollen möglichst wenig Kosten erzeugen. Über Virtualisierungstechnologien kann die hierfür erforderliche Flexibilität gewährleistet werden, was aber auch bedeutet, dass auf das Softwareasset- und Lizenzmanagement eine weitere Komplexitätsstufe zukommen wird. Um diese Themen mit aufzugreifen, wurde die dritte Auflage überarbeitet und um jeweils ein neues Kapitel zum Thema Lizenzmanage-ment in Cloud- und Server-Umgebungen erweitert.Für die Überarbeitung und Erstellung der 3. Auflage möchte ich mich auch wieder bei den Mitarbeitern des Hanser Verlags und besonders bei Brigitte Bauer-Schiewek bedanken, die mir verständnisvoll und fachlich kompetent zur Seite stand. Besonderer Dank geht an mei-nen Freund und Kollegen Jörg Henschel, der mich bei der inhaltlichen Erstellung zum Kapi-tel „Lizenzmanagement in Server-Umgebungen“ unterstützt hat. Weiterhin möchte ich mich bei Germaine Kosch bedanken, die mir mit ihrer Masterarbeit zum „Status quo des Cloud Computings und Auswirkungen auf das Lizenzmanagement“ einen wissenschaftlichen Rah-

XVI Vorwort

men für das Kapitel „Lizenzmanagement in Cloud-Umgebungen“ geliefert hat. Weiterhin möchte ich mich bei Silke Gehrmann bedanken, die im Rahmen unserer gemeinsamen Pro-jektarbeit nicht müde wurde, mich bei meiner Aktualisierung der dritten Auflage immer wieder zu motivieren, und oft Verständnis dafür zeigte, wenn ich mal wieder bis spät in die Nacht am Buch gearbeitet hatte.Bedanken möchte ich mich auch bei allen Lesern, die mir durch den Erwerb des Buchs und die bisherigen vielen positiven Rückmeldungen aufzeigen, dass das Thema Softwareasset- und Lizenzmanagement in den Unternehmen weiterhin ein wichtiger Aspekt bleiben wird.

Torsten Groll, Herbst 2015

2.7 Das Lizenzmodell 41

GNU GPL (General Public License)14

Die GNU GPL gilt heute als eine der wichtigsten Lizenzen für freie Software. Das sogenannte GNU-Projekt15 entstand in den 1980er-Jahren am MIT (Massachusetts Institute of Techno-logy) und geht auf Richard Stallmann zurück. Ende der 1970er-, Anfang der 1980er-Jahre begannen immer mehr Firmen, ihre Software unter stark beschränkten Lizenzbedingungen zu veröffentlichen und den Quelltext unter Verschluss zu halten. Stallmann stellte diesem Modell der proprietären Software ein Modell von freier Software gegenüber. Das Akronym GNU wurde von Stallmann gewählt, da es am MIT üblich war, für sich ähnelnde Programme eine rekursive Abkürzung zu benutzen, die quasi auf sich selbst verweist. Ihm schwebte im ersten Schritt ein freies Betriebssystem in der Art von UNIX vor. GNU bedeutet also „GNU is not Unix“. Vom GNU-Projekt veröffentlichte Software wurde damals unter eigene Lizenz-bestimmungen gestellt, damit die von Stallmann gewünschte Freiheit für den Quellcode gewährleistet werden konnte. Als über das GNU-Projekt immer mehr Software veröffent-licht wurde, entschied sich Stallmann dazu, mit Hilfe von Jerry Cohen die GNU GPL (GNU General Public License) zu entwerfen. Jeder, der freie Software verändert und anpasst, kann zusätzliche „Lizenzen“ für den eigenen Code hinzufügen, aber keine Beschränkungen hin-sichtlich der bestehenden GPL aussprechen, außer, es betrifft etwa abweichende Haftungs- und Gewährleistungsregeln oder Beschränkung der Verwendung von Marken.Unter dem Dach der Free Software Foundation (FSF), die 1985 von Richard Stallmann gegründet wurde, werden alle juristischen, logistischen und finanziellen Aspekte rund um das GNU-Projekt und die GNU GPL gebündelt. Die zurzeit aktuelle Version der GPL ist die Version 3. Für alle Nutzer, die freie Software nur anwenden, aber nicht weiterentwickeln bzw. weitergeben, ist die Einhaltung der GNU GPL aber nicht von essenzieller Bedeutung.

Tipp:Die vollständige Fassung der GNU GPL können Sie auf den GNU-Webseiten nachlesen (http://www.gnu.org/licenses/licenses.html).

■■ 2.7■ Das Lizenzmodell

Um beim Aufbau des Lizenzinventars die kaufmännische (erworbene) Software der techni-schen (installierten) korrekt zuordnen zu können, müssen Sie für jede einzelne Software das anzuwendende Lizenzmodell kennen und in Bezug auf Ihre bestehende IT-Architektur verstanden haben. Die Wahl des richtigen Modells kann Ihnen später erhebliche Kosten ersparen, die Wahl des falschen aber auch unnötige Kosten erzeugen. Die meisten Soft-warehersteller tun alles, um die Nutzungsbestimmungen für ihr Produkt so auszuformulie-ren, dass der normale IT-Anwender seine liebe Mühe hat, dieses komplexe Geflecht zu ver-

14 Text in Teilen übernommen von Wikipedia.org15 Mehr über die Geschichte von Freier Software und GNU können Sie nachlesen auf www.gnu.org.

http://www.gnu.org/licenses/licenses.html

http://www.gnu.org

42 2 Eine Softwarelizenz – was ist das?

stehen, und im Zeitalter der immer weiter voranschreitenden Virtualisierung kommt diese Komplexität noch obendrein dazu.Ein Lizenzmodell setzt sich u. a. aus der Lizenzklasse, einem Lizenztyp und der Lizenz-metrik zusammen. Die Wahl des Lizenzmodells sollte sich deshalb an den individuellen Bedürfnissen und Gegebenheiten Ihres Unternehmens und des geplanten Softwareeinsat-zes sowie an Ihrer bestehenden IT-Architektur orientieren. Die Kombinationsmöglichkeiten sind mittlerweile so vielfältig, dass sich viele Berater nur noch auf ein oder zwei Soft-warehersteller spezialisiert haben, um ihre Kunden bei der Wahl des richtigen Lizenz-modells unterstützen zu können. Die häufigsten Spezialisierungen im Lizenzumfeld finden sich dabei für Microsoft-, Oracle- und SAP-Produkte.Lizenzmodelle beeinflussen die rechtmäßige Softwarenutzung durch folgende Faktoren:

� durch die Lizenzart (z. B. Einzellizenz, Mehrplatzlizenz); � durch die Lizenzklasse (z. B. Vollversion, Upgrade-Version); � durch den Lizenztyp (z. B. pro Gerät, pro gedruckte Seite); � durch die Lizenzmetrik, mit der festgelegt wird, wie gezählt wird (z. B. gilt die Lizenz für 5000 gedruckte Seiten pro Monat oder für 1000 zu verwaltende Systeme);

� durch die Lizenzbindungen bzw. Lizenzbeschränkungen (z. B. Einsatz auf einem Gerät mit maximal zwei CPU-Kernen oder auf einer bestimmten Hardwareumgebung, wie bspw. Hot- oder Could-Stand by, Backup);

� durch das Beschreiben von Weitergabeverboten (beispielsweise das einer OEM-Lizenz) sowie von Veräußerungs- und Vermietverboten;

� durch das Beschreiben bzw. Bestimmen von Laufzeiten der Softwarenutzung (begrenzt, unbegrenzt).

Tipp:Überprüfen Sie in regelmäßigen Abständen, ob das ausgewählte Lizenzmodell noch Ihren Anforderungen und Gegebenheiten (sprich Ihrer aktuellen IT-Architek-tur) entspricht oder einer Anpassung bedarf.

Beispielsweise folgt das Lizenzmodell von Microsoft für Desktop-Anwendungen dem Grund-satz, dass eine Lizenz einem bestimmten Gerät zugewiesen wird und dazu berechtigt, die Software auf dem Gerät zu „verwenden“. Aber auch viele andere Softwarehersteller folgen dieser Definition.Um das zu verstehen, gilt es zwei Aspekte näher zu betrachten:

� Wie wird „Gerät definiert?Ein Gerät kann ein Computer, eine Arbeitsstation, ein Terminal, PDA oder ein anderes elektronisches Gerät sein.

� Wie wird laut Lizenzvertrag „verwenden“ beschrieben? � Kopieren; � Installieren (z. B. auf einer Festplatte oder einer Speicherkarte, USB-Medium); � Nutzung der Software;


� Zugriff über eine Netzwerk- oder eine Peer-to-Peer-Verbindung (von Computer zu Com-puter);

� Anzeigen (z. B. über Fernwartungsservices); � Laufen lassen (ohne ständige Interaktion des Endanwenders, beispielsweise, ist der Webbrowser permanent geöffnet) oder

� eine wie auch immer geartete Interaktion mit dem Softwareprodukt.Wenden wir uns dem ersten der vier wichtigsten Faktoren zu, der Lizenzart.

2.7.1■ Die Lizenzart

Die erste Stufe eines Lizenzmodells wird durch die Lizenzart beschrieben. Hiervon gibt es genau zwei:

Die EinzelplatzlizenzWie es der Name zum Ausdruck bringt, erlaubt es diese Lizenzart, die erworbene Software auf nur einem System zu installieren und anzuwenden. Für jede weitere Installation werden zusätzliche Lizenzen (Lizenzkeys) benötigt. In der Regel sind meistens alle im Einzelhandel zu findenden Box-Produkte (FPPs) Einzelplatzlizenzen sowie, darüber hinaus, Download-Versionen, beispielsweise aus der Kategorie Freeware, Shareware.

Die MehrplatzlizenzBei der Mehrplatzlizenz erlaubt der Urheber dem Endanwender, die erworbene Software mehrmals bis zu einer festgelegten Anzahl unter Verwendung eines einzigen Lizenzschlüs-sels auf verschiedene Systeme zu installieren. Diese Lizenzform wird am häufigsten ein-gesetzt, wenn eine große Stückzahl der Software zum Einsatz kommen soll. Hier hatte ich bereits erwähnt, dass es ab einer bestimmten Menge für ein Unternehmen wirtschaftlich nicht mehr sinnvoll ist, lauter Einzelplatzlizenzen (Box-Produkte) zu kaufen, weil der ent-sprechende Verwaltungsaufwand einfach zu groß ist. In diesen Volumenverträgen gibt es beispielsweise einen sogenannten Volume-Licensekey, der für alle getätigten oder noch zu tätigenden Installationen als gültiger Lizenzkey verwendet werden darf.Beim Aufbau eines Lizenzinventars (kaufmännische Daten) ist es wichtig zu wissen, ob die aufzunehmende Software laut Lizenzvertrag eine Einzelplatz- (FPP oder Box-Produkt) oder Mehrplatzlizenz darstellt. Davon abhängig ist der Lizenzmetrikwert, der wiederum für den Abgleich mit den technischen (Inventory-) Daten wichtig ist, also ob die gefundene Software-installation 1:1 oder n:1 gezählt werden darf.

2.7.2■ Die Lizenzklasse

Im Lizenzvertrag, dem Sie zustimmen müssen, werden die Nutzungsrechte für die erwor-bene Software abgebildet. Zusätzlich werden an die rechtskonforme Nutzung der Software bestimmte Voraussetzungen geknüpft, die u. a. durch eine verfügbare Lizenzklasse beschrie-


ben wird. Des Weiteren nutzt Ihnen die Einteilung der Softwareprodukte in Lizenzklassen, um beispielsweise später Fragen beantworten zu können, von welchem Softwareprodukt wie viele Vollversionen bzw. Upgrades im Einsatz sind. Tabelle 2.2 erläutert die gebräuch-lichsten Lizenzklassen, erhebt aber keinen Anspruch auf Vollständigkeit.

Tabelle 2.2■Lizenzklassen

Lizenzklasse BeschreibungVollversion Beschreibt, dass keine vorhergehende Version für den rechtskonformen Einsatz

vorausgesetzt wird und die beschriebenen Funktionen keinen Beschränkungen unterliegen (außer eventuell zeitliche oder funktionelle Beschränkungen, beispielsweise bei Test- oder Temporärversionen).

Upgrade Beschreibt einen Wechsel zu einer höheren Version (z. B. von 2.5 auf 3.0), setzt eine Vollversion des gleichen Softwareprodukts und der gleichen Sprache voraus, um bestimmte Funktionen weiter ausführen zu können oder aber um den lizenzkonformen Nachweis zu führen. Ein Upgrade-Produkt ist immer kostenpflichtig. Um lizenzkonform zu sein, muss der „Upgrade-Pfad“ lückenlos nachweisbar sein.

Cross-Upgrade Beschreibt ein Softwareprodukt, das als Voraussetzung für die rechtskonforme Verwendung ein ähnliches Produkt eines anderen Herstellers fordert, an sich aber eine Vollversion darstellt und immer kostenpflichtig ist (meist aber zu einem sehr günstigen Preis, um beispielsweise das Konkurrenzprodukt aus dem Markt zu drängen).

Update Beschreibt einen kleinen Wechsel innerhalb einer Version (z. B. 2.5 auf 2.6) und geht einher mit der Behebung von Fehlern; wird häufig auch als „Hotfix“, „ Aktualisierung“, „Sicherheitsrelease“ oder „Patch“ bezeichnet und oft im Rahmen eines Wartungsvertrags mit angeboten.

AddOn Beschreibt eine zusätzliche Komponente zu einer Software, die auch lizenz- und kostenpflichtig sein kann.

AddOn-Upgrade Beschreibt eine zusätzliche Komponente zu einer Software, die auch lizenz- und kostenpflichtig sein kann, in der Form eines Upgrades.

CAL (Client Access License)

Sonderform: Wenn ein Gerät oder Nutzer auf einen Server zugreift und dessen Dienste verwendet (als Lizenztyp eine Geräte- oder Nutzer-CAL). CALs sind immer kostenpflichtig.

CAL-Upgrade Client Access License

Sonderform als Upgrade: Wenn ein Gerät oder Nutzer auf einen Server zugreift und dessen Dienste verwendet (als Lizenztyp eine Geräte- oder Nutzer-CAL). CALs sind immer kostenpflichtig.

Die Einteilung der Software in Lizenzklassen zum Zweck der Klassifizierung ist für alle Lizenzformen (Freeware, Shareware, proprietäre Software, Open Source etc.) gleich.

Hinweis:CALs lassen sich kaum automatisiert zählen und müssen deswegen manuell verwaltet werden (es findet keine Interaktion mit irgendeiner Software statt). In kleinen und mittelständischen Unternehmen wird diesem Umstand nicht immer genügend Aufmerksamkeit geschenkt, weshalb es leicht zu einer Unter-


lizenzierung kommen kann. Insbesondere Microsoft – aber auch andere Soft-warehersteller – schauen gerade aus diesem Grund bei einem anstehenden Software-Audit auf die korrekte Lizenzierung der CAL-Lizenzen.

2.7.3■ Der Lizenztyp

Der dritte wichtige Faktor, um ein Lizenzmodell zu beschreiben, ist der Lizenztyp. Er formu-liert einen Bestandteil der im Lizenzvertrag einzuhaltenden rechtskonformen Verwendung der Software. Beispielsweise, dass die Software mit dem Lizenztyp „Pro Gerät“ nur auf einem Computer mit maximal zwei CPU-Kernen installiert werden darf, welches in diesem Fall gleich die anzuwendende Lizenzmetrik (wie wird gezählt) mit definiert. Die am häufigs-ten anzutreffenden Lizenzmodelle werden in Tabelle 2.3 kurz erläutert.

Tabelle 2.3■Die gebräuchlichsten Lizenztypen

Lizenztyp BeschreibungPro Gerät Erlaubt die Nutzung der Lizenz pro Gerät; auch Pro Device genannt.Pro Nutzer Erlaubt die Nutzung der Lizenz pro Nutzer; auch Pro User genannt.Pro CPU Erlaubt die Nutzung pro CPU. Dieser Lizenztyp wird meistens im Umfeld von Software

für Server- und Großrechnersysteme angewendet. Die Lizenzmetrik bestimmt dann, auf wie vielen CPUs die Lizenz gleichzeitig genutzt werden darf. Im Desktop umfeld werden in den allermeisten Fällen von den Softwareherstellern Systeme mit zwei CPUs (eine CPU mit zwei Kernen oder auch zwei physische CPUs) wie ein System mit nur einer CPU behandelt, so dass dafür keine zusätzlichen Lizenzen erforderlich sind.

Die hier aufgeführten Lizenztypen bilden in Verbindung mit den in Tabelle 2.4 genannten Lizenzmetriken und deren möglichen Kombinationen die meisten von den Herstellern for-mulierten Nutzungsbedingungen ab. Der am einfachsten vollautomatisiert zu verwaltende und am häufigsten verwendete Lizenztyp für Anwendungssoftware ist „Pro Gerät“. Durch das Auslesen von Berechtigungsstrukturen, beispielsweise aus dem „Active Directory“, können auch die „Pro Nutzer“-Lizenzen in einem Lizenzmanagement-Tool halb- oder voll-automatisiert verwaltet werden. Es gibt derzeit noch keine festgelegten und standardisier-ten Begriffe, so dass jeder Softwarehersteller mitunter etwas anderes meint, wenn er den Begriff „Lizenztyp“ verwendet.

2.7.4■ Die Lizenzmetrik

Für den Aufbau eines Lizenzinventars sind nun schon die Faktoren beschrieben worden, über die Sie Ihre Softwarelizenzen klassifizieren können (Lizenzart, Lizenzklasse, Lizenz-typ). Damit das anzuwendende Lizenzmodell auch korrekt auf Ihre technische Situation abgebildet werden kann (die installierte Anzahl der einzelnen Softwareprodukte), benöti-gen Sie noch die Beschreibung und den erlaubten „Wert“, wie ein Softwareprodukt laut Lizenzvertrag „genutzt“ werden darf. Dieser Faktor ist die „Lizenzmetrik“. Um beispiels-


weise einen Überblick zu bekommen, ob die Anzahl der gekauften Software mit der tat-sächlich installierten (Compliance-Report) übereinstimmt, müssen Sie wissen, wie die Soft-wareprodukte anhand des bestimmenden Lizenzmodells zu zählen sind und ob diese Zählweise auch zu Ihrer IT-Architektur passt. Die Lizenzmetrik beschreibt den anzuwen-denden Faktor und die Maßeinheit (Seitenanzahl, Volumengebunden, MIPS 16 u. a.). Es gibt viele Varianten, wie eine Softwarelizenz „gezählt“ wird. Die Zählweise kann außerdem an besondere Vertragsformen gekoppelt sein.Als Beispiel sei das Zweitkopie - oder auch „Work-at-home“ -Recht genannt. Das Zweit kopie-Recht darf nur dann ausgeübt werden, wenn es in den Produktnutzungsrechten bzw. dem EULA (FPPs) enthalten ist. Wird beispielsweise Software von Microsoft über einen Volu-menlizenzvertrag erworben, beinhaltet das immer das Zweitkopie-Recht für alle Desktop-Anwendungen.17 Das Zweitkopie-Recht gilt ausschließlich für tragbare Geräte und in kei-nem Fall für Betriebssysteme oder Server-Produkte. Dies bedeutet: Wenn Sie Office 2010 auf Ihrem Desktopsystem installieren und verwenden, haben Sie das Recht, eine Kopie der-selben Software (hier Office 2010) auf einem weiteren, dem Hauptnutzer des Desktopsys-tems zugeordneten tragbaren Gerät (meist Laptop) zu installieren und zu nutzen. Diese Lizenzen bei einem Compliance-Report auseinanderzuhalten und korrekt zu zählen (mit den Inventory-Daten abzugleichen), ist die kleine Königsdisziplin eines guten Lizenz-management-Tools.

Hinweis:In der Regel finden Sie die Erlaubnis für ein Zweitkopie-Recht nur in bestimm-ten Volumenverträgen der Softwarehersteller. Die im Einzelhandel erhältlichen Produkte (z. B. FPPs) beinhalten dieses Recht nicht. Wenn ein FPP mehrmals installiert wird und es keinen ausdrücklichen Hinweis darauf gibt, dass die Software mehr als einmal auf unterschiedlichen Systemen installiert werden darf (Stichwort: Mehrplatzlizenz), wird „unlizenzierte Software“ verwendet.

Lizenzmetriken unterliegen keinen allgemeingültigen Begriffsdefinitionen oder Merkma-len. Hier formuliert jeder Softwarehersteller seine eigene Lizenzmetrik bzw. ändert u. U. auch einmal die Abrechnungsmethode. Als Beispiel sei hier IBM genannt, die damals zum November 2006 ihr Abrechnungsmodell für IBM Middleware geändert haben. Software, die bislang nach Prozessoren abgerechnet wurde, wird jetzt nach PVUs (Processor Value Units) berechnet. Dabei entspricht ein bisheriger Prozessorkern 100 PVUs.Microsoft hat beispielsweise gegenüber IBM und Oracle erst sehr spät auf die geänderten IT-Architekturen mit einem neuen Lizenzmodell reagiert und beispielsweise bei der Ein-führung des SQL Server 2012, z. B. mit der Enterprise Server Version, die Lizenzmetrik „pro Prozessor“ in „pro Kerne“ umgewandelt. Die erforderliche Umstellung des Lizenzmodells hatte später nicht unerhebliche Auswirkungen auf bestehende IT-Architekturen und die Sicherstellung des lizenzkonformen Betriebs. Damit Sie hier nicht vor eventuellen Über-

16 MIPS = Million Instructions per Seconds, Maßeinheit für die Leistungsfähigkeit eines Rechenkerns (CPU), wird meistens nur noch bei Großrechnern angegeben und dient auch zur Berechnung von Lizenzgebühren.

17 Desktop-Anwendungen von Microsoft sind u. a. Office, Project, Visio, Outlook, InfoPath, OneNote.


raschungen stehen, ist es sehr wichtig, beim Aufbau des Lizenzinventars die Lizenzmetrik zum jeweiligen Lizenzmodell mit abzubilden.Tabelle 2.4 beschreibt eine Auswahl häufig angewendeter Lizenzmetriken. Die Auswahl erhebt keinen Anspruch auf Vollständigkeit, da laufend neue Lizenzmetriken hinzukom-men können bzw. vom Hersteller geändert werden.

Tabelle 2.4■Häufig verwendete Lizenzmetriken und Maßeinheiten

Lizenzmetrik Faktor Maßeinheit BeschreibungPro Gerät (Pro Device)

1 bis n Gerät ( Device)

Lizenz pro Gerät, gezählt wird eine Lizenz pro Ins-tallation der Software auf einem System/Gerät/PC, meistens eine 1:1-Abbildung mit dem Lizenz-typ „Pro Gerät“. Ausnahmen gibt es aber auch hier, beispielsweise bei Anti-Virensoftware oder bei der „Microsoft Office Home and Student 2007 Edi-tion“, die ausschließlich für den privaten Gebrauch oder für die Nutzung im Studium verwendet wer-den darf. Diese seit Anfang 2007 in Deutschland käufliche, spezielle Lizenzversion darf auf drei Rechnern installiert werden. Als Sonderform zum Lizenztyp „Pro Gerät“ sei noch das „Zweitkopie-Recht“ von Microsoft genannt (siehe weiter oben).

Per Node 1 bis n Node Node-Lizenzen sind an ein bestimmtes System gebunden und erlauben meistens die Nutzung der Software nur auf diesem System (Desktop-, Ser-ver- oder Netzwerksysteme). Der anzuwendende Lizenztyp ist hierbei Pro Gerät. Die „Per Node“-Li-zenzierung ist häufig bei Software zur Verwaltung von Netzwerkumgebungen anzutreffen.

Pro Nutzer (Pro User)

1 bis n Nutzer (User)

Lizenz pro Nutzer, gezählt wird pro Nutzer, meis-tens eine 1 : 1-Abbildung mit dem Lizenztyp „Pro Nutzer“. Oft gibt es aber auch Mengenangaben, wie z. B., dass die Softwarelizenz gültig für 250 Nutzer ist.

Named User (auch Current oder Authorized User genannt)


Die Named User-Lizenzmetrik wird in Kombination mit dem Lizenztyp „pro Nutzer“ angewendet. Der Endanwender für diese Lizenzmetrik muss nament-lich benannt werden, nur er darf dann die Lizenz nutzen (wird z. B. bei Entwicklungslizenzen von Software angewendet).

Floating License (auch Concurrent Use genannt)


Erlaubt die Nutzung der Software auf unterschied-lichen bzw. beliebig vielen Systemen. Dabei ver-waltet ein dafür einzurichtender Lizenzserver die Anzahl der gekauften Lizenzen. Jeder Nutzungs-aufruf der Software verringert die Anzahl der ver-fügbaren Lizenzen um 1. Die Floating License kann sowohl mit dem „Pro Gerät“ als auch mit dem „Pro Nutzer“-Lizenztyp verknüpft werden.


Lizenzmetrik Faktor Maßeinheit BeschreibungPro Seite 1 bis n Seite Lizenzkosten werden aus der Anzahl der gedruck-

ten Seiten ermittelt (beispielsweise beruht die erlaubte Softwarenutzung auf fixen Werten wie z. B. 5000 Seiten/Monat etc.). Dazu kann noch eine Zeitkomponente hinzukommen, wie beispiels-weise Stunde, Woche, Monat u. a.). Der hierfür zu verwendende Lizenztyp wäre Pro Gerät (Drucker oder Scanner).

Pro CI 1 bis n CI Basis ist die Anzahl der zu verwaltenden CIs in einer Datenbank; wird oft bei der Lizenzierung von Asset-Management-Tools verwendet. (CI = Configuration Item, Begriff aus ITIL®)

Pro Session 1 bis n Session Basis ist die erlaubte Anzahl aufgebauter Verbin-dungen (beispielsweise zu einer Online-Datenbank oder einem Recherchedienst). Hinzu kann noch eine Zeitkomponente kommen, wie beispielsweise Stunde, Woche, Monat u. a.).

Pro CPU 1 bis n CPU logisch CPU phy-sisch

Basis für die Lizenz sind die Anzahl der installierten und genutzten CPUs (gezählt wird pro CPU). Beispielsweise muss bei einer Prozessorlizenz für Oracle-Softwareprodukte die Anzahl der CPU-Ker-ne (physisch) mit einem Faktor zw. 0,25 und 0,75 multipliziert werden (abhängig von der Hard-wareumgebung), um die korrekte Anzahl an zu lizenzierenden Prozessorlizenzen zu errechnen.

Pro MIPS 1 bis n MIPS Basis sind MIPS (Million Instructions per Seconds); die Maßeinheit für Leistungsfähigkeit eines Rechen kerns (CPU) wird meistens nur noch bei Großrechnern angegeben und dient zur Berech-nung von Lizenzgebühren).

Pro MSU 1 bis n MSU oder MIPS

Basis sind MSU (Million of Service Units), eine MSU entspricht 6 MIPS; weitere Beschreibung siehe MIPS.

Pro PVU (Processor Value Unit)

1/100 100 PVU 1 bisheriger Prozessor entspricht 100 PVUs, 1 PVU kostet 1/100 des bisherigen Prozessorprei-ses. Ein Single-Core-Prozessor wird mit 100 PVUs berechnet. Siehe auch den Auszug aus der aktuel-len IBM-PVU-Tabelle in Kapitel 21 (Bild 21.2).

Pro Transaktion 1 bis n Transaktion Basis ist die erlaubte Anzahl von Transaktionen mit den vereinbarten Wertemengen. Hinzu kann eine Zeitkomponente kommen, wie beispielsweise Stunde, Woche, Monat u. a.

Tabelle 2.4■Häufig verwendete Lizenzmetriken und Maßeinheiten (Fortsetzung)


Lizenzmetrik Faktor Maßeinheit BeschreibungVolumen- gebunden

1 bis n z.B. Terabyte Gigabyte Megabyte Stück

Basis ist das verfügbare Volumen mit den verein-barten Wertemengen; beispielsweise darf die Soft-warelizenz so lange genutzt werden, bis 5 GB an Datenvolumen erreicht ist. Das eben genannte Beispiel ist eines von vielen Möglichkeiten, eine Lizenz volumengebunden zu verwenden.

Standort- gebunden (bzw. per Site)

1 bis n z.B. pro Land pro Nieder-lassung pro Org.- Einheit

Standortgebundene Lizenzformen sind meistens gleichzeitig Unternehmens- bzw. Konzernlizenzen. Häufig anzutreffen beim Einsatz im Umfeld von Serversoftware und Rechenzentren.

Zeit-gebunden 1 bis n z.B.: pro Minute pro Stunde pro Woche pro Monat pro Jahr

Eine zeitgebundene Lizenzmetrik wird vor allem bei Software verwendet, die z. B. für Testzwecke ein-gesetzt oder aber nur für eine bestimmte Abrech-nungsperiode verwendet wird (z. B. beim Erstellen von Jahresendabrechnungen etc.).

Hinweis:Wird ein unbegrenzter Wert vereinbart, spricht man auch von einer Konzern- oder Unternehmenslizenz. Diese wird dann häufig mit dem Lizenztyp „Pro Gerät“ oder „Pro Nutzer“ gekoppelt, ist um ein Vielfaches teurer, erleichtert Ihnen aber die Arbeit und es besteht keine Gefahr der Unterlizenzierung.

Lizenzmodelle und Metriken können für ein und dieselbe Software unterschiedlich ausfal-len, da die Softwarehersteller auf möglichst viele unterschiedliche Kundenanforderungen reagieren und eingehen wollen. Die Kehrseite der Medaille sind die immer komplexeren und teilweise schwer nachvollziehbaren Lizenzmodelle und Lizenzmetriken. Das richtige Lizenzmodell für das eigene Unternehmen beispielsweise bei SAP oder Oracle zu finden, ist schon zu einer sportlichen Aufgabe geworden. Das sind aber nur Aspekte, die den Einkauf interessieren. Der Lizenzmanager muss sich an die tatsächlich vereinbarten Lizenzmetri-ken halten, um einen rechtskonformen Lizenzabgleich durchführen zu können. Zu prüfen sind in jedem Einzelfall die Lizenzmodelle und Lizenzmetriken, wenn der Einsatz der Soft-ware in virtuellen Umgebungen vorgesehen ist. Diese Variationen sind nicht so ohne weite-res automatisierbar.

Hinweis:Es ist wie mit der Verpflichtung zur geforderten Verfügbarkeit Ihrer IT-Systeme. Denken Sie bitte daran, welchen Nutzen Sie mit welchem Aufwand erzeugen wollen, und wägen Sie das sorgsam gegeneinander ab. Was ist unter Umständen kostengünstiger? Eine Softwarelizenz nachzukaufen, ein bis zwei Mitarbeiter zu


beschäftigen, die eventuell aufwendig im Archiv recherchieren müssen, ob eine Vollversion für das Upgrade-Produkt irgendwo rumschwirrt, oder vielleicht doch das Softwareprodukt zu deinstallieren, weil der Mitarbeiter die Software eigent-lich nicht wirklich braucht.

Es ist sehr aufwendig, für alle auf dem Markt anzutreffenden Lizenzmodelle und Lizenz-metrikarten eine Compliance herzustellen. Deshalb konzentrieren sich die meisten Lizenz-managementprojekte zunächst auf die Abbildung der Lizenzmodelle „Pro Gerät“ und „Pro Nutzer“ bzw. heute (2015) auf die immer mehr zu administrierenden virtuellen Maschinen und Desktopsysteme, die auch einem Gerät oder einem Benutzer zugewiesen werden. Des Weiteren muss auch immer mehr die Abbildung der Lizenzmodelle „pro Prozessor“, „pro Kern“ und „pro CPU“ in den Fokus gerückt werden, da die IT-Architektur mit physikali-schen und virtuellen Servern immer mehr aus Kostengründen und aufgrund der Maßgabe zur Einhaltung eines lizenzkonformen Betriebs der Rechenzentren Rechnung tragen muss. Es ist auch bei weitem kein großes Geheimnis mehr, dass im Server- und Rechenzentrums-betrieb mittlerweile viel größere Einsparpotenziale zu finden sind.Die Feststellung der im Unternehmen angewendeten Lizenzmodelle und deren Lizenzmetri-ken sind also ein erster Schritt auf dem Weg zu einer rechtmäßigen Lizenz-Compliance und zur Einhaltung der rechtlichen Bestimmungen.

■■ 2.8■ Rechtliche Bestimmungen zur Softwarenutzung in Deutschland

Die Entwicklung des deutschen Urheberrechts wird seit Anfang der neunziger Jahre erheb-lich durch die europäische Gesetzgebung beeinflusst. Die EU kann für die Regelungen auf dem Gebiet des Immaterialgüterrechts (zum Beispiel des Urheber-, Patent-, Marken- und Geschmacksmusterrechts) Vorgaben in Form von EU-Richtlinien erteilen. Innerhalb einer bestimmten Frist müssen diese Richtlinien in nationales Recht überführt werden. Seit 1991 wurden einige Harmonisierungsrichtlinien verabschiedet, die u. a. zum Inhalt haben, das Urheberrecht in den einzelnen Mitgliedsstaaten anzugleichen und Unterschiede in den Rechtsordnungen zu verringern oder aufzuheben. Vereinheitlicht wurde in diesem Zuge zum Beispiel auch das (Urheber-)Recht an Computerprogrammen. Ein Europäisches Urhe-berrechtsgesetzbuch wird man vergeblich suchen. Nach wie vor wird das Urheberrecht durch die Gesetze der einzelnen Mitgliedsstaaten geregelt. Die EU verpflichtet die nationa-len Gesetzgeber lediglich dazu, ihre jeweiligen Gesetze an die Vorgaben der EU-Richtlinien anzupassen. Ausgehend von einer EU-Richtlinie vom Mai 1991, wurde das Urheberrecht zum Schutz von Computerprogrammen auch im deutschen Recht verankert. Computerpro-gramme sind seit Juni 1993 umfassend urheberrechtlich geschützt. Auf dieser Basis zählt Software heute zu den geschützten geistigen Gütern wie Literatur, Wissenschaft und Kunst. Allein der Urheber (Hersteller) hat das Recht zum Vervielfältigen, Übersetzen, Verbreiten, Vermieten oder Verändern eines Produkts, Dritte dürfen dies nur mit ausdrücklicher

6In diesem Kapitel erfahren Sie u. a.: � wie man an die Aufnahme der Ist-Situation herangeht, � wie sich die Ist-Situation mit Werkzeugen wie Word, Excel, PowerPoint & Co ausreichend dokumentieren lässt.

In diesem Kapitel lesen Sie etwas über die grundlegenden Voraussetzungen, die Sie für die erforderliche Aufnahme der Ist-Situation in Ihrem Lizenz-management umfeld schaffen sollten. Um einen ersten Überblick zu erhalten, sollten Sie die erarbeiteten Ergebnisse mit Hilfe entsprechender Werkzeuge dokumentieren. Diese Informationen können Sie dann für die Gestaltung und Optimierung der neuen Soll-Prozesse einsetzen.

In Kapitel 5 „Den Projektplan aufstellen“ haben wir uns mit den theoretischen Vorberei-tungen für die Planung eines Lizenzmanagementprojekts auseinandergesetzt. Projektziele wurden definiert, der Projektscope wurde festgelegt, der Projektplan mit Phasen, Meilen-steinen und Aufgaben wurde erstellt, das war Phase 1.Phase 2 „Aufnahme der Ist-Situation“ ist nun der logische nächste Schritt. In diesem Kapitel wird bewusst nur auf die allgemeinen Faktoren eingegangen, da in Kapitel 7 der Software-Life-Cycle-Prozess detaillierter abgebildet und beschrieben wird, den Sie als Fahrplan für die Aufnahme und Abbildung Ihrer Ist-Situation verwenden sollten. Darauf aufbauend kön-nen Sie dann mit einer anschließenden Reifegradanalyse die Ist-Prozesse bewerten und so feststellen, wo gegebenenfalls Optimierungspotenzial liegt.

■■ 6.1■ Aufnahme der Ist-Situation – wo beginnen?

Verdeutlichen Sie sich noch einmal kurz Ihre Ausgangssituation. In vielen Fällen sind die bestehenden Rechtsunsicherheiten aufgrund fehlender gesamtheitlicher Prozesse im Lizenzmanagementumfeld der wichtigste Grund für den Start eines Lizenzmanagementpro-

Erste Schritte zur Analyse und Dokumentation der Ist-Situation

110 6 Erste Schritte zur Analyse und Dokumentation der Ist-Situation

jekts, dicht gefolgt von dem Ziel, Kostentransparenz und Kosteneinsparung herzustellen. Die Ausgangssituation entspricht also meist der Stufe 1, wie sie in Bild 6.1 beschrieben ist.

Kost

en

Zeit

Ist-Situation

Lizenzmanagementimplementieren

Soll-Situation

Proj

ekts

tart

Proj

ekte

nde

Kontrolle der Beständeunvollständig

Lizenzmanagementist eingeführt:� Transparenz vorhanden� Rechtssicherheit entsteht� Kosten sinken

Lizenzmanagementnicht vorhanden: � keine Transparenz� keine Rechtssicherheit� hohe Kosten

Optimierungbeginnt

− Verträge analysieren− Bestände kontrollieren− Rechtssicherheit herstellen

+

Stufe 2Stufe 1 Stufe 3

+ =

− Reifegrad analysieren− Soll-Prozesse erstellen− LiMa-Tool auswählen

+ =

Bild 6.1■Stufe 1 als mögliche Ist-Situation im Lizenzmanagementumfeld eines Unternehmens

Auf dieser Stufe gibt es keine Kontrolle über die Softwarebestände. Bevor Sie sich also Gedanken machen können, wie es besser gemacht werden sollte, benötigen Sie Informatio-nen über das Hier und Jetzt. Sie müssen die Ist-Situation aufnehmen.Sicherlich könnte man auch die Aufnahme der Ist-Situation überspringen und die erforder-lichen Soll-Prozesse gleich neu gestalten und formulieren. Das mag zwar verlockend sein, lässt sich aber nur dann umsetzen, wenn Sie mit dem Aufbau von optimierten Geschäfts-prozessen auf der grünen Wiese beginnen können. Und das ist in den seltensten Fällen möglich. Die Realität sieht leider anders aus. Eingefahrene Wege zu verlassen, bessere und kürzere Wege zu finden und zu planen, das ist jetzt die neue Herausforderung.Die erste Frage, die Sie sich stellen sollten: War Software-Lizenzmanagement eventuell schon einmal ein Thema in Ihrem Unternehmen oder hat sich bis dato noch niemand damit auseinandergesetzt? Wenn sich ein Vorprojekt schon einmal daran versucht hat, verschaf-fen Sie sich einen Überblick über die erreichten Ergebnisse und analysieren Sie, wenn mög-lich, warum dieses Projekt nicht weitergeführt oder zu Ende gebracht wurde bzw. warum die erreichten Ergebnisse nicht umgesetzt wurden. Oftmals stoßen Sie dabei auf Ergebnisse und Dokumente, die Ihnen bei der weiteren Dokumentation der Ist-Situation helfen können. Wahrscheinlich reicht das aber noch nicht aus und Sie müssen außerdem das Wissen in den Köpfen der Mitarbeiter identifizieren und zu Papier bringen. Stellen Sie fest, dass sich noch keiner im Unternehmen mit dem Thema Lizenzmanagement beschäftigt hat, müssen Sie leider ganz von vorne beginnen.Um sich einen ersten Überblick zu verschaffen und gleichzeitig die vorgefundene Situa-tion prägnant zu visualisieren, hat sich eine beispielhafte Darstellung wie in Bild 6.2 sehr bewährt. Sie zeigt die Ist-Situation der wichtigsten Abschnitte bezogen auf das Lizenzma-nagement und auf die gewünschte Soll-Situation nach der Einführung eines Lizenzmanage-ments.

6.1 Aufnahme der Ist-Situation – wo beginnen? 111

Ist Soll

Organisation/Prozesse

Rollen und Richtlinien

Schnittstellenübersicht

Compliance-Status

Vertragstransparenz

nicht vorhanden optimiert

Bild 6.2■ Überblick Ist- und Soll-Situation

Ausgehend von der in Bild 6.2 gezeigten Darstellung können Sie in einem nächsten Schritt eine zusammenfassende Risikobeschreibung und Einteilung durchführen. In Bild 6.3 sehen Sie dazu ein Beispiel. Hier wird noch einmal die Situation beschrieben und in eine Risiko-stufe (gering, mittel, hoch) eingeordnet. Damit haben Sie mit zwei Folien eine übersichtliche Darstellung der Ist-Situation erreicht. Sie eignet sich hervorragend für eine Management-zusammenfassung.

Die Bedarfsanforderungen für Software werden nicht prozessual unterstützt. Dadurch besteht keine ausreichende und transparente Übersicht. Beschaffungen erfolgen unkoordiniert, dezentral und unabgestimmt. Die erforderliche Rechtmäßigkeit kann so nicht eingehalten werden, es besteht keine wirkliche Kontrolle über die Softwarebestände.

Organisation und Prozesse

Im Unternehmen sind noch keine zentralen Rollen und Steuerungsmöglichkeiten für ein operatives bzw. strategisches Lizenzmanagement etabliert. Es fehlen die dafür erforderlichen Prozesse und Richtlinien sowie deren organisatorische Einbindung in die bestehenden Geschäftsprozesse.

Rollen und Richtlinien

Die vorhandenen Tools ermöglichen kein effizientes Softwareasset- und Lizenz-management. Daten die gesammelt werden, können nicht verwendet werden. Die Datenschnittstellen sind inkompatibel, es existieren viele Medienbrüche bei der Verarbeitung von Bedarfen.

Schnittstellenübersicht

Die ausreichende und bedarfsgerechte Verfügbarkeit für Softwarelizenzen innerhalb des Unternehmens sowie in Richtung der Kunden ist nicht durchgängig bekannt. Eine bestehende Unterlizenzierung bzw. auch Überlizenzierung kann nicht erkannt werden.

Compliance-Status

Die vorhandenen Softwareverträge liegen nicht in einer elektronisch auswertbaren Form vor. Eine Transparenz über die abgeschlossenen Wartungsverträge fehlt. Eine zentral verwaltete Ablagestelle von Softwareverträgen ist nicht vorhanden.

Vertragstransparenz

Risiko: mittelRisiko: hoch

Bild 6.3■Risikoeinschätzung


Nachdem Sie so eine erste Übersicht über Ihre bestehende Situation erstellt haben, können Sie weiter ins Detail gehen. Bild 6.4 zeigt Ihnen, wie Sie dabei vorgehen können.

Organisation und Prozesse

Problemfeld

• Den Reifegrad der Geschäftsprozesseermitteln

• Einen Soll-Prozess definieren(Optimierungsmöglichkeiten prüfen)

• Die Beschaffungen sind über eine zentraleStelle auszuführen.

• Eine schrittweise Umsetzung von Prozessenfür eine zentrale Beschaffung von Software-produkten

• Der Reifegrad der Geschäftsprozesse ist nicht bekannt.

• Ein Software-Life-Cycle-Prozess ist nicht vorhanden.

• Die Beschaffungen erfolgen unabgestimmtund unkoordiniert.

• Eine Kontrolle über die Softwarebestände erfolgt nicht.

Die Bedarfsanforderungen für Software werden nicht prozessual unterstützt, dadurch besteht keine ausreichende und transparente Übersicht von Softwareanforderungen. Die Beschaffungen erfolgen unkoordiniert, dezentral und sind unabgestimmt. Die erforderliche Rechtssicherheit kann so nicht eingehalten werden, es besteht keine wirkliche Kontrolle über die Softwarebestände.

Maßnahmen

Bild 6.4■Detailliertere Darstellung des Punkts „Organisation und Prozesse“

So können Sie auch die nächsten von Ihnen formulierten Punkte weiter detaillieren und auf-zeigen, wo die Schwachstellen liegen, die Sie dazu bewegt haben, Ihren Schieberegler auf die Position zu bringen, die Sie für realistisch halten (siehe noch einmal Bild 6.2). Die in den vorhergehenden Abbildungen gezeigte Vorgehensweise ist allerdings nur für einen ersten Überblick geeignet. Um eine konkrete und gut bewertbare Darstellung der Ist-Situation zu erreichen, müssen Sie die Analyse verfeinern und vertiefen.Am besten teilen Sie die Analyse der Ist-Situation und deren Abbildung und Dokumentation in zwei Abschnitte auf:

� in die kaufmännischen Prozesse mit den Anforderungs-, Beschaffungs- und Lieferungs-prozessen und

� in die technischen Prozesse mit den Installations-, Verwendungs- und Entsorgungspro-zessen.

Die kaufmännischen Prozesse bilden zusammen mit den technischen Prozessen den Soft-ware-Life-Cycle-Prozess ab (siehe Bild 6.5).

Technische ProzesseKaufmännische Prozesse

Anforderung Beschaffung Lieferung Installation Verwendung Entsorgung

Bild 6.5■Übersicht Software-Life-Cycle-Prozesse kaufmännisch und technisch

Wenden wir uns zuerst den kaufmännischen Prozessen zu.


6.1.1■ Die kaufmännischen Prozesse

Die kaufmännischen Prozesse umfassen die drei Hauptprozesse Anforderung, Beschaffung und Lieferung von Software. Um eine Software in das Unternehmen bzw. auf den Arbeits-platz zu bekommen, muss in einem ersten Schritt eine Softwareanforderung ausgelöst werden. Beschreiben Sie also hier, was alles in einem Anforderungsprozess getan werden muss und wo, damit irgendwann die angeforderte Software auf dem PC oder Server genutzt werden kann.Folgende Fragestellungen können auch mithelfen, eine Gesamtsicht zu bekommen:

� Gibt es u. U. bestimmte Restriktionen, dürfen beispielsweise nur bestimmte Personen eine Softwareanforderung auslösen, oder gibt es Richtlinien, die einzuhalten sind, etc.?

� Welche Systeme bzw. Tools werden für die Anforderung verwendet? � Müssen Genehmigungsprozesse durchlaufen werden oder kann beispielsweise die Soft-wareanforderung über verschiedene Wege (E-Mail, Fax, Papieranforderung) an die ent-sprechenden Einheiten gestellt werden?

� Gibt es einen festgelegten Warenkorb (siehe Abschnitt 3.2.1, „Softwareportfolio – Schutz vor Softwarewildwuchs“) oder kann jeder bestellen, was gerade benötigt wird, ohne auf bestimmte Vorgaben Rücksicht nehmen zu müssen?

Im zweiten Schritt geht es um die eigentliche Beschaffung. Hier müssen Sie herausfin-den, über welche Wege, Abteilungen und Ansprechpartner Software konkret beschafft wird. Wenn Sie sich nicht sicher sind, welche Fachbereiche in die Beschaffung von Software in -volviert sind, erstellen Sie ein Organigramm und tragen Sie dort alle verantwortlichen Orga-nisationseinheiten und Ansprechpartner ein. In Bild 6.6 sehen Sie ein Beispiel dazu. Mit dieser Übersicht erkennen Sie gleich, wer für die anschließenden Interviews zur Analyse der Ist-Situation die richtigen Ansprechpartner sind.

Anforderung Beschaffung Lieferung Installation Verwendung Entsorgung

Client

Fachbereich IT-K IT-S IT-C IT-CL FP-S FP-SAnsprech-Partner Hr. Thes Hr. Schulze Fr. Jaeckel Hr. Meier Hr. Schatz Hr. Keder

Server

Fachbereich IT-M IT-EK IT-S IT-SRV IT-RZ FP-SAnsprech-Partner Hr. Krimm Fr. Götzer Fr. Monet Hr. Fischer Fr. Angel Hr. Keder

Bild 6.6■Beispiel einer Organigramm-Zuordnung der Ansprechpartner und Fachbereiche zu den Software-Life-Cycle-Prozessen

Ganz wichtig sind Personen, die bisher dafür zuständig waren, die kaufmännische Soft-ware- und Lizenzdatenbank zu pflegen (sofern vorhanden). Vergessen Sie auch nicht die Rechtsabteilung, sofern diese für die Softwareverträge verantwortlich zeichnet, oder die Abteilung, die die Verträge verwaltet. Versuchen Sie alle Dokumente aufzutreiben, die in irgendeiner Weise mit der Beschaffung von Software in Ihrem Unternehmen zu tun haben könnten.


Beispielsweise wären das: � Einkaufs- und Vertragsrichtlinien, � Beschaffungsrichtlinien.

Versuchen Sie, die für das Verwalten der kaufmännischen Softwarelizenzen eingesetz-ten Systeme zu identifizieren und zu benennen. Wo werden Bestellungen bzw. Vertrags-daten abgelegt? Geschieht das zentral oder dezentral, in einem oder mehreren Tools? Sind eventuell verschiedene Wege für die Softwarebeschaffung nutzbar? Befragen Sie alle in Ihrem Organigramm festgehaltenen Personen, um sich ein möglichst umfassendes Bild zu machen. Je mehr Informationen Sie sammeln können, umso einfacher und schneller lässt sich die Ist-Situation anhand von Prozessbildern beschreiben.Später müssen Sie mit diesen Daten und Informationen den ersten Baustein Ihres Lizenz-managements aufbauen: das Lizenzinventar (Übersicht über alle erworbenen Softwarepro-dukte aus Verträgen und Bestellungen).Der dritte Schritt ist die Beschreibung der Lieferung der Software. Informieren Sie sich, wie die Software in das Unternehmen gelangt und an den Anforderer ausgeliefert wird. Gibt es beispielsweise einen zentralen Wareneingang oder wird die bestellte Software direkt an den Anforderer überstellt? Wer bucht den Wareneingang, wer übernimmt die fachliche Prüfung der eingegangenen Bestellung, wie wird die Rechnungszahlung veranlasst? Das sind nur einige Beispiele, im Zusammenhang mit der Warenlieferung müssen Sie sicher noch mehr Fragen stellen. Auch für die Lieferung versuchen Sie bitte, Anordnungen und Richtlinien zu finden und zu dokumentieren.Nachdem die Software nun im Unternehmen ist und möglichst über standardisierte Verfah-ren in einem Softwarekatalog bzw. Softwareportfolio aufgenommen wurde, muss sie irgend-wie auf das System des Anforderers gelangen und installiert werden. Kommen wir also zu den technischen Prozessen.

6.1.2■ Die technischen Prozesse

Abhängig davon, ob es sich um eine bereits eingesetzte Software und damit eventuell schon paketierte Software oder eine für das Unternehmen ganz neue Software handelt, sind ver-schiedene technische Prozessschritte bis zur Installation dieser Software zu durchlaufen. Um die teilweise recht komplexen technischen Abläufe identifizieren und beschreiben zu können, sollten Sie die verantwortlichen Mitarbeiter aus den dafür zuständigen Fachabtei-lungen um Hilfe bitten.Auch hier gibt es mit Sicherheit festgelegte Spezifikationen wie beispielsweise diese:

� Ab welcher Installationsanzahl wird ein Softwareprodukt paketiert? � Wird ein Softwareprodukt auch installiert, wenn es eventuell noch keine kaufmännische Lizenz dafür gibt?

� Wird das Produkt erst dann installiert, wenn der kaufmännische Wareneingang gebucht wurde?


Diese wichtigen Indikatoren müssen Sie finden und dokumentieren. Sprechen Sie bitte dabei auch mit den verantwortlichen Abteilungen die im Ist-Prozess gelebten Zuständigkei-ten genau ab, denn es kommt oft vor, dass beispielsweise das Clientmanagement die Hoheit über die Durchführung der technischen Prozesse besitzt und diese nicht so ohne Weiteres an ein zukünftiges Lizenzmanagement anpassen will. Sollten sich hier schon im Vorfeld Probleme abzeichnen, müssen Sie unbedingt die erforderlichen Schnittstellen und die Ver-antwortlichkeiten zwischen dem zukünftigen Lizenzmanagement und den Abteilungen, die für die technischen Prozesse zuständig sind, festlegen. Zu den aufzunehmenden Informa-tionen, gehören auch festgelegte bzw. zu vereinbarende Richtlinien.

6.1.3■ Richtlinien

Zu den wichtigen Richtlinien, die zu dokumentieren sind, gehören beispielsweise: � Richtlinien zum Umgang mit dem Internet und dem daraus resultierenden Download von Software,

� Richtlinien für Telearbeitsplätze, Home Office, Zweit-PCs, Laptops, Tablets oder über-haupt zu mobilen Geräten und deren Einsatz.

Richtlinien, die den Umgang mit „privaten“ Geräten (BYOD)1 beschreiben: � Richtlinien für den Umgang mit Testsystemen und Lizenzen, � Richtlinien zur Softwareinstallation (Wer darf was?), � Richtlinien für die einzuhaltende Softwareproduktstrategie.

Hinweis:Nehmen Sie erst einmal nur allgemeine Spezifikationen auf, in einen tieferen Detaillierungsgrad werden Sie automatisch kommen, wenn Sie die schon an-gesprochenen Software-Life-Cycle-Prozesse und Richtlinien für die Aufnahme der Ist-Situation analysieren.

Weiterhin sind auch die vorhandenen Rollen und Verantwortlichkeiten bei der Aufnahme der Ist-Situation zu identifizieren und dokumentieren.

6.1.4■ Rollen und Verantwortlichkeiten identifizieren

Klassischerweise ist das Verwalten und Dokumentieren von Softwarelizenzen sehr oft im Einkauf angesiedelt, weil dort auch die Softwareverträge abgeschlossen werden. Hier finden Sie vor allem fachliches Vertrags-Know-how, das Sie bei der Erfassung und Bestimmung der Lizenzmodelle für das zukünftige Lizenzinventar benötigen werden. Dabei sind (je nach Größe des Unternehmens) verschiedene Mitarbeiter für die Softwareverwaltung zuständig.

1 BOYD = "Bring your own Device" (das private Gerät wie z. B. Laptop, Smartphone, Tablet wird zur Nutzung mit in das Unternehmensnetzwerk integriert)


Gerne wird auch eine Unterteilung in bestimmte Softwarehersteller und deren Produkte vorgenommen, wie beispielsweise SAP, IBM, Adobe, Oracle, Microsoft u. a., oder nach dem Einsatzumfeld, wie beispielsweise Client, Server, Host u. a. Auf der technischen Seite bzw. im Fachbereich, wo die Software eingesetzt wird, fühlt sich meistens ein Mitarbeiter ver-antwortlich, der oft auch als technischer Produktverantwortlicher oder Softwareexperte bezeichnet wird. Auch hier genügt es erst einmal zu wissen, ob es diese Rollen gibt bzw. wie diese in Ihrem Unternehmen genannt werden. Es wird für das künftige Lizenzmanage-ment sehr wichtig sein, Ansprechpartner auf der kaufmännischen und technischen Seite zu finden bzw. bestimmen zu können. Die drei wichtigsten Rollen im Lizenzmanagement Strategischer Lizenzmanager, Operativer Lizenzmanager und der Produktverantwortliche bzw. Softwareexperte werden ausführlich in Abschnitt 8.3 („Rollen und Verantwortlichkei-ten definieren“) beschrieben. Ihre Aufgabe ist es, bei der Aufnahme der Ist-Situation darauf zu achten, ob es solche oder ähnlich geartete Rollen bereits gibt und ob diese auch „gelebt“ werden.

■■ 6.2■ Dokumentation der Ist-Situation

Die Informationen und Ergebnisse aus Ihrer Ist-Aufnahme sollten umfassend dokumentiert werden. Neben den üblichen und gebräuchlichsten Werkzeugen wie Word, Excel, Power Point und Visio kann Ihnen am Anfang auch die Erstellung von Mindmaps eine gute Hilfe-stellung leisten. Oft hilft diese Methode auch allen Beteiligten, einen Einstieg in die kom-plexe Thematik zu finden. Veranstalten Sie mit den benannten Projektmitgliedern einen Workshop, der sich ganz allgemein mit dem Thema „Lizenzmanagement“ beschäftigt und nehmen Sie die Erwartungshaltung der anderen zu diesem Thema mit auf. So können zunächst alle Ideen und Einfälle gesammelt, und nach Wichtigkeit priorisiert werden.PowerPoint und auch Visio werden gerne für die Abbildung von Prozessen und System-landschaften verwendet und in einem ersten Schritt kann es durchaus ausreichend sein, die wichtigsten Hauptprozesse bzw. Beschaffungswege darin zu dokumentieren und zu beschreiben. Am einfachsten ist es für Sie, wenn Sie die in Kapitel 7 beschriebenen Soft-ware-Life-Cycle-Prozesse mit Ihren Unterprozessen als einen ersten Fahrplan skizzieren, die derzeitige Ist-Situation beschreiben und daran abbilden. In PowerPoint könnte dies bei-spielsweise wie in Bild 6.7 aussehen.

6.2 Dokumentation der Ist-Situation 117

Kaufmännische Prozesse

Anforderung Beschaffung Lieferung

Zusammenfassung der Ist-Situation im Anforderungsprozess• Ein Tool, um damit Lizenzinformationen zu erfassen, ist nicht verfügbar − Dadurch ist kein Compliance-Report erstellbar − Eine Zuordnung der Vertrags- und Lizenzdaten mit Daten aus dem

technischen Inventory ist nicht möglich − Upgrade-Pfade können nicht abgebildet werden− Eine zentrale Beschaffung von Software wird nicht ausreichend gesteuert

• Eine transparente Sicht über die beschafften Softwareprodukte besteht nicht • Informationen über ausgeschöpfte Vertragsvolumen sind nicht ermittelbar

Bild 6.7■Beschreibung der Ist-Situation im Prozess „Anforderung“

In den meisten Unternehmen wird auch Excel quasi als „kleine“ Datenbank eingesetzt. In Excel können Sie zunächst auch erst einmal Informationen aus den unterschiedlichsten Systemen zusammentragen und dokumentieren, wie beispielsweise Verträge und Bestellun-gen, um im ersten Schritt einen groben Überblick zu erhalten, mit welchen Datenmengen Sie später umgehen müssen. Natürlich eignet sich auch eine Textverarbeitung wie Word, um eine Dokumentation der Ist-Situation zu erstellen. So können Sie dort beispielsweise alle Informationen dokumentieren, die Sie aus Interviews oder anderen Quellen zusammen-getragen haben. Die Möglichkeiten sind wie immer sehr mannigfaltig und jeder von Ihnen hat sicherlich eine präferierte Form, wie Dokumentationen erstellt werden. Letztendlich kommt es aber nur darauf an, möglichst alle Informationen zusammenzutragen, die Sie für die weitere Analyse Ihrer Ist-Situation benötigen.

Fazit:Die Aufnahme der Ist-Situation Ihres Lizenzmanagementumfelds ist eine wichtige Maßnahme, die Sie vom Zeitaufwand her nicht unterschätzen sollten. Können Sie eventuell bereits auf die Ergebnisse eines Vorprojekts zurückgreifen, müssen Sie nicht ganz von vorne beginnen. Die Ist-Aufnahme ist insofern empfehlenswert, da Sie dadurch wichtige Erkenntnisse beispielsweise über die bisher angewen-deten Softwarebeschaffungsprozesse oder auch zu den anderen bisher gelebten Prozessen im Software-Life-Cycle-Prozess gewinnen können. Des Weiteren ver-schaffen Sie sich damit einen ersten Überblick über die anstehenden Aufgaben bei der Optimierung Ihres Software-Life-Cycle-Prozesses.

20In diesem Kapitel erfahren Sie u. a.: � weshalb es wichtig ist, dass das Lizenzmanagement die IT-Architektur des Unternehmens kennen sollte und umgekehrt die IT-Architektur wissen muss, dass es ein Lizenzmanagement gibt,

� welche Voraussetzungen notwendig sind, um das Lizenzmanagement bei der Planung, Erweiterung und Änderung der IT-Architektur aktiv mit einbinden zu können,

� welche typischen Fehler entstehen können, wenn das Lizenzmanagement bei Veränderungen der IT-Architektur nicht mit einbezogen wird,

� wie Sie vorgehen, um eine korrekte Lizenzierung erkennen zu können (anhand des Beispiels einer Microsoft-Server-Lizenzierung).

Dieses Kapitel beschreibt, warum IT-Architekten und das Lizenzmanagement zusammenarbeiten sollten und wieso dies einen erheblichen Einfluss auf den Status eines Unternehmens in Bezug auf eine korrekte Lizenzierung seiner Software haben kann.

Der Begriff „Architektur“ umschreibt im Allgemeinen die Planung des Baus von Straßen und Gebäuden in Bezug zur jeweiligen Umwelt und Natur. Für das Funktionieren einer Stadt gilt es, die unterschiedlichsten – in der Regel sich gegenseitig beeinflussenden – Fak-toren zu beachten (z. B. sollte der Straßenverkehr möglichst störungsfrei ablaufen können). Um dieses Ziel zu erreichen, müssen viele Einflussfaktoren ständig beobachtet und gesteu-ert werden, und es bedarf natürlich auch einer Regelung für die Teilnahme am Straßen-verkehr. Die Straßenverkehrsordnung legt solche Regeln fest, die wiederum innerhalb des Verkehrsraums für alle Verkehrsteilnehmer sichtbar gemacht werden müssen und je nach Nutzungszweck entweder für die eine oder die andere Gruppe der Verkehrsteilnehmer Gül-tigkeit besitzen.Dem entsprechen die gewachsenen Strukturen und Prozesse in einem Unternehmen mit den jeweiligen Hard- und Softwarelandschaften (die IT-Umgebung also). Auch hier wer-den, vorgegeben durch die IT-Unternehmensstrategie, die IT-Landschaften architektonisch geplant und umgesetzt und müssen teilweise bestimmten von außen (Hersteller) vorgege-benen Regeln und Nutzungsbedingungen folgen.

IT-Architektur und Lizenzmanagement

342 20 IT-Architektur und Lizenzmanagement

■■ 20.1■ Einige Gedanken zur IT-Architektur

Die IT-Architektur stellt IT-Leistungen zur Unterstützung der Geschäftsprozesse bereit. Bevor eine IT-Architektur entsteht bzw. umgesetzt wird, muss die IT-Strategie eines Unter-nehmens definiert sein. Schon an diesem Punkt sollte auch das Lizenzmanagement be -rücksichtigt werden, damit sich die IT-Strategie später wie vorgesehen umsetzen lässt. Wenn Sie hier nicht mit dem nötigen Augenmaß arbeiten, müssen Sie unter Umständen Lösungen für das Lizenzmanagement finden, die nicht ganz billig sind. In Bild 20.1 ist eine Übersicht einer Gesamtstrategie als Schichtenmodell abgebildet.

Ges

amts

trate

gie

IT-Architektur

Informations-architektur

Unternehmens-architektur

Lizenzmanagement

INOUT

C

BA

Bild 20.1■Notwendige Einbindung des Lizenzmanagements in die Gesamtstrategie einer Unternehmensarchitektur

Ich möchte aber an dieser Stelle nicht weiter auf die erforderlichen Aspekte und Rahmen-bedingungen einer gesamthaften IT-Strategie eingehen, die für die Formulierung und Umsetzung von strategischen, taktischen und operativen Zielen notwendig ist. Hierfür gibt es genügend einschlägige Fachliteratur, wie z. B. das Kapitel „IT-Strategien entwickeln und umsetzen“ und das Kapitel „IT-Architekturen planen und managen“ im „Handbuch IT-Management“.Eine permanente Herausforderung für jeden IT-Manager sind die im Unternehmen gewach-senen heterogenen Systemlandschaften und deren ständige Anpassung an den aktuellen technologischen Fortschritt in den IT-Architekturen. Denn es sind nicht nur die technischen Infrastrukturen zu berücksichtigen, sondern auch die Vielfalt der Anwendungslandschaf-ten mit ihren Systemen, deren Abhängigkeiten voneinander und den oft auftretenden Re -dundanzen. Was die IT-Landschaften so komplex macht, ist die notwendige Verknüpfung der unterschiedlichsten Anwendungen, die bei Umstrukturierungen, Organisationsände-rungen (wie z. B. Outsourcing) und wechselnden Verantwortlichkeiten zum Problem wer-den können. Dabei geht leicht der Überblick verloren und es drohen höhere Risiken im

20.1 Einige Gedanken zur IT-Architektur 343

Bereich des Lizenzmanagements (z. B. mangelnde Transparenz bei der Softwarebeschaf-fung, fehlerhafte Lizenzierung oder Bereitstellung von Software u. a.). In Bild 20.2 habe ich Ihnen einmal einen beispielhaften Aufbau einer IT-Architektur mit verschiedenen Betriebs-abschnitten und den darin befindlichen Komponenten bzw. Bausteinen dargestellt.

Unternehmensarchitektur

Facharchitektur (Geschäftsprozesse, Dienste, Anwendungsfälle, Geschäftsobjekte, Rollen und Berechtigungen)

IT-A

rchi

tekt

ur

Tech

nolo

gie

Info

rmat

ions

syst

eme

Betri

eb

Dienste/Funktionen

Plattformen

TechnischeDienste

Hardware

HardwarenaheIT-Systeme

Client-Software Browser Messaging Dokumenten-bearbeitung Anti-Viren ERP-System

Server Storage Netzwerk Endgeräte (PC, Drucker- und Multifunktions-geräte, Notebooks, Mobile Devices)

Betriebssysteme Virtualisierung Werkzeuge(Monitoring, Inventory Scan)

DomainServices

Datenaustauschund Kommunikation

VPN-Services

Workflow-Services

Security-Services

Web Service

Anwendungen SAPLotus Notes Adobe, Office KasperskyIE, Firefox

Application Server SMTP-Server

Datenbanken(Oracle, MS SQL)

Druck-management

Backup-Management

Archivierungs-management

Bild 20.2■Übersicht Schichtenmodell einer IT-Architektur über drei Ebenen

Wenn über IT-Architektur gesprochen wird, werden fast immer die jeweiligen Anwen-dungslandschaften in den Vordergrund gestellt, was primär natürlich richtig ist, da ja die Geschäftsprozesse unterstützt werden sollen und der Einsatz der Ressourcen möglichst wirtschaftlich erfolgen sollen. Oft genug werden aber die Anwendungslandschaften nur in Bezug auf Performance und höhere Verfügbarkeit getrimmt. Systeme bzw. ganze Anwen-dungslandschaften zu konsolidieren und zu virtualisieren, um Allgemeinkosten (Strom, Kühlung, Räume u. a.) zu sparen, heißt aber noch lange nicht, dass sich damit Softwarekos-ten einsparen lassen. Sehr häufig entstehen bei den geplanten Konsolidierungs- und Mig-rationsszenarien Fehler aufgrund unzureichender Kenntnis der Softwareverträge und der darin vereinbarten Nutzungsbedingungen. Genau hier steckt der Teufel oft im Detail. So ist beispielsweise von entscheidender Wichtigkeit, ob ein System als aktives Backupsystem oder vielleicht nur als sogenanntes „Cold-Stand-By“-System dienen soll. Je nachdem, kann es lizenzkostenfrei oder lizenzkostenpflichtig sein. Den größten Fehler begeht man, wenn man das Lizenzmanagement in Fällen, in denen es um die Beurteilung von Änderungen an der IT-Architektur geht, nicht oder nicht rechtzeitig mit einbezieht.Das Lizenzmanagement soll und muss die Frage beantworten, ob ein bestimmtes System- oder Anwendungsszenario mit den vorherrschenden und vereinbarten Nutzungsbedingun-


gen abbildbar ist. Dazu müssen unter Umständen nicht nur die bestehenden Verträge, son-dern auch die aktuellen PURs (Product Use Rights) und oft auch noch zusätzlich Experten der Softwarehersteller zu Rate gezogen werden. Ein Beispiel dazu sehen Sie in Bild 20.3.

Lizenzmanagement

Szenario 1

Welches Lizenzmodell

ist für welches Szenario optimal?

• Eigene Verträge prüfen• Nutzungsbedingungen des Herstellers

prüfen• Produktverantwortlichen einbeziehen• Experten des Herstellers einbeziehen• Optimales Szenario bewerten und

prüfen

Lizenzmodell festlegen

Szenario 1 �

Internet

Windows Server 2008

Szenario 2

Windows Server 2008

Oracle Oracle

Oracle Oracle

Bild 20.3■Ermitteln des optimalen Lizenzmodells aus der vorhandenen IT-Architektur

Bei dem Beispiel in Bild 20.3 muss eine Entscheidung gefällt werden, ob man das „Named User Plus“ oder das „Singlecore-Prozessoren“-Modell (Lizenzmetrik) von Oracle anwen-det. Hierbei müssen weitere Faktoren beachtet werden, z. B. welche Version der Oracle-Datenbank zum Einsatz kommt und auf welcher Hardware die Datenbank installiert werden soll. Diese Informationen benötigt das Lizenzmanagement aus den Fachbereichen und von den Produktverantwortlichen, die die Anwendung betreuen, um letztendlich das optimale Lizenzmodell bestimmen zu können.

HinweisSicherlich geht es in erster Linie um die effiziente und korrekte Steuerung der unternehmenseigenen IT-Architektur sowie der damit als Ziel verbundenen erhöhten Wirtschaftlichkeit der IT-Landschaft. Aber ihre IT-Strategie und -Archi-tektur sollten auch so flexibel gestaltet sein, dass sie auf ein außerordent liches Ereignis wie z. B. eine Fusion oder die Zusammenlegung von Rechenzentren reagieren können.

Die Kernfragen lauten nun: � Welche Voraussetzungen müssen für die Einbindung des Lizenzmanagements in die IT-Architektur geschaffen werden?

20.2 Voraussetzungen für die Einbindung des Lizenzmanagements schaffen 345

� Wie lässt sich das Lizenzmanagement aktiv in die Steuerung der IT-Architektur einbin-den?

Um beide Fragen beantworten zu können, müssen Sie im Vorfeld Ihren aktuellen Software-Life-Cycle-Prozess betrachten und prüfen, ob Sie überhaupt an die Einbindung des Lizenz-managements – in Bezug auf die IT-Architektur-Steuerung – gedacht haben. Zum Zweiten sollten weitere Voraussetzungen gegeben sein.

■■ 20.2■ Voraussetzungen für die Einbindung des Lizenzmanagements schaffen

Die zu schaffenden Voraussetzungen sind sehr vielfältig und bedürfen der Mitwirkung diverser Fachbereiche und Rollen, um letztendlich eine aktive Einbindung des Lizenz-managements zu erreichen:

� Bebauungspläne einsehen Das Lizenzmanagement sollte sich immer eine aktuelle Übersicht über die IT-Landschaft und die bestehenden IT-Architekturen verschaffen können. Dafür lassen sich normaler-weise sogenannte Bebauungspläne zu Rate ziehen, die es für jedes einzelne Szenario in der IT-Anwendungslandschaft und als Gesamtplan geben sollte. Diese Pläne bilden die Grundlage, um die bestehende IT-Architektur lizenzrechtlich betrachten und verstehen zu können. Bild 20.4 zeigt ein Beispiel für einen fiktiven groben Bebauungsplan einer Anwendungslandschaft für den Zugriff von Kunden über das Internet auf einen zur Ver-fügung gestellten Service (z. B. das Ausführen von Wertpapierorders).

Anwendung

DB2

RZ 1 - Produktion

Kunde

RZ 2 - Backup

Hot-S

tand

by

Cold-StandbyTransaktion

Datenbank-Backup

VMWare

Firewall 1 Firewall 2

24*7 24*7

Cloud

WebSphere Oracle Oracle Oracle

Oracle

Bild 20.4■Grober Bebauungsplan für ein Szenario mit Zugriff über das Internet


Eine saubere Darstellung von Anwendungsszenarien ist natürlich nicht nur für das Lizenzmanagement wichtig, sondern auch für viele andere Bereiche, wie z. B. das Ser-vice Management, um etwa die Verfügbarkeiten von Anwendungen zu regeln und zu bestimmen.

� Zugriff auf die Vertragsmanagementsysteme und Daten Um überhaupt beurteilen zu können, ob sich eine geplante Veränderung in der IT-Archi-tektur, auch auf die vereinbarten Nutzungsbedingungen auswirkt, sollte das Lizenzma-nagement ausreichenden Zugriff auf die Softwareverträge erhalten. Im besten Fall sollte das Lizenzmanagement selbst die Softwareverträge verwalten und einsehen können.

� Software-Life-Cycle-Prozess prüfen Stellen Sie fest, ob in Ihrem aktuellen Software-Life-Cycle-Prozess das Lizenzmanage-ment überhaupt mit eingebunden ist, wenn es um Neuplanungen (IT-Architekturboard) oder Veränderungen (Change- und Release-Management) innerhalb der IT-Landschaft geht (dazu gehören auch Konsolidierungs- und Migrationsprojekte).Das Lizenzmanagement sollte dabei an mehreren Stellen im Software-Life-Cycle-Prozess mit eingebunden sein:1. Im Anforderungsprozess, um hier bereits eine Softwareanforderung auf bestimmte

Kriterien prüfen zu können (z. B. ob ein für das Unternehmen festgelegtes Softwarepro-dukt genutzt werden kann)

2. Im Beschaffungsprozess, um z. B. prüfen zu können, ob der Fachbereich die richtige Produkt version (in Bezug zur Aufgabenstellung) ausgewählt hat (z. B. Microsoft Office Standard und nicht – etwa – Microsoft Office Professional)

3. Im Prozess „Installation“ und hier insbesondere im Prozess „Paketierung und Ab -nahme“, um zu prüfen, ob z. B. die korrekten Softwarelizenzkeys verwendet wurden

4. Im Prozess „Verwendung und Betrieb“, um bei Veränderungen an der IT-Architektur, z. B. bei einer Erweiterung der Ressourcen eines Servers (Prozessorerweiterung), prü-fen zu können, ob die Nutzungsbestimmungen noch zutreffen und keine Unterlizenzie-rung auftreten kann.

Je nach Gestaltung Ihrer Software-Life-Cycle-Prozesse und deren Teilprozesse, könnten weitere Prozesse mit eingebunden sein, so z. B. der Prozess „Providersteuerung“.

� Mitsprache im IT-Architekturboard Zumindest der strategische Lizenzmanager sollte an den vom IT-Architekturboard getrof-fenen Entscheidungen beteiligt sein. In bestimmten Situationen, etwa wenn das vorge-sehene Szenario recht komplex ist und mit den bisherigen Nutzungsbedingungen nicht abbildbar scheint, sollten Sie sich nicht scheuen, den Hersteller um Unterstützung zu bitten, und sich eventuell ein bestimmtes Szenario absegnen lassen – schriftlich fest-gehalten, damit bei einem späteren Audit die lizenzkonforme Nutzung nachweisbar ist (siehe auch Bild 20.2).

� Einbindung des Lizenzmanagements im Release- und Change-Management Das Lizenzmanagement sollte über alle Veränderungen im Release- und Change-Manage-ment informiert und bei der Planung größerer Konsolidierungs-, Migrations- oder Roll-outprojekte rechtzeitig mit einbezogen werden. Nur so ist es möglich, Entscheidungen zu treffen, um später mögliche lizenzrechtliche Probleme zu vermeiden.

20.3 Verteilte IT-Landschaften 347

HinweisDas Lizenzmanagement trifft keine Entscheidungen, ob eine bestimmte Anwen-dung in der Unternehmens-IT-Architektur zum Einsatz kommen soll oder nicht – das entscheiden allein die Fachbereiche mit ihren Anwendungsverantwort lichen bzw. die Produktverantwortlichen.Für die Integration der vielfältigen Systeme eines Unternehmens zu einem ein-heitlichen Ganzen stehen die Produktverantwortlichen und IT-Strategen in der Pflicht, wobei insbesondere die Anbindung der Standardsoftware an proprietäre Schnittstellen und Anwendungslandschaften zu gewährleisten ist.Bei der Entscheidungsfindung kann das Lizenzmanagement beraten und unter-stützen, indem es die notwendigen Werkzeuge, Daten und Prozesse verwendet, um die benötigten Informationen fach- und sachgerecht zur Verfügung zu stellen.

■■ 20.3■ Verteilte IT-Landschaften

Seit einigen Jahren werden diverse Strategien für die Optimierung der IT-Landschaften erprobt oder aus anderen Gründen wie beispielsweise durch Firmenfusionen vorange-trieben. In den seltensten Fällen lagert man bei solchen Aktivitäten die kompletten IT-Landschaften und Architekturen an einen Servicedienstleister aus. Meist sind es spezielle Formen von IT-Leistungen, die aus einem internen Rechenzentrum an einen Servicedienst-leister (Provider) ausgelagert werden in der Hoffnung, diese Leistungen kostengünstiger abzuwickeln. Im einfachsten Fall könnte es sich um einen Druckservice handeln, aber auch ganze SAP-Systeme und Speicherfarmen können ausgelagert werden. Dass diese Formen der Optimierung und Kostenreduktion von IT-Leistungen noch immer nicht der Weisheit letzter Schluss sind, zeigt die Tatsache, dass man ständig neue Visionen und Strategien ausprobiert, nicht zuletzt wird beständig in den letzten Jahren versucht, das Ganze über das „Cloud Computing“ in einer weiteren Technologieform abzubilden.

Risiken einer teilweise ausgelagerten IT-LandschaftAbgesehen vom Risiko, dass der ausgewählte Servicedienstleister möglicherweise seine Aufgaben nicht befriedigend erfüllt und die vereinbarten Dienstleistungen (SLAs) darunter leiden, gibt es weitere Aspekte, die zu berücksichtigen sind, bei den Vertragsverhandlun-gen und beim Vertragsabschluss aber oft vergessen werden. Vorweg sei erwähnt, dass ich mich im Folgenden auf die Softwareprodukte konzentriere.Ein Grund, Teile der IT-Landschaft und IT-Services auszulagern, sind sicherlich Kostenein-sparungen. Meistens werden der Betrieb von Servern bis zur Oberkante Betriebssystem und eventuell noch Services für den IT-Infrastrukturbetrieb (z. B. Help Desk, Softwarebereitstel-lung, Softwareverteilung, PC-Umzüge u. v. a. m.) ausgelagert. Die von einem Serviceprovider zu erbringenden Dienstleistungen im Infrastrukturbetrieb des Kunden sind in Bezug auf das Lizenzmanagement oft unkritisch. Anders sieht es bei dem Betrieb von Systemen mit


Software aus (z. B. Server). Hier herrscht immer noch eine große Unsicherheit, was die lizenzrechtlich korrekte Verwendung der eingesetzten Software betrifft.Viele Hersteller lassen in ihren Nutzungsbedingungen nicht zu, dass ein Dienstleister „ihre“ Software „weitervermietet“. Das ändert sich und einige Hersteller bieten mittlerweile für solche Fälle besondere Lizenzen an (z. B. Microsoft mit dem SPLA-Programm), doch gibt es hier immer noch eine Grauzone sowohl für den Kunden als auch für Serviceprovider mit entsprechenden Risiken, unlizenzierte oder sogar unrechtmäßige Software einzusetzen.

HinweisTextauszug von der Website von Microsoft:„Das Microsoft Services Provider License Agreement (SPLA) eignet sich für Unternehmen, die beabsichtigen, Kunden gehostete Software und Services (z. B. Webhosting, Plattform-Infrastruktur, gehostete Anwendungen für das Messaging und die Zusammenarbeit etc.) anzubieten. Mit der Einführung von SPLA Essentials wurde es Service-Providern erleichtert, ihre Lösungen auf den Markt zu bringen.“ (http://www.microsoft.com/de-de/licensing/lizenzpro-gramme/spla/default.aspx#tab_1)Die zu beachtenden Lizenzierungsoptionen (Nutzungsbedingungen) wurden von Microsoft mit dem Dokument „ServicesProviderUseRights(Worldwide)(English)(April2015)(CR).docx“ (http://www.microsoftvolumelicensing.com/Document-Search.aspx?Mode=3&DocumentTypeId=2) verfasst. Das Word-Dokument kann in verschiedenen Sprachversionen heruntergeladen werden. Es beschreibt auf ca. 70 Seiten die Produktnutzungsrechte für Serviceprovider, die Sie als Anwender ebenfalls kennen sollten, z. B. für die Vertragsverhandlungen und die spätere Kontrolle, ob im Rahmen der geplanten IT-Architektur der Part Ihres Serviceproviders richtig umgesetzt wurde.

Viele Unternehmen kaufen nach wie vor ihre Software selbst. Das hat vielerlei Gründe, wie z. B. steuerrechtliche oder vertragliche Aspekte, aber häufig geht es auch um die direkt an den Kunden (Lizenznehmer) zu erbringenden Wartungs- und Supportleistungen durch den Softwarehersteller gegenüber dem Lizenznehmer. Ein weiterer Aspekt ist, dass die Kunden bei einem Wechsel des Serviceproviders „ihre“ Software zum neuen Serviceprovider mit-nehmen wollen und die Serviceleistungen für Hosting dadurch auch leichter vergleichbar sind. Die Unternehmen geben dann ihre Softwareprodukte und Lizenzen an den Service-provider weiter (Beistellung von Software), damit dieser die vereinbarten Dienstleistungen erbringen kann.Umgekehrt untersagen die Nutzungsbedingungen der Softwarehersteller den Servicepro-vidern meistens, Lizenzpools aufzubauen, um die Software auch für andere Kunden nut-zen zu können. So steckt jeder für seinen Teil in einem Dilemma und die Komplexität der Szenarien verringert sich dadurch nicht gerade.

http://www.microsoft.com/de-de/licensing/lizenzprogramme/spla/default.aspx#tab_1

http://www.microsoft.com/de-de/licensing/lizenzprogramme/spla/default.aspx#tab_1

http://www.microsoftvolumelicensing.com/DocumentSearch.aspx?Mode=3&DocumentTypeId=2

http://www.microsoftvolumelicensing.com/DocumentSearch.aspx?Mode=3&DocumentTypeId=2

20.3 Verteilte IT-Landschaften 349

Welche Risiken bestehen? � Es werden keine ausreichenden und korrekten Aufzeichnungen geführt (weder vom Kun-den noch vom Serviceprovider), wann Serviceprovider welche Softwareprodukte auf wel-chen Systemen einsetzen (Lizenzmanagement gleich null).

� Es gibt keine ausreichende Verwaltung der Softwareprodukte, die vom Kunden bzw. vom Serviceprovider zur Erfüllung der vereinbarten Serviceleistungen beigestellt werden (keine Übersicht auf beiden Seiten über die Anzahl der anfallenden Lizenzverbräuche).

� Die vereinbarten Leistungsscheine werden nicht genau genug beschrieben und dann feh-lerhaft umgesetzt.

� Änderungen an der Konfiguration der Systeme bzw. der Anwendungslandschaft, sowohl aus dem Fachbereich des Kunden, der die Anwendungen betreut, als auch vom Service-provider in Richtung des Kunden, werden nicht ausreichend und nicht rechtzeitig kom-muniziert.

� Es erfolgt keine regelmäßige Überprüfung, ob die Systeme noch mit den vereinbarten Leistungsscheinen übereinstimmen.

� Der Serviceprovider achtet bei der dynamischen Verwaltung der Systeme nicht auf mög-liche lizenzrechtliche Probleme (z. B. bei der Verschiebung von virtuellen Umgebungen (Servern) oder bei der Erweiterung von Hardwareressourcen, wie z. B. dem Hinzufügen weiterer Prozessoren).

� Wird beim Serviceprovider ein Herstelleraudit durchgeführt, können diese Aktivitäten bei eventuellen Unregelmäßigkeiten unter Umständen auch auf die Kunden des Service-providers ausgedehnt werden, vor allem dann, wenn der Kunde und der Serviceprovider identische Produkte beistellen (siehe auch Kapitel 24 Software-Audit).

Tipp:Einige Hersteller bieten sogar eine kostenlose Beratung bei der Erstellung und Optimierung von IT-Architektur-Szenarien an. So können Sie z. B. bei Microsoft den Service „Executive Briefing Centre (EBC)“ in Anspruch nehmen. Dieser Ser-vice hilft Ihnen bei der Analyse Ihrer IT-Umgebungen und unterbreitet auf dieser Basis Optimierungsvorschläge. Der Weblink dazu lautet: https://www.micro-soft.com/enterprise/ebc/default.aspx#fbid=4jty3gWGMmJ. Natürlich geht es hier primär um die Bildung einer IT-Roadmap und Optimierung mit Microsoft-Produkten. Ich habe des Öfteren Gutes über diesen Service erfahren, umso unverständlicher ist es, dass ihn Microsoft kaum bewirbt bzw. weiter publik macht.

https://www.microsoft.com/enterprise/ebc/default.aspx#fbid=4jty3gWGMm

https://www.microsoft.com/enterprise/ebc/default.aspx#fbid=4jty3gWGMm


■■ 20.4■ Lizenzmanagement als Funktion der IT-Architektur

In den bisherigen Erläuterungen führte ich aus, wie wichtig es ist, dass das Betreiben der IT-Landschaften und IT-Architekturen Unterstützung durch einen fachkundigen Bereich benötigt, der ein Auge darauf hat, dass die lizenzrechtlich vereinbarten Nutzungsbedingun-gen von Softwareprodukten eingehalten, aber auch optimiert genutzt werden.Insofern kann man also behaupten: Ja, das Lizenzmanagement ist eine Funktion der IT-Architektur! Warum? Weil die permanente Einhaltung der lizenzkonformen Nutzung der Software gewährleistet sein muss, nicht nur gegenüber dem Hersteller und dem Gesetz geber (Urheberrecht), sondern auch, weil dadurch die Gefahr von unlizenzierter Softwarenutzung verringert oder sogar verhindert wird. Damit schützt das Lizenzmanagement wiederum das Unternehmen vor eventuellen Nachzahlungen. Wenn die Zusammenarbeit optimal läuft, hilft das Lizenzmanagement auch bei der optimalen Ausnutzung der vorhandenen Kapazi-täten. In Bild 20.5 werden die eben genannten Zusammenhänge verdeutlicht.

Lizenzmanagement

Hersteller

Neue Anforderungen oder Veränderungen

IT-Architektur

Verträge prüfen

Nutzungs-bedingungen

prüfen

Bild 20.5■Lizenzmanagement als Funktion der IT-Architektur

Damit das Lizenzmanagement arbeitsfähig ist und seine Aufgaben erfüllen kann, muss es verlässliche und belastbare Informationen und Daten bekommen. Für die Grundfunk-tion, technische und kaufmännische Daten aus der IT-Architektur für die Verarbeitung im Lizenzmanagement zu erhalten, kann von zwei Szenarien ausgegangen werden: das Erfas-sen der Daten aus dem Client-Umfeld und das Erfassen der Daten aus dem Server-Umfeld. Beide Szenarien gliedern sich dann jeweils in drei mögliche Evolutionsstufen (siehe die Bilder 20.8 bis 20.10).

Erfassen der Daten aus dem Client-UmfeldBild 20.6 zeigt das Grundszenario für das Erfassen von Daten aus dem Client-Umfeld.

20.4 Lizenzmanagement als Funktion der IT-Architektur 351

QA

Standard-Scansystem�Client-Hardware�Softwareinstallationen�Daten aus dem Active

Directory (User, Adressbuch)

TechnischeDaten�Hardwareinventar�Infrastrukturdaten

Re-Scan

Holding

Re-Scan

Außendienst

Kaufmännische Daten�Beschaffungen

(Kauf-, Mietverträge)�Rahmenverträge

(Lizenzmetriken, Absprachen)

Datenlieferung

Anforderung & Rückmeldung

QA Qualitätsanalyse

Bild 20.6■Grundszenario für die Erfassung von Client-Daten

Die Standardsysteme für die Erfassung von Hard- und Software sammeln die erforderlichen technischen Daten aller am Unternehmensnetzwerk angeschlossenen Systeme. Gleichzeitig werden weitere Informationen (z. B. aus dem Active Directory) mit in die technische Daten-bank übertragen. Diese Daten können zusätzlich mit weiteren kaufmännischen Informa-tionen ergänzt werden. Über eine Qualitätsprüfung (mit „QA“ im Bild gekennzeichnet) werden die Rohdaten aus dem Scanlauf auf ihren Informationsgehalt (z. B. ob bestimmte Parameter erfüllt wurden) und die erforderlichen Qualitäten geprüft. Sollten die Daten nicht den Anforderungen entsprechen, wird ein Re-Scan durchgeführt, um eine bessere Daten-qualität und -quantität zu erhalten.Damit sind die Informationen aus der IT-Architektur des Client-Umfelds erhoben und im Rahmen der Stufe 1 (aktiv) verarbeitet worden (siehe hierzu auch Bild 20.8 Stufe 1 – Aktive Unterstützung der Lizenzkonformität).

Erfassen der Daten aus dem Server-UmfeldDas Erfassen der benötigten Informationen aus dem Server-Umfeld stellt das zweite Grund-szenario dar, wie Bild 20.7 demonstriert.


Re-Scan

Anwendungen

Herstellerspezifische Scansysteme�Hardware�Software�Kennzahlen�Parameter

IT-Architektur

Architekturspezifische Scansysteme (Skripte, Batches)�Umgebungsparameter�Auslastungen�Performance-

Messungen� Log-Files

Manuelle Mitwirkung im Prozess

CMDB

Import der

Daten

Re-Scan

Kaufmännische Daten�Beschaffungen

(Kauf-, Mietverträge)�Rahmenverträge

(Lizenzmetriken, Absprachen)

Technische Daten�Hardwareinventar� Infrastrukturdaten

Rechenzentrum

Manuelle Erfassung(z.B. mit Excel-Templates)�Hardware�Software

Standard-Scansysteme�Hardware�Software

Datenlieferung

Anforderung & Rückmeldung

QA

QA

Qualitätsanalyse

Bild 20.7■Grundszenario für das Erfassen von Server-, Anwendungs- und IT-Architekturdaten

Das in Bild 20.7 abgebildete Szenario beschreibt die Erfassung von Hard- und Software-daten aus dem Rechenzentrum mit den dort implementierten Scansystemen (abhängig von den eingesetzten Betriebssystemplattformen). Dabei werden die Daten unter Umständen auch nur manuell oder halbautomatisiert erfasst. Nicht immer ist die Konstellation derge-stalt, dass auf den Server-Systemen Scansoftware laufen darf, teilweise aus Performance-, oft aber aus Sicherheitsgründen. Auch hier können die erfassten Daten in der technischen Datenbank mit weiteren Informationen ergänzt werden. Über die Qualitätsanalyse werden auch hier die Rohdaten aus dem Scan- bzw. dem Importlauf auf die erforderlichen Quali-täten geprüft und zwar so lange, bis die gewünschten Datenqualitäten erreicht werden. Zusätzlich zu den allgemeinen technisch erfassbaren Daten (Scandaten) ist es möglich, wei-tere Softwareprodukte durch herstellerspezifische Scansysteme zu erfassen. Ein Beispiel hierfür wäre der Einsatz des Scantools von IBM: das ILMT (IBM License Metric Tool)1. Das Tool erfasst alle IBM-Produkte (für diesen Einsatzzweck ist das Tool kostenfrei), kann aber auch für das Scannen von jeglicher Serversoftware eingesetzt werden (dafür müssen dann aber Lizenzgebühren gezahlt werden). IBM setzt dieses Tool hauptsächlich dafür ein, den korrekten Verbrauch der Lizenzmetrik PVU (Processor Value Unit) zu messen, die abhängig

1 http://www-03.ibm.com/software/products/en/licensemetrictool, http://www-01.ibm.com/software/tivoli/products/license-metric-tool/

http://www-03.ibm.com/software/products/en/licensemetrictool

http://www-01.ibm.com/software/tivoli/products/license-metric-tool/

http://www-01.ibm.com/software/tivoli/products/license-metric-tool/


von der eingesetzten Hardwareumgebung und der Anzahl der genutzten aktiven Prozessor-kerne ist.2

Da die herstellerspezifischen Scansysteme eigene Datenbestände erzeugen, können diese Informationen nur dann in einer weiteren Datenbank abgelegt werden (bevorzugt eine CMDB – Configuration Management Data Base), wenn sie außerhalb der herstellerspezifi-schen Lösung weiterverarbeitet werden sollen. In diese CMDB fließen dann zusätzliche Informationen aus der IT-Architektur (z. B. aus verschiedenen Anwendungslandschaften) mit ein und werden dort entsprechend aufbereitet. Diese Informationen lassen sich durch die manuelle Mitwirkung von Experten (z. B. einem Produktverantwortlichen oder einem Ansprechpartner aus dem die Anwendung betreuenden Fachbereich) ergänzen oder zusam-menführen.Damit sind die Informationen aus der IT-Architektur des Server-Umfelds erhoben und im Rahmen der Evolutionsstufe 1 (aktiv) verarbeitet worden.Wenden wir uns nun der Erläuterung der eingangs erwähnten drei Evolutionsstufen einer Lizenzkonformität zu.

20.4.1■ Lizenzkonformität Stufe 1 (aktiv)

Die Lizenzkonformität der Stufe 1 beschreibt die grundlegend erforderlichen Aktivitäten und Voraussetzungen zur Erfassung und Bereitstellung von Informationen für das Lizenz-management und umfasst folgende Anforderungen:

� Alle Softwareprodukte von Servern und Clients werden erfasst (manuell, halb- oder voll-automatisch).

� Infrastrukturdaten stehen zur Verfügung (z. B. aus dem Active Directory, E-Mail-Adress-bücher oder die Benutzerdaten aus dem SAP-System – hier werden nur namentlich benannte Benutzer für die Lizenzierung angewendet).

� Kaufmännische Daten stehen zur Verfügung (z. B. aus einem zentralen Vertragsmanage-mentsystem).

� Der Software-Life-Cycle-Prozess ist etabliert (mit dem wichtigsten Prozess: der zentralen Anforderung und Beschaffung von Software).

� Die Rollen (z. B. Lizenzmanager) und Richtlinien (z. B. darf keine Software unautorisiert installiert werden) sind bekannt und werden „gelebt“.

� Aus den erforderliche Daten und Informationen können bereits belastbare Compliance-Reports erstellt werden.

2 Siehe auch dazu auf der IBM-Webseite http://www-01.ibm.com/software/passportadvantage/pvu_licensing_for_customers.html

http://www-01.ibm.com/software/passportadvantage/pvu_licensing_for_customers.html

http://www-01.ibm.com/software/passportadvantage/pvu_licensing_for_customers.html


Datenabgleich

Verträge Lizenzen

QA QA

Reporterstellen

Test-auswertungQA

Stufe 1 (aktiv)

Datenlieferung

QA

Lizenzmanagement-Tool

Technische Daten�Hardwareinventar�Infrastrukturdaten

Einkauf

Prüfen

Datenlieferung Anforderung & Rückmeldung QA Qualitätsanalyse

Compliance- Report

Bild 20.8■Stufe 1 – Aktive Unterstützung der Lizenzkonformität

Die Lizenzkonformität der Stufe 1 (siehe Bild 20.8) sieht bereits eine aktive Unterstützung zur Erfassung und Verarbeitung der für das Lizenzmanagement notwendigen Daten vor. Die größte Herausforderung besteht darin, die erforderliche Datenqualität und oft auch die erforderlichen Quantitäten zu erhalten. Nicht selten sind verschiedene Scanner-Systeme mit unterschiedlichen Datenstrukturen im Einsatz, so dass bereits im Vorfeld eine relativ umfangreiche Datenzusammenführung, Verdichtung und Bereinigung der Softwareroh-daten erfolgen muss. Die zweite Maßnahme besteht darin, die Ergebnisse noch einmal einer Qualitätsanalyse (QA) zu unterziehen, damit auch wirklich nur verwertbares Datenmate-rial für den Datenabgleich Verwendung findet (Box: Datenabgleich). Das eben Gesagte gilt natürlich auch für die Bereitstellung der kaufmännischen Daten und Informationen, also der Vertragsdaten mit den getroffenen Vereinbarungen (z. B. wurden eventuell spezielle von den normalen Nutzungsbedingungen der Software abweichende Lizenzmetriken fest-gelegt), weiterhin die für einen Softwarevertrag wichtigen Lizenzinformationen (wie z. B. Lizenzmetriken, Wartungsfristen) u. v. a. m. Zusätzlich müssen die getätigten Bestellungen (Bewegungsdaten) in den Datenabgleich mit einfließen.Im nächsten Schritt werden die im Lizenzmanagement-Tool zusammengeführten Daten einer Testauswertung unterzogen und über eine erste Plausibilitätsprüfung ausgewertet (Box: Testauswertung mit anschließender Qualitätsanalyse). Sind die Ergebnisse aus der Testauswertung plausibel, kann man den ersten Compliance-Report erstellen. Sicherlich wird nicht gleich die gewünschte Datenqualität zu erwarten sein, sie muss sich erst langsam aufbauen und konsistenter werden. Deswegen kommt es beim ersten Compliance-Report


öfter zu Rückfragen und man muss prüfen, welche Daten unter Umständen korrigiert oder neu justiert werden müssen. Das ist insgesamt ein recht langwieriger, iterativer Prozess, der sich über mehrere Wochen hinziehen kann.

HinweisDas Lizenzmanagement verarbeitet nur die ihm über Schnittstellen übermittelten Informationen mit einem Werkzeug (Lizenzmanagement-Tool) und ist selbst nicht der Eigentümer dieser Informationen. Das Lizenzmanagement selbst kann nur Hinweise geben und den Eigentümern der Daten Maßnahmen empfehlen, um eine bessere Datenqualität zu erreichen.

Sind die ersten Schwierigkeiten gemeistert, kann man Stufe 2 für die Unterstützung der Lizenzkonformität in Angriff nehmen.

20.4.2■ Lizenzkonformität Stufe 2 (proaktiv)

Die Lizenzkonformität der Stufe 2 bindet bereits verantwortliche Experten aktiv in die Auf-gabenstellungen des Lizenzmanagements mit ein und umfasst folgende Anforderungen:

� Das Lizenzmanagement ist bereits permanent und aktiv in Entscheidungsfindungen zur Änderung oder Neuausrichtung der IT-Architektur und oder Anwendungslandschaft mit eingebunden.

� Das Lizenzmanagement führt proaktive Beratung bei Technologieänderungen und bei der Beschaffung von Software durch (ist zentraler Ansprechpartner für die Fachbereiche und für die Produktverantwortlichen).

� Unterstützt die IT-Strategie und berät die Produktverantwortlichen in den Fachbereichen im Vorfeld von Projekten.

� Die Stufe 2 kann bereits geforderte Kennzahlen zu Softwareassets liefern (z. B. Anzahl der Installationen eines bestimmten Softwareprodukts, räumliche Verteilung eines bestimm-ten Softwareprodukts u. a.).

Die Stufe 2 (siehe Bild 20.9) bindet bereits gezielt Beratungs- und Unterstützungsleistung aus den Fachbereichen und vom operativen Lizenzmanager mit ein. Insbesondere werden hier aktiv die angewendete IT-Strategie mit den IT-Landschaften, die IT-Architektur mit den Bebauungsplänen der Anwendungslandschaften und das Veränderungsmanagement (Change Management) über alle diese Ebenen hinweg gemeinsam mit dem Lizenzmanage-ment gesteuert. Dies setzt natürlich auch voraus, wie bereits erwähnt, dass die Rolle des strategischen Lizenzmanagers aktiv an den Entscheidungen aus den IT-Strategie- und IT-Architektur-Meetings beteiligt wird. Die Fachbereiche und die Produktverantwortlichen sehen das Lizenzmanagement bereits als SPOC (Single Point of Contact) für Fragen rund um den Software-Life-Cycle-Prozess in Bezug auf Anforderung, Beschaffung und Change Management von Softwareprodukten und Lizenzen.


Produkt -verantw .

Datenabgleich

Verträge

Einkauf

Lizenzen

QA QA

Reporterstellen

Test-auswertungQA

Datenlieferung

QA

Prüfen�IT-Strategie�IT-Architektur�Change Mgmt.

Lizenz-management Fachbereich


Stufe 2 (proaktiv)


Datenlieferung Anforderung & Rückmeldung QA Qualitätsanalyse

Compliance- Report

Bild 20.9■Stufe 2 – proaktive Unterstützung der Lizenzkonformität

20.4.3■ Lizenzkonformität Stufe 3 (optimiert)

Die Stufe 3 der Lizenzkonformität benutzt zusätzliche Informationen, ob eine Software-installation (und damit auch die Lizenz) ausreichend genutzt wird. (In Kapitel 18 „Soft-warenutzung – Lizenzen proaktiv managen“ wird auf diesen Aspekt ausführlich eingegan-gen.) Die Lizenzkonformität der Stufe 3 ist die höchste erreichbare Stufe und unterstützt proaktiv die komplette Steuerung der in einem Unternehmen verfügbaren Softwareassets und Lizenzen.Sie umfasst folgende Anforderungen:

� Die Softwarenutzungsdaten können dauerhaft erhoben und verarbeitet werden. � Das Softwareportfolio wird anhand der Nutzungsdaten proaktiv verwaltet und gesteuert. � Die Standardisierung der Anwendungslandschaft wird durch die Erhebung der Soft-warenutzungsdaten unterstützt.

� Das Lizenzmanagement hilft, Kosten zu reduzieren, und unterstützt aktiv die Optimie-rung des vorhandenen Lizenzbestands.

� Die Fachbereiche und Produktverantwortlichen steuern zusammen mit dem Lizenz-management die Anwendungslandschaften in Bezug auf bestmögliche Ausnutzung der mit den Herstellern vereinbarten Nutzungsbedingungen.


� Bei Konsolidierungsvorhaben und Migrationsprojekten werden bereits im Vorfeld die zusätzlichen Softwarenutzungsdaten mit einbezogen und unterstützen Entscheidungen im IT-Architekturboard bzw. bei der Ausrichtung der IT-Strategie.

� Die Informationen helfen, die Dienstleistungen eines Serviceproviders aktiv zu steuern, auch in Bezug auf Anpassung und Optimierung der vom Serviceprovider betriebenen Systeme und Anwendungen (z. B. Konsolidierung von Servern durch Virtualisierung).

� Aus den verarbeiteten Daten können Informationen zur Ableitung weiterer Optimierungs-maßnahmen gewonnen und zur Steuerung für andere Prozesse verwendet werden.

Maßnahmenkatalog mit Optimierungsvorschlägen

Produkt -verantw .

Datenabgleich

Verträge

Einkauf

Lizenzen

QA QA

Reporterstellen

Test-auswertungQA

Datenlieferung

QA

Prüfen�IT-Strategie�IT-Architektur�Change Mgmt.

Lizenz -management Fachbereich

Software-nutzungsdaten

ahmenkatalo


Stufe 3 (optimiert)


Datenlieferung Anforderung & Rückmeldung

QA Qualitätsanalyse

Bild 20.10■Stufe 3 – optimierte Unterstützung der Lizenzkonformität

Die Stufe 3 (siehe Bild 20.10) wird in der Regel erst erreicht, wenn alle Systeme und Pro-zesse aufeinander eingespielt sind und in puncto Qualität und Quantität gleichbleibende Datenlieferungen vorausgesetzt werden können. Eine weitere wichtige Voraussetzung ist die Möglichkeit, die permanent erhobenen Softwarenutzungsdaten in den Datenabgleich mit aufzunehmen, um beispielsweise Aussagen über installierte, aber nicht mehr genutzte Softwareprodukte treffen zu können. Hieraus lassen sich weitere Maßnahmen ableiten und durchführen (z. B. die Deinstallation nicht genutzter Software und deren Rückführung in einen gemeinsamen Software-Pool) oder die Verteilung nicht genutzter Software an andere Standorte oder Unternehmensteile (wenn es die Nutzungsbedingungen des Herstellers, die Product Use Rights – PUR gestatten). Diese Ergebnisse sind dann für viele andere Fach-bereiche und Verantwortliche von enormer Wichtigkeit. So können beispielsweise nicht


mehr genutzte Softwareprodukte aus dem genehmigten Softwareportfolio entfernt werden, was u. a. die Service- und Infrastrukturkosten reduziert (Help Desk, Patch- und Release Management). Der Einkauf und das Vertragsmanagement benötigen diese Informationen, um die notwendigen Lizenzbeschaffungen und die bereits bestehenden Verträge (mit und ohne Wartung) aktiv steuern und anpassen zu können.

■■ 20.5■ Beispielszenarien von IT-Architekturen

In Bild 20.3 wurde bereits ein beispielhaftes Szenario vorgestellt, in dem die Mithilfe des Lizenzmanagements erforderlich wäre. Hier geht es darum, die für das Unternehmen best-mögliche, wirtschaftlichste und gleichzeitig lizenzkonformste Lösung zu finden (gemäß den mit dem Hersteller vereinbarten Nutzungsbedingungen). Um diese Aufgabenstellung zur Zufriedenheit aller lösen zu können, werden Informationen aus der bestehenden IT-Archi-tektur und zusätzlichen Informationen aus den Verträgen benötigt. Im Folgenden werden einige typische Szenarien vorgestellt:

20.5.1■ Szenario 1 IBM-Lizenzierung

Beurteilung, ob für eine Datenbankanwendung eine Volllizenz erforderlich ist oder ob eine beschränkte Lizenz (Restricted Version) eingesetzt werden kann.

AusgangssituationDas Unternehmen betreibt seine IT-Landschaft in einer gemischten Umgebung. Teile der IT-Infrastruktur werden von mehreren Serviceprovidern betrieben. So sind die Client- und Server-Strukturen in der Verantwortung unterschiedlicher Serviceprovider. Die Komplexi-tät in diesem Szenario ergibt sich daraus, dass der Provider die Anwendungslandschaften teilweise mit beigestellter Software vom Kunden, aber auch mit eigener (identischer) Soft-ware betreibt.

AufgabeIn die Anwendungsumgebung werden Datensätze geliefert, die ein kleines Zusatzpro-gramm innerhalb der Datenbankinstanz temporär verarbeitet und mit weiteren Informa-tionen anreichert. Nach der Verarbeitung werden diese Daten aus der Datenbankinstanz komplett in ein anderes Datenbanksystem exportiert, auf das die Anwender von außen, über das Internet, zugreifen können. Die beiden Datenbanksysteme kommunizieren über die erforderliche Schnittstelle nur mit den Rechten eines internen Servicekontos.

FrageWie ist der Zugriff von außen auf das Hauptdatenbanksystem in Richtung auf das die Daten-sätze verarbeitende Datenbanksystem lizenzrechtlich zu beurteilen?

A

AddOn 498Adobe Mietmodell 19Advancved Compression Option (Oracle) 397Agent-based 498Agent-less 498Aktivitätenplan für eine Projektdurchführung 90Angebotsauswertung – Bewertungstabelle (Beispiel) 285

Ansprüche nach §§ 97ff UrhG 477Anwendungsaufrufe – Ergebnisse zur Nutzung 332

Anwendungsdaten – Grundszenario für das Erfassen 352

Anwendungsvirtualisierung – Varianten 335

Application Specific License (ASL) 378Arbeitspaket 498 – Aufgabendefinition 100 – festlegen 98

Audit – Praxistipp 476

Auditierung 498 – Verhaltensregeln 479 – Welche Informationen sind wichtig? 481

Auditierungsverhalten, IBM, Microsoft, Oracle, Adobe, SAP 483

Auditinformationen – IBM 481 – Microsoft 482

Auditrecht 472Aufbau der Server-Komponenten des ILMT-Tools

362Aufbewahrungsfrist Lizenzverträge und Lizenz-

nachweise 4

Auftraggeber – Rollenbeschreibung 81

Aufwandskategorie – Einteilungsmatrix 256

Ausgelagerte IT-Landschaft – Risiken 347

Ausschreibung, erforderliche Dokumente 272Ausschreibungsprojekt – grober Zeitplan 275 – Informationsabschnitte 275

Auswertung tatsächlicher Softwarenutzung (Praxisbeispiel) 321

BBaFin Rundschreiben zum Risikomanagement

14Basel II 56, 498BDSG siehe Bundesdatenschutzgesetz 11Beispielmatrix für die Ermittlung zusätzlicher

Lizenzen 366Beitrittsvertrag 498Bereitstellungs- und Installationsprozess, KPI

159Beschaffungsprozess – analysieren 173 – anfordern und bestellen 173 – Fragen 174 – KPI 158 – Maßnahmen zur Optimierung 175 – Merkmale zur Optimierung 175

Beschaffungswege – vereinheitlichen, Schritte 182 – weitere identifizieren 181

Besichtigungsrecht – zivilrechtlich 472

Index

510 Index

Besitzanzeigende Verträge 498Bestandsaufnahme – Abgrenzung der Daten 190 – Inventarlisten 189 – kaufmännische Softwaredaten 209 – Software, Vorgehen und Planung 189

Bestelldaten, bereinigen 230Box-Produkt siehe FPP Full Packaged Product

32Brute-Force-Ansatz 388BSA (Business Software Alliance) 468 – aktuelle Studie 4

BSA-Studie, Daten 468

CCAL (Client Access License) 498CAL Guide 371CALs, weitere Informationen (Weblink) 391CI Configuration Item 498Citrix-Umgebung, Lizenzierung (Beispiel) 363Client 498Client Access Rights (CAL) 389Client-Daten – Grundszenario für die Erfassung 351

Clientklassen 499Clientklassen (Fachbereiche) – mögliche Verteilung 251

Cloud 430, 499 – neue Komplexitäten 440

Cloud Computing – klassische Softwareprodukte in der Cloud 443

– neue Anforderungen an das Lizenzmanage-ment 444

Cloud-Anbieter 437Cloud-Formen, Aufteilung 436Cloud-Liefermodell mit Bezug zum Lizenz-

management 432Cloud-Servicemodelle 433 – Aussagen zu strategischen Zielen 438

Cloud-Services – Erwartungshaltung bei der Umsetzung 440

Cloud-Technologien – Ziele 438

Cloud-Umfeld – Hürden 439

Cloud-Umgebungen – die vier Formen 431

Cluster (Rechnerverbund) 381

CM 499CMDB 499CMMI 499CoM 499Community Cloud, Beschreibung 432Community-Cloud-Form bei öffentlichen

Behörden 433Compliance 499Compliance-Auswertung Adobe Standard

(Beispiel) 312Compliance-Check 499Compliance-Report, Bestandteile 12, 500Computerwoche – Informationen rund um die Oracle-Welt (Weblink) 406

Computing, Voraussetzungen schaffen 426Concurrent Use 500Cross-Upgrade 500

DDaten einer Inventarisierungsaktion, Auszug 205Datenbereinigung – Aufbau Materialstamm (Beispiel) 231 – eindeutige Kennzeichnung (Beispiel) 231 – erreichbare Ziele 236 – Grobplanung Arbeitspakete 228 – Initialbeladung vorbereiten 235 – kaufmännisch 228 – Punkte für die Planung 233 – Softwareprodukte kennzeichnen 230 – technisch 232, 234

Datenmodell 500DOAG Deutsche ORACLE-Anwendergruppe e.V.

(Weblink) 406Dokument „Memorandum of Understanding

(MoU)“ 286Dongle 500Downgrade-Recht 500DSL (Definitive Software Library) 500

EeCl@ss 500 – Aufbau und Struktur 245 – Beschreibung 244 – Hauptgruppen 245 – Klassifizierung, Beispiel 246 – Vorteile 244

Einfache Softwareklassifizierung, Übersicht 241

Index 511

ELP (Effective License Position), erforderliche Daten 482

Embedded License 378End User License Agreement 13, 23, 38Entitlement 500Entsorgungsprozess, KPI 159, 160EULA (End User License Agreement) 500EULA (Lizenzvertrag einer Download-Lizenz) – Auszug 38

EuroSOX 55Evaluierungsanforderungen – Aufbau Tabellenkopf 277

Experte, Rollenbeschreibung 84Externe Bestellung, Beschreibung 180

FFalsch lizenzierte Software 469Flowchart, Arbeitspakte, Projektstrukturplan

99Forecast-Based Agreement 500Free Software, Definition 24Freeware 500 – Definition 23

Freie Software – Definition 24 – Kriterien 25 – Lizenzvertrag 40

FSF siehe Free Software Foundation 25, 41Full- und Sub-Capacity im Vergleich (Beispiel

Kundensituation im IBM-Server-Umfeld) 414FullPackaged Products (FPP) 500Funktionstest 500

GGartner – 10 Top-Tech-Trends 18Gartner-Analyse zum aktuellen Audit-Trend bei

Softwareherstellern 475GDPdU (Grundsätze zum Datenzugriff und zur

Prüfbarkeit digitaler Unterlagen) 11Gebrauchte Software – Verkauf 471

Gerät 500 – Definition 42

Geräteklassen – Übersicht und Beschreibung (Beispiel) 248 – Zuordnung zu Softwareklassen 249

Gesamtklassifizierung Softwareprodukte (Beispiele) 251

Geschäftliches Wachstum, Grundprinzip 120Geschäftsprozess 501GNU GPL (General Public License) 41, 501Greenfield-Ansatz 501Grober Bebauungsplan für ein Szenario mit

Zugriff über das Internet 345Grober Projektzeitplan, Phasenübersicht 98Grundlizenzmetriken (Prozessor, Core, Installa-

tion) 385

HHaftung des Unternehmens 477Haftung – handelsrechtlich 54 – strafrechtlich 53 – zivilrechtlich 52

Haftungsausschluss 468Haftungserweiterung, § 100 UrhG 477Hard-Disk loading 470Hardware 501Hardwaremerkmale für eine Server-Lizenzierung

379Hardwareparameter – physikalische Sockel 379 – Prozessortyp 379

Hybrid Cloud 432

IIBM ILMT (Komponenten) 363 – Toolerläuterung 362

IBM ILMT-Tool (Weblink) 361IBM Passport Advantage Agreements, forms

and attachments (Weblink) 362IBM PVU (Weblink) 362IBM Rules for Manual Calculation of Virtuali-

zation Capacity 361IBM Sub-capacity Licensing Information

(Weblink) 362IBM Virtualization Capacity rules for each

eligible virtualization environment (Weblink) 362

IBM-Lizenzierung (Beispiel) 358IBM-PVU-Tabelle (Auszug, Stand Juni 2015) 407IMAC (Install, Move, Add, Change) 121, 501Implementierungsphase – Projektplan (Beispiel) 294

Implementierungsprojekt – Phasenplan (Beispiel) 293

512 Index

Infrastructure-as-a-Service (IaaS) 433Initialbeladung 501Initialbeladungsszenario (Beispiel) 236International Passport Advantage Agreement

(IPAA), (IBM-Vertrag) 410Interne Bestellung, Beschreibung 179Internetpiraterie 470Inventarisierung – Agent-based 193 – Agent-less 194 – Ausschlussliste 191 – Daten analysieren, auswerten 202 – Gegenüberstellung klassisch und virtuell 442 – installationsloses Verfahren 195 – Linux-Server 192 – Methoden und Werkzeuge 192 – Methodik 196 – mit Greenfield-Ansatz 197 – mit kommerziellen Werkzeugen 198 – mit Open-Source-Werkzeugen 197 – mit Regeldatei 197 – nutzbare Datenquellen 200 – Powershell-Script 201 – Scanumfang Clients 199 – Scanumfang Server 199 – weitere Quellen 201 – Windows-Client 191 – Windows-Server 191

ISO 19770-1 – Prozesse 493, 494

ISO/IEC 19770-1 – Ausschnitt Prozessbewertung 136 – Beschreibung 491 – die vier Implementierungsabschnitte 139 – Hinweis zum Einsatz 122 – Kompetenzfelder 136

Ist-Aufnahme 501Ist-Situation – Komplexitätstreiber 127 – Strukturen und Prozesse 124

IT-Architektur – Allgemeines 342 – Beispielszenarien 358 – Daten erfassen aus dem Client-Umfeld 350 – Daten erfassen aus dem Server-Umfeld 351 – Kernfragen 344 – Lizenzkonformität Stufe 1 (aktiv) 353 – Lizenzkonformität Stufe 2 (proaktiv) 355 – Lizenzkonformität Stufe 3 (optimiert) 356 – Schichtenmodell 342 f.

– verteilte IT-Landschaften 347 – Voraussetzungen schaffen 345

IT-Architekturdaten – Grundszenario für das Erfassen 352

KKaufmännische Datenbereinigung – planen 228

Kaufmännischer Report 501Key Process Indicator (KPI) im Lizenzmanage-

ment 157Klassifizierungsprojekt – Meilensteinplan zur Durchführung 257

Kommunikationsfluss – im Projekt 86 – zwischen den Projektbeteiligten 86

Komplexitätssteckbrief für Lizenzmetriken 129

Komplexitätstreiber – Prozesse 127 – Rollen 127 – Schnittstellen 128 – Verträge 127

KonTraG (Gesetz zur Kontrolle und Transparenz im Unternehmensbereich) 11, 13, 56, 501

Konzernlizenz 501KPIs für die Optimierung des Lizenzbestands

420Kumulierte verdichtete Rohdaten – Auszug 234

Llaptop.nfo-Datei – Auszug 203 – umgewandelt in Laptop.txt-Datei 203

Laptop.txt – Datenexport nach Excel 204

Lastenheft 501 – Beispielformulierung 265 – Beschreibung 262 – Definition 263 – häufige Probleme bei der Erstellung 268 – Inhalt 262 – Struktur und Aufbau 264 – Worauf achten? 267

Lastenheftanforderungen, Strukturgramm 268Lenkungskreis, Rollenbeschreibung 83License Metrik Tool (ILMT), (IBM) 409

Index 513

Lieferantenreport – Anforderungsbeschreibung (Beispiel) 305

Lizenz 22, 501Lizenz, 90-Tage-Regel 383Lizenzadministrator 501Lizenzart 501 – Beschreibung 43 – Einzelplatz 43 – Mehrplatz 43

Lizenzbedarf Server, ermitteln 376Lizenzbestand Server, ermitteln 376Lizenzeigenschaften, Microsoft (Beschreibung)

387Lizenzform 501 – Erläuterung 23 – Übersicht 26

Lizenzierung – Lizenzmobilität 386 – Oracle Database Enterprise Edition (Beispiel) 404

– Server-Optimierung 415 – Server-Paradigmenwechsel (Praxisbeispiel, Oracle) 416

– Server-Umgebung 374 – Sub-Capacity Beispiel (IBM) 412 – WebSphere Application Server (Vorgehen) 408

Lizenzierungsparameter – dynamische Veränderung durch Virtuali-sierung 382

Lizenzinventar 502 – Aufbau 215 – Aufbau in Excel 217 – Bestelldaten identifizieren 219 – erforderliche Daten 216 – Historisierung 224 – Indiz 221 – Lizenzkanal Beschreibung 221 – Lizenznachweise qualifizieren 222 – Lizenznachweise sammeln 220 – Vertragsdaten identifizieren 217 – Vorgehen bei Recherchen 219 – Was ist ein Lizenznachweis? 221 – Was ist kein Lizenznachweis? 223

Lizenz-Key 502Lizenzklasse 502 – AddOn 44 – AddOn-Upgrade 44 – Beschreibung 43 – CAL 44

– CAL-Upgrade 44 – Cross-Upgrade 44 – Übersicht 44 – Update 44 – Upgrade 44 – Vollversion 44

Lizenzkonformität – Stufe 1, aktive Unterstützung 354 – Stufe 2, proaktive Unterstützung 356 – Stufe 3, optimierte Unterstützung 357

Lizenzkostenvergleich in einem virtualisierten Umfeld 418

Lizenzmanagement 502 – allgemeine Ziele 8, 79 – als Funktion der IT-Architektur 350 – Ausblick und Trends 17 – Aussichten für Cloud-Umgebung 445 – Begriffsdefinition 3 – Cloud-Computing 425 – Darstellung der Ist-Situation (Stufe 1) 110 – die Zehn Regeln 75 – Dokumentation der Ist-Situation 116 – Einbindung in die Unternehmensarchitektur 342

– Einhaltung der Rechtmäßigkeit 14 – Einordnung zu ITIL® 155 – Entwicklungsstufen 146, 428 – Entwicklungstrend 445 – Funktion der IT-Architektur 350 – Herausforderungen für den Cloud-Betrieb 441 – Inhalt und Mehrwert 147 – Integration in ITIL® 156 – in virtuellen Umgebungen 442 – Ist-Situation dokumentieren 109 – kaufmännische Prozesse 113 – kaufmännische Prozesse, Fragen 113 – Meilensteinplan 97 – Nutzen 80 – organisatorische Einbettung 104 – Phasenmodell 96 – Potenzial und Nutzen 15 – Projektphasen und Meilensteine 95 – Rechtmäßigkeit gewährleisten 13 – Richtlinien 115 – Risiken 87 – Risiken und Chancen 5 – Risikoeinschätzung zur Ist-Situation 111 – Roadmap 94 – Rollen definieren 104, 115, 161 – Rollen und Verantwortlichkeiten 80

514 Index

– Schnittstellen 148 – Softwarenutzung als Qualitätsverbesserung 17 – Soll-Prozesse modellieren 144 – strategisches vs. operatives 450 – technische Prozesse 114 – Überblick der Ist- und Soll-Situation 111 – Übersicht KPIs 157 – Unterschiede in Client- und Server- Umgebungen 376

– Welche Fragen sind zu stellen 6 – Welchen Nutzen gibt es 15 – Welche Risiken gibt es 13 – Welches Potenzial gibt es 15 – Werkzeug, Server 421 – Wie Compliance herstellen 11 – Wie Kosten senken 10 – Wie Transparenz schaffen 9 – Wo verorten? 7 – Zeitraum bestimmen 94 – Ziele zur Compliance 9 – Ziele zur Kostensenkung 8 – Ziele zur Rechtmäßigkeit 9 – Ziele zur Transparenz 8 – Zielsetzung neue Prozesse 146 – Zielvorgaben aus dem Management 8

Lizenzmanagement-Tool – Anforderungen formulieren 281 – Angebote bewerten 285 – Aufstellung von Herstellern (Beispiel) 284 – Ausschreibung vorbereiten 272 – Auswahl Hersteller und Beschreibung 494 – erforderliche Mindestfunktionen 278 – evaluieren, Wirtschaftlichkeitsbetrachtung erstellen 278

– implementieren 289 – implementieren, Implementierungsplan erstellen 293

– implementieren, organisatorische Maß-nahmen (Auftraggeber) 290

– implementieren, organisatorische Maß-nahmen (Auftragnehmer) 292

– implementieren, technische Maßnahmen (Auftraggeber) 291

– implementieren, technische Maßnahmen (Auftragnehmer) 292

– implementieren, Testphase durchführen 294 – implementieren, Voraussetzungen schaffen (Auftraggeber) 290

– implementieren, Voraussetzung schaffen (Auftragnehmer) 292

– Proof of Concept durchführen 286 – Tipps zur Anbieterwahl 283 – weitere Kriterien 282 – Zusammenfassung von Informationen 307

Lizenzmanager – operativ 502 – strategisch 502

Lizenzmetrik 13, 502 – Beschreibung 45 – ConcurrentUse 500 – und Maßeinheiten, Übersicht 47 f. – Ermittlung der PVU-Werte 408 f. – Floating License 47 – Floating License siehe auch Concurrent Use 500

– Full-Capacity (IBM) 408 – LPAR (IBM) 413 – LPAR pro CPU 503 – Microsoft-Server-CAL-Lizenzierung 388 – MIPS 46 – Multiplexing (Oracle) 402 – nach Prozessor 376 – Named User 47, 503 – Named User Plus (NUP) (Oracle) 392, 402, 405

– non-human operated device (Oracle) 403 – per Node 47, 503 – pro CI 48, 503 – pro CPU 48, 503 – pro Gerät 47, 504 – pro MIPS 48, 504 – pro MSU 48, 504 – pro Nutzer 47, 504 – pro PVU 48, 504 – pro Seite 48, 504 – pro Session 48, 504 – pro Transaktion 48, 504 – Prozessorlizenz PL (Oracle) 392 – PVU IBM (Werte ermitteln) 408 – PVU (Processor Value Unit) 46 – PVU-Werte (Sub-Capacity-Betrieb) ermitteln (IBM) 407, 409

Lizenzmetrik Server – pro Core 385 – Prozessor/CAL 385 – Server/CAL 385

Lizenzmetrik \„Singlecore-Prozessoren\“ bei Oracle-Produkten 360

– standortgebunden (bzw. per Site) 49, 505 – vCPU (IBM Virtual CPU) 413

Index 515

– Virtual Core für PVU-Lizenzierung (IBM) 412 – volumengebunden 49, 507 – Wachstum pro Jahr in Prozent 507 – zeitgebunden 49, 507

Lizenzmobilität 386Lizenzmodell 13, 502 – Beispielszenario (Oracle) 394 – Beschreibung 41 – Core-Lizenzierung 390 – Hard Partitioning (Oracle) 393 – IBM Ressourcen Value Unit (RVU) 408 – Lizenz pro Gerät 13 – Lizenz pro Nutzer 13 – Microsoft, Oracle und IBM 385 – Microsoft SQL Server 386 – \„Named User Plus\“ anwenden (Oracle) 405

– neue Lizenzmetriken (Microsoft) 389 – nicht benutzerbedientes Gerät, als Named User Plus (NUP) 402

– On-Premise (Definition) 18 – Oracle 392 – Oracle mit einer VM-Installation 396 – Oracle zusätzliche Funktionen und Optionen 399

– Processor Value Unit (PVU) (IBM) 407 – \„Prozessorlizenz\“ anwenden (Oracle) 405

– Prozessorlizenzen in einem Server-Cluster mit VCenter 5.1 396

– Soft Partitioning (Oracle) 393 – Sub-Capacity (IBM) 407

Lizenznachweis 502 – Anforderungen der Hersteller 223 – Relevanz und Auditierbarkeit 222

Lizenz-Pool 502Lizenzrechtlich lesbare Softwareprodukte 377Lizenzreport 502 – Compliance-Report Aufgaben 306 – Compliance-Report Auslöser 307 – Compliance-Report (Übersicht) 306 – Eintrittsereignisse 309 – kaufmännisch 304 – Lizenzdaten ermitteln 303 – Maßnahmenkatalog erstellen 309 – Optimierung 311 – Reports im Lizenzmanagement 304 – Snow License Manager Tool (Beispiel) 307 – technisch 304

Lizenz siehe auch Nutzungsrecht 13

Lizenztyp 502 – Beschreibung 45 – Übersicht 45

Lizenzübertragung, an Dritte 57Lizenzvertrag 502 – Beschreibung 37 – Verbot der kurzfristigen Neuzuweisung 386 – verwenden 42

LzM (Lizenzmanager) 503

MMaintenance 503Master Agreement 503Medium 503Mehrfachkopien 469Meilenstein 503Meilensteinplan Klassifizierungsprojekt

(Beispiel) 257Memorandum of Understanding, Dokument zur

Abgrenzung von Aufgaben 272, 503Microsoft Enterprise Agreement (EA) 389Microsoft Executive Briefing (EBC) 391Microsoft SQL Server 2012, Unterschiede in der

Lizenzierung 390Microsoft-Lizenzierung, weitere Quellen 371,

387Microsoft-Product-Licensing-Website 371Microsoft-Produktbenutzungsrechte (Weblink)

390Microsoft-Produktlisten (Weblink) 391Microsoft-Produktlizenzierung (Weblink) 391Microsoft-Server, Zuweisungspflicht 388Microsoft-Volume-Licensing-Website 371Microsoft-Volumenlizenzprogramm (Weblink)

391Mindestbenutzerzahlen – anzuwenden bei der Lizenzierung mit Named User Plus 403 f.

Mindestlizenzierung von Named User Plus (Oracle) 403

MoU-Dokument, Inhaltsaufstellung 286

NNicht besitzanzeigende Verträge 503Nichtdeterministisch, polynomiell 388Norm ISO/IEC 19770-2 234NUP-Lizenzen, Vorgehen zur Mengenbestimmung

404

516 Index

Nutzungsrecht 22 – bzw. kaufmännische Lizenz 4 – siehe Lizenz 13

Nutzungsübersicht für Microsoft Project (Praxisbeispiel) 333

OObjekttyp 503OEM siehe Original Equipment Manufacturer

28OEM-Lizenzen 503OEM-Software, Definition 35Online-Portale, Microsoft, IBM 474Open Source Initiative siehe OSI 25Open Source siehe auch Freie Software 25Open-Source-Software 503Operativer Lizenzmanager 503 – Aufgaben 165 – fachliche Kompetenzen 166 – Rollenbeschreibung 164 – soziale Kompetenzen 166 – Umfragewerte zur Rolle 465

Operatives Lizenzmanagement 449 – administrative Komponenten 452 – Aspekte und Komponenten 451 – emotionaler Aspekt 452 – kaufmännische Komponenten 454 – lizenzrechtliche Komponenten 454 – politischer Aspekt 452 – rationaler Aspekt 452 – Rolle Lizenzverwalter 459 – Rolle Materialstammdatenpfleger 464 – Rollenbild Lizenzmanager 465 – Rolle Software-Katalogmanager 460 – Rolle Softwareverteiler 462 – Rolle Softwarewarenkorb-Verantwortlicher 461 – Rolle Zentraler Archivverantwortlicher 463 – Schnittstellen 456 f. – technische Komponenten 453 – weitere Rollen 459

Optimales Lizenzmodell – Ermitteln (Beispielszenario) 344

Optimierungsansätze Lizenzmanagement, Aufzählung 145

Oracle – Interne Verwaltungstabellen 398 – Server-Lizenzierung 392 – Überblick genutzte technische Funktionen 399 f.

– Was wird lizenziert? 395 – Zusätzliche Optionen & Funktionspacks 397

Oracle-Datenbankinstanz – Parameter (Beispiele) 400

Oracle-Komponenten lizenzieren, Schritte 400Oracle License and Service Agreement

(Weblink) 406Oracle License and Service Agreement (OLSA)

392Oracle License Management Services (Weblink)

406Oracle-Lizenzierung, Stolperfallen 401Oracle-LMS-Team (License Management

Services) 392Oracle Partitioning Policy, Informationen

(Weblink) 393Oracle-Prozessorfaktor, aktuelle Liste (Weblink)

395Oracle-Prozessortabelle (Auszug) 396Oracle Software Delivery Cloud (Weblink) 406Oracle Software Investment Guide (Weblink)

406Organigramm Lizenzmanagementrollen,

Verteilung 162Organisation und Prozesse – detailliertere Darstellung 112

OSI siehe Open Source Initiative 25

PPartitioning Option (Oracle) 397Periodizität 503Pflichtenheft 503 – Anforderung prüfen 264 – Beschreibung 263 – Definition 263

Physikalische CPUs – Anzal ermitteln 369

Platform-as-a-Service (PaaS) 434PoC – Aufstellung von Testfällen 287 – Funktionsorientierte Tests 287 – Gliederung Testkonzept 287 – Negativtest 288 – Positivtest 288 – Prozessorientierte Tests 287

Portfolio-Analyse – Auswertung (Beispiel) 280

Praxisbeispiel zur ISO/IEC 19770-1, Tier1-4 139Private Cloud 432

Index 517

Product User Rights siehe PUR 37Produktmanipulationen 470Produktnutzungsrecht, universell 39Produktverantwortlicher (Softwareexperte) 504 – Aufgaben 167 – fachliche Kompetenzen 168 – Rollenbeschreibung 167 – soziale Kompetenzen 168

Projektauftrag – erstellen 77 – Ziele formulieren 77

Projektdurchführung – Aktivitätenplan 90

Projektleiter, Rollenbeschreibung 81Projektmitarbeiter, Rollenbeschreibung 82Projektorganisation 80Projektphasen – einer Softwarenutzungsanalyse 324 – Fertigstellungsgrade 102

Projektplan aufstellen – Stufen der Umsetzung für ein Lizenzmanage-ment 16

– Qualitätsanspruch 91 – Umfang beschreiben 90

Projekt-Roadmap, definieren 94Projektstrukturplan, Übersicht 99Projektziele – beschreiben 91 – Rahmenbedingungen 92

Proof of Concept 504proprietäre Software, Erläuterung 23Prozess „Anforderung“, Beschreibung der

Ist-Situation 117Prozess-Assessment 504Prozessablauf – Anforderung aus Softwarewarenkorb 150 – Compliance-Report 153 – Deinstallation Software 152 – kaufmännische Übersicht 121 – „Neue Software anfordern“, grobe Darstellung 150

– technische Übersicht 121 – Weiterverrechnung Kosten 151

Prozesserfüllungsgrade, Merkmale und Stufen 132

Prozessmanagement und -schnittstellen, KPI 157Prozessor – Einordnung in einer grafischen PVU-Tabelle (IBM), Weblink 409

– Leitfaden zur Bestimmung (IBM), Weblink 409

Prozessortabelle – Oracle 395

Prozessortechnologie für Sub-Capacity-Lizen-zierung bestimmen

– IBM 410Prozess-Schritt Reporting &Analyse – Soll-Prozess 310

Prozess-Situation, Übersicht der Änderungen 145

Public Cloud 432PUR, Product Use Rights (Microsoft) 344, 385 – ausgeführte Instanz Beschreibung (Microsoft) 386

– Auszug Universelle Lizenzbestimmungen (Microsoft) 386

– Instanzen erstellen und speichern (Definition) (Microsoft) 387

PVU-Tabelle (IBM) 407PVU-Werte, Online-Kalkulator (IBM), Weblink

409

QQuellsysteme, Datenbereinigung 103

RRACI 504Rahmenvertrag 504Rangliste der Anwendungshersteller – Übersicht (Beispiel) 308

Raubkopien und Fälschungen 469Rechtswidrige Nutzung – Beispiele 471 – Formen 469

Regeldatei 504Reifegradanalyse – Benchmarking 130 – nach CMMI, Beispielergebnis 134

Reifegradbestimmung – CMMI-Modell 131 – ISO/IEC 19770-1 134

Reifegradmodell – CMM, CMMI 130 – Erläuterung 130

Reifegradstatus – nach ISO/IEC 19770-1, Darstellung der vier SAM-Stufen 142

– nach ISO/IEC 19770-1, Gesamtergebnis 138Reifegradstufen, Beschreibung 135

518 Index

Re-Imaging 28Report (Daten) 504Request of Proposal (ROP) 505 – Angebotsabgabe 272 – Gliederung (Beispiel) 273 – Teilnahmebedingungen (Beispiel) 274

Richtlinien – Erstellen 170 – Umgang mit Software 169

Risikomanagementsystem siehe RMS 56Rolle Auftraggeber 81Rolle Experte 84Rolle Lenkungskreis 83Rolle Lizenzverwalter – Aufgaben 459 – fachliche Kompetenzen 460 – soziale Kompetenzen 460

Rolle Materialstammdatenpfleger – Aufgaben 464 – fachliche Kompetenzen 464 – soziale Kompetenzen 464

Rolle im Lizenzmanagement, definieren 80, 104

Rolle Projektleiter 81Rolle Projektmitarbeiter 82Rolle Software-Katalogmanager – Aufgaben 460 – fachliche Kompetenzen 461 – soziale Kompetenzen 461

Rolle Softwarewarenkorb-Verantwortlicher – Aufgaben 461 – fachliche Kompetenzen 462 – soziale Kompetenzen 462

Rolle Softwarewareverteiler – Aufgaben 462 – fachliche Kompetenzen 463 – soziale Kompetenzen 463

Rolle Sponsor 85Rolle Zentraler Archivverantwortlicher – Aufgaben 463 – fachliche Kompetenzen 464 – soziale Kompetenzen 464

SSaaS – Software as a Service 17SAP-Betrieb, Tipps (Weblink)\“. 483SB – System-Builder-Software, Definition 35Scan-Schnittstellen – Übersicht 233

Schichtenmodell IT-Architektur 343Server 505Serverdaten – Grundszenario für das Erfassen 352

Server-Hardware, Parameter ermitteln 379Server-Host (physikalischer Server) 380Server-Lizenzierung – Hardwaremerkmale 379

Server-Lizenzierung (IBM) 406Server-Lizenzierung, Microsoft 385Server-Software – identifizieren 378 – Lizenzmodelle der wichtigsten Hersteller 385 – lizenzrelevante Parameter 377

Server-Umgebungen, Kontextinformationen ermitteln 379

Servicebereitsteller (Cloud) – Nachteile 435 – Vorteile 434

Servicekategorie 1, Beschreibung 253Servicekategorie 2, Beschreibung 253Servicekategorie 3, Beschreibung 253Servicekategorien – Einteilungsmatrix 254

Servicemodelle, prozentuale Verteilung 436Servicenehmer (Cloud) – Nachteile 435 – Vorteile 435

Shareware 505 – Definition 24

Sicherungskopie erstellen 51SKU (Stock Keeping Unit) 505SLA 505SMART-Faktoren, die fünf Kriterien 78 f.Software 505 – falsch lizenziert 469 – gebraucht 56 – rechtswidrige Nutzung 486 – unlizenziert 30, 469 – unterlizenziert 469 – verwalten und managen 61 – Warum virtualisieren? 330

Software Assurance für Volumenlizenzierung (Weblink) 391

Softwareanforderer 505 – Definition 176

Softwareanforderung, auslösen 177Softwareanforderungsprozess 505 – beispielhafte Darstellung 178 – Übersicht 176

Index 519

Software-as-a-Service (SaaS) 434Softwareasset- und Lizenzmanagement – Tools und Hersteller 495

Software-Audit – Ablauf 479 – abschließende Maßnahmen 488 – Adobe 483 – Anwenderwissen 475 – Bestandteile und Arten von Lizenznachweisen 486

– erforderliche Informationen 485 – gültiger Lizenznachweis 486 – IBM 483 – Klauseln 477 – Lizenznachweise Adobe 487 – Lizenznachweise IBM 487 – Lizenznachweise Microsoft 486 – Lizenznachweise Oracle 487 – Microsoft 483 – Oracle 483 – Rechtliches 472 – rechtswidrige Nutzung 469 – SAP 483 – Schwierigkeiten der Hersteller 474 – vorbereiten 484 – Was kommt nach dem Audit? 488

Softwarebeschaffungen, Formen 181, 182Softwarebestellprozess 505 – beispielhafte Darstellung 180 – Beschreibung 179

Softwaredaten – kaufmännische Bestandsaufnahme 209

Software Identification (SWID)-Tags nach der Norm ISO 19770 – 2 201

Softwarekatalog – Aufbau 63 – erforderliche Daten 63

Softwarekategorien, Überblick 154 – Softwarekategorie, Kategorie 1 154 – Softwarekategorie, Kategorie 2 154 – Softwarekategorie, Kategorie 3 155

Softwareklassen (SwKl) – Einteilung nach Best Practice 247, 248

Softwareklassifizierung – Aufwandskategorien 255 – Ausgangssituation 242 – Beispiel 241 – Definition 239 – eCl@ss 243 – Fragen 241

– Geräteklassen 248 – Projekt planen 256 – Prozessablauf (Beispiel) 249 – Servicekategorien beschreiben 252 – Servicekategorien einteilen 254 – Softwareklassen (Definition) 247 – Softwarenutzung definieren 250 – strategisch 246 – Supportstufen 254 – Warum klassifizieren? 240 – Ziele 242

Softwareleasing als neues Modell 19Software-Life-Cycle-Prozess – Beschreibung Hauptprozesse 121 – Aufstellung der Hauptprozesse 112 – optimieren 143 – Probleme bei der Analyse 125 – Prozessaufgaben 124 – Schnittstellen (KPI) 158 – Schnittstellen 122 – Überblick 120 – Übersicht Ansprechpartner 113 – Übersicht der Teilprozesse 121 – Übersicht der Teilprozesse in Verantwortung des Lizenzmanagements 123

Softwareliste 505Softwarelizenz 501, 505 – Begriffsklärung 22 – kaufmännisch 32 – typische Unternehmenssituation 27 – Übertragung aus einem Microsoft Vertrag 59

Softwarelizenz siehe auch Nutzungsrecht 22Softwarelizenzkosten optimieren – Maßnahmen 420 – Softwarenutzungsanalyse 419 – Vorgehen 419

Software Metering (Softwarenutzungsanalyse) 505

– Übersicht von Messmethoden 320Softwarenutzung – Auswirkungen 318 – Beispiele aus dem Projektgeschäft 315 – Einsparpotenziale 323 – Faktoren 317 – IT-Bestände identifizieren 316 – Lizenzen managen 315 – Praxisbeispiele 325 – Praxismethoden und Ergebnisse 318 – rechtliche Bestimmungen 50

520 Index

Softwarenutzungsanalyse – Beispiel Microsoft Office Standard und Pro-fessional 322

– grober zeitlicher Projektablaufplan 325 – Übersicht Projektphasen 324 – Was wird gemessen? 323

Softwarepaket, Bestandteile der Verkaufsver-packung 34

Software-Pool 502Softwareportfolio 505 – Beschreibung 66 – Informationsbestandteile 64

Softwareprodukte – Bestandsaufnahme in der klassischen PC-Umgebung 188

– Bestandsaufnahme in Server-Umgebungen 188

– in Cloud-Umgebungen, neue Verbrauchs-modelle 19

– technische Bestandsaufnahme 187 – Übersicht der Nutzung 317 – Verteilung 62

Softwarevirtualisierung – Arten von Virtualisierungsumgebungen 334 – Auswirkungen 336 – Grundlagen 333 – Kernfragen 331 – mögliche Konzepte 335 – Nachteile 334 – Voraussetzungen schaffen 331 – Vorgehen 329 – Vorteile 336

Softwarewarenkorb 68, 505Soll-Prozess, Gesamtübersicht 149SOX 55Sponsor, Rollenbeschreibung 85Standardanwendungen – Beschreibung 250 – optionale Fachbereichsanwendungen 251 – spezifische Fachbereichsanwendungen 250

Strategische Softwareklassen 505Strategischer Lizenzmanager (StLM) 505 – Aufgaben 163 – fachliche Kompetenzen 164 – Rollenbeschreibung 163 – soziale Kompetenzen 164

Studie IT-Lohnkosten, KPMG 317Sub Capacity, Beschreibung 361Sub-Capacity-Lizenzbedingungen (IBM), Anlage

411

Sub-Capacity-Produkte (IBM), Beispielprüf-bericht 412

Sub-Capacity-Umgebungen – Ausnahmen 411 – Bedingungen 411 – Voraussetzungen (IBM) 410

Subcaplicensing (IBM), Weblink 411Supportstufen 505System Builder Software 506Systeminformation, Windows-Oberfläche 204Szenario 2\ – Microsoft-Office-Lizenzierung in einer Citrix-Umgebung 365

TTatsächliche Softwarenutzung – Auswertung (Praxisbeispiel) 321

Technische Bestandsaufnahme, Vorgehen und Planung 189

Technische Datenbereinigung – Planung 232

Technische und kaufmännische Daten – Szenarien zur Erhebung 207

Technischer Report 506Teilprozess, Bedarfsmeldung managen 133Testablauf – Abnahmespezifikation erstellen 300 – Rahmenbedingungen formulieren 299 – schematische Darstellung 299

Testbedarfsmeldung, Inhaltsbeschreibung (Beispiel) 297

Testbericht erstellen, Beispiel 298Testdokumentation 506Testdokumente nach ANSI/IEEE – Übersicht 296

Testdurchführung – Ablaufplan (Beispiel) 300

Testkonzept, Gliederung (PoC) 287Testlizenz 506Testprozess 506Testvorschrift – Ablauf 297 – Aufbau und Gliederung 296

The Cloud (Wolke) 18Theory of PVU Licenses (IBM Developer Blog),

Weblink 409TNSListener (Transparent Network Substrat) 401Toolauswahl, Anforderungsbeschreibung 101Tuning Pack (Oracle) 398

Index 521

UÜberlizenzierung 506 – Definition 27

Übertragung von FPP, OEM, Schulversionen 58Umgang mit Software – Richtlinien 169

Universelle Lizenzbestimmungen, Auszug Microsoft Volumenlizenz 39

Universelles Produktnutzungsrecht 506Unlizenzierte Software 469Unterlizenzierte Software 469Unterlizenzierung 506 – Definition 29

Update 506Upgrade 506Urheberrecht (UrhG) 506 – Beschreibung 51

Urheberrechtsgesetz (UrhG) 469 – Ansprüche des Herstellers 53

VVerhältnis zwischen der Anzahl von Anwendun-

gen und der Softwarenutzung 320Verkauf von gebrauchter Software, Hinweise

471Vertragsart 506Vertragsdatenbank, Aufbau 103Vertragsdaten – Fragen 218 – Komplexitätstreiber 218

Vertragsmanagement – Daten aus SAP (Beispiel) 214 – erforderliche Lizenzinformationen 213 – Nutzen 210 – spezifische Daten 212 – Vertragsformen 211 – Voraussetzung schaffen 213 – wichtige Punkte 210 – zu erfassende Daten 212

Vertriebskanalmissbrauch 471Vervielfältigungsrecht 51Virtual Desktops Infrastructure (VDI) 329Virtualisierte Umgebung – Nutzungsformen 441

Virtualisierung – im IBM-Umfeld, Aspekte 413 – mit Microsoft-Produkten (Weblink) 391 – Power VM (IBM) 383

Virtualisierungskapazität 387

Virtualisierungstechnologie Power VM (IBM) 414

Virtualisierungsumgebung, Definition (IBM) 410Virtuell Desktop Infrastuktur Lizenzabdeckung – Detaildarstellung einer Compliance-Berech-nung 309

Virtuelle Instanzen – Ermitteln der Anzahl 370

VMware, VMotion 383Vollprodukt 507Vollversion 507Volumenvertrag 59

WWartung 507WiBe Wirtschaftlichkeitsbetrachtung 278Windows Server 2012, Lizenzberechnung für

Installationsszenarien 369Windows Server 2012 R2 – Lizenzierungsberechnung (Beispiel) 370 – Lizenzierung 366 – Unterschiede der Editionen und Virtualisie-rungsrechte 368

– Überblick Downgrade-Rechte 368 – Überblick Lizenzmodell 367

Windows-Server-2012-Datacenter-Edition – Wie viele Lizenzen sind erforderlich? 371

Wirtschaftlichkeitsbetrachtung (WiBe) 278, 507 – Ergebnisse 281

Wolke – The Cloud (Beschreibung) 18Work-at-home siehe auch Zweitkopie 46

YY-Modell des Lizenzmanagements 12

ZZivilrechtliches Besichtigungsrecht 472Zugriff über das Internet – grober Bebauungsplan 345

Zweitkopie siehe auch Work-at-home 46

Leseprobe Torsten Groll - bücher.de · 2018. 7. 2. · 20.5.1 Szenario 1 IBM-Lizenzierung ........

Documents

Transcript of Leseprobe Torsten Groll - bücher.de · 2018. 7. 2. · 20.5.1 Szenario 1 IBM-Lizenzierung ........