SAP's Revamped Strategy for Small and Midsize Businesses

Dean Mansfield

SAP announced today the launch of a new division focused solely on sales of its systems to small and midsize businesses. The SMB Solutions Group will be headed up by Dean Mansfield and will focus on companies with up to 500 employees. Moving against the tide, Mansfield comes to SAP from NetSuite, where he headed up global sales and operations.

Product Strategy: Simplified Suite on HANA and Business One

What I find most interesting in the SAP press release is its ambiguity on what products Mansfield will be selling into the SMB market. The first part of the announcement appears to be saying that SAP will target the SMB market with a cloud version of its Business Suite, though it does not say so explicitly: 

Mansfield will execute on a board strategy to redefine the SMB business solutions market by creating the next generation of simplified, integrated business applications powered by SAP HANA®, delivered via the cloud that will solve tomorrow's complex SMB business challenges. 

The announcement then explicitly mentions Business One (a separate system from SAP's Business Suite), which will continue to be sold and supported through partners. It also refers to a push to move those partner offerings to hosting on HANA, as a separate deployment option for SMBs:

In addition, Mansfield will lead the current SAP Business One application portfolio, which will continue to operate through the Global Partner Operations organization, and plans to accelerate the adoption of SAP Business One, version for SAP HANA, as well as the SAP Business One Cloud solution, version for SAP HANA. 

What's missing from the announcement? Any mention of SAP Business ByDesign (ByD).

This lack of clarity about the products that SAP will offer to SMBs was also picked up by one analyst in SAP's quarterly earnings call. Adam Wood from Morgan Stanley, noting that SAP appears to have deemphasized ByDesign, asked SAP CEO Bill McDermott what would be the main product focus in SAP going to market with SMBs.

McDermott responded, in part:

ByDesign is still part of our product portfolio and we now have ByDesign on SAP HANA, which is absolutely a game changer because everything is faster and better on HANA as you know. [Emphasis mine.]

McDermott is a careful speaker, and his use of the word "still" is revealing. He wouldn't dream of saying, "The Business Suite is still part of our product portfolio," or "SAP HANA is still part of our product portfolio." The word "still," therefore, indicates that ByDesign is not part of SAP's core strategy.

McDermott continued:  

We also believe strongly that Business One has been going through an indirect channel now and has proven itself to be a very successful, high growth, double-digit business with good margin. So we will continue that. But we also put B1 up on HANA in the Cloud and we go global and we think that can be a very serious category killer.

Once it get into the market place and people see what it can do on HANA and we will continue innovate in that space now with a defined agenda underneath Dean Mansfield. So it's a combination of things we are going to go after the market with.

So, this confirms the implication in SAP's announcement that, in contrast to Business ByDesign,  Business One is strategic to SAP's SMB strategy.

Without directly using the words "Business Suite," McDermott then implied that the Business Suite itself, running on the HANA Enterprise Cloud, would also be a product offering for SMBs:

Related to the HANA Enterprise Cloud and the multi-tenant debate, the bottom line is the HANA Enterprise Cloud and each customer wants their solutions. They want it beautiful. They want them to work and yes, we can make money on it because HANA is the great simplifier.

When you radically simplify the IT stack--I mean SAP [in context, the SAP Business Suite--ed] used to run on eight terabytes of data. Now it's like closer to 1.5. You dramatically lower your cost of operation and improve the speed of everything in the operation. So it's perfect for "Run Simple." It doesn’t matter whether it's single- or multi-tenant. What matters is the customer gets what they want at the price point in the performance and the user experience they're looking for, and that's precisely what we intend to give them.

Will SAP's SMB Strategy Work? 

I would interpret SAP's strategy as two-fold. For really small businesses, starting at even five or 10 employees, SAP wants to continue its reseller channel strategy with Business One. For small divisions of larger companies, especially those already running its Business Suite globally, SAP will also position Business One, whether on-premises or hosted by partners.

For midsize companies, especially those that are growing and need more comprehensive functionality, SAP wants to position its flagship Business Suite. But this product has not performed well for midsized businesses in the past, even when packaged with preconfigured industry templates as SAP All-in-One, due to its size and complexity. SAP is betting that it will be successful with its "Run Simple" strategy to turn this product into a "Simple Suite." This is what McDermott was talking about when he mentioned going from 8 terabytes to 1.5. And, by running it as a managed service on the HANA Enterprise Cloud, SAP hopes to simplify the implementation and ongoing support experience for SMBs.

In my view, there are two risks in SAP's strategy and they both involve the Business Suite. First, even if "simplified," will midsize businesses find the Suite simple enough? The early signs with SAP's Simple Financials are promising. But is that possible with the rest of the Business Suite? Second, will the experience of the HANA Enterprise Cloud be as friendly as the cloud-only ERP providers, such as NetSuite, Plex, Rootstock, FinancialForce, and others?

In recent years, SAP had a cloud-only solution in Business ByDesign that was more directly comparable to the competition. That's no longer part of the plan. Rather, SAP believes that a combination of Business One and a simplified Business Suite will be a winning strategy. Time will tell.

Update, 5:22 p.m.: Removed references to Business One on Hana Enterprise Cloud (HEC), which does not appear to be part of the solution. Thanks to Dick Hirsch for the clarification.

Update, July 18: Dennis Howlett picks up on my post and provides more analysis, including a history of ByD.

Related Posts

Fighting Complexity: Can SAP Run Simple?

Fighting Complexity: Can SAP Run Simple?

When it comes to enterprise software vendors, SAP wants to be not just the largest but also the most simple. That’s the message behind SAP’s new theme, “Run Simple,” rolled out at its annual SapphireNow user conference in Orlando last week.

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.

Newly appointed to the sole CEO role, Bill McDermott set the tone in his kick-off keynote: SAP customers need to “fight complexity,” to simplify how they interact with their customers, starting with how they deal with their own workforce. At the same time, McDermott acknowledged that SAP itself has been part of its customers’ complexity. But n

McDermott is an inspiring and disciplined speaker. But fulfilling this vision will take more than an inspiring keynote. In my view, if SAP really wants to beat complexity, it will need to run simple in three ways: in its products, in its ongoing support, and in how it deals with its customers. So, let’s look at each of these.

Simple Finance the First Step toward a Simplified Business Suite

On the first day of the conference, SAP announced the future delivery of Simple Finance. As I see it, Simple Finance will be a major new release of SAP financial applications (starting with FI and CO) as the first SAP Business Suite products to undergo radical code optimization to take advantage of HANA, SAP’s in-memory database technology.

Based on interviews and a demonstration I received on the show flow, I see at least three ways that Simple Finance is, well, simpler.

• A simpler code base. Under HANA the applications can now simply record transactions and not have to create any summarized data fields for later reporting. With HANA, reporting always goes back to the source data in memory to build aggregated data fields on the fly. This shrinks the size of the programs, greatly reducing the number of lines of code, making them less error-prone and easier to debug. It also means that users can now drill down from summary data to details in any way they choose, without having to write special reports or customize the code.
   
• A simpler user interface. SAP Fiori provides the user interface for Simple Finance. Fiori apps operate across desktop and mobile devices to provide a simplified user interface for SAP’s applications. They are not just a new presentation layer but in many cases combine SAP transactions into a single user process. For example, entering a manual payment in Accounts Payable can now be done in a single screen instead of the multiple screens it previously required in SAP. On a side note, after much push-back from customers, SAP announced that Fiori apps will now be delivered at no charge to customers under maintenance, removing one barrier to adoption of Simple Finance.
   
• Simpler to implement. Implementation tools and methodologies are built right into the application, based on SAP’s previous work with its Rapid Deployment Services. These include wizard-like tools to guide and configure the applications. There are data migration tools to map data from existing systems into Simple Finance—whether from previous versions of SAP or from other systems. Implementation testing is also managed within the system itself. In addition, Simple Finance is integrated with SAP’s collaboration system, Jam, to encourage knowledge exchange. If a user runs into problems, for example, he or she can reach out to other users for help.

A date for general availability of Simple Finance has not been announced, only that early ramp-up customers are about to start implementation. Following Simple Finance, other parts of the Business Suite will also be “Simplified” until the entire product becomes a “Simple Suite.”

SAP personnel demonstrating Simple Finance appeared genuinely excited about the product. One indicated she was slated to work on implementations with early adopters. She said that she had even signed up some ramp-up customers earlier that day on the show floor, indicating a high level of interest.

I am optimistic that new prospects will find Simple Finance much more attractive than older versions of SAP financial systems. Simple Finance will be better received by midsize organizations that might have been otherwise scared off by the size, scale, and perceived complexity of SAP Business Suite. Score one for SAP.

My take: product simplification is the most straightforward mandate facing SAP. For the most part, it is only a technical challenge. SAP is loaded with software engineers, and HANA does represent a new paradigm for how business systems are architected. This is not to say there won't be bumps along the road, but I am hopeful SAP will get there.

Cloud Deployment Simplifying Ongoing Support

SAP also wants run simple in how customers keep their applications up-to-date. Like most traditional on-premises vendors, the majority of SAP customers are not on the latest releases of its products. The reason is that applying new versions (in SAP lingo, “enhancement packs”) is often a labor-intensive activity—testing the new code, retrofitting any customizations, regression testing to be sure nothing gets broken, and migrating data.

SAP’s solution is to take over these responsibilities by hosting customers’ systems in SAP’s HANA Enterprise Cloud (HEC). This program, already rolled out to some early SAP customers, is essentially a managed services offering in which SAP takes all responsibility for day to day operation of the system in SAP’s own data centers. Notably, SAP also takes responsibility for keeping the customer’s system up to date with the latest enhancement packs and bug fixes. It even supports systems with custom modifications.

The managed services offering should allow the customer’s IT personnel to focus less on technical aspects and more on business process design and effective use of the system.

My take: simplifying SAP’s ongoing support by moving customers to its managed services offering
will be more of a challenge. Only a tiny fraction of SAP’s customers are committed to this offering today. There is likely to be much inertia in SAP’s installed base about having SAP host their systems. Even though customers may be experiencing pain, many will view migration as short- term cost and effort for long term benefit. It may all come down to how SAP prices its managed services offering. If existing customers do not take up SAP on the offer, they will not experience much simplification in their SAP support experience, and SAP will retain its reputation for complexity.

Many other vendors have tried this approach—in particular, Oracle. Although most customers of Oracle Fusion Applications (Oracle’s next generation apps) are reportedly choosing the hosted deployment offering, I do not believe Oracle is seeing a mass migration of its preexisting applications, such as E-Business Suite, Siebel, JDE, or PeopleSoft, to its hosted delivery model. Will SAP’s experience be any different? I have my doubts.

Making SAP Simple to Deal With

The third way in which SAP must run simple is in its customer-facing processes. How easy is it for customers to deal with SAP? McDermott did not spend as much time in his keynote on this point, but he did emphasize it toward the end.

“Run Simple is more than a slogan for SAP--it is an organizing principle for our company,” he said. “We'll ask the tough questions: do our products and technologies run simple? Does our customer experience run simple? Are we empowering our employees to run simple? And are we enabling our customers and our partners to run simple? If not, hold us accountable.”

He continued: “For customers, we're committed to a beautiful user experience. We will make it simple to do business with SAP: simple pricing, pay-as-you-go in the cloud, simple web experience.”

Those are big promises. Anyone who has negotiated an acquisition of SAP software knows that SAP contracts are incredibly complex.  Pricing is opaque, with many various types of named users defined for each product. SAP’s terms and conditions around indirect access (when other systems access information from an SAP system) are onerous.

The result is that it is nearly impossible for an SAP customer to be fully compliant. When SAP does an audit of a customer’s use of SAP products—which it has the right to do—it will find problem, if it looks hard enough.

Even finding the right person in SAP's organization to deal with is not a simple matter. Whether it is the result of having a worldwide organization or peculiarities of German corporate governance, it is difficult to understand who reports to whom, or who is responsible for what.

Lars Dalgaard, founder of Successfactors, recently commented about SAP’s organizational problems.  “[SAP has] this messed up reporting structure where nobody reports to anybody,” Dalgaard said. “It’s this German thing where I didn’t even report up to Bill [McDermott] myself, I was reporting to the Supervisory Board. That doesn’t work. It just doesn’t. I mean, the COO doesn’t report up to the CEO?”

Dalgaard was positive about McDermott’s new role, however. “Someone has to be the decider, and with Bill, now they’ve got a decider on the job, I can tell you that,” he said.

The complexity of SAP’s organization not only affects customers; it affects anyone who has to deal with SAP. Talk to SAP partners, third-party developers, SAP suppliers, and industry analysts—nearly all of them say the same thing. SAP’s organization and decision-making processes are extremely difficult to navigate.

Following McDermott’s recent appointment to the role of sole CEO, SAP underwent a major reorganization, laying off an undisclosed but apparently significant number of employees. SAP claims this was not to cut costs but to better align the organization with SAP’s strategy. If so, the reorganization could be consistent with an attempt at simplification.

My take: SAP’s organization and customer-facing processes will be the most difficult to simplify. Technical simplification is an engineering problem. Support simplification can be solved if SAP can motivate customers to take up its managed services offering. But making SAP simple to deal with requires cultural change.

SAP’s culture manifests itself in how people are measured. One example: why did it take an outpouring of customer wrath for SAP to release Fiori at no charge to customers under maintenance? One source close to SAP told me that, within SAP, product groups are measured by their impact on revenue. If there is no revenue from Fiori, there is little recognition for Fiori developers. I have to believe that many SAP executives understood the opportunity in delivering Fiori at no charge. Some of us have argued that SAP stands to make more money by delivering Fiori at no charge (because it pulls through greater revenue opportunities with HANA and additional user seats). So, why wouldn’t SAP make this move sooner? If my source is correct, it is because that general lift in revenue would not be attributable to Fiori.

When you change program code, the program doesn’t fight back. But when you try to change a large organization, the organization often resists. Having a sole CEO will help, and McDermott appears determined. But has there ever been an example of a large organization that has become less complex over time?

What Does “Run Simple” Mean for Enterprise Tech Buyers

Large tech vendors change their marketing messages periodically, with no change to their core strategy, values, or culture. Is “Run Simple,” merely a branding exercise, or will it be a reality in how customers experience SAP? Time will tell.

In the short term, Simple Finance deserves consideration. In looking for new financial systems, business leaders who might have otherwise dismissed SAP as too complex should take a look at Simple Finance. New and existing customers should also investigate SAP’s managed service offering. But be prepared for continued complexity in dealing with SAP.

SAP did not become a complex organization overnight and it certainly won’t be easy to simplify. McDermott specifically told customers in his keynote to hold SAP accountable. I hope they will do that. I also hope McDermott will follow up in next year’s user conference with a progress report.

Related Posts

What Fiori Means for SAP and Its Customers
Risks and Opportunities with SAP's Platform Economics
Mad as hell: backlash brewing against SAP maintenance fee hike

What Fiori Means for SAP and Its Customers

Over the past several months, analysts and bloggers have been debating about whether SAP should offer its new user apps, Fiori, at no charge to customers under its maintenance program.

The debate can be difficult to follow for those not familiar with Fiori or SAP's technology stack. This post summarizes the debate, including factors not often recognized, along with my view on what SAP should do in its own best interest and what it all means for SAP customers.

What is Fiori?  

SAP Fiori is a set of apps, newly written by SAP, that address the most broadly and frequently-used SAP functions, such as workflow approvals, information lookups, and self-service tasks. They provide simple and easy-to-use access seamlessly across desktops, tablets, and smartphones.

To get a quick idea what Fiori is all about, watch this short video with examples of SAP Fiori apps for managers, or click on the image on the right.

Fiori is more than just a new user interface. It is a set of cross-device applications that allow users to start a process on their desktop, for example, and continue it on a tablet or smartphone. SAP is developing its Fiori apps based on its latest user interface framework, SAPUI5.

SAP lists three types of Fiori apps: 

1. Transactional apps, which allow users to perform SAP transactions on mobile devices, as well as desktops. For example, there is a transactional app for creating a leave of absence request and another for approving a purchase order.
    
2. Fact sheets, which display information about key business objects in SAP. For example, there is a fact sheet app for viewing a Central Purchase Contract, which allows a user to also drill down into related entities, such as vendor contacts, items under contract, and terms.
    
3. Analytical apps, which allow users to display key performance measures and other aggregate information about the business.

A complete list of all the current Fiori apps is available on SAP's website. At the time of this writing, SAP has released two waves of Fiori apps, of 25 apps each, with additional waves underway.

It is important to note that Fiori will never be a comprehensive UI replacement for SAP.  In a back channel conversation, I learned that most SAP ERP processes cannot be done with Fiori, now or in the future. Those SAP processes are simply too complex in their design and do not lend themselves to deployment on a smart phone or tablet. Everyone knows, for example, that you can do a lot more with the desktop version of Netflix than you can on the Netflix iPhone or iPad app. Likewise, it is difficult to take a complex SAP process and dumb it down to the point where you can deploy it on a smartphone.

Complicating things, Fiori is not the only development effort involving SAP's user interface. SAP has also released a product dubbed Screen Personas, which allows users to customize standard SAP screens to their liking. For example, using Personas, a user could remove fields of no interest or change the placement of fields on the screen.

SAP Customers Are Pushing Back on Pricing for Fiori

The best source of information on the debate about Fiori pricing is a diginomica post written by John Appleby, an SAP expert who works for an SAP partner, Bluefin Solutions. Some of what follows borrows from Appleby's post and its long comment thread. 

The list price for Fiori is currently a one-time fee of $150 per user and it gives that user access to all current and future Fiori apps. That might sound like a good deal, until you consider several factors. First, as Appleby points out, that $150 per user fee can add up quickly. If a user only needs access to one or two Fiori apps (e.g. approvals), the $150 fee gets expensive in companies with thousands of such users. In the comments, Jarret Pazahanick points to one company that has 80,000 employees and would have had to pay $12M simply to let all of its employees view their pay stubs using Fiori. Nevertheless, Appleby points out that there are scenarios where Fiori is easily cost-justified such as when enabling the salesforce with a number of Fiori apps: the $150 fee per user is a no-brainer in such cases.

But, more basically: what are customers paying maintenance for? SAP's current maintenance pricing is 22% of the customer's license fee, which means that, in fewer than five years, the customer has essentially purchased its entire SAP product portfolio a second time. Customers look at Fiori as an extension of the SAP products they have already licensed. Why should they have to pay more money to SAP in order to license Fiori? 

As Chris Kanaracus found when he interviewed those in leadership positions from three major SAP user groups worldwide, SAP customers are up-in-arms over SAP's policy of charging them for Fiori. It's reminiscent of the customer revolt against SAP's forced march of customers to higher levels maintenance fees a few years ago. It is also reminiscent of SAP's struggles with how to charge for its mobility platform and the SAP Netweaver Gateway, back in 2011.

Strangely, SAP's policy toward existing customers appears to be harder than it is toward new customers. Back channel conversations indicate that when SAP is selling net new deals, it nearly always demonstrates Fiori--because it shows really well. When it comes to putting together a proposal, then, SAP typically bundles Fiori as part of the total deal. 

Yet, when an existing customer wants to buy Fiori, that customer needs to pony up $150 per user. The exception, of course, is when the customer has something else it wants to buy from SAP. Then SAP can wink and nod and bundle Fiori into the deal with the other SAP products the customer is buying. In other words, unless you are willing to buy something more from SAP, you have to pay for Fiori.

Other Vendors Provide New Functionality at No Charge

Some on Twitter have argued that SAP's policy is no different than that of other vendors. I disagree. Some other vendors have a much more liberal approach to delivering new functionality to existing customers under maintenance at no additional charge. For example, Workday recently rolled out a new user interface, and previous revisions added extensive mobile support. Workday didn't charge its existing customers extra for this new functionality.  Salesforce did something similar with its Salesforce1 platform, a major new release of its Force.com platform--at no additional charge.

Furthermore, it is not just the pure cloud vendors who provide new functionality at no additional charge. For example, Microsoft Dynamics recently announced major new CRM functionality at no additional charge to existing enterprise users (the top tier of users). This was not a user interface upgrade but totally new functionality from acquired products: a complete marketing automation system, from its acquisition of Marketing Pilot, a social media listening system, from its acquisition of Netbreeze, and a new service desk system, from its acquisition of Parature.

Finally, releasing new functionality at no charge already has precedent within SAP. For example, in 2012, SAP released a new product known as HR Renewal, which encompasses learning, employee and manager self-service, personnel administration, organizational management, and more. All of this was provided at no additional charge to customers under maintenance. See this blog post from Jarret Pazahanick for details (including the comments). I see no logic in how SAP can charge customers for Fiori, while releasing HR Renewal to existing customers at no charge.

But...Paying for Fiori is the Least of the Problem

The argument to this point is simple: customers are paying maintenance on existing SAP products, and Fiori is an enhancement to those products. Therefore, SAP should make it freely available to customers. This was and is my position. But, as it turns out, for most SAP customers who want Fiori, that $150 flat fee per user is the least of their problems. There are two other obstacles to Fiori:

• Fiori needs current releases of SAP products. Some years ago, SAP introduced the concept of enhancement packs, whereby customers could selectively apply upgrades to individual SAP products instead of installing a completely new release. This approach is good: it lets customers can more easily install only the updates they really need or want. But it also means that many customers will not be completely up-to-date on all enhancement packs. Therefore, when a customer wants to install a Fiori app, the customer may first need to upgrade to a more current version of the product and install certain enhancement packs. Depending on how back-leveled the customer is, the upgrade can be a major effort. The prerequisites for each Fiori app are listed on SAP's website.  
   
• Fiori needs HANA. Sometimes lost in the debate is the fact that, to use Fiori, customers need to be running HANA underneath their SAP products. SAP explicitly says that HANA is a hard requirement for Fiori fact sheet apps and Fiori analytic apps. For transactional apps, SAP says, somewhat cryptically, "They run best on an SAP HANA database, but can also be ported to other databases with acceptable performance." A back channel conversation with someone in a position to know, however, says that without HANA, Fiori transactional app performance is slow on mobile devices and, as a result, may not deliver a positive user experience.

Neither of these are small issues. One source with direct Fiori experience reports that the biggest problem is the effort required to upgrade SAP products and the expertise required to install Fiori. What percentage of SAP customers have all the upgrades and enhancement packs in place for Fiori? It is impossible to determine, but it cannot be a large percentage.

Another source points out that slow adoption of HANA is a major impediment to Fiori. Out of approximately 40,000 SAP Business Suite customers, only about 1,000 have bought Business Suite on HANA, and SAP doesn't say how many of them are live on HANA. Even if all of them are live on HANA, that is less than 3% of Business Suite customers. Charging for  Fiori is "a small barrier" in comparison to the need to implement HANA.

SAP Could Make More Money By Giving Away Fiori

So, if the price tag for Fiori is the least of customers problems, why not turn it around and ask, what would it mean if  SAP were to offer Fiori to existing customers at no charge?

• It would give a positive reason for SAP customers to upgrade to HANA. The real opportunity, in my opinion, is not some small amount of revenue SAP might receive from sales of Fiori to existing customers. It is in moving those customers to HANA.
  
  SAP has staked its entire product strategy on HANA. Yet, as we have just shown, fewer than 1% of Business Suite customers have purchased HANA. If SAP wants to be successful, it must do everything it can to move customers to HANA. Yet, the business case for Business Suite on HANA to date has mostly been, in effect, "you can do things faster." Yes, there are a few dramatic examples, such as large companies being able to do a complete MRP regeneration in seconds instead of hours. But for most customers, "faster" is not enough to justify the time and expense of a HANA migration.
  
  Fiori changes that. SAP can now say, if you go to HANA, you can change the user experience of SAP with these Fiori apps. Fiori, in effect, could be the trojan horse for HANA.
   
• It would sell more SAP user licenses. The only individuals who can use Fiori apps within a customer's organization are those who have a user license for the underlying SAP product. Fiori, therefore, may tip the scales in favor of getting more users licensed for SAP products.
  
  As Appleby wrote:

I don’t have any facts to support this, but it makes sense from a strategy perspective. Fiori Launchpad hosts multiple Fiori apps for a given person. If I’m a sales rep, then I could have approvals, accounts, and a bunch of other things. Each of these apps requires some user license of some kind....

If users are using Fiori, they will want new capabilities too, and those new capabilities have a sell-on, but only if people are using Fiori. Get customers on it, and get the account team in to sell-on.

Compared to the strategic value and revenue opportunities for moving customers onto HANA and selling additional user licenses, charging existing customers for Fiori is chump change.

SAP Has It Exactly Backwards

In summary, charging for Fiori is a big mistake for two reasons. First, it annoys customers, who need to see more value in SAP's maintenance program. True, it is unlikely that any single customer is going to migrate away from SAP simply because SAP is charging for Fiori. But SAP's stated policy reinforces the perception that there is not much value in SAP's maintenance program. SAP's most recently quarterly results show that SAP's core business--sales of its Business Suite--are shrinking. SAP, therefore, should be doing everything it can to keep the customers it already has.
 
Second, SAP in practice already gives away Fiori when it is part of a larger deal. As discussed earlier, nearly every Fiori deal to existing customers is by definition going to be a larger deal, either because the customer will need to license and implement HANA or because the customer will want to move additional users onto SAP in order for them to use Fiori.

In a subsequent email discussion, Appleby asks:

How can SAP positively motivate customers to move to SAP's innovation stack (HANA, Fiori, Hana Enterprise Cloud, etc.). This is where the good stuff will happen. Why isn't SAP bundling these three things together including the services to get customers there? Why doesn’t SAP take some of the risk up front to keep its relevance?

Taking it a step further, if Fiori is part of the key to moving customers onto SAP's latest technology stack, perhaps SAP should by paying customers to take Fiori, rather than charging them for it. The payment could be in the form of a moderate credit toward new user licenses or HANA licenses. Or, as Appleby proposes, a discounted bundle of products and implementation services.

Such a program would generate much good will among SAP's installed base and would further SAP's larger product strategy.

SAP Customers Should Investigate Fiori Possibilities

What does this mean for SAP customers? First, get up to speed on the Fiori apps currently available and show them to your end users. Long time SAP users are often jaded in their expectations, which means the bar is set pretty low. They will most likely be pleasantly surprised by the possibilities of Fiori. Screen Personas are another way to impress long-time SAP users with new possibilities. If they become supportive of Fiori and Screen Personas, they may give you the business case to make an investment.

Second, spend some time to determine what additional investments you will need to implement Fiori.  If you are like most SAP shops, you will need to upgrade some SAP products. You will also probably need to migrate at least some portions of your Business Suite to HANA. Or, at least you will want the option to do so if Fiori performance turns out to be unacceptable without HANA. You may also need some additional SAP user licenses.

Finally, talk to your SAP account representative about putting together a bundled deal for Fiori, Screen Personas, new user licenses, and the other technologies you will need, including HANA. Despite SAP's stated policy to charge for the new apps, it is likely that SAP will be quite willing to cut an attractive deal when there is a larger amount of money at stake. 

Update: Dennis Howlett had a post on diginomica last week where he delves into some of these same points.

Update, June 4, 2014: Better late than never. SAP, responding to pressure from its customers, announced during its annual user conference that Fiori apps and Personas will now be available to customers under maintenance at no charge. 

Related Posts

Risks and Opportunities with SAP's Platform Economics 
SAP innovating with cloud, mobile and in-memory computing
Mad as Hell: backlash brewing against SAP maintenance fee hike

SAP’s Database Strategy Faces an Uphill Battle

Last week I attended a half day SAP press conference in San Francisco, on the subject of SAP’s strategy for database technology and mobility. Both are hot topics in enterprise software, and there were plenty of announcements. In fact, it’s quite easy to get lost in the weeds. So, in this first of two posts, I’ll try to summarize what I see as the big picture for SAP’s database strategy.

SAP Positioning Itself as a Database Company

When SAP acquired Sybase in 2010, it said it was doing the deal primarily Sybases's mobility platform. But Sybase also has its traditional relational database products, leading with its Adaptive Server Enterprise (ASE) database. At the same time, SAP itself has been rolling out its HANA in-memory database (IMDB) technology. Until now, these two database products were managed separated, but no longer. SAP is consolidating all its database offerings—HANA and Sybase’s—along with middleware and tools, under one management unit.

There were many tactical announcements. SAP announced general availability of its BW business intelligence product on HANA, and its plan to make HANA available later this year as the database of choice for its small business customers of its Business One ERP product. In addition, customers later this month will have the flagship Sybase ASE database available as a deployment option for SAP’s Business Suite and All-in-One products.

SAP rolled out all of these announcements under the banner of its plan to become known as a database company.

Database Migrations Difficult to Justify

After the press conference, one SAP executive sensed my ambivalence about this plan. With Oracle taking an ever-increasing adversarial position toward SAP, I can understand SAP’s discomfort with having a large percentage of its best customers running on Oracle’s database. At the same time, the other two major providers of relational databases (IBM and Microsoft) are SAP-friendly. IBM is SAP’s largest system integration partner, while SAP and Microsoft often find their technology interests aligned. So, how do you threaten Oracle while not also threatening IBM and Microsoft?

Furthermore, does SAP honestly believe that existing SAP customers are going to migrate in droves from Oracle, IBM’s DB2, or Microsoft SQL Server to HANA or ASE? In the case of business analytics, there may be some movement toward HANA, yes, as the value of in-memory performance for analytic applications is somewhat easy to envision. But what about SAP’s business applications, such as Business One, All-in-One, and the Business Suite? With all the challenges and demands placed on CIOs these days, it’s difficult to imagine an installed SAP customer undergoing a database migration, simply to eliminate some Oracle, or DB2, or Microsoft SQL Server licenses. SAP insists there is business value for HANA in some transaction processing—and I can see that, say, in supply chain management. But is that enough to justify a database migration? Even less so, why would a customer swap out Oracle, DB2, or Microsoft for ASE, which is essentially a like-for-like product? I just don’t see it.

In side-bar discussions, SAP executives basically agree. Alright then, so the target is net-new application customers? But here the challenge is essentially the same. In most cases, business apps prospects already have skills and experience with Oracle, DB2, or MS SQL Server. Are they really going to want to invest in learning Sybase ASE, or HANA? Unless they can completely eliminate those other database platforms from their environments, going with Sybase or HANA is adding to their complexity, not simplifying things.

I think that selling databases is going to be harder row to hoe than SAP is making it out to be.

Subsidizing HANA May Meet Complications

Perhaps recognizing the challenge, SAP realizes it is going to have to sweeten the pot, especially for HANA. So, at the press conference, SAP announced that it is putting up some serious money, through two funds:

• For new and existing customers: a $337 million fund to subsidize services for SAP customers to convert to HANA. I assume the initial target for these funds will be in migrating business analytics customers to HANA.
  
  
• For technology start-ups: a $155 million venture capital fund through SAP Ventures for start-ups to build new apps on HANA.

It’s encouraging that SAP is putting its money where its mouth is. For customers, making a database change may not be cost-justified without some help from SAP. Moreover, tech start-ups may need some financial encouragement to build new products on HANA.

However, I see complications with each of these funding efforts.

• With the customer fund, there may be issues with SAP’s partners. By funding SAP’s own services to assist with HANA, SAP is taking work away from partners, who typically play a key role in SAP implementations and migrations. In response to my question on this, SAP executives said that it will bring partners into this work at some point in the future.
  
  Nevertheless, I have to believe that, at first, partners will view SAP as increasing its share of services at the partners’ expense. This is especially true under current economic conditions where customers can only absorb a certain amount of change at once. Moreover, by delivering HANA services directly, SAP delays giving partners the HANA experience they will need for the future. SAP can solve this problem, of course, by ponying up the money but letting customers choose whether to use SAP’s professional services group or partners to deliver the services, or by co-delivering services with partners.
  
  
• For start-ups, HANA may not be as attractive as SAP thinks. Looking back at SaaS and other tech start-ups over the past decade, most of them chose to build on open-source database technologies, such as MySQL or PostgreSQL. The reason, of course, is that open-source infrastructure minimizes their own costs as they grow. It also leaves more customer budget available to invest in the application, instead of the required infrastructure.
  
  I once asked a start-up executive why his firm was building on MySQL instead of Oracle. He replied, “Oracle scales technically, but it doesn’t scale economically.” I have to wonder if HANA will face the same resistance, even with funding from SAP Ventures. A quick check with associates indicated that there are already open-source in-memory databases (IMDBs), including CSQL and VoltDB. I have no knowledge of the capabilities of these products or how they compare with HANA. It is likely that HANA is head and shoulders above open source alternatives. But Oracle’s flagship database was and still is head and shoulders above open source capabilities, and that didn’t stop cloud start-ups from using MySQL and PostgreSQL.

Ultimately, very few organizations want to buy databases—or middleware. They want business applications, and those apps require databases and middleware as part of the technology stack. So, when SAP talks about becoming a database company, it’s hard for me to become excited.

Perhaps SAP already knows that it's going to be difficult. Earlier this year, it began floating the idea of making its goal, "to become the No. 2 database provider by the year 2015." But by the time of the press conference, the goal had been watered down to “becoming the fastest growing database provider.”

When you are starting from such a small market share, becoming the “fastest-growing” is not a very high bar.

Update, Apr. 16: Some deeper questions on Oracle's database strategy from Jonathan Wilson. And, a good post from Vitaliy Rudnytskiy, pointing out that HANA is more than an "in-memory database."

Related posts

SAP in Transition on Mobile, Cloud, and In-memory Computing
SAP Innovating with Cloud, Mobile and In-memory Computing