INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

SAP Third Party – Indirect Usage Licensing Part 1

November 26th, 2012 by
SAP Software License Guide

SAP Software Licensing

Many SAP customer license contracts contain either a direct or an indirect reference to SAP’s third party usage licensing requirements.  That requirement is referred to as “indirect usage” and carries a hefty potential financial penalty.  The basic idea is that if you use any non-SAP system to access SAP data the user of that external system must acquire an SAP Named User License.

While I understand SAP’s argument that if you use portions of the SAP software (BAPIs, RFCs, Function Modules, etc.) that you are using their Intellectual Property (“IP”) then they should be paid for that–, it still frustrates many customers.

Where is the Reference to Indirect Usage?

Unless you have explicitly negotiated OUT (or around) the indirect usage it is most commonly contained in SAP contracts in 1 of 2 ways.  It is either explicitly spelled out in the contract language, OR it is buried in some boilerplate language related to the order in which any contract confusion (or dispute) is to be resolved.  Frequently that language lists a hierarchy which references the SAP Price List. 

The SAP price list (in its January 2012 form) is currently over 120 pages AND contains detailed language related to indirect usage.  When it comes time to Untangle SAP Software Licensing your organization should become very familiar with its various provisions.  Like it or not most contracts do subject you to the price list’s terms.  You might as well consider that 120+ pages part of your contract.

SAP Indirect Usage or Third Party Usage Enforcement

Recently SAP has gotten more aggressive about customers paying for third party system connections to SAP applications.  The current push is that you must have a Named User License for any user who gains access to SAP data – even from external systems.  While there are some narrow exceptions the push is to just license any user who acquires the data.

From a customer standpoint Indirect Usage or Third Party Usage creates no value.  It only creates friction, frustration, and mistrust between SAP and their customer base.

In a recent license and contract negotiation with SAP and a fair sized customer, with a significant annual license and maintenance spend rate, this issue came up.  It became a major hurdle to reaching a reasonable agreement that everyone could be happy with.  While SAP was willing to concede special Named User licenses for the Indirect Usage (at a very low cost) it was still a problem.  The customer perspective is that if they decide to use another vendor’s product, and are not engaged in some unethical means of SAP software use to avoid paying SAP licenses there shouldn’t be any fee.  This is becoming a serious issue because from a customer standpoint Indirect Usage or Third Party Usage creates absolutely no value.  It only serves to create friction between SAP and their customer base.

The current focus seems to be on going after third party applications such as Salesforce.com which serve to displace SAP’s own CRM solution.   The SAP User Experience has become a big part of the reason many customers choose alternative solutions and SAP has got to do a better job of addressing that.  Because of SAP’s CRM application shortfalls I have also suggested SAP consider SugarCRM as The PERFECT SAP Acquisition Target, but the real issue is that sales people and customer facing processes want “pretty.”  The SAP CRM option comes up short in the “pretty” and usability category.

There are options for SAP customers, and there are better options for SAP as a software vendor.  Yes SAP, there actually is a way to grow your revenue, increase your software footprint AND have happy customers too!  There really is a way to “have it all” if you will consider it!

The discussion next week is around an SAP Sales and Marketing option which can significantly change this customer pain point.  It will help set SAP further apart from competitors while still growing the application footprint AND increasing revenue.  SAP, if you’re reading this, you don’t want to miss next week’s post!




Popular Searches:


  • sap indirect usage licensing
  • indirect usage of licence sap
  • tco sap crm
  • SAPThirdParty-IndirectUsageLicensingPart1|INNOVATE INTEGRATE TRANSFORM
  • sap use means direct or indirect
  • SAP TCO examples
  • sap tco
  • sap rfc license
  • sap price not comming from contract
  • sap indirect usage
  • SAP Indirect Price List
  • SAP Indirect license
  • is it legal to use RFC connections in Sap Erp to avoid licenses
  • third party sap

Related Posts:

Untangle SAP Software Licensing

July 9th, 2012 by
SAP Software License Guide

SAP Software Licensing

Recently I read a self-serving post on LinkedIn from a company who promotes how “wonderful” Oracle is for having a public price list and how terrible it is that SAP and others do not.  While it may be true that SAP does not publicly publish a price list there is one, it is regularly updated, and it is quite thorough. 

The main complaint was that SAP lacks “transparency,” whatever that means.  There was no mention in the post about how Oracle sales tactics include virtually giving their software away and then after a company finally gets stable they hammer them with massively increasing maintenance fees and costs.  Think about that, once you become dependent they more than make up for the software license with the forced maintenance march.  That really makes their price list completely worthless.  My response about SAP’s lack of “transparency” was:

On this point I completely disagree.  It is not that SAP does not have transparency, it is that their solution and license portfolio, as well as dependencies reflect their size.  Unfortunately it does make it complex.

So, I will absolutely guarantee you that if you do NOT have deep SAP application experience you will be completely baffled.  Not because anyone is trying to trick anyone, but because the solution portfolio and its capabilities are huge. 

SAP is like an “erector set” both in how you set up the various applications to meet business needs AND how you deal with multiple application integration issues to address a particular need.

Just concluded an SAP software licensing negotiation.  Significant solution portfolio, significant application landscape, typical fragmented multi-national who grew by M&A.  If you do not know the SAP landscape you will become completely LOST in their price list and in understanding the solutions.  You almost need to be a solution architect to really be able to help customers navigate the solution footprint.

———————-

I can absolutely guarantee you that if you do not have deep SAP solution exposure you WILL be lost.  However that is NOT a function of some nefarious scheme to hide pricing.

I reviewed a recent copy of SAP’s price list I have from January 2012 and found there are roughly 18 spreadsheet type pages, with a little over 50 price list entries on each page, for around 900 total entries.

One Reason Why SAP Doesn’t Publicly Publish Their Price List

I have heard from some SAP insiders that one reason for not publishing their price list is the sheer amount of confusion it would create.  Solution architecture can be difficult enough –, even as an SAP veteran since 1994, with a deep and diverse SAP background, the substantial size of the SAP solution portfolio can be overwhelming.  Then combine that with the dependencies or requirements for each solution and you have a recipe for more confusion rather than clarity by publishing a large price list.  Then you have the “sales model” of “give it away” and make it up by crushing dependent customers after they finally stabilize.  Add to this the natural tendency of competitors to seize on any single item and deliberately take it out of context to “land a deal” and it is understandable why SAP doesn’t publish their price lists publicly.

Where To Get SAP Licensing and Pricing Information

Probably as a result of the licensing confusion SAP publishes a public license guide and has a price list which is also available.  Both of them are designed to help clarify licensing with SAP products and solutions.  Keep in mind that between the “introduction” guide and the actual price list document we are approaching 200 pages (Into Guide about 40 pages, full price list around 140+).

The introductory guide helps customers understand the SAP licensing approach and options.  It is freely available and I have included a recent version on my site here:

While this license guide provides you the key principles you need to understand there is also an actual, detailed price list as well.  That price list includes roughly 120 pages of explanations and examples for licensing the various specific SAP products, and then another 20 pages of the roughly 900 price list items.  THAT guide should be obtained through your SAP sales rep.  I can assure you that they will generally provide this if you ask. 

Out of respect for SAP’s decision not to openly publish their price list to the public I will not place any versions of their price list online.  However if you are a customer and are confused with the price list I will be happy to walk you through it if you contact me.

Good luck on your SAP journey!




Popular Searches:


  • sap price list
  • sap licensing guide
  • sap price list 2012
  • sap license price list
  • sap r 3 price list
  • price license popularity of sap
  • SAP pricelist 2012
  • sap pricing and licensing principles

Related Posts:

SAP Landscape Consolidation

February 13th, 2012 by

SAP Landscape Consolidation Direction

SAP direction

For any number of reasons many companies who run SAP end up with fragmented and piecemeal landscapes.  It happens for lots of reasons:  roll-outs, independent Business Units, mergers and acquisitions, immature software procurement processes, lack of a Software Asset Management program, etc.  The results can leave your SAP application and business solution looking like someone set off an explosion scattering pieces everywhere. 

More and more I am seeing companies looking to consolidate onto either a single platform or at least a few regional platforms.  This makes sense for a lot of reasons.  It is easier and more cost effective to manage user licenses, engines, solutions, and create centrally supported business processes. 

Getting the SAP application space all together makes it simpler to manage and helps to control overall costs–, both from a solution cost perspective as well as internal maintenance.  Done properly a consolidated SAP landscape can help to reduce TCO and improve your ROI.

SAP Total Cost of Ownership is reduced by more than just any hardware or architecture savings, there are also real savings in the ability to centralize support and maintenance.  Your overall consulting costs will be reduced as well because in a fragmented environment any consulting efforts that are needed in the broader enterprise tend to be duplicated as well as fractional.  On top of that there is also the cost of bringing each of those fragmented consulting resources “up to speed” on that particular business unit.  Then there is the cost of short-term spot consulting.  I’m sure I’m not alone here but on shorter engagements I charge a higher rate than on longer term engagements.  And those are just a few examples of the impact on SAP TCO.

If you are considering an SAP application consolidation all of the previous posts and information on re-implementation are very similar to what you deal with on a consolidation.

Consolidating Fragmented SAP Solutions

Because of SAP’s focus on business application solutions their application footprint tends to expand into many areas of the business.  Aside from more traditional application offerings like SAP ERP, CRM, BW / Business Objects, and HR, there are many engines SAP also licenses and you can quickly end up with a jigsaw puzzle of SAP solutions spread around your enterprise.

Done properly a consolidated SAP landscape can help to reduce TCO and improve your ROI

Over time this jigsaw puzzle leads to licensing headaches where you can be over-licensed or under-licensed even on the same SAP solution across instances.  You can end up with a huge architecture headache where the hardware, interfaces, infrastructure, security, and usefulness of the systems are impacted.  Remote use of the systems creates duplicated access and duplicated security problems.  Reporting across the various solutions becomes little more than critical compliance rather than business insight across the enterprise.  And the list goes on. 

There are also struggles even after a successful consolidation.  One of the better components which likely led to some of the fragmentation was the autonomy and freedom to set up the system to run it the way the business thought was best.   In a consolidated environment that freedom becomes more difficult because it must be coordinated with all of the other players.

Even though there are benefits there are still a few drawbacks.  But many of these drawbacks were the same things you likely considered when each SAP instance was used to replace some legacy application. 

Where Do You Begin SAP Landscape Consolidation?

Just like with an SAP reimplementation one of the first decisions to make will be whether to use an existing system as your starting point or whether you should do a “clean” start with part of the application landscape?  My personal preference is to start clean and challenge any custom development as to how necessary it really is.  That is one issue. 

Then there is the issue of defining global standards around data, authorizations, user provisioning, development, processes, etc.  How you will segregate legitimate needs for differences between the various businesses?  What are your processes for this?  There are also political realities.  It is tough to get some very profitable or flagship business units on board with these types of initiatives. 

Then there is the issue with how do you start such an initiative?  Once again, I suggest you begin where it makes sense, and where it has the least financial impact.  Begin with either a rollout location OR with a location that is in need of an upgrade.  While the effort and impacts are different the project work and some budgeting around these areas is already being planned for.  It is just a matter of systematically rolling any upgrade or rollout efforts into the newly determined “central” instance as time goes on.  This way each phase can take lessons learned, refine project standards, improve on delivery processes, enhance deliverable templates, etc. 

And then there will be the issue of negotiating agreements with SAP that allows for the changes in the application footprint and user licensing.  Do not underestimate this effort.  At this point I would suggest you hire an outside IT spend management firm to help with determining what a new contract or license agreement should look like.  For example I work with a company called “NPI Financial” from time to time.  There are others out there but this is also an important component of your landscape consolidation.

Good luck on the journey and if you need architecture, solution, spend management, or other consolidation help please feel free to reach out and contact me.




Popular Searches:


  • Consolidating on sap
  • sap jigsaw implementation
  • what is solution landscape consolidation

Related Posts: