If you want to run your SPLA business efficiently, SPLA automation is needed for several key reasons, such as Reducing time spend. Optimizing license cost, Optimize end customer invoicing and Improving Compliance status.
What is SPLA automation?
At the core SPLA automation includes:
- Automated inventory collection, from multiple data sources, to establish the data foundation needed,
- Complex license calculations, finding the most optimal licensing option across versions, editions, etc. and deliver an accurate draft for ordering.
But in addition to this, it should also include:
- Support for end customer invoicing
- Documentation for Audit purposes
Common pitfalls in relation to reporting
Even when you have automated and accurate inventory to perform the sometimes complex license calculations, you still need to take specific license rules into considerations, such as, but not limited to:
- Reporting only one 2 core pack when you are required to report a minimum of 4 cores
- Miss combination of Windows and SQL
- Reporting Office without RDS
- Reporting SharePoint without SQL
- Reporting SharePoint Enterprise without reporting Standard
In addition to this you need to be in control of what products are being licensed under SPLA, and which are not.
You need to track Proof of Concept for customers, exclude server installations covered by License Mobility and keep continuous track of these entitlements in relations to required licenses, to mention a few.
Adding SAL for SA will increase complexity as you should report (and Invoice) based on actual access and not the number of SAL for SA entitlements, taking mixed licensing with SAL for SA and regular SALs in to considerations.
End customer invoicing
This may not be a core feature of a SPLA reporting tool, but this is more often than one should expect, a topic that can be improved.
When inventory is more than a snapshot twice a month and the inventory baseline, the previous reporting month is concluded, the changes related to licensing, can be used to improve the accuracy of end customer invoicing.
To be able to automate support for end customer invoicing you need to have the inventory data sorted on a per customer basis, in relation to deployments and access. As customers are not static, keeping track of changes becomes vital for accurate invoicing, which again also ties into the highest watermark mentioned above.
A report, showing if changes on an end customer has occurred delivers a fast and efficient overview on which customer(s) needs attention in relation to invoicing for the reporting month, so proper actions can be taken.
Documentation for audit purposes
Unless you are able to reject an auditor’s claim, an audit can be quite expensive as auditors often seem to make assumptions that favor Microsoft at the expense of the service provider.
Documentation is the best, and often the only, defense in relation to an audit as “He who holds the best arguments, often wins the discussion”.
Linear calculations, like: “The auditor is applying the logic of that the ESX hosts we have today were the same for the past three years”. (Needless to say that is not the case) or assumptions like: “Based on these sample data we can extrapolate your license needs to be…” are not unusual, but without proper documentation it can be difficult to argue against.
By automating inventory, keeping track of changes during the reporting month, describing how licenses were calculated and saving this in a format which cannot be tampered with, you will have the data needed for the documentation you need for an audit.
