Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1 Einleitung
1.1 Ziele der Arbeit
1.2 Vorgehensweise
2 Grundlagen - Compliance
2.1 Corporate Compliance
2.1.1 Begrifflichkeiten und Zweck der Compliance
2.1.2 Risikopotential
2.1.3 Elemente der Compliance in einem Unternehmen
2.2 IT-Compliance
2.2.1 Einordnung auf konzeptioneller Ebene
2.2.2 Definition IT-Compliance
2.2.3 Einflussfaktoren und Ziele von IT-Compliance
2.2.4 Aufgaben und Maßnahmen der IT-Compliance
2.3 Zusammenhang zwischen IT-Compliance und Software-Asset-Management
3 Grundlagen - Software-Asset-Management
3.1 Definition
3.2 Ausgangssituation und Notwendigkeit einer SAM-Einführung
3.2.1 Die Herausforderungen einer SAM-Einführung
3.3 Ziele und Potentiale des Software-Asset-Managements
3.4 Gängige Modelle des Software-Asset-Managements
3.4.1 Grundlagen und Begrifflichkeiten
3.4.2 Praxismodell nach Torsten Groll
3.4.3 SAM-Referenzmodell nach ISO 19770
3.5 Organisatorische Einordnung des SAM
3.6 Zusammenfassung
4 Grundlagen – Software-Lizenz
4.1 Begriffsklärung
4.2 Lizenzkategorisierung
4.3 Klassische Modelle der Software-Lizenzierung
4.3.1 Die Lizenzart
4.3.2 Die Lizenzklasse
4.3.3 Der Lizenztyp
4.3.4 Die Lizenzmetrik
4.4 Lizenzmodelle der Zukunft
4.5 Schlussfolgerungen aus der Vielfalt der Lizenzmodelle
5 Reifegradmodelle im SAM
5.1 Einleitung und Definition
5.2 Grundlegende Charakteristika
5.3 Referenzmodelle zur Bestimmung des Reifegrades
5.3.1 Capability Maturity Model Integration (CMMI)
5.3.2 Erkenntnisse aus dem CMMI-Modell
5.4 Das COBIT-Reifegradmodell
5.4.1 Erkenntnisse aus dem COBIT-Modell
5.5 ITIL – Process Maturity Framework (PMF)
5.5.1 Erkenntnisse aus dem ITIL PMF-Modell
5.6 Deloitte - SAM Muturity Modell
5.6.1 Erkenntnisse aus dem Maturity-Modell nach Deloitte
5.7 Microsoft - SAM Optimization Model (SOM)
5.7.1 Erkenntnisse aus dem SAM Optimization Model
5.8 Erstellung eines gültigen SAM-Reifegradmodells
5.8.1 Auswahl der SAM-Kompetenzgruppen
5.8.1.1 SAM-Governance
5.8.1.2 Richtlinien und Prozeduren
5.8.1.3 Technologie
5.8.1.4 Rollen und Verantwortlichkeiten
5.8.1.5 Kontinuierlicher Verbesserungsprozess
5.8.1.6 Verbreitung und Implementierung
5.8.2 Zuordnung der Kompetenzen zu SAM-Kompetenzgruppen
5.9 Das SAM-Reifegradmodell
6 Der Leitfaden – Eine Vorgehensweise zur stetigen Entwicklung
6.1 Begriffsdefinition
6.2 Aufbau des Leitfadens und Abgrenzung zum SAM-Reifegradmodell
6.3 Wechselwirkungen des Leitfadens mit Reife, Risiko und Compliance
6.4 Generelle Vorgehensweise – Vom SAM-Projekt zum SAM-Organisationsprozess
7 Das SAM-Haus - Ein Leitfaden zur Entwicklung des Software-Asset-Managements
7.1 Das SAM-Fundament
7.1.1 SAM-Governance
7.1.2 SAM-Organisation
7.1.3 Zentralisierung des Einkaufs
7.1.4 Reifegradverbesserung durch das SAM-Fundament
7.2 SAM-Standardisierung
7.2.1 Prozesse
7.2.1.1 Allgemeine Vorgehensweise bei der Prozessoptimierung
7.2.1.2 Konkrete Optimierungsvorschläge am Beispiel von Beschaffungs- und IMAC-Prozessen
7.2.2 Daten und Tools
7.2.3 Software-Lieferanten
7.2.4 Reifegradverbesserung durch die SAM-Standardisierung
7.3 SAM-Rationalisierung
7.3.1 SAM-Technologien
7.3.2 Kontinuierlicher Verbesserungsprozess
7.3.3 Reifegradverbesserung durch die SAM-Rationalisierung
7.4 SAM-Agilität
7.4.1 SAM-Strategie
7.4.1.1 Ausrichtung am Business
7.4.1.2 Die Rolle des Software-Asset-Managements im Unternehmen stärken
7.4.2 Qualifizierung der Mitarbeiter
7.4.3 Reifegradverbesserungen durch die SAM-Agilität
8 Ausblick und Zusammenfassung
Literaturverzeichnis
Anhang
Abb. 1 Bedeutung der Software-Lizenzen
Abb. 2 Elemente der Compliance
Abb. 3 Konzeptioneller Rahmen der IT-Compliance
Abb. 4 Einflussfaktoren der IT-Compliance
Abb. 5 Bestandteile des Software-Asset-Managements
Abb. 6 Lizenzmanagement als Teil des SAM
Abb. 7 SAM-Verbreitung in den Unternehmen
Abb. 8 Zielvorgaben des SAM
Abb. 9 Potentiale des SAM
Abb. 10 Software-Life-Cycle-Prozessübersicht nach Groll
Abb. 11 Vertikale Einordnung im Unternehmen
Abb. 12 Horizontale Einordnung im Unternehmen
Abb. 13 Kategorisierung von Software
Abb. 14 Reifegradstufen und steigende Leistungsfähigkeit
Abb. 15 Veränderungsprozess zwischen den Reifegraden
Abb. 16 Genereller Aufbau eines SAM-Reifegradmodells
Abb. 17 Erweiterung des bisherigen Modells nach COBIT
Abb. 18 Entwicklungspfad der IT
Abb. 19 Reifegrade des SAM Optimization Model
Abb. 20 Abhängigkeiten des Leitfadens
Abb. 21 SAM-Governance-Modell
Abb. 22 SAM-Fundament
Abb. 23 Betrachtungsgegenstand der Prozessoptimierung
Abb. 24 Konzept eines SAM-Tools
Abb. 25 SAM-Standardisierung
Abb. 26 Datenfluss im SAM-Lebenszyklus I
Abb. 27 Datenfluss im SAM-Lebenszyklus II
Abb. 28 Effizienter SAM-Prozess
Abb. 29 Kontinuierlicher Verbesserungsprozess
Abb. 30 SAM-Rationalisierung
Abb. 31 Drei Ebenen der Veränderung
Abb. 32 Auswirkung von Richtlinien auf die Mitarbeiter
Abb. 33 SAM-Agilität
Abb. 34 Das SAM-Haus
Abb. 35 Prozesssteckbrief
Tab. 1 Für Compliance relevante Gesetze und Regelwerke
Tab. 2 ISO 19770 - Überblick über die Prozesse von SAM
Tab. 3 Lizenzklassen
Tab. 4 Die gängigsten Lizenztypen
Tab. 5 Reifegrade von CMMI
Tab. 6 Fähigkeitsgrade nach CMMI
Tab. 7 Reifegrade in COBIT
Tab. 8 Vergleich der Maturitätsattribute (ITIL und COBIT)
Tab. 9 SAM-Kompetenzen nach Deloitte
Tab. 10 SAM-Reifegrade nach Deloitte
Tab. 11 Die 10 SOM-Kompetenzen
Tab. 12 SOM Fragebogen zur Einschätzung der Reife
Tab. 13 Abbildung der Modelle auf SAM-Kompetenzgruppen
Tab. 14 SAM-Reifegradmodell
Tab. 15 SAM-relevante IT-Technologien
Abbildung in dieser Leseprobe nicht enthalten
In den vergangen Jahrzehnten hat uns keine andere Technologie so geprägt wie die Informationstechnologie (IT). Die Erfindung des Computers und die damit zusammenhängende, digitalisierte Verarbeitung von Informationen haben auf vielen Gebieten einen Quantensprung ausgelöst. Computer sind aus dem heutigen Arbeitsleben nicht mehr wegzudenken. Es ist jedoch nicht die Hardware des Computers, die einen direkten Einfluss auf den Nutzen für das Unternehmen hat, es ist vor allem die Software. Die Software steht sinnbildlich für alle datenverarbeitenden Anwendungen und hat eine tiefgehende Verankerung in allen Geschäftsprozessen. Ein Unternehmen kann heute seinem Geschäft ohne Software nicht nachgehen. Die Nutzung von Software ist die elementare Voraussetzung für den Geschäftserfolg. Um Software nutzen zu können brauchen Unternehmen eine Erlaubnis vom Softwarehersteller. Diese Erlaubnis wird in Form einer Lizenz, mit Bedingungen und definierten Rechten, an die Unternehmen ausgestellt. Die Abhängigkeit von Lizenzen, Software und dem eigentlichen Geschäftsbetrieb wird in der unteren Grafik abgebildet. Aus wirtschaftlicher Sicht ist es immens wichtig den Betrieb des Unternehmens durch ausreichende und korrekte Lizenzierung sicherzustellen.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1 Bedeutung der Software-Lizenzen[1]
Die hohe Verankerung der Software in allen Geschäftsprozessen hat eine enorme Steigerung der Kosten im Betrieb und Wartung der Computersysteme und darauf laufender Anwendungen zur Folge. Aufgrund von Anpassungen und Erweiterungen des IT-Portfolios an sich ständig ändernde Marktbedingungen sind Unternehmen gezwungen immer mehr Geld in die Entwicklung der IT zu investieren, um Softwaresysteme stabil und lauffähig zu halten. Der wirtschaftliche Druck der vergangenen Jahre und die stetig wachsende Konkurrenz aufgrund globaler Märkte erfordern ein hohes Kostenbewusstsein. Da IT-Kosten schon seit Längerem zu mehr als einem Drittel aus den Kosten für neue Software oder Software-Wartungsgebühren bestehen[2], sind Unternehmen gezwungen auch diesen Kostenblock zu analysieren und Einsparpotentiale zu ermitteln.
An dieser Stelle eröffnet sich ein Spannungsfeld, welches den Umgang mit Software in der Gegenwart und Zukunft erschwert und weiterhin erschweren wird. Die Kostenoptimierung der Softwarenutzer wird gleichzeitig zu einem Rückgang der Einnahmen auf der Seite der Softwarehersteller und Softwareanbieter führen. Diese sehen sich gezwungen den Wegfall der Einnahmen durch andere Quellen zu kompensieren. Dazu gehören z. B. Überprüfungen des Softwareeinsatzes bei den Unternehmen im Rahmen von Audits. Diese sollen Lizenzverstöße identifizieren und so die verlorenen Einnahmen wieder einbringen. Laut einer durchgeführten Gartner-Studie hat sich die Wahrscheinlichkeit durch einen Softwarehersteller auditiert zu werden, von 35% im Jahr 2007 zu 65% im Jahr 2011 nahezu verdoppelt[3]. Heute kann durchaus von höheren Prozentzahlen ausgegangen werden. Die hohe Aufmerksamkeit der Hersteller und die regelmäßige Überprüfung der Nutzung verursachen auf beiden Seiten den Bedarf und den Wunsch die Lizenzbestimmungen möglichst genau zu definieren und festzuschreiben. Hier sind die Software-Anwender, also Unternehmen, die die Software nutzen, in einer nachteiligen Position. Sie können auf die Nutzungsbestimmungen nur reagieren und müssen das einhalten, was der Hersteller vorgibt. Aufgrund der Agilität und der sehr raschen Entwicklung der IT, ändern sich die Programme und die Versionen stetig und verursachen eine ebenso ständige Änderungen der Nutzungsbedingungen. Da ein Unternehmen meistens unterschiedliche Software von verschiedenen Softwareherstellern einsetzt, bewirkt dieses Maß an Komplexität einen enormen Aufwand in der Verwaltung der Software. Hinzu kommt noch die Schwierigkeit, dass Software ein immaterielles Gut ist und aus diesem Grund sehr schwer inventarisiert und verwaltet werden kann. Unternehmen stehen daher vor einer enormen Herausforderung. Auf der einen Seite sind sie durch die Lizenzbestimmungen an gewisse Regeln und Richtlinien gebunden und müssen sich im schlimmsten Falle auch vor Gericht verantworten. Auf der anderen Seite können sie aufgrund der Schnelllebigkeit und der vielen Veränderungen in den IT-Landschaften keine vollends korrekte, punktuelle Aussage zu der aktuellen Lizenzsituation machen. Der Kostendruck sowohl auf der Seite der Lizenzausgaben als auch bei den Ausgaben für die Sicherstellung einer korrekten Nutzung der Software ist in der heutigen wirtschaftlichen Lage sehr hoch und trägt zur Intensivierung der Situation bei. Alle Unternehmen, insbesondere die mittelständischen und großen Unterhemen, müssen sich daher in diesem Spannungsfeld bewegen und sich die Frage stellen, wie sie mit der eingesetzten Software richtig umgehen können. Diese Herausforderungen gilt es unter Befolgung des Wirtschaftlichkeitsprinzips zu meistern.
Die vorliegende Master-Thesis bietet eine wissenschaftliche Einführung in das Thema Software-Asset-Management (SAM) und soll Unternehmen helfen ihre Kompetenzen und ihren Reifegrad im Umgang mit Software-Assets zu optimieren. Vordergründig ist diese Arbeit an mittlere und große Unternehmen gerichtet, die global tätig sind. Diese sind in der aktuellen Situation von den in der Einleitung erwähnten Problemen am meisten betroffen. Sie stehen nämlich im Fokus der stetig wachsenden Anzahl von Audits und somit im erläuterten Spannungsfeld. Mit dieser Arbeit werden drei wesentliche Ziele verfolgt. Zum einen dient die Arbeit dazu das Thema Software-Asset-Management allumfänglich darzustellen und die Probleme, Herausforderungen, Ziele und Lösungen zu erläutern. Als zweites Ziel soll ein Bewertungsverfahren hergeleitet werden, wie der Reifegrad des Software-Asset-Managements in einem Unternehmen bestimmt werden kann. Die Bewertungsmatrix soll eine korrekte Einschätzung ermöglichen und Aussagen über die Schwächen und Stärken geben. Hierzu werden gängige Reifegradmodelle analysiert und miteinander verglichen. Das dritte und wichtigste Ziel dieser Arbeit besteht darin den Unternehmen eine Antwort auf die folgende Fragestellung zu geben: Wie können Unternehmen ihren Umgang mit Software-Assets optimieren, um den Herausforderungen der aktuellen Situation gewachsen zu sein? Um diese Frage zu beantworten, wird in dieser Ausarbeitung eine Schritt-für-Schritt-Anleitung, ein sogenannter Leitfaden entwickelt. Diese Anleitung wird einen möglichen Entwicklungspfad aufzeigen, wie Unternehmen ein ganzheitliches SAM-Programm etablieren und weiter optimieren können. Durch diesen Leitfaden und durch die Bewertungsmatrix werden Unternehmen in die Lage versetzt ihren aktuellen Umgang mit Software-Assets zu analysieren und daraus Maßnahmen ableiten zu können, wie der Umgang mit diesen Assets verbessert werden kann. Durch die Optimierung ergeben sich folgende strategische Vorteile:
1. Transparenz: Durch die Analyse des Software-Asset-Managements gewinnt das Unternehmen viele neue Erkenntnisse und kann daraus weitere Optimierungen und Vereinfachungen generieren.
2. Kostensenkungen: Ein optimales SAM erkennt Einsparungspotentiale und hilft bei der Beschaffung, Nutzung und Stilllegung von Software Kosten einzusparen.
3. Compliance: Der korrekte Umgang mit Software-Lizenzen bewahrt vor negativen Ergebnissen im Falle eines Audits und sichert die rechtmäßige Nutzung. Das rechtliche Risiko wird deutlich minimiert.
Zu Beginn dieser Arbeit werden die wichtigsten Grundlagen erläutert, die dem besseren Verständnis der Materie dienen und einen Einstieg in die gesamte Thematik ermöglichen. Dies ist zum einen das große Feld der Compliance. Compliance wird aus den IT-relevanten Gesichtspunkten beleuchtet und Anforderungen an das Software-Asset-Management werden daraus abgeleitet. Im zweiten Grundlagenkapitel wird Software-Asset-Management als Teildisziplin der IT-Organisation dargestellt und mit allen Facetten erörtert. Es werden die wichtigsten Techniken, Normen, Prozesse, Problemstellungen und Potentiale erläutert, um einen Gesamtüberblick zu diesem Thema zu geben. Der letzte Teil der Grundlagen beschäftigt sich mit Software-Lizenzen und gibt einen Überblick über die unterschiedlichen Lizenzformen, die Software-Typen, die Metriken und die bestehenden Lizenzmodelle. Es werden Erkenntnisse für die Unternehmen geschaffen, welchen Herausforderungen im Bereich der Software-Lizenzierung sie sich zu stellen haben und wie sie die Vielfalt der unterschiedlichen Typen besser verwalten können.
Auf den Grundlagen aufbauend wird sich die Arbeit mit Reifegradmodellen im Software-Asset-Management auseinandersetzen. Es werden die am Markt und in der Praxis vorhandenen Reifegradmodelle analysiert und bewertet. Diesem Kapitel kommt eine hohe Bedeutung zu, da Unternehmen nur durch eine korrekte Analyse des eigenen Reifegrades im Umgang mit Software-Assets Schritte zur weiteren Optimierung ableiten können. Am Ende dieses Kapitels werden die wichtigsten Aspekte der untersuchten Reifegradmodelle miteinander verglichen und ausgewählte Kriterien in ein hybrides Bewertungsmodell überführt und ergänzt. Das Ziel ist es ein möglichst objektives Reifegradmodell zu entwickeln.
Im Hauptkapitel, der Entwicklung des Leitfadens, geht es um eine schrittweise Empfehlung möglicher Optimierungen im Umgang mit Software-Assets. Aus den wichtigsten Erkenntnissen der Reifegradkriterien des vorherigen Kapitels werden Entwicklungsstufen abgeleitet, die bestimmte Maßnahmen empfehlen, um zur nächsten Stufe des Reifegradmodells aufzusteigen. In die Entwicklung dieses Leitfadens fließen sowohl die Ergebnisse der Grundlagenkapitel, als auch die Analyse der aktuellen Herausforderungen am Markt ein. Das Ziel ist es den Unternehmen einen Weg aufzuzeigen, wie die Verwaltung der Software-Assets im übertragenen Sinne und der Umgang mit Software-Lizenzen im eigentlichen Sinne verbessert werden kann und welche Vorteile sich daraus ergeben.
Im letzten Kapitel der Masterthesis werden die wichtigsten Ergebnisse zusammengefasst und ein Gesamtbild des erstellten Leitfadens visualisiert. Zusätzlich wird ein Ausblick gegeben mit welchen Herausforderungen sich die Unternehmen in Zukunft noch intensiver auseinander setzen müssen. Denn aufkommende, neue IT-Technologien erschweren den Umgang mit Software-Assets und erfordern eine stetige Überprüfung und Verbesserung des Software-Asset-Managements.
Ende des 20. und Anfang des 21. Jahrhunderts gab es in der Weltwirtschaft einige spektakuläre Unternehmenspleiten, die auf einen Betrug von Bilanzsummen oder Verschleierung von Verlusten zurückzuführen sind. Als prominentes Beispiel können an dieser Stelle zwei Unternehmen aufgeführt werden, die nach der Aufdeckung der Betrugsfälle Insolvenz anmelden mussten. Das Unternehmen Enron gehörte Ende der 90er Jahre zu den größten Energieunternehmen der USA und erlitt aufgrund starker Expansionsbestrebungen und des Absinkens der Energiepreise starke Verluste. Diese Verluste wurden intern durch diverse Maßnahmen verschleiert, um die Bilanzsumme künstlich zu verbessern. Diese Maßnahmen waren nur möglich, da interne Kontrollsysteme unzureichend entwickelt waren und die Entscheidungsträger so einen großen Spielraum bei der Ausgestaltung hatten. Nach Anmeldung der Insolvenz 2001 wurden diese Machenschaften aufgedeckt und die Verantwortlichen zur Rechenschaft gezogen. Ein anderes prominentes Beispiel ist der Untergang einer der größten Telefongesellschaft der Welt im Jahr 2002: Worldcom. Auch hier wurde die negative Bilanzsumme, die sich aus den schwierigen Konjunkturzeiten und Fehlinvestitionen ergab, durch Falschausweise verschleiert. Die Durchführung dieses Betrugs ist ebenfalls auf fehlende Kontrollsysteme und die große Macht von Unternehmenseignern und Managern zurückzuführen. Diese und noch andere Pleiten waren der Auslöser für die Forderung nach mehr Transparenz durch die Gesetzgeber und Aufsichtsbehörden. Es entwickelte sich der Trend, Unternehmen über regulatorische Vorgaben und Anforderungen zu einer transparenten Unternehmensführung zu bewegen und so wieder mehr Vertrauen in die Märkte zu bringen[4]. Die Erfüllung solcher Anforderungen und Vorgaben wird als Compliance bezeichnet. Sie ist ein Ziel unternehmerischen Handelns, da die Nichteinhaltung zu Risiken für das Unternehmen und dessen Management führen kann.
Als Reaktion auf die kriminellen Praktiken in der Betriebsführung wurden national und international neue Gesetze und Regulierungen geschaffen, denen vom Manager bis zum normalen Mitarbeiter alle unterliegen. Nicht selten wurden darüber hinaus aus Eigeninteresse unternehmensspezifische Regeln aufgestellt, die ebenfalls unter den Aspekt der Compliance fallen und von den Unternehmen befolgt werden. Schneider definiert in einem Zeitschriftenbeitrag die Compliance folgendermaßen:
„Compliance umfasst die Gesamtheit aller Maßnahmen, um das rechtmäßige Verhalten aller Unternehmen, ihrer Organmitglieder, ihrer nahen Angehörigen und der Mitarbeiter im Blick auf alle gesetzlichen Gebote und Verbote zu gewährleisten.“ [5]
Die folgende Tabelle gibt einen Überblick über bestehende Gesetze und externe Regelwerke:
Abbildung in dieser Leseprobe nicht enthalten
Tab. 1 Für Compliance relevante Gesetze und Regelwerke[6]
Darüber hinaus existieren noch weitere Regelwerke und Gesetze, wie etwa das Bundesdatenschutzgesetz (BDSG), der ISO-Standard 17799, aber auch das für das Software-Asset-Management wichtige Urheberrechtsgesetz (UrhG). Alle genannten Gesetze zielen im Groben darauf ab, die Unternehmen zu einem Einsatz von Risikomanagementsystemen und internen Kontrollsystemen (IKS) zu bewegen. Dadurch soll die Sicherheit und Transparenz im Unternehmen gestärkt und gefördert werden und damit der Fortbestand und die Entwicklung des Unternehmens sichergestellt werden.
Verstärkt wurde der Fokus auf das Compliance-Thema durch weitere aufkommende Skandale, wie die Schmiergeldaffäre bei Siemens, die Korruptionsaffäre bei Volkswagen oder die Mitarbeiterüberwachung bei Lidl. Es wurde deutlich, dass die Nichtbeachtung der Compliance-Regeln nicht nur wirtschaftlich-rechtliche Schäden mit sich führt, sondern vor allem auch das Ansehen des Unternehmens gefährdet. Ein Verstoß gegen die Compliance-Richtlinien, ob intern oder extern, kann für das Unternehmen dramatische Folgen haben und bis zu strafrechtlichen Maßnahmen gegen Management und Mitarbeiter führen.[7] Untenstehend werden einige wichtige Konsequenzen für die Nichteinhaltung aufgeführt.[8]
- Gefährdung des Unternehmens durch negative Berichte in den Medien über Missstände im Unternehmen
- Werteverfall für die Shareholder
- Eingreifen des Aufsichtsrates und Aufsichtsbehörden
- Vergabesperre und „Blacklisting“ für künftige Aufträge
- Betriebsstillegung
- Unternehmenskrise, Gefährdung der Arbeitsplätze
- Bußgelder bis zu 10% des Konzernumsatzes
- Verfall des mit inkriminierten Geschäften erzielten Gewinns an die Staatskasse
- Untersuchungshaft und Freiheitsstrafen für Manager
- Geldstrafen für Management und Unternehmen
- Einstweilige Verfügungen gegen die Durchführung einzelner Geschäftsaktivitäten
- Pfändung von Bankkonten
- Schadensersatzforderungen durch Kunden, Wettbewerber und Verbraucher
- Aufwändige Beschäftigung des Managements mit Verteidigungsaktivitäten zu Lasten der Konzentration auf das Geschäft
- Bedrohung der beruflichen Existenz der Organmitglieder
Die oben genannten Konsequenzen gilt es der Sicht des Unternehmens zu vermeiden, da diese Punkte einen potentiellen Schaden bedeuten. Dieser Schaden kann gemeinsam mit einer vorhandenen Bedrohung (Fahrlässigkeit, Vorsatz oder organisatorische Mängel) und einer gewissen Eintrittswahrscheinlichkeit als Risiko für das Unternehmen definiert werden. Das große Ziel der Compliance ist es dieses Risiko zu minimieren und die genannten potentiellen Schäden abzuwenden. Hierzu müssen Sicherheitsmaßnahmen ergriffen werden, die der Unternehmensleitung helfen, die Risiken zu überwachen und zu managen.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2 Elemente der Compliance[9]
Zur Konkretisierung und Einordnung der Sicherheitsmaßnahmen können die fünf Elemente aus dem obigen Schaubild herangezogen werden. Dies sind die organisatorischen Kernbereiche der Compliance, mit denen die Unternehmensleitung die Compliance durch Definition und Überwachung von Maßnahmen steuern kann. Compliance ist in erster Linie die Aufgabe der Geschäftsführung. Die Geschäftsführung hat dafür Sorge zu tragen, dass Compliance als Prozess im gesamten Unternehmen gelebt wird und von allen Mitarbeitern befolgt wird, um rechtliche und wirtschaftliche Risiken zu minimieren. Die Risikominimierung erfordert eine etablierte Risikoanalyse, die sich mit der Identifikation und der Einschätzung des Risikos beschäftigt. Erst wenn die Risiken, die potentielle Schäden hervorrufen können, identifiziert sind, können präventive Maßnahmen ergriffen werden. Im zweiten Schritt ist eine klare Positionierung der Unternehmensleitung notwendig. Compliance-Bestrebungen dürfen nicht nur auf dem Papier bestehen, sondern müssen von der Geschäftsführung vorgelebt werden.[10] Nur so können die Mitarbeiter und die externen Interessensvertreter von der Einhaltung aller Regelwerke überzeugt werden. Im nächsten Schritt muss genau diese Haltung publik gemacht werden und sowohl intern, als auch extern kommuniziert werden. Üblicherweise machen es Unternehmen durch die Verabschiedung eines „Mission Statement“ seitens der Geschäftsführung oder durch das Verfassen und Publizieren eines eigenen internen Regelwerks, wie z. B. eines Code of Conduct. Weitere Maßnahmen könnten regelmäßige Schulungen der Mitarbeiter sein, wie sie bei Siemens nach der Schmiergeldaffäre eingeführt worden sind. Zur Nachverfolgung und der ständigen Überprüfung der Compliance ist es ratsam eine speziell dafür vorgesehene Organisation im Unternehmen aufzubauen. Dieses könnte die Einsetzung eines Compliance-Beauftragten oder die Einrichtung einer ganzen Compliance-Abteilung bedeuten.[11] Aufgaben dieser Organisation bestehen in der Nachverfolgung aller Compliance-Aktivitäten und der konstanten Weiterentwicklung der Compliance im gesamten Unternehmen. Das wichtigste Ziel der Compliance, die Reduzierung der Risiken durch Schaffung von Transparenz, wird mit dem letzten Element abgeschlossen. Das Unternehmen erweist sich erst dann als glaubwürdig, wenn es die Einhaltung der diversen Regelungen auch tatsächlich nachweisen kann. Dies erfolgt durch die Dokumentation aller Entscheidungen, Prozesse und Maßnahmen. In der Praxis wird diese Dokumentation in ein internes Kontrollsystem integriert und so in einem regelmäßigen Prozess an die Interessensvertreter berichtet. Als IKS wird die „Gesamtheit aller aufeinander abgestimmten und miteinander verbundenen Kontrollen, Maßnahmen und Regelungen“[12] bezeichnet. Die fünf Kernbereiche der Compliance stehen in einer ständigen Wechselwirkung miteinander und können in einem Unternehmen in einen PDCA-Zyklus (Plan-Do-Check-Act) zur Risikominimierung durch Compliance integriert werden. Ein PDCA-Zyklus ist ein immer wiederkehrender Kreis von definierten Vorgängen, die eine kontinuierliche Weiterentwicklung eines Themas sicherstellen. Er besteht aus vier Phasen, die im Folgenden auf die Compliance bezogen erläutert werden:
1. Plan: Formulierung der gültigen Richtlinien und der Compliance-Ziele in einem Code of Conduct und Planung der Maßnahmen zur Zielerreichung (Commitment)
2. Do: Die Schaffung einer Compliance-Kultur im Unternehmen durch Kommunikation, Schulungen und vorbildliches Verhalten der Unternehmensleitung (Kommunikation und Organisation)
3. Check: Überprüfung der Compliance-Situation durch interne oder externe Audits und durch Erfolgskontrollen in der Handhabung von Risiken (Dokumentation)
4. Act: Überprüfung der geltenden Rechte und Richtlinien unter Berücksichtigung der Ergebnisse aus der Check-Phase. Erarbeitung möglicher Korrekturvorschläge, die im nächsten Plan-Zyklus Einzug finden (Risikoanalyse)
So können alle wesentlichen Compliance-Elemente immer wieder einer Überprüfung und Optimierung unterzogen werden.
Die Corporate Compliance lässt sich in der Wirtschaft dem Fachgebiet der Corporate Governance unterordnen. Unter Corporate Governance wird die Gesamtheit aller Regeln zur Steuerung und Überwachung des Unternehmens zusammengefasst. Compliance ist dabei nur ein Teil, der sich mit der Einhaltung dieser Regeln beschäftigt. IT-Compliance ist dabei nur ein Teil der Corporate Compliance und ist mit dieser aufgrund der stetig zunehmen Komplexität der Geschäftsprozesse eng verknüpft.[13] Auch in der IT wird zwischen IT-Governance und IT-Compliance unterschieden.
„IT-Governance ist ein Prozess der verantwortungsvollen Steuerung von IT, der durch transparente Regeln und Kontrollmechanismen die optimale Unterstützung der Geschäftsprozesse durch IT sicherstellt. IT-Governance befasst sich mit dem (1) Wertbeitrag der IT, dem (2) IT-Risikomanagement und der (3) IT-Compliance.“ [14]
Das folgende Schaubild stellt schematisch die Beziehung der genannten Fachgebiete dar und weist darüber hinaus die jeweiligen Interessensgruppen, Rahmenbedingungen und Standards / Frameworks des jeweiligen Bereichs aus:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3 Konzeptioneller Rahmen der IT-Compliance[15]
Wie im vorherigen Kapitel bereits angedeutet, ist IT-Compliance eine Querschnittfunktion, die sowohl Teil der Corporate Compliance als auch Teil der IT-Governance ist. Nach einer gängigen Definition von Michael Rath wird mit IT-Compliance die Einhaltung und Umsetzung von regulatorischen Anforderungen im weitesten Sinne mit dem Ziel eines verantwortungsvollen Umgangs mit allen Aspekten der Informationstechnik (IT) bezeichnet[16]. Dabei gibt es zwei Blickwinkel aus denen IT-Compliance betrachtet werden kann:
- IT als Gegenstand der Compliance
Die IT als Teilgebiet eines Unternehmens mit den dort ablaufenden Prozessen und Datenverarbeitungsanwendungen muss selbst den Normen und Gesetzen unterliegen, die dafür definiert worden sind. So muss z. B. das Bundesdatenschutzgesetz (BDSG), welches vor Missbrauch personenbezogener Daten schützt, bei den IT-Prozessen und IT-Applikationen befolgt werden. Entgeltabrechnungen und Buchhaltungsanwendungen müssen ebenfalls den geltenden Normen entsprechen und von Aufsichtsbehörden abgenommen sein.
- IT als Instrument der Compliance
IT ist nicht nur Gegenstand der Compliance-Betrachtung, sondern dient auch als Werkzeug, um die Corporate Compliance im weiteren Sinne sicherzustellen. So können Regelverstöße durch IT-Systeme verhindert oder mithilfe eines IT-basierten, internen Kontrollsystems die Corporate Compliance über den gesamten PDCA-Zyklus gemanagt werden. IT ist hierbei ein Mittel zur Erfüllung von Compliance-Anforderungen.
Die IT-Compliance unterliegt vielen externen und internen Einflussfaktoren, die die Ausrichtung und die Ausgestaltung von IT-Compliance in jedem Unternehmen neu definieren. Eine isolierte Betrachtung des Bereiches IT ist nicht ausreichend, um IT-Compliance nachhaltig zu etablieren. Es müssen ebenfalls alle unternehmensübergreifenden inneren und äußeren Faktoren berücksichtigt werden. Gemäß des konzeptionellen Rahmens der IT-Compliance aus dem Kapitel 2.2.1 müssen aus allen genannten Ebenen des Rahmens die Einflussfaktoren abgeleitet werden. Nur wenn diese umfassend bekannt sind, können Unternehmen Ziele für die IT-Compliance aufstellen, um ihnen zu begegnen.
Einen groben Überblick über die gegenwärtigen Einflussfaktoren gibt die folgende Einordnung in das PEST-Schema.[17]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4 Einflussfaktoren der IT-Compliance[18]
Die genannten Einflussfaktoren unterliegen einem ständigen Wandel. Es kommen regelmäßig weitere Gesetze und Regeln hinzu, die eingehalten werden müssen. IT-Systeme entwickeln sich weiter, die Anzahl neuer Anforderungen und externer Prüfungen steigt stetig an. Durch neue Projekte und Kunden werden weitere Stakeholder an das Unternehmen gebunden, deren Interessen wiederrum gewahrt werden müssen. Die einmalige Herstellung der IT-Compliance ist aus diesem Grund nur eine Zwischenetappe. Die große Herausforderung und somit das Ziel für Unternehmen besteht darin den Zustand der IT-Compliance zu wahren und ständig diese sowohl proaktiv als auch reaktiv auf neue Gegebenheiten anzupassen. IT-Compliance muss folglich in die vorhandenen Unternehmensprozesse und Regelkreise eingebunden werden, um Teil der Unternehmensabläufe zu werden.
Die Aufgaben und Maßnahmen, die sich für die Unternehmensleitung aus den genannten Einflussfaktoren ergeben, sind je nach Unternehmen sehr individuell. In der Praxis existieren zwei mögliche Wege, die eingeschlagen werden können:
1. Unternehmen können sich der Best-Practices gegebener Standardmodelle und Frameworks bedienen oder
2. Unternehmen entwickeln eigene Maßnahmen.
Die eigenen Maßnahmen haben den Vorteil, dass sie auf die individuellen Anforderungen des Unternehmens zugeschnitten sind, bedürfen jedoch einer aufwendigen Konzeptionsphase. Zusätzlich ergibt sich die Schwierigkeit eines akzeptierten Nachweises, da z. B. keine Zertifizierung nach einem Standardmodell möglich ist. Bei der Nutzung eines Frameworks sind hingegen die Maßnahmen anerkannt und transparent. Somit ist der Nachweis einer IT-Compliance problemlos möglich. Die Maßnahmen sind jedoch sehr allgemein gehalten und müssen auf gegebene Einflussgrößen aufwendig angepasst werden. Unabhängig von der Entscheidung des Unternehmens ein Framework-Modell zu nutzen oder eigene Maßnahmen zu entwickeln, sind folgende Aufgabenblöcke immer Bestandteil des Maßnahmenkatalogs:
- Die Erfassung und Dokumentation der IT-Ressourcen einschließlich der Anforderungen, die sich aus den Geschäftsprozessen ergeben
- Analyse und Bewertung der damit verbundenen Risiken
- Anpassung der IT-Ressourcen zur Reduzierung des Risikos
Im obigen Kapitel wurde darauf eingegangen, dass die Erfassung aller relevanten IT-Ressourcen Gegenstand der IT-Compliance ist. Eine Ressource ist der Definition nach „ein Mittel, das der Produktion von Gütern oder Dienstleistungen zur Verfügung steht.“[19] Hierunter fallen sowohl die Arbeitskraft als auch alle Sachmittel, die im Wertschöpfungsprozess zum Einsatz kommen. Die IT ist in den meisten Fällen kein produzierender Bereich des Unternehmens und konzentriert sich auf die Erbringung von IT-Dienstleistungen und der damit einhergehenden Aufrechterhaltung des Geschäftsbetriebs. Aus diesem Betrachtungswinkel sind insbesondere die Ressourcen relevant, die sich dem Aufbau und der Ausstattung des Betriebs im Unternehmen widmen. Bei diesen Gütern handelt es sich um Gegenstände aus dem Betriebs-/ oder Anlagevermögen (englisch: Asset). Einen sehr großen Teil des IT-Anlagevermögens stellen IT-Systeme wie Hardware und Software dar. Diese Hardware und Software-Assets werden als Anlagevermögen in der Anlagenbuchhaltung des Unternehmens geführt. Aufgrund der Anforderungen aus der IT-Compliance muss das Unternehmen die rechtskonforme Nutzung der IT-Assets sicherstellen. Rechtskonform ist die Nutzung jedoch nur dann, wenn ausreichend Lizenzen zum Betrieb dieser Assets zur Verfügung stehen.[20] Diese Sicherstellung der korrekten und ausreichenden Lizenzierung der eingesetzten Software kann als „Software-Asset-Management“ bezeichnet werden. SAM wird im Kapitel 3.1 ausführlich als Begriff eingeführt.
Wie wirkt sich nun die IT-Compliance auf die Durchführung eines Software-Asset-Managements aus? Die Antwort auf diese Frage ist recht simpel: Aus der Bestrebung das Risiko zu minimieren formuliert die Corporate Compliance Anforderungen an die IT-Compliance, welche wiederum ihre Anforderungen an das Software-Asset-Management weitergibt. Der folgende Absatz verdeutlicht dies.
In der heutigen Zeit gibt es kaum einen Unternehmensprozess, der nicht durch eine Software unterstützt wird. Durch die weite Verbreitung der Software und durch die unzähligen Angebote am Markt und online ist heute faktisch jeder Endanwender eines Unternehmens in der Lage Software auf seinem Computer in Betrieb zu nehmen. Diese Subprozesse gehen oftmals an der IT vorbei. Die IT, als Dienstleistungserbringer und Betreiber dieser Software, befindet sich dadurch in einer gefährlichen Situation. Einerseits muss der Betrieb des Unternehmens sichergestellt werden, andererseits trägt die IT die Verantwortung für einen ordnungsgemäßen Ablauf und für eine korrekte Nutzung der Software. Beide Herausforderungen in Einklang zu bringen bedarf eines gut organisierten Software-Asset-Managements. Durch einen falschen, bzw. in manchen Fällen gar illegalen Einsatz von Software können Lizenzbestimmungen und Rechte Dritter verletzt werden. Aus diesem Grund steht Software-Asset-Management unter der genauen Beobachtung der IT-Compliance. In seiner Dissertation entwickelt Michael Falk ein Control-Framework zur IT-Compliance, welches er aus anderen, gängigen Modellen und Standards ableitet und mit wichtigen Themen anreichert. So sieht auch er das Management der IT-Assets als einen wichtigen Teil der IT-Compliance mit dem Ziel einer durchgängigen Kontrolle: „Controls provide reasonable assurance that components of the service and infrastructure are defined and controlled, that the configuration information are maintained accurate, that the configuration is deployed consistently across the enterprise, that planning is enhanced so that changes are in accordance with the overall architecture, that unauthorized changes to hardware and software are discovered, which could otherwise result in security breaches, that the ability to fall back is given and that the documented information are not failing to reflect the current architecture, that business-critical components can be identified and that assets can be accurately accounted for”.[21] Weiterhin gibt er als Empfehlung aus, in periodischen Abständen im Rahmen der IT-Compliance diesen Teil zu überprüfen und speziell darauf zu achten, ob der Einsatz der Unternehmenssoftware den Nutzungsbestimmungen entspricht. Auf festgestellte Mängel, d.h. einen illegalen Einsatz von Software sollte reagiert und die Fehler und Abweichungen von den Lizenzbestimmungen sollten schnellstmöglich behoben werden.[22] Das Risiko für Unternehmen ist meistens viel höher, als es der Unternehmensleitung bekannt ist. Aus einer Studie durch die Business Software Alliance (BSA) aus dem Jahr 2013 geht hervor, dass 43% der eingesetzten Software nicht den originären Nutzungsbestimmungen entsprechen[23]. Dabei ist es unerheblich, ob eine falsche Software-Lizenz oder gar keine Software-Lizenz vorliegt. Beides widerspricht der Gesetzeskonformität. Mehr als ein Drittel aller weltweit eingesetzten Software in den Unternehmen ist somit illegal und damit nicht gesetzeskonform. Dieses Verhalten ist höchst urheberrechtswidrig und kann neben zivilrechtlichen Ansprüchen des Verletzen (§§ 97 ff. UrhG) auch ordnungsrechtliche und strafrechtliche Konsequenzen nach sich ziehen (§§ 106ff. UrhG).[24] Wenn zusätzlich noch eine Unternehmensbezogenheit des Endanwenders zu dem Unternehmen nicht widerlegt wird, haften Unternehmen zudem für Urheberrechtsverletzungen ihrer Mitarbeiter (§§ 100 UrhG).[25] Weiterhin erweist sich eine falsche Lizenzierung oder eine Unterlizenzierung als eine Verletzung aufsichtsrechtlicher Vorgaben. So stellt dies meist ein Verstoß gegen die Corporate Governance Regeln und geltende Aspekte des Sarbanes-Oxley Acts und Basel II dar, in denen ein intaktes Software-Asset-Management zwingend vorausgesetzt wird.
Die Unkenntnis über die Abweichung vom geltenden Nutzungsrecht, vom UrhG und von den zahlreichen internationalen Regularien (SOX, Basel II) entbindet die Geschäftsführung nicht von der Verantwortung lizenzrechtliche Nutzungsbestimmungen einzuhalten. Die Wichtigkeit einer intakten IT-Compliance wird durch diese Regularien noch stärker betont und führt zu wachsenden Anforderungen an ein funktionierendes Software-Asset-Management. Auf der einen Seite muss durch das SAM Gesetzeskonformität und Compliance mit geltenden Regeln hergestellt und auf der anderen Seite darüber hinaus noch weitere wirtschaftliche Vorteile für das Unternehmen erzielt werden. Welche Anspruchsgruppen, welche Rahmenbedingungen und Frameworks für das SAM existieren um die genannten Ziele zu erreichen wird im nächsten Kapitel näher erläutert.
Der Begriff Software-Asset-Management ist bereits in den Kapiteln zuvor genannt worden. Das Ziel dieses Abschnitts wird es sein, eine umfassende Einführung in das Thema Software-Asset-Management zu geben und diesen Begriff zu definieren. In den weiteren Unterkapiteln werden die Beweggründe, die Potentiale und die Herausforderungen einer SAM-Einführung benannt. Es werden gängige Standardmodelle und Prozesse diskutiert und das SAM organisatorisch in die Aufbauorganisation des Unternehmens eingeordnet.
Zum Begriff des Software-Asset-Managements existieren einige Definitionen, wobei sich keine Definition als allgemeingültig durchgesetzt hat.
Definition nach ITIL:
“Software-Asset-Management is all of the infrastructure and processes necessary for the effective management, control and protection of the software assets within an organisation, throughout all stages of their lifecycle.” [26]
Definition nach ISO:
“Software-Asset-Management is a discipline that is specifically aimed at managing the acquisition, release, deployment, maintenance and eventual retirement of software assets.” [27]
Definition nach Gartner:
“A process for making software acquisition and disposal decisions. It includes strategies that identify and eliminate unused or infrequently used software, consolidating software licenses or moving toward new licensing models.” [28]
Definition nach Deloitte:
“SAM is a business practice that involves managing and optimizing the purchase, deployment, maintenance, utilization, and disposal of software assets within an organization. The goals of SAM are to reduce IT costs and limit operational, financial and legal risks related to the ownership and use of software.” [29]
Alle Definitionen haben eine gemeinsame Komponente. Alle vier betrachten das SAM als einen Prozess, eine Disziplin oder eine betriebliche Praxis, die Software-Assets über den gesamten Lebenszyklus hinweg verwaltet. Vom Eintritt einer Software bis hin zur Stilllegung oder Entsorgung der Software tragen alle Phasen des Lebenszyklus zum ganzheitlichen Bild des Software-Asset-Managements bei. Die Definition nach ITIL geht noch eine Stufe weiter und bezieht nicht nur die Prozesse ein, die den Umgang mit Software-Assets steuern, sondern involviert zusätzlich noch alle Infrastrukturkomponenten, die zur Verwaltung der Software-Assets genutzt werden. Nach diesen weitfassenden Definition kann man SAM als eine Teilorganisation des Unternehmens auffassen, bestehend aus Menschen, die diese Organisation steuern, IT-Systemen, die durch die Menschen für den definierten Zweck des effektiven Software-Asset-Managements genutzt werden und schlussendlich den SAM-Prozessen, die das Zusammenwirken von Menschen und IT-Systemen verknüpfen. Häufig wird folgendes Schaubild verwendet, um die Tragweite des Software-Asset-Managements in einem Unternehmen zu visualisieren:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 5 Bestandteile des Software-Asset-Managements[30]
In den deutschen Quellen hat sich die Begrifflichkeit eines Software-Asset-Managements noch nicht final durchgesetzt. So wird in der gängigen Literatur stets von Lizenzmanagement gesprochen und doch an vielen Stellen das Software-Asset-Management damit gemeint. Die Begriffe werden zum Teil synonym verwendet. Wie unterscheidet sich nun Lizenzmanagement von Software-Asset-Management und welche Definition wird in dieser Arbeit zu Grunde gelegt?
In dieser Arbeit wird eine klare Trennung zwischen Lizenzmanagement und Software-Asset-Management vorgenommen. Zuerst wird der Begriff Lizenzmanagement definiert und später von Software-Asset-Management abgegrenzt.
Definition nach Groll:
„Lizenzmanagement setzt sich aus dem Begriff Lizenz (lat. licere, licentia, Erlaubnis, Freiheit, Befugnis), und dem Begriff Management (lat. manus, Hand) zusammen und steht für das Verwalten und Managen von Softwarelizenzen. Das Lizenzmanagement beschreibt Prozesse für den legalen Umgang mit Software und deren Lizenzbestimmungen und ist somit mehr in der kaufmännischen als technischen Ecke zu sehen“ [31]
Wie auch das Software-Asset-Management beschreibt das Lizenzmanagement Prozesse für den Umgang mit Software. Aus der Definition geht zwar nicht hervor, dass sich die Prozesse auf den gesamten Lebenszyklus einer Software beziehen, jedoch kann diese Annahme durchaus hinein interpretiert werden. Der große Unterschied wird jedoch im letzten Teil dieser Definition deutlich. Lizenzmanagement bezieht sich mehr auf die kaufmännische Betrachtung einer Software, insbesondere auf Lizenzbestimmungen, wohingegen das SAM auch die Infrastruktur betrachtet. Das Lizenzmanagement (LIMA) könnte folglich als ein Element des SAM bezeichnet werden und wäre der Mengenlehre nach eine Teilmenge des SAM.
Abb. 6 Lizenzmanagement als Teil des SAM32
Abbildung in dieser Leseprobe nicht enthalten[32]
Software-Asset-Management und Lizenzmanagement sind noch recht junge Disziplinen und befinden sich noch in vielen Teilen der wirtschaftlichen Welt im Aufbau. Das immer steigende Augenmerk auf dieses Thema hängt mit der raschen technischen Entwicklung und den damit verbundenen fallenden Hardwarekosten zusammen. Vor vielen Jahren hatte IT-Hardware den größten Anteil an den IT-Kosten bei den Unternehmen und bescherte den Hardwareherstellern enorme Gewinne. Durch die effizientere Nutzung der Hardware, durch neue Technologien (z. B. Virtualisierung) konnten Unternehmen jedoch erhebliche Ressourceneinsparungen erzielen. Es ergab sich für die Unternehmen jedoch ein anderer Kostenposten, der mit den Jahren immer weiter anwuchs: Die Kosten für die IT-Software.
Die Rolle der Software hat sich in den vergangenen Jahrzehnten stark gewandelt. In Zeiten der Mainframe-Maschinen in den 70er Jahren war Software der Code, der individuell für Unternehmen auf den Maschinen programmiert wurde, um eigens aufgestellte Unternehmensanforderungen zu erfüllen. Der Endnutzer, als Hauptanwender und Nutzer von Software war noch nicht bekannt. Erst mit dem Personal Computer (PC) und den ersten Applikationen zur Steigerung der Nutzerproduktivität erhielt der heutige Endnutzer Zugang zur Software. Verstärkt durch die aufkommenden Client-Server-Architekturen in den 90er Jahren und die Entwicklung des Internets verbreitete sich der PC als ein unabkömmliches Arbeitsmittel in fast allen Tätigkeiten, allem voran in der Geschäftswelt. Heute ist Software überall in der Welt verbreitet, übernimmt lebensnotwendige Funktionen wie in der Medizin, steuert die Energieflüsse, lässt Raketen und Roboter in den Weltraum fliegen und zurück, organisiert die Logistik und steuert die Mehrheit der Prozesse in jedem Unternehmen. Insgesamt hat sich das Bewusstsein weg von der Hardware und hin zu der Software entwickelt. Die Bedeutung der Software hat in den vergangenen Jahren so immens zugenommen, dass sich die Frage stellt, nicht ob, sondern wie Unternehmen sich aufgestellt haben, um dieses aufstrebende Wirtschaftsgut effektiv zu managen. Im Hinblick auf zukünftige Trends wie Cloud Computing, Software-as-a-Service und neue Formen der Virtualisierung wird der Einfluss von Software noch weiter wachsen und erfordert eine besondere Aufmerksamkeit. IT-Manager können diesen Herausforderungen mit einem Software-Asset-Management begegnen. Es stellt ihnen alle notwendigen Werkzeuge zur Verfügung.
Einschlägige Studien bestätigen, dass viele Unternehmen diesen Weg bereits eingeleitet haben. Forrester Research hat 200 IT-Professionals zu der aktuellen SAM-Situation in ihrem Unternehmen befragt. Demnach haben 39% der Unternehmen bereits SAM-Prozesse und Lösungen im Einsatz. 52% der Unternehmen sind gerade dabei oder planen in den nächsten 12 Monaten mit der Einführung von SAM zu beginnen. 9% aller befragten Unternehmen setzen noch nicht auf SAM oder wollten sich dazu nicht äußern.[33]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 7 SAM-Verbreitung in den Unternehmen[34]
Die Mehrheit der Unternehmen hat erst in der unmittelbaren Vergangenheit angefangen SAM-Programme zu initiieren. Vor 2012 schien dieses Thema nicht im Fokus der IT-Leiter zu stehen. Für diese Tatsache gab es und gibt es laut den Ergebnissen von Forrester immer noch mehrere Gründe. Unklare Regelungen der Verantwortung führen dazu, dass sowohl die IT, der Einkauf, die Rechtsabteilung und die Verantwortlichen der Buchhaltung sich mit dem Thema auseinandersetzen, aber dieses nicht federführend voran treiben. So existieren viele Interessensvertreter, aber niemand, der diese Disziplin im Unternehmen fest verankert. Weiterhin fürchten sich viele Unternehmen mit der SAM Einführung anzufangen. Dies würde eine aufwendige Untersuchung der historischen Lizenzentwicklung bedeuten und enormen Aufwand bei der Bereinigung der Fehlbestände verursachen. Viele Unternehmen sind noch nicht bereit solche Projekte zu starten, da das Risiko eines Compliance-Vorfalls noch nicht hoch genug eingeschätzt wird. Speziell diese Unternehmen werden jedoch aufgrund der bereits in der Einleitung gezeigten Audit-Entwicklung SAM als Disziplin im Unternehmen einführen und weiter entwickeln müssen. Doch trotz der wachsenden Bedeutung von SAM befinden sich die Unternehmen noch in der Anfangsphase. Verdeutlicht wird dies durch bereits erwähnte BSA-Studie, wonach 43% der im Unternehmen eingesetzten Software nicht vollständig, nicht richtig oder überhaupt nicht lizenziert ist.[35]
Es stellt sich daher die Frage, warum die Unternehmen, obwohl sie sich mehrheitlich mit SAM als Prozess und Organisationsform auseinandersetzen, noch nicht die beabsichtigten Resultate erzielen können. Dafür gibt es einige Gründe, die im nächsten Kapitel erläutert werden.
KPMG hat in einer Untersuchung die Gründe für die schlechten Resultate der bisherigen SAM-Programme erforscht. Ein Ergebnis der Studie geht näher auf die größten Herausforderungen solch einer SAM-Einführung ein. Für viele IT-Manager und IT-Professionals ist die Einführung eines Tools zum Verwalten von Softwarelizenzen gleichzusetzen mit einem ganzheitlichen SAM im Unternehmen. Dieses ist jedoch keinesfalls richtig, wie die Definitionen von SAM und Lima es dargelegt haben. SAM ist hauptsächlich das Zusammenwirken von Menschen und IT-Systemen in ganzheitlichen Prozessen. Aus diesem falschen Verständnis von SAM heraus, entwickelt sich ein Ungleichgewicht zwischen eigener Wahrnehmung und der tatsächlichen Situation. Ganz oben auf der Liste der größten Herausforderungen steht folglich die Verankerung des SAM als Teil der Unternehmenskultur. Insbesondere in den BRIC-Staaten, Osteuropa und Asien ist Softwarepiraterie gängige Praxis.[36] Genau in diesen Regionen und Staaten bedarf SAM einer höheren Aufmerksamkeit. Weitere Herausforderungen für Unternehmen bei der erfolgreichen Einführung von SAM stellen komplexe Lizenzregeln dar, die von Hersteller zu Hersteller stark variieren und sich dazu enorm schnell verändern. Die kürzer werdenden Softwareentwicklungszyklen, die neuen Technologien und stetig steigende Individualität in den Produktportfolios bringen ständige Veränderungen von Lizenzbestimmungen mit sich. In vielen Fällen wissen die Softwarehersteller selbst nicht, wann sich welche Bestimmungen geändert haben und welche gültige Bestimmung für das Unternehmen in expliziten Fall greift.[37] Die für die Unternehmen fehlende Standardisierung der Bestimmungen erschwert eine Einführung und eine regelmäßige Anpassung der SAM-Prozesse ungemein. Hinzu kommt noch die Tatsache, dass Abteilungen, die die Verträge und Bestimmungen ausgehandelt haben, nicht für die Einhaltung dieser Bestimmungen verantwortlich sind. In Unternehmen, in denen keine starke Kooperation zwischen IT, Rechtsabteilung und Einkauf besteht, kann die IT als Halter des SAM-Prozesses die Lizenz-Compliance nicht sicherstellen, wenn sie kein Mitspracherecht bei der Ausgestaltung der Softwareverträge hat. Darüber hinaus existieren noch weitere Gründe für das Missverhältnis, dass es eigentlich viele Unternehmen gibt, die SAM bereits etabliert haben, sie anscheinend jedoch noch nicht in der Lage sind, die Compliance herzustellen. Von ihrer Wertigkeit sind sie jedoch niedriger einzustufen als die genannten Punkte und werden daher an dieser Stelle nicht weiter aufgezählt.
Trotz einiger Hürden, die die Unternehmen bei der Einführung von SAM meistern müssen, begeben sich, wie die Statistik im letzten Kapitel gezeigt hat, mehr als die Hälfte der Unternehmen auf diesen Weg. Der wirtschaftliche Gesamtlage und der der Druck, die auf die Unternehmen einwirken, lassen ihnen keine Alternativen zu. Die Zielformulierung unterscheidet sich bei den verschiedenen Firmen kaum. Torsten Groll formuliert in seinem Praxisleitfaden vier wesentliche Ziele des Software-Asset-Managements, die im folgenden Schaubild schematisch dargestellt werden.
Abb. 8 Zielvorgaben des SAM [38]
Abbildung in dieser Leseprobe nicht enthalten
Software-Asset-Management stellt ein Werkzeug für Unternehmen dar, um die vier genannten Ziele zu erreichen. Compliance und Rechtmäßigkeit sind zwei dieser Ziele. Beide wurden bereits in der vorliegenden Arbeit im Grundlagenkapitel erläutert und werden hier noch zusätzlich nach Compliance-Anforderungen gegenüber Software-Herstellern und nach gesetzlichen Anforderungen separiert. Bei beiden geht es darum mit einem Software-Asset-Management die vereinbarten Nutzungsrechte und die geltenden Gesetze einzuhalten, um Haftungsrisiken und Schadensersatzzahlungen zu vermeiden. Ein Verstoß bringt unnötige Anspannungen in das Verhältnis mit dem Hersteller, wodurch zukünftige Rabatte und Vergünstigungen erschwert werden. Die wichtigste Aufgabe, um Rechtmäßigkeit mit geltendem Recht und aufgestellten Compliance-Anforderungen herzustellen, ist der permanente Abgleich der Installationszahlen mit dem aktuellen Lizenzbestand. Ein mögliches Ergebnis dieses Abgleiches könnte eine Unterlizenzierung sein. Das Unternehmen hat einen höheren Installationsbestand als einen Lizenzbestand und befindet sich in einer gefährlichen Zone der Nicht-Compliance. Solange der Compliance-Verstoß nicht festgestellt wird, ist das Unternehmen in einem wirtschaftlichen Vorteil. Wenn jedoch, durch ein Audit oder eine Wirtschaftsprüfung dieser Verstoß identifiziert wird, wird das Unternehmen daraus einen Schaden nehmen. Häufig ist im Fall der Unterlizenzierung nicht nur der Nachkauf der fehlenden Lizenzen notwendig, es müssen auch noch Strafgebühren und rückwirkende Wartungspauschalen entrichtet werden. Es ist durchaus möglich, dass Unternehmen aus Angst vor einem Compliance-Vorfall dazu neigen ihren Lizenzbedarf überproportional zu decken. Dadurch minimiert das Unternehmen das rechtliche Risiko nahezu auf null, entfernt sich durch die entstehende Überlizenzierung aber vom Ziel der Kostensenkung. Das minimale Risiko wird somit teuer erkauft. Trotz der Sicherstellung des Betriebs durch ausreichende Lizenzen, hat das Unternehmen mehr Geld dafür ausgegeben, als es eigentlich hätte tun müssen. Diese Finanzkraft fehlt in den wichtigen Zweigen des Unternehmens und kann dort nicht entfaltet werden. Beide Fälle, sowohl Über- als auch Unterlizenzierung müssen aus Unternehmenssicht vermieden werden, um die Kosten minimal zu halten. Das Ziel der Transparenz soll die Firmen dabei unterstützen. Das Wissen, welche Software, in welchen Mengen und in welchen Bereichen des Unternehmens eingesetzt wird, ist eine zentrale Voraussetzung für ein aktives und proaktives Lizenzmanagement.[39] Dadurch wird das Unternehmen in die Lage versetzt Beschaffungsprozesse langfristiger zu planen, das Vertragsmanagement besser zu gestalten und die Umverteilung nicht genutzter Lizenzen optimal zu organisieren. Durch die Transparenz erlangen die IT-Manager überhaupt erst das Wissen, wie es um die anderen drei Ziele steht und wie der Status des SAM allgemein im Unternehmen ist. Sollten die Ergebnisse der Transparenz-Bestrebung jedoch nicht realisiert werden, so erreicht das Unternehmen alleine durch die Transparenz noch keinen Mehrwert. Um erfolgreich zu sein und Potentiale des SAM nutzen zu können, müssen alle vier Ziele in Balance gehalten werden. Sie hängen so stark voneinander ab, dass sie nur dann einen wirtschaftlichen Nutzen bringen, wenn sie gemeinsam erfüllt werden. Mit der Erreichung der Ziele wird eine enorme Wirkungsfähigkeit, sowohl operativer als auch strategischer Natur ermöglicht. In einer durchgeführten Studie von KPMG wurde nachgewiesen, dass durch verbesserte Kontrolle und Transparenz von Hardware- und Software-Assets die Unternehmen in der Lage waren, die Stundenanzahl für das Verwalten der IT-Umgebung pro Asset um die Hälfte zu reduzieren.[40] Neben den direkten, positiven Auswirkungen auf die IT-Ausgaben, können Unternehmen weitere Potentiale durch die Erreichung der genannten Ziele realisieren. Das folgende Schaubild gibt eine allgemeine Übersicht über strategische und operative Vorzüge.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 9 Potentiale des SAM[41]
Wie aus der Definition von SAM hervorgeht, handelt es sich dabei nicht nur um ein Tool, ein IT-System oder ein Set an Best-Practices, sondern um Prozesse, die Menschen und Werkzeuge in einem Gesamtgebilde miteinander verbinden. Bevor die im vorigen Kapitel genannten Vorzüge realisiert werden können, müssen sich die Unternehmen mit der Einführung und der Optimierung der notwendigen SAM-Prozesse beschäftigen. Prozesse transformieren einen oder mehrere Inputfaktoren durch die Ausführung verschiedener Funktionen zu einem oder mehreren Outputfaktoren. Sie sind demnach eine Folge von logischen Einzelfunktionen zwischen denen Verbindungen bestehen.[42] Dieses Kapitel beschäftigt sich mit diesen Einzelfunktionen im Bereich des Software-Asset-Managements und gibt einige Beispiele aus der Theorie und Praxis, wie die SAM-Prozesse zusammenhängen und in welchen Referenzmodellen sie realisiert werden können. Referenzmodelle werden nach Helmut Krcmar folgendermaßen definiert:
„Referenzmodelle sind Informationsmodelle, welche nicht nur im Kontext, der ihrer Konstruktion zugrunde liegt, sondern auch in weiteren Anwendungskontexten verwendet werden können. Sie erheben somit einen Anspruch auf Allgemeingültigkeit und formulieren Sollempfehlungen für eine Klasse abstrakter Anwendungsgebiete.“ [43]
Torsten Groll definiert in einem Praxisleitfaden für Lizenzmanager ein Software-Life-Cycle-Modell, welches er aus seiner langjährigen Erfahrung als Berater und Lizenzmanager in den Unternehmen beobachtet und mitentwickelt hat. Aus diesem Grund ist das Modell sehr stark an der Praxis orientiert, versucht einen möglichst schnellen Einstieg in das Thema zu geben und gleichzeitig jedoch dem Anspruch eines allgemeingültigen und ganzheitlichen Modells zu genügen. Der Software-Life-Cycle setzt sich bei Groll aus sechs Hauptprozessen zusammen, wobei drei davon der Beschaffung und drei dem Betrieb der Software zuzuordnen sind. Jedem dieser Hauptprozesse werden Unterprozesse zugeordnet, die die Hauptprozesse gliedern und detaillieren. Insgesamt gibt das Modell 19 Unterprozesse vor.[44]
Abb. 10 Software-Life-Cycle-Prozessübersicht nach Groll[45]
Abbildung in dieser Leseprobe nicht enthalten
Das Modell ist sehr einfach aufgebaut und gibt den Verlauf einer Software über ihren Lebenszyklus hinweg im Unternehmen wieder. Es beginnt mit der Anforderung für neue Software mit den dazugehörigen Unterprozessen, von einer Bedarfsmeldung bis hin zu der Klassifikation neuer Software im Portfolio. Im zweiten Schritt wird diese Software bestellt, unter Einhaltung aktueller Verträge und akzeptierter Lizenzmodelle. Im dritten kaufmännischen Schritt wird die Software ausgeliefert, muss in Empfang genommen, an den Anforderer gemeldet und weiter gereicht werden. Der abgeschlossene Bestellvorgang muss hierbei archiviert und die erworbene Lizenz abgelegt werden. Nach der erfolgreichen Bestellung müssen nun die technischen Prozesse greifen und die Software installiert werden. Dazu müssen in einer IT-Serviceorganisation Aufträge für diesen Vorgang erfasst, das zu installierende Softwarepaket technisch vorbereitet und schließlich auf den Client des Endanwenders gebracht werden. Im Laufe des Betriebs können Änderungen an der Software auftreten. So muss ggfs. die Softwarelizenz umgezogen werden, da der eigentliche Nutzer diese nicht mehr benötigt und die Lizenz freigegeben werden kann. Um solch eine Bedarfsänderung festzustellen, ist ein effektives Reporting notwendig und muss bei der Prozessgestaltung ebenso betrachtet werden. Erreicht die Software und ihr technisches Ende, d. h. sie ist veraltet und wird nicht mehr benötigt, so muss diese stillgelegt und aus dem aktiven Bestand entfernt werden. Dazu wird sie vom Computer des Anwenders deinstalliert. Die nicht mehr benötigte Lizenz kann aus dem aktiven Pool entfernt oder wenn die Möglichkeit besteht, an den Lizenzgeber zurückgegeben werden, um den noch verbliebenen kaufmännischen Wert einzutauschen. Am Schluss wird die betroffene Software aus dem Softwareportfolio entfernt, um zukünftige Neubestellungen dieses Assets auszuschließen.
Mit diesem Modell legt Groll den Grundstein für ein ganzheitliches Software-Asset-Management. Das Unternehmen wird angeleitet sich an den Haupt -und Teilprozessen auszurichten und diese zu etablieren. Da es sich dabei um ein Praxismodell handelt, ist es eher in das operative Management von Software-Assets einzuordnen. Compliance, Rollen und Verantwortlichkeiten, regelmäßige Prozeduren zum Überprüfen der SAM-Entwicklung sind hier nicht vorgesehen. Dieses Modell ermöglicht einen schnellen Start. Organisatorische Prozesse und Governance-Themen im Zusammenhang mit SAM müssen separat abgewickelt werden.
Wie die einleitenden Kapitel dargestellt haben ist SAM ein Thema, welches erst in der nahen Vergangenheit in den Fokus der Unternehmen gerückt ist. Aus diesem Grund gab es lange Zeit keine standardisierten Prozesse. Mit der Entwicklung und der Ausbreitung von der IT Infrastructure Library (ITIL) wurden IT-Prozesse einheitlich dargestellt und die über Jahre gesammelte Erfahrungen in Standardwerken festgehalten. So entstanden Prozesslandschaften, die Unternehmen Best-Practices zur Verfügung stellten und diese miteinander vergleichbar machten. Weil es aber in ITIL keine direkte Schnittstelle zu Lizenzmanagement oder Software-Asset-Management gibt, ist SAM zum Untersuchungsgegenstand einer anderen Norm geworden. Die daraus entwickelte ISO/IEC-Norm 19770 entstand aus dem Bestreben heraus die fehlende Standardisierung durch ein international anerkanntes Framework auszugleichen. Im Mai 2006 wurde im ersten Teil dieser Norm (ISO 19770-1) ein Prozessrahmen veröffentlicht, der die geforderten Governance-und Unternehmensanforderungen für das SAM wirksam im IT-Service-Management umsetzt.[46] Zielsetzung war es ein Modell zu entwickeln, das Unternehmen den Einstieg und die Optimierung des SAM ermöglichen soll. Ein Standard, ähnlich wie ITIL, erfordert nicht eine vollständige Umsetzung aller genannten Prozesse, sondern versteht sich als Unterstützung oder Hilfestellung. Die letzte und bisher finale Version des Standards wurde 2012 veröffentlicht und unterteilt das Modell in drei Hauptbereiche. Im ersten Prozessblock geht es um organisatorische Managementprozesse für SAM, während sich der zweite Block mit SAM-Kernprozessen auseinandersetzt. Der dritte Bereich bezieht sich mehr auf die operative Ebene und beschäftigt sich mit den Lebenszyklus-Prozessen. Diese Hauptkategorien gliedern sich wiederum in Unterkategorien, die insgesamt 27 Teilprozesse umfassen. Das folgende Schaubild gibt einen Überblick über den gesamten Prozessrahmen:
Abbildung in dieser Leseprobe nicht enthalten
Tab. 2 ISO 19770 - Überblick über die Prozesse von SAM[47]
Dieses Modell erweitert das vorgestellte Praxismodell von Groll. Während sich das Praxismodell hauptsächlich auf die operative Ebene konzentriert, geht das ISO-Modell weit darüber hinaus und betrachtet das SAM auch aus der strategischen und taktischen Sicht. Die Gliederung des Modells in die drei Hauptbereiche gibt dies exakt wieder. Die organisatorischen Managementprozesse beziehen sich auf den SAM-Rahmen, also Richtlinien und Verfahren, Rollen und Verantwortlichkeiten und setzen sich mit der Fragestellung auseinander, wie SAM im Unternehmen eingeführt und kontinuierlich weiterentwickelt werden kann. Die Kernprozesse haben die Erfassung der Lizenzsituation und die Einhaltung der Lizenz-Compliance als Schwerpunkt. Darüber hinaus werden dort die Schnittstellen zu anderen Unternehmensprozessen, wie dem Beziehungs- und Vertragsmanagement definiert. Im dritten Bereich, der von der Idee her dem Praxismodell von Groll gleicht, geht es um Lebenszyklusprozesse von Software, von der Anschaffung bis hin zur Ausmusterung. Zusätzlich werden an dieser Stelle noch die Schnittstellen zu IT-Service-Management-Prozessen, wie Incident-Management oder Problem-Management beschrieben.
Das ISO-Modell deckt die volle Bandbreite aller möglichen SAM-Prozesse ab. Es normiert den SAM-Einführungsvorgang und stellt sicher, dass von der Governance-Funktion bis hin zu den operativen Handlungen alles korrekt ausgerichtet ist, um erfolgreiches SAM zu betreiben. Der Standard ist unabhängig von Anbietern und Produkten, es beschreibt eine universale Vorgehensweise und lässt den Unternehmen dadurch den Freiraum die Prozesse je nach Stand und Reifegard individuell einzuführen. Es gibt weiterhin keine Priorisierung zwischen organisatorischen Prozessen und Kernprozessen. Diese Entscheidung wird den IT-Managern überlassen.[48] Die erfolgreiche Einführung und den Betrieb von SAM können sich Unternehmen zudem international durch die ISO nach 19770-1 zertifizieren lassen und sich dadurch wertvolle Argumente in Verhandlungen oder Audits mit Softwareherstellern- und Anbietern sichern.
Software-Asset-Management ist eine interdisziplinäre Aufgabe. Diese Aussage wurde im vorherigen Kapitel verdeutlicht. Die Entstehung des SAM rührt aus der Zielsetzung, die Compliance im Unternehmen zu bewahren und somit das ökonomische Risiko zu beherrschen. Da es sich bei Software-Assets um Anlagen aus der IT handelt, sind schon dadurch drei vertikale Bereiche der Aufbauorganisation eines Unternehmens angesprochen:
1. Die Rechts- Compliance- oder Risikoabteilung zur Wahrung der Gesetzeskonformität
2. Der Einkauf zur Minimierung der Ausgaben und zur Verhandlung über neue Verträge und Bezugskanäle
3. Die IT, als Eigner der Software-Assets und als Verantwortlicher für die Sicherstellung der Lebenszyklus-Prozesse
Grundsätzlich gibt es keine fest definierte Stelle wo die Hauptverantwortung für das SAM anzusiedeln ist.[49] Es handelt sich um eine junge Disziplin und alle Variationen sind durchaus denkbar. Eindeutig steht jedoch fest, dass alle drei Einheiten eng miteinander arbeiten müssen und je nach Situation sowohl der Anforderer als auch der Lieferant von Informationen oder Prozessergebnissen sein können.
Abb. 11 Vertikale Einordnung im Unternehmen[49]
Abbildung in dieser Leseprobe nicht enthalten[50]
Auch in der horizontalen Ausrichtung einer SAM-Aufbauorganisation kann die Verteilung der Verantwortlichkeiten variieren (siehe Abb. 11). Folgende Ausrichtungen sind denkbar:
1. Zentrale SAM-Verantwortung in einer der definierten vertikalen Einheit (links oben im Schaubild)
2. Regionale SAM-Verantwortung ohne Konzentrierung der Verantwortung an einer zentralen Stelle (rechts oben im Schaubild)
3. Matrixorganisation mit zentraler Hauptverantwortung und dezentralen Kompetenzzentren (unten im Schaubild)
Abbildung in dieser Leseprobe nicht enthalten
Abb. 12 Horizontale Einordnung im Unternehmen[51]
Die Einordnung von SAM in der Aufbauorganisation kann mannigfaltig gestaltet werden und sollte sich immer an den Unternehmensprozessen ausrichten. Die vorgestellten Formen geben lediglich einen Überblick darüber, an welchen Stellen der Aufbau und Einsatz der SAM-Kernkompetenz sinnvoll ist und wie es häufig in der Praxis gelebt wird.
Dieses Kapitel hat eine allgemeine Einführung in das Software-Asset-Management gegeben. Die Begrifflichkeiten wurden definiert, Software-Asset-Management wurde von dem Begriff des Lizenzmanagements abgegrenzt und die Entwicklungshistorie dieser Disziplin wurde aufgezeigt. Studien haben jedoch dargelegt, dass obwohl SAM im Fokus der meisten Unternehmen steht, sich die Erfolge in Grenzen halten und unerlaubter Einsatz von Software immer noch ein großes Problem darstellt. Ihren Beitrag zu diesen Misserfolgen tragen die enormen Herausforderungen des SAM bei, die in diesem Kapitel ausführlich benannt worden sind. Wenn es den Unternehmen jedoch gelingt, die gesetzten Ziele zu erreichen, so können sie erhebliche operative wie strategische Potentiale realisieren. Unternehmen können sich als Hilfestellung vorhandene Modelle am Markt heranziehen und das SAM nach einem der vorgestellten Modelle ausrichten. Am Ende des Kapitels wurde SAM als Aufgabengebiet in die Aufbauorganisation eines Unternehmens einsortiert und mehrere Realisierungslösungen wurden aufgezeigt.
[...]
[1] Concessau, Why focus on Software License Management, S.2
[2] Vgl. Groll, 1x1 des Lizenzmanagements, S. XII
[3] Vgl. Deas, u.a., Software Asset Management
[4] Vgl. Dietzfelbinger, Praxisleitfaden Unternehmensethik, S. 299.
[5] Schneider, ZIP, 15/2003, S. 646
[6] Vgl. Stahl, IT-Sicherheit, Grundlagen des IT-Risikomanagements, S. 29
[7] Vgl. Wecker, Compliance in der Unternehmenspraxis, S.9
[8] Vgl. Wecker, Compliance in der Unternehmenspraxis, S.9f
[9] Wecker, Compliance in der Unternehmenspraxis, S.12
[10] Vgl. Schneider, ZIP 15/2003, 645, 647
[11] Vgl. Bürkle, in: Hauschka, Corporate Compliance, § 8 Rn. 7 ff.
[12] Kozlova, Hasenkamp, IT-Systeme in der Rechnungslegung, S. 992.
[13] Vgl. Wecker, Compliance in der Unternehmenspraxis, S. 129
[14] Vgl. Falk, IT-Compliance in der Corporate Governance, S.37
[15] Vgl. Falk, IT-Compliance in der Corporate Governance, S.7
[16] Vgl. Rath, Computerwoche, 11/2007, S. 54
[17] PEST-Analyse wird als Werkzeug im Rahmen von strategischer Planung eingesetzt und dient hauptsächlich der Analyse des internen und externen Unternehmensumfelds und der dort wirkenden Verflechtungen. PEST besteht aus vier Betrachtungsdimensionen und steht für p olitische, wirtschaftliche (E conomic), s ozio-kulturelle und t echnologische Betrachtungswinkel.
[18] Vgl. Falk, IT-Compliance in der Corporate Governance, S.4
[19] Definition nach Rittershofer, Wirtschafts-Lexikon
[20] Eine Lizenz entspricht einem Nutzungsrecht und wird im Kapitel 4.1 näher erläutert
[21] Falk, IT-Compliance in der Corporate Governance, S. 225
[22] Vgl. Falk, IT-Compliance in der Corporate Governance, S. 225
[23] Vgl. BSA, The Compliance Gap, S. 2
[24] Vgl. Ammann, Rechtssicheres IT-Lizenzmanagement, S. 74
[25] Vgl. Wandtke, UrhH, §§100 UrhG
[26] SAM Definition nach ITIL
[27] SAM Definition in ISO 19770-5_2013, Absatz 4.1
[28] Gartner, IT Glossary
[29] Deas, u.a., Software Asset Management
[30] Canavan, ISO19770-1:2012, S. 2
[31] Groll, 1x1 des Lizenzmanagements, S. 4
[32] Eigene Darstellung
[33] Vgl. Mann, State of SAM Survey Results
[34] Mann, State of SAM Survey Results
[35] Vgl. BSA, The Compliance Gap, Seite 2
[36] Vgl. KPMG, Software Asset Management, S. 21
[37] Vgl. KPMG, Software Asset Management, S. 21
[38] Groll, 1x1 des Lizenzmanagements, S. 8
[39] Vgl. Groll, 1x1 des Lizenzmanagement, S. 10
[40] Vgl. KPMG, Software Asset Management, S15
[41] Eigene Darstellung
[42] Vgl. Prozessdefinition nach Krcmar, Informationsmanagement, S. 141
[43] Krcmar, Informationsmanagement, S.121
[44] Vgl. Groll, 1x1 des Lizenzmanagement, S. 115
[45] Groll, 1x1 des Lizenzmanagement, S. 116
[46] Vgl. Groll, 1x1 des Lizenzmanagement, S. 284
[47] Groll, 1x1 des Lizenzmanagement, S. 285, Canavan, ISO19770-1:2012, S. 10f.
[48] Vgl. Canavan, ISO19770-1:2012, S.3
[49] Vgl. Groll, 1x1 des Lizenzmanagement, S. 82
[50] Eigene Darstellung
[51] Eigene Darstellung
