SAM tools often get a bad rap. While it is normal for anyone embarking on a program to better discover and manage their software consumption to initially create and issue an RFI to a number of SAM tools providers (possibly narrowed down to a shortlist with the help of independent analysts), give it six months, a year or two years and it is more common than not for said SAM tool to have “failed to deliver” what the organization was hoping to achieve.
In fact, Gartner has publicly stated that in the coming years, as many as 75% of SAM tool users will feel dissatisfied with their purchase. Three out of four organizations that invested in proactively managing their software will feel they made a bad choice. Let that sink in for a moment.
But why will such high levels of dissatisfaction exist?
There are already several good articles and posts out there that make suggestions on how to go about defining the SAM program to best ensure success. So, I won’t duplicate that sound advice. Instead, I want to focus on a pivotal moment for anyone embarking on a SAM program – the RFI itself.
Having been in the industry for longer than I care to remember, I’ve seen a lot of RFIs. I’ve also seen a lot of analyst research questionnaires which bear an uncanny resemblance to an RFI. While some RFIs and RFPs are well-written, the majority suffer from the same three common mistakes (my opinion, feel free to disagree).
1. Asking “if” not “how”
It is extremely common to see a SAM tools RFI ask if the tool or service “can identify all the software on the network?”. Another likely question is something like “does [tool/service] provide full support for IBM licensing?”.
Faced with such a question, and the prospect of a juicy licensing or services deal, no provider in their right mind is going to answer “no” or even “yes, but with the following caveats”. Without fail, the answer will be “yes”. Short, succinct and (arguably) true.
Whether or not the tool or service can accurately identify software running on Linux boxes or whether it can really automate the calculations for IBM sub-capacity licensing is by-the-by to a large extent. The vendor will sleep soundly at night thinking they provided a truthful (enough) answer. Meanwhile, the customer is potentially sleep-walking into that “trough of disillusionment” further down the line when they finally discover the shortcomings of their chosen solution.
Arguably, a much better way to phrase questions in an RFI or RFP would be something like “how does the solution discover software on heterogeneous networks” or “how does the solution support IBM sub-capacity licensing calculations”. Make the vendor have to think and be more descriptive in their responses!
“How” should also apply to how the solution or service collects, stores, processes and presents data and what the overhead on the organization’s IT infrastructure is.
Read with a cynical mind (the only way to read RFI responses), holes in the solution’s capabilities or the prioritization of marketing fluff over solid content becomes much more apparent.
2. Failing to identify where the “magic” happens – thinking it’s all about the tool
There’s no denying that the SAM tools vendors have done a great job of marketing their solutions. As with the point above, ask “if” the solution can do something and the answer is inevitably “yes”. However, all the major SAM tools vendors have very different business models and delivery mechanisms. Some sell direct to customers and have in-house teams that actually do a lot of the unseen ‘heavy lifting’ to make the tool look good (“yes we can support IBM sub-capacity, because we have a team of five IBM licensing specialists massaging the raw data and re-entering it into the license manager GUI, but we keep them in a dark room well away from customers”), some sell through channels and rely on those channels to provide the services manpower and some just sell the technology, leaving the customer to find the skills to actually use it. And then there are the service providers who either align themselves to specific technologies or who work with whatever the incumbent technologies are. None of the approaches is right or wrong. And (here’s the rub), none of them are perfect.
SAM is often referred to as a ‘dark art’ and that’s because there’s no SAM technology on the market that can completely do away with the need for human expertise. There are vast differences in the tools’ capabilities, but unless your SAM program scope is particularly narrow (see point 3 below), there is always going to be the need for people with the time to work raw data and the licensing expertise to manage and reconcile entitlements (which are not as standard as you might like to think), performing the ‘magic’ behind the scenes to create meaningful and reliable results.
RFIs/RFPs should make it deliberately difficult for tools vendors and service providers to ‘hide’ the need for human capital. It shouldn’t be a dirty secret that SAM tools need people to interpret the results or that complex licensing decisions can’t be based entirely on automated routines (none of the SAM tools or services are yet effectively using Machine Learning, although it will come…).
3. Choosing the wrong technology/ies for today’s needs
It is understandable that organizations should want to future-proof their SAM programs by selecting technologies that meet not only their immediate requirements but also future stages of the SAM program’s maturity. That might include advanced automation capabilities, support for platforms not in scope for the initial program or the ability to integrate with third party applications (whose own teams are far too busy getting the systems stood up to worry about taking SAM or ITAM data feeds).
It is not uncommon for organizations to choose a SAM tool (and we’re not even discussing the fact that one solution is rarely enough to meet all your needs) only to still not have rolled it out completely a year or two later, or to find that they are using just 10% of the chosen technology’s full capabilities several years after implementation.
Investing in an advanced SAM platform is expensive (especially when some still don’t support subscription pricing or cloud delivery models!) and can easily eat up most if not all of the allocated budget. Depending on the provider and their sales/delivery model, this could leave precious little money to cover the human brainpower required to actually deliver on the organization’s goals (see point 2 above).
As such, while the RFI should include questions (remembering to ask ‘how’ rather than ‘if’) about future SAM requirements, the sections should perhaps be weighted so that the most immediate requirements can be prioritized and scored accordingly, giving the organization a better chance of hitting their immediate quick-win targets (and securing ongoing investment and executive sponsorship!).
I wrote in a recent post about why 2019 will see an increased focus on managing software and subscriptions. As such, I expect to see an increase in the number of ‘SAM RFIs’ issued in the coming 12 months. Hopefully these points will help those issuing the RFIs and using them select technology and service providers make good choices that avoid the ‘trough of disillusionment’ further down the line:
1. Ask “how” not just “if”
2. Probe for what can be done with technology and what needs human decision-making
3. Prioritize on the capabilities to demonstrate successes that will secure continued support beyond the initial 6-12 months