Podcast: Episode 23 - All things SAP

07 July 2016
15 minute read
Podcasts

Podcast: Episode 23 - All things SAP

07 July 2016
15 minute read

Podcast Episode 23:

In this Podcast episode, I am joined by Patrick Dickinson, Senior Consultant at Aspera to discuss all things SAP.

Podcast topics:

  • About Secure Integration and Aspera
  • Which team of an organisation deal with selling/ implementing SAP?
  • What are the key things to look for when looking at SAP Licensing?
  • Why do I need to invest in a SAP Management tool?
  • The difference between SAP tools and other tools
  • Constraints of SAP
  • An end user’s perspective
  • Reviewing your environment
  • Specific business metrics/ engines
  • Engines vs user profiles
  • Indirect access
  • SAP and The Cloud

Transcript:

SAP, the low hanging fruit of datacentre software savings

I recently spoke with Patrick Dickinson, senior consultant at SecurIntegration – an SAP licensing optimization technology (recently acquired by Aspera).

I asked Patrick about best practices for managing SAP and the different risks and challenges of SAP licensing.

Martin: Q. could you tell me a little about SecurIntegration and your background?

Patrick: We started doing this in 2009, however the company has been in existence since 2001 and hence the name, SecurIntegration.

SecurIntegration has a long standing in Security Management for SAP systems, hence the name, and we still have quite a few consultants doing security but our focus has heavily shifted towards the license management and we’ve developed a tool called Software License Control (SLC). SecurIntegration has recently joined forces with Aspera and the name SecurIntegration will soon disappear.

Q. SAP is usually a big strategic purchase for a company, underpinning big chunks of their business with a dedicated SAP team. I’m interested in your perspective of how you talk with customers: Do you sell SAP license optimization to the SAP team or the Software Asset Manager? Who typically owns SAP license management in a company?

Patrick: It depends; it can be the SAP team or the ITAM team. Someone in senior management usually takes the decision to reduce costs or increase transparency into usage. With SAP that is not always easy to do so when it comes to execution we normally end up engaging with the SAP experts within the company.

Q. My understanding of SAP is that there are two main types of SAP Licenses; users and engines. So for the users it’s a case of optimising them, as you would with Microsoft office, you want less copies of professional and more copies of standard and the same principle applies to optimisation of SAP users – is this correct?

Patrick: It’s comparable yes.

The main focus should be on your user management. With users, you have different license types. There are so called professional user types, limited professional user – which is being out-phased at the moment, worker licenses, developer licenses, and other various different licenses. They each have different costs involved. The professional license is very expensive, but you can also have decently priced user licenses. For example, the worker license or the employee license – they are limited in their functionality within the SAP environment. As long as you know what your users are going to do within your environment, and what the effort is going to be to analyse what they’re really using, then you can really tell how many licenses you need from a specific type and how much you should be licensing towards SAP.

SAP engines can be tricky because SAP themselves doesn’t really support the customers in any sort of way. It’s very hard to measure all SAP engines. You have certain engines that have so called self-declared license types. These tell SAP how much you’ve been using, and they simply believe you. It’s a situation of trust, which often is a source of negotiation issues.

Q: So if I’m playing devil’s advocate here, why do I need to invest in SLC or another SAP management tool, can’t I just drop these users into excel and do a bit of crunching and work out who needs shifting on to the right user type? It seems a bit like overkill.

Patrick: I can see your point there, however if you really want to do this manually it’s going to spiral out of control very quickly because you’ve got environments say 200/300 users that become unmanageable because of the size. The more users you have the less manageable it becomes from a manual perspective.

For example, you’ve got an employee changing departments, changing his roles or thereof in the department, maybe leaving the company, or you’ve got new employees starting. There’s a constant shift going on in your user environment and you need to track that. You really need to know what’s going on, which users are being created, which licenses you should have in stock to cover those user demands so it can be a huge manual effort.

Q. We did a review of SAP tools a little while ago, and one of the things I liked about the tools is, if we use the comparison of SAP users with Microsoft again; you might have Office standard and professional and lets say you identified 1000 people that could be downgraded to Office Standard, you would have to physically adjust the software on 1,000 machines; uninstalling professional and reinstalling standard. Whereas with SAP, you can identify user changes and execute them immediately within SAP.

Patrick: Yes that’s true, you can redefine the license type of that specific user so you can say – this is not a developer user anymore it is now a worker user; in doing so you are reducing the functionality of that user account, and also you automatically have a different license allocated to it. So whenever SAP decides to come and visit you and do a check, do an audit (which they don’t usually do as a side note, they ask you to do it yourself), you then report on your current situation. If your current situation is such that you’ve got 50 developers and 200 worker licenses instead of 200 developer users and 300 worker licenses then that’s fine because you’ve reduced your amount of licenses according to the actual usage.

Q: And for this reason I think, especially when you’re looking at datacentre licensing, I think SAP is almost low hanging fruit because you can implement so quickly can’t you? I think it’s one to look at first.

Patrick: It certainly is! User consolidation is the topic that everybody can – and should be – looking at. There are certain trips you can trip over. SAP is not very forthcoming with definitions on what a user type may or may not do, so in actual fact often it’s a negotiation thing you have to discuss with SAP. It says in your contract what your specific license type is, maybe it’s professional user or whatever, and what they are really allowed to do in terms of so called transactions; that’s how the internal SAP technology works. You may have the same license type but you’re allowed to do all sorts of different things than your rival company or your neighbours across the road; it’s not as straightforward as you might think.

Q. If you were shifting user type based on genuine usage, “we genuinely and legally don’t need these high profile users, we’re going to shift them down to a lower user and we’re going to execute that using SLC” for example, are there any constraints to that? For example, if we again use Microsoft as an example, there’s the 90-day rule. You can do certain things as long as it’s within 90 days; Are there similar constraints with SAP? How often can you do this?

Patrick: There are no time constraints on how many times you may do a user consolidation. However, there are certain things you have to consider when you’re doing a consolidation. There are 2 main factors here: one is that SAP also has the 90-day rule, which says, “Only usage within the last 90 days is licensed for”. If you have an account that hasn’t logged in to SAP within the last 90 days it is not licensable so you can ignore those accounts immediately. It’s really important to measure and highlight the accounts that have not seen any usage within 90 days – that’s one key aspect.

The other key aspect is there are 5 main types of user interactions within SAP: 4 of them are system based, and one is so called dialogue user type. You only have to license the dialogue users, so that’s a further aspect you should consider. You can reduce the amount of licenses you have to pay towards SAP considerably only by looking at those 2 aspects.

SAP does not always help you with reducing your license costs. Clearly they don’t have any incentive to do so. They provide you with an audit tool called the LAW which helps you to analyse your SAP environment, however it is quite crude for user consolidation and sometimes it doesn’t consider the so called technical accounts where you don’t have to pay any licenses and still counts them as viable licenses.

Q. What’s it like from an end user perspective? Are the users that require a shift in user type even going to notice? What’s the end user impact likely to be for these sorts of changes?

Patrick: Usually they’re not going to notice because the functionality that those users are using so far is still available to them. As soon as they then start using other functionalities their license type just has to increase. You don’t really have a hard block within the SAP system itself if you don’t want that to happen. I think you can set those things yourself if you want to have hard blocks in terms of functionality, but it’s not something that SAP does automatically; and it makes sense for them not to give you hard blocks because they want your accounts to use as many functionalities as possible for you to incur higher license costs clearly.

Q. For your existing customers, how often are they doing this exercise? What would you recommend in terms of best practise around this?

Patrick: Our recommendation would be once a week. It’s quite crucial to keep a close eye on profiles. The self-declaration in SAP self-audits is labour intensive.

Q. By once a week you mean setting up SLC to check, reconcile and automate the shift of users in a set it and forget it fashion? You do not have to do reconciliation every week?

Patrick: Absolutely. The process is such that you do it once or twice yourself at the beginning, and you set SLC exactly the way you want it and can tweak it whenever you want.

There is a very specific place where you can set the different steps you want to be done – that you want the tool to do for you during the measurement. Then you can even set the tool to write back to your SAP environment. So if you’ve found the settings you really love and you really want, then it automatically writes back in to SAP to implement the optimisation simulated by the tool directly back into your environment.

It can also trigger the LAW measurement so that you always have the latest data that SAP would draw from your environment available according to your most recent optimisation. Once you’re there the tool also allows you to read that data from the LAW which is otherwise quite tricky and you need real experts to do that; you can read with transparency what that report says before you send it to SAP. Knowing what you’re reporting to SAP beforehand is a massive advantage and really crucial.

Q. What percentage of risk or financial impact are engines vs. user profiles? Should I just focus on users now and engines later or what would you recommend?

Patrick: No, you should definitely look at all aspects that SAP licensing includes. It’s definitely user based licensing, definitely engines. You should look at indirect access, and you should look at database technology; everything is relevant. In terms of percentage from revenue, it depends on the business you’re in. For example, if you’re in banking industry in the finance world, you will have a lot of engines – probably 80% compared to 20% users, something like that, in terms of licensing. If you’re in manufacturing, it’s probably completely the opposite –probably 80% of your licensing are user licenses and only 20% are engines, because you need a license for all your workers and so on.

Q. At our events last year Mark Bartrick from Forrester said SAP indirect access was a bit of a cash cow for SAP during audits because of the ambiguity. My understanding of SAP indirect access is when another technology or connection is making use of the SAP IP?

Patrick: That’s pretty much what SAP does. They group indirect access per application. They look at different non-SAP applications that access SAP managed data within your environment or even write to a SAP environment.

Q. I would have thought the first challenge was “where is the indirect access?” “How do I know?” Is that obvious? Can you go into SAP and it will tell you these are the indirect access points to SAP data? Or how do you go about finding out exactly the scope and risk?

Patrick: You need to know where to look and it’s very deeply hidden within the tables within SAP. So you absolutely need expert knowledge to find out which applications may or may not incur indirect access to protect your position when SAP then says, “this application we believe is indirect accessing you should therefore license it accordingly”.

SAP has not really published a comprehensive list of which applications they declare as indirect access. However, there have been lists published through SAP of applications that they have already, in audit situations, declared as indirect access. It’s very grey, and it’s very murky at the moment. You can’t be 100% sure. What you can say is that most applications you’ve written for yourself, as in self developed software, is indirect access and the same applies to most applications you’ve purchased with SAP specifically in mind.

There are millions of applications out there that are specifically designed to do something with your SAP data, and literally all of those will have some kind of indirect access which leads to audit risk.

Q. The large software publishers are trying to transition their business models to the cloud. We’re seeing it with Microsoft, Oracle and SAP. Let’s say that you’re spending $1M a year with SAP, just for arguments sake, and then you do this optimisation and you reduce the number of users legitimately and legally and then you work out that you and actually pay less to SAP, they’re going to come up to the account manager and say “I’m expecting $1M out of your account and we need to fill that gap so you need to spend it on something else”, and one of those ways is pushing it to the cloud.

Patrick: SAP, like the other mega vendors, is pushing their customers into the cloud with incentives. Bear in mind that SAP is currently taking a revenue hit because of their cloud environment and it’s not going to be as cheap as it is for the foreseeable future. It’s definitely going to see some ramp up, other license metrics will be made obsolete or not supported anymore.


Have any questions regarding SAP? Please drop into our Forum and receive knowledgeable answers from topic experts in The ITAM Review community.

Image credit

Can’t find what you’re looking for?