May 17th, 2007

More on Simplification at SAP (Sapphire Vienna)

Posted by Michael Krigsman @ 1:16 pm

Categories: Implementation, Interview, Sapphire07

Tags: Michael Krigsman

A comment to this recent interview with Pascal Brosset got me thinking about implementation complexity. The commenter states: “Hopefully the simplification will reduce implementation projects to a more human scale, making success more likely and less expensive.” When Pascal refers to “prescriptive solutions”, I believe he is referring to exactly this: smaller, simpler software units that are faster and easier to implement (read: SOA).

The language of simplification with respect to implementation has been used inside SAP for more than ten years. For example, in the late-1990’s there was a team called the Simplification Group, based in Palo Alto and part of SAP Labs. Their mandate was defining methods and documentation to reduce custom configuration in the field, thereby reducing implementation time. In effect, AcceleratedSAP mirrored these exact same objectives. (By the way, the ASAP tools were developed by my company under a team working for me, so I have some experience here.) Aside from these efforts, SAP has also tried to address implementation complexity through what it calls SAP Best Practices. Each of these projects represented a major initiative involving teams of people, and this is only a partial list of SAP’s efforts over the last ten years to improve implementations.

So, is anything really new here? The fundamental implementation business problem remains unchanged: deploying enterprise software is slow, expensive, and risky (SAP and its competitors all share this). The depth and extent of the implementation challenge is evidenced by the fact that SAP and many other companies in the industry continue to invest in new tools, techniques, and methods for making deployment easier. Bottom line: despite years of effort, the basic problem remains. In fairness, however, the various tools and techniques developed over the years have helped the situation, although not nearly enough.

SAP believes that SOA is the best solution yet for simplifying enterprise software implementations (and thereby making this project failures blog obsolete, I must point out). In theory, it all sounds great — however, technology developers are always optimistic about their products. Nonetheless, it’s clear that SAP is investing substantial resources with the goal of reducing complexity.

On the other hand, if you are an SAP customer suffering through a problematic implementation, you may well be more interested in solutions that solve your problems TODAY.

—–

May 15th, 2007

"Custom Code Over My Dead Body" (Sapphire, Vienna)

Posted by Michael Krigsman @ 3:03 pm

Categories: Implementation, Sapphire07

Tags: Michael Krigsman

SAP is actively supporting a group of bloggers here at Sapphire in Vienna. Yesterday I engaged in a lengthy discussion between a half dozen bloggers and Pascal Brosset, Senior Vice President of Market Strategy for SAP.

The conversation was wide-ranging, with Pascal describing his overall goals and the mandate of his job. Fundamentally, Pascal is involved with helping SAP understand what customers will need and demand in the future. These anticipated customer requirements are used to guide SAP’s product strategy and the corresponding investment decisions required to build future products.

From the perspective of project success and failure, which is the focus of this blog, Pascal made a few important points:

• Simplification. The future holds smaller, increasingly well-defined products tailored to the needs of specific groups of companies and industries. The assumption here is that SAP software embodies a rich set of carefully-researched best practices, which the great majority of SAP customers will find very workable. These “prescriptive solutions” trade flexibility for simplicity, which SAP believes is in the best interests of it’s market. Basically, it’s the old 80/20 rule in action.
• “Custom code over my dead body.” Pascal believes strongly (I am definitely understating here) that SAP customers should virtually never write custom code. Custom code in a packaged solution creates a variety of evils, which taken together lead to cost and time over-runs downstream, aside from increased development costs and risks during the project. During the discussion of custom code, he asked the rhetorical question, “Would you customize your telephone?”. I understood this to mean that a well-defined solution, performing more or less as the user requires, should not need be redesigned by customers in the field. I do agree with this point, by the way.

Overall, my impression was quite positive. Much of what he said is logical, and corresponds to my own understanding of the real pains and experiences of customers. Clearly, Pascal is very serious about his mission and about charting a course that does the right thing for SAP customers.

Note to the naysayers: if all this sounds uncritically positive, well, I call it exactly as I see it.

Update 5/17/07: For more on the subject of simplification at SAP, see this posting: http://projectfailures.com/blog/2007/5/17/more-on-simplification-at-sap-sapphire-vienna.html