Blueprint? RDS don’t need no stinkin’ Blueprint

Strong SAP SDN post by Mark Chaffen on SAP RDS (Rapid Deployment Solutions) and the case of the missing Blueprint.   I’ve only started to dig in to the topic, so these are my (likely half-baked) first thoughts:

  • On balance “no Blueprint” is good.  Its exclusion reinforces that a RDS implementation is of a fixed, limited scope.  There must always be some sort of scope statement, of course, and its there.  Unfortunately, “Blueprint” seems to equal “everything and the kitchen sink” in some SI’s SAP glossaries!  Wise to make a clean break in the lexicon.
  • Avoid Death by Change Order.   RDS is designed to deliver only what one needs to execute — the wish list comes later.  Only fill in regulatory, statutory, or other compliance gaps during the initial implementation; otherwise make a conscious decision to remaining requirements into  backlogs that get burned down release-by-release. 
  • RDS still too “new solution” oriented.  There are other ways to expand a SAP footprint… how about RDS for acquisitions, divestitures, or other growth/transformation scenarios?

Using analogy to communicate complexity

Glen Alleman posts here on the need to ensure that analogies fit the domain.  He notes a common problem with metaphors, especially those adapted from math or science.  They sound right to the layman, but are off-key to the expert.

This insight provoked a few thought on analogies in the ERP world.  We often use analogies to convey the complexity of ERP: changing the engines on an in-flight 747 is very popular.  It sure sounds tough, doesn’t it?  And the image is powerful and vivid, but does it have anything to do with how ERP really works with your business?  Also, who has ever done something like that?

I’ve found that it is much more effective to leverage metaphors that are a bit more concrete.  For example, I’ve found that a conversation about ERP as “a model of your business that operates in real time” gets me down a better path.  We can then move on to concrete visualizations that model — from Tinker Toys, to Lincoln Logs, to K-Nex, to Lego, to Erector Sets, to HeathKits — that come from the participants, not from me.

Krigsman’s 2012 trends: three quick takes

The always valuable Michael Krigsman (@mkrigsman, IT failures blog here) weighs in with a 2012 prediction: that rapid implementation will get more sustained focus.  I believe that there has been considerable progress over the years in improving both ERP implementations and ERP sustainability (see here for a bit of the bad old days).  However, there’s room for further improvement, especially in achieving consistent success.  Here’s my quick take on the three initiatives Michael highlighted:

ERP isn’t still this scary

Glen Alleman passed along this link on the ERP paradox, which appears to be that:

the end result of ERP implementations is often the opposite: less control, and efficiency; and even though the number of applications may be reduced, this advantage is often offset by the cost and effort of maintaining ERP systems.

Unfortunately, the interesting commentary at the beginning of the post is compromised by a rotten foundation: much of the commentary relies upon a 10-year-old paper based on a SAP implementation that started in 1994.   A few comments:

  • Grafting process re-engineering on to a SAP implementation: Does anyone still buy that bill of goods?  Isn’t it the industry standard to assume that core SAP processes will be good-enough practice for processes that aren’t differentiating?
  • Homogeneity vs. heterogeneity:  Heterogeneous processes are valid when driven by hard factors (e.g., statutory, regulatory, compliance, logistical requirements ) and must be questioned when driven by soft factors (e.g., this is the way we’ve always done it).  There’s also an industry angle: for example, CPG go-to-market processes are hard to globalize because they vary based on market maturity and commercial customs.
  • 9-day Upgrade Downtime:  Wow, you’d have to work at that these days; perhaps if your upgrade strategy was to burn down the data center, restore from tapes, then upgrade, you might get there.

SAP SME Portfolio Précis

Yesterday, tossed Don Fornes’ post on SAP’s SME solutions over the Crossderry transom.  All-in-all it is a good overview, with a couple of caveats:

  1. Industry coverage of the SAP Business Suite and All-in-One is depicted as equal and that’s a stretch.  Perhaps I need to brush up on my SAP release strategy, but I recall that industry solution coverage for All-in-One is not nearly as extensive as that of the full Business Suite.
  2. I like that Don highlights the NPV calculations you need to make for on demand vs. on premise.  It is easy to forget that what looks cheap now ain’t so cheap after you’ve been paying for a few years.  However, he’s not clear what the $27,416 NPV represents.  It looks right per user (at $149/month and using his assumptions of a ten-year life for software and a 6% discount rate).

Podcast Link — Enterprise IT: Inside an SAP customer

Here’s the promised link — Enterprise IT: Inside an SAP customer — to my recent podcast w/ Michael Krigsman.  I’ll elaborate a bit on f these themes in future posts.  As I mentioned earlier, the interview stoked my blogging fire again!

SAP’s Sleeping Product Giant

Michael Krigsman and I had a chance to chat last week — he recorded a podcast w/ me that will be up on his blog before too long — and thankfully the chat got my blogging mojo going again. 

I don’t want to steal our podcast’s thunder, so I’ll focus on a tangent from our call — SAP’s innovation problem.  Michael himself has hoped that SAP’s leadership change would help to bring more innovation to market.  Ray Wang put it more bluntly in his take on Leo’s ouster:

[T]he issue is not sales. It’s products. Snabe and Vishal will need strong product vision to right SAP and point it in a forward direction. Engineering and products need more attention to bring out trapped innovation at SAP.

“Trapped innovation”… that’s so much of what I saw at SAP.  There are many cool technologies floating around, but they don’t fit in the “margin now” mindset that has pervaded the company.   The company is stuck in the classic [successful]  innovator’s dilemma:

By only pursuing “sustaining innovations” that perpetuate what has historically helped them succeed, companies unwittingly open the door to “disruptive innovations”.

Even worse,  SAP had deluded themselves into thinking they were responding appropriately — what was marketed as real innovation was simply new wine in old skins.  Exhibit 1 — 2007-2009 versions of Business ByDesign.

SAP’s product side is the problem

Dennis Byron here gives the most succinct gloss I’ve seen on the challenge before Hasso:

Hasso Plattner wants to drive a great deal of technological innovation at SAP, and did not believe it could happen under Leo’s leadership, and without Hasso’s very direct involvement…. The product organization is full of conflicting technologies, conflicting interests, and conflicting agendas. Driving change in this kind of climate will be very challenging for Jim [Snabe] and Vishal [Sikka].

Hasso stalks the product halls?

There’s one more challenge: SAP hasn’t been honest about what is working on the product side. BYD folks walked around like the cocks of the walk long after it was clear that BYD was in deep trouble.  And the leadership let them…

Hasso’s right: Leo couldn’t call BS on the product side effectively enough.  From what I can tell, he’s the only one left in SAP who can meld innovation with the market AND is credible and powerful enough to actually do it!

Unfortunately, I can imagine that many on the development time think that they’ve won and happy days are here again.  Hasso’s back and it’s innovation for innovation’s sake at SAP!  What…monetize?  Isn’t that what sales people are for?

Don’t bad mouth SAP project managers to me!

When I was a SAP engagement manager, many SAP customers used to complain to me about SAP’s project management capabilities with the lament:

If only you could manage projects as well as your implementation partners do!

I always thought that jab at SAP was hooey.  And now that I am a customer of two SAP implementation partners on SAP and non-SAP projects, I can confirm that it is hooey.  They struggle with “real” projects — where there isn’t a well-tested, industrialized implementation roadmap — at least as much as we did, if not more. 

I’ll repeat the offer I made to one of my past SAP PMO colleagues: if you hear anyone make the claim above, I’ll set them straight.

Why SAP ramp-ups are hard to get into

Ramp-up interview in progress

Ramp-up interview in progress

Another note from the Dave Rosenberg post on cloud services (Dave’s post here)  inked to in my last post on software engineering (my post here).  I was often asked why SAP made it so hard to enter ramp-ups for new or upgraded solutions.  The answer is pretty simple and Dave put the reason succinctly in his post:

… it’s important to know what you are getting into if you want to use these [cloud] services now. As with any nascent technology, early adopters will benefit in some ways and suffer in others (emphasis mine).

It still surprises me how many technology professionals are themselves surprised that new solutions aren’t risk-free.   SAP wanted to make sure that ramp-up customers understood that, in the enterprise space especially, there is no way to test all the data constellations and system modifications a new solution will come up against. In fact, that’s one of the benefits of going into ramp-up: your bugs get worked first.

%d bloggers like this: