What do ITSM and SAM have to offer each other?

Many of us working in the IT sphere have heard about ITSM and the ITIL Framework that puts best practise into wording. There are plenty of other frameworks and manifestos that also claim their piece to describe the same and other parts of IT’s reality. In this wealth of solutions and beliefs, I do miss a more wide spread discussion on one, in my view critical, part of IT.

The part that for most organisations stands for the same amount of money as personnel, i.e. their software expenditure. For most industries it stands for 30% of their IT budget and with an ongoing digitalisation and service-orientation, this has been and will be increasing. So in my view how to manage this part of IT effectively and efficiently deserves a spot among the books on DevOps, Agile, etc.

Because whether it’s a traditional purchased client-application, a hired server-license or some cloud solution, the way we need to manage these assets is still the same. The legal, financial, architectural and operational implications are as demanding and IT needs to deliver their part in a cost efficient and value-adding manner.

I am by far an IT Asset or License expert, but I do know that doing the right things in the right way benefits the business and bottom line. And this requires working with people, processes and tools, managing change. I had the opportunity to work with Software Asset Management issues for the first time some 6 years ago. Having worked a few years with ITSM and with some background in ISO9001 and CRM, our newly appointed License Manager and I embarked on a journey with the appropriate ISO Standard in our bags. As we proceeded a number of things became apparent to us:

-        An organisation can only take in a certain amount of new terminology and adapt to new ways of working. Managing organisational change for SAM is as critical as for ITSM. SAM affects all users in an organisation! Be considered.

-        Clear governance, stipulating policies, objectives, roles, responsibility and mandates is critical

-        A number of processes defined by the ISO 19770-1 are in principle the same as what ITIL describes. It would be a waste of time and resources not to make sure to incorporate SAM requirements into the existing ITSM processes.

-        In particular working with (Software) Asset identification and control, shows how determined one has to be if/when embarking on Configuration Management with probably an even larger scope.

-        Another area of SAM that plays a forefront role is Supplier and Contract Management. Handle it well and it will serve you well

-        At that time acquiring knowledge and sharing experience on SAM seemed, compared to the ITSM/ITIL community, almost non-existing or only available through software vendors.

-        Then also tools for inventory, metering, etc. to help SAM were in an early stage of the hype cycle. Good enough to support specific tasks for License Management, but not management tools that can streamline workflows and decision making.

Due to organisational changes we both engaged in other challenges, but while years passed these thoughts remained in the back of my mind. The last 2 years as an ITSM consultant I have had the opportunity to meet with many more organisations and it is clear that many still struggle (more or less conscious) with ITSM and SAM duties and initiatives not being synced.

While SAM overall was clearly less mature 6 years ago, it has gained traction. Then the methods and concepts to extend the ISO standard came primarily from the vendor side like Microsoft’s MOF. Now there is a recognised independent framework from IAITAM and the tools to support it have improved considerably. At the same time more and more the broader term ITAM is being used instead of SAM, including all IT-related Assets, like hardware, in the approach. And for what it’s worth it, ITIL has clearly sated SAM/ITAM is a critical element of successful IT Service Management.

While ITIL/ITSM, with all right, talks a lot about the importance of organisational capabilities, SAM has a much stronger case for why these should be up to specs: incompliance has tangible legal and direct financial consequences. So while audits (external or internal) can be regarded by some as a blessing to tidy things up once every now and then, the more mature License and Software Asset Managers whish for a more continuous management and continual improvement: to build and manage organisational capability. Within logistics no one closes down a distribution centre to do a yearly inventory. Stock taking is performed daily and integrated with other logistic duties.

The need for management of change becomes evident. Nothing major, rather an evolution that actually also can enrich the ITSM practises of an organisation and help to quantify benefits in monetary terms and risk management, something the CFO will like.

It means taking advance of existing implementation and process capabilities by involving for example your Service Level Manager(s) and Change Manager(s) in the adoption of existing processes to specific requirements from SAM. And be aware the benefits are in either direction: While adding SAM-oriented Change Models will help to make the “ITSM-based” Change Management more complete, data from Incidents and Service Requests will give an extra dimension to Asset data, when meeting suppliers during renegotiations.

This does indicate a certain maturity of the IT organisation, to be able to take advantage of the ITSM capabilities for SAM. But any CIO with a long term vision and strategy to contribute to the bottom line should include the opportunity given by matching these 2 practices once passed the phase of establishment.

//Maarten Merckx
Verksamhetskonsult på Olingo Consulting och ITIL utbildare hos Informator

Vill du lära dig mer om SAM kopplat till ITIL? Då är kursen  ITIL Lifecycle -Service Transition ett steg i rätt riktning. Klicka här för att se hela Informators utbud inom ITIL och ITSM.

Läs mer

ITIL och agila metoder - Motsatser eller komplement?

I mitt förra inlägg skrev jag om ITIL och förhållandet till ramverk i allmänhet. Nu går vi in på förhållandet till specifika ramverk och vi startar med agila metoder.

Agila metoder har vunnit mark på senare år och det av bra skäl - kortare cykler, snabb anpassning till ändrade behov, bättre nyttjande av kompetens och säkert fler ändå. Tyvärr ser många en konflikt mellan detta och de "rigida" och "oflexibla" ITIL-processerna. Ofta, om inte oftast, är detta en helt onödig konflikt och ett pseudoargument mot ITIL och IT service management i största allmänhet.

För att sätta förväntningarna så definierar jag agila metoder enligt följande: 
Lättrörliga programvaruutvecklingsmetoder som används för programvaruutveckling där fokus ligger på nära samarbete mellan utvecklare och experter på affärens behov och processer. Detta kännetecknas av korta cykler, täta möten mellan beställare och utvecklare med uppföljning och justering, inkrementellt och iterativt arbetssätt och förlitande på människor, relationer och kommunikation mer än process och dokumentation. Se det agila manifestet: http://www.agilealliance.org/the-alliance/the-agile-manifesto/

Jag påstår att missuppfattningen till mycket stor del bygger på det faktum att tillämpningen av ITILs ramverk och utformningen av processerna upplevs som tungrodd. Det är förmodligen helt sant. Men det behöver inte vara så. Tvärtom. Dessa två vinklar in på delvis olika, delvis samma sanning kan samverka och skapa oanade synergier. Låt oss kika på en del områden där det kan uppstå konflikter.

• Change management är ITIL-processen för beslut och kontroll.
• Agil metodik bygger på ständiga små inkrementella beslut.
• Konflikt? Inte nödvändigtvis.

Att fatta beslut om riktlinjer för Change management att hålla sig inom är ett kännetecken för mogna organisationer. Det är mekanismen för högre chefer att ta strategiska beslut att genomsyra de taktiska och operativa besluten.

Exempel: Om strategin är att nå ut snabbt med nya tjänster och kvaliteten inte står i fokus så är det OK med en Change-hantering som inte trycker hårt på testning, kvalitetssäkring och genomarbetade business case. Google är ett företag som har anammat den change-strategin. Det var också en nyckelfaktor för hur www.aftonbladet.se blev den mest framgångsrika nyhetssajten i Sverige redan på 90-talet. Det var ofta nytt utseende på hemsidan och nya sätt att hantera och sortera information. Inte många kommer ihåg att det ofta var störningar och avbrott i tjänsten.

Det finns ingen motsättning till denna strategi i ITIL-processen Change Management. Tvärtom, ITIL trycker hårt på vikten av att anpassa varje enskild (ITIL)-process efter organisationens specifika behov och strategier.

• Release and Deployment management är ITILs process för att med en helhetssyn säkerställa att grupper av godkända ändringar byggs, testas, rullas ut och verifieras på ett säkert, repeterbart och spårbart sätt.
• Inom agila metoder är det inbyggt med inkrementella utrullningar av den programvara som produceras.
• Motsägelsefullt? Inte alls!

De flesta förstår det mycket kraftfulla argumentet som IT service management och ITIL slår fast som en grundbult: det är tjänster som levereras, inte teknik. 

Att programvaruutvecklare tar hand om de fel och brister som uppstår i och med deras ständigt pågående utveckling och utrullning är en bra sak. Vissa kallar detta "dog fooding", dvs man äter sin egen hundmat och tar fullt ansvar för den och alla aspekter av den.
Men, en seriös och mogen beställare inser att det slutliga målet är att detta ska landa i en tjänsteleverans och att förutsättningarna för detta måste skapas Detta är ett ansvar som läggs på utvecklingen av samtliga komponenter - applikationer, infrastruktur, supportprocesser, information och verktyg för hantering av tjänsteinformationen etc.

Alltså - om en organisation väljer att fylla sin Release and Deployment-process med ett agilt innehåll är detta helt OK. Vissa saker kommer att vara annorlunda, andra kommer att vara precis likadana. ServiceDesk kommer fortfarande att behöva förbereda sitt bidrag till den färdiga tjänsten, det kommer fortfarande att behövas en Known Error Database (KEDB), Incident management processen kommer fortfarande att behöva känna till hur den ska anpassas och de nya Service Requests som tjänsten obönhörligt kommer att ge upphov till ska förberedas och fördelas.

Med en lagom stor dos ödmjukhet på alla sidor kan man säkert komma överens och till och med sätta en metodik och erfarenhet som kan gälla framtida utvecklingsprojekt och hur det ska fungera i verkligheten. Ju bättre rustad organisationen är för detta, desto bättre beställning och desto större chans att projektet lyckas hålla sig inom den heliga treenigheten tid - kostnad - resultat/kvalitet.

• En sista jämförelse - Configuration management.
• För det första, det verkar som de flesta inom IT-världen har förstått att Configuration management inom Software Asset Management är en sak och att Configuration management inom IT service management är en annan sak. De har beröringspunkter, men är två olika discipliner.
• Bråk? Inte om man tänker efter först.

För att leverera tjänster med en chans att lyckas behövs kontroll på vad man har och hur det hänger ihop. Självklart kan krav ställas på allt som går i produktion att det ska vara känt vad det är och var det är. På en nivå som tjänstelevererande organisation bestämmer och utvecklingsprojektet tillhandahåller som del av leverans. Komplett med dokumentation.
Om man bara lyssnar och tar hänsyn till alla intressenters behov och krav i förväg har man en bra chans att lyckas. Om inte tar man en stor risk att vakna upp väldigt bryskt.

Nästa inlägg i denna serie kommer att handla om arkitektur och jag kommer att dra en lans för en ny slags arkitektroll. Som vanligt tar jag tacksamt emot era åsikter och kommentarer. 

Jim Lindfors
Verksamhetsutvecklare och utbildare

Läs mer