Herausforderung SAP-Lizenzmanagement

Die Diskussion rund um die indirekte Nutzung ist weder ein neues noch ein SAP-spezifisches Thema. Aus der Definition der Nutzung aus den AGB der SAP (siehe Kasten Seite 47) ist ersichtlich, dass nicht nur die Nutzer von Drittanwendungen zu lizenzieren sind, sondern gegebenenfalls weitere Nutzungsrechte für die mit SAP kommunizierende Anwendung erworben werden müssen.

Indirekte Nutzung – kein SAP-Spezifikum

Geht man einen Schritt weiter, kann die Definition zur Nutzung darin interpretiert werden, dass zwischen direkter und indirekter Nutzung nicht grundsätzlich unterschieden wird. Die Nachverfolgung von mittelbarer (indirekter) Nutzung ist wie bereits angedeutet nicht nur bei SAP detaillierter zu betrachten.

Bereits vor über zehn Jahren gab es dieses Thema: Microsoft, IBM, Oracle und andere Hersteller verfolgen dies seit geraumer Zeit. Unter Microsoft-Kunden ist die Sachlage beispielsweise als Multiplexing bekannt: ein Vorgang, bei dem Hardware und Software genutzt wird, Verbindungen zur Software zu poolen, Informationen umzuleiten oder die Anzahl der direkt zugreifenden Geräte oder Nutzer zu reduzieren.

Fragen diesbezüglich sind auch immer wieder Gegenstand von Software Audits. Um das Thema für SAP-Lizenzierung verlässlich anzugehen, muss man auch zwischen einem reinen und einfachen Lizenzverstoß und einer erhöhten Lizenzierungsanforderung durch eine mittelbare Nutzung unterscheiden.

Indizien wie z. B. Multiple Logons eines Users könnten gegebenenfalls auf eine indirekte Nutzung hinweisen, wenn der Account eines Nutzers eine extreme Vielzahl paralleler Zugriffe aufweist, da dann ein Rückschluss auf automatisierte Zugriffe möglich wäre.

Beispielsweise könnte der Account eines für das betroffene Unternehmen agierenden Softwareentwicklers nicht nur für diesen genutzt werden, sondern auch für alle Kunden des durch diesen programmierten Webshops, welcher auf SAP-Funktionalitäten zugreift.

Selbiges Beispiel könnte dadurch entstehen, dass dem Nutzer ein hoher Workload oder durchgängige Nutzung (24/7) nachgewiesen werden kann. Oder aber die Vermessung gibt Hinweise über die entsprechende komponentenübergreifende Nutzung. Dies alles sind nicht unbedingt 100 Prozent stichhaltige, aber zumindest mögliche Indizien, um Anlass zur tieferen Analyse der Verbindungen und Nutzung zu geben.

Natürlich könnte es sich bei Mul­tiplen Logons, hohem Workload oder langer Arbeitszeit auch um einen „einfachen“ Lizenzverstoß handeln, das heißt Teilen des Accounts oder ein technischer User wurde irrtümlicherweise als z. B. Dialog-User klassifiziert.

Mittelbare/Indirekte Nutzung kann beispielhaft wie folgt verursacht werden: Ein Nutzer (lizenziert oder nicht lizenziert) greift z. B. über eine Non-SAP-Dritt­applikation auf SAP-Funktionalitäten zu bzw. auf die in der SAP-Umgebung vorgehaltenen Informationen.

Durch das vorgeschaltete Nicht-SAP-System erfolgt somit ein indirekter Zugriff auf Daten im SAP CRM, ERP oder auf andere Komponenten. Wichtig ist nicht nur der Zugriff über eine Nicht-SAP-Applikation, sondern auch, wie der Zugriff erfolgt:

Verfügen die User der Drittapplikation über die notwendigen SAP-Named-User-Lizenzen? Je nach für das Szenario gültigen Lizenzbedingungen kann es auch eine Rolle spielen, ob Daten in Echtzeit übertragen werden oder zeitversetzt, sowie einige andere Kriterien, je nachdem, ob SAP eine entsprechende Lösung bereitstellt, welche die externen Funktionalitäten ersetzen könnte.

In welche Richtung erfolgt der Datentransfer (uni-, bidirektional, Inbound, Outbound etc.)? Erfolgt ein Massenabzug von Daten (Bulk)? Eine Bewertung ist für jedes indirekte Nutzungsszenario in der Unternehmenslandschaft durchzuführen und erscheint insbesondere dann sinnvoll, wenn man aus möglichen Vertragskonditionen Interpretationsspielräume identifizieren kann, die unnötige Mehrlizenzierung vermeiden könnten.

Beispielsweise findet man in älteren Vertragskonstrukten (Zusammenspiel aus relevantem Vertrag, PKL, AGB und SUR) oftmals Informationen darüber, dass die Nutzung von Informationen, sofern diese z. B. nicht in Echtzeit geschieht und einige andere Kriterien erfüllt sind, über bestehende Nutzungsrechte abgebildet werden kann.

Vertragsbedingungen in Altverträgen können somit Lösungsmöglichkeiten sein, die z. B. nur die Lizenzierung der Anwender von Drittapplikationen erfordern, aber nicht die Drittapplikation selbst.

Dies ist jedoch in jedem Falle kritisch zu überprüfen und setzt in jedem Fall voraus, dass SAP keine entsprechenden Funktionalitäten bereitstellt. So kann die Zwischenschaltung von Middleware eine akkurate Lösung sein, dies gilt jedoch nur für dedizierte Fälle und setzt die Gültigkeit entsprechender Lizenzbedingungen voraus.

Auch hier ist also die Analyse der Verträge unabdingbar, um die Einhaltung der Lizenzbedingungen und die notwendige Compliance zu gewährleisten. Wobei an dieser Stelle zu erwähnen ist, dass Middleware insoweit eine technische Lösungsmöglichkeit sein kann, solange die Funktionalitäten der vorgeschalteten Non-SAP-Software nicht bereits von SAP angeboten werden.

Bspw. würde eine eigenentwickelte Zeit­erfassungslösung, die über eine Mes­sage Queuing Middleware Daten nicht in Echtzeit sowie per Massenabzug an das entsprechende SAP-System reportet, keine geeignete Lösung darstellen, da SAP selbst entsprechende Funktionalitäten anbietet. Anders könnte die Sachlage aber bei sehr industriespezifischen Lösungen sein, die aktuell nicht im Softwareprogramm von SAP enthalten sind.

Für die somit zumindest für die meisten Nutzungsfälle notwendige korrekte Lizenzierung von Drittapplikationen hat SAP im Jahr 2010 die Lizenz „SAP Net­Weaver Foundation for Third-Party Applications“ mit ins Programm aufgenommen, die nach Named-User- oder Core-Metrik zu erwerben ist.

Das Festlegen auf eine der Metriken ist nur einmalig, vor dem ersten Kauf, möglich. Das heißt: Es ist ratsam, in die Rechte und Bedingungen der Altverträge zu schauen und bestehende Interpretationsspielräume optimal zu nutzen.

Es ist ebenfalls zu erkennen, dass sich ein Trend hin zu einer größeren Auswahl an Lizenzen abzeichnet, um den vielfältigen und komplexer werdenden Szenarien indirekter Nutzung gerecht zu werden. Das Schaubild veranschaulicht einige dieser Szenarien, mit alternativen Lizenzierungsmöglichkeiten, die aktuell von SAP weiterentwickelt werden.

So hat sich SAP – wie auch im Rahmen der diesjährigen Sapphire in Orlando kommuniziert – der gängigsten Szenarien (Procure-to-Pay, Order-to-Cash und Static Read) angenommen und stellt Kunden Lizenzmetriken mit entsprechenden Nutzungsrechten, wie im obigen Beispiel, bereit, um eine korrekte Lizenzierung kosteneffizient abzubilden.

Vorausgesetzt, dass Kunden anderweitig korrekt lizenziert sind, zeigt sich SAP auch durch die Kommunikation der Zugeständnisse im Rahmen notwendiger Upgrades verständnisvoll gegenüber dem zeitgemäßen Bedarf der Kunden.

Es empfiehlt sich grundsätzlich, egal um welchen Hersteller es sich handelt, zu analysieren, ob indirekte Nutzungsszenarien im Unternehmen bestehen, und diese lizenzrechtlich zu bewerten. Nur so lässt sich eine Lizenz-Compliance sicherstellen, welche im Verantwortungsbereich des Lizenznehmers liegt.

Begleiter des Fortschritts

Noch vor zwei Jahrzehnten waren SAP-Systeme, damals hauptsächlich in Form der ERP-Komponenten, mit ihrem allumfassenden Portfolio an Geschäftsmöglichkeiten das ideale Front-End für Kunden, um den Schritt in die Zukunft zu wagen.

Plötzlich bestand die Möglichkeit, Geschäftsprozesse effizienter zu gestalten und Durchlaufzeiten drastisch zu verkürzen. Auch diverse Workflows konnten hiermit bereits teil- bzw. vollautomatisiert abgebildet werden.

Somit war die Einführung einer ERP-Software der prestigeträchtige und zugleich mutige Schritt in eine von Digitalisierung geprägte Welt der Geschäftsprozesse und Anwendungen, um mit den wachsenden internationalen Konkurrenzstrukturen Schritt halten zu können.

Es war eine Zeit des Umbruchs und der technisch unendlich erscheinenden Möglichkeiten, nicht aber die Zeit der Antizipierung und Beachtung der einhergehenden Lizenz- und damit Compliance-Risiken.

Im Laufe der Zeit und mit der Entwicklung der heutigen technischen Möglichkeiten wie Virtualisierung, Cloud-Applikationen, regulatorischen Anforderungen genügender Storage Appliances und hoch performanten Datenbanklösungen stellte sich für alle Beteiligten, Lizenzgeber sowie Anwender, die erste größere Herausforderung.

Die Lizenzgeber mussten bei der Ausarbeitung ihrer Lizenzmodelle zukünftige technische Möglichkeiten antizipieren, die Lizenznehmer sahen sich der immer komplexer werdenden Vielfalt an Lizenzmodellen, Metriken und Lizenzbedingungen ausgesetzt.

SAP-Ökosystem

Im Fall von SAP entwickelte sich die über zwei bis drei Jahrzehnte gewachsene homogene Systemlandschaft weg von der einstigen Bedeutung als generelles Front-End hin zu einem ganzheitlichen Ökosystem, an das eine Vielzahl an spezialisierten On-premise- und Cloud-Applikationen angebunden ist.

Prominente Beispiele sind CRM-Funktionalitäten von Salesforce.com und Human Capital Management von Workday. Beide Beispiele ersetzen oder ergänzen i. d. R. SAP-eigene Funktionalitäten.

Zur technisch korrekten Integration dieser und weiterer spezialisierter Anwendungen stellt SAP die entsprechende Technologie bereit. Dies erfolgte in der Vergangenheit beispielhaft in Form des Produktes Process Integration (PI).

Neben der technischen Integration setzt die Nutzung des zugrunde liegenden SAP-Ökosystems eventuell den Erwerb zusätzlicher Nutzungsrechte voraus. Ein bekanntes Beispiel hierfür ist die bereits erwähnte Lizenz „SAP NetWeaver Foundation for Third-Party Applications“.

Ein User, der beispielsweise den Zugriff auf SAP-Funktionalitäten rein über eine externe Plattform nutzt, kann hier durch eine entsprechende Plattform-Lizenz lizenzkonform mit Nutzungsrechten ausgestattet werden.

Dies gilt jedoch, irrtümlicherweise von vielen Kunden unbeachtet, nicht als ausreichende Lizenzierung, sondern kann ggf. auch den zusätzlichen Erwerb der „NetWeaver Foundation for Third-Party Applications“-Lizenz erfordern, sofern das Ziel der Applikation auf der NetWeaver Platform basiert. Auch ein zwischengeschaltetes PI-System ändert hieran in aller Regel nichts.

Oftmals wird hier SAP mangelnde Innovationskraft vorgeworfen und man degradiert deren originäre Front-End-Systeme zu einem Back-End-System für junge, innovative Lösungsanbieter. Bei näherer Betrachtung ergibt sich jedoch ein klares Bild auf diesen Wandel und das ermöglicht, diesen als die logische Weiterentwicklung der SAP-Systemlandschaft zu sehen. Unternehmensanforderungen haben sich verändert, und Flexibilität hat in globalen IT-Strukturen an Bedeutung gewonnen.

Ganzheitliche Transparenz

Mit zunehmender Heterogenität der durch Kunden genutzten SAP-Ökosysteme und der oft kundenspezifischen Nutzung der integrierten und miteinander vernetzten Produkte und Schnittstellen gewinnt die Schaffung ganzheitlicher Transparenz seit geraumer Zeit zunehmend an Bedeutung.

Die Frage nach der Ursache der oft mangelhaften Transparenz lässt sich oft in simpler Art und Weise erklären. Ist ein Lizenzmanager heute generell übergreifend für jegliche Softwarelizenzen und die Vermessung der entsprechenden Nutzung verantwortlich, so ist er dies im Falle von SAP-Lizenzen oftmals nicht oder aber erst seit kürzerer Zeit.

Der Grund hierfür findet sich in der häufig anzutreffenden Trennung zwischen Nicht-SAP- und SAP-IT-Organisationseinheiten. Aus Sicht des Kunden, für den das SAP-System eine Business-kritische Applikation bereitstellt, ist dies gut nachvollziehbar, aber aus Lizenzmanagement-Sicht ein grauer Fleck auf der Landkarte der zu betreuenden Applikationen.

So wurden Lizenzvermessung und Lizenzkäufe in der Vergangenheit verständlicherweise auch durch diese SAP-Organisationseinheiten veranlasst. Doch ohne die Etablierung entsprechender Rollenkonzepte und Prozesse, die beispielsweise im Falle von Unternehmensein- oder -austritten von Mitarbeitern eine Aktion anstoßen, ist es beinahe unmöglich, kosteneffizient aufgestellt zu sein.

Auch ist es schwierig für diese Organisationseinheiten, in ihrem zweifellos vorhandenen Wissen über SAP-Lizenzen mit der heutigen Entwicklung der technischen Möglichkeiten Schritt zu halten.

Konvergente und hyper-konvergente IT-Infrastrukturen sind notwendige Übel zur Gewährleistung der Ausfallsicherheit durch die Verwendung von heutigen Wide-Area-Network-Netzwerken (WAN) und ergänzen den zunehmenden Grad der Virtualisierung.

Die Auswirkung der Nutzung dieser Strukturen aus Lizenzmanagement-Sicht zu erfassen liegt jedoch oft außerhalb des entsprechenden Verantwortungsbereichs. Unterlizenzierung ist bei dem Einsatz von der Struktur abhängiger Produkte vorprogrammiert.

Alte Software-Lizenzverträge, die auf CPU oder Core-Lizenzmodellen basieren, sind beispielsweise häufig nicht auf den Einsatz in virtuellen Netzwerken ausgelegt.

Bei der Überprüfung alter Business-Objects-Verträge lässt sich dies sehr leicht feststellen und anstatt eines physischen Servers, auf dem die Software in der Vergangenheit genutzt wurde, muss nun der physische Server der virtuellen Umgebung lizenziert werden, der in aller Regel deutlich größer konfiguriert wurde, was Prozessorkerne, CPUs und Rechenleistung angeht.

Doch das wäre noch der leichter zu verschmerzende Fall. Heutige virtuelle Umgebungen umspannen jedoch zumindest mehrere physische Server, auf denen in Form eines Clusters die Arbeitslast verteilt wird. So ist man, was die Notwendigkeit von Lizenzen betrifft, von einem physischen Server schon bei mehreren angelangt. Doch auch dies ist nicht der Worst Case.

Worst Case?

Hat man aktuelle VMware-Virtualisierungstechnologie im Einsatz, so ist man über bestimmte Funktionalitäten (vMotion) in der Lage, auch Cluster-übergreifend die Arbeitslast zu verteilen.

Über den Einsatz von NSX-Technologie, durch konvergente und hyper-konvergente Infrastrukturen, ist es sogar möglich, ganze Datacenter mit einer Virtualisierungsebene zu überziehen.

Die aus Lizenzierungspflicht resultierende Notwendigkeit zum Erwerb der entsprechenden Nutzungsrechte ist hierbei kaum beherrschbar, da diese häufig nicht in die Business-Case-Betrachtung der strategischen Entscheidung zur Einführung derartiger Strukturen einbezogen wurde.

Doch die Notwendigkeit dieser Situation lässt sich anzweifeln, wird die IT-Asset-Management/Lizenzmanagement-Organisation doch genau für die Bewertung dieser Szenarien mit Ressourcen, Know-how und Kompetenzen ausgestattet, um als Trusted Advisor mit Rat und Tat zur Verfügung zu stehen.

Die Vermeidung solcher Fälle ist einer der Gründe für die Notwendigkeit einer etablierten Governance-Struktur für IT-Asset-Management.

Lizenzmodelle werden immer komplexer

Dieser zunehmende Grad an Komplexität, im Zusammenspiel mit immer komplexer strukturierten Lizenzmodellen und Lizenzbedingungen, betrifft jedoch nicht nur herstellereigene Produkte wie im Fall von SAP.

Aufgrund der beschriebenen Evolution des SAP-Ökosystems durch die Integration und Nutzung von Nicht-SAP-Produkten wirkt sich dies auf weitere Bereiche des Lizenzmanagements aus.

Dies stellt Organisationen mit einem niedrigen Reifegrad oder fehlender Governance im Lizenzmanagement vor weitreichende Herausforderungen. So ist es zur Schaffung größtmöglicher Transparenz wichtig, die eigene komponentenübergreifende Nutzung zu erkennen bzw. zu wissen, auf welchen Wegen Nutzer, Systeme, Bots und weitere Aktoren miteinander kommunizieren.

So werden heutzutage beispielsweise in der Automotive- und Maschinenbauindustrie im Rahmen der Einführung von Industrie-4.0- und IoT-Strukturen zunehmend Telemetrie-Module verbaut, die sich beispielsweise mit Meldungen zur anstehenden Wartung oder der frühzeitigen Warnung vor einer voraussehbaren Ausfallwahrscheinlichkeit beim Hersteller melden.

Hierbei geht die Integration bisweilen so weit, dass in SAP der entsprechende Support-Auftrag erstellt und ein Techniker auf den Weg geschickt wird, ohne dass es einer weiteren Interaktion bedarf. Doch das Ausbleiben einer humanen Interaktion bedeutet nicht, dass diese Szenarien nicht lizenzpflichtig wären.

Hier gilt es also mit Vertrags-, Lizenz- und technischem Wissen zu analysieren, wie ein Business Case möglichst kosteneffizient gestaltet und die Umsetzung lizenzkonform abgebildet werden kann. Eine korrekte Lizenzierung obliegt in jedem Fall dem Kunden.

Spätestens bei dem Einsatz entsprechender Produkte, die außerhalb von SAP installiert sind, jedoch auf SAP-Funktionalitäten zugreifen, ist dann der letzte Grund erkennbar, der dafür spricht, dass die für Lizenzmanagement verantwortliche Organisation unbedingt von Beginn einer Planung einzubeziehen ist.

Es ist notwendig und wichtig, in die Management-Konsolen der externen Applikationen einzutauchen oder aber bis hinab auf Ordnerlevel entsprechende Nutzergruppen zu identifizieren und deren Zugriffsrechte und Berechtigungen zu analysieren.

Die Einführung einer Governance-Struktur, die kontinuierliche Einbeziehung der Lizenzmanagement-Organisation und die stetige Kommunikation der relevanten Stakeholder sind durch diese Entwicklungen ein unabdingbarer Schritt in eine Zukunft geworden, in der die Sicherstellung der Lizenz-Compliance herausfordernder ist als je zuvor.

Neben der Nachverfolgung jedweder auf RFC-Technologie basierender Kommunikationskanäle zwischen SAP- und Drittsystemen gilt es sämtliche Non-RFC-Verbindungen (z. B. HTTP, IDoc, IPSec …) durch qualitative und quantitative Erhebungsmethoden (z. B. Dokumentationen, Systemchecks etc.) zu erfassen und auszuwerten.

Empfehlungen zum funktionalen Lizenzmanagement

Die Empfehlungen für eine funktionale Lizenzmanagement-Organisation sind für SAP, mit wenigen Ausnahmen, dieselben wie für jegliche andere Hersteller.
Grundsatz für jeden guten Lizenzmanager ist es, kommerzielle Nutzungsrechte zu kennen, Informationen über die technische Nutzungsart und das Nutzungsvolumen zu identifizieren und diese am Ende gegeneinander abzugleichen. Darüber hi­naus ist es wichtig, Entwicklungen und Veränderungen in den Lizenzierungsregeln und -metriken zu erkennen und in der eigenen Umgebung umzusetzen.
So kann Aufschluss über eine bestehende Über- oder Unterlizenzierung gewonnen werden. Folgend soll ein kurzer Überblick gegeben werden über Punkte, welche in jedem Falle zur Sicherstellung der benötigten Transparenz befolgt werden sollten.

Empfehlung: Transparenz in der indirekten Nutzung

Die indirekte Nutzung von SAP-Systemen sollte abhängig vom jeweiligen Anwendungsfall und den zugrunde liegenden Gegebenheiten individuell im Rahmen einer Szenario-Analyse betrachtet werden. Dazu hat sich der nachfolgende Referenzprozess etabliert und in der Praxis bewährt: Im ersten Schritt gilt es die initiale Datensammlung sämtlicher vermessungsrelevanter Produktiv-, Entwicklungs- oder alternativer nutzungsrelevanter Systeme einzuleiten und durchzuführen. Je nach Unternehmensgröße weisen Unternehmen mehrere Dutzend oder gar Hunderte unterschiedliche Datenquellen auf. Diese Vielschichtigkeit und Komplexität ist einer der hauptsächlichen Gründe, warum eine sorgfältig geplante und konzipierte Datenerhebung/-konsolidierung sowie eine anschließende Analyse unabdingbar sind.

Den zentralen Anlaufpunkt für die systemseitige Erhebung der Informationen zu den RFC-Verbindungen der vermessungsrelevanten SAP-Systeme stellt idealerweise eine ganzheitlich integrierte und zentral verwaltete SAP-Solution-Manager-Instanz dar.

Wenn eine solche nicht existiert, sollte eine alternative Datenquelle gefunden werden, die einen ähnlich zentralisierten Charakter aufweist. Anschließend werden die gesammelten Daten und Informationen konsolidiert und nach ihrer Relevanz sowie Kritikalität klassifiziert und priorisiert.

Die Systeme und die darauf aufbauenden Verbindungen werden abschließend nach individuellen Kriterien zur weiteren Analyse vorselektiert.

Das Resultat stellt dann idealerweise eine konsistente Gesamtübersicht der vermessungsrelevanten SAP-Systeme dar, deren Verbindungen zu Drittsystemen am kritischsten und – unter Berücksichtigung diverser Aspekte der indirekten Nutzung – relevantesten einzustufen sind.

Technische Nutzungsszenarien, auch Use Cases genannt, stellen einen elementaren Bestandteil des Vermessungs- und Erhebungsprozesses der indirekten Nutzung dar. Je nach Unternehmensgröße können einige wenige, aber auch Hunderte unterschiedlicher Szenarien der indirekten Nutzung identifiziert werden.

Um diese Komplexität ein wenig übersichtlicher zu gestalten, empfiehlt es sich, bei der Definition der jeweiligen Nutzungsszenarien eine parallele Betrachtungsweise einzunehmen. Aufbauend auf der zugrunde liegenden technischen Verbindung und je nach Ausgangslage kann aber auch ein anderer Diversifikationsgegenstand gewählt werden.

In der Regel wird aber zwischen RFC- und Non-RFC-Use-Cases unterschieden.
Nach der losgelösten Betrachtung empfiehlt es sich im nächsten Schritt, die entsprechenden Use Cases zu übergreifenden Szenarien zu konsolidieren. Zur Konsolidierung werden oftmals technische Informationen zur unterstellten Hardware- sowie Virtualisierungsebene hinzugezogen. Dies sorgt für eine weitere Präzisierung und erleichtert die anschließende Analyse und Bewertung.

Das Ergebnis dieses Prozessschrittes stellt eine Auflistung der, aus Sicht der Risikominimierung, relevantesten Nutzungsszenarien dar (in Form einer gesamtheitlich-logischen Übersicht).

Der dritte Schritt im Referenzprozess, der SAP-Lizenzabgleich, baut auf einer soliden Datenbasis auf. Zunächst empfiehlt es sich, die bereits erhobenen Daten durch Nutzungsdaten sowie die Berechtigungen der entsprechenden SAP-User auf den Zielapplikationen anzureichern.

Dies erfolgt durch einen systemseitigen Datenabzug und eine systemgestützte Auswertung dieser Daten. Ergänzt wird dies ggf. durch eine Analyse von Zugriffsrechten und Berechtigungen in der Umgebung der Zielapplikationen (beispielsweise über eine Analyse innerhalb des Active Directory).

Dabei gilt es die lizenzrelevanten Informationen zunächst zu identifizieren und einen Datenabzugs- und Auswertungsmechanismus zu entwerfen. Anschließend werden zugehörige Tätigkeitsprofile anhand der realen Nutzungsdaten entwickelt, um die tatsächliche Datenbasis als Ausgangslage nehmen zu können.

Zu beachten ist hierbei, dass die reale Tätigkeitsbeschreibung stets generisch zu betrachten ist. Sowohl die Nutzungsdaten als auch die Tätigkeitsbeschreibungen der jeweiligen Profile der Nutzer sollten idealerweise über die technischen Zugriffsberechtigungen und tatsächlich getätigten Zugriffe/Aktivitäten auf den entsprechenden SAP-Applikationen verfügen.

Dazu empfiehlt es sich, die entsprechenden Zielapplikationen auf technischer Berechtigungsebene zu analysieren. Abschließend wird der Soll-Zustand (der vertraglich angegebene Lizenzbestand) mit dem Ist-Zustand abgeglichen. Dieser wird aus der tatsächlichen Nutzung abgeleitet.

Die Erkenntnisse aus dem Lizenzabgleich werden im vierten Schritt des Referenzprozesses herangezogen, um die zuvor definierten Use Cases betriebswirtschaftlich bewerten zu können.

Neben diesen Betrachtungen werden zusätzlich Risk Assessments durchgeführt, um die Evaluierung auf einer detailreicheren und präziseren Ebene betrachten zu können. Auch hier empfiehlt es sich, zur Komplexitätsreduktion die Business Cases nach den technologischen Gegebenheiten aufzuteilen, losgelöst voneinander zu betrachten und anschließend zu übergreifenden, allgemeingültigeren Business Cases zu konsolidieren.

Anschließend werden die übergreifenden Business Cases einer kritischen Bewertung unterzogen. Diese Bewertung basiert auf zuvor definierten und gewichteten Kriterien.

Durch dieses Vorgehen wird sichergestellt, dass ausschließlich Business Cases in den engeren Kreis der Entscheidung einbezogen werden, die aus der Analyse als relevant hervorgehen. Relevant bedeutet in diesem Kontext nicht nur relevant aus Sicht der Risikominimierung, sondern vielmehr relevant zur Sicherstellung der vergleichsweise kostengünstigsten und unter Compliance-Aspekten beherrschbaren Gesamtlizenzierung.

Im letzten Schritt werden technische Möglichkeiten zur vorausschauenden Risikominimierung, oder idealerweise -vermeidung, indirekter Nutzung identifiziert. In diesem Zusammenhang erfolgt die monetäre Bewertung der potenziellen Maßnahmen.

Durch die Zusammenfassung der diversen Szenarien zu logischen Gesamtpaketen werden Vorschläge zur kostengünstigsten Gesamtlizenzierung identifiziert. In diesem Zusammenhang erfolgt die Sicherstellung der Compliance (gegebenenfalls in Absprache mit SAP) durch technische Anpassungen oder durch den proaktiven Erwerb benötigter Lizenzen.

Hierbei sollte nicht nur auf eine kurzfristige Problembeseitigung gesetzt werden. Vielmehr sollte, gegebenenfalls in Zusammenarbeit mit Spezialisten, nachhaltige Transparenz geschaffen werden. Erarbeitete Lösungsmöglichkeiten haben zum Ziel, ein Regelwerk zur Identifikation und proaktiven Bewertung indirekter Nutzung im Unternehmen zu etablieren.

Fallbeispiel: Zeiterfassung

Um das Beispiel der Zeiterfassung näher zu beleuchten und zu verstehen, wann eine
Eigenlösung einen Compliance-Verstoß verursacht, werden drei verschiedene Szenarien
zur Veranschaulichung herangezogen.

Mitarbeiter eines Unternehmens nutzen eine eigenentwickelte oder Dritthersteller-Zeiterfassungssoftware zur Arbeitszeiterfassung. Über SAP PI werden die Daten in das vorgesehene SAP-System gespielt.

1. Szenario:

Lizenzpflichtig wären damit alle User, welche die Zeiterfassungssoftware nutzen. Die genaue Höhe der benötigten Named-User-Lizenzen würde eine Analyse voraussetzen, in der überprüft wird, ob die Nutzer der Zeiterfassung bereits über Named-User-Lizenzen verfügen und ob die darin enthaltenen Rechte ausreichend sind. Zusätzlich bedarf es der Lizenzierung der Eigen- bzw. Drittanwendung (Zeiterfassung) mit SAP NetWeaver Foundation for Third-Party Applications.

2. Szenario:

Ein mögliches Zwischenschalten von Nachrichten-Warteschlangen, die Daten nur im Bulk und zeitverzögert über PI an das vorgesehene SAP-System weitergeben, könnte eine Lösung darstellen, welche die Nutzer nicht zwangsläufig als lizenzrelevant einstuft. Diese mögliche technische Lösung bedarf aber mindestens zweier Voraussetzungen:

• Vertragliche Voraussetzungen müssen entsprechend vorhanden sein.
• Funktionen der Non-SAP-Software sind nicht bereits in verfügbaren SAP- Lösungen enthalten.

Diese Art der Lizenzierung ist jedoch nicht eindeutig festgeschrieben, sodass im Zweifelsfall mindestens eine Lizenzpflicht wie in Szenario 1 existiert, wenn SAP-Software dieselben Funktionalitäten anbietet. Hinzu kommen würde ggf. noch eine entsprechende Lizenz für das eingesetzte Message Queuing. Dies gilt es im Zweifelsfall zu analysieren.

3. Szenario:

Eine weitere Lösung könnte das Zwischenschalten eines Mitarbeiters von HR oder eines Shared-Service-Mitarbeiters darstellen, der manuell die Daten aus den Berichten der Nicht-SAP-Applikation in SAP erfasst. Dieser Mitarbeiter wäre zu lizenzieren und es gilt sicherzustellen, dass die richtige Lizenz zugewiesen wurde. Im Regelfall wäre es für einen HR-Mitarbeiter eine SAP-Professional-User-Lizenz.

Einsichten und Aussichten

Herausforderungen im Lizenzmanagement sind kein Thema, das SAP-spezifisch ist. Vielmehr gibt SAP, wie bereits beschrieben, ihren Kunden ein Tool an die Hand, um eine korrekte Lizenzierung zu unterstützen. Warum ist Software-Asset-Management dennoch gefühlt ein hochkomplexes Thema, das oftmals zu Problemen führt?

Die Digitalisierung von Geschäftsmodellen funktioniert mit Software und in vielen Bereichen ist Software die Basis für das Funktionieren von Geschäftsprozessen und -modellen.

Die zunehmende Komplexität in dem Betrieb von IT-In­frastrukturen und den entsprechenden Softwareanwendungen erhöht gleichzeitig auch die Komplexität einer korrekten Lizenzierung der eingesetzten und genutzten Software. Einfaches „Zählen, Messen und Wiegen“, wie man es in der Vergangenheit konnte, hilft nicht mehr.

Seit Virtualisierung und Cloud Computing verstärkt genutzt werden, haben die Lizenzmodelle der Softwarehersteller durch diese technologischen Entwicklungen an Komplexität stark zugenommen.

Viele Unternehmen sind nun gefragt, im Lizenzmanagement Hybridmodelle aufzubauen, die einerseits das originäre Lizenzmanagement und andererseits auch das Management von Subscription-Modellen verbinden. Diese Aufgabe erfüllt kaum eine Lizenzmanagement-Organisation.

Hinzu kommt, dass dieses Thema bei den meisten CIOs aktuell keinen prominenten Platz auf der Agenda hat. In unserer Beratungspraxis machen wir die Erfahrung, dass Unternehmen mit über 100.000 Mitarbeitern nur eine Person im Lizenzmanagement haben, die das Lizenzmanagement für Hunderte Softwareprodukte ausführen soll.

Nicht selten wird dies dann nicht durch ein professionelles SAM-Tool unterstützt, sondern das Management erfolgt mithilfe von Excel-Listen. Führt man sich vor Augen, dass ein einziger Softwarehersteller ca. 50 Lizenzbedingungen in jeder Woche ändert, so kann das Ergebnis einer derartigen Konstellation nur eine „In-Compliance“ sein.

Aufkommende Diskussionen zu speziellen Themen, aktuell beispielsweise zum Thema „indirekte Nutzung“, erhöhen die Unsicherheiten im Lizenzmanagement, wobei dieses Thema bereits seit Jahren von verschiedenen Softwareherstellern adressiert wird.

Durch die jüngsten Zugeständnisse seitens SAP hinsichtlich der Bereitstellung entsprechender Lizenzmodelle für die gängigsten Szenarien empfiehlt sich eine zeitnahe Evaluierung der individuellen Lizenzsituation, um von diesen Zugeständnissen proaktiv zu partizipieren, anstatt im Falle eines Lizenzaudits die angebotenen Möglichkeiten ggf. nicht mehr, oder nicht vollständig nutzen zu können.

Cloud ist derzeit bei allen Softwareherstellern ein Topthema und Kunden versprechen sich davon Kosteneinsparungen gegenüber ihren derzeitigen Kosten für Lizenzen und Wartung. Wie soll ein Kunde aber eine Wirtschaftlichkeitsbetrachtung anstellen, wenn er gar nicht weiß, ob er derzeit korrekt und kosteneffizient lizenziert ist?

Einen Business Case sollte man auf einer soliden Basis rechnen und dazu trägt ein funktionierendes Software-Asset-Management bei. Gleiches gilt auch für das Thema Cyber Security.

Ein funktionierendes SAM hilft einem Unternehmen, stets einen aktuellen Blick auf die eingesetzte Software zu einem jeweiligen Versionsstand zu haben und so versionsspezifische Security-Risiken sauber analysieren zu können.

Was sollten IT-Entscheider machen, was empfiehlt sich, um den beschriebenen Herausforderungen zu begegnen? Ein Unternehmen, das sich mit SAM befasst, sollte ein Governance-Modell mit Rollen, Verantwortlichkeiten und Prozessen implementieren, die ein effektives und effizientes Lizenzmanagement ermöglichen.

In großen Unternehmen ist das keine Aufgabe, die durch ein oder zwei Mitarbeiter bewerkstelligt werden kann, sondern die SAM-Organisation sollte die Komplexität des Gesamtunternehmens widerspiegeln.

Es sollte ein SAM-Tool eingesetzt werden, das die Lizenzmanager in ihren Aufgaben unterstützt und eine Steuerung des Themas erlaubt. Ein Schwenk hin zu Subscription-Modellen ist keine Lösung, um Defizite im Lizenzmanagement zu beheben.

Entscheidend für ein erfolgreiches Lizenzmanagement ist das Commitment des Topmanagements. Für den CIO muss SAM eine wichtige Komponente seiner übergeordneten IT-Strategie sein. Eine sichere Basis ist die Grundvoraussetzung, um Business Cases zu berechnen und solide Investitionsentscheidungen für neue Technologien zu treffen.

Internationale Studienergebnisse prognostizieren, dass 2017 über 75 Prozent aller Cloud-Transformationsaktivitäten ohne Kenntnis der tatsächlichen Lizenzkosten vor der Entscheidung und ohne ein wirksames Controlling während der Transformation stattfinden. Das gibt zu denken!

[/av_textblock]