What This Article Covers
- Quotes from Snow Software
- Analysis of the Quotes
Snow Software wrote a paper titled 5 Ways to Cut Spending on SAP Software. In this article, we will analyze this paper.
Quotes from Snow Software’s Article
SAP has more than 40 named user license types in its standard definitions, ranging in price from $60 to $7,000 per license. These license types determine what transactions the user is permitted to perform in the environment. SAP puts the onus on its customers to assign the appropriately named user license type to each user account. Without the right data upfront, the only way to do this is to generalize and attempt a best-fit. The work that individuals perform can change year on-year. This means that a license type which once fit well beforehand is no longer compliant
It is in fact quite interesting that SAP has such a broad continuum of user license prices.
Organizations typically end up overspending because they do one or both of the following:
- Purchase unnecessarily costly named user license types to ensure coverage of user’s requirements, but also cover them for use of transactions that they do not need.
- Keep user-license assignments static until the next SAPmandated system measurement, and then pay the fees that SAP requests for any shortfall.
So basically customers have a hard time optimizing their licenses. I think there is a common misimpression that the company’s contract or purchasing arm will perform license optimization. This is not the case. And one does require software to provide the necessary information. This also keeps SAP from leading the discussion, which will, of course, lead to more of what SAP wants, rather than what the customer needs.
During a proof of concept, Snow typically discovers around 20% of licensed users in an organization who have been inactive for more than 90 days. Users who have been inactive for more than 90 days (or whatever date is deemed appropriate) can have their license returned to a pool (re-harvested) for reassignment as and when they are required.
This was quite interesting. This means that many customers are over licensed. This is also interesting because SAP only ever discusses the potential of being “under licensed.”
This environment evolves over time as new systems are added. Users must be licensed to access these systems and so they are often provided with a new account, the username of which may be different from the username they have for other systems.
Another issue where SAM software can assist.
Indirect Usage is, in simple terms, where an SAP system is accessed or queried through a third-party application. The way in which that application interacts with the SAP system and underlying data can have a significant impact on licensing requirements and financial exposure at the point of audit. If any individuals are accessing SAP-stored data through third-party software, organizations must ensure that they have an SAP named user license of the right type provisioned for them.
Why this is true. The assumption presented here is that all integrations to SAP applications mean that the customer needs to have licenses. This is an endorsement of SAP’s Type 2 indirect access. However, Brightwork has repeatedly questioned whether this type of indirect access is even valid. This is the concerning feature of SAP, that they can make a proposal which breaks with the legal precedent in licensing, and pretty soon everyone from consulting companies to SAM vendors is repeating it.
Organizations should build up an architectural diagram of Indirect Usage across the SAP environment. This places them in a strong position when SAP audits because any additional fees are based upon real usage, not an estimated and perhaps overinflated value which is indefensible because of lack of visibility.
Yes, this is true, SAP sets about to cheat its customers whenever possible. So SAM software is necessary because the customer must have access to usage information that is independent of SAP.
SAP licensing is not only based on per-user metrics, but includes software engines as well. SAP engines (aka packages, modules and add-ons) are optional applications for which additional licenses must be purchased. The metric used for licensing differs by engine, and is based upon the objects that exist within that application or its total CPU consumption. For example, the metric for SAP Payroll Processing is number of master records, while the metric for SAP E-Recruiting is number of employees.
This is apparent from reading the SAP Price List. It is so complex to price many of SAP’s applications, that even account executives rely on a professional pricing expert that does nothing but pricing within SAP. What Snow software is saying is that this pricing is built into their software. We are not validating this, but if true it is an impressive accomplishment given SAP’s pricing complexity.
SAP licensing is both complex and open to interpretation. Typically, environments have been running for many years, so it is difficult to get a handle on which licenses are assigned to which users, whether those licenses are correct for the user and indeed whether a license is required at all.
This quotation highlights how licensing must be run occasionally as the usage of the SAP system changes over time.
Snow Software’s paper was quite helpful and educational. The indirect access quotations are a concern for reasons already listed in this article.
Who is the Most Accurate Source on SAP?
Want to find out? See... A Study into The Accuracy of SAP