If SAP consultants would build cars

Yesterday, during a coffee break, I had an interesting conversation with a colleague consultant from "the other planet". Now, I am from planet Earth of course. I make sound and earthly design decisions when it comes to designing software systems for "the business" (who happen to live on Mount Olympus). Not knowing any better, I approach the business' demands with the methodologies I was taught and with the skills I have acquired over the years. The process "consultants of my kind" follow is roughly like this:

1. Help the business understand their main problem and what they really need: translate their demands (which are often features like: a blue casing, a multi-touch UI or a "stealth mode" button) to actual needs. The result should be a set of bare necessities that current (legacy) systems are not fulfilling or can no longer fulfill (in case of systems near their end of life).
   
2. Make a logical design of the system that fulfills these needs (resulting in a selection of pictures that show stick figures holding balloons and rectangular shapes with arrows).
3. Make a physical design of the system. The result of this step should be at least one technical solution, but preferably a number of technical solutions for the problem we helped the business understand in step 1. Such a solution usually is a composition of legacy systems and new technologies. An exciting but also very time consuming part of this step is the selection of the new technologies, which can lead to miniature religious wars within the IT department.
   
4. Realize the solution that you managed to convince the business of picking. The new system is built from the ground up over a period that roughly varies between 1 month and 4 years. Ideally, the business is involved in this process so we end up with a system that it indeed needs and can actually use.
   

If this were applied to car manufacturing, the resulting car wouldn't look at all like the initial designs (step 2 and 3). Somehow, the multi-touch UI and the stealth mode button come standard with the car, but several bare necessities migrated to optional features that will cost you extra. The car is everything you desire but not exactly what you need (car sellers heavily depend on that). Once in your possession you will boast about your car's specifications (engine type and horse power, top speed, number of airbags, built-in stereo wattage, interior design details, et cetera) because they matter a lot to you. Your car certainly isn't a mere transportation device, it is a fashion statement and a way of life!

Okay, this is slightly exaggerated, but more or less true (I may have been watching too many episodes of Top Gear).

In my conversation with the extra-terrestrial colleague from the planet SAP, we embarked on all this. Every large enterprise either has an SAP-based system or an Oracle-based system for managing enterprisy things such as enterprise resources (ERP), customer relations (CRM) and the supply chain (SCM). That means that the consultants of my kind working for a large enterprise will eventually deal with an SAP consultant during the process I sketched above. An SAP consultant approaches a business' demands from a completely different direction:

1. Determine the industry (e.g. insurance, health care, banking, retail, utilities, ...) that the business requesting the service of the SAP consultant, belongs to. 
2. Make a single, authoritative, SAP-specific design that is entirely in shades of blue (it is even called "blueprint")
   
3. Compose an industry tailored SAP package that exactly fulfills the business' bare necessities.
   
4. Advice the business to buy this package and to make no (if possible) or only minimal customizations. Use it as it is.
5. Implement the SAP packaged composed in step 3. This takes between 9 and 18 months on average, although there are cases known where it took just 45 days, but also 10 years. The result is a system that already does about 80% of what you need out of the box. One trick in achieving 100% is in making the business in question see that they are not a special case in their industry, and that their specific needs are not really necessary. In the end, these business will customize their SAP system to approach the 100% need coverage.
   

Now, let's return to the car manufacturing analogy. When the SAP approach would be applied to car manufacturing, the resulting cars would all be blue and have all the primary functions a car should have for the intended use, and nothing more. For instance, a family car is a blue 5-door, very safe station car. And a medium transport vehicle is a blue van with a standard size loading volume. The engines in these cars would deliver exactly enough horse powers needed for the car's intended uses and nothing more. You are strongly discouraged from customizing the car to fulfill needs that are specific to your situation. No options whatsoever, the car is what it is. Once in your possession, you will treat the car as a mere tool that you happen to use for transportation. Nothing special, just a decent tool. You will have no idea, nor the interest of the car's internal workings, but only how well it provides the functions you need.

You can imagine what happens when a consultant from my kind is to collaborate with an SAP consultant on a system. I tend to want to understand the internal workings of parts of SAP, and if these parts really are suitable for the business in the long term and if they should perhaps be replaced with parts from other vendors. But the SAP consultant does not understand why I would want all that. The SAP consultant would specify the system in terms of business applications, where I would specify it in terms of technology components that ideally comply with open standards. We are both right in part. It is the classic clash between open and closed. I love that! I have such an exciting job!

Related articles by Zemanta

• Larry Ellison Tears Into SAP (gigaom.com)
• The Sleek and the Geek @ SAP (zoliblog.com)

Powered by ScribeFire.