24. Aug. 2016

Acht Mythen über Herstellerzertifizierungen

Auf dem SAM-Markt herrscht Verwirrung: Anlass ist das Thema „Herstellerzertifizierung“ von Lizenzmanagement-Tools. Was bedeutet es eigentlich, wenn ein Anbieter angibt, dass seine SAM-Plattform oder sein SAM-Tool „herstellerzertifiziert“ ist? Und welche Vorteile ergeben sich aus einer vermeintlichen „Zertifizierung“ für Sie, den Kunden, im Fall eines Audits

Zunächst ein paar Grundlagen

Grundsätzlich bedeutet die „Zertifizierung eines SAM-Tools“, dass der Softwarehersteller bestätigt, dass ein SAM-Tool korrekte Daten oder Ergebnisse erzeugt. Klingt gut, oder? Denn was gibt es Besseres, als bei Verhandlungen qualifizierte Daten auf den Tisch legen zu können, die ein Anbieter bereits als offiziell und präzise bestätigt hat?

Vielleicht überrascht es Sie zu hören, dass es Herstellerzertifizierungen für Lizenzmanagement-Tools in dieser Form jedoch nicht gibt. Aber das ist tatsächlich der Fall. Auch wenn einige Unternehmen von solchen Zertifizierungen berichten, sollten Sie das nicht als Kriterium bei der Auswahl des passenden SAM-Tools für Ihr Unternehmen berücksichtigen. Martin Thompson, Gründer von ITAM Review, schrieb kürzlich in einem Artikel: „Ich würde Herstellerzertifizierungen nicht als Differenzierungsmerkmal heranziehen, um zwischen verschiedenen Tools zu entscheiden.“

Im heutigen Blog wollen wir mit acht verbreiteten Mythen in diesem Zusammenhang aufzuräumen. Zur Erläuterung werden wir einige Fakten von den Webseiten von IBM und Oracle anführen.

Mythos 1: Es gibt Herstellerzertifizierungen für Lizenzmanagement-Tools.

Es gibt sie nicht – natürlich nicht. Wenn Sie kurz darüber nachdenken, ist das auch ganz offensichtlich. Warum sollte ein Softwarehersteller auf das Recht verzichten, ein Audit durchzuführen (und damit auf eine potenziell beträchtliche Einnahmequelle), nur weil der Kunde für ein Lizenzmanagement-Tool eines Drittanbieters bezahlt hat?

„Aber der Vertriebsmitarbeiter von Unternehmen XYZ hat mir gesagt, dass sein Unternehmen eine Zertifizierung von Oracle und IBM hat. Wollen Sie mir sagen, dass er lügt?“ Nun ja, zumindest dehnt er die Wahrheit ein wenig aus. Schauen wir einmal, was Oracle und IBM zum Thema sagen.

Mythos 2: IBM akzeptiert offiziell Drittanbieter-Tools als Ersatz für ILMT.

Getreu dem Motto „Reden ist Silber, Schweigen ist Gold“ findet man auf der IBM-Webseite keinerlei Informationen zu Richtlinien, Programmen, Zertifizierungen oder Verifizierungen für Tools. Tatsächlich hat IBM nie ein offizielles Statement abgegeben, das erlaubt, vom Grundsatz, ausschließlich IBM-eigene Tools für Sub-Capacity-Reporting zu verwenden - wie z. B. ILMT, TADd/TAD4D, IBM BigFix oder SUA – abzuweichen. 

Begegnen wir der Verwirrung mit weiteren Fakten. Selbst wenn der Hersteller eine solche Erklärung abgeben würde, besteht die einzige Möglichkeit des Kunden darin, direkt bei IBMs Rechts- oder Compliance-Team eine Verzichtserklärung oder Vertragsänderung anzufordern. Mit einer solchen Verzichtserklärung senken Sie aber Ihr Audit-Risiko nicht. Im Gegenteil: Ihr Audit-Risiko steigt erheblich, da eine solche Erklärung bedeutet, dass Sie ILMT ersetzen werden. Jetzt kann IBM sowohl für Ihre Daten UND für Ihr Tool ein Audit durchführen.

Selbst wenn IBM verschiedene Optionen für einen Partnerstatus und technische oder konzeptionelle Zertifizierungen anbietet, lässt sich nichts davon als Herstellerzertifizierung für SAM-Tools interpretieren. Bedauerlicherweise sind einige Marketingaussagen an dieser Stelle nicht differenziert genug, um zwischen den verschiedenen Optionen zu unterscheiden, sondern vermischen die Fakten. Wir empfehlen Ihnen, Technologie-Anbieter, die die Wahrheit allein für sich beanspruchen, kritisch zu betrachten – außer es geht um den Verkauf oder die Installation ihrer eigenen Produkte. 

Eine Ausnahmeregelung ist nur dann von Vorteil, wenn Sie bereits ein Drittanbieter-Tool implementiert haben und keinen weiteren Scan-Agenten für dieselben Daten verwenden wollen. Ein großes Problem bei ILMT besteht darin, dass der aktive Agent in einem Scanintervall von 30 Minuten auf jeder Maschine ausgeführt wird. Jedes Ersatz-Tool müsste genauso vorgehen – und die gleiche Leistung auf Ihre Geräte bringen. Die erzeugten Daten würden jedoch als Ergänzung für IBM-Audits und nicht als vollwertiger Ersatz verwendet. Was haben Sie also gewonnen?

Mythos 3: Tools von Drittanbietern gelten als Ausnahme. Warum? Weil die Anbieter entscheiden!

Erst kürzlich hat IBM offiziell erklärt, die Technologie eines bestimmten Anbieters bei individuellen Verhandlungen „nicht länger als Ersatz für ILMT zu akzeptieren“, die dieser intensiv als Ersatz-Tool für ILMT vermarktet.

Die Prüfer von IBM haben anfangs Ergebnisse von Drittanbieter-Technologie ignoriert, die unzureichende und unvollständige Daten liefert. Jetzt scheint IBM sich genau diese Vorgehensweise für die Verhandlungen mit Kunden, die ILMT ersetzen wollen, angeeignet zu haben.

Mythos 4: Alternative Technologien werden immer zur Selbst-Auditierung  akzeptiert.

Eine freiwillige License Review bietet zwar die Möglichkeit, eine alternative Technologie zu ILMT zu verwenden, es besteht jedoch keine Garantie, dass diese auch akzeptiert wird. Auch wenn bei Ihnen kein Audit unmittelbar bevorsteht, wäre es riskant, davon auszugehen, dass die Verwendung einer externen Technologie ungeprüft hingenommen wird. Der Einsatz einer solchen Technologie wird zwischen den Beteiligten verhandelt. Reviews mögen zunächst zwar einen „harmlosen“ Eindruck vermitteln, vergessen Sie aber bitte nicht, dass sie nichts anderes als „normale“ Audits sind, die lediglich vom Kunden initiiert wurden. Alle mit und von dem Anbieter oder seinem Partner gesammelten und ausgetauschten Informationen werden stets genutzt, um die korrekte Nutzung und Lizenzierung zu identifizieren. Wann immer also ein solches „harmloses Audit“ durchgeführt wird, ist zu beachten, dass die gleichen Regeln und Verfahren wie für ein normales Anbieter-Audit gelten.

Mythos 5: Ein verifiziertes Scanner-Tool bedeutet, dass Ihr SAM-Tool von Oracle zertifiziert ist.

Es ist ganz einfach: Oracle bietet keine pauschale Tool-Zertifizierung an.

Natürlich arbeitet Oracle mit einem Verifizierungsprozess für Scanner-Tools. Damit wird garantiert, dass das Tool dieselben Oracle-Nutzungsinformationen ausgibt, die ein Kunde auch durch die manuelle Ausführung eines Oracle Compliance Scripts erhalten würde. Und mit der Verifizierung wird darüber hinaus gewährleistet, dass die Scanning- Ergebnisse durch das Compliance-Team von Oracle anerkannt werden. Aber, und das ist entscheidend, es werden nur die Rohdaten anerkannt – keinerlei Ergebnis einer SAM-Lösung selbst.

Das ist also weit entfernt von einer Zertifizierung eines SAM-Tools oder von Oracle-Ergebnissen. ITAM Review hat den eingeschränkten Umfang des Oracle-Verifizierungsprozesses detailliert besprochen.

Anders als bei IBM erklärt Oracle auf seiner Website folgendes:

„Der Verifizierungsprozess umfasst nur die Datenerfassung bezogen auf die Installation und die Nutzung von bestimmten Oracle-Produkten, und zwar Oracle Database und damit verbundene Optionen. Die Verifizierung umfasst keine anderen Oracle-Produkte und bezieht sich auch nicht auf die Leistungsfähigkeit der Lösung eines SAM-Tool-Anbieters insgesamt. […]. Bitte beachten Sie, dass die Installation und Nutzung eines Tools von einem verifizierten Anbieter kein Oracle License Review oder Audit ersetzt oder das vertragliche Recht von Oracle zur Durchführung eines License Review oder Audit aufhebt.“

Worin liegt hier das Risiko? Oracles Sichtweise in Bezug auf Datenquellen ist sehr detailreich. Das sollten Sie immer bedenken. Anerkannt werden beispielsweise nur Enterprise Edition Datenbanken und dazugehörige Optionen – folglich sind mehr als 90 % der Oracle-Produkte nicht berücksichtigt. Und im Falle einer Schwäche der Daten aus gleich welchem Grund verbleibt letztlich die Verantwortung beim Kunden.

Mythos 6: Für ein verifiziertes Tool ist Datenqualität kein Thema. 

Ein Drittanbieter-Tool ist verifiziert, wenn dessen Ergebnisse zum Zeitpunkt der Überprüfung mit den Ergebnissen übereinstimmen, die auch von Oracle-Skripten produziert werden können oder wenn sie mehr Ergebnisse liefern. Leider ist dieses Vorgehen häufig Ursache für Fehlerquellen.  

Tatsächlich sind uns bei Aspera erst kürzlich solche „falschen positiven“ Ergebnisse bei von Oracle verifizierten Tools aufgefallen. Produkte wie Advanced Compression, Tuning Pack und Diagnostics Pack wurden als „im Einsatz“ dargestellt, obwohl das nicht der Fall war. Darüber hinaus wurden Standard Edition-Installationen nach einem Patch als Enterprise Editions angezeigt. Ein anderes Beispiel ist die Umsetzung von Aktualisierungen, die Oracle an seinen Skripten vornimmt und der Zeitpunkt, wann Hersteller diese umsetzen. Nachdem sie zunächst verifiziert wurden, „vergaßen“ einige Anbieter, ihre Oracle-Komponente zu pflegen und konnten folglich nicht mehr die genauen Ergebnisse für die aktuellen Oracle-Produktversionen erbringen.

Solche Phänomene kommen so häufig vor, dass Oracle die Häufigkeit und den Umfang seines Re-Verifizierungsprozesses zwischenzeitlich erhöhte.

Mythos 7: Ein verifiziertes Scanning-Tool ersetzt ein Oracle-Audit.

Die Verwendung eines verifizierten Tools ist niemals ein Ersatz für ein Oracle License Review oder Audit. Die Daten werden als Ergänzung für das Oracle License Management Services (LMS)-Review verwendet. Und so wird auch mit allen anderen Daten umgegangen, die Sie an Oracle weitergeben.

Bedeutsam im Zusammenhang mit Oracle LMS-Verifizierung ist sicher auch das Interview, das ITAM Review kürzlich mit internen Quellen geführt hat. Darin heißt es: „Das Thema LMS-Verifizierung liegt auf Eis und damit zurzeit etwa 50 Tools ebenfalls... und sollte nicht als Kriterium für Qualität berücksichtigt werden.“ Es kursieren diverse Gerüchte rund um das Thema, zum Beispiel auch, dass es ein „Oracle eigenes Scanning Tool“ niemals geben wird.

Mythos 8: Mit der Verifizierung sind Sie alle Sorgen los. 

Es ist wichtig zu wissen, dass die Verifizierung eines SAM-Tools keinen Einfluss auf Berechtigungen, Bewertungen oder Compliance hat. Bei jedem Verifizierungsansatz werden die Bestands- und Messdaten berücksichtigt, die technisch erfasst werden können. Beim Verweis auf eine Datenbank gibt das verifizierte Tool stets dieselben Daten wie die Skripte und Tools von Oracle aus. Das bedeutet, dass die Verantwortung für unvollständige Daten letztlich immer in Ihrer Organisation liegen wird.

Natürlich gibt es Hersteller-Zertifizierungen. Einige Anbieter von SAM-Tools haben Zertifikate in technischer Oracle-Entwicklung oder -Verwaltung beantragt. Diese Zertifikate erlauben es Plattformen, Oracle-Software für ihre Produkte und ihre Architektur zu verwenden, zeigen einen Trainingsstand und andere Aspekte auf.

Selbstverständlich handelt es sich dabei um eine komplett andere Art von „Herstellerzertifizierung“, die keinen Einfluss auf die SAM-Funktionen oder die Anerkennung solcher Ergebnisse hat. Einige Drittanbieter kombinieren ihre Zertifizierungsaussagen jedoch derzeit sehr kreativ in SAM-Marketingtexten, sodass die Aussagen für neue Kunden von höherer Relevanz erscheinen als sie es tatsächlich sind. Derartigen Versprechen gegenüber sollten sie Vorsicht walten lassen, denn die Realität ist meist komplexer als mancher Werbeslogan.

Warum sprechen wir gerade jetzt über das Thema?

Warum wird so viel für diese „Phantomzertifikate“ geworben? Und wie sollten Sie bei der Wahl einer SAM-Lösung am besten vorgehen, wenn es eine Herstellerzertifizierung gar nicht gibt?

Der Hype: Eine „Herstellerzertifizierung“ wird in der Regel dann stark beworben, wenn eine Drittanbieterplattform über Technologie schlecht hervorgehoben werden kann. Möglicherweise bestehen keine ausreichenden Verbindungen zu dem bevorzugten Scanner-Tool des Kunden oder dem vorgeschriebenen Tool eines Herstellers. Die SAM-Plattform empfiehlt also ihre eigene Analyse, um die möglicherweise ineffektive Datensammlung auszugleichen.

Effektive SAM-Lösungen basieren auf Vertrauen, Zuverlässigkeit und Ergebnissen. Wenn die Grundlage der ursprünglichen Verkaufstaktik zu bröckeln beginnt, lassen weitere Plattformdefizite nicht mehr lange auf sich warten.

Die Lösung: Wenn Sie bereits eine SAM-Plattform gekauft haben, die ihre Kaufversprechen nicht erfüllt, werfen Sie einen Blick in Ihren Vertrag. Dort sollten Sie einen Paragrafen finden, laut dem Sie zum Rücktritt vom Vertrag berechtigt sind, wenn einige – oder alle – definierten Funktionen nicht gegeben sind.

Wenn Sie nicht vom Vertrag zurücktreten können, wenden Sie sich am besten an einen erfahrenen SAM-Berater. Mit der Hilfe eines Experten kann Ihre Organisation ihre technischen und konzeptionellen Optionen definieren, zu denen auch der Austausch der Technologie zählen kann. Prozess-, Technologie- und Datenqualität ist immer der Schlüssel zu Ihrem Erfolg.

Die Strategie: Unser wichtigster Tipp zum Schluss: Es ist entscheidend für Ihr Unternehmen, einen Technical Proof of Concept (POC) durchzuführen, um die Behauptungen des Tools zu überprüfen, bevor Sie es kaufen.

Wenn Sie eine nicht optimale Technologie kaufen und implementieren, wird es für Sie teuer. Ihr Unternehmen kann viel Zeit verlieren – wenn Audits nicht richtig durchgeführt werden – und es kann sogar zu Strafzahlungen führen. Seien Sie vorsichtig, wenn Ihnen die Werbung verspricht, eine schnelle Lösung für Ihre Herausforderungen zu bieten. Wie alle wichtigen Dinge des Lebens braucht auch SAM Zeit.

Wir bei Aspera konnten uns schon oft davon überzeugen, dass es ein sehr teurer Fehler werden kann, wenn Unternehmen eine Technologie kaufen und implementieren, die nicht die gewünschten Ergebnisse liefert. Anschließend haben wir die Unternehmen dabei unterstützt, den Fehler wieder rückgängig zu machen.

Wir wissen, dass Vertrauen die stabile Grundlage für ein erfolgreiches SAM bildet. Die Beziehung zu unseren Kunden endet nicht mit der Vertragsunterzeichnung oder der Implementierung eines Tools. Unser erfahrenes Team gibt sein Wissen gerne an Sie weiter, was solche Tools leisten können und was nicht.



Themen: Oracle, IBM, SAM Insights




Kommentare (0):

Es gibt noch keine Kommentare.