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
  • SAP INDIRECT LICENSE
  • indirect use licensing
  • Sap indirect usage license
  • sap indirect licensing how it works
  • SAP direct and indirect licensing
  • sap crm indirect usage license
  • sap appcenter license contract
  • SAP 3rd party access of data
  • licence cost indirect use of sap from salesforce
  • sap licence 3rd party access

Related Posts:

Storms Coming on the Salesforce.com Cloud Front

November 19th, 2012 by
Salesforce.com Cloudy Vision

Salesforce.com financial clouds

 

I recently ran into a post from a pretty well respected investor blog over at “Seeking Alpha.”  The basic takeaway is that the Salesforce.com cloud business is not all it is hyped up to be and that shareholders may be in for a seriously rude awakening [FN1].

——————–

The way it is described there sounds a LOT like Enron accounting.  They called it a Ponzi Scheme and here is how it works:

  • Employees receive stock options INSTEAD OF cash compensation for various raises, bonuses, etc.
  • Salesforce.com takes the DIFFERENCE in stock value that they gave to their employees (an expense under GAAP and IFRS) verses what it WOULD HAVE COST in cash and books THAT DEFERRED COST as actual cash flow.  Viola! Magical cash flow appears!
  • THEN they add the “saved cash flow” (deferred cost, i.e. Expense) to non-GAAP earnings as “profit” thereby doing a complete Enron to convert an expense into profit.

So, let’s sum this all up.  They issue more stock certificates, they provide them to internal employees, then they simply count the stock certificates as profit.  WOW!  That is some creative accounting. 

The post goes on to explain the shareholders have their share value diluted, not necessarily in dollar terms in the SHORT TERM, but most definitely in quantity terms in the short term.  It is only a matter of time before it all catches up with them however.  Their whole premise is the Salesforce.com Cloud sales model is unsustainable in the mid to long term.

An added expense to the shareholder is the dilution that these increasing stock-based compensations are causing. Every quarter, the share count is rising. So the shareholder is fooled in a double manner. By dilution and representing costs as profits.

They go on to add that while some investors may be fooled in the short term on the non-GAAP claims the GAAP numbers tell a story that the company may have some very serious storm clouds ahead.

Without deeper insight, instinct would tell you there must be a catch, simply by asking the following question: How can you raise cash by spending more than you earn? Spending more than earning is exactly what Salesforce.com is doing, as evidenced by the company’s increasing GAAP losses.

The summary is that Salesforce.com excludes the huge expense of stock based compensation to present NON GAAP profits (masking that this expense results in GAAP losses), but on the other hand they include it in their cash flow statement to present rising cash flow (masking that true cash flow from operations is falling).

Consequences of a Salesforce.com Stock Fall

A Salesforce.com stock slide would have significant ripple effects across all of the software space, but most aggressively on any of the cloud vendors.  Because it is such a high profile cloud vendor, and a high profile CRM software company, the effects would likely have at least some short term impact even on companies like SAP.  

 


 

[FN1] Salesforce.com Accounting Shenanigans Explained

http://seekingalpha.com/article/857361-salesforce-com-accounting-shenanigans-explained

Related Posts:

Where Does Agile Fit in SAP Projects?

November 12th, 2012 by
Agile on SAP projects

Agile SAP Success

After offering insight based on my personal experiences around “Agile Project Methods for SAP ERP Projects?” I thought it would be helpful to highlight a couple of areas where Agile does work.

  • Design sessions
  • Development efforts (i.e. coding)
  • Data conversions

Once you begin to move very far beyond these areas you quickly encounter dependent work streams that need much more coordination.  Those additional dependencies make it difficult to apply Agile methods.

While Agile tends to emphasize the 1 week to 1 month “sprint,” I would define a “sprint” in more of a completed requirements and planning package rather than a pure time-box approach.

 

Applying Agile Methods to ABAP Software Development and SAP Data Conversions

Development (ABAP, Java, or other coding)

Since Agile methods have been used for some time with small, discrete components of software development I won’t spend a lot of time there.  On a typical SAP project you will end up with a functional spec which defines the program requirements and a technical spec which informs the development details.  Even though the more typical “Agile Manifesto” method would not require the documentation it is well-placed on an SAP project.  In fact, it is foolish not to have it for long term support and maintenance. 

Development can work well for the Agile stages of build / prototype, demonstrate, gather feedback, adjust, and repeat.  The key here is to limit the number of these “Agile” cycles to no more than 3 for software development.  By 3 cycles I mean 3 completed cycles too.  This is not a demonstration with feedback that is only partially built.  If the feedback cycle is not completely implemented then it is not a complete cycle.  Even though Agile would consider these “sprints,” I would consider them a FAILED sprint if the requirements of the current plan, or the subsequent plans, are not fully realized in the prototype or demonstration.

SAP Data Conversions using Agile Sprints

With data conversions I suggest at least 3 complete cycles or “sprints” (not including a minimum of 1 mock go-live conversion, probably 2 or more if you can). 

  1. Build the initial conversion program to all of the requirements (again, partial requirements do not count as a full cycle).
  2. Pilot a test conversion with all data, no matter how much fails, and capture all necessary changes.  This will include data dependencies and sequencing.  At this point you will be lucky to achieve a 70% success rate when considering all of the data dependencies.  This step is not about getting things perfect but about identifying data and programming issues to resolve.
  3. Implement all SAP data conversion changes the conversion pilot exposes, script every conversion step and rough timings, and aim for a successful test target of at least 90%.
  4. Make additional changes and attempt to follow the scripted conversion, making adjustments to the conversion script where necessary, and achieve a goal of at least 98% conversion completeness and accuracy.

Once you achieve this level of conversion consistency it is ready for a mock-conversion.  These Agile “sprints,” or as they are starting to call them now “Scrum-ban” (as a spinoff of Kanban) will help to ensure a successful data conversion.

Agile Design

Agile processes or sprints, are effective for design sessions.  Done correctly, this allows a customer to be exposed to the system earlier, provide better insights and results, and generally improve overall solution fit.  

One of the major differences with Agile Design vs. the traditional SAP Blueprint is the timeline.  An Agile Design approach requires more time because there is an element of system setup and solution discovery.  In the traditional Blueprint approach, everything is done on paper and many details are often missed.

When you combine an Agile Design approach with Lean principles, you can see overall project benefits in quality, cost, and overall solution stability at go live.  What this means is that during the design you are actually doing small “sprint” type activities to build out key areas of the solution.  Design sessions become playback and adjustment.  One key consideration with this approach is that you will not have 100% of the integration areas, or solution areas completely set up and defined.  This is important to understand.  If a customer expects to see perfection during Agile Design then a more structured waterfall approach, with a formal paper Blueprint would be required before any system solution activities are performed.

Conclusion on Agile in SAP or other ERP Projects

Even with newly packaged Scrum, Agile, or other methods, on an SAP project there are so many moving parts and work streams to coordinate that there is no substitute for a good waterfall project approach.  Using “Agile-like” methods for the ABAP development or data conversions is not a substitute for good project management either.  Done properly this approach can work well as long as it is carefully managed along with the rest of the work streams.

The Agile approach that works for an SAP deployment is one with a mix of both Agile for discrete task areas combined with a waterfall overlay.




Popular Searches:


  • erp prototype
  • what is erp prototype

Related Posts: