Ariba

SAP S/4HANA at SapphireNow

Prior to SapphireNow 2015, I anticipated that SAP S/4HANA would dominate the event. Due to scheduling conflicts I arrived late, but from what I can tell, so did S/4HANA. Of course it did make its way onto the main stage later on in the opening keynote, but not with the fanfare expected for “the biggest product launch in the history of the company.”

Formally announced in February 2015, SAP S/4HANA is described by SAP as follows:

What is SAP S/4HANA?

SAP S/4HANA is a new product fully built on the most advanced in-memory platform – SAP HANA – and modern design principles with SAP Fiori User Experience (UX). SAP S/4HANA delivers massive simplifications (customer adoption, data model, user experience, decision making, business processes and models) and innovations (Internet of Things, Big Data, business networks, and mobile-first) to help businesses run simple in a digital and networked economy.

The SAP Business Suite is SAP S/4HANA’s predecessor. The Business Suite is just that: a suite of separate (integrated) products including ERP, CRM, SRM, SCM and PLM. Like the SAP Business Suite, SAP S/4HANA is designed for the large enterprise, but unlike the SAP Business Suite, all these separate products will be merged into a single product, SAP S/4HANA, eliminating any redundancy of data and the resultant synchronization or data passing. Both will play well with certain SAP cloud offerings including SuccessFactors (HCM) and the Ariba [supplier] network.

Also in February, Hasso Plattner announced that it would eventually satisfy the requirements of the same 26 industries SAP has spent decades building out, implying customers should be patient because this would indeed take time. After all, SAP had over 400 million lines of code to rewrite.

To get a better sense for the similarities and differences between the Business Suite and SAP S/4HANA, I would suggest you take a moment and read SAP S/4HANA: Simple, Fast, Different. That post concluded with “…the devil is in the details.” There were still many lingering questions over how both new customers and existing SAP customers would make the transition. Many industry observers were clamoring for more details on plans, roadmaps and specific status of different functions for different deployment options.

Some of those observers are still clamoring, some quite loudly. And as you might expect, they aren’t shouting SAP’s praises from the rooftops. They are looking for detailed roadmaps. But roadmaps for what? And where are they looking? I know SAP is preaching “Simple.” It is a commendable goal to try to simplify the implementation for any one customer. But where these customers are now is anything but simple.

Taken en mass, the “typical” SAP customer just doesn’t exist. The sheer number of different products, versions, databases, hardware platforms and configurations is staggering. Customers (or pundits) are not going to find all the answers and a road map wrapped up in a nice bow on a website. Each customer (and prospect) needs to engage one-on-one with SAP. And quite frankly, which customers raise their hands and express interest can and should impact the sequence in which SAP will deliver pieces of the puzzle.

If SAP publishes a timetable and sticks with it, come hell or high water, it runs the risk of not satisfying real demand. On the other hand if SAP publishes said timetable and then adjusts it according to actual demand, the industry observers without any skin in the game will cry foul. SAP will be damned if they do, damned if they don’t. There is a lot of moving parts here folks, and the more fluid and responsive SAP can be, the better for its customers.

That is not to say that SAP can afford to take its time and wait. But it is not waiting. While Hasso may have implied it would take time to bring those 26 different industries over to S/4HANA, indeed they are all there today – kind of. There was some disbelief expressed in the Executive Q&A when Bernd Leukert (member of the Executive Board and the Global Managing Board of SAP with global responsibility for development and delivery of all products across SAP’s product portfolio) announced they were all there. No, the development team did not rewrite all that code in the last 3 months, but it did make sure that the code supporting these industries was compatible with SAP S/4HANA. This is just the first stage in the full transition (rewrite) of code, but a necessary one if customers want to start making the move to SAP S/4HANA today as it is still progressing.

Customers starting on the SAP S/4HANA journey today will be running a mix of code that has been converted (to HANA) to be compatible and code that has been optimized. Customers that have not started the journey might need some help in seeing the (vast) potential benefits for doing so. Typically this assistance comes from other customers that already had an idea. Seeing those customers on stage is one of the reasons customers come to an event like SapphireNow.

But SAP S/4HANA is really too new for that. Or is it? SAP did have customers on stage, but they were more likely to be customers who had gathered experience through SAP Business Suite on HANA. So the stories tended to be more about HANA than S/4HANA. And as Jon Reed pointed out, Surprisingly, the business potential of the HANA platform is rarely factored into the initial HANA use case.”

I actually don’t find that surprising at all. First of all, for the first several years SAP itself had been talking about HANA as break-through technology in search of a problem. In recent years it has tried to shift the discussion to the business value, but that transition is hard because many SAP-ers and most industry influencers talk in “tech-speak.” Even those that insist they are talking about the impact on the business often litter the rhetoric with phrases like nearline storage, dynamic tiering, multi-tenant database containers, expansion in virtualization, publishing of objects, etc. ..along with a whole host of alphabet soup (SOAP, REST, HTML5, XML, etc.)

News Flash: business folks don’t know or care about these tech terms.

Those business users do care about speed of reporting. They care about getting answers to questions and knowing which questions to ask. And they care about reduced database size when you equate that to the cost of storage. They do care about being able to inventory and assess prior customizations that built barriers to into taking advantage of innovation and growth opportunities. They care about flexibility and agility in terms of the business as their organizations grow and restructure.

The real questions should be:

  • Can SAP S/4HANA deliver all these business benefits?
  • Can SAP deliver innovation to SAP S/4HANA that will help prospects and customers respond to real-world business changes?

The HANA platform is critical to delivering on the promise of the first question. In order to satisfy the second question, SAP needs to start delivering innovation faster than it has ever done so in the past. And the bar continues to rise on this. Its competitors that deliver only a single multi-tenant SaaS solution have a leg up in that they only have to maintain a single line of code. Others that continue to offer both cloud and on-premise solutions are forced to maintain multiple versions and also often offer a choice of operating system and database. For every hour they spend innovating, they must spend a multiple of that hour making sure it works across the entire spectrum of choice offered, in any possible combination.

In offering multiple deployment options for SAP S/4HANA is SAP putting itself at the tactical disadvantage of having to maintain different lines of code? SAP says no. While SAP has committed to delivering annual updates to on-premise customers, it pledges to deliver innovation on a quarterly basis in the cloud. And yet it claims to only maintain a single line of code, and delivers different configurations, updates and extensions through more sophisticated packaging of all these elements. This implies the core code base never changes, but all innovation is managed separately and then packaged with the base. I myself am a little unclear on the technical details here, but the goal is spot on. Business users will have to trust SAP on this for the moment. Time will tell if this approach is indeed sustainable and manageable.

The future of SAP S/4HANA depends on it.

Tagged , , , , , , , , ,

SAP’s Cloud Strategy: Striving For Clarity

Sometimes procrastination pays off. Whenever I attend an event like SapphireNow, I always write something about it. In the case of Sapphire in particular, I usually have several things I want to “say.” But it has been over a week since I headed out from the event (a bit early this year) and yet this is my first attempt to write anything. Why? First of all, I was on the road, but that usually doesn’t stop me. The bigger reason… I had been really looking forward to hearing about (and writing about) SAP’s cloud strategy.  With the acquisition of SuccessFactors and the reorganization of the teams, I had a lot of questions. Unfortunately the presentations (to groups both large and small) this year created more new questions than they answered and I struggled with how I could publicly voice my lingering questions and concerns constructively.

But before I resolved that dilemma, the picture changed.

Yesterday (May 22, 2012) SAP announced it would expand its cloud presence through the acquisition of Ariba. While I know Ariba quite well, I haven’t followed the company closely over the past several years. The SAP announcement said, “Ariba is the second largest cloud vendor and runs the largest global trading network, driving more than $319 billion in commerce transactions among more than 730,000 companies.” The acquisition will make SAP a clear leader in cloud Supplier Relationship Management (SRM) and also has a direct impact on some of my concerns.

My Questions

To put this in context, let me explain some of the questions I had after I heard Lars Dalgaard, former SuccessFactor CEO and now SAP Executive Board Member, speak about the company’s cloud strategy. During his keynote, and also in a press release launched during the show, cloud solutions were announced for four lines of business to manage people, money, customers and suppliers. That statement alone raised no red flags with me. Every company deals with those four elements in some form or another. But the comment Lars made next did cause concern. He added something along the lines of, “That covers everything any company would need.” With my own roots extending deeply in the manufacturing space, my first thought was, “Did I hear that right?” Those four elements are indeed critical to every manufacturer, but there’s also more to manage, like inventory, planning and scheduling, engineering and production. I Tweeted:

Didn’t hear @LarsLuv talk about #Manufacturing processes in #cloud #sapphirenow

So just to be sure, in the press conference that followed, I asked if this had been an oversight or had SAP specifically decided against competing in this market. The answer I got (from Lars himself) was that SAP thought the interest and demand for other solutions far outweighed the interest and demand for manufacturing solutions. This included solutions that surround ERP with functions such as CRM and HCM. History bears this out. Adoption rates for cloud solutions for these extensions far exceeds cloud-based ERP. But that’s more about what’s running in the cloud, not what kind of company is running it. So that implied (but didn’t specifically state) that other applications were a higher priority for the cloud than ERP.

OK, that’s a business decision and SAP appeared to be going where the easiest sell and the most opportunity was. I followed up with another Tweet saying it didn’t look like SAP was going after the same market as Plex Systems, a SaaS only ERP solution provider that markets and sells exclusively to manufacturers. Response in the Twitter stream went like this:

Hide conversation

 

William_Newman: RT @ERP_cindyjutras: Didn’t hear @LarsLuv talk about #Manufacturing processes in #cloud #sapphirenow > can already happen w/ @sapbydesign 11:46am, May 15 from Twitter for iPhone

 

LarsLuv: @William_Newman @erp_cindyjutras @sapbydesign that’s right, and we’re excited about this 2:23pm, May 15 from Twitter for iPhone

Now of course, having followed Business ByDesign since its very first coming out party in New York City in September 2007, I knew it had manufacturing functionality and I have spoken with more than a few manufacturers that use it today. That was partly why I asked the original question. But these exchanges left me more confused. I don’t expect the guy at the top to get mired in the details, but is SAP going after manufacturing with cloud solutions or not? I know it has a strong solution in on-premise solutions (the Business Suite and Business All-in-One plus complementary manufacturing and supply chain planning and execution applications), and I know partners strengthen the Business One offering for manufacturers. But I’m left thinking ByDesign will compete better against NetSuite’s solution for light manufacturing than it will against Plex Systems’ Plex Online or other mature ERP solutions for manufacturers now offered in various flavors of SaaS or hosting.

So what about ERP in general?

The second sentence of the cloud strategy press release continued, referring to the four lines of business, “These are planned to be offered in a consistent way and seamlessly integrated into enterprise resource planning (ERP) business software.” Now we already heard that SAP was responding to demand for other applications that extend and surround ERP (like HCM and CRM), and this statement implies these other applications will be fully integrated with ERP. Indeed Lars talked both about “loosely coupled end-to-end integration” and the press release states, “SAP plans to deliver its multitenant cloud solutions as a loosely-coupled suite of best-of-breed applications.”  But nowhere in the press release did it specifically talk about delivering ERP as part of the cloud strategy. Yet if Business ByDesign isn’t ERP then I wouldn’t know what else to call it today. And it is only available as a multi-tenant SaaS solution (i.e. via the cloud). Does this mean ByDesign will be transformed from ERP into a loosely-coupled suite of best-of-breed applications? Is there a difference?

Loosely Coupled versus Tightly Integrated

The difference lies under the covers. There is work to be done in order to make this transformation. SAP will be pulling different components out of ByDesign so they can stand alone. Finance will be first and in fact will be the solution to satisfy the “money” line of business referenced previously. This allows SAP to bundle different elements together like finance (money) and human capital management (employees). Other functions will be prioritized and extracted in the future, but finance is the logical place to start as it is probably the most marketable as a separate “best of breed” application.

Everyone needs general ledger, accounts payable and accounts receivable and many smaller companies are intimidated by the thought of implementing a full blown integrated ERP. And in offering these loosely coupled applications it provides the customers with more choice to keep other non-SAP solutions or even to buy new non-SAP solutions. While this provides more choice, it also encourages complexity and makes less business sense from a cross-sell and up-sell perspective.

The advantage of a tightly integrated ERP is the ability to eliminate redundant data and reduce complexity. There used to be an intrinsic functional advantage of “best of breed” applications over those included in ERP. The disadvantage (trade-off) of course was lack of integration. But those functional differences have shrunk over the years as ERP solutions offer more robust features and functions even in some non-core modules. And there is no integration required between the modules of ERP – it is all built in.

In terms of redundancy of data, with integrated ERP there is only one customer master shared by order management, accounts receivable and any other function that deals with customers. There is only one supplier master file shared by purchasing and accounts payable and perhaps manufacturing planning. This is one of the reasons most ERP vendors have moved away from selling individual modules in favor of a bundled set of core modules and charging on a per user basis. A customer using fewer modules will have fewer users and pay less. As they expand into new areas, they add more users (and pay more), but there is no additional license or installation to worry about.

SAP appears to be bucking this trend and moving in the opposite direction, moving from fully integrated ERP to loosely coupled best of breed applications. So in pulling out the finance function, SAP will need to bring the customer and supplier master files along with them. OK, that’s just a packaging issue. But those same customer and supplier files will also have to be bundled with best of breed order management and purchasing solutions. Then if a customer buys finance, order management and purchasing, will they have two copies of a customer master and two copies of a supplier master? Probably not. There are other ways to handle this – most likely by defining these masters as meta data. And it makes it easier to deal with multi-vendor solutions. Good for the customer, not as good (business-wise) for SAP. This isn’t especially difficult, but it will mean that developers will be working on this instead of working on innovation.

How does Ariba change the game?

Today all cloud offerings across these four lines of business: customers, money, employees and suppliers are managed in a single business unit run by Lars Dalgaard. When (and of course if) the acquisition is completed, Ariba will run as a separate SAP company. SAP has done this twice before rather successfully – first with Business Objects and then with Sybase. Eventually both were quietly merged into the SAP fold.  But in the meantime, there will be two business entities within the SAP corporate structure that together provide all the cloud offerings. When that happens the supplier area will land in the house of Ariba, as it should.

I actually think this will be a very good thing. Lars has great experience with Human Capital Management. He has a proven track record for delivering on a go-to-market strategy (something that has been lacking with Business ByDesign) and he has the necessary cloud DNA. He’s already brought energy and focus to SAP’s cloud strategy. But a global trading network and experience with supply chains and supplier networks is something that fits much more naturally into a manufacturing (and also a distribution) environment and Bob Calderoni (current CEO of Ariba) clearly has more experience on that front. Will Business ByDesign be divided up and shared or will it stay with Lars? I suspect had Bob been at Sapphire I might have gotten different answers to my questions about manufacturing and maybe even those about Business ByDesign.

Bottom line though… even as Bob and Lars manage different segments of SAP’s cloud strategy it is imperative that they work together as a single cloud team. The SAP co-CEOs said as much. And eventually SAP will quietly merge Ariba into SAP proper. At that point there may only be room for one of these powerful leaders at the top. Will this fact influence the journey up until that happens? Time will tell.

 

 

 

Tagged , , , , , , , , , , , , , , , ,