SAP Maintenance and the Sol Man (I)

October 22, 2009

With Siemens asking for and apparently getting a huge break on SAP maintenance costs, it is time to take a look once again to take a look at the whole issue. Understandably, there is a lot of emotion and name-calling and confusion around this; it’s not quite the health-care debate here in the United States, but the real issues have been buried under rhetoric in a strikingly similar way.

SAP Charges for Improved Support

Let me first state SAP’s position as sympathetically as possible. SAP believes (quite correctly) that the customer’s TCO (total cost of ownership) ought to go down, as software and hardware gets better and cheaper. It also believes that if it does something that would help TCO go down, it should get a share of the benefits.

Who would disagree with either point?

Roughly two years ago, therefore, it introduced a series of software and support improvements that it believed would indeed reduce TCO. These improvements largely revolved around a newly improved version of the Solution Manager, a piece of software that is supposed to do what its name implies.

The Solution Manager (or Sol Man, as it is called familiarly) was actually introduced roughly ten years ago. In its original version, it was a separate piece of software (one that ran on its own Windows box) that one used to communicate with SAP support (filing bug reports, etc.) and to monitor the performance of your SAP installation.

In the version introduced two years ago, the Sol Man EE (or enterprise edition), it did considerably more: it allowed you to do more extensive monitoring, test and manage upgrades, and even document your business processes. This new edition also beefed up the connectivity with SAP Support, so that support could use it to troubleshoot your installation more rapidly and effectively.

When SAP introduced its new, higher-priced Enterprise Edition support package, it placed the Solution Manager EE front and center. In every speech and every press release, it wasn’t, “We’re raising prices because Oracle got away with it.” It was, “We’ve developed new tools and support services based on those tools, and we’re increasing the cost of maintenance, because the maintenance has improved.”

The tools it was referring to were the various components of the Sol Man EE, and the improved support services were made possible by and delivered through the Sol Man.

To sum up, SAP’s position is that it is improving enterprise support by providing customers with new and better support tools. It is in the software business. So it is only reasonable for it to charge for those tools. That it charges via a maintenance price increase rather than by charging for the product itself is reasonable, presumably, because many of the benefits involve improved services, which are provided through the maintenance contract.

The Customer Reaction

It’s just a plain fact, of course, that nobody paid much attention to this. It took me, for instance, almost a year (until John Krakowski’s excellent presentation at ASUG last May) to figure out what SAP was getting at when it talked about new tools. (Before that, I wrongly, but honestly believed that the talk about tools was pure hand-waving.)

Other commentators on this, like Vinnie Mirchandani or Ray Wang or Dennis Howlett , may have gotten to a proper understanding of the argument faster than I did, but for the most part, they didn’t try to address its merits.

Today, for instance, the Enterprise Advocates, gave a webinar on Reducing SAP Maintenance Costs. (The Enterprise Advocates include the aforementioned three, plus Frank Scavo and Oliver Marks.) Not once during the main body of the talk did they even mention SAP’s recommendation for reducing maintenance support costs, which is to implement the Solution Manager and use it.

I don’t blame the advocates for this; it’s not their job. But I do blame SAP. If the Sol Man is what justifies the price increase, then SAP need to explain this in clear language.

Once SAP fails to do this, the Advocates and the SAP customer base are entitled to believe what you and I would believe when somebody offers an unclear explanation for something that seems to require some explanation: they dismiss the explanation that’s offered.

At some point, though, it does seem that someone should give SAP the benefit of the doubt and ask the question that SAP wants you to ask, namely, “Can the Sol Man EE deliver so much benefit that it justifies the maintenance price increase?”

If the answer is, “Yes,” that would of course be the best thing all around. Customers would have a clear path to reducing maintenance costs. SAP would have a product that keeps its customers paying maintenance. Total cost of ownership would go down.

And the Answer Is…?

Over the past four months, I’ve spent a fair amount of time finding out what I could about the Sol Man. I don’t have access to the documentation (all 1000 pages of it), but I do have the more public documents that SAP has issued, and I have talked to a number of Sol Man users and consultants.

What I found out is so complicated, and this blog is already too long. So I’ll delay a full report to another post. But here’s the answer in a nutshell:

1. To get the benefits of the Sol Man absolutely requires significant investment on the part of the customer.

2. It does not appear to be the case that the Sol Man was designed with the goal that SAP now has for it top of mind. It appears to be a product that was designed to be one thing that is now being turned to a different purpose.

3. The areas of benefit that the Sol Man promises are indeed important, and it is at least possible that customers can get significant benefit from it, if they put in the work.

4. At the end of the day, though, it appears to this humble observer that SAP needs to put more skin in the game.

Hope all this whets your appetite for the next post on the subject.

Advertisement

8 Responses to “SAP Maintenance and the Sol Man (I)”


  1. […] after the webinar, David Dobrin wrote a thoughtful piece on Solution Manager (SolMan as we usually call it.) The webinar didn’t give SolMan a lot of attention except to […]


  2. “SAP believes (quite correctly) that the customer’s TCO (total cost of ownership) ought to go down, as software and hardware gets better and cheaper.”

    David, you heard me present on the SAP “surround” costs in the webinar yesterday – SIs, infrastructure, apps management offshore, upgrades.You saw example after example of waste in SI fees and travel, and little productivity even after tens of thousands of implementations. You saw my comparisons of today’s SAP infrastructure compared to cloud metric and with less stringent SLAs, you saw areas where offshore firms have learned the same tricks as their US colleagues.

    Where is SAP in all this? Why has it not taken more responsibility for TCO management? You could argue clouds and offshore are more recent areas of focus and SAP is still learning (not an ideal situation, but somewhat understandable) but SIs? How long have you, I and others warned SAP?

    On SolMan, if the justification is it makes testing lower during an upgrade that’s pretty darned weak – I am not hearing in field, audit folks saying reduce your regression or other testing becasue of SolMan. And even if it was, how do to justify paying 22% every year to get a productivity improvement in an upgrade itself with questionable ROI? Especially when in contrast SaaS vendors are showing painless, in background upgrades with downtime only a few minutes, certainly not long weekends. And no spike in fees to justify that perk.

  3. toppundit Says:

    Does SAP believe that TCO should go down? Vinnie, you’ve been following this company for as long as I have, and I’m sure you remember the many, many keynotes and meetings with analysts where SAP said, basically, “Our strategy for IT in the 21st Century is to keep reducing the cost of IT and take a share of the savings.” They’ve made this commitment over and over again.

    The real question is, “Have they done what they committed to doing?” You make a really good case that they haven’t. An unassailable case given the facts that we know.

    So what are we to make of this? At the very least, SAP has a problem on its hands. Maybe the problem is that they, er, are not the sort of company that makes good on its public commitments. If so, that’s one sort of thing–and not exactly unusual in the software business.

    Or maybe the problem is that they disagree with you (and me). Maybe they think they have made good on those commitments. This would be good, in one sense; at least we wouldn’t feel like running around muttering something about pants on fire.

    But it, too, is troubling. If they really think that Sol Man is already providing benefits on a scale that would justify a price increase, either they are more confused than I’d like any software company to be or they think so poorly of you and of me and of the customer that they don’t think it’s worth the bother to make the case for what they believe.

    If there is such a case, I think it’s time for them to trot it out. And if there isn’t–that is, if the points you make are right–then maybe it’s time for them to admit that they’ve gone wrong and this time make a commitment that everybody will see they can keep.


  4. Social comments and analytics for this post…

    This post was mentioned on Twitter by toppundit: @dealarchitect Is SAP really committed to reducing the TCO of installations? Posted a response to your reply. http://bit.ly/4ytyfq


  5. Well, David, I agree that SAP basically had the right idea with SolMan which is to use technology to ease the chores of maintenance. But there are a number of fundamental issues with the way this was done. A big one is the lack of backward compatibility. Another one is that SolMan is complicated: I recently got a 500 page book on the enterprise edition. Among the authors are no less than 11 product managers. In the past, when projects loke OS/360 were done, such an approach was called “million monkey approach” or “Vietnamization”.
    But let us assume for a moment that SolMan were the perfect product cutting the customer side of applying support by 50% or more. At this time, when even SAP experts can become redundant, many a competence center hero would rather prefer to discount the merits of SolMan to being laid off. As it turns out, SAP made SolMan sufficiently complicated and hence contributed to job security. If I had to suggest something to SAP, I’d say (once again) “put SolMan into the public domain – make it open source”. That should do wonders.


  6. […] and as a counterpoint to David Dobrin’s analysis of Solution Manager, I spent time with one of Walldorf people working on SolMan and saw a canned demo. Note: canned. […]

  7. Tony de Thomasis Says:

    David

    We spoke briefly at the SAP Influence Summit in Boston late last year.

    Just a short note to tell you that I will be blogging about the 10 easiest pieces of functionality to deploy as part of a SolMan deployment geared toward cutting support costs.

    These blogs are based on the way we organised the SolMan roll out at Australia Post on a sensible budget. http://www.sdn.sap.com/irj/sdn/alm.

    I look forward to your valued comments, Tony.


  8. […] that time, David Dobrin wrote an interesting piece on Sol Man (as it is more affectionately known) arguing that: 1. To get the benefits of the Sol Man absolutely […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: