SAP Business Suite 7.0 — life w/out upgrades?

I haven’t a chance to dig into the details of SAP Business Suite 7, but it looks very promising w/r/t implementation costs and other TCO drivers. The enhancement package approach was a great start, but the new Business Suite should be a more comprehensive breaking of “the upgrade barrier” (per Ed Toben of Colgate-Palmolive).

Here are a couple of videos on the new suite: Jim Hagemann Snabe on the strategy (here) and a SAP Business Suite 7 demo (here).

New Leader Focus Area — Creatively Wielding Occam’s Razor

I’m wrapping up this first series about what goes into taking over a new organization (earlier posts (herehere, here, and here).  The theme of simplicity and parsimony gets mangled during many discussions; for example, sometimes people think that “simple = easy”.    Also, that old simplicity maxim — Occam’s Razor — focuses on analysis to the exclusion of creation (BTW, it wasn’t given its modern form by William of Ockham himself). 

Ockham’s own phrase Frustra fit per plura quod potest fieri per pauciora [It is futile to do with more things that which can be done with fewer] better expresses the essence of elegant design.  Notice the shift from “explain” to “do”?  With Ockham’s words in mind, let’s consider these HBR New Leader leading questions about complexity:

  • How complex are your product or service offerings, and what is that degree of complexity costing you?
  • Where is your innovation fulcrum?
  • What are the few critical ways your products stand out in customers’ minds?
  • How complex is your decision making and organization relative to competitors’?
  • What is the impact of this complexity?
  • Where does complexity reside in your processes?
  • What is that costing you?

Still looking down in checklists?

Just saw this article of the power of checklists in medicine (here) which reminded me that I had forgotten to include a link in an earlier post (here).  Atul Gawande wrote a long piece in the New Yorker a little more than a year ago simply entitled “The Checklist“.  It is far too rich to summarize effectively — please read the whole article — but below are a few snippets

[I]t’s far from obvious that something as simple as a checklist could be of much help in medical care. Sick people are phenomenally more various than airplanes… Mapping out the proper steps for each is not possible, and physicians have been skeptical that a piece of paper with a bunch of little boxes would improve matters much.

In 2001, though, a critical-care specialist at Johns Hopkins Hospital named Peter Pronovost decided to give it a try. He didn’t attempt to make the checklist cover everything; he designed it to tackle just one problem, the one that nearly killed Anthony DeFilippo: line infections…. These steps are no-brainers; they have been known and taught for years. So it seemed silly to make a checklist just for them. Still… [i]n more than a third of patients, [doctors] skipped at least one. 

The results were so dramatic that they weren’t sure whether to believe them: the ten-day line-infection rate went from eleven per cent to zero. So they followed patients for fifteen more months. Only two line infections occurred during the entire period. They calculated that, in this one hospital, the checklist had prevented forty-three infections and eight deaths, and saved two million dollars in costs.

Still think your project is too complicated to benefit from a checklist or two?

The deeper current of Darwin’s thought

When people think of Charles Darwin, they first think of evolution.  But as Matt Ridley notes in this excellent The Spectator piece (here), there are currents of Darwin’s thought that flow on almost unrecognized:

Charles Darwin, who was born 200 years ago next month, has spent the 150 years since he published The Origin of Species fighting for the idea of common descent…  But in some ways it is less radical and topical than his other, more philosophical legacy: that order can generate itself, that the living world is a ‘bottom-up’ place.

As regular readers know, I’m skeptical of the way many technologists don the cloak of “innovator”, or “revolutionary”, or “pathfinder” (here and here).   The role of innovators is humbler in Darwin’s world:

Every technology has traceable ancestry; ‘to create is to recombine’ said the geneticist François Jacob. The first motor car was once described by the historian L.T.C. Rolt as ‘sired by the bicycle out of the horse carriage’. Just like living systems, technologies experience mutation (such as the invention of the spinning jenny), reproduction (the rapid mechanisation of the cotton industry as manufacturers copied each others’ machines), sex (Samuel Crompton’s combination of water frame and jenny to make a ‘mule’), competition (different designs competing in the early cotton mills), extinction (the spinning jenny was obsolete by 1800), and increasing complexity (modern cotton mills are electrified and computerised).

It’s a nice bit of irony that so many of these self-styled technology revolutionaries — who often believe their innovations had no precedents — are at heart believers in theories like spontaneous generation or intelligent design.  Not the company they would imagine themselves keeping, eh?

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.

PM Quote of the Day — Vince Lombardi

Practice does not make perfect. Only perfect practice makes perfect.

When I was younger, I never got the point of practice.  Sure, I knew that it would get me in shape and knock of the rust off.  However, I never got the idea that practice would help me perform better under pressure.  Too many times I found myself over-thinking a situation because I hadn’t practiced enough to make it automatic.  I finally started to realize that realistic practice in all sorts of endeavors — in particular, public speaking and presenting — helped to take the edge off along with the rust.

Practice?...  Youre talkin about practice?

Practice?... We're talkin' about practice?

Lombardi’s point also applies to how we test our processes and systems.  Too often I’ve seen customers and consultants assume away difficulties in their desire to save testing time and money.  Even worse, this saving “spasm” usually comes towards the end of the project, just as the testing was about to get serious.

The best testing practice (so to speak) I’ve seen came at a global firm that does dirty and dangerous work.  As you might imagine, that company is very conscious of safety and quality.  That firm called their last round of testing not integration or user acceptance, but “business simulation.”  Business simulation didn’t simply involve folks following a script.  We brought the system, interfaces, and data up like go-live, then encouraged the users to go “do their jobs” and call support if something went wrong.

Sure, such an approach is expensive.  But how much is that peace of mind that comes with a no-holds-barred validation that the system and its support conformed to requirements worth?

Obscure SAP Tools — Release Strategy Documents

I’ve always been surprised how many customers and partners aren’t aware of SAP’s Release Strategy documents (main topic page here).  These documents cover the availability of new SAP releases, the length and conditions of their maintenance, and the dependencies among individual releases.  Below are links to the three main documents (actually, the pre-2005 material is a re-formatted hierarchy of the original documents):

SAP’s Release Strategy for Large Enterprises
Explains in detail SAP’s simplified release strategy based on a stable core approach for SAP core applications, delivery of new functionality via optional enhancement packages, as well as related complementary offerings.

SAP’s Release Strategy for Small Businesses and Midsize Companies
Presents the solution portfolio for small businesses and midsize companies (little-known fact: ~ 70% of SAP customers are small businesses and midsize companies). This document focuses on the SAP Business One application, the SAP Business All-in-One solution, and the SAP Business ByDesign on-demand solution.

SAP’s Release Strategy for all Shipments up to 2005
In the past, SAP’s release and maintenance strategy was more component-oriented than application-oriented.  The former versions of the brochure “SAP’s Release Strategy” are available for customers who are still running SAP applications and components released before 2005.

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.

SOA and Project Management

We’ve discussed the impact of enterprise services and Enterprise SOA on a number of occasions (in many of the links collected here and here especially).  My focus has been on complexity and how Enterprise SOA is part of the transition where “every project becomes a program”.

One of the little discussed impacts — on project managers, that is — is the increased interaction among business process experts, business users, and technical teams.  Demir Barlas has a link rich post on the SOA in SAP topic here.  I had seen some of these links before (Dennis’s post in Demir’s quote below), but Demir has pulled together other good links that serve as primers on the topic.

The impact of SOA on project management practices is alluded to in Demir’s last full paragraph:

Finally, because SOA is right at the heart of both business processes and enterprise applications, it brings together what you might call the suits and the geeks. SOA is making these disparate communities speak each other’s languages, as you can discover on SAP’s BPX forum.

In particular, project managers must dedicate more attention to their stakeholder management practices.  Many of these stakeholder groups are new to SAP projects.  As Demir notes, they don’t speak the same language.  Business and transactional users also have very different expectations about how the project should engage their time and attention.

Before you manage your next SAP Enterprise SOA project, take a few minutes to poke around on SDN and BPX to get a feel for the discussions.

PM Quote of the Day — George S. Patton

A good plan, violently executed now, is better than a perfect plan next week.

This quote is an nice appropriate bookend to yesterday’s Eliot quote (here).  Most SAP projects have to be delivered within a tight time window within strict resource constraints.  With two legs of the triple constraint almost fixed — and we can’t compromise on quality with mission-critical applications — our scope planning and prioritization must be ruthless. 

While it is important to have patience with ourselves and others, dithering about features and functions doesn’t work in today’s project environment.  To slip in another quote: Say what you’ll do, do what you say… and don’t look back.

%d bloggers like this: