SAM Process Engineering – Governance, Scope, Systems and Processes

By Rory Canavan, 1E

I’ve blogged on more than one occasion that there are no silver bullets in SAM. Too many organizations labour under the misapprehension that the mere purchase of a SAM suite will remove all the potential headaches that effectively managing software entails. In this article, I will examine the role that processes can play in SAM, and ultimately highlight how well-crafted processes can underpin not just SAM goals, but wider business goals as well.

I think it’s important to review the dictionary definition of Software Asset Management, namely:

“SAM is the right blend of People, Systems and Processes required to effectively manage your software and software-related assets through each and every stage of their lifecycle.”

All too often, Processes get overlooked, and without the processes, the People (the stakeholders) will bumble about the SAM suite figuring out as they go what they believe to be the kind of reports the business wishes to see, or worse still, ignore any SAM initiative and carry on with their day to day jobs ignoring any potential proliferation of software. Ultimately, without the correct processes in place, your SAM suite becomes nothing more than a prime candidate for removal through lack of use.

Governance

First and foremost, a SAM framework should be aligned to company Governance – any employees who might (rightly) ask why a particular process is being executed should be able to be told by any stakeholder what value this process has to the company. The reasons could be varied, and arguably tenuous, but there should be a thread from the process activity through to a higher IT or business strategic goal. These can range from environmental/waste management, through to charitable considerations; your processes should encapsulate these aspirations to ensure that appropriate management delegation is given to managing software. It might be easy to think that such goals are too lofty, or abstract in the day-to-day management of software, however it’s worth considering that Sarbanes-Oxley legislation was established for this very reason – to demonstrate accountability and evidence of directorship responsibilities with every-day operations, and let’s not forget that the collapse of Enron led to the downfall of Arthur Andersen Accountants, and caused a massive run on the US Stock Exchange – Governance is not to be ignored.

Scope

Processes too, are shaped by the Scope to which they are applied. Many SAM frameworks are founded with the best of intentions looking to accommodate the desktop estate, or perhaps a specific software vendor. Quickly-won gains from such SAM frameworks may not exactly match a widening of scope to include the server estate or perhaps another vendor. Expectation setting should be included in either supporting documentation, or through communication to senior management that by merely altering the scope of a process, exponential or even proportional success is not guaranteed. A further note to take account of on processes in relation to scope, is that of business-related boundaries. Many enterprise organizations are not typically one large company, being served by one large IT department – often they are composed of disparate entities that operate in different ways and to different agendas; a one-size-fits-all process may not be appropriate in certain cases.

Typical flow charts may not highlight who carries out an activity, and so we can borrow a tried and trusted method from operations management that allows us to map who does what, and to what degree they are involved in a function step or process. RACI charts (whereby RACI stands for Responsible, Accountable, Consulted and Informed) offers us the chance to document stakeholder involvement and hopefully curtail “turf wars” early on in the process drafting stage. The sooner people/departments are on board with the tasks they are expected to perform, the sooner a process can be benchmarked and adopted as BAU (business as usual).

It could be very easy to arbitrarily create process maps, and somehow magically expect data to wing its way across a series of networks with little or no regard to the technical, network or security-based protocols that have to be addressed. By drilling down to the base requirements needed to satisfy audit and reconciliation reports, you will quickly come to appreciate further stakeholders you may not have considered prior to implementing your processes, or further function steps you might have to undertake to accommodate security or network considerations.

IT Systems

It could be that you are fortunate enough to be able to have your pick of IT systems that will be used in the construction of your SAM framework; but more likely you will be expected to inherit existing inventory systems already in place (as a minimum). Equally, you could be compelled to use certain inventory systems (as might be the case with IBM) – whatever your system circumstances are, take a step back and first consider the goals and objectives of your desired SAM Framework. Be bold enough to ask: do those existing systems satisfy my SAM requirements? If they do not, then you have one of two options: obtain new systems, or revise your goals; no amount of process engineering is going to bridge that gap.

Processes

When creating your SAM processes, there are many aspects to consider, namely:

  • Formatting
  • Stakeholder Involvement
  • Methods of Communication
  • Timing of Communication
  • The SAM Lifecycle
  • Process Scope

Formatting: If your company already has an existing format for its process documentation, then don’t re-invent the wheel – use the existing format. This will prevent culture shock, and so increase the adoption of the information you are trying to convey.

Stakeholder Involvement: Using a RACI chart to determine who does and when, is one of the best ways I have found to prevent business and systems analysis spiraling into an echo-chamber of ideas. Consider too, that stakeholders are subject to their own lifecycle; and therefore to ensure continuity of service, new members of staff should be brought up to speed on what might reasonably be expected of them in their new post.

Methods of Communication: We all have email accounts, and unwittingly or otherwise, we have a knack of screening that helps us to prioritize the sequence in which we deal with the information provided to us. Entrusting to one means of communication, and then assuming that all stakeholders will give as much time and attention to your efforts as you did is wishful thinking. Key players should receive communication face to face (wherever possible). WebEx’s, video chats and online presentations are also a useful means of delivering the most important points you wish to convey.

Additionally, cunning use of registering for such events can help determine those individuals who have yet to go through any training the new SAM framework might require of them. End users can be problematic, insofar as they might view the IT equipment as an extension of their own personal equipment; ensuring your processes resonate with them that the hardware and software are company assets, should hopefully mitigate shadow IT becoming a responsibility finance have to address when it comes to replacing such equipment.

Timing of communication: Timing of communication is equally important – if your company is international, then consider that midday in San Francisco is 8pm in London, so staggering communications could be potentially vital (or equally, adopt realistic expectations of comprehension and response times from an email if that is expected).

SAM Lifecycle and Process Scope: Ideally, your processes should hang together like a finely jewelled watch, and thereby support a SAM/ITAM framework that should have a clearly defined boundary that captures as many of the SAM lifecycle processes as possible.

These include:

  • Requisition
  • Acquisition
  • Testing
  • Packaging
  • Deployment
  • Incident Management
  • Problem Management
  • Retirement
  • Disposal

Due to your company’s unique configuration, it could be that some of these processes need to be either broken down, or perhaps even have certain steps within them scoped out of the solution (thereby entrusting to 3rd parties or external entities to deliver certain elements or aspects of processes in a timely fashion). Whatever the shape of your SAM framework, it might be a useful exercise not only to comment on what the objectives of the Framework are, and who they apply to, but also what has been excluded, and why. New individuals to a company (or perhaps absent-minded senior management!) may enquire as to why the SAM/ITAM framework only extends so far in a certain direction, or perhaps doesn’t apply to a particular area of the business. Qualifying your scoping out as well as your scoping in could save a lot of time and heartache.

A further point to consider when crafting your processes is not to try and do everything in one massive process – it’s not as though when your computer is running there is an executable commanding everything called “Operating System.exe” elements of code are loaded into memory on an “as required” basis to make the best use of the hardware at your disposal. Equally, try not to make your processes so miniscule that they are deemed too petty or fiddly to bother with.

Another aspect to address when considering the creation of processes is that of a timeline: What is an acceptable length of time to allow for a process to complete? A Joiners, Movers and Leavers process (the process by which mobile assets are managed within a SAM framework) could conceivably take years to complete – whereas a process which oversees the loading of importing inventory data could be completed in hours. When creating processes and looking to establish tangible and focussed objectives, we can borrow an acronym from operations management, and that is SMART:

Specific: The primary goal of the process should be able to be adequately described in one sentence using simple language.

Measurable: Success or failure of the process should be apparent once the process has completed its lifecycle.

Attributable: All tasks within the process should be assigned (ideally) to an individual or as a minimum, to a department – that way accountability doesn’t fall away to a collective bout of shoulder-shrugging.

Realistic: If a task requires specific system or licensing knowledge, then the expectation for the successful completion of a function step or process should be that the task(s) are assigned to appropriately skilled staff. Equally, if processes demand certain technical functionality of a system, then the system should be suitable in all respects to carry that task out.

Time-based: If processes are permitted to drag on, then the business will eventually circumvent the business need for the knowledge being derived, thereby undermining the medium to long-term permanence of the SAM framework. Don’t be afraid to set expectations concerning the deliverables your SAM framework processes provide.