How to Write a Software Asset Management Process – Part 2

In a previous blog we examined the meta-activities that should be undertaken to provide the best possible prospect of Software Asset Management (SAM) processes being correctly modeled and maintained.

In this article I’d like to detail the entities that we could reasonably expect to see in a process map and their overall relevance to conveying the message of SAM. The shapes used in the table below are part of the ARIS modelling framework – for more details see: www.ariscommunity.com.

	Your process will be comprised of many steps in order to make the tools manageable by those contributing to their successful completion.
	It may be that a function step can only be assigned to specific individuals because of a unique skill set that they possess; or it could be the case that an activity hasn’t been mapped to any individual because the analysis hasn’t gone that far. Either way, try not to model single points of failure or have sketchy supporting work instructions so that data arrives in a department where no one has a clue how to process it next.
	It might be apparent to certain stakeholders that a particular piece of software is used in the execution of a function step, but it won’t be to everyone – clarity around this point helps. At the very least, this will shape the composition of any underlying process definition documents (PDDs) and standard operating procedures (SOPs).
	Data flows into a function step and comes out of a function step – modelling this input and output is critical in demonstrating how data is changed and at what point it is changed.
	If a stakeholder might need to consult a document in the completion of a function step, then this shape represents how this is modelled.
	The cause of why a function step is required.
	A point at which stakeholders should be aware – failure to acknowledge such flagged risks might lead to a process/SAM system failure.
	A measurement point is added to a process map at the point where a metric can be captured, which will help determine good, bad, or indifferent performance of a function step within a process.
	The “OR” symbol – process users can take only one path coming out of this decision point.
	The AND/OR symbol – process users can take one of many paths coming out of this decision point.
	The “AND” symbol – process users must take ALL paths coming out of this decision point.
	Entry and exit points to a process need to be modelled so that use cases can be used to stress-test the cohesion of the processes comprising the overall SAM/ITAM framework. Top tip: the same processes can have multiple entry and exit points to and from the same processes.

A final point: Try not to make your process maps too large – they should only be modelled to satisfy your major and minor process goals and objectives.

So let’s take a look at some of those major and minor objectives that we might reasonably encounter for a SAM process. For example, the software request process – being service management gurus you might already have a process by which you handle service requests, but here’s the $64,000 question: Did you consider SAM in your service design?

If you did not, then all is not lost. Indeed, through general IT best practices, you might have covered some of the main SAM points, and so you are starting with a good working model that you know already serves your company.

If I were to implement a software request process from scratch, then these are the points I would want addressing:

Major Objective

• To manage the request of software as quickly and efficiently as possible; whilst respecting the companies license position.

Minor Objectives

• Line management endorsement is factored into the request process.
• Technical endorsement is factored into the request process.
• A licence pool check is carried out PRIOR to any requests being handed off to a purchasing process.

Points to Consider

• Line management endorsement may not be required for all titles.
• Technical approval should be handled by validating the request against the supported software catalogue (SSC).
• Exceptions that receive line management approval but are not on the SSC should be handed off to an approvals process.
• You might want to drive best practices within the process by having the help desk validate that all requests come with a stock keeping unit (SKU) number, so that the requestee knows exactly what they are ordering and in what quantity.
  Top tip: If you use the SSC as a drop-down list in any online request form, then it is harder for the requestee to mess this up.

The scope of this article prevents me from offering a model using the shapes above, as most likely you will have your own unique requirements that need adding in.

Image Credit