More than forty seasoned software asset management professionals were asked for one piece of advice for someone starting out in a SAM role. Their answers fell into four categories, and none of them was "buy a tool".
A question went out on LinkedIn a couple of months before this was written, inviting a network of seasoned software asset management professionals to offer a single piece of advice to anyone starting out in a SAM role.
More than forty people answered. Reading through them all, four clear categories emerged:
What follows is the substance of that advice, grouped the way it grouped itself.
Start with a plan and an agreement. Before anything else, get a written understanding between you and the business about what the SAM programme is expected to deliver. Clear outcomes. Clear deliverables. If nobody has written down what success looks like, everybody gets to decide for themselves later — usually at your expense.
Treat quick wins carefully. Quick wins can erode fast. Target them, but target them inside a broader effort to establish good practice and sustain the result. A saving you cannot repeat next year was a one-off, not a programme.
Define the scope, then define the measure. Set out the scope of the programme alongside the specific business outcomes it exists to produce, and build metrics that let success be judged objectively rather than argued about.
Phase it. A phased approach produces measured, meaningful results. Attempt everything at once and you will get lost in the data — and the data is very large.
You will not do this alone. There may be very few of you. That is normal. It also means the plan has to depend on other people co-operating, so build it that way from the start.
Keep it simple, and grow two things at once: your knowledge and your reputation. Engage openly and honestly with the rest of the business, and demonstrate the value of good SAM practice rather than asserting it.
Sponsorship is a people problem. Developing and maintaining your people skills is how you gain and retain sponsorship from an executive, and how you secure buy-in from the stakeholders whose data and co-operation you need. Relationships — with stakeholders, with leadership, with peers — are the foundation everything else in SAM is built on.
Network with practitioners, not just vendors. Speak to people actually doing SAM on the ground, facing the same problems you are facing, and learn from their experience and their mistakes. This community is unusually generous with both.
Educate continually — yourself, your peers and your stakeholders. Most people believe they already understand ITAM and SAM, and most of them are picturing something it is not. Then one day you see it land in someone’s expression, they finally get it, and your support network has just grown by one.
Consider a certification. Formal credentials in the discipline are a real boost, particularly early on when you are still establishing why anyone should listen to you.
Get the people, the tools and the processes in place. All three. Missing any one of them makes the other two much harder than they need to be.
Data quality is not a detail, it is the whole job. All the work is in vain without total data quality and a real understanding of that data. Bad data will always be bad data — presenting it more attractively does not change what it is. If your effective licence position rests on an inventory you cannot defend, you do not have an effective licence position. You have an opinion.
Build relationships with your vendors and resellers. They are not necessarily the adversary you might assume. A working relationship on both sides resolves a great many issues before they turn into findings.
Be passionate. It is far easier to sell a concept when people can see that you care about it.
The clearest signal in forty-odd replies was that no one of these is sufficient. There is no single move that makes a SAM programme work. Cover each of the four areas above and you give yourself a genuine chance of succeeding in the role.
If you are new to SAM, the most valuable thing you can do this week costs nothing: find the wider SAM community and start learning from other people’s blind alleys instead of walking down them yourself.
The one piece of advice with a technology consequence is the one about data quality, so it is worth being concrete about what “good data” actually requires.
Recognition is the first test. Raw inventory returns thousands of installed files with inconsistent publisher and version strings; what you need is a normalised title. CerteroX SAM resolves installs against the Software Recognition Database — more than 3.5 million titles — and adds release date, end-of-support and extended-support dates against each one, so lifecycle questions are answered from the same record as compliance questions.
Coverage is the second. An inventory that only sees the machines an agent reached is not an inventory of what you own. CerteroX ITAM runs ten discovery and inventory methods into a single schema, across six operating system families, so there is no reconciliation exercise between the sources.
Usage is the third, and it is the one that turns compliance work into savings work. File-based usage metering records first-used and last-used per install and computes a percentage-used figure over a rolling 90-day window. That is the evidence that lets you harvest a licence rather than argue about whether anyone would miss it.
None of that substitutes for the plan, the sponsorship or the relationships. It just means that when you have those, your numbers hold up.
If you would like to talk to someone who does this for a living, get in touch.
Other posts covering the same ground.
Most SAM programmes are built on Active Directory and an agent deployment, which means they are built on a list that is already wrong. Discovery is not a preliminary step to software asset management — it is the foundation the rest of it stands on.
SCCM is good at what it was built for and was never built for software asset management. You do not have to throw it away to close the gap — but you do have to know precisely where the gap is.
SCCM can tell you a file exists on a disk. It cannot tell you whether the application was installed, whether it belongs to a suite, or which edition you are running — and every one of those decides what you owe.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.