The SAP/Oracle Choice re: Integration

With the release of SAP Business Suite 7, the debate about the SAP and Oracle integration strategies has heated up.  Loraine Lawson at IT Business Edge (here) uses two posts by Ray Wang (here) and Dan Woods (here), to contrast the two approaches.

Of course, I agree with Lawson and Woods that the SAP approach is better :-).  I also agree that the Forbes audience — C- or high-level business folks — will eat up the SAP message.  However, IMO, it isn’t quite so simple.  Per a paragraph from Woods’s Forbes piece.

Companies implementing new applications or consolidating many companies must ask which foundation is best: a productized and unified platform for business automation or a collection of products that needs to be integrated. Best-of-breed is another way of saying that the user, not the vendor, is responsible for integration [emphasis mine]. 

My experience is that some firms and industries like to have that responsibility and chafe at having processes “pre-integrated.”  Again, I don’t think that is a great default position — one ends up automating non-differentiating processes nearly from scratch — but many pharma and financial firms in particular have tried to “grow their own.”  It is a legitimate strategy if you are truly creating competitive advantage via custom development and integration.

What SAP has done with the Business Suite and its business process platform strategy is to accommodate that desire to be different.  Enterprise SOA allows such customers to get the benefits of process integration without forgoing the capability to differentiate (by assembling or building enterprise services on top of the platform).

Is this really a tech vendor secrecy problem?

I know, I know…I’ve been remiss on posting.  All I have are very lame excuses that I won’t give.

Just saw this article “Global CIO: Tech Vendors’ Secrecy Hinders Innovation” and I’m still not sure what to make of it.  Perhaps we can blame the copy editor for the headline, because the author raises some issues that I don’t think have much to do with secrecy (at least not in the case of SAP):

1. Mobile devices:  I don’t get the secrecy angle here at all.  The author assumes that enterprise SW vendors have “somehow managed to miss out so far on a pretty big opportunity here — I mean, it’s not as if the smartphone market just sneaked up on everyone.”   But this argument begs the question of the “big opportunity”: for whom is it a big opportunity? Is there really more-than-incremental revenue for the SW vendor? How many solutions really need mobile, or at least more mobile than having e-mail/workflow alerts pushed and granting application access via mobile device’s web browsers?
2. SAP Business ByDesign: Here “secrecy” sounds more plausible, but I believe the answer is simple.  We’ve been pretty clear that we need to get SAP Business ByDesign to a certain cost/user point before we can scale up fully.  The year-end scramble due to the financial crisis can’t have helped matters.  Perhaps that solution’s roadmap could be clearer, but my take is that our approach has less to do with secrecy and more to do with an abundance of caution about issues we’ve acknowledged. 

Using SCRUM with ASAP

Ron Stanton sent me a mail asking how SCRUM works with our implementation methodology — ASAP for Implementation. While SAP does have a SCRUM methodology that we use — SAPScrum — it is an internal approach used for solution development.  SAPScrum is pretty straight SCRUM, so there’s no mystery to it.

We just started a project to make ASAP more agile-friendly, we’re a little ways from publishing it. For now, below are a few general guidelines in using SCRUM in an ASAP environment.

1. The first principle is to remember that the SAP solution(s) serves as the development platform or environment. It isn’t simply an application to which you’re integrating.
2. Of course, a product backlog should be one of the outputs of the Blueprint phase. The product backlog should be mapped to the processes here (as part of identifying testing scenarios).
3. Appropriate prioritization of the backlog is critical in an SAP environment. In particular, non-technical product owners often forget to include integration dependencies as one of the prioritization criteria.
4. Sprints need to synch with the various ASAP configuration/testing cycles (e.g., unit test, string test, etc) for the overall solution.
5. It is critical to ensure that custom development sprints are scheduled so that the sprint output delivers to the relevant testing cycle.
6. Most ASAP config/testing cycles are typically 2-4 weeks long, so one sprint:one config/test cycle is reasonable. If the project is especially large — with longer config/test cycles — then consider nesting sprints within those longer cycles.

BI, Deliverables, and Change Control

This post may court the Business Week curse, but I’m highlighting this story on BI and the recession (here) as the jumping off point for a couple of observations.  Rob T.’s comment in the piece (sorry, but I can’t link directly) notes that:

Unlike ERP, BI can be implemented step-wise, first in targeted, strategic areas, and then using a broad brush once it’s value has been proven. A wise strategy for this economy is to start small, pick a problem or area where a quick win is possible and attack it with a 60-90 day effort.

I mentioned this opportunity for short, focused projects in my WSJ interview.  These short cycle times and the nature of BI work pose problems for traditional ERP change control and deliverables definition. 

For example. what exactly is “done” on a BI project?  The traditional ERP definition of deliverables — focused on processes that deliver tangible, measureable outcomes (e.g., Order to Cash, Purchase to Pay, Hire to Retire) — doesn’t work well for BI.  Typically, reporting projects focused on # of reports, explicitly defined.  Also, in analytics projects those reports or queries often spark more ideas for how data can be cross-tabbed, projected, etc.  Do you always want to be presenting a change orders for new reports?

What has worked for you when defining deliverables and change control for BI initiatives?  Now if you’ve read this blog for a while, then you can guess that I’m in tune attacking these issues with a capabilities-focused approach to deliverables.  This approach points one in the right direction when defining what done looks like.  However, many PMs find it hard to grok the requirements and required capabilities of analytics-savvy stakeholders and consultants.

SAP PMO Webcast Recording

As a follow up, over 250 people attended last week’s SAP PMO webcast (original post here) hosted by Keith Johnson, the VP for the SAP North America PMO VP and Jim Curry, Program Delivery Director.  It’s always great to have a customer — in this case, Kelly Gear, Senior Program Manager, Johns Manville — confirm the value of some of what SAP offers and suggests.

Considering what we’ve been discussing here and here about goals, deliverables, and activities, this topic from the webcast caught my eye:

How to establish the critical link between the steering committee’s goals and the project team’s activities.

The recording is available here — you will need to do a free registration if you don’t have a SAP.com login already.

Surviving PMO Success — Establish an innovation model

During my keynote on “Lessons from a Mature PMO on Sustaining Success”, I spent a considerable amount of time discussing one of the pitfalls of success: becoming satisfied with what was already in place. For example, some global PMO services stopped evolving and improving. Our regions felt like they had to build their own improvements — even worse, we didn’t have a mechanism for leveraging these innovations.

Luckily, we did a some working models that we were able to formalize. Below is a graphic — with a link to a PDF — that outlines the basic concept and an example (WBS templates).

SAP Solution Manager to document your SAP solution

One of the most important — but underused — features of SAP Solution Manager is the ability to document SAP solutions and the processes enabled by the solutions. It seems like a no-brainer to have documentation and configuration together in one system, including for partner components, custom code and interfaces.

As part of the SAP Solution Manager series I referenced earlier (here), Evan Stoddard has an extensive recorded session on the topic (here).  Note that the recording is >250MB so ensure you have plenty of bandwidth before downloading.

SAP Solution Manager Enterprise Edition — Broadcast Series

If you’re in the SAP ecosystem, you’ve probably heard about the new capabilities that SAP Solution Manager Enterprise Edition delivers.   The product management team for SAP Solution Manager will offer a series of virtual presentations ranging from an overview down to the Expert Guided Implementation service for SAP Solution Manager.  These sessions are available on demand in the SAP Service Marketplace at http://www.service.sap.com/enterpriseedition (Service Marketplace registration required).

The series began on Feb. 12, 2009 with a session by Dr. Mattias Melich (session here, note this is a ~70 MB download so watch the bandwidth!).  Mattias provides a overview of SAP Solution Manager Enterprise Edition and its positioning.

Building an SAP PMO — Webcast

Keith Johnson — the VP of SAP’s North America PMO — hosts a webcast on Achieving Operational Excellence Through a Project Management Office.  The webcast is free, though you’ll have to register in advance (registration form here).  Registrants will receive a complimentary copy of the SAP Consulting Solution Brief: Program and Project Management Services.  Here’s a little more on the webcast:

[Y]ou’ll discover how a well-structured PMO can help ensure the success of your next project – whether it’s a new implementation, an upgrade, or a rollout of new functionality. For example, you’ll discover:

• How to leverage a PMO to achieve operational excellence
• How to establish the critical link between the steering committee’s goals and the project team’s activities

In addition, Keith will be joined by an SAP customer — Johns Manville — which will discuss how it has leveraged its PMO to reduce costs, lower risks, and focus on proven methodologies.

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).