It’s been more than two years since SAP revealed its new “run simple” market positioning. Back in 2014, Frank Scavo of Strativa and Computer Economics declared: “At first glance, the theme of simplicity is an odd one. For over 20 years, SAP has been widely regarded as having software that is functionally rich but enormously complex. Its name has become synonymous with implementation projects that run into the tens, even hundreds, of millions of dollars, sometimes ending in failure or at least in organizational exhaustion. SAP is easy to stereotype.”
Yes, SAP is easy to stereotype. And, the stereotype is based on evidence.
It’s unusual for me to name names. Particularly when it comes to a sometimes competitor like SAP. Nevertheless, I think it’s important to realize the real message behind the “run simple” campaign. To read between the tweets and the enormous marketing spend. SAP seems to have doubled down on this positioning, despite widespread skepticism. As Vinnie Michandani, the author of SAP Nation, wonders about the tag line:”‘When you run Live, you run Simple’ What does that mean?”
Here’s my take:
1) Shift of the Technical Debt Blame Game
ERP companies leveraged the flexibility of code customization to quickly enter new markets. I don’t think that it’s possible to provide massive configuration for multiple markets, as FreeBalance does for the government domain. The result has been highly customized code that is difficult to adapt to change in ERP applications like SAP. This is what the Gartner Group terms as “legacy” technology. A “run simple” theme is that massive customization is more a fault of customers. The myth is that customers ought to use vanilla or “out-of-the-box” configurations with so-called embedded best practices. Geoff Scott, CEO of the America’s SAP User’s Group was quoted by Katherine Noyes of PCWorld: “Most organizations don’t buy SAP because they have simple problems to solve. You purchase it because you’re a complex organization with complex business processes.” In other words, code customization is necessary, in SAP, to meet legitimate needs.
2) Feature Set for S4/HANA Limited
SAP, like most enterprise software vendors, leveraged existing client/server code for web products. These web-enabled products, often incorrectly called “web-based”, achieved faster time to market than rewriting software for the new deployment method. This became more difficult as systems moved from on-premises to the cloud. It exposed software architecture shortcomings. FreeBalance recognized the trends back in 2006, so we embarked on a complete web-native rewriting of our Accountability Suite. Microsoft started and abandoned a similar effort, Project Green. Oracle developed Fusion that provides some replacement for legacy business applications. S4/HANA is a bit late to the web-native party. That means that only subsets of functionality are available, such as “Simple Finance.” Therefore, SAP is positioning the lack of features in a positive light.
3) Customer Lock-in, the HANA Way
Large enterprise software vendors have been acquiring companies in a rush to own customers. These vendors have a wide range of business applications and underlying middleware. The rent-seeking idea is to sell customers the entire “stack” of software from a single vendor. This increases switching costs. It allows software vendors to own you. HANA is an in-memory database system. SAP is leveraging this database for transactional and analytic applications. That means that customers are locked into hardware platforms. That’s not to say that in-memory is not a good idea. It’s just that almost all the innovation for new database concepts come from open source. The “run simple” positioning suggests the number of tables are reduced and that there is no need for aggregate tables. This is a new definition of “simple”.
4) Real-time ain’t Real Time
Marketers are using the term “real time” so much that it’s lost all meaning. So, what SAP calls “real time” is not “real time” in the technical definition. It’s fast. The question is whether customers need that speed or not. That’s been a big struggle for SAP because the cost for “really fast” can be far more than “fast enough.” Often it’s a question of a small subset that needs to be immediate. And, that doesn’t require in-memory databases. For example, we’ve been supporting immediate checks for budget availability since back in the client/server days. In other words, the availability of budget, the “free balance”, was what our company was founded on. Yet, many systems built for the private sector required posting giving the opportunity to overspend the budget. (Or, the “vote”.) SAP is trying to create a sense of urgency that is unwarranted.
5) Growing SME Market
It is difficult to move downmarket in enterprise software. Feature richness makes implementations in small and medium-sized enterprises complex. That’s why this market is dominated by mid-tier vendors. But, it’s a growing market. It’s a market turning to the cloud. Therefore, SAP needs to get on the bandwagon as a kinder, gentler, simpler SAP. And, they need to get into this market without the overhead of high implementation costs – particularly costs incurred through systems integration firms.
6) Twisted Innovation Narrative
Marketers have also made sure that the term “innovation” has lost meaning. SAP seems to characterize every new feature as an “innovation.” S4/HANA required significant engineering skill. Much of that skill was about packaging and integration. In-memory databases have been around for some time. As have engineered systems. NoSQL, columnar databases, map-reduce and other innovations come from open source. SAP goes further to indicate that “run simple” and cloud enable customer innovation. That’s not exactly true: simple applications that are cloud deployed enable automating non-core functions. It’s the core functions that need to be automated.
Will SAP get simple? Be simple? As Brian Sommer of Diginomica has summed up, selling simple is not the same as achieving it.