1X1 Des Lizenzmanagements“

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 Inhalt

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

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

1 Lizenzmanagement – vom Risiko zum Wert ...... 3 1.1 Lizenzmanagement – eine Begriffsdefinition ...... 3 1.2 Ausgangssituation ...... 4 1.3 Allgemeine Ziele ...... 8 1.3.1 Transparenz schaffen ...... 9 1.3.2 Kosten senken ...... 10 1.3.3 Compliance herstellen ...... 11 1.3.4 Rechtmäßigkeit gewährleisten ...... 13 1.4 Aktives Lizenzmanagement – Potenzial und Nutzen ...... 15 1.5 Lizenzmanagement – Ausblick und Trends ...... 17

2 Eine Softwarelizenz – was ist das? ...... 21 2.1 Softwarelizenz – begriffliche Klärung ...... 22 2.2 Die gebräuchlichsten Lizenzformen ...... 23 2.2.1 Proprietäre Software ...... 23 2.2.2 Freie Software, Free Software ...... 24 2.3 Über- oder unterlizenziert ...... 26 2.3.1 Überlizenzierung ...... 27 2.3.2 Unterlizenzierung ...... 29 2.4 Unlizenzierte Software ...... 30 2.4.1 Wie gelangt unlizenzierte Software in das Unternehmen?...... 31 2.5 Softwarelizenz kaufmännisch betrachtet ...... 32 2.5.1 Full Package Product (FPP, Box-Produkt) ...... 34 2.5.2 System-Builder-Software...... 35 2.5.3 OEM-Software...... 35 VI Inhalt

2.6 Der Lizenzvertrag ...... 37 2.6.1 End User License Agreement (EULA) ...... 38 2.6.2 Universelle Produktnutzungsrechte ...... 39 2.6.3 Der Lizenzvertrag für Freie Software ...... 40 2.7 Das Lizenzmodell ...... 41 2.7.1 Die Lizenzart ...... 43 2.7.2 Die Lizenzklasse ...... 43 2.7.3 Der Lizenztyp ...... 45 2.7.4 Die Lizenzmetrik ...... 45 2.8 Rechtliche Bestimmungen zur Softwarenutzung in Deutschland ...... 50 2.8.1 Das deutsche Urheberrecht (UrhG) ...... 51 2.8.2 Bestimmung zur Erstellung einer Sicherungskopie ...... 51 2.8.3 Verletzung des Vervielfältigungsrechts ...... 51 2.9 Zivil-, straf- und handelsrechtliche Aspekte ...... 52 2.9.1 Zivilrechtliche Haftung ...... 52 2.9.2 Strafrechtliche Haftung ...... 53 2.9.3 Handelsrechtliche Haftung...... 54 2.10 SOX, EuroSOX, Basel II, KonTraG ...... 55 2.11 Gebrauchte Software ...... 56

3 Der IT-Arbeitsplatz – eine „Black Box“? ...... 61 3.1 Die Software verwalten und managen ...... 61 3.2 Der Softwarekatalog – welche Software kommt ins Unternehmen?...... 63 3.2.1 Softwareportfolio – Schutz vor Softwarewildwuchs ...... 66 3.2.2 Softwareportfolio managen – Kosten reduzieren...... 67 3.2.3 Softwarewarenkorb – Basis für das Lizenzinventar ...... 68

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

4 Das Lizenzmanagementprojekt starten ...... 73 4.1 Die zehn wichtigsten Regeln ...... 75 4.2 Voraussetzungen für den Start schaffen ...... 77 4.3 Ziele und Nutzen für den Projektauftrag definieren ...... 78 4.4 Rollen und Verantwortlichkeiten klar verteilen ...... 80 4.5 Die Risiken einschätzen und bewerten ...... 87

5 Den Projektplan aufstellen ...... 89 5.1 Was gehört zum Projektplan? ...... 90 5.1.1 Das Ziel ist der Weg ...... 91 5.1.2 Was ist zu planen? ...... 93 5.2 Eine Roadmap definieren ...... 94 5.3 Projektphasen und Meilensteine erarbeiten ...... 95 Inhalt VII

5.4 Die Arbeitspakete festlegen ...... 98 5.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 . . . 109 6.1 Aufnahme der Ist-Situation – wo beginnen? ...... 110 6.1.1 Die kaufmännischen Prozesse ...... 113 6.1.2 Die technischen Prozesse ...... 115 6.1.3 Richtlinien ...... 115 6.1.4 Rollen und Verantwortlichkeiten identifizieren ...... 116 6.2 Dokumentation der Ist-Situation ...... 117

7 Prozesse: Strukturen analysieren, bewerten, optimieren ...... 119 7.1 Der Software-Life-Cycle-Prozess im Überblick ...... 120 7.2 Der Software-Life-Cycle-Prozess und seine Schnittstellen ...... 122 7.3 Die bisherigen Strukturen und Prozesse untersuchen und bewerten . . . . . 124 7.4 Komplexitätstreiber identifizieren ...... 127 7.5 Die Reifegradanalyse – eine Methode für das Benchmarking und Optimieren von Prozessen ...... 130 7.5.1 Reifegradbestimmung mit dem CMMI-Modell ...... 131 7.5.2 Reifegradbestimmung mit der Norm ISO/IEC 19770-1 ...... 134

8 Den Software-Life-Cycle-Prozess optimieren ...... 143 8.1 Die Soll-Prozesse modellieren ...... 144 8.2 Einteilung der Softwarekategorien ...... 154 8.2.1 Kategorie-1-Software...... 154 8.2.2 Kategorie-2-Software...... 154 8.2.3 Kategorie-3-Software...... 155 8.3 Einordnung des Lizenzmanagements in die ITIL®-Umgebung ...... 155 8.4 Übersicht KPIs im Lizenzmanagement ...... 157 8.5 Rollen und Verantwortlichkeiten definieren...... 161 8.5.1 Die Rolle Strategischer Lizenzmanager ...... 163 8.5.2 Die Rolle Operativer Lizenzmanager ...... 164 8.5.3 Die Rolle Produktverantwortlicher/Softwareexperte ...... 167 8.6 Die wichtigsten Richtlinien für den Umgang mit Software ...... 169 8.6.1 Erstellen einer Richtlinie ...... 170

9 Die Beschaffungsprozesse Bedarfsanforderung und Bestellung von Software ...... 173 9.1 Den Beschaffungsprozess analysieren ...... 173 9.2 Der Softwareanforderungsprozess...... 176 9.2.1 Eine Softwareanforderung auslösen ...... 177 VIII Inhalt

9.3 Der Softwarebestellprozess...... 179 9.3.1 Die interne Bestellung ...... 179 9.3.2 Die externe Bestellung ...... 180 9.3.3 Weitere Beschaffungswege identifizieren ...... 181

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

10 Technische Bestandsaufnahme der Softwareprodukte ...... 187 10.1 Vorgehen und Planung ...... 189 10.1.1 Abgrenzung ...... 190 10.1.2 Vorgehen bei Windows-Client ...... 191 10.1.3 Vorgehen bei Windows-Server ...... 191 10.1.4 Vorgehen bei Linux-Server ...... 192 10.2 Methoden und Werkzeuge ...... 192 10.2.1 Agent-based-Tools ...... 193 10.2.2 Agent-less-Tools ...... 194 10.2.3 Installationsloses Verfahren ...... 195 10.2.4 Methodik der Erhebung von Softwaredaten ...... 196 10.2.4.1 Inventarisierung - Open-Source-Werkzeuge ...... 197 10.2.4.2 Inventarisierung - Kommerzielle Werkzeuge ...... 198 10.2.5 Scanumfang ...... 199 10.3 Nutzbare Datenquellen zur Inventarisierung ...... 200 10.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 ...... 210 11.2 Erforderliche Daten und Informationen ...... 211 11.3 Voraussetzungen schaffen ...... 213 11.4 Aufbau eines Lizenzinventars ...... 215 11.5 Die benötigten Daten und Informationen identifizieren ...... 217 11.5.1 Vertragsdaten identifizieren...... 217 11.5.2 Bestelldaten identifizieren ...... 219 11.5.3 Vorgehen für die Vertrags- und Bestellrecherche ...... 219 11.6 Die Lizenznachweise sammeln ...... 220 11.7 Historisierung und Stichtag – warum ist das wichtig? ...... 224 11.8 Warum kann Ihnen Ihr Lieferant helfen? ...... 225

12 Datenbereinigung und Konsolidierung ...... 227 12.1 Planung der kaufmännischen Datenbereinigung ...... 228 12.2 Die kaufmännischen Daten bereinigen ...... 228 12.3 Die Softwareprodukte eindeutig kennzeichnen ...... 230 Inhalt IX

12.4 Planung der technischen Datenbereinigung ...... 232 12.5 Die technischen Daten bereinigen ...... 234 12.6 Die Daten für eine Initialbeladung vorbereiten ...... 235

13 Klassifizierung von Software – Methoden aus der Praxis ...... 239 13.1 Warum ist eine Klassifizierung zu empfehlen? ...... 239 13.2 Warum Software klassifizieren?...... 240 13.3 eCl@ss – ein Standard mit Zukunft ...... 243 13.4 Die Software strategisch einteilen ...... 246 13.5 Klassifizierung über Geräteklassen...... 248 13.6 Die Softwarenutzung für Client-Klassen definieren ...... 250 13.7 Die Software weiter einteilen ...... 252 13.7.1 Servicekategorien ...... 252 13.7.2 Supportstufen ...... 254 13.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 ...... 261 14.1 Lastenheft und Pflichtenheft – ein kurzer Überblick ...... 262 14.1.1 Das Lastenheft ...... 262 14.1.2 Das Pflichtenheft ...... 263 14.2 Struktur und Aufbau eines Lastenhefts ...... 264 14.2.1 Beispiel eines Lastenhefts für ein Lizenzmanagement-Tool (gekürzte Fassung) ...... 265 14.2.2 Worauf Sie bei der Erstellung des Lastenhefts achten sollten . . . . . 267

15 Das Lizenzmanagement-Tool evaluieren ...... 271 15.1 Vorbereitung der Ausschreibungsunterlagen ...... 272 15.2 Lizenzmanagement-Tool – zentrale Anforderungen formulieren ...... 281 15.3 Auswahl der Anbieter ...... 283 15.4 Die Angebote analysieren und bewerten ...... 284 15.5 Die Teststellung – der Proof of Concept (PoC) ...... 285

16 Das Lizenzmanagement-Tool implementieren ...... 289 16.1 Die Umsetzung und Implementierung – wer leistet was? ...... 290 16.1.1 Voraussetzungen, die der Auftraggeber schaffen sollte ...... 290 16.1.2 Voraussetzungen, die der Auftragnehmer schaffen sollte ...... 292 16.2 Den Implementierungsplan erstellen ...... 293 16.3 Die Testphase organisieren ...... 294 16.3.1 Aufbau und Gliederung der Testvorschrift ...... 296 X Inhalt

16.3.2 Beispiel einer Testbedarfsmeldung ...... 297 16.3.3 Testbericht erstellen ...... 298 16.3.4 Rahmenbedingungen formulieren ...... 299 16.4 Die Abnahmespezifikation definieren und erstellen ...... 300 16.5 Das Tool geht in Produktion ...... 301

17 Lizenzreporting – Ermittlung der Lizenzdaten ...... 303 17.1 Die wichtigsten Reports im Lizenzmanagement ...... 304 17.2 Der Compliance-Report ...... 306 17.3 Das Erstellen eines Maßnahmenkatalogs ...... 309 17.4 Permanente Steuerung und Optimierung ...... 311

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

18 Softwarenutzung – Lizenzen proaktiv managen ...... 315 18.1 Identifizierung von nicht genutzten IT-Beständen ...... 316 18.2 Methoden und Ergebnisse aus der Praxis ...... 318 18.3 Ein Softwarenutzungsanalyse-Projekt durchführen ...... 324 18.4 Ergebnisbeispiele aus der Praxis ...... 325

19 Optimierung von Softwareprodukten und -lizenzen durch Virtualisierung ...... 329 19.1 Warum Software virtualisieren? ...... 330 19.2 Voraussetzungen schaffen ...... 331 19.3 Grundlagen der Softwarevirtualisierung ...... 333 19.4 Konzepte der Virtualisierung ...... 335 19.5 Auswirkungen der Softwarevirtualisierung auf bisherige Prozesse . . . . . 336

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

20 IT-Architektur und Lizenzmanagement ...... 341 20.1 Einige Gedanken zur IT-Architektur ...... 342 20.2 Voraussetzungen für die Einbindung des Lizenzmanagements schaffen . . . 345 20.3 Verteilte IT-Landschaften ...... 347 20.4 Lizenzmanagement als Funktion der IT-Architektur ...... 350 20.4.1 Lizenzkonformität Stufe 1 (aktiv) ...... 353 20.4.2 Lizenzkonformität Stufe 2 (proaktiv) ...... 355 20.4.3 Lizenzkonformität Stufe 3 (optimiert) ...... 356 20.5 Beispielszenarien von IT-Architekturen ...... 358 20.5.1 Szenario 1 IBM-Lizenzierung ...... 358 20.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 . . 369 20.6.2 Weitere Ressourcen zur Microsoft-Lizenzierung ...... 371

21 Lizenzmanagement in Server-Umgebungen ...... 373 21.1 Lizenzierung von Server-Umgebungen – Vergangenheit und Gegenwart . . . 374 21.2 Unterschiede im Lizenzmanagement von Client- und Server-Umgebungen . . 376 21.2.1 Ermitteln des Lizenzbedarfs ...... 376 21.2.2 Ermitteln des Lizenzbestands ...... 376 21.3 Lizenzrelevante Parameter für Server-Softwareprodukte ...... 377 21.3.1 Softwareprodukte finden und identifizieren...... 378 21.3.2 Hardwareparameter ermitteln ...... 379 21.4 Kontextinformationen der IT-Infrastruktur ermitteln ...... 379 21.5 Dynamische Veränderung der Lizenzierungsparameter durch Virtualisierung ...... 382 21.6 Die Lizenzmodelle für Server-Softwareprodukte der wichtigsten Hersteller . . 385 21.6.1 Microsoft: Server-Lizenzierung im Überblick ...... 385 21.6.1.1 Microsoft: Was wird lizenziert? ...... 387 21.6.1.2 Microsoft: neue Lizenzmodelle und Lizenzmetriken. . . . . 389 21.6.2 Oracle: Server-Lizenzierung im Überblick ...... 392 21.6.2.1 Oracle: Was wird lizenziert? ...... 395 21.6.2.2 Oracle: zusätzliche Optionen und Funktionspacks . . . . . 397 21.6.2.3 Oracle-Lizenzierung: Wo liegen mögliche Stolperfallen? . . . 401 21.6.2.4 Oracle-Lizenzierung: Named User Plus (NUP) ...... 402 21.6.3 IBM: Server-Lizenzierung im Überblick ...... 406 21.6.3.1 IBM: das PVU-Lizenzmodell ...... 407 21.6.3.2 Weitere Aspekte zur Virtualisierung im IBM-Umfeld . . . . 413 21.6.3.3 Maßnahmen und Optimierungsmöglichkeiten ...... 415 21.7 Optimieren der Softwarelizenzkosten ...... 419 21.8 Gibt es ein Werkzeug für ein Server-Lizenzmanagement? ...... 421

22 Lizenzmanagement in Cloud-Umgebungen ...... 425 22.1 Voraussetzungen schaffen ...... 426 22.1.1 Entwicklungsstufen eines Lizenzmanagements ...... 428 22.2 Was ist eigentlich eine Cloud? ...... 430 22.2.1 Die Cloud-Liefermodelle ...... 432 22.2.2 Die Cloud-Servicemodelle ...... 433 22.3 Ziele für die Anwendung von Cloud-Technologien ...... 438 22.4 Neue Komplexitäten durch die Cloud ...... 440 22.4.1 Kann die bisherige Software mit in die Cloud? ...... 443 22.4.2 Neue Anforderungen an das Lizenzmanagement ...... 444 22.4.3 Aussichten des Lizenzmanagements in Cloud-Umgebungen . . . . . 445 XII Inhalt

23 Operatives Lizenzmanagement ...... 449 23.1 Strategisches vs. operatives Lizenzmanagement ...... 450 23.2 Aspekte und Komponenten des operativen Lizenzmanagements ...... 451 23.2.1 Administrative Komponenten ...... 452 23.2.2 Technische Komponenten ...... 453 23.2.3 Kaufmännische Komponenten ...... 454 23.2.4 Lizenzrechtliche Komponenten ...... 454 23.3 Die Schnittstellen des operativen Lizenzmanagements ...... 456 23.4 Weitere Rollen im operativen Lizenzmanagement ...... 459 23.4.1 Lizenzverwalter ...... 459 23.4.2 Software-Katalogmanager...... 460 23.4.3 Softwarewarenkorb-Verantwortlicher...... 461 23.4.4 Softwareverteiler...... 462 23.4.5 Zentraler Archivverantwortlicher ...... 463 23.4.6 Materialstammdatenpfleger...... 464 23.5 Das Rollenbild des operativen Lizenzmanagers im Unternehmen ...... 465

24 Software-Audit ...... 467 24.1 Rechtswidrige Nutzung von Software ...... 469 24.2 Software-Audit – Rechtliches ...... 472 24.3 Die Schwierigkeiten der Hersteller ...... 474 24.4 Was der Anwender wissen sollte ...... 475 24.5 Bestandteile einer Audit-Klausel ...... 477 24.6 Wie läuft ein Audit ab? ...... 479 24.6.1 Wie bereiten Sie sich vor? ...... 484 24.6.2 Was ist ein gültiger Lizenznachweis? ...... 486 24.7 Was kommt nach dem Audit? ...... 488

25 Anhang ...... 491 25.1 Webseite zum Buch ...... 491 25.2 ISO/IEC 19770 Software Asset Management...... 491 25.3 Lizenzmanagement-Tools ...... 494 25.4 Glossar ...... 498

Index ...... 509 Vorwort

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. 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 deutlich 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 stehen 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 mobilen 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 technischen (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.org 15 Mehr über die Geschichte von Freier Software und GNU können Sie nachlesen auf 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; 2.7 Das Lizenzmodell 43

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 Einzelplatzlizenz Wie 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 Mehrplatzlizenz Bei 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 erworbene Software abgebildet. Zusätzlich werden an die rechtskonforme Nutzung der Software bestimmte Voraussetzungen geknüpft, die u. a. durch eine verfügbare Lizenzklasse beschrie- 44 2 Eine Softwarelizenz – was ist das?

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 Beschreibung Vollversion 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 Sonderform: Wenn ein Gerät oder Nutzer auf einen Server zugreift und dessen (Client Access Dienste verwendet (als Lizenztyp eine Geräte- oder Nutzer-CAL). CALs sind License) immer kostenpflichtig. CAL-Upgrade Sonderform als Upgrade: Wenn ein Gerät oder Nutzer auf einen Server zugreift Client Access und dessen Dienste verwendet (als Lizenztyp eine Geräte- oder Nutzer-CAL). License 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- 2.7 Das Lizenzmodell 45

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 formuliert 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 Beschreibung Pro 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 Desktopumfeld 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 formulierten 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 standardisierten 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- 46 2 Eine Softwarelizenz – was ist das?

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 Zweitkopie- 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 keinem 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 derselben 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 bestimmten 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. 2.7 Das Lizenzmodell 47

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 hinzukommen können bzw. vom Hersteller geändert werden.

Tabelle 2.4 Häufig verwendete Lizenzmetriken undMaßeinheiten Lizenzmetrik Faktor Maßeinheit Beschreibung Pro Gerät 1 bis n Gerät Lizenz pro Gerät, gezählt wird eine Lizenz pro Ins- (Pro Device) (Device) 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 werden 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 1 bis n Nutzer Lizenz pro Nutzer, gezählt wird pro Nutzer, meis- (Pro User) (User) 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 1 bis n Nutzer Die Named User-Lizenzmetrik wird in Kombination (auch Current (User) mit dem Lizenztyp „pro Nutzer“ angewendet. Der oder Endanwender für diese Lizenzmetrik muss nament- Authorized User lich benannt werden, nur er darf dann die Lizenz genannt) nutzen (wird z. B. bei Entwicklungslizenzen von Software angewendet). Floating License 1 bis n Nutzer Erlaubt die Nutzung der Software auf unterschied (auch (User) lichen bzw. beliebig vielen Systemen. Dabei ver- Concurrent waltet ein dafür einzurichtender Lizenzserver die Use genannt) 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. 48 2 Eine Softwarelizenz – was ist das?

Tabelle 2.4 Häufig verwendete Lizenzmetriken und Maßeinheiten (Fortsetzung) Lizenzmetrik Faktor Maßeinheit Beschreibung Pro Seite 1 bis n Seite Lizenzkosten werden aus der Anzahl der gedruckten Seiten ermittelt (beispielsweise beruht die erlaubte Softwarenutzung auf fixen Werten wie z. B. 5000 Seiten/Monat etc.). Dazu kann noch eine Zeitkomponente hinzukommen, wie beispielsweise 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 Basis für die Lizenz sind die Anzahl der installierten CPU phy- und genutzten CPUs (gezählt wird pro CPU). sisch 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 Rechenkerns (CPU) wird meistens nur noch bei Großrechnern angegeben und dient zur Berech- nung von Lizenzgebühren). Pro MSU 1 bis n MSU oder Basis sind MSU (Million of Service Units), eine MIPS MSU entspricht 6 MIPS; weitere Beschreibung siehe MIPS. Pro PVU 1/100 100 PVU 1 bisheriger Prozessor entspricht 100 PVUs, 1 (Processor Value PVU kostet 1/100 des bisherigen Prozessorprei- Unit) ses. Ein Single-Core-Prozessor wird mit 100 PVUs berechnet. Siehe auch den Auszug aus der aktuellen 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. 2.7 Das Lizenzmodell 49

Lizenzmetrik Faktor Maßeinheit Beschreibung Volumen- 1 bis n z.B. Terabyte Basis ist das verfügbare Volumen mit den verein- gebunden Gigabyte barten Wertemengen; beispielsweise darf die Soft- Megabyte warelizenz so lange genutzt werden, bis 5 GB an Stück Datenvolumen erreicht ist. Das eben genannte Beispiel ist eines von vielen Möglichkeiten, eine Lizenz volumengebunden zu verwenden. Standort- 1 bis n z.B. Standortgebundene Lizenzformen sind meistens gebunden pro Land gleichzeitig Unternehmens- bzw. Konzernlizenzen. (bzw. per Site) pro Nieder- Häufig anzutreffen beim Einsatz im Umfeld von lassung Serversoftware und Rechenzentren. pro Org.- Einheit Zeit-gebunden 1 bis n z.B.: Eine zeitgebundene Lizenzmetrik wird vor allem bei pro Minute Software verwendet, die z. B. für Testzwecke ein pro Stunde gesetzt oder aber nur für eine bestimmte Abrech- pro Woche nungsperiode verwendet wird (z. B. beim Erstellen pro Monat von Jahresendabrechnungen etc.). pro Jahr

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 weiteres 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 50 2 Eine Softwarelizenz – was ist das?

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 eigentlich 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 physikalischen 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 erheblich 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 Erste Schritte zur Analyse 6 und Dokumentation der Ist-Situation

In 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 managementumfeld 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- 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.

Lizenzmanagement implementieren

Lizenzmanagement rt Lizenzmanagement

nicht vorhanden: ta ist eingeführt: − Reifegrad analysieren end e ts t keine Transparenz − Soll-Prozesse erstellen Transparenz vorhanden jek jek keine Rechtssicherheit − LiMa-Tool auswählen Rechtssicherheit entsteht Pro hohe Kosten Pro Kosten sinken

Kontrolle der Bestände − Verträge analysieren Optimierung unvollständig − Bestände kontrollieren beginnt − Rechtssicherheit herstellen en st

Ko +=+ + = Ist-Situation Soll-Situation

Stufe 1 Stufe 2 Stufe 3 Zeit 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 erforderlichen 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, verschaffen 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

nicht vorhanden optimiert Organisation/Prozesse

Rollen und Richtlinien

Schnittstellenübersicht

Compliance-Status

Vertragstransparenz Bild 6.2 Überblick Ist- und Ist Soll 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.

Organisation und Prozesse 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. Rollen und Richtlinien 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.

Schnittstellenübersicht Die vorhandenen To ols 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.

Compliance-Status 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.

Vertragstransparenz 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.

Risiko: hoch Risiko: mittel Bild 6.3 Risikoeinschätzung 112 6 Erste Schritte zur Analyse und Dokumentation der Ist-Situation

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

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.

Problemfeld Maßnahmen

• Der Reifegrad der Geschäftsprozesse ist • Den Reifegrad der Geschäftsprozesse nicht bekannt. ermitteln • Ein Software-Life-Cycle-Prozess ist nicht • Einen Soll-Prozess definieren vorhanden. (Optimierungsmöglichkeiten prüfen) • Die Beschaffungen erfolgen unabgestimmt • Die Beschaffungen sind über eine zentrale und unkoordiniert. Stelle auszuführen. • Eine Kontrolle über die Softwarebestände • Eine schrittweise Umsetzung von Prozessen erfolgt nicht. für eine zentrale Beschaffung von Software- produkten

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 aufzeigen, 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).

Kaufmännische Prozesse Te chnische Prozesse

AnforderungBeschaffung Lieferung Installation VerwendungEntsorgung

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

Wenden wir uns zuerst den kaufmännischen Prozessen zu. 6.1 Aufnahme der Ist-Situation – wo beginnen? 113

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 entsprechenden 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.

AnforderungBeschaffung Lieferung Installation Verwendung Entsorgung

Client

Fachbereich IT-K IT-S IT-C IT-CLFP-SFP-S Ansprech- Hr. Thes Hr. SchulzeFr. JaeckelHr. MeierHr. SchatzHr. Keder Partner

Server

Fachbereich IT-M IT-EKIT-SIT-SRVIT-RZ FP-S Ansprech- Hr. Krimm Fr. Götzer Fr. MonetHr. FischerFr. AngelHr. Keder Partner 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. 114 6 Erste Schritte zur Analyse und Dokumentation der Ist-Situation

Beispielsweise wären das: Einkaufs- und Vertragsrichtlinien, Beschaffungsrichtlinien. Versuchen Sie, die für das Verwalten der kaufmännischen Softwarelizenzen eingesetzten 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 irgendwie 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 verschiedene 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? 6.1 Aufnahme der Ist-Situation – wo beginnen? 115

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) 116 6 Erste Schritte zur Analyse und Dokumentation der Ist-Situation

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 verantwortlich, 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 komplexe 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 beispielsweise 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 verschaffen Sie sich damit einen ersten Überblick über die anstehenden Aufgaben bei der Optimierung Ihres Software-Life-Cycle-Prozesses.  IT-Architektur und 20 Lizenzmanagement

In 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 gesteuert 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 werden, 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. 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.

Unternehme ns- architektur

C e IN Informations-

gi A OUT architektur te B ra st mt sa

Ge IT- Architektur

Lizenzma nageme nt

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 gewachsenen 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 werden 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) e Anwendungen IE, Firefox Lotus Notes Adobe, Office Kaspersky SAP

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

Domain Druck- Backup- Archivierungs- Dienste/ Web Service

Informationssystem Funktionen Services management Management management

e Technische Datenaustausch VPN- Workflow- Security- Dienste und Kommunikation Services Services Services -Architektur chnologi

IT SMTP- Datenbanken Plattformen Application Server Te Server (Oracle, MS SQL)

Werkzeuge Hardwarenahe Betriebssysteme Virtualisierung IT-Systeme (Monitoring, Inventory Scan)

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

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- 344 20 IT-Architektur und Lizenzmanagement

gen abbildbar ist. Dazu müssen unter Umständen nicht nur die bestehenden Verträge, sondern 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.

Szenario 1 Oracle Oracle Windows Server 2008

Lizenzmanagement

Internet •Eigene Verträge prüfen •Nutzungsbedingungen des Herstellers prüfen Welches Lizenzmodell •Produktverantwortlichen einbeziehen Szenario 2 ist für welches •Experten des Herstellers einbeziehen Szenario optimal? •Optimales Szenario bewerten und Oracle Oracle prüfen Windows Server 2008 Lizenzmodell festlegen

Szenario 1

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.

Hinweis Sicherlich 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ßerordentliches 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 einbinden? 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).

RZ 1 -Produktion 24*7 RZ 2 -Backup 24*7 y

Datenbank-Backup db

DB2 WebSphere Oracle an Oracle Oracle St t-

Ho VMWare Anwendung Oracle Cold- Standby Transaktion

Firewall 1 Firewall 2

Cloud

Kunde Bild 20.4 Grober Bebauungsplan für ein Szenario mit Zugriff über das Internet 346 20 IT-Architektur und Lizenzmanagement

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 Produktversion (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 getroffenen 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 festgehalten, 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

Hinweis Das 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 Anwendungsverantwortlichen 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-Landschaft Abgesehen 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 348 20 IT-Architektur und Lizenzmanagement

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.

Hinweis Textauszug 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 nutzen zu können. So steckt jeder für seinen Teil in einem Dilemma und die Komplexität der Szenarien verringert sich dadurch nicht gerade. 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 welchen 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.  350 20 IT-Architektur und Lizenzmanagement

■■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 Gesetzgeber (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.

IT-Architektur

Neue Anforderungen oder Veränderungen

Lizenzmanagement

Verträge Nutzungs- prüfen Hersteller 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-Umfeld Bild 20.6 zeigt das Grundszenario für das Erfassen von Daten aus dem Client-Umfeld. 20.4 Lizenzmanagement als Funktion der IT-Architektur 351

Re- Scan

Standard-Scansystem Re- Client-Hardware Scan Softwareinstallationen Daten aus dem Active TechnischeDaten Directory Holding Außendienst Hardwareinventar (User, Adressbuch) Infrastrukturdaten

Kaufmännische Daten Beschaffungen Datenlieferung (Kauf-, Mietverträge) Rahmenverträge Anforderung & Rückmeldung (Lizenzmetriken, Absprachen) 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-Umfeld Das Erfassen der benötigten Informationen aus dem Server-Umfeld stellt das zweite Grund szenario dar, wie Bild 20.7 demonstriert. 352 20 IT-Architektur und Lizenzmanagement

Technische Daten Rechenzentrum Hardwareinventar Re-Scan Infrastrukturdaten Standard-Scansysteme Hardware QA Software Import der Manuelle Erfassung Re- Daten (z.B. mit Excel-Te mplates) Scan Hardware Software CMDB Anwendungen Herstellerspezifische Scansysteme Hardware Software Kennzahlen Parameter Kaufmännische Daten Manuelle Beschaffungen Mitwirkung (Kauf-, Mietverträge) IT-Architektur im Prozess Rahmenverträge Architekturspezifische (Lizenzmetriken, Scansysteme Absprachen) (Skripte, Batches) Umgebungsparameter Datenlieferung Auslastungen Performance- Anforderung & Rückmeldung Messungen Log-Files 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, weitere 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/ 20.4 Lizenzmanagement als Funktion der IT-Architektur 353

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 354 20 IT-Architektur und Lizenzmanagement

Stufe 1 (aktiv) Technische Daten Hardwareinventar Infrastrukturdaten Datenlieferung Einkauf

Prüfen

Verträge Lizenzen

Lizenzmanagement- QA QA Tool

Test- Report Datenabgleich QA QA auswertung erstellen

Compliance- Report

Datenlieferung Anforderung & Rückmeldung QA Qualitätsanalyse 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 festgelegt), 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 20.4 Lizenzmanagement als Funktion der IT-Architektur 355

ö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.

Hinweis Das 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 bestimmten 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. 356 20 IT-Architektur und Lizenzmanagement

Stufe 2 (proaktiv) Technische Daten Hardwareinventar Infrastrukturdaten Lizenz- Fachbereich Datenlieferung Einkauf management

Produkt- verantw . IT-Strategie Prüfen IT-Architektur Change Mgmt. Verträge Lizenzen

QA QA Lizenzmanagement-Tool

Test- Report Datenabgleich QA QA auswertung erstellen

Compliance- Report

Datenlieferung Anforderung & Rückmeldung QA Qualitätsanalyse 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 eingegangen.) 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. 20.4 Lizenzmanagement als Funktion der IT-Architektur 357

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.

Stufe 3 (optimiert) Technische Daten Hardwareinventar Infrastrukturdaten Lizenz- Einkauf Fachbereich Datenlieferung management

Produkt- verantw . IT-Strategie Prüfen IT-Architektur Change Mgmt. Verträge Lizenzen

QA QA Lizenzmanagement-Tool

Test- Report Datenabgleich QA QA auswertung erstellen Software- nutzungsdaten

Datenlieferung Anforderung & Rückmeldung

QA Qualitätsanalyse Maßnaahhmmeenknkatatalalogo mit Optimierungsvorschlägen 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 358 20 IT-Architektur und Lizenzmanagement

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.

Ausgangssituation Das 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.

Aufgabe In 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.

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

In 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 beachten 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 Vorgehensweisen 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.  468 24 Software-Audit

Haftungsausschluss Die 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 lizenzkonformen Nutzung von Software bestehen. Hier müssen also weiterhin die verantwortlichen Personen eine verstärkte Bildung und Aufklärung über die Einhaltung des geistigen 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.com 2 http://globalstudy.bsa.org/2013/index.html 3 http://globalstudy.bsa.org/2013/downloads/studies/2013GlobalSurvey_Study_en.pdf 4 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 rechtswidrige 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.aspx Außerdem stellt Microsoft auch eine Webseite zur Überprüfung von Produkt- merkmalen „Microsoft Produktidentifikationsservice“ (kurz: „PID-Service“) zur Verfügung: 470 24 Software-Audit

https://www.microsoft.com/de-de/rechtliche-hinweise/pidservice.aspx Fü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, manchmal 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 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 Nutzung Hier 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. 2007 Die 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. 2009 Eine 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 werden 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. 472 24 Software-Audit

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 Rechtein 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. 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 interessante 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 unwirksam 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 korrekte lizenzkonforme Nutzung der Softwareprodukte gegenüber dem Hersteller verpflichtet haben, sind Sie faktisch auch daran gebunden, diese einzuhalten. Daher sollte es Sie eigentlich 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 474 24 Software-Audit

■■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 lizenzrechtlich 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 werden, 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 einmal 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 wurden.

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

in den letzten zwölf Monaten 100 Anzahl, die ein Audit gemeldet haben Prozentsatz, die gemeldet haben

75 65 56 2011 auf 65% 50 44 47 Hersteller- 38 Audits 35 32 28 2007 auf 35% 24 25 19 16 0 IBM Adobe Microso Oracle SAP

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 Lizenzbedin 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“, Table1 11 Quelle: Gartner, ID:G00230816 „Software Vendor Auditing Trends: What to Watch for and How to Respond“, Figure1 476 24 Software-Audit

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.

Tipp Sie 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 handelt. In vielen Fällen ist das aber eine vorgeschobene Begründung, denn es ist zu vermuten, dass die Hersteller längst untereinander Informationen über besonders 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 Mitarbeiter Bei 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 werden, 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 angesprochen 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. 478 24 Software-Audit

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 unbedingt 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 24.6 Wie läuft ein Audit ab? 479

den Lizenznehmer dazu verpflichten, über vorgefertigte Formulare z. B. alle 30 Tage etwaige 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ündi 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 oderSysteme 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 Audit 1. 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 verantwortlichen 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 verantwortlichen Ansprechpartners im Unternehmen an diesen weiterzuleiten. 480 24 Software-Audit

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 beteiligten 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 werden 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 recherchieren 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 stichprobenartig 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 24.6 Wie läuft ein Audit ab? 481

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 weitergegeben 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.

Hinweis Im 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 werden. 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/ 482 24 Software-Audit

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 verlangt 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.

Hinweis Microsoft 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.  24.6 Wie läuft ein Audit ab? 483

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 erfahren, dass es mittlerweile recht gute Open-Source-Produkte gibt, die der Kunde dann einsetzt, 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 mehrfach 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/ 484 24 Software-Audit

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 

Hinweis Auch 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 24.6 Wie läuft ein Audit ab? 485

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 Photoshop“), 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 virtuellen 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). 486 24 Software-Audit

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 ausgestellten 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) 24.6 Wie läuft ein Audit ab? 487

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 verbundenen 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 Adobe Rechnungen, 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 Oracle Auszug aus der Lizenzdatenbank, originales Bestellformular, Zahlungsnachweis IBM 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 488 24 Software-Audit

Hinweis Sie 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 urheberrechtlich 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 notwendige 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

Hinweis Probieren 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). 

Fazit Einige 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.  Index

A Auftraggeber ––Rollenbeschreibung 81 AddOn 498 Aufwandskategorie Adobe Mietmodell 19 ––Einteilungsmatrix 256 Advancved Compression Option (Oracle) 397 Ausgelagerte IT-Landschaft Agent-based 498 ––Risiken 347 Agent-less 498 Ausschreibung, erforderliche Dokumente 272 Aktivitätenplan für eine Projektdurchführung 90 Ausschreibungsprojekt Angebotsauswertung ––grober Zeitplan 275 ––Bewertungstabelle (Beispiel) 285 ––Informationsabschnitte 275 Ansprüche nach §§ 97ff UrhG 477 Auswertung tatsächlicher Softwarenutzung Anwendungsaufrufe (Praxisbeispiel) 321 ––Ergebnisse zur Nutzung 332 Anwendungsdaten ––Grundszenario für das Erfassen 352 B Anwendungsvirtualisierung BaFin Rundschreiben zum Risikomanagement ––Varianten 335 14 Application Specific License (ASL) 378 Basel II 56, 498 Arbeitspaket 498 BDSG siehe Bundesdatenschutzgesetz 11 ––Aufgabendefinition 100 Beispielmatrix für die Ermittlung zusätzlicher ––festlegen 98 Lizenzen 366 Audit Beitrittsvertrag 498 ––Praxistipp 476 Bereitstellungs- und Installationsprozess, KPI Auditierung 498 159 ––Verhaltensregeln 479 Beschaffungsprozess ––Welche Informationen sind wichtig? 481 ––analysieren 173 Auditierungsverhalten, IBM, Microsoft, Oracle, ––anfordern und bestellen 173 Adobe, SAP 483 ––Fragen 174 Auditinformationen ––KPI 158 ––IBM 481 ––Maßnahmen zur Optimierung 175 ––Microsoft 482 ––Merkmale zur Optimierung 175 Auditrecht 472 Beschaffungswege Aufbau der Server-Komponenten des ILMT-Tools ––vereinheitlichen, Schritte 182 362 ––weitere identifizieren 181 Aufbewahrungsfrist Lizenzverträge und Lizenz- Besichtigungsrecht nachweise 4 ––zivilrechtlich 472 Index 510

Besitzanzeigende Verträge 498 CM 499 Bestandsaufnahme CMDB 499 ––Abgrenzung der Daten 190 CMMI 499 ––Inventarlisten 189 CoM 499 ––kaufmännische Softwaredaten 209 Community Cloud, Beschreibung 432 ––Software, Vorgehen und Planung 189 Community-Cloud-Form bei öffentlichen Bestelldaten, bereinigen 230 Behörden 433 Box-Produkt siehe FPP Full Packaged Product Compliance 499 32 Compliance-Auswertung Adobe Standard Brute-Force-Ansatz 388 (Beispiel) 312 BSA (Business Software Alliance) 468 Compliance-Check 499 ––aktuelle Studie 4 Compliance-Report, Bestandteile 12, 500 BSA-Studie, Daten 468 Computerwoche ––Informationen rund um die Oracle-Welt (Weblink) 406 C Computing, Voraussetzungen schaffen 426 CAL (Client Access License) 498 Concurrent Use 500 CAL Guide 371 Cross-Upgrade 500 CALs, weitere Informationen (Weblink) 391 CI Configuration Item 498 D Citrix-Umgebung, Lizenzierung (Beispiel) 363 Client 498 Daten einer Inventarisierungsaktion, Auszug 205 Client Access Rights (CAL) 389 Datenbereinigung Client-Daten ––Aufbau Materialstamm (Beispiel) 231 ––Grundszenario für die Erfassung 351 ––eindeutige Kennzeichnung (Beispiel) 231 Clientklassen 499 ––erreichbare Ziele 236 Clientklassen (Fachbereiche) ––Grobplanung Arbeitspakete 228 ––mögliche Verteilung 251 ––Initialbeladung vorbereiten 235 Cloud 430, 499 ––kaufmännisch 228 ––neue Komplexitäten 440 ––Punkte für die Planung 233 Cloud Computing ––Softwareprodukte kennzeichnen 230 ––klassische Softwareprodukte in der Cloud ––technisch 232, 234 443 Datenmodell 500 ––neue Anforderungen an das Lizenzmanage- DOAG Deutsche ORACLE-Anwendergruppe e.V. ment 444 (Weblink) 406 Cloud-Anbieter 437 Dokument „Memorandum of Understanding Cloud-Formen, Aufteilung 436 (MoU)“ 286 Cloud-Liefermodell mit Bezug zum Lizenz Dongle 500 management 432 Downgrade-Recht 500 Cloud-Servicemodelle 433 DSL (Definitive Software Library) 500 ––Aussagen zu strategischen Zielen 438 Cloud-Services E ––Erwartungshaltung bei der Umsetzung 440 Cloud-Technologien eCl@ss 500 ––Ziele 438 ––Aufbau und Struktur 245 Cloud-Umfeld ––Beschreibung 244 ––Hürden 439 ––Hauptgruppen 245 Cloud-Umgebungen ––Klassifizierung, Beispiel 246 ––die vier Formen 431 ––Vorteile 244 Cluster (Rechnerverbund) 381 Einfache Softwareklassifizierung, Übersicht 241 Index 511

ELP (Effective License Position), erforderliche Geschäftliches Wachstum, Grundprinzip 120 Daten 482 Geschäftsprozess 501 Embedded License 378 GNU GPL (General Public License) 41, 501 End User License Agreement 13, 23, 38 Greenfield-Ansatz 501 Entitlement 500 Grober Bebauungsplan für ein Szenario mit Entsorgungsprozess, KPI 159, 160 Zugriff über das Internet 345 EULA (End User License Agreement) 500 Grober Projektzeitplan, Phasenübersicht 98 EULA (Lizenzvertrag einer Download-Lizenz) Grundlizenzmetriken (Prozessor, Core, Installa ––Auszug 38 tion) 385 EuroSOX 55 Evaluierungsanforderungen H ––Aufbau Tabellenkopf 277 Experte, Rollenbeschreibung 84 Haftung des Unternehmens 477 Externe Bestellung, Beschreibung 180 Haftung ––handelsrechtlich 54 ––strafrechtlich 53 F ––zivilrechtlich 52 Falsch lizenzierte Software 469 Haftungsausschluss 468 Flowchart, Arbeitspakte, Projektstrukturplan Haftungserweiterung, § 100 UrhG 477 99 Hard-Disk loading 470 Forecast-Based Agreement 500 Hardware 501 Free Software, Definition 24 Hardwaremerkmale für eine Server-Lizenzierung Freeware 500 379 ––Definition 23 Hardwareparameter Freie Software ––physikalische Sockel 379 ––Definition 24 ––Prozessortyp 379 ––Kriterien 25 Hybrid Cloud 432 ––Lizenzvertrag 40 FSF siehe Free Software Foundation 25, 41 I Full- und Sub-Capacity im Vergleich (Beispiel Kundensituation im IBM-Server-Umfeld) 414 IBM ILMT (Komponenten) 363 FullPackaged Products (FPP) 500 ––Toolerläuterung 362 Funktionstest 500 IBM ILMT-Tool (Weblink) 361 IBM Passport Advantage Agreements, forms and attachments (Weblink) 362 G IBM PVU (Weblink) 362 Gartner – 10 Top-Tech-Trends 18 IBM Rules for Manual Calculation of Virtuali Gartner-Analyse zum aktuellen Audit-Trend bei zation Capacity 361 Softwareherstellern 475 IBM Sub-capacity Licensing Information GDPdU (Grundsätze zum Datenzugriff und zur (Weblink) 362 Prüfbarkeit digitaler Unterlagen) 11 IBM Virtualization Capacity rules for each Gebrauchte Software eligible virtualization environment (Weblink) ––Verkauf 471 362 Gerät 500 IBM-Lizenzierung (Beispiel) 358 ––Definition 42 IBM-PVU-Tabelle (Auszug, Stand Juni 2015) 407 Geräteklassen IMAC (Install, Move, Add, Change) 121, 501 ––Übersicht und Beschreibung (Beispiel) 248 Implementierungsphase ––Zuordnung zu Softwareklassen 249 ––Projektplan (Beispiel) 294 Gesamtklassifizierung Softwareprodukte Implementierungsprojekt (Beispiele) 251 ––Phasenplan (Beispiel) 293 Index 512

Infrastructure-as-a-Service (IaaS) 433 ––verteilte IT-Landschaften 347 Initialbeladung 501 ––Voraussetzungen schaffen 345 Initialbeladungsszenario (Beispiel) 236 IT-Architekturdaten International Passport Advantage Agreement ––Grundszenario für das Erfassen 352 (IPAA), (IBM-Vertrag) 410 Interne Bestellung, Beschreibung 179 K Internetpiraterie 470 Inventarisierung Kaufmännische Datenbereinigung ––Agent-based 193 ––planen 228 ––Agent-less 194 Kaufmännischer Report 501 ––Ausschlussliste 191 Key Process Indicator (KPI) im Lizenzmanage- ––Daten analysieren, auswerten 202 ment 157 ––Gegenüberstellung klassisch und virtuell 442 Klassifizierungsprojekt ––installationsloses Verfahren 195 ––Meilensteinplan zur Durchführung 257 ––Linux-Server 192 Kommunikationsfluss ––Methoden und Werkzeuge 192 ––im Projekt 86 ––Methodik 196 ––zwischen den Projektbeteiligten 86 ––mit Greenfield-Ansatz 197 Komplexitätssteckbrief für Lizenzmetriken ––mit kommerziellen Werkzeugen 198 129 ––mit Open-Source-Werkzeugen 197 Komplexitätstreiber ––mit Regeldatei 197 ––Prozesse 127 ––nutzbare Datenquellen 200 ––Rollen 127 ––Powershell-Script 201 ––Schnittstellen 128 ––Scanumfang Clients 199 ––Verträge 127 ––Scanumfang Server 199 KonTraG (Gesetz zur Kontrolle und Transparenz ––weitere Quellen 201 im Unternehmensbereich) 11, 13, 56, 501 ––Windows-Client 191 Konzernlizenz 501 ––Windows-Server 191 KPIs für die Optimierung des Lizenzbestands ISO 19770-1 420 ––Prozesse 493, 494 Kumulierte verdichtete Rohdaten ISO/IEC 19770-1 ––Auszug 234 ––Ausschnitt Prozessbewertung 136 ––Beschreibung 491 L ––die vier Implementierungsabschnitte 139 ––Hinweis zum Einsatz 122 laptop.nfo-Datei ––Kompetenzfelder 136 ––Auszug 203 Ist-Aufnahme 501 ––umgewandelt in Laptop.txt-Datei 203 Ist-Situation Laptop.txt ––Komplexitätstreiber 127 ––Datenexport nach Excel 204 ––Strukturen und Prozesse 124 Lastenheft 501 IT-Architektur ––Beispielformulierung 265 ––Allgemeines 342 ––Beschreibung 262 ––Beispielszenarien 358 ––Definition 263 ––Daten erfassen aus dem Client-Umfeld 350 ––häufige Probleme bei der Erstellung 268 ––Daten erfassen aus dem Server-Umfeld 351 ––Inhalt 262 ––Kernfragen 344 ––Struktur und Aufbau 264 ––Lizenzkonformität Stufe 1 (aktiv) 353 ––Worauf achten? 267 ––Lizenzkonformität Stufe 2 (proaktiv) 355 Lastenheftanforderungen, Strukturgramm 268 ––Lizenzkonformität Stufe 3 (optimiert) 356 Lenkungskreis, Rollenbeschreibung 83 ––Schichtenmodell 342 f. License Metrik Tool (ILMT), (IBM) 409 Index 513

Lieferantenreport ––CAL-Upgrade 44 ––Anforderungsbeschreibung (Beispiel) 305 ––Cross-Upgrade 44 Lizenz 22, 501 ––Übersicht 44 Lizenz, 90-Tage-Regel 383 ––Update 44 Lizenzadministrator 501 ––Upgrade 44 Lizenzart 501 ––Vollversion 44 ––Beschreibung 43 Lizenzkonformität ––Einzelplatz 43 ––Stufe 1, aktive Unterstützung 354 ––Mehrplatz 43 ––Stufe 2, proaktive Unterstützung 356 Lizenzbedarf Server, ermitteln 376 ––Stufe 3, optimierte Unterstützung 357 Lizenzbestand Server, ermitteln 376 Lizenzkostenvergleich in einem virtualisierten Lizenzeigenschaften, Microsoft (Beschreibung) Umfeld 418 387 Lizenzmanagement 502 Lizenzform 501 ––allgemeine Ziele 8, 79 ––Erläuterung 23 ––als Funktion der IT-Architektur 350 ––Übersicht 26 ––Ausblick und Trends 17 Lizenzierung ––Aussichten für Cloud-Umgebung 445 ––Lizenzmobilität 386 ––Begriffsdefinition 3 ––Oracle Database Enterprise Edition (Beispiel) ––Cloud-Computing 425 404 ––Darstellung der Ist-Situation (Stufe 1) 110 ––Server-Optimierung 415 ––die Zehn Regeln 75 ––Server-Paradigmenwechsel (Praxisbeispiel, ––Dokumentation der Ist-Situation 116 Oracle) 416 ––Einbindung in die Unternehmensarchitektur ––Server-Umgebung 374 342 ––Sub-Capacity Beispiel (IBM) 412 ––Einhaltung der Rechtmäßigkeit 14 ––WebSphere Application Server (Vorgehen) ––Einordnung zu ITIL® 155 408 ––Entwicklungsstufen 146, 428 Lizenzierungsparameter ––Entwicklungstrend 445 ––dynamische Veränderung durch Virtuali- ––Funktion der IT-Architektur 350 sierung 382 ––Herausforderungen für den Cloud-Betrieb 441 Lizenzinventar 502 ––Inhalt und Mehrwert 147 ––Aufbau 215 ––Integration in ITIL® 156 ––Aufbau in Excel 217 ––in virtuellen Umgebungen 442 ––Bestelldaten identifizieren 219 ––Ist-Situation dokumentieren 109 ––erforderliche Daten 216 ––kaufmännische Prozesse 113 ––Historisierung 224 ––kaufmännische Prozesse, Fragen 113 ––Indiz 221 ––Meilensteinplan 97 ––Lizenzkanal Beschreibung 221 ––Nutzen 80 ––Lizenznachweise qualifizieren 222 ––organisatorische Einbettung 104 ––Lizenznachweise sammeln 220 ––Phasenmodell 96 ––Vertragsdaten identifizieren 217 ––Potenzial und Nutzen 15 ––Vorgehen bei Recherchen 219 ––Projektphasen und Meilensteine 95 ––Was ist ein Lizenznachweis? 221 ––Rechtmäßigkeit gewährleisten 13 ––Was ist kein Lizenznachweis? 223 ––Richtlinien 115 Lizenz-Key 502 ––Risiken 87 Lizenzklasse 502 ––Risiken und Chancen 5 ––AddOn 44 ––Risikoeinschätzung zur Ist-Situation 111 ––AddOn-Upgrade 44 ––Roadmap 94 ––Beschreibung 43 ––Rollen definieren 104, 115, 161 ––CAL 44 ––Rollen und Verantwortlichkeiten 80 Index 514

––Schnittstellen 148 ––Proof of Concept durchführen 286 ––Softwarenutzung als Qualitätsverbesserung 17 ––Tipps zur Anbieterwahl 283 ––Soll-Prozesse modellieren 144 ––weitere Kriterien 282 ––strategisches vs. operatives 450 ––Zusammenfassung von Informationen 307 ––technische Prozesse 114 Lizenzmanager ––Überblick der Ist- und Soll-Situation 111 ––operativ 502 ––Übersicht KPIs 157 ––strategisch 502 ––Unterschiede in Client- und Server- Lizenzmetrik 13, 502 Umgebungen 376 ––Beschreibung 45 ––Welche Fragen sind zu stellen 6 ––ConcurrentUse 500 ––Welchen Nutzen gibt es 15 ––und Maßeinheiten, Übersicht 47 f. ––Welche Risiken gibt es 13 ––Ermittlung der PVU-Werte 408 f. ––Welches Potenzial gibt es 15 ––Floating License 47 ––Werkzeug, Server 421 ––Floating License siehe auch Concurrent Use ––Wie Compliance herstellen 11 500 ––Wie Kosten senken 10 ––Full-Capacity (IBM) 408 ––Wie Transparenz schaffen 9 ––LPAR (IBM) 413 ––Wo verorten? 7 ––LPAR pro CPU 503 ––Zeitraum bestimmen 94 ––Microsoft-Server-CAL-Lizenzierung 388 ––Ziele zur Compliance 9 ––MIPS 46 ––Ziele zur Kostensenkung 8 ––Multiplexing (Oracle) 402 ––Ziele zur Rechtmäßigkeit 9 ––nach Prozessor 376 ––Ziele zur Transparenz 8 ––Named User 47, 503 ––Zielsetzung neue Prozesse 146 ––Named User Plus (NUP) (Oracle) 392, 402, ––Zielvorgaben aus dem Management 8 405 Lizenzmanagement-Tool ––non-human operated device (Oracle) 403 ––Anforderungen formulieren 281 ––per Node 47, 503 ––Angebote bewerten 285 ––pro CI 48, 503 ––Aufstellung von Herstellern (Beispiel) 284 ––pro CPU 48, 503 ––Ausschreibung vorbereiten 272 ––pro Gerät 47, 504 ––Auswahl Hersteller und Beschreibung 494 ––pro MIPS 48, 504 ––erforderliche Mindestfunktionen 278 ––pro MSU 48, 504 ––evaluieren, Wirtschaftlichkeitsbetrachtung ––pro Nutzer 47, 504 erstellen 278 ––pro PVU 48, 504 ––implementieren 289 ––pro Seite 48, 504 ––implementieren, Implementierungsplan ––pro Session 48, 504 erstellen 293 ––pro Transaktion 48, 504 ––implementieren, organisatorische Maß ––Prozessorlizenz PL (Oracle) 392 nahmen (Auftraggeber) 290 ––PVU IBM (Werte ermitteln) 408 ––implementieren, organisatorische Maß ––PVU (Processor Value Unit) 46 nahmen (Auftragnehmer) 292 ––PVU-Werte (Sub-Capacity-Betrieb) ermitteln ––implementieren, technische Maßnahmen (IBM) 407, 409 (Auftraggeber) 291 Lizenzmetrik Server ––implementieren, technische Maßnahmen ––pro Core 385 (Auftragnehmer) 292 ––Prozessor/CAL 385 ––implementieren, Testphase durchführen 294 ––Server/CAL 385 ––implementieren, Voraussetzungen schaffen Lizenzmetrik \„Singlecore-Prozessoren\“ bei (Auftraggeber) 290 Oracle-Produkten 360 ––implementieren, Voraussetzung schaffen ––standortgebunden (bzw. per Site) 49, 505 (Auftragnehmer) 292 ––vCPU (IBM Virtual CPU) 413 Index 515

––Virtual Core für PVU-Lizenzierung (IBM) 412 Lizenztyp 502 ––volumengebunden 49, 507 ––Beschreibung 45 ––Wachstum pro Jahr in Prozent 507 ––Übersicht 45 ––zeitgebunden 49, 507 Lizenzübertragung, an Dritte 57 Lizenzmobilität 386 Lizenzvertrag 502 Lizenzmodell 13, 502 ––Beschreibung 37 ––Beispielszenario (Oracle) 394 ––Verbot der kurzfristigen Neuzuweisung 386 ––Beschreibung 41 ––verwenden 42 ––Core-Lizenzierung 390 LzM (Lizenzmanager) 503 ––Hard Partitioning (Oracle) 393 ––IBM Ressourcen Value Unit (RVU) 408 M ––Lizenz pro Gerät 13 ––Lizenz pro Nutzer 13 Maintenance 503 ––Microsoft, Oracle und IBM 385 Master Agreement 503 ––Microsoft SQL Server 386 Medium 503 ––\„Named User Plus\“ anwenden (Oracle) Mehrfachkopien 469 405 Meilenstein 503 ––neue Lizenzmetriken (Microsoft) 389 Meilensteinplan Klassifizierungsprojekt ––nicht benutzerbedientes Gerät, als Named (Beispiel) 257 User Plus (NUP) 402 Memorandum of Understanding, Dokument zur ––On-Premise (Definition) 18 Abgrenzung von Aufgaben 272, 503 ––Oracle 392 Microsoft Enterprise Agreement (EA) 389 ––Oracle mit einer VM-Installation 396 Microsoft Executive Briefing (EBC) 391 ––Oracle zusätzliche Funktionen und Optionen Microsoft SQL Server 2012, Unterschiede in der 399 Lizenzierung 390 ––Processor Value Unit (PVU) (IBM) 407 Microsoft-Lizenzierung, weitere Quellen 371, ––\„Prozessorlizenz\“ anwenden (Oracle) 387 405 Microsoft-Product-Licensing-Website 371 ––Prozessorlizenzen in einem Server-Cluster mit Microsoft-Produktbenutzungsrechte (Weblink) VCenter 5.1 396 390 ––Soft Partitioning (Oracle) 393 Microsoft-Produktlisten (Weblink) 391 ––Sub-Capacity (IBM) 407 Microsoft-Produktlizenzierung (Weblink) 391 Lizenznachweis 502 Microsoft-Server, Zuweisungspflicht 388 ––Anforderungen der Hersteller 223 Microsoft-Volume-Licensing-Website 371 ––Relevanz und Auditierbarkeit 222 Microsoft-Volumenlizenzprogramm (Weblink) Lizenz-Pool 502 391 Lizenzrechtlich lesbare Softwareprodukte 377 Mindestbenutzerzahlen Lizenzreport 502 ––anzuwenden bei der Lizenzierung mit Named ––Compliance-Report Aufgaben 306 User Plus 403 f. ––Compliance-Report Auslöser 307 Mindestlizenzierung von Named User Plus ––Compliance-Report (Übersicht) 306 (Oracle) 403 ––Eintrittsereignisse 309 MoU-Dokument, Inhaltsaufstellung 286 ––kaufmännisch 304 ––Lizenzdaten ermitteln 303 N ––Maßnahmenkatalog erstellen 309 ––Optimierung 311 Nicht besitzanzeigende Verträge 503 ––Reports im Lizenzmanagement 304 Nichtdeterministisch, polynomiell 388 ––Snow License Manager Tool (Beispiel) 307 Norm ISO/IEC 19770-2 234 ––technisch 304 NUP-Lizenzen, Vorgehen zur Mengenbestimmung Lizenz siehe auch Nutzungsrecht 13 404 Index 516

Nutzungsrecht 22 ––Was wird lizenziert? 395 ––bzw. kaufmännische Lizenz 4 ––Zusätzliche Optionen & Funktionspacks 397 ––siehe Lizenz 13 Oracle-Datenbankinstanz Nutzungsübersicht für Microsoft Project ––Parameter (Beispiele) 400 (Praxisbeispiel) 333 Oracle-Komponenten lizenzieren, Schritte 400 Oracle License and Service Agreement (Weblink) 406 O Oracle License and Service Agreement (OLSA) Objekttyp 503 392 OEM siehe Original Equipment Manufacturer Oracle License Management Services (Weblink) 28 406 OEM-Lizenzen 503 Oracle-Lizenzierung, Stolperfallen 401 OEM-Software, Definition 35 Oracle-LMS-Team (License Management Online-Portale, Microsoft, IBM 474 Services) 392 Open Source Initiative siehe OSI 25 Oracle Partitioning Policy, Informationen Open Source siehe auch Freie Software 25 (Weblink) 393 Open-Source-Software 503 Oracle-Prozessorfaktor, aktuelle Liste (Weblink) Operativer Lizenzmanager 503 395 ––Aufgaben 165 Oracle-Prozessortabelle (Auszug) 396 ––fachliche Kompetenzen 166 Oracle Software Delivery Cloud (Weblink) 406 ––Rollenbeschreibung 164 Oracle Software Investment Guide (Weblink) ––soziale Kompetenzen 166 406 ––Umfragewerte zur Rolle 465 Organigramm Lizenzmanagementrollen, Operatives Lizenzmanagement 449 Verteilung 162 ––administrative Komponenten 452 Organisation und Prozesse ––Aspekte und Komponenten 451 ––detailliertere Darstellung 112 ––emotionaler Aspekt 452 OSI siehe Open Source Initiative 25 ––kaufmännische Komponenten 454 ––lizenzrechtliche Komponenten 454 P ––politischer Aspekt 452 ––rationaler Aspekt 452 Partitioning Option (Oracle) 397 ––Rolle Lizenzverwalter 459 Periodizität 503 ––Rolle Materialstammdatenpfleger 464 Pflichtenheft 503 ––Rollenbild Lizenzmanager 465 ––Anforderung prüfen 264 ––Rolle Software-Katalogmanager 460 ––Beschreibung 263 ––Rolle Softwareverteiler 462 ––Definition 263 ––Rolle Softwarewarenkorb-Verantwortlicher 461 Physikalische CPUs ––Rolle Zentraler Archivverantwortlicher 463 ––Anzal ermitteln 369 ––Schnittstellen 456 f. Platform-as-a-Service (PaaS) 434 ––technische Komponenten 453 PoC ––weitere Rollen 459 ––Aufstellung von Testfällen 287 Optimales Lizenzmodell ––Funktionsorientierte Tests 287 ––Ermitteln (Beispielszenario) 344 ––Gliederung Testkonzept 287 Optimierungsansätze Lizenzmanagement, ––Negativtest 288 Aufzählung 145 ––Positivtest 288 Oracle ––Prozessorientierte Tests 287 ––Interne Verwaltungstabellen 398 Portfolio-Analyse ––Server-Lizenzierung 392 ––Auswertung (Beispiel) 280 ––Überblick genutzte technische Funktionen Praxisbeispiel zur ISO/IEC 19770-1, Tier1-4 139 399 f. Private Cloud 432 Index 517

Product User Rights siehe PUR 37 Prozessortabelle Produktmanipulationen 470 ––Oracle 395 Produktnutzungsrecht, universell 39 Prozessortechnologie für Sub-Capacity-Lizen Produktverantwortlicher (Softwareexperte) 504 zierung bestimmen ––Aufgaben 167 ––IBM 410 ––fachliche Kompetenzen 168 Prozess-Schritt Reporting &Analyse ––Rollenbeschreibung 167 ––Soll-Prozess 310 ––soziale Kompetenzen 168 Prozess-Situation, Übersicht der Änderungen Projektauftrag 145 ––erstellen 77 Public Cloud 432 ––Ziele formulieren 77 PUR, Product Use Rights (Microsoft) 344, 385 Projektdurchführung ––ausgeführte Instanz Beschreibung (Microsoft) ––Aktivitätenplan 90 386 Projektleiter, Rollenbeschreibung 81 ––Auszug Universelle Lizenzbestimmungen Projektmitarbeiter, Rollenbeschreibung 82 (Microsoft) 386 Projektorganisation 80 ––Instanzen erstellen und speichern (Definition) Projektphasen (Microsoft) 387 ––einer Softwarenutzungsanalyse 324 PVU-Tabelle (IBM) 407 ––Fertigstellungsgrade 102 PVU-Werte, Online-Kalkulator (IBM), Weblink Projektplan aufstellen 409 ––Stufen der Umsetzung für ein Lizenzmanage- ment 16 Q ––Qualitätsanspruch 91 ––Umfang beschreiben 90 Quellsysteme, Datenbereinigung 103 Projekt-Roadmap, definieren 94 Projektstrukturplan, Übersicht 99 R Projektziele ––beschreiben 91 RACI 504 ––Rahmenbedingungen 92 Rahmenvertrag 504 Proof of Concept 504 Rangliste der Anwendungshersteller proprietäre Software, Erläuterung 23 ––Übersicht (Beispiel) 308 Prozess „Anforderung“, Beschreibung der Raubkopien und Fälschungen 469 Ist-Situation 117 Rechtswidrige Nutzung Prozess-Assessment 504 ––Beispiele 471 Prozessablauf ––Formen 469 ––Anforderung aus Softwarewarenkorb 150 Regeldatei 504 ––Compliance-Report 153 Reifegradanalyse ––Deinstallation Software 152 ––Benchmarking 130 ––kaufmännische Übersicht 121 ––nach CMMI, Beispielergebnis 134 ––„Neue Software anfordern“, grobe Darstellung Reifegradbestimmung 150 ––CMMI-Modell 131 ––technische Übersicht 121 ––ISO/IEC 19770-1 134 ––Weiterverrechnung Kosten 151 Reifegradmodell Prozesserfüllungsgrade, Merkmale und Stufen ––CMM, CMMI 130 132 ––Erläuterung 130 Prozessmanagement und -schnittstellen, KPI 157 Reifegradstatus Prozessor ––nach ISO/IEC 19770-1, Darstellung der vier ––Einordnung in einer grafischen PVU-Tabelle SAM-Stufen 142 (IBM), Weblink 409 ––nach ISO/IEC 19770-1, Gesamtergebnis 138 ––Leitfaden zur Bestimmung (IBM), Weblink 409 Reifegradstufen, Beschreibung 135 Index 518

Re-Imaging 28 Schichtenmodell IT-Architektur 343 Report (Daten) 504 Server 505 Request of Proposal (ROP) 505 Serverdaten ––Angebotsabgabe 272 ––Grundszenario für das Erfassen 352 ––Gliederung (Beispiel) 273 Server-Hardware, Parameter ermitteln 379 ––Teilnahmebedingungen (Beispiel) 274 Server-Host (physikalischer Server) 380 Richtlinien Server-Lizenzierung ––Erstellen 170 ––Hardwaremerkmale 379 ––Umgang mit Software 169 Server-Lizenzierung (IBM) 406 Risikomanagementsystem siehe RMS 56 Server-Lizenzierung, Microsoft 385 Rolle Auftraggeber 81 Server-Software Rolle Experte 84 ––identifizieren 378 Rolle Lenkungskreis 83 ––Lizenzmodelle der wichtigsten Hersteller 385 Rolle Lizenzverwalter ––lizenzrelevante Parameter 377 ––Aufgaben 459 Server-Umgebungen, Kontextinformationen ––fachliche Kompetenzen 460 ermitteln 379 ––soziale Kompetenzen 460 Servicebereitsteller (Cloud) Rolle Materialstammdatenpfleger ––Nachteile 435 ––Aufgaben 464 ––Vorteile 434 ––fachliche Kompetenzen 464 Servicekategorie 1, Beschreibung 253 ––soziale Kompetenzen 464 Servicekategorie 2, Beschreibung 253 Rolle im Lizenzmanagement, definieren 80, Servicekategorie 3, Beschreibung 253 104 Servicekategorien Rolle Projektleiter 81 ––Einteilungsmatrix 254 Rolle Projektmitarbeiter 82 Servicemodelle, prozentuale Verteilung 436 Rolle Software-Katalogmanager Servicenehmer (Cloud) ––Aufgaben 460 ––Nachteile 435 ––fachliche Kompetenzen 461 ––Vorteile 435 ––soziale Kompetenzen 461 Shareware 505 Rolle Softwarewarenkorb-Verantwortlicher ––Definition 24 ––Aufgaben 461 Sicherungskopie erstellen 51 ––fachliche Kompetenzen 462 SKU (Stock Keeping Unit) 505 ––soziale Kompetenzen 462 SLA 505 Rolle Softwarewareverteiler SMART-Faktoren, die fünf Kriterien 78 f. ––Aufgaben 462 Software 505 ––fachliche Kompetenzen 463 ––falsch lizenziert 469 ––soziale Kompetenzen 463 ––gebraucht 56 Rolle Sponsor 85 ––rechtswidrige Nutzung 486 Rolle Zentraler Archivverantwortlicher ––unlizenziert 30, 469 ––Aufgaben 463 ––unterlizenziert 469 ––fachliche Kompetenzen 464 ––verwalten und managen 61 ––soziale Kompetenzen 464 ––Warum virtualisieren? 330 Software Assurance für Volumenlizenzierung (Weblink) 391 S Softwareanforderer 505 SaaS – Software as a Service 17 ––Definition 176 SAP-Betrieb, Tipps (Weblink)\“. 483 Softwareanforderung, auslösen 177 SB – System-Builder-Software, Definition 35 Softwareanforderungsprozess 505 Scan-Schnittstellen ––beispielhafte Darstellung 178 ––Übersicht 233 ––Übersicht 176 Index 519

Software-as-a-Service (SaaS) 434 ––Geräteklassen 248 Softwareasset- und Lizenzmanagement ––Projekt planen 256 ––Tools und Hersteller 495 ––Prozessablauf (Beispiel) 249 Software-Audit ––Servicekategorien beschreiben 252 ––Ablauf 479 ––Servicekategorien einteilen 254 ––abschließende Maßnahmen 488 ––Softwareklassen (Definition) 247 ––Adobe 483 ––Softwarenutzung definieren 250 ––Anwenderwissen 475 ––strategisch 246 ––Bestandteile und Arten von Lizenznachweisen ––Supportstufen 254 486 ––Warum klassifizieren? 240 ––erforderliche Informationen 485 ––Ziele 242 ––gültiger Lizenznachweis 486 Softwareleasing als neues Modell 19 ––IBM 483 Software-Life-Cycle-Prozess ––Klauseln 477 ––Beschreibung Hauptprozesse 121 ––Lizenznachweise Adobe 487 ––Aufstellung der Hauptprozesse 112 ––Lizenznachweise IBM 487 ––optimieren 143 ––Lizenznachweise Microsoft 486 ––Probleme bei der Analyse 125 ––Lizenznachweise Oracle 487 ––Prozessaufgaben 124 ––Microsoft 483 ––Schnittstellen (KPI) 158 ––Oracle 483 ––Schnittstellen 122 ––Rechtliches 472 ––Überblick 120 ––rechtswidrige Nutzung 469 ––Übersicht Ansprechpartner 113 ––SAP 483 ––Übersicht der Teilprozesse 121 ––Schwierigkeiten der Hersteller 474 ––Übersicht der Teilprozesse in Verantwortung ––vorbereiten 484 des Lizenzmanagements 123 ––Was kommt nach dem Audit? 488 Softwareliste 505 Softwarebeschaffungen, Formen 181, 182 Softwarelizenz 501, 505 Softwarebestellprozess 505 ––Begriffsklärung 22 ––beispielhafte Darstellung 180 ––kaufmännisch 32 ––Beschreibung 179 ––typische Unternehmenssituation 27 Softwaredaten ––Übertragung aus einem Microsoft Vertrag ––kaufmännische Bestandsaufnahme 209 59 Software Identification (SWID)-Tags nach der Softwarelizenz siehe auch Nutzungsrecht 22 Norm ISO 19770 – 2 201 Softwarelizenzkosten optimieren Softwarekatalog ––Maßnahmen 420 ––Aufbau 63 ––Softwarenutzungsanalyse 419 ––erforderliche Daten 63 ––Vorgehen 419 Softwarekategorien, Überblick 154 Software Metering (Softwarenutzungsanalyse) ––Softwarekategorie, Kategorie 1 154 505 ––Softwarekategorie, Kategorie 2 154 ––Übersicht von Messmethoden 320 ––Softwarekategorie, Kategorie 3 155 Softwarenutzung Softwareklassen (SwKl) ––Auswirkungen 318 ––Einteilung nach Best Practice 247, 248 ––Beispiele aus dem Projektgeschäft 315 Softwareklassifizierung ––Einsparpotenziale 323 ––Aufwandskategorien 255 ––Faktoren 317 ––Ausgangssituation 242 ––IT-Bestände identifizieren 316 ––Beispiel 241 ––Lizenzen managen 315 ––Definition 239 ––Praxisbeispiele 325 ––eCl@ss 243 ––Praxismethoden und Ergebnisse 318 ––Fragen 241 ––rechtliche Bestimmungen 50 Index 520

Softwarenutzungsanalyse Sub-Capacity-Produkte (IBM), Beispielprüf ––Beispiel Microsoft Office Standard und Pro bericht 412 fessional 322 Sub-Capacity-Umgebungen ––grober zeitlicher Projektablaufplan 325 ––Ausnahmen 411 ––Übersicht Projektphasen 324 ––Bedingungen 411 ––Was wird gemessen? 323 ––Voraussetzungen (IBM) 410 Softwarepaket, Bestandteile der Verkaufsver Subcaplicensing (IBM), Weblink 411 packung 34 Supportstufen 505 Software-Pool 502 System Builder Software 506 Softwareportfolio 505 Systeminformation, Windows-Oberfläche 204 ––Beschreibung 66 Szenario 2\ ––Informationsbestandteile 64 ––Microsoft-Office-Lizenzierung in einer Citrix- Softwareprodukte Umgebung 365 ––Bestandsaufnahme in der klassischen PC-Umgebung 188 T ––Bestandsaufnahme in Server-Umgebungen 188 Tatsächliche Softwarenutzung ––in Cloud-Umgebungen, neue Verbrauchs ––Auswertung (Praxisbeispiel) 321 modelle 19 Technische Bestandsaufnahme, Vorgehen und ––technische Bestandsaufnahme 187 Planung 189 ––Übersicht der Nutzung 317 Technische Datenbereinigung ––Verteilung 62 ––Planung 232 Softwarevirtualisierung Technische und kaufmännische Daten ––Arten von Virtualisierungsumgebungen 334 ––Szenarien zur Erhebung 207 ––Auswirkungen 336 Technischer Report 506 ––Grundlagen 333 Teilprozess, Bedarfsmeldung managen 133 ––Kernfragen 331 Testablauf ––mögliche Konzepte 335 ––Abnahmespezifikation erstellen 300 ––Nachteile 334 ––Rahmenbedingungen formulieren 299 ––Voraussetzungen schaffen 331 ––schematische Darstellung 299 ––Vorgehen 329 Testbedarfsmeldung, Inhaltsbeschreibung ––Vorteile 336 (Beispiel) 297 Softwarewarenkorb 68, 505 Testbericht erstellen, Beispiel 298 Soll-Prozess, Gesamtübersicht 149 Testdokumentation 506 SOX 55 Testdokumente nach ANSI/IEEE Sponsor, Rollenbeschreibung 85 ––Übersicht 296 Standardanwendungen Testdurchführung ––Beschreibung 250 ––Ablaufplan (Beispiel) 300 ––optionale Fachbereichsanwendungen 251 Testkonzept, Gliederung (PoC) 287 ––spezifische Fachbereichsanwendungen 250 Testlizenz 506 Strategische Softwareklassen 505 Testprozess 506 Strategischer Lizenzmanager (StLM) 505 Testvorschrift ––Aufgaben 163 ––Ablauf 297 ––fachliche Kompetenzen 164 ––Aufbau und Gliederung 296 ––Rollenbeschreibung 163 The Cloud (Wolke) 18 ––soziale Kompetenzen 164 Theory of PVU Licenses (IBM Developer Blog), Studie IT-Lohnkosten, KPMG 317 Weblink 409 Sub Capacity, Beschreibung 361 TNSListener (Transparent Network Substrat) 401 Sub-Capacity-Lizenzbedingungen (IBM), Anlage Toolauswahl, Anforderungsbeschreibung 101 411 Tuning Pack (Oracle) 398 Index 521

U Virtualisierungstechnologie Power VM (IBM) 414 Überlizenzierung 506 Virtualisierungsumgebung, Definition (IBM) 410 ––Definition 27 Virtuell Desktop Infrastuktur Lizenzabdeckung Übertragung von FPP, OEM, Schulversionen 58 ––Detaildarstellung einer Compliance-Berech- Umgang mit Software nung 309 ––Richtlinien 169 Virtuelle Instanzen Universelle Lizenzbestimmungen, Auszug ––Ermitteln der Anzahl 370 Microsoft Volumenlizenz 39 VMware, VMotion 383 Universelles Produktnutzungsrecht 506 Vollprodukt 507 Unlizenzierte Software 469 Vollversion 507 Unterlizenzierte Software 469 Volumenvertrag 59 Unterlizenzierung 506 ––Definition 29 Update 506 W Upgrade 506 Wartung 507 Urheberrecht (UrhG) 506 WiBe Wirtschaftlichkeitsbetrachtung 278 ––Beschreibung 51 Windows Server 2012, Lizenzberechnung für Urheberrechtsgesetz (UrhG) 469 Installationsszenarien 369 ––Ansprüche des Herstellers 53 Windows Server 2012 R2 ––Lizenzierungsberechnung (Beispiel) 370 V ––Lizenzierung 366 ––Unterschiede der Editionen und Virtualisie- Verhältnis zwischen der Anzahl von Anwendun- rungsrechte 368 gen und der Softwarenutzung 320 ––Überblick Downgrade-Rechte 368 Verkauf von gebrauchter Software, Hinweise ––Überblick Lizenzmodell 367 471 Windows-Server-2012-Datacenter-Edition Vertragsart 506 ––Wie viele Lizenzen sind erforderlich? 371 Vertragsdatenbank, Aufbau 103 Wirtschaftlichkeitsbetrachtung (WiBe) 278, 507 Vertragsdaten ––Ergebnisse 281 ––Fragen 218 Wolke – The Cloud (Beschreibung) 18 ––Komplexitätstreiber 218 Work-at-home siehe auch Zweitkopie 46 Vertragsmanagement ––Daten aus SAP (Beispiel) 214 ––erforderliche Lizenzinformationen 213 Y ––Nutzen 210 Y-Modell des Lizenzmanagements 12 ––spezifische Daten 212 ––Vertragsformen 211 ––Voraussetzung schaffen 213 Z ––wichtige Punkte 210 Zivilrechtliches Besichtigungsrecht 472 ––zu erfassende Daten 212 Zugriff über das Internet Vertriebskanalmissbrauch 471 ––grober Bebauungsplan 345 Vervielfältigungsrecht 51 Zweitkopie siehe auch Work-at-home 46 Virtual Desktops Infrastructure (VDI) 329 Virtualisierte Umgebung ––Nutzungsformen 441 Virtualisierung ––im IBM-Umfeld, Aspekte 413 ––mit Microsoft-Produkten (Weblink) 391 ––Power VM (IBM) 383 Virtualisierungskapazität 387