In this post, I specifically look at one item that’s been in my focus for a few months now, especially the past week, namely Software Asset Management environments and tools, with a particular focus on requirements.
I’m enthused by possibility and opportunity at the moment. One of my major responsibilities is Software Asset Management (SAM), of which much can be written about. I’m under the impression that what I’ve been doing has been haphazard and mediocre, holding together an enterprise wide view of our software estate through spreadsheets, purchase data from our ERP system, our SAM discovery tool, and a specialist in-house tool that is used to manage IT hardware (which we call ISAD)
To question my haphardness, I’ve recently been brave enough to answer some surveys based on what I do, and have been surprised at myself when quizzed that what I do (which still seems haphazard and time consuming) is really not that bad a practice, compared with some of the options given to survey responses. The problem with answering surveys of course is that you don’t see the full results, and hence one’s own opinion can be skewed if one assumes that others’ will answer less positively.
Detailed Requirements for SAM
The reason for highlighting this to myself is to aid research options for a commercial tool to handle my SAM needs with a little more intelligence and less manual effort. The reason for my opportunistic optimism is that we are in the formation of a low-level requirement specification, and I met up yesterday with our IT manager (and current ISAD system owner) to obtain a joined up worldview of our combined requirement.
I cast my mind back to this ComputerWeekly opinion piece some time ago, about IT and business merging (and I managed to find again), specifically the 5 simple rules:
- Don’t give the users what they want
- Listen to what the users want
- Try to figure out what they really need
- Persuade them what they need is really what they want
- Then, give them something even better.
The conversation with our IT manager was very much about seeking to understand his needs, and seek agreement on where our needs meet. Before I came along to manage our business software tools, he managed most software in ISAD, so that element is specific to their working methodolgy, which does not mirror that of mine.
Next step is to seek out service providers (internal and external) who can help me turn these requirements into some form of reality and, as David Chan suggests above, “give ourselves something even better.”