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.

%d bloggers like this: