Fnp wp motorola_july10_ger

1. Erhöhen der Kundenzufriedenheit
durch bessere Qualität
der Lizenzimplementierung
Dan Griffith – Geschäftsführer, Comprehensive Software Asset Management, Motorola
Rich Kline – Strategischer Berater, Flexera Software
WHITEPAPER

2. Erhöhen der Kundenzufriedenheit durch
bessere Qualität der Lizenzimplementierung
Kurzfassung
Unzählige Anbieter von Software und eingebetteter Software ha-
ben die Lizenzierungslösung FlexNet® von Flexera Software erfolg-
reich implementiert, um die Verwendung nicht lizenzierter Software
zu verringern, neue kundenorientierte Lizenzierungsmodelle auf
den Weg zu bringen und die Fähigkeit der Kunden im Hinblick
auf die Lizenzgüterverwaltung zu verbessern. Zur Gewährleistung
erfolgreicher Lizenzimplementierungen in vielen verschiedenen
Anwendungen stellt Flexera Software eine äußerst robuste und
flexible Lizenzierungsfunktion zur Verfügung. Flexera Software hat
jedoch bisher noch keine Best Practice-Richtlinien für die Lizenzim-
plementierung formuliert. Dies hat dazu geführt, dass die Qualität
der Lizenzimplementierungen bei den verschiedenen Anbietern aus
der Perspektive des Endbenutzers sehr unterschiedlich ist.
In diesem Whitepaper, das gemeinsam von Flexera Software, dem
laut IDC branchenführenden Unternehmen im Bereich Softwareli-
zenzierung, und Motorola, einem bedeutenden Mitglied der
Lizenzbenutzercommunity, ausgearbeitet wurde, sollen Anbieter
darin geschult werden, die Qualität von Lizenzimplementierungen
zu verbessern. Dabei werden die häufigsten Probleme, denen sich
Endbenutzer stellen müssen, in einer Übersicht zusammengefasst
und wichtige Hinweise für die Implementierung gegeben, die
Anbieter beachten sollten. Schließlich wird das FlexNet-Zertifizie-
rungsprogramm vorgestellt, mit dem Anbieter die Qualität ihrer
FlexNet-Lizenzimplementierungen kostengünstig überprüfen und
zertifizieren können.
Die Qualität von Lizenzimplementierungen
Hintergrund
Die Mehrheit der zahlreichen Unternehmenskunden von Flexera
Software hat bereits globale Infrastrukturen für die Softwarelizen-
zierung implementiert oder befindet sich gerade mitten im Prozess
einer solchen Implementierung. Mit diesen Infrastrukturen können
große Unternehmenskunden Lizenzen innerhalb von Benutzercom-
munitys, die geografisch oder organisatorisch fragmentiert sind,
gemeinsam verwenden.
Viele Unternehmen haben für ihre Endbenutzercommunitys eine
zentrale Beschaffungs- und Lizenzverwaltung implementiert, damit
diese attraktive Lizenzverträge für Unternehmen nutzen können und
Rabatte bei Lizenzmodellen sowie günstige Konditionen erhalten.
Außerdem geben sie einen Großteil der Dynamik weiter, die auf
dem Markt im Hinblick auf eine nutzenorientierte Preisgestaltung
und Software as a Service (SaaS) entsteht.
Da globale Lizenzinfrastrukturen immer mehr genutzt werden, um
FLEX-fähige Anwendungen bereitzustellen, werden die Unterschiede
zwischen Lizenzimplementierung mit hoher und niedriger Qualität
immer deutlicher und führen bei Systemadministratoren, die diese
Netzwerke verwalten, zu Frustration. Gleichzeitig stehen Adminis-
tratoren zunehmend unter Druck und müssen bei der Berichterstel-
lung für Unternehmensinhaber und Budgetverantwortliche immer
mehr Feinheiten berücksichtigen.
Das serverbasierte Lizenzmodell
Folgenden Problemen müssen sich Lizenzadministratoren innerhalb
der Unternehmensumgebung häufig stellen:
• Lizenzdateien, die nur schwer dem Produkt zugeordnet werden
können, für das Lizenzen bestellt und erworben wurden
• Anwendungen, deren Lizenzverwendung äußerst kompliziert
ist und für die eine genaue Berichterstellung in einigen Fällen
unmöglich ist
• Anwendungen mit komplexen Lizenzabhängigkeiten
• Anwendungen, die durch unlogische und nicht kundenfreundli-
che Abläufe Probleme bereiten, wenn eine Lizenz abläuft oder
aus anderen Gründen nicht mehr verfügbar ist
Dieses Whitepaper enthält Empfehlungen zu
heutzutage häufig auftretenden Problemen bei der Beschaffung,
Berichterstattung und den Abhängigkeiten.
Empfehlungen zur Lizenzimplementierung
Betrachten Sie die Lizenzierung als eine der wichtigsten Produkt-
komponenten.
Behandeln Sie die Lizenzierung wie jede andere Produktkom-
ponente. Entwickeln und binden Sie Ihre Lizenzimplementierung
ein, bevor die Testphase für das Produkt beginnt. Dadurch wird

3. Erhöhen der Kundenzufriedenheit durch bessere Qualität der Lizenzimplementierung
3Flexera Software: Whitepaper-Reihe zur FlexNet Producer Suite
sichergestellt, dass Ihr Lizenzierungssystem nicht einfach nur ein
Anhängsel ist und ordnungsgemäß getestet werden kann.
Als positiver Nebeneffekt dieses Ansatzes wird die Effizienz der
Testphase erhöht. Durch die Nutzung von Berichten zur Lizenz-
verwendung, die Tester von Betaprogrammen erstellen, kann
gezeigt werden, wie die lizenzierten Produkte tatsächlich verwen-
det werden – Informationen, die andernfalls nicht zur Verfügung
stehen. Durch die Herausgabe von Nodelocked-Lizenzen mit einem
bestimmten Ablaufdatum wird sichergestellt, dass Ihre neuesten
Produkte nicht in den Händen von Wettbewerbern landen.
Mit Lizenzen für Anwendungsversionen, die am Ende der Beta-
phase auslaufen, wird außerdem gewährleistet, dass Kunden ein
Upgrade auf Ihr endgültiges Release vornehmen, sodass die laufen-
den Supportkosten gesenkt werden.
Entwickeln Sie eine Architektenfunktion für die Lizenzierung.
Flexera Software empfiehlt Anbietern, einen Verantwortlichen für
die Lizenzierungsarchitektur zu bestimmen, der für eine einheitliche
Implementierung bei den verschiedenen Produkten und Produktlini-
en sorgt. Lizenzadministratoren lehnen es ab, wenn Produkte von
dem gleichen Hersteller über verschiedene Richtlinien zur Ausfallsi-
cherung verfügen oder bei einer im Grunde gleichen Verwendungs-
einheit unterschiedliche Definitionen und Anweisungen vorliegen.
Die Berichterstattung zur Verwendung der lizenzierten Funktionen
muss innerhalb eines Produktkontexts erfolgen.
Mit einfachen Worten: Geben Sie Kunden die Möglichkeit,
Berichte zur gesamten Verwendungszeit eines Produkts sowie zur
Verwendung lizenzierter Produktfunktionen zu erstellen.
Dies kann am besten bewerkstelligt werden, wenn ein primärer
Funktionsname vorhanden ist, mit dem diese Richtlinien eingehalten
werden.
• Mit dem Namen muss das Produkt, dem der Name zugewiesen
ist, eindeutig identifizierbar sein.
• Er muss immer, wenn das Produkt ausgeführt wird, ausgecheckt
werden und während der gesamten Zeit, in der das Produkt
verwendet wird, ausgecheckt bleiben.
• Der Name muss eindeutig sein und kann nicht gemeinsam mit
oder bei anderen Produkten verwendet werden. Während der
Entwicklung neuer Produkte oder bei der Bündelung von Produk-
ten darf der primäre Funktionsname eines vorherigen Produkts
nicht bei der Lizenzierung des neuen Produkts bzw. Produktbün-
dels verwendet werden.
Weitere Hinweise zur Art und Weise, wie Kunden in der Regel
Berichte zur Lizenzverwendung erstellen möchten, erhalten Sie,
wenn Sie sich die folgende Produktfamilie ansehen. Bei dieser sind
sowohl Kern- als auch optionale Funktionen lizenziert: Beachten
Sie, dass zur Ausführung von „Graph 10“ die Lizenz für „Chart 10“
Chart 10
chart.primary , 150 $
Graph 10
chart.graph , 50 $
Write 10
write.primary , 100 $
Present 10
tool-suite.present
Count 10
tool-suite.count
Print 10
common.print , 150 $
Tool Suite 10
tool-suite.primary , 200 $
In Diagramm 1 sind die Produkte „Chart 10“ und „Tool Suite 10“ dargestellt, wobei „Tool Suite 10“ die Shell-Anwendung ist, mit der die
Produktkomponenten „Write 10“, „Present 10“ und „Count 10“ aufgerufen werden.

4. Erhöhen der Kundenzufriedenheit durch bessere Qualität der Lizenzimplementierung
4 Flexera Software: Whitepaper-Reihe zur FlexNet Producer Suite
zunächst über einen Lizenzserver aktiviert werden muss. Das
gleiche gilt für „Present 10“ und „Tool Suite 10“. Da zwei Lizenzen
benötigt werden, können Kunden Berichte zur Gesamtnutzung des
jeweiligen Produkts sowie zur Nutzung der sekundären Funkti-
onskomponenten erstellen. Dies ist beim Produkt „Tool Suite 10“
besonders wichtig, bei dem die Einzellizenzen für „Write 10“,
„Present 10“ und „Count 10“ unter Umständen häufig ausgecheckt
und zurückgegeben werden. Es wird jedoch immer mindestens
eine Komponente und damit auch eine Lizenz für „Tool Suite 10“
verwendet.
Sekundäre Funktionen werden verwendet, um optionale Kompo-
nenten Ihrer Anwendung zu lizenzieren. Beispiel: Ein Kunde erwirbt
„Chart 10“ für 150 $ (siehe Diagramm 1) sowie das „Graph“-
Modul für 50 $. Für den Zugriff auf die Graph-Funktionen kann
nun eine Teilfunktion verwendet werden. Diese Lizenz kann dem
Kunden entweder während des Erstkaufs oder zu einem späteren
Zeitpunkt zur Verfügung gestellt werden, wenn der Kunde diese
Funktion benötigt.
Gemeinsame Funktionen werden verwendet, um Softwarekom-
ponenten zu lizenzieren, die bei mindestens zwei Ihrer primären
Anwendungen gemeinsam verwendet werden. Wenn genau
ermittelt wird, welche Komponenten gemeinsam verwendet werden
und von welchen Anwendungen diese genutzt werden (siehe Ab-
schnitt „Nutzung der FlexNet-Auscheckdaten zur Bereitstellung des
Produktkontexts“), sind Kunden in der Lage, genaue Berichte über
die Verwendung zu erstellen.
Die Verwendung der Paketfunktionen von FlexNet
Ausgehend vom vorherigen Beispiel ergibt sich die Frage, was pas-
siert, wenn „Tool Suite 10“ kein einzelnes Produkt ist, sondern ein
ganzes Marketingpaket (mit den eigenständigen Produkten „Write
10“, „Present 10“ und „Count 10“) umfasst? Dieses Marketingpa-
ket wird beim Veröffentlichen der Produkte nicht starr festgelegt,
sondern wird in der Lizenzdatei unter Umständen dynamisch
erstellt, sogar nachdem die Produkte beim Kunden bereits installiert
wurden.
In diesem Fall ist es möglich, Berichte über die Verwendung des
Gesamtpakets „Tool Suite 10“ sowie über die einzelnen Kompo-
nenten dieses Marketingpakets zu erstellen. Hierfür wird das Paket
„Tool Suite 10“ in der Lizenzdatei mit den folgenden Hilfsmitteln
erstellt:
die Option SUITE_RESERVED
PACKAGE Tool_Suite_10 vendorname 10.0
COMPONENTS = “write.primary present.primary
count.primary” OPTIONS=SUITE_RESERVED
Damit können Benutzer sowohl Berichte über die Verwendung des
gesamten Pakets als auch über die der einzelnen im Paket enthalte-
nen Komponenten erstellen.
Die Implementierung einheitlicher Konventionen
für Funktionsnamen
Daemon-Namen für Hersteller
Hersteller-Daemons sollten so ausgewählt werden, dass Kunden
den Softwarehersteller problemlos ermitteln und lokalisieren können.
Namenskonvention für Funktionen
Unsere empfohlene Namenskonvention für Funktionen sieht wie
folgt aus:
application_name.feature_type
Die Beispielsyntax für die primäre Funktion des Produkts „Chart 10“
in Diagramm 1 lautet folgendermaßen:
chart.primary
Die Beispielsyntax für die Teilfunktionen von „Chart 10“ lautet
folgendermaßen:
chart.graph
chart.pivot (nicht abgebildet)
Beispielsyntax für die Benennung der gemeinsamen Funktionen:
common.print
common.export
Durch die Implementierung einer gut durchdachten Namenskonven-
tion können Produkt- und Funktionsname in einer einzigen Lizenz-
datei verstanden werden, und zwar unabhängig vom umgebenden
Kontext. Dies ist besonders dann wichtig, wenn Sie über viele
Produkte verfügen oder mehrere Lizenzmodelle unterstützen (z. B.
Nodelocked- und Floating-Lizenzen).
Für Funktionsnamen sollten keine Abkürzungen verwendet werden,
es sei denn, sie können mit der zugehörigen Funktion problemlos
assoziiert werden, werden in der Produktdokumentation erläutert
und lassen sich in den Onlinehilfedateien suchen.
Abkürzungen ohne Bedeutung führen zu den Berichterstellungspro-
blemen, denen heutzutage bei vielen Lizenzimplementierungen
begegnet wird.
Betrachten wir die Funktion „Chip Compiler“
Zulässige Abkürzungen:
ChpCom, ChpComp, ChipComp usw.
Nicht zulässige Abkürzung:
ChpOpt
Hersteller sollten sich bemühen, die Standards für die Funktionsbe-
nennung während des gesamten Produktlebenszyklus einzuhalten.
Namensänderungen mitten im Produktlebenszyklus können die
Berichte über die Lizenzverwendung und die zugehörigen Prozesse
erheblich beeinträchtigen. Weitere Informationen hierzu erhalten
Sie unten in den Kommentaren unter „Funktionsbenennung und
Versionsvergabe bei Anwendungen“.
Implementierungshinweis: Funktionsbenennung und Lizenzsicherheit
Flexera Software empfiehlt, den Funktionsnamen, der zum Ausche-
cken weitergeleitet wird, in einem dynamischen Speicher aufzu-
bewahren. Funktionsnamen in einem statischen Speicher können
die Sicherheit in zweierlei Hinsicht beeinträchtigen. Erstens lassen
sie sich problemlos in der Binärdatei einer Anwendung finden und
können von jedem, der über Basiskenntnisse in der Softwareent-
wicklung verfügt, geändert werden. Ein Kunde mit einer für ein
bestimmtes Produkt gültigen Lizenz könnte beispielsweise ein
anderes Produkt aktivieren, indem er einfach den Funktionsnamen
des zweiten Produkts so ändert, dass dieser zum Produkt seiner
gültigen Lizenz passt. In diesem Fall kann der Funktionsname nur

5. Erhöhen der Kundenzufriedenheit durch bessere Qualität der Lizenzimplementierung
5Flexera Software: Whitepaper-Reihe zur FlexNet Producer Suite
so geändert werden, dass der neue Name zumindest die gleiche
Anzahl an Zeichen enthält.
Zweitens bilden Namen im statischen Speicher ein Ziel für Soft-
warepiraten, die versuchen, in der Anwendung den eingebetteten
FlexNet-Lizenzcode zu finden. Wenn der Aufruf zum Auschecken
im Code gefunden wird, kann dies zu einer Deaktivierung der
Lizenz führen. Zugegebenermaßen erfordert dies mehr als nur ein
grundlegendes Verständnis von Software und auch ein bestimmtes
Maß an Entschlossenheit.
Folglich sollten Hersteller alle Komponenten von Funktionsnamen
dynamisch aufbauen, damit sichergestellt wird, dass sich die
Funktionsbenennung nicht zum schwächsten Glied in der Kette
entwickelt.
Funktionsbenennung und Versionsvergabe bei Anwendungen
Wenn Kunden eine neue Version einer Anwendung von einem
bestimmten Hersteller lizenzieren, sind sie normalerweise dazu
berechtigt, die aktuelle Version der Anwendung weiterhin aus-
zuführen, vorausgesetzt, die Verwendung der alten und neuen
Versionen der Anwendung ist im Rahmen der Lizenzgewährung
zulässig. Viele Hersteller fördern diese Vorgehensweise, indem sie
die datumsbezogene Versionsvergabe von FlexNet implementieren.
Hier umfasst die Produktlizenz für die Dauer des jeweiligen War-
tungsvertrags die Rechte, die für die Upgrades der Anwendung
notwendig sind.
In solchen Fällen ist es für einen Hersteller nicht sinnvoll, Funktions-
namen bei den verschiedenen Anwendungsversionen zu ändern.
Dennoch möchten Hersteller manchmal die Verwendung von
Funktionen aus zurückliegenden Versionen unterbinden, wenn eine
neue Produktversion veröffentlicht wird. Dies kommt in der Regel
bei Produktmigrationen oder Obsoleszenzstrategien vor. In diesen
Fällen müssen die Hersteller die Funktionsnamen innerhalb eines
zusammengehörigen Produktsets, das ähnliche Funktionen umfasst,
ändern.
Wenn die folgende Namenskonvention für Funktionen eingehalten
wird:
application_name.feature_type
können Hersteller mit diesen Situationen besser umgehen, da
unter dem Namen der neuen Anwendung auf die Funktionsnamen
verwiesen wird.
Nutzung der FlexNet-Auscheckdaten zur Bereitstellung
des Produktkontexts
Mit FlexNet können detaillierte Daten zu angeforderten Lizenzfunk-
tionen erfasst und von Herstellern oder Endbenutzern in Berichtspro-
tokollen für die spätere Berichterstellung gespeichert werden. Wenn
Sie Auscheckdaten festlegen, entsteht zwischen einer gemeinsa-
men Komponente und der Anwendung, von der die Anforderung
stammt, eine Verknüpfung.
Ein nützliches Beispiel hierfür sieht folgendermaßen aus:
In dem Beispiel aus Diagramm 1 teilt sich die Anwendung
„Chart“ mit mehreren Anwendungen eine gemeinsame Kompo-
nente. Wenn „Chart“ (chart.primary) die Komponente „Print“
(common.print) aufruft, kann mit FlexNet protokolliert werden,
dass die Anforderung für die Komponente „Print“ von der An-
wendung „Chart“ (chart.primary) ausging.
Durch die Bereitstellung dieser Daten für FlexNet werden sowohl
Sie als auch Ihre Endbenutzer verstehen können, wie Produkte
eingesetzt werden und Trends bei der Softwareverwendung
entdecken.
Nutzen Sie die FlexNet-Auscheckdaten zur Bereitstellung von
Produktversionen.
Wir empfehlen bei der Berichterstellung, dass Hersteller die Num-
mer der Produktversion (oder das Versionsdatum) als Auscheckdaten
an den Lizenzserver weiterleiten. Dadurch können Kunden Berichte
zur tatsächlichen Version der verwendeten Funktionen erstellen
sowie zur Lizenzversion, mit der diese Funktion bereitgestellt wurde.
Normalerweise animieren Hersteller ihre Endbenutzer, zur aktuellen
Version einer Anwendung zu wechseln. Dennoch gibt es keine
Möglichkeit, mit der sich die Benutzer, die alte Anwendungsver-
sionen ausführen, problemlos ermitteln lassen, es sei denn, die
Hersteller sorgen für eine Berichterstellung, aus der diese Informati-
onen hervorgehen.
Paint
paint.primary
Draw
draw.primary
Sculpt
sculpt.primary
ART STUDIO
Diagramm 2

6. Erhöhen der Kundenzufriedenheit durch bessere Qualität der Lizenzimplementierung
6 Flexera Software: Whitepaper-Reihe zur FlexNet Producer Suite
Die Verwendung von FlexNet-Paketen für eine einfachere
Zuordnung von Lizenzdateien und Kundenbestellungen
FlexNet bietet zwei verschiedene Möglichkeiten (Lizenzschlüssel-
wörter) zur Erstellung von Produktpaketen:
• PACKAGE. Hierbei handelt es sich einfach um die Möglich-
keit, ein Set aus lizenzierten Produkten oder Komponenten in
der Lizenzdatei zu bündeln. Dies hat keinen Einfluss auf die
Lizenzierung oder die Berichterstellung.
• PACKAGE_SUITE_RESERVED. Hierbei handelt es sich um die
Möglichkeit, ein Set aus lizenzierten Produkten oder Kompo-
nenten in der Lizenzdatei zu bündeln und dabei Einfluss auf
das Verhalten dieser lizenzierten Komponenten während der
Ausführungszeit zu nehmen. So werden diese Komponenten
aus der Perspektive der Lizenzverwendung als ein Paketbün-
del behandelt. Wie bereits oben erwähnt, können mit dieser
Option Berichte sowohl zur Verwendung des Gesamtpakets
als auch der einzelnen Komponenten erstellt werden.
Dementsprechend eignen sich Pakete sowohl für die Vereinfachung
der Inhalte einer Lizenzdatei (PACKAGE) als auch für die Durchset-
zung gebündelter Lizenzmodelle (PACKAGE_SUITE_RESERVED).
Wir empfehlen Herstellern die Verwendung der FlexNet-Paketfunk-
tionen, weil wir Kunden eine einfachere Möglichkeit bieten möch-
ten, die empfangenen Lizenzdateien den tatsächlich erworbenen
Produkten zuzuordnen. Denken Sie an die hypothetische Produkt-
suite „Art Studio“ mit den an sich eigenständigen Produkten „Paint“,
„Draw“ und „Sculpt“.
Ohne die Verwendung des FlexNet-Pakets würde ein Kunde, der
eine Version des Bündels „Art Studio“ bestellt, um es auf dem
Host „Madison“ zu installieren, die folgende FlexNet-Lizenzdatei
erhalten (Lizenzdateielemente wurden aus Gründen der Klarheit
abgekürzt):
INCREMENT paint.primary vendor 1.0 permanent uncounted
HOSTID=”Madison” . . . . .
INCREMENT draw.primary vendor 1.0 permanent uncounted
HOSTID=”Madison” . . . . .
INCREMENT sculpt.primary vendor 1.0 permanent uncounted
HOSTID=”Madison” . . . . .
Von der Einkaufsseite aus betrachtet, sieht diese Lizenzdatei im
Vergleich mit der folgenden Lizenzdatei sehr ungünstig aus:
PACKAGE ArtStudio vendor 1.0 COMPONENTS =
”paint.primary draw.primary sculpt.primary”
INCREMENT ArtStudio vendor 1.0 permanent uncounted
HOSTID=”Madison” . . . . .
Die zweite Lizenzdatei, die genau dieselben Lizenzinformationen
wie die erste Lizenzdatei enthält, lässt sich bedeutend einfacher
dem bestellten und bezahlten Artikel zuordnen.
Das FlexNet-Zertifizierungsprogramm
Flexera Software hat das FlexNet-Zertifizierungsprogramm entwi-
ckelt, um Herstellern eine spezielle Hilfestellung bei der Lizenz-
implementierung zu geben und sie bei den Problemen, denen
Lizenzadministratoren begegnen, zu unterstützen. Das Programm
gibt Herstellern und Endbenutzern in Unternehmen außerdem die
Möglichkeit, FLEX-fähige Anwendungen gemäß den branchenübli-
chen Best Practices bereitzustellen.
Unter dem FlexNet-Zertifizierungsprogramm zertifiziert Flexera Soft-
ware die Lizenzimplementierungen von Herstellern und verwendet
dabei Kriterien aus den folgenden Bereichen:
• Lizenzverteilung
• Produkt- und Lizenzserverinstallation
• Anwendungsverhalten bei der Suche nach Lizenzen, die
Handhabung auslaufender Lizenzen, die Handhabung von
Ausfallbedingungen beim Lizenzserver
• Berichterstellung – Fähigkeit, genaue und eindeutige Berichte
zur Lizenzverwendung zu erstellen
• Warnungen – Verfügbarkeit und Konfigurierbarkeit von
Warnmeldungen
Die vollständigen Richtlinien zum FlexNet-Zertifizierungsprogramm
erhalten Sie unter www.flexerasoftware.com. Dort erfahren Sie
auch, wie Sie die Zertifizierung einer Anwendung beantragen
können.
Zusammenfassung
Die Qualität vieler Lizenzimplementierungen von heute ist im
Hinblick auf Benutzerfreundlichkeit und Berichterstellung völlig
unzureichend. Ohne eine definierte Lizenzierungsrichtlinie riskieren
Hersteller bei ihrer gesamten Produktpalette inkonsistente Lizenzim-
plementierungen. Wenn sich die definierte Lizenzierungsrichtlinie
eines Herstellers nicht am Kunden orientiert, verliert der Hersteller
außerdem die Möglichkeit, den Produktwert für den Kunden erheb-
lich zu erhöhen. Diese Situation tritt in der Regel auf, wenn das
Toolkit für die Lizenzierung an Produktentwicklungsgruppen über-
geben wird, ohne dass der Hersteller zuvor seine Lizenzierungs-
richtlinien festgelegt und diese den verschiedenen Produktgruppen
unmissverständlich vermittelt hat.
Die Lösung zu diesen und anderen Problemen besteht darin, die
Lizenzierung als eine der wichtigsten Produktfunktionen und nicht
als ein Anhängsel zu betrachten. Darüber hinaus sollten Hersteller
während des gesamten Lizenzimplementierungsprozesses auf die
Anwendungsfreundlichkeit für den Kunden achten.
Angesichts der großen Projekte, die bei Unternehmen mit einer gro-
ßen Endbenutzerbasis, z. B. bei Motorola, Chevron, Texaco, Shell,
Honeywell, Pfizer, Northrop Grumman, AMD, Intel, Shell, BP und
NASA, durchgeführt werden, um globale Infrastrukturen für die Ver-
waltung der Softwarelizenzierung und für die Berichterstellung zu
implementieren, wird deutlich, dass die Verbesserung der Lizenz-
implementierung besonders zeitkritisch ist. Durch die zunehmende
Zentralisierung von Beschaffung und Verwaltung fallen Hersteller mit
weniger guten Lizenzimplementierungen immer mehr auf, insbeson-
dere bei Verkäufen an Fortune 500-Unternehmen.
Die Erhöhung der Transparenz bei der Lizenzierung liegt in jedem
Fall im Interesse der Hersteller selbst. Wenn Kunden einfacher
zeigen können, dass sie Produkte aktiv nutzen, ist es auch für
Hersteller leichter, ergänzende Produkte und Lizenzen zu verkaufen,
insbesondere bei steigenden Nutzungsraten. Eine eindeutige und
genaue Berichterstellung über die Verwendung bildet die Grundla-

7. Erhöhen der Kundenzufriedenheit durch bessere Qualität der Lizenzimplementierung
7Flexera Software: Whitepaper-Reihe zur FlexNet Producer Suite
ge für ein stabiles Set an Lizenzierungsmodellen, aus denen Kun-
den bei ihren Einkäufen wählen können, und ist Voraussetzung
für die nutzungsorientierten Preismodelle von heute und morgen.
Informationen zu Flexera Software Consulting
Die Beratungssparte von Flexera Software steht Softwareherstel-
lern zur Verfügung, um ihnen bei FlexNet-Implementierungen zur
Seite zu stehen. Unser Ziel ist es, Anbieter von Software und ein-
gebetteter Software bei der Implementierung von FlexNet zeitge-
recht und vorhersehbar zu unterstützen und dabei für schnellere
Erträge zu sorgen und den ROI zu erhöhen. Flexera Software
verfügt über mehr als 20 Jahre Erfahrung in der Lizenzierungs-
technologie und bei der Arbeit mit der FlexNet-Plattform. Das
Unternehmen bietet umfassende Beratungsdienstleistungen,
darunter die Lizenzierungsbewertung, die Strategieentwicklung,
die Anforderungsentwicklung, Schulungen vor Ort, die Imple-
mentierung von Lizenzierungen und Operationen sowie die
FlexNet-Zertifizierung. Weitere Informationen erhalten Sie unter
www.flexerasoftware.com.
Informationen zu Flexera Software
Flexera Software ist der führende Anbieter strategischer Lösungen
für die Verwaltung der Anwendungsnutzung. Diese Lösungen sor-
gen für fortwährende Compliance, eine optimierte Nutzung und
maximale Wertschöpfung bei Anwendungsherstellern und ihren
Kunden. Über 80.000 Kunden vertrauen auf Flexera Software.
Sie benötigen unsere umfassenden Lösungen bei der Installati-
on und Lizenzierung, der Verwaltung von Berechtigungen und
Compliance sowie im Hinblick auf die Einsatzbereitschaft der
Anwendungen und die Lizenzoptimierung in Unternehmen. Da-
durch können sie die Anwendungsnutzung strategisch verwalten
und herausragende Ergebnisse erzielen, die nur mit unserem
Ansatz auf Systemebene ermöglicht werden. Flexera Software ist
ein Unternehmen in Privatbesitz und entstand durch eine Investi-
tion der Private-Equity-Gesellschaft Thoma Bravo, LLC. Weitere
Informationen hierzu finden Sie unter
http://www.flexerasoftware.com
Informationen zu den Verfassern
Dan A. Griffith (Dan.Griffith@motorola.com)
Dan A. Griffith ist Leiter des Teams „Comprehensive Software
Asset Management“ (CSAM) bei Motorola, das für die Vertei-
lung von EDA-Softwarelizenzen an sämtliche Motorola-Entwick-
lungszentren weltweit von einem zentralen Lizenzserver in den
USA aus verantwortlich ist. CSAM verfügt über 20 Lizenzserver,
die sich in Arizona und Illinois befinden. Auf diesen Servern
wurden 2002 59 Millionen Stunden Lizenznutzung protokolliert
und über 499 Millionen Lizenzereignisse für 31 Softwareherstel-
ler erfasst.
Griffith arbeitet seit 25 Jahren bei Motorola und verfügt über
12 Jahre Erfahrung in der Verwaltung und Unterstützung elektro-
nischer Lizenzierung sowie in der Verhandlung von Softwareli-
zenzverträgen für Motorola. Vor der Gründung von CSAM im
Juni 1998 war Griffith für die Verwaltung der EDA-Softwareli-
zenzen und der UNIX-Rechenumgebung für die ASIC-Abteilung
bei Motorola verantwortlich. Außerdem arbeitete er von 1978
bis 1991 für die Government Electronic Group bei Motorola als
Testmanager.
Griffith studierte Elektrotechnik an der University of Toledo und
erwarb an der University of Phoenix einen Bachelor-Abschluss in
Betriebswirtschaftslehre. Er lebt in Scottsdale, Arizona.
Richard A. Kline (rkline@flexerasoftware.com)
Richard A. Kline ist strategischer Berater bei Global Consulting
Services, das zu Flexera Software gehört. Dort ist er dafür ver-
antwortlich, Softwarehersteller bei der Planung und Implementie-
rung ihrer elektronischen Lizenzierungsstrategien zu unterstützen.
Er verfügt über mehr als acht Jahre Erfahrung in der Entwicklung,
Implementierung und Wartung elektronischer Lizenzierungs- und
Softwarebereitstellungslösungen. Zuvor arbeitete er mit über
100 Softwareunternehmen zusammen, darunter Synopsys,
Symantec und Documentum.
Bevor er zu Flexera Software kam, war Kline bei Intraware tätig,
wo er für die Zusammenarbeit zwischen Intraware und Flexera
Software zuständig war. Während dieser Zeit entwickelte er
FLEXlm für SubscribeNet, die gehostete GTlicensing-Implementie-
rung von Intraware. Bevor Kline bei Intraware anfing, gründete
er BITSource Inc. (1999 von Intraware aufgekauft), wo er das
Konzept einer digital signierten Volumenlizenz auf den Weg
brachte. Hierbei können Softwareunternehmen die papierba-
sierte Lizenzierung beseitigen, die hohe Kosten verursacht und
zeitaufwendig ist. Kline hatte außerdem bei Synopsys und
Apple Positionen im Produktmanagement inne und arbeitete
an Produkten für die Softwareverteilung und die elektronische
Lizenzierung.
Kline erwarb an der Drexel University in Philadelphia, Pennsylva-
nia, einen Bachelor-Abschluss in Informatik.

8. Flexera Software, Inc.
1000 East Woodfield Road,
Suite 400
Schaumburg, IL 60173 USA
Schaumburg
(Unternehmenshauptsitz):
+1 800-809-5659
Großbritannien (Hauptsitz für
Europa, Naher Osten):
+44 870-871-1111
+44 870-873-6300
Japan (Hauptsitz für Asien und
die Pazifikregion):
+81 3-4360-8291
Weitere Standorte finden
Sie unter:
www.flexerasoftware.com
© 2010 Flexera Software, Inc. und/oder InstallShield Co. Inc. Alle anderen aufgeführten Marken- und Produktnamen können Marken und eingetragene Marken ihrer jeweiligen Eigentümer sein.
FNP_WP_Motorola_July10