How to Write a Software Asset Management Process – Part 1

In viewing many efforts at creating and maintaining a Software Asset Management (SAM) process in different organizations, it’s come to my attention that addressing a few basics taken from the discipline of business and systems analysis would benefit many businesses in this area. Below are my top ten tips for creating a SAM process (equally, these could be applied to the crafting of any process for any business discipline):

1. Know your audience. It may well be that you require more than one physical document depending who you are trying to reach. Process maps offer an excellent “30,000 ft. view” of what takes place; process definition documents offer a “10,000 ft. view” appropriate for a head of department/line manager. Finally, a standard operating procedure should offer a key-stroke by key-stroke explanation of what takes place at each and every step of a process.
2. Know what you are trying to model. Define the primary and secondary objectives of your process from the earliest possible point; this provides focus, but also prevents “process creep” i.e. extraneous activities being added to a process because it seems like a good idea at the time.
3. Align your processes to your SAM strategy. Don’t leave people in any doubt as to what role a process plays in the bigger picture.
4. Align your processes (wherever possible) to your IT If a particular process has an impact purely beyond a SAM sphere of influence, then reinforce that importance, get SAM understood within IT.
5. Align your processes (wherever possible) to your business strategy. Typically, within IT we are quite bad at promoting what it is we do for a company, so here’s an ideal opportunity to remind the business that IT is not merely a utility, and SAM is not just there to keep software vendors at bay.
6. Collaborate. When crafting processes, identify the stakeholders who need to be engaged with, to ensure that the implementation of revised working practices are going to be a success. It’s far easier to engage with stakeholders from the outset with a view to gaining their trust, rather than presenting them with a pre-ordained view of what life will be like after you have finished your design work and SAM becomes “Business As Usual” (BAU) – the culture shock could be too jarring.
7. Test. It’s not enough to merely design processes, they have to be tested to ensure that they are workable for your company and that they deliver the expected results. If not, don’t be afraid to consider re-engineering.
8. Process owner assignment. Make sure your processes have an owner who is prepared to oversee the management and running of the new/revised processes. Without having an advocate for implementation and maintenance, many stakeholders will tend to “revert to type” and fall into the bad habits that we are trying to avert.
9. Process review. A periodic review to ensure that your processes still deliver against their SAM/IT/business objectives is vital if you wish to see your SAM program maintain relevance and drive SAM maturity higher.
10. Look and feel. If your company already has a standard approach to presenting documentation, then leverage this wherever possible – again, this will reduce the perceived culture shock incumbent with any new proposed ways of working.

As previously mentioned, a lot of the above could be applied to any assignments requiring processes and documentation, but they are particularly cogent to SAM. Next time, I’ll take you through the content of the process maps themselves, and what entities should be used to ensure that your process maps get the message across.

Image Credit