Leseprobe „1x1 des Lizenzmanagements“Leseprobe . zu „1x1 des Lizenzmanagements“ von Torsten...

Leseprobe zu

„1x1 des Lizenzmanagements“

von Torsten Groll

Print-ISBN: 978-3-446-44392-1 E-Book-ISBN: 978-3-446-44426-3

Weitere Informationen und 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?

24In diesem Kapitel erfahren Sie u. a.: � welche Faktoren eine rechtswidrige Nutzung von Software beschreiben, � welche rechtlichen Aspekte im Umfeld eines Software-Audits auftreten, � welche Schwierigkeiten die Hersteller bei der Durchsetzung eines Software- Audits haben und was Sie als Anwender dazu wissen sollten,

� welche Bestandteile eine Audit-Klausel in einem Software- oder Lizenzvertrag haben sollte,

� wie ein Software-Audit abläuft und welche Daten und Informationen dafür benötigt werden,

� welche Verhaltensregeln bei der Durchführung eines Software-Audits zu beach-ten sind,

� aus welchen Bestandteilen ein gültiger Lizenznachweis im Allgemeinen besteht, � wie es nach einem überstandenen Audit weitergeht.

Dieses Kapitel gibt einen ersten Einblick in das umfangreiche und komplexe The-ma „Software-Audit“. Neben einem kurzen Überblick über die möglichen Formen rechtswidriger Nutzung von Software geht das Kapitel auch darauf ein, welche rechtlichen Aspekte zu beachten sind (in Deutschland), welche Informationen die Grundlage für einen Software-Audit bilden und wie ein Software-Audit üblicher-weise abläuft. Aufgrund sehr unterschiedlicher Techniken und Vor gehensweisen der Hersteller kann das Kapitel nicht konkret auf bestimmte Software-Audit-Abläufe einzelner Hersteller eingehen. Zum Schluss gibt es noch Best-Practise-Empfehlungen für Aufgaben, die nach einem Software-Audit noch zu erledigen sind.

Software-Audit

468 24 Software-Audit

HaftungsausschlussDie in diesem Kapitel beschriebenen Sachverhalte, Anmerkungen und Empfeh-lungen erheben keinen Anspruch auf Vollständigkeit und bilden keine von mir formulierte Rechtsmeinung ab. Auszüge von Rechtsmeinungen oder Zitate sind immer mit der jeweiligen Quelle gekennzeichnet. Es werden keine Garantien und Haftungen bzgl. der Allgemeingültigkeit und/oder rechtlichen Korrektheit der hier beschriebenen Inhalte übernommen. Dieses Kapitel stellt keine Rechts-beratung dar. Wenn Sie rechtliche Beratung benötigen, wenden Sie sich bitte an eine darauf spezialisierte Rechtsanwaltskanzlei. Die im Kapitel genannten Web-links aus dem Internet wurden im Mai 2015 aufgerufen und waren zu diesem Zeitpunkt noch als Quelle verfügbar.

Seit vielen Jahren untersucht die BSA (Business Software Allianz) zusammen mit IDC1 (IDC ist ein führender Anbieter von Marktinformationen) den Anteil der weltweiten illegalen und unlizenzierten Softwareinstallationen. Die Zahlen zur Studie „The Compliance Gap, BSA Global Software Survey“ (veröffentlicht im Juni 2014)2, 3 sprechen leider immer noch eine deutliche Sprache: 43 % der in 2013 auf der Welt installierten und genutzten Soft-ware war nicht korrekt lizenziert. Die Studie hat bei der Befragung von IT-Verantwortlichen weiterhin ergeben, dass in nur ca. 35 % der Unternehmen Richtlinien und Vorgaben zur lizenzkon formen Nutzung von Software bestehen. Hier müssen also weiterhin die verant-wortlichen Personen eine verstärkte Bildung und Aufklärung über die Einhaltung des geis-tigen Eigentums erhalten. Eine verbesserte Verwaltung und Optimierung der eingesetzten Softwareprodukte kann zudem mit Hilfe darauf ausgerichteter Geschäfts- und Software-Life-Cycle-Prozesse erreicht werden. Der in der BSA-Studie erhobene Durchschnittswert von unlizenzierter Software liegt bei 62 % für den asiatisch-pazifischen Raum, bei 61 % für den Raum Zentral- und Osteuropa, im lateinamerikanischen Raum sowie im Mittleren Osten und Afrika liegt die Rate bei 59 %. Das westliche Europa liegt mit 29 % auf dem vorletzten Platz, die mit 19 % niedrigste Rate hat Nordamerika vorzuweisen.In der Studie ergab sich auch, dass laut Selbstauskunft von 100 deutschen Software-anwendern ca. 66 keine unlizenzierten Softwareprodukte einsetzen. Es sind also immer noch 34 von 100, die ihre aktiven Softwareanwendungen nicht lizenzkonform betreiben oder unlizenziert im Einsatz haben. Ein kleiner Lichtblick im Kampf gegen die zunehmende Verbreitung unlizenzierter Software ist der rasante Zuwachs bei neuen Technologien, wie beispielsweise bei Tablet-Computern. Hier wurde ein Zuwachs um 80 % auf ca. 80 Millionen eingesetzte Tablets verzeichnet und das führt damit ein Stück weit auch zum Rückgang von nicht lizenzkonform eingesetzten Softwareprodukten. Die ebenfalls stetig steigende Nut-zung von „Software-as-a-Service (SaaS)“ macht allerdings auch erst einmal nur 1 % Anteil an der gesamten im Einsatz befindlichen Software aus4 und konnte die Datenlage von illegal genutzter Software nicht spürbar nach unten korrigieren. Aber was bedeutet eigentlich die Aussage, wenn Software unlizenziert genutzt wird?

1 http://www.idc.com2 http://globalstudy.bsa.org/2013/index.html3 http://globalstudy.bsa.org/2013/downloads/studies/2013GlobalSurvey_Study_en.pdf4 http://globalstudy.bsa.org/2011/downloads/press/pr_germany_de.pdf

http://www.idc.com

http://globalstudy.bsa.org/2013/index.html

http://globalstudy.bsa.org/2013/downloads/studies/2013GlobalSurvey_Study_en.pdf

http://globalstudy.bsa.org/2011/downloads/press/pr_germany_de.pdf

24.1 Rechtswidrige Nutzung von Software 469

■■ 24.1■ Rechtswidrige Nutzung von Software

Seit dem 9. Juni 1993 müssen die Paragrafen des Urheberrechtsgesetzes (UrhG) auch auf Software und deren Nutzungsrechte angewendet werden. Die Aufnahme von Software in das UrhG soll vor allem den Urheber und sein Werk vor unerlaubter Vervielfältigung schüt-zen und ist bspw. im Paragraf 69c UrhG beschrieben. Um eine unerlaubte Vervielfältigung oder rechtswidrige Nutzung nachzuweisen, muss erst einmal beschrieben werden, was eine rechtswidrige Nutzung ausmacht.Formen der rechtswidrigen Nutzung sind:

� Un-lizenzierte Software Es wird Software verwendet und eingesetzt, für die überhaupt keine rechtmäßige Lizenz erworben wurde.

� Unter-lizenzierte Software Eine wiederholte Installation von Software, die den vereinbarten Nutzungsumfang über-schreitet (z. B. ein Softwarepaket über eine automatisierte Softwareverteilung ohne Prü-fung auf ausreichend vorhandene kaufmännische Nutzungsrechte), erzeugt eine Unter-lizenzierung und stellt somit eine rechtswidrige Nutzung des Softwareprodukts dar.

� Falsch lizenzierte Software Die Software wird für Zwecke eingesetzt, die nicht von den im Vertrag festgelegten Nut-zungsvereinbarungen abgedeckt sind (z. B. der Einsatz von Software mit temporären Lizenzkeys, oder Testlizenzen – z. B. in einer produktiven Umgebung). Um eine rechts-widrige Nutzung handelt es sich auch, wenn eine Software in einem IT-Architektur-Sze-nario falsch eingesetzt wird oder Funktionen genutzt werden, die nicht lizenziert wurden. Das ist sehr oft beim Einsatz von Oracle-Datenbanken der Fall (falsche Edition, oder es werden Funktionen bei der Installation zusätzlich mit ausgewählt, die dann eine Lizenz-pflicht auslösen) oder z. B. wenn Server-Betriebssysteme in Verbindung mit einer Virtu-alisierungsumgebung falsch eingesetzt werden (siehe dazu auch Kapitel 20.5 „Beispiels-zenarien von IT-Architekturen“).

� Mehrfachkopien Es werden mehr Kopien von Originalmedien erstellt, als erlaubt ist, und mehrfach auf unterschiedlichen PCs installiert, oder ein einzelner Lizenzkey wird für mehrere Installa-tionen verwendet (siehe auch Unterlizenzierung).

� Raubkopien und Fälschungen Komplette Softwarepakete werden gefälscht und als Originalsoftware verkauft. Wer ein solches Produkt installiert, nutzt die Software rechtswidrig.

In vielen Fällen ist es für den Laien nur sehr schwer erkennbar, ob er es mit einer Fälschung zu tun hat, weil die Methoden der Fälscher immer besser werden. Microsoft bietet Informationen dazu über den folgenden Weblink an:http://www.microsoft.com/de-de/howtotell/default.aspxAußerdem stellt Microsoft auch eine Webseite zur Überprüfung von Produkt-merkmalen „Microsoft Produktidentifikationsservice“ (kurz: „PID-Service“) zur Verfügung:

http://www.microsoft.com/de-de/howtotell/default.aspx


https://www.microsoft.com/de-de/rechtliche-hinweise/pidservice.aspxFür Adobe-Produkte können Sie diesen Weblink verwenden:http://www.adobe.com/de/aboutadobe/antipiracy/auctioncaution.html

� Internetpiraterie Im Internet werden immer häufiger Downloads von illegaler Software angeboten, manch-mal auch ganze Webportale von Herstellern gefälscht. Auch stehen oft illegale Kopien über Auktionshäuser oder Hackerforen zum Verkauf. Eine weitere Methode besteht darin, günstige Software über Spam-E-Mails zu offerieren.

� Hard-Disk loading Viele Fachhändler, die Hardware verkaufen, installieren teilweise Software auf den PCs vor und liefern u. U. dem Käufer dazu die erforderlichen rechtmäßigen Lizenzmedien nicht mit aus.

� Produktmanipulationen Werden einzelne Bestandteile von Originalsoftware verkauft, spricht man von Produkt-manipulationen, da die Käufer kein vollständiges Produkt erhalten. Um Manipulation handelt es sich auch, wenn Bestandteile der Originalsoftware mit gefälschten Komponen-ten ergänzt und als komplettes Originalprodukt angeboten werden.Eine weitere, nicht gleich erkennbare Version der Produktmanipulation ist der Vertrieb von Upgrade-Boxen als Vollversionen. Hier sagen die Nutzungsbedingungen ganz klar, dass für die korrekte Nutzung eines Upgrades eine vorhergehende Vollversion als Basis-lizenz vorhanden sein muss. Zudem muss diese auch in derselben Sprache verfasst sein (eine Basislizenz in Englisch und ein Upgrade in deutscher Sprache wären z. B. nicht zulässig, da es sich dabei um keine „Multilanguage Version“ handelt, sondern um zwei eigenständige, lokalisierte Sprachversionen).Adobe weist zurzeit bspw. verstärkt auf sogenannte „Vollversions-Bundle“ hin:„Ein solches Bundle besteht dann nicht aus zwei generischen, zusammengehörigen Lizenzen, sondern lediglich aus einem neueren, meist originalen Upgrade und – als angeblicher Basis-lizenz – entweder aus:

� einer Raubkopie der Programme „Adobe Photoshop 6.0 OEM“ oder „Adobe Photoshop 7.0“ in der oben dargestellten Form,

� einer bloßen Registrierkarte mit aufgeklebter (gefälschter) Seriennummer ohne weitere Bestandteile wie Datenträger, Handbuch und/oder Umverpackung,

� einem bloßen Endbenutzer-Lizenzvertrag mit aufgeklebter (gefälschter) Seriennummer ohne weitere Bestandteile wie Datenträger, Handbuch und/oder Umverpackung, oder

� einer bloßen, auf dem Upgrade-Produkt zusätzlich aufgeklebten (gefälschten) Seriennummer.Letztgenannte Fälschungsart kommt derzeit insbesondere bei dem Produkt „Adobe Photo-shop“ oder dem Produktpaket „Adobe Creative Suite“ vor. Ein solches Bundle verschafft dem Käufer indessen nicht die zur Installation und Nutzung des Upgrades erforderlichen Lizenz-rechte.5

5 Quelle: http://www.adobe.com/de/aboutadobe/antipiracy/auctioncaution.html

https://www.microsoft.com/de-de/rechtliche-hinweise/pidservice.aspx

http://www.adobe.com/de/aboutadobe/antipiracy/auctioncaution.html

http://www.adobe.com/de/aboutadobe/antipiracy/auctioncaution.html

24.1 Rechtswidrige Nutzung von Software 471

� Vertriebskanalmissbrauch Nicht selten werden Vollversionen von originalen Softwareprodukten, die nur für eine besondere Lizenzform Gültigkeit besitzen, als „normale Vollversionen“ weiterverkauft, z. B. Softwareprodukte, die die Kennzeichnung „Not-for-Resale (NFR)“ haben, oder Pro-dukte und Lizenzen, die ausdrücklich nur für Forschung und Lehre eingesetzt werden dürfen (bspw. Campus-Lizenzen).

� Verkauf gebrauchter Software Wenn Sie gebrauchte Software erworben haben und einsetzen, kann das ebenfalls zu rechtswidriger Nutzung führen, z. B. wenn zwar ein Vertrag mit einem Lizenzgeber über eine ausreichende Anzahl von Lizenzen abgeschlossen wurde, aber der Lizenzgeber zur Lizenzerteilung gar nicht berechtigt war. Das passiert oft im Gebrauchtmarkt von Software, wenn beim Kauf/Verkauf nicht auf die Nutzungsbedingungen des Herstellers geachtet wird (z. B. bei Veräußerungen von Volumenlizenzen).

Beispiele rechtswidriger NutzungHier lesen Sie zwei Beispiele von rechtswidriger Softwarenutzung aus der Rubrik „Nach-richten & Termine“(Archiv), die von der BSA (Business Software Alliance) veröffentlicht wurden6.Fall 1: Ein Unternehmen zahlt über 600 000 Euro für den Einsatz unlizenzierter Soft-ware:

„BSA verbucht bislang größten Erfolg in Deutschland München, 14. 8. 2007Die BSA hat ihren bislang größten Ermittlungserfolg gegen die gewerbliche Nutzung un -lizenzierter Software in Deutschland erzielt. Ein überregional tätiger Groß- und Einzelhänd-ler von Bürobedarf und EDV bezahlte insgesamt über 600 000 Euro an Schadensersatz und Lizenzgebühren für illegal verwendete Software. Zusätzlich wurde ein Strafverfahren gegen die Geschäftsführer und den IT-Administrator der Firma erst nach Zahlung einer beträcht-lichen Geldauflage eingestellt. Die zuständige Staatsanwaltschaft hatte nach einer gleichzei-tigen Durchsuchung von acht Niederlassungen der Firma unlizenzierte Software auf über 300 Rechnern im Wert von einer halben Million Euro festgestellt.“ (Auszug aus der Presse-mitteilung der Business Software Alliance vom 14. 08. 2007)

Fall 2: „Geeignete Maßnahmen“ für lizenzierte Software fehlen: Solartechnikfirma zahlt 40 000 Euro Schadensersatz:

„Gericht äußert sich deutlich zur Verantwortung von Geschäftsführern, München, 15. 1. 2009Eine Strafanzeige, 40 000 Euro Schadensersatz, eine Unterlassungsverpflichtung, eine umfassende Auskunftsverpflichtung und im Wiederholungsfall ein Ordnungsgeld von bis zu 250 000 Euro. Dies sind die Folgen für den Einsatz unlizenzierter Software, die einem Solartechnikunternehmen zusätzlich zum Kauf der fehlenden Lizenzen entstehen. Das rechtskräftige Urteil aus zweiter Instanz gegen das Unternehmen und den Geschäftsführer enthält weitreichende Aussagen über die Verantwortlichkeit für Urheberrechtsverletzungen in Firmen und über die Maßnahmen, die von Seiten der Unternehmensleitung ergriffen wer-den müssen. Die Herausgabe von Richtlinien zum Softwareeinsatz und Ermahnungen aus gegebenem Anlass sind nicht genug. Im Gegenteil: ein Geschäftsführer handelt pflichtwidrig,

6 Leider wurde dieser Beitrag von den Webseiten der BSA entfernt.


wenn er nicht sicherstellt, dass Software nur von autorisierten Personen installiert werden darf.“ (Auszug aus der Pressemitteilung der BSA vom 15. 1. 20097)

Weitere Beispiele finden Sie auch hier: � OLG Frankfurt am Main: Übertragung von Softwarelizenzen OLG Frankfurt am Main, Urteil v. 22. 06. 2010, Az. 11 U 13/10; http://www.telemedicus.info/urteile/Urheberrecht/1097-OLG-Frankfurt-am-Main-Az-11-U-1310-UEber tragung-von-Softwarelizenzen.html

� OLG München: Zum Weiterverkauf von Computerprogrammen OLG München, Urteil v. 03. 08. 2006, Az. 6 U 1818/06; http://www.telemedicus.info/urteile/IT-Vertragsrecht/294-OLG-Muenchen-Az-6-U-181806-Zum-Weiterverkauf-von-Computerprogrammen.html

� BGH: UsedSoft (Oracle-Urteil, anhängig beim Gerichtshof der Europäischen Union EuGH zum Oktober 2011) BGH, Beschluss v. 03. 02. 2011, Az. I ZR 129/08; http://www.telemedicus.info/urteile/IT-Vertragsrecht/1153-BGH-Az-I-ZR-12908-UsedSoft.html

■■ 24.2■ Software-Audit – Rechtliches

Die Softwarehersteller haben zugegebenermaßen ein berechtigtes Interesse daran, die Ein-haltung der lizenzkonformen Nutzung ihrer Softwareprodukte zu überwachen. Um dieses Interesse zu wahren, sind in den Softwareverträgen häufig Klauseln zu finden, die dem Lizenzgeber mehr oder weniger umfangreiche Auditrechte zugestehen sollen. Diese Audit-Klauseln sind ein beliebtes Thema in der Softwarebranche und müssen sich an den gesetz-lichen Regelungen in Deutschland messen lassen (UrhG, BGB). Das macht es den Herstel-lern nicht gerade leicht. Rechtsanwalt Thomas Feil hat dazu in einem Aufsatz folgende Meinung formuliert:

„Ein verdachtsunabhängiges Auditrecht ist den gesetzlichen Regelungen zum Urheberrecht fremd. Das hat seinen Grund. Nach der gesetzgeberischen Wertung würde das legitime Inter-esse des Anwenders an einer Wahrung seiner Geschäftsgeheimnisse gegenüber dem Interesse des Rechteinhabers zu sehr vernachlässigt werden (BT-Drucks. 11/4792, S. 32 f.). Außerdem wäre ein solches verdachtsunabhängiges Auditrecht mit dem geltenden Rechtsschutzsystem unvereinbar. Es genügt, dass der Rechteinhaber den Lizenznehmer bei gewichtigen Verdachts-momenten zur Abgabe einer eidesstattlichen Versicherung veranlassen kann.Zivilrechtliches Besichtigungsrecht Im Bürgerlichen Gesetzbuch (BGB) findet sich in § 809 ein Besichtigungsrecht. Ein solches kann sogar zu genauen Untersuchungshandlungen berechtigen, wenn sich der Rechte in ha-ber Gewissheit verschaffen will, ob ihm Ansprüche gegen den Lizenznehmer zustehen. Sol-che Ansprüche können bei Rechtsverletzungen durch den Softwarenutzer bestehen. Es muss

7 Leider wurde dieser Beitrag von den Webseiten der BSA entfernt.

http://www.telemedicus.info/urteile/Urheberrecht/1097-OLG-Frankfurt-am-Main-Az-11-U-1310-UEbertragung-von-Softwarelizenzen.html



http://www.telemedicus.info/urteile/IT-Vertragsrecht/294-OLG-Muenchen-Az-6-U-181806-Zum-Weiterverkauf-von-Computerprogrammen.html



http://www.telemedicus.info/urteile/IT-Vertragsrecht/1153-BGH-Az-I-ZR-12908-UsedSoft.html

http://www.telemedicus.info/urteile/IT-Vertragsrecht/1153-BGH-Az-I-ZR-12908-UsedSoft.html

24.2 Software-Audit – Rechtliches 473

jedoch ein gewisser Grad an Wahrscheinlichkeit bezüglich des Bestehens eines Anspruchs gegeben sein und der Rechteinhaber muss ein ernstliches Interesse geltend machen. Beides muss im Zweifelsfalle auch bewiesen werden. Ein Kontrollrecht „ins Blaue hinein“ gibt die Vorschrift nicht.Ein Besichtigungsrecht besteht nicht, wenn schutzwürdige Belange entgegenstehen. Das kön-nen vertrauliche Inhalte, Betriebsgeheimnisse oder Persönlichkeitsrechte Dritter sein. Dass bei der „Prüfung“ von Computern und Geschäftspapieren in Unternehmen regelmäßig ein Zugriff auf sensible Daten nicht ausgeschlossen werden kann, liegt auf der Hand und bedarf keiner weiteren Erläuterung. Daher muss im Einzelfall nach einer Verhältnismäßigkeits-abwägung entschieden werden, ob ein Besichtigungsrecht besteht. Die Wahrscheinlichkeit der Rechtsverletzung, die Verletzung von Betriebsgeheimnissen und der Grad der widerstrei-tenden Interessen von Softwarehersteller und Lizenznehmer sind hier nur einige von vielen einzubeziehenden Faktoren. Grundsätzlich aber kann davon ausgegangen werden, dass nach der gesetzlichen Regelung in Bezug auf die Kontrolle von Firmencomputern ein Besich-tigungsrecht eher die Ausnahme denn die Regel darstellt.“8

In dem hier zitierten Aufsatz von Thomas Feil (Feil Rechtsanwälte) zu dem Thema „Auditie-rungsmaßnahmen durch Softwarehersteller – Audit-Klausel“ werden noch weitere interes-sante Aspekte angesprochen, die darauf abstellen, dass Audit-Klauseln in für Deutschland geltenden Standard-AGB-Formularverträgen häufig unwirksam sind.Auch wenn sich viele weitere Rechtsmeinungen mit dem Thema der „berechtigten oder unberechtigten Einräumung von Audit-Klauseln in Software- und Lizenzverträgen“ aus-einandersetzen und zugegebenermaßen recht einleuchtende Argumente finden, die dafür sprechen, dass die Audit-Klauseln zumindest in Standard-AGB-Formularverträgen unwirk-sam sind, werden Ihnen solche rechtlich nicht verbindlichen Meinungsäußerungen in der Praxis letztlich nur wenig weiterhelfen. Auch gibt es, soweit mir bekannt ist, zurzeit keinen ausjudizierten Fall in dieser Sachlage. Im Gegenteil: Es könnten recht langwierige Rechts-streitigkeiten oder auch die Beendigung der Geschäftsbeziehung drohen. Und wenn das in Ihrem Unternehmen ein strategisches Softwareprodukt betreffen sollte, kann dies auf Ihren Geschäftsbetrieb verheerende Auswirkungen haben, da die Hersteller oft am längeren Hebel sitzen.Bei Streitigkeiten könnte ein Hersteller z. B. mit einer einstweiligen Verfügung Ihren Geschäftsbetrieb unter Umständen erheblich einschränken, denn der Richter, der diese anordnet, muss dafür die Gegenseite nicht anhören. Da Sie sich vertraglich für eine kor-rekte lizenzkonforme Nutzung der Softwareprodukte gegenüber dem Hersteller verpflichtet haben, sind Sie faktisch auch daran gebunden, diese einzuhalten. Daher sollte es Sie eigent-lich nicht überraschen, wenn dies gelegentlich überprüft wird.Der Gesetzgeber hat festgestellt, dass hier weitere Anpassungen erforderlich sind, und hat im Wege einer weiteren Novellierung im „Gesetz zur Verbesserung der Durchsetzung des geistigen Eigentums (GEigDuVeG)“ den § 101 a UrhG (Anspruch auf Vorlage und Besich-tigung) ergänzt und präzisiert (beschrieben unter Artikel 6, S. 1201 ff). Das Gesetz ist am 7. Juli 2008 in Kraft getreten und hat weitere Paragrafen des UrhG aktualisiert (§§ 97–111c).

8 Quelle: Feil Rechtsanwälte https://www.recht-freundlich.de/abmahnung-urheberrechtlich-filesharing/auditierungsmasnahmen-durch-softwarehersteller

https://www.recht-freundlich.de/abmahnung-urheberrechtlich-filesharing/auditierungsmasnahmen-durch-softwarehersteller

https://www.recht-freundlich.de/abmahnung-urheberrechtlich-filesharing/auditierungsmasnahmen-durch-softwarehersteller


■■ 24.3■ Die Schwierigkeiten der Hersteller

Trotz der weiteren Stärkung des Schutzes geistigen Eigentums bleibt festzustellen, dass aus Sicht der Softwarehersteller weiterhin eine zusätzliche vertragliche Audit-Klausel in den Verträgen unverzichtbar ist, wenn Ansprüche wegen einer (eventuellen) Verletzung des Urheberrechts geltend gemacht werden sollen.Ein Hersteller von Softwaretools, u. a. für das Softwareasset- und Lizenzmanagement, wollte es genauer wissen und hat eine Umfrage in Auftrag gegeben. Diese Umfrage, die von der Flexera Software beauftragt und mit Unterstützung der IDC-Forschungsabteilung für Soft-warepreisgestaltung und -lizenzierung durchgeführt wurde, hat in Bezug auf das Thema Audit folgende Werte ermittelt:Im Jahr 2010 haben 13 Prozent der befragten Hersteller für die Einhaltung der lizenzrecht-lich korrekten Nutzung ihrer Softwareprodukte Audit-Teams eingesetzt.

„Obwohl diese Zahl verglichen mit anderen Methoden – wie Überprüfungen der Serien-nummern (39 Prozent), Produktaktivierungen (36 Prozent) und Dongles (24 Prozent) – gering erscheint, befinden sich Audits im Aufschwung. Im vergangenen Jahr nutzten nur 3 Prozent der Hersteller Audits zur Compliance-Prüfung. 18 Prozent der Hersteller erwarten, dass Audits in den nächsten zwei Jahren häufiger durchgeführt werden. Die Zunahme von Audits, die häufig mit Unternehmenszusammenführungen und -übernahmen begründet wer-den, sowie Änderungen in der Umgebung (z. B. Virtualisierung), führen zwar zu steigenden Gewinnen bei den Herstellern, erhöhen jedoch gleichzeitig Spannungen zwischen Hersteller und Kunden.“ 9

Um einen plausiblen Anlass für einen Audit zu schaffen (das UrhG kennt kein verdachts-unabhängiges Audit-Recht, siehe Abschnitt 24.2), greifen die Hersteller unter anderem auch auf diese mittlerweile sehr einfach verfügbaren Informationen zurück und gleichen diese mit anderen Daten, bspw. aus den herstellereigenen Online-Portalen (Microsoft: „Volume Licensing Service Center (VLSC)“, IBM: „IBM Passport Advantage Online“) ab. Ergeben sich hier Unstimmigkeiten und entsteht der Verdacht einer Unterlizenzierung, wird schon ein-mal ein freundlicher Brief an den Kunden verschickt, mit der Aufforderung, eine Lizenz-bilanz einzureichen. Unternehmer, die diesen Brief erhalten und sich bis dahin nicht viel um das Thema Lizenzmanagement gekümmert haben, werden dann nicht nur einige schlaf-lose Nächte vor sich haben, sondern auch sehr viel zu tun bekommen. Wird dann der Audit durchgeführt, weil gewisse Umstände seitens des Herstellers dafür sprechen, kann sich dieser über mehrere Wochen oder Monate hinziehen, bindet in dieser Zeit mindestens eine Vollzeitarbeitskraft und verschlingt noch etliches an weiteren Arbeitsstunden, die u. U. von weiteren Fachbereichen geleistet werden müssen. Dass dieser Umstand nicht ganz von der Hand zu weisen ist und ein erhöhtes Audit-Risiko besteht, zeigen die im Bild 24.1 grafisch aufbereiteten Umfrageergebnisse, die am 27. Januar 2012 von Gartner veröffentlicht wur-den.

9 Umfrage 2010 über wichtige Trends bei der Softwarepreisgestaltung und -lizenzierung; Quelle: http://files.vogel.de/vogelonline/vogelonline/files/3991.pdf

http://files.vogel.de/vogelonline/vogelonline/files/3991.pdf

http://files.vogel.de/vogelonline/vogelonline/files/3991.pdf

24.4 Was der Anwender wissen sollte 475

Anzahl, die ein Audit gemeldet haben

Prozentsatz, die gemeldet haben

in den letzten zwölf Monaten

2011 auf 65%

2007 auf 35%

Hersteller-Audits

IBM Adobe Microso� Oracle SAP0

25

100

35

75

50

65

44

56

38

47

162419

2832

Bild 24.1■Aktueller Audit-Trend bei Softwareherstellern10

Ganz klar erkennbar ist die gestiegene Anzahl an durchgeführten Audits beispielsweise bei IBM von 65 gemeldeten in 2011 – innerhalb von vier Jahren – bezogen auf eine gemeldete Zahl von 35 aus dem Jahr 2007 (hier nicht mit dargestellt).Ebenso diesen Trend bestätigend ist die in einer weiteren Gartner-Studie gestellte Frage, die am 23. Mai 201211 veröffentlicht wurde. Darin wurden 228 Anwender aus den verschie-densten Unternehmen befragt, ob sie und wenn ja, vom wem, in den letzten zwölf Monaten zu einem Software-Audit aufgefordert wurden. 65 % wurden zu einem Software-Audit auf-gefordert, 25 % wurden das nicht und 10 % konnten keine Angaben dazu machen. Auf die Frage „Wer hat aufgefordert?“ wurden die nachfolgend alphabetisch aufgezählten Hersteller am meisten genannt: Adobe, Attachmate, Autodesk, IBM, Informatica, Microsoft, Oracle, SAP, Symantec und VMware. Die genannten Hersteller sind eigentlich auch die, die Sie im Auge behalten sollten, wenn Sie bei sich „aufräumen“ wollen. Daraus ergibt sich also ein klares Bild, das den Unternehmen aufzeigt, doch mehr auf die Einhaltung der Lizenz-nutzungsbestimmungen zu achten, denn die Audits werden eher mehr als weniger.

■■ 24.4■ Was der Anwender wissen sollte

Die Hersteller lassen die vertraglich vereinbarte Einhaltung der Nutzungs- und Lizenz bedin-gungen prinzipiell von Wirtschaftsprüfungsgesellschaften wie z. B. KPMG AG (Schwerpunkt Microsoft) oder Deloitte & Touche GmbH (Schwerpunkt IBM) überprüfen und die Audits von dem jeweiligen verantwortlichen Vertriebsmitarbeiter begleiten.

10 Quelle: Gartner, ID:G00228206 „The Software Vendors That Are Auditing Now and What to Do About It“, Table111 Quelle: Gartner, ID:G00230816 „Software Vendor Auditing Trends: What to Watch for and How to Respond“,

Figure1


Es hängt sehr viel von den geprüften Unternehmen selbst ab, wie sie ihre Beziehungen zu den Lieferanten oder Herstellern gestalten und ob ihnen eher ein laues Lüftchen oder eine starke Brise entgegenweht, wenn es um die Klärung festgestellter Sachverhalte geht. Versuchen Sie deswegen möglichst, ein ehrliches, von gegenseitigem Respekt getragenes Verhältnis zu den Mitarbeitern der Softwarehersteller oder Lieferanten aufzubauen und zu unterhalten, um einen eventuellen Software-Audit für alle Beteiligten mit fairen Ergebnis-sen über die Bühne zu bringen.

TippSie sollten darauf achten, dass Ihr Unternehmen nicht von sich aus dem Herstel-ler einen Anlass bietet, ein Audit durchzuführen. Hersteller können z. B. Anhalts-punkte für eine mögliche Unregelmäßigkeit in Ihren Lizenzbeständen gewinnen, wenn bei Supportanfragen durch den Lizenznehmer Widersprüche entstehen, also beispielsweise Supportanfragen gestellt werden, die nicht zu den vertraglich festgelegten Nutzungsbedingungen passen (z. B. bei der Klärung von IT-Szena-rien). Achten Sie auch darauf, was in Ihren Pressemitteilungen publiziert wird. Wenn Sie Meldungen verbreiten wie z. B. „Als einer der größten Hersteller von . . . haben wir mit einer Investition von über 50 Millionen Euro ein neues Rechenzen-trum errichtet, welches mehr als 2500 weitere Anwender unterstützen kann . . .“, wird diese Meldung sicher nicht nur von den Aktionären gelesen.Vertriebsmitarbeiter der Softwarehersteller verwenden unter Umständen auch Informationen aus Gesprächen mit ihren Ansprechpartnern aus den Fachberei-chen, um eventuelle Diskrepanzen aufzudecken. Diese Gefahrenstelle können Sie beseitigen, wenn die Fachabteilungen für die Evaluierung von Software keine Befugnisse erhalten, mit externen Herstellern oder Lieferanten alleine zu ver-handeln, sondern zumindest ein Mitarbeiter aus dem Lizenzmanagement hinzu-gezogen werden muss.Erhalten Sie einen Brief, der einen Software-Audit ankündigt, ohne einen erkenn-baren oder nachvollziehbaren Grund, könnte es sein, dass Sie entweder wirklich nur zufällig ausgewählt wurden oder es sich um eine reine Routinekontrolle han-delt. In vielen Fällen ist das aber eine vorgeschobene Begründung, denn es ist zu vermuten, dass die Hersteller längst untereinander Informationen über beson-ders interessante potenzielle Prüflinge austauschen. Wie sonst ist es zu erklären, dass nach einem Audit eines Herstellers der nächste eines anderen nicht lange auf sich warten lässt.Auch habe ich schon die Situation erlebt, dass ein Dienstleister auditiert wurde und anschließend der Auftraggeber des Dienstleisters gleich mit in den Audit-Ring steigen musste, weil erhebliche Unregelmäßigkeiten festgestellt wurden. Dies hatte dann – wegen fehlender vertraglicher Vereinbarungen mit dem Dienstleister für den korrekten Einsatz und die Nutzung der vom Auftraggeber beigestellten Softwareprodukte – erhebliche finanzielle Auswirkungen auf die Lizenzsituation des Auftraggebers (Nachlizenzierung).

24.5 Bestandteile einer Audit-Klausel 477

Sollte es zu berechtigten Ansprüchen des Herstellers gegenüber Ihrem Unternehmen (dem Lizenznehmer) kommen, sollten Sie folgende Aspekte kennen:Die Ansprüche nach §§ 97ff UrhG richten sich nicht nur gegen den Vertragspartner, viel-mehr kann jeder, der die Software rechtswidrig einsetzt und verwendet, Anspruchsgegner werden. Hierfür wurde in § 100 UrhG die Haftung teilweise erweitert:

� Tochter- und verbundene Unternehmen � Dienstleister (Service Provider, Outsourcer); hier haftet das Unternehmen auch für die korrekte Nutzung der beigestellten Software beim Dienstleister.

� Haftung des Unternehmens, seiner Organe und der MitarbeiterBei rechtswidrigem Einsatz von Software haftet grundsätzlich das Unternehmen selbst. Im Rahmen der sogenannten Organhaftung haftet das Unternehmen auch für seine Organe (Geschäftsführung). Eine fahrlässige Handlung besteht beispielsweise, wenn es keine geeigneten Arbeitsanweisungen gibt, um die Einhaltung der Lizenzbestimmungen sicherzustellen. Auch der Inhaber eines Unternehmens kann für Urheberrechtsverstöße, die seine Arbeitnehmer begehen, persönlich haftbar gemacht und im Falle eines Scha-dens zum Ersatz gegenüber der Gesellschaft verpflichtet werden (§§ 43 GmbHG, 93 AktG, 91 AktG). Als Voraussetzung gilt, dass die Urheberrechtsverstöße in enger Verbindung mit einer nach außen hin dienstlichen Tätigkeit des Arbeitnehmers stehen müssen. Wenn bspw. der Arbeitnehmer in seiner Tätigkeit als Administrator unlizenzierte Software ver-teilt oder zum Einsatz bringt, kann diese Voraussetzung bereits erfüllt sein.

Selbstverständlich kann auch jeder andere Mitarbeiter zur Verantwortung gezogen wer-den, der selbst wissentlich oder unwissentlich Urheberrechtsverletzungen begeht oder sich an solchen beteiligt, also z. B. eine unrechtmäßige Kopie auf einen Rechner aufspielt oder selbst originale Softwareprodukte (z. B. eine DVD aus einem Volumen-Programm, die ja nicht mehr aktivierungspflichtig ist und einen globalen Lizenzkey bereits beinhaltet) zur Anfertigung von unrechtmäßige Kopien zur Verfügung stellt.

■■ 24.5■ Bestandteile einer Audit-Klausel

Egal, ob Sie eine individuelle Audit-Klausel vereinbaren oder eine Standardklausel vom Vertragspartner Verwendung findet, sollten darin mindestens die folgenden Punkte ange-sprochen werden:

� Organisatorische Punkte Ein bevorstehender Audit sollte vom Hersteller in einem angemessenen Zeitraum an -gekündigt werden (üblich sind 30 – 45 Tage vorher).Ablauf und Durchführung des Audits müssen zu den normalen Geschäftszeiten des Unternehmens erfolgen (die Zeiten sind zu vereinbaren).Es sollte festgelegt werden, in welchem Umfang, zu welchem Zeitpunkt und in welcher Periodizität ein Audit stattfindet.


� Inhaltliche Punkte Wenn der Hersteller im Vorfeld schon weiß, wen er als Auditor einsetzt, z. B. Wirtschafts-prüfer oder ein Unternehmen, das die Lizenzprüfung durchführt (was aber eher die Aus-nahme ist), sollte dies mit aufgenommen werden.Wenn es um bestimmte zu prüfende Nutzungsvereinbarungen für ein bestimmtes Soft-wareprodukt oder einer bestimmten Lizenzmetrik geht, sollte der Prüfungsinhalt darauf abgestimmt sein (z. B. die Einhaltung der korrekten Lizenzierung für CPU-basierte Met-riken wird geprüft).

� Juristische Punkte Es sollte festgehalten werden, dass keine personenbezogene Datenverarbeitung während des Audits stattfindet und nur Daten verarbeitet werden, die man für die Prüfung der Ein-haltung der Nutzungsbedingungen benötigt. Außerdem sollte die Wahrung der Betriebs- und Geschäftsgeheimnisse des zu prüfenden Unternehmens vereinbart sein.Wollen die Lizenzprüfer auf Ihren Systemen z. B. eine Batchdatei laufen lassen, um mit bestimmten Parametern die Einhaltung gewisser Lizenzregeln automatisiert zu überprü-fen, sollten Sie sich auf alle Fälle eine Verpflichtung nach § 5 Bundesdatenschutzgesetz (BDSG)12 von den Prüfern unterschreiben lassen.Wollen die Prüfer eventuell auch ein Audit-Programm installieren, sollten Sie sich unbe-dingt vergewissern, dass das Programm zertifiziert ist und wirklich nur die für die Lizenzprüfung notwendigen Parameter abfragt und verarbeitet.Es sind Vereinbarungen und Maßnahmen zu beschreiben (unter rechtzeitiger Hinzuzie-hung des betrieblichen Datenschutzbeauftragten), um den Datenschutz und die Datensi-cherheit ausreichend zu gewährleisten, und die erzielten Audit-Ergebnisse unterliegen der strikten Geheimhaltung.Es ist schriftlich zu vereinbaren, dass die mit dem Audit beauftragten Personen bei einer erforderlichen Prüfung an oder in laufenden Produktionssystemen für etwaige Schäden und Performance-Probleme der IT-Umgebungen/Systeme haften.

� Kaufmännische Punkte Es ist festzulegen, wer die Kosten des Software-Audits trägt und unter welchen Prämis-sen (z. B. ob der Lizenznehmer die Kosten des Audits tragen muss, wenn ein bestimmter Schwellenwert bei einer festgestellten Unterlizenzierung überschritten wird?).Vereinbart werden sollte auch, in welchem Zeitraum nach Bekanntgabe des Audit-Ergeb-nisses die eventuell entstandenen Nachzahlungen für die nicht lizenzkonforme Nutzung der Software zu entrichten sind (üblicherweise 30 Tage).Es ist festzulegen, in welcher Weise eventuell fehlende Lizenzen nachgekauft werden müssen. (Anmerkung: Nicht unüblich sind dann Verrechnungen der zusätzlich zu erwer-benden Lizenzen mit marktüblichen Listenpreisen, also ohne die bestehenden Rabatte und bei Lizenzen mit Wartung, die zusätzliche rückwirkende Erhebung von Wartungsge-bühren (Renewal) über einen Zeitraum von ein bis zwei Jahren.)

� Sonstige Punkte In den Audit-Klauseln werden dann gerne noch Bestimmungen mit aufgenommen, die

12 Quelle: http://www.bfdi.bund.de/SharedDocs/Publikationen/Arbeitshilfen/VerpflichtungDatengeheimnis1.pdf?__blob=publicationFile&v=5

http://www.bfdi.bund.de/SharedDocs/Publikationen/Arbeitshilfen/VerpflichtungDatengeheimnis1.pdf?__blob=publicationFile&v=5

http://www.bfdi.bund.de/SharedDocs/Publikationen/Arbeitshilfen/VerpflichtungDatengeheimnis1.pdf?__blob=publicationFile&v=5

24.6 Wie läuft ein Audit ab? 479

den Lizenznehmer dazu verpflichten, über vorgefertigte Formulare z. B. alle 30 Tage etwa-ige Veränderungen an Systemen oder IT-Szenarien zu melden (so etwas kommt bspw. bei IBM vor).

Auf alle Fälle sollten Sie den Audit-Passus so verhandeln, dass die wirtschaftlichen und rechtlichen Interessen beider Seiten ausreichend gewahrt bleiben und Sie sich auch danach gegenseitig immer noch in die Augen schauen können.

■■ 24.6■ Wie läuft ein Audit ab?

In Kapitel 24.4 sind einige Varianten beschrieben, aus welchen Gründen ein Unternehmen ein Schreiben mit der Ankündigung eines Software-Audits erhalten kann. Das Schreiben erhalten die Unternehmen mit Bezug auf einen bestimmten zu klärenden Sachverhalt oder auf das vertraglich vereinbarte Audit-Recht mit der schon genannten üblichen Ankün di-gungsfrist von 30 bis 45 Tagen. In einem ersten zu vereinbarenden Telefoninterview kön-nen dann die organisatorischen Maßnahmen erörtert werden, die für die Durchführung des Audits erforderlich sind, also das Festlegen der Ansprechpartner auf beiden Seiten, wie und in welchem Zeitraum der Audit ablaufen soll, welche Softwareprodukte oder Systeme Bestandteil der Prüfung sein sollen u. v.a.m. In der nachfolgenden Aufstellung habe ich Ihnen einmal die wichtigsten Verhaltensregeln für einen stattfindenden externen Audit zusammengestellt.

Verhaltensregeln bei einem externen Audit1. Es sind keine Termine mit dem Auditor ohne die benannten verantwortlichen Ansprech-

partnern in Sachen Software- und Lizenzmanagement-Themen zu vereinbaren.2. Es sind keine Softwarelizenzen in einer Ad-hoc Maßnahme zu beschaffen, falls Kenntnis

über eine evtl. Unterlizenzierung besteht, diese Lizenzen sind nicht für den Audit anre-chenbar (Stichtagsregelung) und es werden nur unnötige Hektik und Kosten erzeugt.

3. Der Zugang zu den IT-Systemen oder dem internen Netzwerk wird dem Auditor nur mit Genehmigung der Geschäftsführung erteilt/erlaubt.

4. Es sind keine schriftlichen oder mündlichen Aussagen, die den Audit-Fall betreffen, weiterzugeben, wenn diese Informationen im Vorfeld nicht mit den benannten verant-wortlichen Ansprechpartnern im Unternehmen abgestimmt wurden.

5. Die Kommunikation mit dem Auditor ist auf den Audit-Fall zu beschränken, es sollten keine zusätzlichen Informationen freiwillig und vor allem nicht ohne Abstimmung mit den verantwortlichen Ansprechpartnern im Unternehmen weitergegeben werden.

6. Die Vor-Ort-Termine mit dem Auditor sind auf ein Minimum zu beschränken und immer im Vorfeld mit den verantwortlichen Ansprechpartnern abzusprechen und abzustim-men.

7. Alle Termine und Gespräche sind zu protokollieren und bei Nichtteilnahme des verant-wortlichen Ansprechpartners im Unternehmen an diesen weiterzuleiten.


8. Dem vom Auditor vorgeschlagenen „Projektablaufzeitplan“ sollte nicht sofort Folge geleistet werden, das erzeugt Hektik und Druck und dadurch entstehen unnötige Feh-ler. Der Ablaufzeitplan sollte in Ruhe studiert und mit dem eigenen internen Ablauf-zeitplan abgeglichen werden.

9. Es sollten keine persönlichen Auskünfte oder Meinungen (z. B. zu bestehenden Prozes-sen, dem Qualitätsmanagement, der Qualität der angefragten Daten oder andere Infor-mationen den Audit-Fall betreffend) ohne Abstimmung erteilt werden.

10. Es sind keine Vermutungen zum Sachverhalt zu äußern. Können Fragen nicht fundiert beantwortet werden, sind diese zurückzustellen und in gemeinsamer Absprache mit den verantwortlichen Ansprechpartnern abzuklären und zu beantworten.

11. Bei auftauchenden Unsicherheiten sollte immer eine Abstimmung mit den beteilig-ten Personen im Vorfeld erfolgen, bevor Informationen an den Auditor mündlich oder schriftlich übermittelt werden.

Nach der ersten Kontaktaufnahme und ersten Abstimmgesprächen mit dem Auditor erhält das zu prüfende Unternehmen Formulare des Softwareherstellers (meistens sind es Excel-Formulare mit einem bestimmten standardisierten Aufbau), mit deren Hilfe eine Selbst-auskunft über die bestehende IT-Struktur (Hardwareumgebung, Client und oder Server, Anzahl der Mitarbeiter, Anzahl von Softwarelizenzen, Betriebssysteme) zu erstellen ist. Das ist auch abhängig davon, welche Softwareprodukte mit in die Prüfung aufgenommen wer-den und welche Lizenzmetriken (pro Gerät, pro User, pro CPU etc.) angewendet werden. Soll beispielsweise ein IBM-Softwareprodukt mit der Lizenzmetrik PVU geprüft werden (z. B. eine DB2-Anwendung), sind zwingend die Hardwareparameter der eingesetzten Serversys-teme erforderlich, da IBM je nach Hardwareplattform hier mit bestimmten PVU-Faktoren rechnet (siehe dazu auch Kapitel 20.5 „Beispielszenarien von IT-Architekturen“).Im nächsten Schritt werden dann die von Ihnen vervollständigten Unterlagen an den Audi-tor oder die mit der Prüfung beauftragten Personen weitergeleitet. Diese Daten und Infor-mationen gleicht dann zunächst der Wirtschaftsprüfer bzw. der Auditor mit den Daten ab, die ihm der Hersteller übermittelt hat. Das sind meistens Informationen und Zahlenmate-rial über die abgeschlossenen Verträge und deren vereinbarte bzw. erworbene Stückzahlen. Die Auditoren verlassen sich aber nicht nur auf die Angaben des Prüflings, sondern recher-chieren zusätzlich an bestimmten Punkten, wie z. B. die Anzahl der aktiven Mitarbeiter im Active Directory, im Adressbuch von Lotus Notes oder vom Exchange-Server u. v. a. m., um damit (meistens stichprobenartig) die Korrektheit der abgegebenen Zahlen und Informa-tionen prüfen zu können. Ebenso lassen sie sich IT-Architekturpläne vorlegen oder gehen vor Ort in das Rechenzentrum, um bestimmte auf Papier angegebene Konstellationen zu überprüfen. Sie erinnern sich: Eine rechtswidrige Nutzung kann auch vorliegen, wenn das im Einsatz befindliche IT-Szenario nicht auf die erlaubten Nutzungsbedingungen der Soft-ware ausgerichtet ist (ein klassisches Problem bei Virtualisierungsumgebungen).

Tipp:Die Auditeure gehen manchmal auch in die Aufbewahrungslager Ihrer PC- und Server-Systeme und schließen den einen oder anderen Computer stichproben-artig an Strom und Netzwerk an, um zu prüfen, ob sich darauf zusätzliche Soft-ware (außer dem Betriebssystem, da dies meistens eine OEM-Lizenz ist) finden


lässt. Diese wird dann in den Lizenzinstallationsreport mit aufgenommen und gezählt. Sollten Sie hier keinen ordnungsgemäßen Prozess definiert haben, der nur Computersysteme über die Lagerschwelle lässt, die quasi eine nackte Festplatte haben, kann eine recht unangenehme Situation entstehen, denn die Lizenz darauf ist lizenzrechtlich gesehen noch aktiv und gilt als „verbraucht“. Leider denken die wenigsten Unternehmen an diese möglichen Fallstricke.

Haben die Auditoren die Überprüfung der Angaben abgeschlossen, wird das Prüfungser-gebnis in einem Bericht festgehalten und an den Softwarehersteller übermittelt. Der sichtet in aller Regel noch einmal die Ergebnisse und stellt die für ihn relevanten und zu klärenden Punkte in einem zweiten Bericht zusammen, der dann an das geprüfte Unternehmen wei-tergegeben wird. Es kommt auch vor, dass die beauftragte Wirtschaftsprüfungsgesellschaft gleich von Beginn an alle Recherchen vornimmt und in dem vom Hersteller zur Verfügung gestellten Bericht ablegt.

HinweisIm Verlauf eines Audits sollten immer nur einen oder maximal zwei Mitarbeiter aus Ihrem Unternehmen – offiziell sozusagen als Pressesprecher des Lizenz-managements – mit dem Prüfer bzw. dem Vertreter des Herstellers (meist der Key-Account-Vertrieb für Ihr Unternehmen) in Kontakt stehen. Dies kann – wenn es diese Rolle bei Ihnen schon gibt – der Strategische Lizenzmanager sein oder aber auch eine andere Rolle (Softwareexperte, Einkauf etc.).Ebenso sollten an die Auditoren nur geprüfte Informationen weitergegeben wer-den. Sie sollten strengstens darauf achten, dass keinerlei ungeprüfte Informatio-nen von nicht autorisierten Personen (z. B. ein Produktverantwortlicher oder An-wendungsverantwortlicher aus einem Fachbereich) an die Prüfer weitergegeben werden können. Dazu gehören z. B. Aufstellungen von Daten oder IT-Architektur-szenarien. Richten Sie dazu am besten ein Gruppenpostfach ein, wo Sie die ein- und auslaufenden Informationen ausreichend kontrollieren können.

Welche Informationen verlangen IBM und Microsoft im Vorfeld der Auditierung ?

� Beispiel IBM Zur Erfassung der für die Prüfung notwendigen Informationen wird ein Excel-Formular verwendet (IBM Audit Workbook)13, in dem alle zu prüfenden Produkte aufgenommen werden und das dann von Ihnen zu vervollständigen ist.Der Prüfbericht fasst z. B. unter dem Titel „Software Plausibilisierungs Settlement bei . . .“ die Ergebnisse zusammen (meistens ein von Auditor erstelltes PowerPoint-Dokument). Darin wird für jedes Softwareprodukt ein Steckbrief mit der folgenden Struktur erstellt: Übersicht der Lizenzbestände Ist/Soll, Beschreibung der Situation, die dargestellte Kun-

13 Auf dieser Webseite ist auch eine kleine Aufzählung der Schritte beschrieben (englisch): http://www.thinkasg.com/blog/ibm-software-compliance-audits-oh-boy/

http://www.thinkasg.com/blog/ibm-software-compliance-audits-oh-boy/

http://www.thinkasg.com/blog/ibm-software-compliance-audits-oh-boy/


densicht zu diesem Produkt, das Rechercheergebnis und die möglichen Verbindlichkeiten. Am Schluss des Berichts folgt eine Gesamtaufstellung der möglichen Verbindlichkeiten.

� Beispiel Microsoft Der Auditor (meistens die KPMG) erstellt einen sogenannten Report mit dem Titel „ELP – Effective License Position“, in dem folgende Daten erfasst werden:Product Family, Version, Type of license, Licenses (MLS Volume Licenses, OEM Licenses, other), Preliminary License Entitlement, Deployments (Identified by Inventory Discovered Tool, Identified Manually), Total Software Deployment, Software Deployment vs. License Entitlement, License Allocation (+/-), (Downgrades, Upgrades, Virtualization, Parallel Ins-tallations, Training Licenses, Test Installations), Total License Allocation, Licensing Delta, Upgrade Licenses (Upgrade Licenses Quantity, Upgrade Licenses Quantity (w/Mainte-nance), Comments).Um diese Fülle an Informationen überhaupt auswerten zu können, werden Unterlagen und Informationen aus dem Volume Licensing Service Center (VLSC) mit Inhalten aus den aktuellen Select-, Open- und Enterprise-Agreement (EA)-Verträgen und aus der Vergangenheit gesichtet (z. B. die erfolgten TrueUps während der Laufzeit). Falls diese Informationen ungenügend sein sollten, können weitere Unterlagen vom Kunden ver-langt werden, z. B. die Lizenznachweise von Einzelhandelspaketen (FPPs) oder OEM- und System-Builder-Softwareprodukten (hier oft Betriebssysteme).Soweit mir bekannt ist, gibt es die Möglichkeit, wichtige Informationen für das ELP-For-mular schon aus dem VLSC-Portal zu exportieren, so dass der Auditor oder der Kunde nicht ganz von vorne anfangen muss, um die Informationen in das ELP-Sheet einzutragen.Auch hier wird ein Abschlussbericht erstellt und an Microsoft weitergeleitet. Die weiteren Maßnahmen koordiniert dann ein Vertriebsmitarbeiter von Microsoft in Zusammenarbeit mit dem zuständigen Lieferanten.

HinweisMicrosoft bietet (möglicherweise sogar als einziger Hersteller) einen Software-Audit-Prozess an, den die Unternehmen mit Hilfe von SAM-Partnern durchführen können. Die Unternehmen erhalten nach erfolgreichem Abschluss ein SAM- Zertifikat, worin man ihnen bescheinigt, dass die Microsoft-Softwareprodukte korrekt und gemäß den vereinbarten Nutzungsbedingungen eingesetzt werden. (Weblink: http://www.microsoft.com/sam/de/de/default.aspx)Microsoft „verschont“ das Unternehmen für mindestens ein Jahr mit Software-Audits und das Unternehmen hat nun fürs Erste eine Baustelle weniger.Geschmäckle: Der SAM-Partner ist oft auch ein Wiederverkäufer von Microsoft-Softwareprodukten, für den die Feststellung einer Unterlizenzierung neue Ge-schäfte verspricht, weil er dann den Lizenzbestand des Kunden auffüllen kann. Nicht jeder SAM-Partner zeigt Wege auf, wie sich der Lizenzbestand eventuell ohne Zukauf wieder auf das richtige Gleis setzen lässt. Großartige Kostenopti-mierungsszenarien sollten Sie hier nicht erwarten.Microsoft erreicht damit aber, dass viel weniger Software-Audits z. B. an die KPMG beauftragt werden müssen, denn es kommt natürlich auch vor, dass der Auditor keine Verfehlungen feststellt– somit muss Microsoft die entstandenen Kosten des Audit tragen.

http://www.microsoft.com/sam/de/de/default.aspx


Welche Hersteller auditieren gerne und oft? � IBM IBM wird oft auf den vorderen Rängen platziert, was die Dauer und Häufigkeit der Audits betrifft.

� Microsoft Microsoft hat den Ruf, die Sache mit weniger Aggressivität anzugehen. Dafür fallen hier manchmal die beauftragten Wirtschaftsprüfungsgesellschaften negativ auf, wenn sie noch unerfahrene Mitarbeiter zur Prüfung einsetzen, die mit aller Macht versuchen, etwaige Lizenzverstöße aufzudecken.

� Oracle Oracle ist seit 2009 recht fleißig, was die Software-Audits betrifft, und hat leider wegen seiner bekannten meist unfreundlichen Vorgehensweisen im Umgang mit seinen Kun-den bzgl. der Einhaltung seiner Lizenzbedingungen keinen guten Ruf. Zudem setzt der lizenzrechtlich korrekte Einsatz der Produkte von Oracle auch sehr viel Sach- und Fach-verständnis voraus, damit nicht aus Versehen bei der Installation eine Option zu viel ausgewählt wird, die dann vielleicht nicht mit der vereinbarten Nutzung abgedeckt ist (Stichwort Fehler bei der Paketierung bzw. Installation). Darauf setzt Oracle auch, ist meistens gnadenlos, wenn einem Administrator dieser Fehler bei der Installation unter-laufen ist, und verlangt nachträgliche Lizenzgebühren.

� Adobe Auch Adobe ist zurzeit recht häufig in Sachen Software-Audit unterwegs und in der Inter-pretation der Nutzung seiner Produkte in bestimmten Konstellationen nicht sehr kulant.14 Adobe musste aber schon das eine oder andere Mal nach einem Audit schmerzlich erfah-ren, dass es mittlerweile recht gute Open-Source-Produkte gibt, die der Kunde dann ein-setzt, um die Adobe-Produkte abzulösen (siehe dazu auch Kapitel 18.4 Fallbeispiel 1).

� SAP SAP hat seine Kunden eigentlich schon immer durch seine eigene Systemvermessung (das SAP-eigene Tool Licence Administration Workbench) an die Lizenzreports und peri-odischen Systemvermessungen gewöhnt. Meistens sind Nachlizenzierungen notwendig, weil die SAP-Anwender sich nicht ausreichend mit der Lizenzthematik von SAP ausein-andersetzten. Allerdings könnten die SAP-Anwender bei richtiger Vorgehensweise noch erhebliche Lizenzkosten einsparen, auch wenn es SAP den Anwendern nicht gerade einfach dabei macht, beispielsweise SAP-User zu identifizieren, die das System wenig bis gar nicht nutzen. Hier hilft nur eine konsequente Steuerung und Überwachung der Userberechtigungen und Namenskonventionen. Denn auch wenn ein SAP-User physisch nur einmal existiert, der Name aber z. B. in Form verschiedener Schreibweisen mehr-fach auftaucht (Stichwort: Doubletten), wird es gleich teurer. Ein anderer beliebter Feh-ler ist die fehlende Klassifizierung des SAP-Users (darum muss sich der SAP-Anwender selbst kümmern), denn ohne eine solche wird dieser automatisch in die teuerste Lizenz-kategorie eingeordnet. Für weitere Informationen empfehle ich Ihnen den nachfolgend aufgeführten Weblink „Tipps für den SAP-Betrieb“.

14 Artikel ZDNet, 16. November 2010 „Experton Group warnt vor verstärkten Lizenzkontrollen durch Adobe“ Link: http://www.zdnet.de/41540793/experton-group-warnt-vor-verstaerkten-lizenzkontrollen-durch-adobe/

http://www.zdnet.de/41540793/experton-group-warnt-vor-verstaerkten-lizenzkontrollen-durch-adobe/


Weitere interessante Weblinks: � Artikel von wiwo.de „Microsoft und Oracle nehmen Unternehmen in die Mangel“, 14. 07. 2009,http://www.wiwo.de/unternehmen/angebliche-lizenzverstoesse-microsoft-und-oracle-nehmen-unternehmen-in-die-mangel/5558902.html

� Artikel von Computerwoche.de: „Tipps für den SAP-Betrieb“ Lizenz-Manage-ment räumt das SAP-System auf, 12. 11. 2008,http://www.computerwoche.de/a/tipps-fuer-den-sap-betrieb,1878517,3

� Artikel von Computerwoche.de „Lizenz-Management schützt vor Strafe, Soft-ware-Audit – hoffen, dass alles stimmt“, 13. 03. 2006,http://www.computerwoche.de/a/lizenz-management-schuetzt-vor-strafe, 573465,2

HinweisAuch Wirtschaftsprüfer sind nicht vor Fehlern gefeit. Deswegen sollten Sie bei der Vorstellung der Abschlussprüfberichte die Zahlen genau kontrollieren und ggf. auch kritisch hinterfragen, wenn Sie gewisse Darstellungen nicht verstehen oder Ihnen diese nicht plausibel erscheinen. Ein Kollege und ich erhielten den „Gegenprüfauftrag“ eines großen Unternehmens, in dessen Rahmen wir die Ergebnisse eines Audit-Berichts untersuchten. Dabei stellten wir im Bereich der Office-Suite-Lizenzierungen zu Ungunsten des Kunden berechnete Zahlen fest. Unsere Nachprüfung ergab, dass der Kunde im Bereich der Office-Produkte doch nicht unterlizenziert war. Der Auditor hatte vergessen, die Zahlen aus dem „Microsoft Licensing Statement (MLS)“-Report mit einzuarbeiten. Und hier ging es nicht um einen kleinen Betrag!

24.6.1■ Wie bereiten Sie sich vor?

Das Thema Software-Audit ist so vielfältig und teilweise so individuell ausgeprägt, dass es mitunter schwer fällt, schon im Vorfeld zu wissen, wie man mit einem bevorstehenden Audit umgeht.Im ersten Kapitel des Buchs in Bild 1.1 können Sie die Auswertung einer Umfrage zum Thema „Wie reagieren Anwender auf Audits?“ sehen. 41 Prozent von 500 befragten Firmen in Deutschland wählten die Antwort „Zuversichtlich, dass alles gut geht“. Diese Zahl aus dem Jahr 2006 wird sich gegenüber heute nicht wesentlich verändert haben, da noch immer nur wenige Unternehmen erkannt haben, wie wichtig es ist, einen möglichst genauen Über-blick über die im Unternehmen eingesetzten Softwareprodukte zu haben. Doch gerade in kleinen und mittelständischen Unternehmen fehlen oft die Ressourcen und das Know-how, um eine lizenzkonforme Nutzung der Softwareprodukte zu gewährleisten. Daher gibt es meist kaum Prozesse und Werkzeuge, die es ermöglichen, Softwarebestände ausreichend transparent zu verwalten, was für einen Software-Audit eigentlich die beste Voraussetzung

http://www.wiwo.de/unternehmen/angebliche-lizenzverstoesse-microsoft-und-oracle-nehmen-unternehmen-in-die-mangel/5558902.html

http://www.wiwo.de/unternehmen/angebliche-lizenzverstoesse-microsoft-und-oracle-nehmen-unternehmen-in-die-mangel/5558902.html

http://www.computerwoche.de/a/tipps-fuer-den-sap-betrieb,1878517,3


wäre. Doch spätestens nach dem Audit denken die Verantwortlichen intensiver über dieses Thema nach – das ist so sicher wie der morgendliche Sonnenaufgang.Damit Sie dem Audit nicht ganz unvorbereitet gegenüberstehen, sollten Sie die Zeit bis zum angekündigten Prüfungsbeginn nutzen und versuchen, sich einen Überblick über die Sachlage zu verschaffen:

� Sichten Sie die vorhandenen Verträge und mögliche Informationen (wie z. B. E-Mails, Pro-tokolle zu den Verhandlungen der Softwareverträge, wo eventuell weitere Absprachen oder Nebenabreden festgehalten wurden u. a.).

� Lassen Sie sich von den verantwortlichen Mitarbeitern eine aktuelle Aufstellung über die Hard- und Softwareumgebung geben sowie eine Liste der gerade aktiven Mitarbeiter aus dem Active Directory oder dem Adressbuch des E-Mail-Servers (Lotus Notes oder Exchange).

� Suchen Sie die letzten Lizenzmeldungen heraus (z. B. für Microsoft die TrueUp-Meldun-gen).

� Beginnen Sie mit einer umfassenden Aufstellung der genutzten Lizenzen und prüfen Sie schon einmal, ob die in den Verträgen vereinbarten Nutzungsbedingungen in Ihren IT-Szenarien richtig umgesetzt wurden (anhand der Bebauungspläne Ihrer IT-Architektur).

Welche Informationen dafür zusammengestellt werden sollten (z. B. in einem Excel-Sheet):

� Artikel-Nr. des Herstellers (SKU-Nummer15), erworbene Stückzahl, vereinbarte Lizenz-metrik (z. B. PVU, User, Named User, CPU, Device), Produktbezeichnung (z. B. „Adobe Photo shop“), Version, Wartungsbeginn, Wartungsende, Systemname (Server, PC), Umge-bung (z. B. Entwicklung, Test, Produktion); bei Servererfassung wird zusätzlich benötigt: Servertyp (z. B. „HP Proliant DL380 G05“), CPUs (Anzahl), Cores pro CPU (Anzahl), CPU-Modell (z. B. „Intel 2x3, 0 Ghz Quad Core“); aktueller Verbrauch der Lizenzmetrik (z. B. Anzahl der genutzten PVU-Punkte, Anzahl der gefundenen Installationen etc.); bei virtu-ellen Umgebungen muss mit aufgenommen werden: Name des physikalischen Servers, Anzahl der virtuellen CPUs; für Cluster: Clusterbezeichner, Aufstellung der darin enthal-tenen physikalischen Server.

Damit haben Sie sich schon recht gut auf den Audit vorbereitet. Wichtig dabei ist, dass Sie sämtliche Produktverantwortliche und Ihre IT-Architekten mit den verantwortlichen Sys-tembetreuern mit ins Boot holen. Nur sie können Ihnen eventuelle Szenarien richtig erläu-tern und darstellen und die verwendeten Lizenzmetriken erklären.Sicherlich müssen Sie für Ihre Vorbereitungen auch noch auf andere Bereiche zugehen, wie Einkauf, Recht, Finanzen oder sogar auf den Dienstleister, der Ihre Serverfarm betreibt. Die 30- bis 45-Tage-Frist ist schneller abgelaufen, als Sie denken. Achten Sie also darauf, die benötigten Informationen möglichst schnell und effizient aufzubereiten.

15 SKU = Stock Keep Unit (eigentlich sollte es sich dabei um eine eineindeutige Nummer handeln, was aber oft nicht der Fall ist, weil die Hersteller manchmal ganz gehörig schludern).


24.6.2■ Was ist ein gültiger Lizenznachweis?

Für den Nachweis gültiger Lizenzen benötigen Sie diverse Informationen und Unterlagen. Eine Auswahl finden Sie in der folgenden Aufstellung. Aufgrund der Fülle an Softwarepro-dukten und Herstellern kann diese Aufstellung aber nur eine grobe Übersicht vermitteln.Leider gibt es keinen allgemeingültigen Standard, wie eine gültige Lizenz nachgewiesen werden kann. Je nachdem, welches Softwareprodukt im Einsatz ist und über welchen Dis-tributionskanal die Lizenzen erworben wurden, gibt es unterschiedliche Anforderungen an einen gültigen Lizenznachweis. Dieser kann dann aus den unterschiedlichsten Bestandtei-len zusammengesetzt sein; z. B.:

Mögliche Bestandteile und Arten von Lizenznachweisen � Originalverpackung mit dem gesamten originären Inhalt bei Kauf, � Original-Software-Medien (wie CDs, DVDs, USB-Sticks, Memory-Cards, evtl. Disketten), � Lizenzvereinbarung, Garantieschein, Echtheitszertifikat, Handbuch, � Rechnung, Zahlungsnachweis, Quittung, Kaufbeleg, Bestellformular (in Richtung Liefe-rant, Hersteller).

Nicht als Lizenznachweis anerkannt werden z. B. � Lizenzurkunden, die nicht vom Hersteller ausgestellt wurden (ein großes Problem bei Lizenzverkäufen auf dem Gebrauchtsoftware-Markt, da hier teilweise mit von Notaren aus gestellten Lizenzzertifikaten ein rechtmäßiger Erwerb der Nutzung vorgetäuscht wird),

� notarielle Bestätigungen (siehe Lizenzurkunden), � Lieferscheine, � gefälschte (nicht originale) Softwareprodukte (Raubkopien), � Softwareprodukte (auch wenn diese original sein sollten) in einzelnen Bestandteilen, also z. B. einzelne Originaldatenträger, einzelne Echtheitszertifikate (Certificates of Authen-ticity, COAs),

� unrechtmäßige Bundles von Softwareprodukten (siehe Abschnitt 24.1 „Rechtswidrige Nutzung von Software “).

Formen gültiger Lizenznachweise unterschiedlicher Hersteller:Microsoft

� Einzelhandelspaket (FPP)-Software (z. B. aus einem Elektronikmarkt, muss aber voll- ständig sein, so wie bei Kauf erworben) Zahlungsnachweis, Rechnung vom Lieferanten, Echtheitszertifikat, Originalverpackung, Originaldatenträger, Handbuch, Endbenutzerlizenzvertrag (EULA) oder Microsoft Soft-ware License Terms (MSLT)

� OEM und System Builder (SB) z. B. von einem Fachhändler Zahlungsnachweis, Rechnung vom Lieferanten, Echtheitszertifikat (COA-Label), Daten-träger (wenn mitgeliefert), Handbuch (wenn mitgeliefert), Endbenutzerlizenzvertrag (EULA) oder Microsoft Software License Terms (MSLT)


� Enterprise Agreement (EA) oder Select (auslaufend, jetzt nur mehr „Select Plus“) Vertragsdokumente, Beitrittsnachweis, Bestätigung der Bestellung des Beitrittsunter-nehmens, Nachweise der Lizenzübertragung, Zahlungsnachweis, Dokument „Transfer of License“ (Lizenzen, die über diesen Weg in eine andere Firma übertragen wurden, werden nicht im VLSC-Portal abgebildet, daher muss dieses Dokument von Microsoft als einzig gültiger Lizenznachweis aufbewahrt werden)

� Select Plus Vertragsdokumente, Bestellung, Bestätigung der Bestellung des registrierten verbun-denen Unternehmens, Nachweise der Übertragung, Zahlungsnachweis, Daten aus dem VLSC-Portal

� Open Value Vertragsdokumente, Bestätigung der Bestellung, Dokumentation, die die Lizenzübertra-gung nachweist, Zahlungsnachweis, Rechnung vom Lieferanten

� Open License Online-Unterlagen (eOpen), Vertragsdokumente

AdobeRechnungen, Daten des Kunden vom Lieferanten, vorhandene Lizenzzertifikate, Vertrags-dokumente, Bestelldaten aus der Adobe-Lizenzdatenbank (Lizenzkeys werden nicht als Nachweis anerkannt). Adobe stellt einen eigenen „License Manager“ für E-Licensing zur Verfügung.16

OracleAuszug aus der Lizenzdatenbank, originales Bestellformular, ZahlungsnachweisIBM

� Vertragsdokumente: Passport Advantage Express (PAE) (für kleinere und mittlere Unter-nehmensgrößen) oder Passport Advantage für größere Unternehmen mit verschiedenen Rabattstaffeln

� Die Lizenzdokumente für beide Varianten: Der Software-Lizenznachweis und das Doku-ment „Software Subscription & Support“ mit der Übersicht der erworbenen Software-produkte und Lizenzen sowie Wartungslizenzen (andere SKU-Nummer) werden nach Abschluss von IBM an den Kunden ausgeliefert und sind die gültigen Lizenznachweise.

� Außerdem können die Lizenzdokumente bzw. die erworbenen Softwareprodukte auf dem Passport Advantage Online-Portal verwaltet werden.17 Wer sich dafür interessiert, findet hier ein PDF-Dokument darüber, wie dieses Portal bedient wird und was Sie dort alles verwalten können.18

16 Lesen Sie dazu das Whitepaper: http://www.adobe.com/de/elicensing/licensemanagement/alm/pdfs/95007413_eLicensing_wp_d.pdf

17 Weblink: zum Passport Advantage Portal: https://www-112.ibm.com/software/howtobuy/softwareandservices/passportadvantage

18 Weblink: http://public.dhe.ibm.com/software/analytics/spss/licensing/IBMSoftwareDownloadVirtueller Rundgang-PA-DE.pdf

http://www.adobe.com/de/elicensing/licensemanagement/alm/pdfs/95007413_eLicensing_wp_d.pdf

http://www.adobe.com/de/elicensing/licensemanagement/alm/pdfs/95007413_eLicensing_wp_d.pdf

https://www-112.ibm.com/software/howtobuy/softwareandservices/passportadvantage

https://www-112.ibm.com/software/howtobuy/softwareandservices/passportadvantage

http://public.dhe.ibm.com/software/analytics/spss/licensing/IBMSoftwareDownloadVirtuellerRundgang-PA-DE.pdf

http://public.dhe.ibm.com/software/analytics/spss/licensing/IBMSoftwareDownloadVirtuellerRundgang-PA-DE.pdf


HinweisSie sollten sich unbedingt angewöhnen, alles schriftlich zu dokumentieren, was in irgendeiner Form mit der Kommunikation zwischen Ihnen und Ihren Lieferanten oder Vertriebsleuten des Herstellers zu tun hat. Legen Sie bei mündlichen Verein-barungen (z. B. in Meetings oder Telefonaten) Aktennotizen oder Gesprächsproto-kolle an (oder wenigstens ein Gedächtnisprotokoll, wenn kein offizielles erstellt wird) und versichern Sie sich damit noch einmal schriftlich bei Ihrem Gesprächs-partner, ob der besprochene Sachverhalt so Bestand hat. Wenn Sie es auf Seiten des Herstellers oder Lieferanten mit wechselnden Ansprechpartnern zu tun haben, kann es Ihnen sonst passieren, dass eine getroffene vertragliche Verein-barung vom Nachfolger, weil nirgends dokumentiert, nicht mitgetragen wird.

■■ 24.7■ Was kommt nach dem Audit?

Nach dem Audit ist vor dem Audit. Sicherlich kann davon ausgegangen werden, dass in den Unternehmen, die unvorbereitet einen Audit erleben durften und dabei erhebliche Nach-zahlungen zu leisten hatten, die Verantwortlichen spätestens jetzt aufgewacht sind und sich dem Thema Softwareasset- und Lizenzmanagement nicht mehr verschließen werden. Abge-sehen davon, wäre jetzt zu empfehlen, die vergangenen Erfahrungen in einer Nachschau zu bewerten und, wie es so schön heißt, als „Lessons Learned“ aufzunehmen und umzusetzen.Mögliche To-dos:

� Analysieren Sie mit allen am Audit beteiligten internen Mitarbeitern den Ablauf des Audits und halten Sie diese Ergebnisse in einem Abschlussprotokoll fest.

� Erstellen Sie daraus einen Abschlussbericht für das Management und für die Revision. � Erstellen Sie daraus einen Maßnahmenkatalog mit kurz- und mittelfristigen Aufgaben-stellungen.

� Erstellen Sie einen Risikobericht über die eingesetzten Softwareprodukte, um eventuell schon den nächsten potenziellen Software-Audit-Kandidaten zu bestimmen.

� Prüfen Sie, ob die Vertragsunterlagen in Ihren Systemen vollständig und aktuell sind. � Prüfen Sie, ob es klare Anweisungen an die Mitarbeiter bzgl. des Umgangs mit urheber-rechtlich geschützter Software gibt (Open Source ist hier nicht von Belang).

� Sensibilisieren Sie noch einmal Ihre Mitarbeiter und erstellen Sie ggf. neue Richtlinien zum Umgang mit Software.

� Wenn Sie noch kein funktionierendes Lizenzmanagement besitzen, initiieren Sie ein Softwareasset- und Lizenzmanagementprojekt (dafür erhalten Sie jetzt bestimmt die not-wendige Unterstützung).

Die Erfahrung lehrt, dass recht schnell der nächste Software-Audit eines anderen Herstel-lers ins Haus stehen kann. Dafür sollten Sie nun auf der Basis Ihrer neuen Erfahrungen besser gewappnet sein.

24.7 Was kommt nach dem Audit? 489

HinweisProbieren Sie gegebenenfalls die SAM-Potenzialanalyse (dynamische Checkliste) von Microsoft aus. Hier werden bereits einige wichtige Fragen gestellt. Mit den Antworten erhalten Sie in wenigen Minuten eine Auswertung darüber, wie es um Ihren SAM-Bereich steht. Dies dient aber wirklich nur zu einer ersten Einschät-zung. Überbewerten Sie das Ergebnis also nicht (https://www.microsoft.com/de-de/sam/optmodel.aspx).

FazitEinige Marktforschungsunternehmen rechnen aufgrund sinkender Umsätze im Softwareneugeschäft damit, dass die Schlagzahl der Software-Audits durch die Hersteller erhöht wird. Da viele Unternehmen nicht über die erforderliche Transparenz ihrer Softwareassets und Lizenzbestände verfügen, trifft sie ein Software-Audit oft relativ unvorbereitet. Aufgrund fehlender eigener Zahlen und Unsicherheiten bzgl. der zu archivierenden Lizenznachweise müssen sie sich dann meistens mit den von den Herstellern ermittelten Prüfungsergebnissen irgendwie abfinden und unter Umständen erhebliche Nachzahlungen leisten.Nach wie vor gibt es kaum Informationen zum Thema Software-Audit und die wenigsten kennen die allgemeinen Abläufe im Verlauf eines Software-Audits. En Unternehmen wäre schlecht beraten, würde es darauf bauen, dass der Hersteller seine eigenen Lizenzumsätze nicht gefährden will und deswegen auf Software-Audits verzichtet. Sicherlich stellt sich auch für den Hersteller die Frage, ob er dann das Unternehmen als Kunden verlieren könnte – für kleinere und mittlere Hersteller von Software ist dies sicherlich eine nicht ganz unwich-tige Frage. Die Großen der Branche nehmen aber zunehmend ihr Recht wahr, den korrekten, lizenzkonformen Einsatz ihrer Softwareprodukte zu überprüfen.

https://www.microsoft.com/de-de/sam/optmodel.aspx

https://www.microsoft.com/de-de/sam/optmodel.aspx

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 „1x1 des Lizenzmanagements“Leseprobe . zu „1x1 des Lizenzmanagements“ von Torsten...

Documents

Transcript of Leseprobe „1x1 des Lizenzmanagements“Leseprobe . zu „1x1 des Lizenzmanagements“ von Torsten...