Setting the scope of SAM design

Best practice

Setting the scope of SAM design

The views of the writer in no way reflect those of the organisations he’s working or worked in.

Pick any definition you like of Software Asset Management. I’ll go with the ITIL version:

“Software Asset Management (SAM) is all of the infrastructure and processes necessary for the effective management, control and protection of the software assets within an organisation, throughout all stages of their lifecycle.” (OGC, 2003)

Fantastic. Or is it? Let’s have a look at a definition for an asset:

Asset | Item of value owned by an individual or company. In SAM, we often speak of a license asset (covering only the purchased licenses, including maintenance, trade-ups , etc.) and software assets (covering both, licenses and deployments). (GmbH, 2012)

Both of these are open to interpretation and not incredibly handy in locking down the scope and policy for SAM. It’s not hard to see why there can be some confusion in companies when they see a new team that will “manage their software assets”. With much of many companies’ budgets taken up by software costs, management of software is simply an IT function so the above definitions could effectively apply to any number of teams depending on the team’s perspective. Especially in large enterprises with sprawling complex IT departments and equally sprawling views. So, as an organisation decides to bolster its SAM competency how well placed is the new SAM manager to set a clear scope specifically for SAM and deliver a shining new SAM Policy?

SAM is in the eyes of the beholder. Depending on the SAM maturity, culture and experience of the company leadership, “managing software assets” will mean different things. Additionally, if the country has a low SAM maturity this multiplies the effect. The procurement team will have a financial lens and be rubbing their hands at how you’ll be improving pre-purchase assessments and reducing their purchasing risk. Operations will be looking forward to the improved functional use and optimised business continuity plans and security will be awaiting the new assessment procedures. While there are a number of good SAM policy templates on the internet from the perspective of a SAM professional, they may fall short of providing enough scope for all of the teams signing off on the policy. This means that setting the scope of SAM can be a testing process as you try to define the SAM policy amidst an array of differing corporate lenses.

Add to this the typical situation that SAM has only just been kicked off and you could count your staff by the toes on your hand. So let’s look at things so far; far reaching definition, check. Seen as the golden goose for many teams, check. Multiple perspectives on what an asset is and what management of assets looks like, check. A lack of resourcing to tackle the work, check. I suspect this will sound familiar to many.

So what to do?

This really depends on your outlook and the outlook of the organisation you’re working for at the time. Why has SAM been implemented (or improved)? How fast does the company need to get to a decent level of maturity? How many different agendas are floating around (this can be proportionate to the amount of organisational change and forming/storming/norming/performing etc. phases)? In most cases I’ve worked on, SAM is usually being bolstered just after a large vendor has walked into the building with a serious jar of Vaseline in their brief case, and walked out a few million richer. Does the company need to improve how it’s operating the software? No, it wants to stop getting budgetary surprises each year and find a way to get its money back from said vendor.

SAM is typically focussed around cost savings and risk management of assets rather than the operational aspects. The key risk and differentiator of a software asset from other corporate assets is that it comes with a shiny if somewhat blood stained sword of Damocles (read: license agreement).

Given the book value, maintenance cost and potential penalty cost of slipping outside of these agreements, it’s hardly surprising that this is the focus for SAM. Add to this the many short, fat, tall, serrated, double-edged, double-handled swords that different software publishers dangle, SAM is generally a large task requiring a lot of focus in this area. So scope is key.

Now if you take on the many and varied additions to your SAM scope, perhaps wanting to be the shining example of operational service in your company or perhaps ensuring the longevity of your tenure you may want to think again. As with any project that allows scope creep to go unchecked, there’s usually a tough conversation at some time that the project was supposed to finish and a sudden vacancy for a project manager. Absolute clarity is required to both ensure software assets are managed properly and to ensure your annual planning is effective with the right resources (people/processes/tools) assigned to the task.

Managing Assets is about cost and risk

To me, managing software assets is different to the operational management of software. Managing assets is about costs savings and managed risks from a more financial viewpoint. An operational team will hold a different lens to the application management lifecycle to ensure the business is operating effectively. ITSM fills the operational space, ITAM the financial (handy that). If you had a string of hotels, would your asset manager be looking at how the hotels are operating and customer satisfaction, or would they be more focused on ensuring your properties and chattels continued to hold value? Sure, they’d work with the operational teams on certain aspects, but their policy would be focussed on their key outcomes.

As examples, in the pre-deployment phase SAM is looking at potential hooks in agreements, or optimised licensing for the best procurement option. Operations on the other hand is looking at how administrative loads and business continuity impacts as the project and development teams gradually form a solution. In the deployment phase SAM is ensuring the right licenses count is maintained, audit schedules are in place and ongoing maintenance or subscription costs are covered, where operations is looking at ensuring the support teams are ready and bugs are at a minimum.

Now I am not suggesting you slam the door where you perceived the work is outside of purist SAM activities, but be clear on what purist SAM activities are. SAM has a stake in the operational space and can add huge value. Rather than filling the SAM scope with a list of operational activities, working with the business to recognise the additional functions and interrelated policies needed could add wider value to the business beyond asset ROI. Or, you could soak up all the additional activities, put the business case forward for all of the additional staff and make hay while the sun shines. I would say though that you would then move from being a SAM manager to being an IT Manager pretty quickly, and your SAM policy would potentially be broader than necessary. For my money, keep it simple and keep your eye on the ball…or sword as the case may be. Focus on keeping costs down and budget surprises out. Good luck.

I’d be interested in how other asset managers have traversed this topic in organisations they’ve worked and which way they needed to go, and I am happy to share more of my own findings in this area.

Image Credit

References:

• GmbH, O. M. (2012). Top 200 SAM Terms – A Glossary of Software Asset Management Terms. Muenchen: Operations Management Technology Consulting GmbH.
• OGC. (2003). Best Practice for Software Asset Management. Norwich: TSO.

Can’t find what you’re looking for?