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.

A good upgrade “why to” list

Regular Crossderry readers know I’m partial to ERP upgrade tips and advice (here, here, here, and here).  This list by Beth Stackpole stood out as one of the more practical and insightful “Why to upgrade” lists around.  In particular, point four is often overlooked.

  1. Upgrade an ERP system that’s more than five years old.
  2. Upgrade when ERP system integration is difficult.
  3. Upgrade when an ERP system is missing the “modern” features and functions required to efficiently run the business.
  4. Upgrade when employees, partners and consultants aren’t using the system — or aren’t available to fix it.
  5. Upgrade when it’s obviously time, whether the hard upgrade ROI is clear or not.

As they say… read the whole post.

Obscure SAP Tools — Upgrade Dependency Analyzer

In previous posts (here and here), I’ve lamented that too many customers and partners don’t know about some great SAP tools.  Of course, sometimes SAP does a good job of hiding them in plain sight.  Regardless of fault, it’s too bad that these tools languish unused on the SAP Support Portal  (registration required if you haven’t already done so).

To do my part to remedy this, I present the SAP Upgrade Dependency Analyzer.  The use case is straightforward: when planning an upgrade of the systems in an SAP system landscape, customers want to know whether the update has an impact on other systems in their landscape.  Such impact might require additional changes.

While it is quite new, I expect it to become an invaluable tool when setting and planning upgrade projects’ scope.

SAP Upgrade Resources —

Back in the day I did quite a bit of work on planning, managing, and executing SAP upgrades.  This article by Michael Doane — the “from 4.2 to ECC 6.0” head-scratcher notwithstanding — lays out some good considerations for how and when to think about consulting vs. support services.

As I’ve pointed out in previous posts, SAP generates tons of content and tools that don’t get enough time, attention, and use.  On the upgrade topic, I’d like to point folks to (registration required if you haven’t already done so).  The SAP Upgrade Roadmap page (here) is a great place to start to dig in…

Upgrade tips…what’s worse than a modification?

I was going through a list of upgrade tip articles collected by Demir Barlas (here) in his SAP Watch blog (here).  Most of them look unobjectionable, but one touches on a pet peeve.  Amit Jain calls them out here (original SDN post here):

6) Cloned programs — Cloned programs are customer programs copied from standard programs… [they] are coded by copying the standard program to a Z-program, having the standard includes or standard function modules.  This causes issues after the upgrade, because the standard includes or functional modules might not work with our custom code.

Clones are insidious, because developers don’t think they’re system modifications.  They’re right: they’re worse than system modifications.  I’ve never heard a compelling case for cloning.  Directly modifying the standard program — while not exactly encouraged by SAP — is a more straightforward and honest approach:

  1. There’s no more pretending that a clone isn’t a modification.   Taking standard code, modifying it, tacking on a “Z” to the name, then claiming it isn’t a modification seems disingenous.
  2. Clones hide from SAP monitoring and other system features.  In an upgrade, SPAU has features that attempt to account for mods when updating the code base.  It is much simpler to deal with mods in SPAU than by searching through the new SAP program.
  3. Clones create non-value added work.  For example, all of the dependencies to/from the cloned program have to be re-established manually during an upgrade.  Never mind the manual bookkeeping involved…

Cheering up a gloomy project or initiative

Mike Yanagita

I’m curious whether folks have any good stories about humor…I’ve found that a little bit of insanity always helps keep a project or an initiative fun (or at least bearable).  Also, showing that I can laugh at myself is a great way to loosen up the team.

I was on a busy team supporting the wave of SAP R/3 4.6C upgrades back in 2000-2001.  One of our main sources of amusement was reciting dialogue from Fargo, especially from the character Mike Yanagita.  If you’ve been a road warrior you’ll relate to many of his lines:

  • I shouldn’t have done this.  I shouldn’t have done this.  I shouldn’t…
  • I’ve been so lonely.
  • You know, it’s a Radisson, so it’s pretty good. Yah.

"King" Gator

I was reminded of the importance of humor as I amused my son with my rendition of Ken Page’s showstopper “Let’s Make Music Together” from All Dogs Go to Heaven.   Singing King Gator’s part sends him into stitches, given my secret talent for mimicing camp characters and singing Ethel Merman’s signature tunes.  And the difference is.. ?

You’ll know it’s a tough project if I convene a karaoke party and belt out “There’s No Business Like Show Business!

SAP ERP Upgrade Surge

Eric Samuels at the SAP Watch blog has an interview with Steve Strout, the new ASUG CEO (here).  This post focuses on the recent surge in upgrades in process or completed (the SAP press release is here).  A couple of key quotes:

First, it’s an extremely stable release. People are able to do a technical upgrade without much hassle. I know of people who have eliminated upwards of 70% of their custom code just by moving to this release. I also think SAP has done a tremendous job of making the migration a relatively easy one. I know that when I went from 4.6c to 6.0, it was a pretty straight forward process and we didn’t find any real surprises.

SAP has worked diligently on easing upgrade hassles and reducing downtime for years (full disclosure, I was part of the Upgrade Competence Center back in the day and I’ve led three major upgrades).  We also have continually updated our ASAP for Upgrades roadmap (you’ll need to be registered in Service Marketplace to access the upgrade roadmap entry page here, online version here).

In addition…they will start taking advantage of Service Oriented Architecture and expose access to their SAP environment and create new ways of taking out steps of a business process – thus reducing their overall costs. We are starting to see people use SOA technologies to innovate and create new ways for their business to do all new things. And this innovation can’t occur at the same price point with the older technology.

Yup…Enterprise SOA is coming and our customers are putting in the business process platform to support it.

%d bloggers like this: