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.

IT/Business Marriage Counseling

I agree with most of Susan Cramm‘s pieces, but she goes on a bit of a rant on the role of line managers in making IT’s life impossible (here).  While there is at least a grain of truth in her complaints, the IT “can’t do” attitude that infuriates line executives pervades the piece.

IT managers are tired of being treated like high priced waiters serving technology de jour on a moment’s notice.

Perhaps IT managers should stop acting like waiters and order takers for the business. It would be nice if IT wouldn’t “need to study” a request to deploy only somewhat new technology — e.g., Enterprise 2.0 — then come back and say “yes, but”.  Perhaps IT could anticipate what the business needed, for once?

Luke’s business “partners”… in their single-minded pursuit of customers, products and profit [emphasis mine],… simply forgot about IT.

If only IT knew what it’s like to have a single-minded pursuit of those pesky customers, products, and profit.  Not like that’s where their paychecks come from…

Alignment is meant to ensure that the right IT products and services are available to meet business needs with minimal angst for all involved [emphasis mine].

This definition/goal sounds good, but articulates a common IT mistake about defining alignment — avoiding conflict (“yes, but”).  Continue reading

IT Capability Checklist for non-IT leaders

I liked this checklist from Susan Cramm (article here, Word checklist here) because it’s targeted at managers who are rotating through IT.   Obviously, it is a critical rotation in industries where IT can be a differentiator.   But getting involved with — never mind leading — technology projects can be a bit daunting.

Leaders who have worked in these roles do so with a mixture of excitement and apprehension. On the positive side, the prospect of charting new territories is incredibly stimulating. On the negative, it’s also frustrating – navigating IT can be like traveling in a foreign country without an interpreter or a guidebook.

The aura of the dawn of the computer age persists in the software business.  Many IT professionals insist that what they do is beyond the ken of normal humans.  Not so… IT is amenable to rational analysis [unlike my blog].  Cramm says it perfectly here:

It doesn’t have to feel this way. IT is just like any other business function – challenged with developing and delivering products and services to demanding “customers” in the context of constrained resources and changing competitive, organizational and technological landscapes.

IT Project Failure — executives asleep at the wheel

Laurie Orlov from Forrester has a great post about how inattention dooms so many transformational projects (here).  From her piece:

[T]here are many good ways to reduce project risk. And there are also guidelines on how and when to kill failing projects.  No need to belabor them.  But trumping all of these, in my view, is the go-to-sleep attitude of enterprise executives (maybe even including the CIO) as these projects proceed….

CIOs who let business executives off the responsibility and oversight hook, if they let them send underlings to meetings, if they provide a status and get no feedback, if the scope of deliverables is intergallactic, if development is not iterative,… are aiding and abetting [t]heir own project failure….

My experience is that CIOs get distracted by “strategery” and forget to focus on the basic blocking and tackling of project and development management.  Per my comment on Laurie’s post, CIOs who aspire to strategic archetypes of IT management (Laurie’s Forrester study is here, behind a firewall) get distracted because:

  1. They’re acting out according to an archetype they want to be, not what is required.
  2. They have a disinterest in building a solid foundation in core functions, so they end up ignoring, then fire-fighting, problems with utility functions like e-mail, voice, etc.
  3. They believe game changing initiatives have to be big, so none of them question a multi-year timeline.

Every project becoming a program?

As suggested by “The Experience Trap” series I’ve been running, in the very near future, the skills and competencies to lead future initiatives will be those of a program and portfolio manager

I’m not sure that the way we approach methodology is helping.  As an example, my local PMI chapter is sponsoring a speaker on Adaptive Project Framework, a methodology that tries to square the circle between traditional and extreme PM approaches.  Per the invitation e-mail:

Those projects for which both the goal and the solution to reach it are clearly defined are well-supported by traditional project management (TPM) approaches. Those projects whose goal and solution are not clearly defined are well-supported by extreme project management (xPM) approaches. But what about those projects whose goal is clearly defined but whose solution is not? A new approach called Adaptive Project Framework (APF)…

But aren’t today’s complex projects more about the challenges of combining these approaches (rather than either/or)?  In other words, aren’t we first building or upgrading a platform (usually done w/ traditional “waterfall” approaches),  then attaching or layering components large and small on that platform (usually done w/ agile, iterative, or adaptive methods)?  This trend is happening across industries — aerospace w/ the A380 and B787, software w/the SAP Business Process Platform, Enterprise Services, and Custom Development, construction w/ more manufacturing and pre-assembly off-site. 

I’m afraid this signals the impending commoditization of PM — today’s project manager skills and competencies will only get you a team leader role tomorrow.

Reducing SAP implementation time/cost

A case study (here) and press release (here) about a quick, clean SAP Business All-In-One implementation at TomoTherapy.  What stands out about what worked?

  • Using SAP Best Practices as the baseline.  It makes it very easy when one can leverage a fully documented and functional prototype.
  • Using a partner willing to leverage SAP Best Practices.  It is instructive that two partners wanted to build from the ground up.  itelligence is an SAP Best Practices partner (see list here) — the case study is a little misleading about their role in SAP Best Practices — so they were able to bring speed to the table.
  • Splitting the Blueprint SOW from Execution SOW.  We are doing more and more T&M design SOWs, which is great way to get “everything on the table,” as TomoTherapy’s IT director stated.

An aside: it is funny to see that while implementation took only 16 weeks, but it took the PR machine 14 months to get out the word.

 

Staying in, Winning, and Changing the Game

Lot of travel lately — Walldorf, Singapore, and Bangalore back-to-back-to-back. 

I want to pick up a thread I dropped earlier, the idea that CIOs get too caught up in this idea that they have to be “strategic.”  For too many IT shops, this approach leads to several common mistakes:

  • Losing focus on the plumbing, thereby losing credibility to take on higher-order work.
  • Misinterpreting mere business alignment with strategic IT.
  • Wasting time on so-called strategic initiatives in an industry or process where IT has little leverage.

Looking at one’s IT capability and options as a portfolio helps manage this tension between operations and innovation.  One has to build a solid, repeatable process, which is even great for rote, commoditized operations.  Process can even promote systematic alignment with on-going, incremental business operations.

Differentiating one’s business activities — e.g., enabling the CSR that can up-sell based off of your buying, offer to change your service plan to save money, etc. — requires non-process techniques to emerge the individuals and interactions required.

Follow

Get every new post delivered to your Inbox.

Join 2,659 other followers

%d bloggers like this: