Licensed or not? (Part 2): The SAP story

In part 2 of his licensing blog post, UKISUG Director Alan Bowling, looks at the history of SAP licensing, including different marketing terms and the importance of working with experts.

Now you have to have a bit of a history lesson to understand how some of the more well-publicised SAP licensing stories have evolved. In an earlier blog, I described the evolution of SAP – the very first licenses purchased were simply about users, because there was essentially just one product. Then SAP started to develop additional modules (e.g. HR or CRM) to the original offering, and also started to offer those as stand-alone products. So was born some “engine” related licensing in addition to users, now sometimes referred to as “packages”.

And then along came the Internet and MySAP.com, as SAP’s branded internet-ready enterprise solution, with a concept of “internet users”. This was a greyish area being introduced, so much so that one of the SAP Notes applied to systems as part of the routine patching rounds actually removed this user type from customer systems. At the same time, the definition of a user also started to change – so we had different levels of usage, with developer licences, full professional licenses, and limited professional licenses. The strange thing being that SAP defined a proportional ratio of limited versus professional licenses. This was meant to stop abuse of the “cheaper” licenses, but the reality was that every organisation was different with very differing levels of staffing and usage, requiring a degree of flexibility to be introduced into contracts.

So, we ended up with a situation where we had user licenses and engine licenses…and you needed both to be able to play.

Making sense of licensing today

Today, the amount of detail has continued to mushroom as more and more “modules”, “products”, “solutions”, “packages”, and all the other paraphernalia of software marketing terms, have been introduced. For the UK – the current terms and conditions can be found here.

But this is only part of the deal because you also must have the SAP Software Usage Rights document; the current version runs to 78 pages and can be found here.

You may also find this handy 186 page document useful which defines the German market, but it explains more than the software usage rights document in that it also includes maintenance, and other licensing and contractual requirements. How much of the SAP product family you have purchased defines how much of that 186 pager is relevant to you. Then on top of this, you have cloud products. I’ll not go into loads of detail but suffice to say for cloud there isn’t just one agreement there are three, found here.

A further complication is that not all the SAP solutions are either directly measurable and/or do not have an inbuilt tool to monitor usage. Remember what I said in the previous blog.

In my opinion, the well-publicised SAP licensing stories are hardly surprising given how software usage has evolved. Following input from SUGEN, SAP is working towards a new licensing paradigm for the future that looks to improve licensing, especially in the era of IoT and connected systems. This has seen SAP introduce its Digital Access licensing model and more recently its Digital Access Adoption Program – there’s still certainly work to be done but the direction of travel is right and appropriate for the future.

My final thought on licensing applies to all. Whichever way you go it is complex, and can have massive consequences if you get it wrong (for all parties). My advice is to make sure you have access to experts (perhaps independent) who can critically review what you have got against what you need now and into the future.