Spreker
Mike Neuenschwander
General Manager
Mycroft
Mike Neuenschwander en Nick Nichols hebben rond 1999 het Novell DirXML product, de voorloper op de huidige identity manager, van concept tot implementatie ontwikkeld. Mike was destijds product manager, Nick engineer. Ze zijn later beide naar Burton gegaan en Nick is sinds eind 2006 weer terug bij Novell als product manager voor identity manager.
Samenvatting
Deze sessie voorziet partners en overige partijen van praktijk informatie over de benadering van IDM projecten.
Analyse
Volgens onderzoek dat Mike bij Burton heeft verricht, blijkt dat organisaties gemiddeld 3 keer hun IDM project herzien of opnieuw starten. De meest voorkomende problemen zijn:
- aanname dat IDM een plug-and-play product is, zoals een email systeem
- gebrekkige communicatie met business
IDM wordt voor een technisch doel ingezet, bijvoorbeeld synchronisatie. Later groeit de implementatie, waardoor er impact ontstaat op diverse bedrijfsprocessen, zoals HR of helpdesk. Deze worden niet goed gecommuniceerd met de business, omdat het project vanuit de techniek groeit. De business accepteert de nieuwe werkwijze niet, of er bestaan veel te hoge verwachtingen. Het IDM project is vervolgens gedoemd te mislukken.
- gebrekkige governance structuur in de organisatie
Invoering van IDM in een organisatie is een meer jaren traject wat op veel processen invloed heeft. Als de processen in de organisatie zelf onduidelijk en niet gedocumenteerd zijn, ontbreekt de vaste fundering voor IDM.
Mike geeft in globale termen een mogelijke aanpak. Begin met het vastleggen van de huidige processen. Analyseer de procesinrichting en mogelijke risico's. Wat moet de organisatie veranderen aan de processen om IDM te kunnen invoeren, rekening houdend met de business drivers van de projectsponsor. In feite een stukje governance.
Vervolgens processen stuk voor stuk automatiseren met IDM. Het uitgangspunt moet dus niet het IDM systeem zijn, wat zeer veel functionaliteit heeft dat tegelijk ingrijpt op diverse processen. Als dit het uitgangspunt is, wordt er te adhoc op allerlei processen invloed uitgeoefend.
Een aantal van mijn vragen heeft Mike in de sessie naar mijn idee niet concreet genoeg beantwoord. Het gaat om het volgende.
In principe wordt er een analyse gedaan van de huidige staat van bedrijfsprocessen. Vervolgens wordt op gezond verstand van de analist vertrouwd om de gewenste staat van de bedrijfsprocessen te beschrijven. Maar is het niet veel beter een meetbare en repeteerbare methode te hanteren, waarbij een GAP analyse kan worden gemaakt tussen de huidige staat en de gewenste staat van bepaalde bedrijfsprocessen? Een organisatie kan dan gericht gaan sturen en rapporteren over de inrichting van de governance structuur.
Al met al blijkt het zwaartepunt van IDM niet bij de techniek te liggen. Deze week hoop ik samen met Mike en Nick hier nog eens van gedachten over te wisselen.
17.3.08
Discussion: Software Asset Management Best Practices
Samenvatting
Deze sessie geeft praktijk oplossingen en bespreekt software asset management in relatie tot de industrie standaarden als ISO 19770-1 en ITIL. Helaas gingen de vragen uit de zaal vooral over de details van de Novell tool, waardoor het proces bijna niet aan bod is gekomen en de industrie standaarden helemaal niet. Toch is er vanuit COBIT en ISO 27002 een interessante link te leggen tussen asset management en informatiebeveiliging, waar de tool nog niet in voorziet...
Spreker
Christina Chamberlain
Technology Sales Specialist
Novell, Inc.
Analyse
Onafhankelijk van de tool, kan het gehele proces software asset management worden samengevat in de volgende deel activiteiten:
aankopen van software
Het verzamelen van alle aankoop gegevens. Uit deze gegevens wordt afgeleid welke software er 'zou moeten' bestaan in de organisatie. Indien het aankopen van software decentraal is georganiseerd, kan het nog wel eens lastig zijn de juiste informatie te krijgen van alle departementen. Ook de verschillende formaten en interpretatie van de aankoopgegevens veroorzaken problemen.
software inventarisatie
Het handmatig of geautomatiseerd inventariseren van geïnstalleerde software op alle hardware systemen. Deze gegevens geven weer welke software er daadwerkelijk geïnstalleerd is.
licentie beheer
Licenties zijn de koppeling tussen aankopen en daadwerkelijke installaties. Uit een aankoop blijkt een bepaalde licentie, die zeer diverse vormen kan aannemen. (per installatie, CPU, gebruiker, enz.) Aan deze licentie zijn de daadwerkelijke installaties te koppelen, waardoor uiteindelijk blijkt welke software zonder toestemming of zelfs illegaal wordt gebruikt.
Ook het intrekken en opnieuw uitdelen van licenties valt hieronder.
aanleveren van software
Het installeren en toegankelijk maken van de software voor de eindgebruiker.
toewijzen/kosten verrekening
Een IT organisatie berekent (intern of extern) de kosten door aan de afnemende organisatie. Kosten bestaan uit software licenties, maar ook begrote kosten voor de helpdesk of technische werkzaamheden.
Kijkend naar de processen uit Cobit en de controls uit ISO/IEC 27002, zijn processen als patch management en configuratie management sterk gerelateerd of zelfs afhankelijk van software asset management. Configuraties behoren bij software assets, dezelfde assets kunnen ook beveiligingslekken bevatten waarvoor patches worden uitgebracht. Het beheer van software assets houd dus veel meer in dan alleen licenties bijhouden. Bijvoorbeeld: wie is systeem eigenaar? Wie is verantwoordelijk voor de veiligheid van de software? Wie controleert of de aankopen van software pakketten voldoen aan de security requirements die door de organisatie gesteld zijn? Deze zaken zijn niet triviaal te ondersteunen met de tools en bijbehorende documentatie. Vaak zijn dit losse producten die delen van de processen ondersteunen. Technisch zal het vast wel aan elkaar te koppelen zijn, wat nog niet betekent dat een organisatie het goed weet in te bedden in alle processen.
Links
www.iaitam.org - International Association of Information Technology Asset Managers
Deze sessie geeft praktijk oplossingen en bespreekt software asset management in relatie tot de industrie standaarden als ISO 19770-1 en ITIL. Helaas gingen de vragen uit de zaal vooral over de details van de Novell tool, waardoor het proces bijna niet aan bod is gekomen en de industrie standaarden helemaal niet. Toch is er vanuit COBIT en ISO 27002 een interessante link te leggen tussen asset management en informatiebeveiliging, waar de tool nog niet in voorziet...
Spreker
Christina Chamberlain
Technology Sales Specialist
Novell, Inc.
Analyse
Onafhankelijk van de tool, kan het gehele proces software asset management worden samengevat in de volgende deel activiteiten:
aankopen van software
Het verzamelen van alle aankoop gegevens. Uit deze gegevens wordt afgeleid welke software er 'zou moeten' bestaan in de organisatie. Indien het aankopen van software decentraal is georganiseerd, kan het nog wel eens lastig zijn de juiste informatie te krijgen van alle departementen. Ook de verschillende formaten en interpretatie van de aankoopgegevens veroorzaken problemen.
software inventarisatie
Het handmatig of geautomatiseerd inventariseren van geïnstalleerde software op alle hardware systemen. Deze gegevens geven weer welke software er daadwerkelijk geïnstalleerd is.
licentie beheer
Licenties zijn de koppeling tussen aankopen en daadwerkelijke installaties. Uit een aankoop blijkt een bepaalde licentie, die zeer diverse vormen kan aannemen. (per installatie, CPU, gebruiker, enz.) Aan deze licentie zijn de daadwerkelijke installaties te koppelen, waardoor uiteindelijk blijkt welke software zonder toestemming of zelfs illegaal wordt gebruikt.
Ook het intrekken en opnieuw uitdelen van licenties valt hieronder.
aanleveren van software
Het installeren en toegankelijk maken van de software voor de eindgebruiker.
toewijzen/kosten verrekening
Een IT organisatie berekent (intern of extern) de kosten door aan de afnemende organisatie. Kosten bestaan uit software licenties, maar ook begrote kosten voor de helpdesk of technische werkzaamheden.
Kijkend naar de processen uit Cobit en de controls uit ISO/IEC 27002, zijn processen als patch management en configuratie management sterk gerelateerd of zelfs afhankelijk van software asset management. Configuraties behoren bij software assets, dezelfde assets kunnen ook beveiligingslekken bevatten waarvoor patches worden uitgebracht. Het beheer van software assets houd dus veel meer in dan alleen licenties bijhouden. Bijvoorbeeld: wie is systeem eigenaar? Wie is verantwoordelijk voor de veiligheid van de software? Wie controleert of de aankopen van software pakketten voldoen aan de security requirements die door de organisatie gesteld zijn? Deze zaken zijn niet triviaal te ondersteunen met de tools en bijbehorende documentatie. Vaak zijn dit losse producten die delen van de processen ondersteunen. Technisch zal het vast wel aan elkaar te koppelen zijn, wat nog niet betekent dat een organisatie het goed weet in te bedden in alle processen.
Links
www.iaitam.org - International Association of Information Technology Asset Managers
Abonneren op:
Posts (Atom)