“ISO/IEC 19770-2:2009 Software identification tag” als Internationaler Standard formal bestätigt. (22.10.2009)

Dave Bicket Convenor der WG21 hat am 22.10.2009 die Ergebnisse der letzten Abstimmung (JTC1-level) für ISO/IEC 19770-2 verschickt. Damit ist die letzte Hürde für das Software Tagging genommen und wir können bis zum Ende des Jahres die formale Veröffentlichung erwarten.

Hier die Nachricht von David Bicket:

I have just received the results of the final (JTC1-level) vote on ISO/IEC 19770-2. It has been approved as indicated in this summary:

Result of voting

P-Members voting: 23 in favour out of 23 = 100 % (requirement >= 66.66%)

(P-Members having abstained are not counted in this vote.)

Member bodies voting: 0 negative votes out of 25 = 0 % (requirement <= 25%)

Approved

Two small editorial comments were submitted.

Congratulations are due to everyone who has worked so hard on making this happen. I will not give names for now; but we will try to recognize contributors later.

Formal publication will depend on ISO’s editorial and production team. We expect to have it formally published by the end of the year, so that the formal designation of the standard will be “ISO/IEC 19770-2:2009 Software identification tag”.

Now to make it one of the most successful standards in the IT industry!

Best regards,

Dave Bicket
Convener WG21

Microsoft Software Asset Management Homepage

Nach einigen Wochen urlaubs- und projektbedingter Pause möchte ich mich mal wieder zurückmelden und die Serie interessante Informationsquellen, mit einem Blick auf die Microsoft Homepage zum Thema SAM, fortsetzen.

Die Seite gibt einen High Level Überblick über Nutzen, Vorgehensweise, aber auch Links zu SAM Tools und Berater.

Speziell auf der Nutzenseite ist mir die Potentialanalyse ins Auge gefallen. Motto: Finden Sie in nur fünf Minuten heraus, welchen Return on Investment (ROI) Sie durch SAM erzielen können.

Ob das Tool tatsächlich den ROI berechnen kann, lassen wir mal im Raum stehen. Sehr spannend finde ich aber die Fragen und die darauf basierenden Vorschäge für eine optimale Implementierung eines SAM Programmes.

Das ist sehr gut gemacht und Wert sich das einmal anzuschauen.

Hier der Link zum SAM Home

1x1 des Lizenzmanagements ab sofort verfügbar

1x1 des Lizenzmanagements
Praxisleitfaden für Lizenzmanager

Details siehe www.1mal1lima.de

Wie wird man eigentlich "Nicht-Compliant"

Viele Wege führen in die "Nicht-Compliance" hier eine Auswahl mit Vermeidungsstrategien:

• IT Support Techniker installieren Software ohne zu prüfen ob auch ausreichend Lizenzen vorhanden sind.
  Das geht dann so: Ein Kollege möchte eine bestimmten Software und der IT Techniker installiert / downloaded / sendet das Setup, ohne zu prüfen ob die Lizenz vorhanden ist (im Pool, Enterprise Agreement, ...) oder beschafft/gekauft werden muss.
  Ohne Richtlinien unterstützt durch standardisierte Prozesse und Tools die es den IT Technikern erlauben den Job schnell zu erledigen und mit zugehörigen und aktuellen Informationen über die Lizenzsituation zu versorgen wird es schwierig dieses Verhalten zu vermeiden. Eine Toolgestützte soweit möglich automatische Dokumentation des Prozesses und der Buchungen (Lizenzzuordnungen, Pool-Administration) ist hier sehr hilfreich.

• Software die zwar nicht in der Produktiv Umgebung sondern nur im Test/Entwicklung/Evaluation Labor installiert ist.
  egal in welcher Umgebung Software installiert ist und egal ob sie aktiv verwendet wird oder nicht die Lizenzbedingungen treten in Kraft. Oft müssen auch spezielle Lizenzbedingungen für Entwicklungs-/Testumgebungen beachtet werden. Zu diesem Thema gehört auch der nächste Punkt.
  
  
• Vergessene Test-/Evaluierungsinstallationen
  Wie oft wird Software zu Evaluierungszwecken installiert und es leider vergessen sie, nach dem Test und der Evaluierungsphase, wieder zu löschen. Manchmal ist die SW auch für eine bestimmte Zeit kostenlos und muss nach Ablauf der Zeit bezahlt werden.
  Diese beiden Fälle können mit (i.e. agentless) Inventorytools, die am Besten noch die tatsächliche Verwendung ("Software Usage") messen, eingefangen werden, im Idealfall sind auch die Evaluierung an sich, im Rahmen der Beschaffungs-/Change- Prozesse, dokumentiert und diese Informationen für den Compliance Check verfügbar/auswertbar.
  
  
• Eine Anwendung wird von einem User auf verschiedenen Geräten verwendet
  Viele Wissensarbeiter heutiger Generation verwenden die gleich Anwendung auf verschiedenen Systemen wie: Desktop im Büro, Laptop auf Reisen, dem neuen Handy und zu Hause auf dem privaten Rechner. Hier gilt es die Lizenzbedingungen zu beachten. Oft können bei "Device" basierten Lizenzen die Anwendung nur auf einem Gerät instaliert werden und es wird für alle anderen eine eigene Lizenz fällig. Andere Lizenzbedingen erlauben ein Zweitinstallationsrecht oder sind User basiert und eine mehrfache Installation ist dann möglich. Hier gilt es sehr genau die Lizenzbedingungen zu studieren und bei der Nutzung zu beachten.
  Neben den Lizenzbedingungen sind speziell die "Home User" eine interessante Herausforderung für den Lizenzmanager und führt uns zum nächsten Punkt.
  
  
• Firmen Software wird auf privaten System installiert
  In letzter Zeit kommt es in der Regel aus Kostengründen immer mehr in Mode, dass Firmen Software auch auf privaten Geräten installiert wird um den Mitarbeitern zu ermöglichen auch an Wochenenden oder im Home Office zu arbeiten. Im Prinzip eine gute Idee aber ein Alptraum für den Lizenzmanager. Er muss, neben den zu beachtenden Lizenzbedingungen, mit weniger Kontrolle auskommen. In der Regel ist auf privaten Rechnern kein Inventory oder gar Software Usage möglich. Und er muss auch dafür sorgen, dass wenn der Kollege aus dem Unternehmen ausscheidet oder den Aufgabenbereich wechselt, die Anwendung auch wieder de-installiert wird.
  D.h. er muss dafür sorgen, dass die Nutzung von Software außerhalb des Unternehmens akkurat dokumentiert wird. Und dass es Richtlinien und Prozesse gibt die eine "Nichtnutzung" über den erlaubten Zeitrahmen hinaus sicherstellen. Hier helfen entsprechende SW Standards und toolgestützte Requestverfahren, die die Dokumentation möglichst automatisch übernehmen.
  
  
• Virtualisierung
  Eine virtuelle Maschine ist in sekundenschnelle erstellt und auch wieder gelöscht. Es werden hier zu Testzwecken ein paar Server zur Verfügung gestellt/kopiert und dort müssen Lastspitzen ausgeglichen werden. Je mehr die Virtualisierungswelle ins Rollen kommt, umso einfacher einzelnen Betriebssystem, Anwendungen, Server usw. virtualisiert werden können. Umso schwieriger wird es die Kontrolle aus dem Lizenzierungsaspekt zu behalten. Es wird immer wichtiger und immer schwieriger zu ermitteln, wie viele Instanzen, Kopien, Installationen einer Software aktiv in Verwendung sind bzw. zu einem bestimmten Zeitpunkt waren und auch welche Auswirkung die Lizenzbedingungen darauf haben. Ohne dieses Verständnis wird es unmöglich die "Compliance" zu bestimmen und nicht nur eine Scheinsicherheit zu erhalten (das nächste Audit kommt bestimmt). Inventory und Server Konfigurationstools können hier die Messquellen liefern, aber die Lizenzbedingungen müssen Sie selbst lesen und verstehen.
  
  
• Geänderte Lizenzbedingungen
  Änderungen in den Lizenzbedingungen durch die Softwareanbieter können vorteilhaft sein aber sehr oft sind sie für die Kunden von Nachteil. Um entsprechend reagieren zu können sollten diese Änderungen so früh wie möglich untersucht und die möglichen Auswirkungen auf Kosten, Prozesse und Policies analysiert werden.
  

Kennen Sie weiter Fallen? Ich würde mich freuen, wenn wir uns austauschen würden.

Literatur für SAM und Lizenzmanagement

Immer wieder werde ich gefragt ob es vernünftige Bettlektüre zu SAM gibt. Und leider gibt es speziell im deutschsprachigen Raum noch keine Bücher.
Deshalb kommt meine derzeitige Empfehlung und eigentlich auch meine Referenz aus den USA von IBSMA (International Business Software Managers Association):

Software License Management | Study Guide

Leider nur in Englisch aber trotzdem gut lesbar und, da in Form eines Study Guides, mit Testfragen und Wiederholungen. Folgende Themen werden besprochen:
1. Auditing und Compliance Basics
2. Licencing Overview
3. Assessing your SAM Proficiency
4. Tools and Technology
5. Making the Business Case
6. External Audits
7. Self Audit


Neben vielen weiteren Informationen findet sich bei der IBSMA ein Online Glossary zum Licence Management. Sehr gute Referenz und Begriffsdefintionen.

Glossary of Software License and IT Asset Management Terms - Oct. '08


Leider noch nicht verfügbar (ab ca. Ende August) aber sehr vielversprechend:

Torsten Groll
1x1 des Lizenzmanagements
Praxisleitfaden für Lizenzmanager

Details siehe www.1mal1lima.de

Das Buch gibt einen Überblick über das Lizenzmanagement, erklärt die dazugehörigen Fachbegriffe und zeigt, wie Sie es in Ihrem Unternehmen erfolgreich einführen, betreiben und optimieren. Sie erfahren, wie Sie Ihre Unternehmenssoftware und Lizenzen so verwalten, dass Transparenz und Rechtssicherheit hergestellt werden kann.

Da ich Torsten Groll bereits in verschiedenen Projekten erlebt habe, bin ich überzeugt, dass hier ein Buch aus der Praxis für die Praxis geschrieben wurde.


Was sind Ihre Lieblingsbücher und auch Web-Seiten zum Thema. Über eine Liste würde ich mich freuen.

Sind Erkenntnisse aus der Softwareentwicklung auch für SAM gültig?

passend zu den Risiken in Lizenzmanagement Projekten habe ich heute von einem Partner folgende Erkenntnisse aus der Softwareentwicklung bekommen:

Ziv's Unsicherheitsprinzip des Software-Entwicklungsprozess
Engineering: „Unsicherheit ist im Software-Entwicklungsprozess und den Produkten inhärent und unvermeidlich.“ (Ziv, 1996)

Wegner's Lemma:
„Es ist unmöglich, ein interaktives System komplett zu spezifizieren.“ (Wegner, 1995)

Humphrey's Prinzip der Anforderungsunsicherheit:
„In einem neuen Software System werden die Anforderungen solange nicht komplett bekannt sein, bis die Anwender damit arbeiten.“ (Humphrey, 1995)

Ich musste sofort schmunzeln, da ich insbesondere "Humphrey's Prinzip der Anforderungsunsicherheit" in Lizenzmanagement Projekten immer wieder erlebe. Erst wenn die ersten echten Anwender mit der Lösung arbeiten, werden alle Anforderungen bekannt.

Deshalb "alle" Anwender und Stakeholder so früh wie möglich in die Projekte und Konzeptionen einbinden und auch Zwischenergebnisse so früh wie möglich mit den Anwender diskutieren.

OEM Modell für Softwarelizenzierung?

OEM Modell für Softwarelizenzierung

Das Ludwigsburger Unternehmen Listec propagiert in Sachen Softwarelizenzierung ein OEM-Modell (Original Equipment Manufacturer). Listec ist OEM-Distributor für IBM-Software. Mit dem OEM-Modell könnten die Unternehmen der Probleme mit der Softwarelizenzierung Herr werden, hieß es.
Diese Meldung habe ich bei Silicon.de gefunden (siehe Link). Ich bin dazu erst einmal skeptisch. Zum einen glaube ich nicht dass die Hersteller generell für dieses Modell offen sind und zum anderen bin ich nicht überzeugt, dass der Kunde deshalb weniger Lizenzmanagement benötigt. Das Problem wird nur verlagert und im Endeffekt wird es zwei Audits geben und zwar vom Hersteller und vom OEM-Distributor.

Woran scheitern SAM und Lizenzmanagement Projekte?

Ende dieser Woche haben wir im Rahmen einer Ausschreibung eine interessante Frage bekommen:
Woran scheitern Ihrer Erfahrung nach solche Projekte am häufigsten und wie kann sichergestellt werden, dass diese „Pitfalls“ umgangen werden?

Hier die Themen und Abhilfen die uns spontan eingefallen sind:

• Mangelndes Commitment
  Abhilfe: „echten“ Projektsponsor finden
• Fehlendes oder unzureichendes Lastenheft/Pflichtenheft
  Abhilfe: Grobkonzept gemeinsam erarbeiten, Schätzungen auf Grobkonzept basieren
• Scope und Budget passen nicht zusammen
  Abhilfe: mit gegebenem Budget Scope optimieren oder gegebenen Scope hinsichtlich Budget optimieren
• IT Architektur zu wenig Bedeutung beigemessen
  Abhilfe: Architekturskizze erstellen, Einbettung in Unternehmensarchitektur beachten
• Schlechte Projektvorbereitung und -planung
  Abhilfe: Zeit und Budget einplanen
• Keine gute PM Methodik / Vorgehensmodelle
  Abhilfe: USU arbeitet nach dem international anerkannten IPMA-Standard und verfügt über ein bewährtes Vorgehensmodell zur Einführung von Valuemation
• Unklare Rollenverteilung
  Abhilfe: Rollendefinition (z.b. RACI Modell) zu Projektbeginn festlegen und Einhaltung kontrollieren
• Mangelnde Ressourcenverfügbarkeit
  Abhilfe: frühzeitige Planung, interne Ressourcen konsequent freistellen
• Überforderte Projektleiter
  Abhilfe: intern: Ausbildung/Zertifizierung, extern: vor Projektstart kennenlernen
• Termindruck
  Abhilfe: realistische Planung auf Faktenbasis, keine unhinterfragte Abbildung von „Wunschterminen“
• Zu optimistische Annahmen
  Abhilfe: „Verprobung“ der Pläne, Reviews
• Mangelhafte Kommunikation
  Abhilfe: Kommunikationswege und –regeln zu Projektbeginn festlegen, Team-Building-Events
• Mangelhaftes Projektcontrolling
  Abhilfe: regelmäßige Projektstatusberichte (Fortschritt, Restaufwand, Risiken etc.)

Diese Liste stellt keinen Anspruch auf Vollständigkeit. Wie sind Ihre Erfahrungen? Was fehlt? Was ist noch wichtig?