Le Blueprint, C’est Moi: the Counter-Customization Revolution comes to SAP SuccessFactors

Le Blueprint, C’est Moi:  the Counter-Customization Revolution comes to SAP

Sometimes revolutions start with a shot heard round the world, and sometimes they start with a quiet nudge in a new direction. The latter form of revolution was nudged into being for SAP’s HR customers last April in the form of eight words uttered by Mike Ettling, the president of SAP SuccessFactors, during an analyst summit in San Francisco. Ettling’s eight words have been said before, but the fact that they come from a man who is re-writing what it means to be a cloud company, and thereby what it means for customers to consume cloud services, adds enormous gravitas to the moment.

On the surface, I admit this revolutionary utterance seems absurdly benign. All Mike said was the following: “The blueprint should be banned. I’m the blueprint.” Pretty banal, no?

But behind those eight words are a veritable revolution in what it takes to be an enterprise software vendor and an enterprise software consumer. And while this revolution has already been underway for a while, in the world of SAP this revolution means that the status quo ante of software deployment and lifecycle services was just blown to smithereens.

First, let’s talk about why Ettling is going to become a hero by blowing things up. It’s simple: software projects are historically problematic, and Ettling has a plan to fix that.

The success rate of on-premise software deployment would be an industry shame if the industry had any shame. Instead, we’ve all become inured to the pain. It’s safe to say that up to two-thirds of all software projects fail to deliver on their expected results. Most are remediated, blowing schedules and budgets along the way, and annoying end-users, executives, bean counters, and the IT department to no end. But a significant number are cancelled outright or end up in court, tarring the reputation of the customer, service provider, and the vendor in the process.

To say this is the dirty little secret of our industry is to misstate the problem: it’s our dirty big secret. And it’s not even that secret.

What Ettling is referring to with those eight little words starts with the fact that every enterprise software project uses some sort of methodology as the basis for organizing the tasks to be undertaken by the IT department and its counterparts on the service provider side. The methodologies used in the SAP ecosystem are too numerous to count: SAP has at least four (ASAP, A20, various flavors of agile, and a new one, SAPActivate), and most of its services partners have their own as well.

Virtually every methodology has two basic things in common: they all have five phases, and the first phase is called something resembling “blueprint.” The blueprint phase is pretty much self-explanatory: the internal IT team, along with (hopefully) their business counterparts, sit down with the service provider team and hammer out the details of what needs to be done to adapt a largely generic system to the customer’s specific business requirements.

Sounds great, right? Isn’t imprinting the business requirements on the software what it’s all about? So why is Ettling channeling Louis XIV and declaiming “le blueprint, c’est moi?

The answer is that a significant number of troubled projects start with a troubled blueprint. Why? Because all too often free rein is given to perceived business requirements that ultimately mean a tremendous amount of customization. And that customization in turn leads to a lifecycle of complex implementations, complex on-going maintenance, and complex upgrades. This makes customization the the plague flea of enterprise software: easy to find, easy to spread, hard to get rid of, enormously irritating, and every once in a while its bite proves to be fatal.

The key here is “perceived business requirements.” Sometimes the perception of the business managers is spot on, but all too often the alleged business benefit is really just some individual’s or department’s misconception of what enabling competitive advantage in software is all about. When someone insists on a customization because “this is our competitive advantage” it’s more likely they really mean some variation of “this is the way we’ve always done things around here” or “I want the new software to look and feel just like the old software.” And everyone goes home itching and scratching.

What’s remarkable about cloud software like SuccessFactor’s Employee Central is that customization is severely limited, at least compared to the on-premise world. The limits to customization were originally a matter of efficiency for the cloud provider – too much variation between instances breaks the economies of scale of cloud computing by requiring too much one-to-one support. But what started as an expedient has turned into a virtue:  by building in an increasingly significant amount of best practices into products like Employee Central, customers of SuccessFactors can get a lot of their “perceived business requirements” taken care of without customization.

There will always be some customization – which in the parlance of the cloud is called configuration, meaning it doesn’t require one-to-one service to support it.  And there will always be the high-value consultative services that are needed to truly transform a company’s business, and thereby its IT systems. Configuration, and other services like SuccessFactors Intelligent Services Events, a mix of workflows and net new functionality, allow a fair amount of business-specific functionality to be baked into the system. And for the really hardcore, the HANA Cloud Platform supports custom applications integration with SuccessFactors without breaking the cloud support model.

Herein lies the essence of Ettling’s declaration: customization is not your friend. If you have any doubts about the veracity of that statement just ask the old PeopleSoft HR customers, who customized to their heart’s content and won an expensive and time-consuming upgrade as first prize. Customization is the gift that keeps on taking, and it’s time to put the kibosh on these “perceived business requirements”.

Why this is so revolutionary for SAP is simple: The R/3 juggernaut got its start as the poster child of business process re-engineering, which was a buzz-term ginned up by the big systems integrators to generate consulting services. And where customization is the plague flea of enterprise software, too often these consulting services are the plague rat of enterprise software: a vector for delivering a plague of costs and complexities.

The fact that the entire SAP on-premise economy has been built on this symbiosis is why “le blueprint, c’est moi” is so revolutionary. Take away blueprinting, and you take away a huge amount of consulting services that start during the implementation process and continue throughout the lifecycle of the software. It should be no surprise that when Ettling’s head of customer lifecycle engagement, Richard Campitelli, showed analysts the SuccessFactors SAPActivate methodology, it only had four phases – blueprinting was conspicuous by its absence.

In essence, Ettling is leading a classic revolution, despoiling the rich, dysfunctional relationship between complexity, customization, and IT services. SAP is starting this revolution with its cloud properties, but it’s sure to sweep the company over time.  For too many years, enterprise software vendors and partners have been complacent in a business model that discredits the industry. Vive la révolution.